44 Seconds: How an AI Removed a Customer’s Fear and Recovered a £1,099 Sale

A real-time cognitive classifier built with XGBoost, FastAPI, and Node.js — deployed on SAP Commerce Cloud, extensible to any platform Source: Image by the author. Arjun is 33. Software developer. Laptop shopping for work. He visited the same product page three times over six days. Monday. Thursday. Sunday. He never bought. The website had absolutely no idea he had been there before. Every time, it showed him the same page. 47 laptop configurations. 342 reviews. A comparison table. A plain “Add to cart” button. On his third visit, our system watched him for 90 seconds. Not who he was. Not his name, age, or purchase history. Just what he did . He hovered on the battery specification for over 14 seconds. He scrolled back up to re-read the same section six times. He spent 48 seconds reading two-star reviews — specifically the ones mentioning battery life. He had visited three times and never once clicked “Add to cart.” He was not overwhelmed. He was not undecided. He had one specific, unresolved fear. The AI classified him. Four possible outcomes: Analytical → expand specs, show comparison data, use data-heavy social proof Overwhelmed → simplify the page, collapse to three options, hide filters Hesitating → address the specific fear directly, surface the right trust signal, change the CTA Default → confidence too low, show the standard page unchanged Arjun’s result: Hesitating. Confidence: 84%. It moved the battery guarantee to the top of the page. It surfaced five verified reviews from software developers praising battery life. It changed the button to say: “Add to cart — 30-day battery guarantee.” 44 seconds later, Arjun bought a £1,099 laptop. Six days. Three visits. Eight minutes of engagement. One unresolved fear. 62 milliseconds to remove it. A real-time behavioural classifier detects which of four cognitive modes a buyer is in — analytical, overwhelmed, hesitating, or default — and restructures the page experience accordingly. XGBoost. Under 50ms. $0.00056 per call. Deployed on SAP Commerce Cloud. Built in one week across ten phases. This article walks through every architectural decision and every line of code that made it possible. The Problem Nobody in E-Commerce Is Solving The industry has spent a decade building recommendation engines. They are genuinely impressive. Amazon’s recommendation engine drives an estimated 35% of its revenue . Netflix saves approximately $1 billion per year by reducing churn through recommendations. But they all solve the same problem — what to show. 70% of commerce website visitors leave without buying . Many of them know exactly what they want. They are not leaving because they saw the wrong product. They are leaving because the page was designed for a different kind of buyer. Source: Image by the author. The gap is consistent across every major tool — Dynamic Yield, Monetate, Optimizely, and Adobe Target. None detect what cognitive mode a buyer is in and restructure the page experience accordingly, in real time, for each session. That is the gap CCO closes. The Three Buyer Modes CCO Detects Every visitor is classified into one of four states. There are three active modes. One is a fallback. Source: Image by the author. The classifier does not lock a mode in. It updates every two seconds as new signals arrive. If Arjun had shifted from hesitating to analytical mid-session, the page would have responded accordingly. What We Built — Ten Phases in One Week Source: Image by the author. The Technical Architecture Browser └── cco-tracker.js (8KB · any website · collects 14 signals silently) │ ▼ every 2 seconds via sendBeacon Signals API (FastAPI · Python · port 8002) ├── XGBoost classifier → mode + confidence ├── Redis (session state · 1hr TTL) └── ClickHouse (permanent storage · training data) │ ▼ Experience API (FastAPI · Python · port 8001) ├── reads Redis for session mode ├── returns template instructions (JSON) └── 10% control group (always shows default — for measurement) │ ▼ OCC Middleware (Node.js · Express · port 3000) ├── calls SAP Commerce Cloud OCC API → real product data ├── calls Experience API → CCO instructions └── merges both → single response to browser │ ▼ Browser adapter └── CTA changes · sections hide · trust signals appear Source: Image by the author. The plug-and-play design is the key architectural decision. The CCO Core — the classifier, APIs, and tracker — never changes regardless of which commerce platform the client uses. Only the adapter layer is platform-specific. SAP Commerce Cloud was the first integration. Shopify and Salesforce Commerce Cloud adapters are in active development. Any platform exposing a REST API can be connected in days. The Project File Structure cco/ ├── middleware/ ← OCC Middleware (Node.js) │ ├── src/ │ │ ├── index.js ← Express server entry point (port 3000) │ │ ├── routes/product.js ← Merges SAP + CCO into one response │ │ └── services/ │ │ ├── occ.js ← Calls SAP Commerce Cloud OCC API │ │ └── cco.js ← Calls CCO Experience API │ └── .env ← Credentials (SAP URL, OAuth, etc.) │ ├── cco-core/ ← CCO Brain (Python/FastAPI) │ ├── signals/main.py ← Signals API (port 8002) + XGBoost classifier │ ├── experience-api/main.py ← Experience API (port 8001) + Redis templates │ ├── classifier/ │ │ ├── generate_data.py ← Generates synthetic training data │ │ ├── train.py ← Trains XGBoost model │ │ ├── cco_model.json ← Trained XGBoost model (production) │ │ └── training_data.csv ← Synthetic training data (bootstrap) │ └── pipeline/ │ ├── retrain.py ← Retraining pipeline script │ └── scheduler.py ← Weekly schedule runner │ ├── tracker/ │ ├── cco-tracker.js ← The 8KB JS tracker (drop on any website) │ └── test-page.html ← Local test page │ └── docker-compose.yml ← Redis · Kafka · PostgreSQL · ClickHouse The AI Decision: XGBoost, Not Any LLM Choosing XGBoost over any large language model — Claude, ChatGPT, Gemini, Perplexity — was a deliberate decision based on one hard constraint: 200 milliseconds. A page experience must be restructured before the customer consciously perceives the page. No LLM — regardless of provider — can classify within a page load window. Source: Image by the author. Here is the classification code: # The XGBoost inference — under 50ms def classify_mode(signals: dict) -> tuple: features = np.array([[ signals.get('spec_hover_ms', 0), signals.get('scroll_reversals', 0), int(signals.get('compare_tool_opened', False)), signals.get('visit_count', 1), signals.get('review_dwell_ms', 0), int(signals.get('checkout_clicked', False)), signals.get('session_duration_ms', 0), signals.get('scroll_speed_px_sec', 0), ]]) pred_label = int(model.predict(features)[0]) proba = model.predict_proba(features)[0] confidence = round(float(proba[pred_label]), 2) mode = LABEL_MAP[pred_label] return mode, confidence Source: Image by the author. For Arjun’s signals, this returned: Mode: hesitating Confidence: 0.84 Processing time: 48ms Cost: $0.00056 The classifier doesn’t just give a mode — it gives a confidence score. Think of it like a percentage. Arjun scored 0.84 — meaning the AI was 84% certain he was hesitating. That’s high enough to act on. Sessions scoring below 0.6 — below 60% certainty — see the default page unchanged. If the AI isn’t sure enough, it does nothing. A wrong intervention is worse than no intervention. The 8KB Tracker That Goes on Any Website The tracker is a single JavaScript file — 8 kilobytes, no dependencies. Deployed via Google Tag Manager in 10 minutes with zero code changes to the client’s website. // Signal collection — sends every 2 seconds via sendBeacon function flushSignals() { signals.session_duration_ms = Date.now() - START_TIME; const payload = JSON.stringify(signals); if (navigator.sendBeacon) { const blob = new Blob([payload], { type: 'application/json' }); navigator.sendBeacon(CONFIG.signalsUrl, blob); } } setInterval(flushSignals, 2000); window.addEventListener('beforeunload', flushSignals); The fallback rule: if the Experience API does not respond within 200 milliseconds, the page shows as normal. CCO never breaks a commerce page. The SAP Commerce Cloud Integration For the first deployment, CCO integrates with SAP Commerce Cloud 2211 using the OCC (Omni-Commerce Connect) API. The architectural decision: Spartacus adapter vs OCC middleware. A Spartacus adapter works only if the client’s storefront is built on Spartacus. An OCC middleware layer works with Spartacus, Accelerator (JSP), custom React, or any frontend that consumes OCC. We chose OCC middleware — it works for every SAP client regardless of storefront. // Both API calls run in parallel — one response to browser router.get('/:productCode', async (req, res) => { const [product, experience] = await Promise.all([ occ.getProduct(productCode), cco.getExperience(sessionId, productCode) ]); res.json({ ...product, // full SAP product data cco: experience // CCO experience instructions }); }); Source: Image by the author. The 200ms timeout rule — hardcoded: async function getExperience(sessionId, productId) { try { const response = await axios.get(experienceUrl, { params: { session: sessionId, product: productId }, timeout: 200 // hard limit — if CCO is slow, show default }); return response.data; } catch (err) { return null; // timeout or error — default page shows silently } } CCO never blocks a commerce page. If our service is unavailable or slow, the default page shows as if CCO did not exist. Testing the Full Flow End to End Once all services are running, testing the complete flow takes three curl commands. Step 1 — Simulate Arjun’s signals: curl -s -X POST http://localhost:8002/signals \ -H "Content-Type: application/json" \ -d '{ "session_id": "test-arjun-001", "product_id": "816324", "visit_count": 3, "spec_hover_ms": 14200, "review_dwell_ms": 48000, "scroll_reversals": 6, "compare_tool_opened": true, "checkout_clicked": false, "session_duration_ms": 92000, "scroll_speed_px_sec": 180 }' Expected: "mode_detected": "hesitating", "confidence": 1.0 Step 2 — Get the experience: curl -s "http://localhost:8001/experience?session=test-arjun-001&product=816324" Expected: "mode": "hesitating" with "cta_text": "Add to cart — 30-day guarantee" Step 3 — Call the middleware: curl -s http://localhost:3000/api/product/816324 \ -H "x-session-id: test-arjun-001" Expected: full SAP product JSON with a "cco" block containing experience instructions. The Self-Improving Loop The retraining pipeline runs every Sunday at 2 am automatically. # Deploy or rollback decision current_accuracy = get_current_accuracy() if accuracy >= current_accuracy - 0.01: deploy(model, label_map, accuracy) requests.post('http://localhost:8002/reload-model') else: rollback() log(f"New model worse. Keeping current. ({accuracy:.3f} vs {current_accuracy:.3f})") Source: Image by the author. The retraining timeline: Week 1–6,000 synthetic sessions → 96% accuracy on synthetic data Week 6 — first real sessions with outcomes → 80%+ accuracy on real behaviour Month 6–90%+ accuracy, catching hesitation patterns earlier in the session The model gets smarter with every session. A competitor starting today starts with no data. The accumulated learning compounds. The Numbers Source: Image by the author. The control group is not optional. 10% of sessions always see the default page. Without this, it is impossible to scientifically attribute conversion lift to CCO rather than seasonal trends. Every result we report is measured against a clean control. What Comes Next Source: Image by the author. How to Try It Access the GitHub repository with complete setup scripts, synthetic training data, Docker configuration, and documentation for deploying CCO on a test environment. Honest Challenges The 200ms constraint is both a strength and a limitation. It forces architectural discipline — but it also means CCO cannot use richer signals that take longer to process. Privacy is a genuine consideration. CCO uses no personal data , but behavioural data still carries implicit information. Clients deploying CCO in regulated markets (GDPR, CCPA) should review their data governance posture before deployment. The synthetic training data bootstraps the model to 96% accuracy on simulated behaviour. Real customer behaviour is always messier. The first weeks on a live site should be treated as a calibration period. Low confidence classifications — below 0.6 — fall back to the default page automatically. Early in deployment, this fallback fires frequently. As real session data accumulates, confidence scores rise and the fallback rate drops. CCO reshapes e-commerce by bending experiences to fit the cognitive modes of buyers — not the other way around. Madhuri Kolanu · Senior Technical Lead at Capgemini · Making complex AI concepts accessible to every professional. 44 Seconds: How an AI Removed a Customer’s Fear and Recovered a £1,099 Sale was originally published in Towards AI on Medium, where people are continuing the conversation by highlighting and responding to this story.