Recommendation engines that actually lift revenue

The difference between a recommender that lifts revenue and one that's just decoration comes down to signal, speed, and measurement. Get those three right and personalisation becomes one of the highest-ROI systems in the whole business. It's the single highest-leverage AI investment most retail and e-commerce teams can make.

Why Use Behaviour Instead of Just Purchase History?

Clicks, dwell time, cart adds, and searches carry far more intent than the sparse signal of completed purchases. Salesforce's State of the Connected Customer research finds personalized experiences are now a core driver of loyalty, not a nice-to-have. Blend real-time session behaviour with long-term preferences, fed by a data pipeline that reacts to what the customer is doing right now, not what they did last quarter.

Session Signals Carry More Intent Than Purchases

Most sessions never end in a purchase, which means a model trained only on completed orders is training on a tiny, biased slice of behavior. A shopper who views the same product category five times in one session, adds an item to cart, then abandons it, is telling you far more about intent than a purchase made three months ago ever could. Weight recent session signals heavily, and treat old purchase history as context, not the primary driver.

Blending Real-Time and Long-Term Preference

The best-performing recommenders don't pick one signal type over the other, they blend them. Long-term preference (category affinity, price sensitivity, brand loyalty built over months) sets the baseline. Real-time session behavior adjusts that baseline for what the shopper actually wants right now. A customer with a long-term preference for budget electronics who's spent the last ten minutes browsing premium headphones is signaling a shift the long-term model alone would miss.

Why Serve Recommendations in Real Time or Not at All?

• Precompute embeddings offline, but rank candidates in real time against the live session.
• Cap end-to-end latency to a few dozen milliseconds. A recommendation that lands after the page does nothing.
• Fall back gracefully to popular-in-category when you have no signal, so new visitors still see something relevant.

The Offline/Online Split That Makes Speed Possible

Computing a full embedding for every product against every possible customer state in real time doesn't scale. The workable split is offline/online: heavy embedding computation runs as a batch job against your product catalog and historical behavior, while the online path only has to do lightweight ranking of a shortlist against the live session. That split is what makes tens-of-milliseconds response times achievable without a massive real-time compute bill.

Setting a Latency Budget and Holding to It

A recommendation panel that renders after the shopper has already scrolled past it contributes nothing. Set an explicit latency budget end to end, typically under 100 milliseconds for the ranking call, and treat any breach as a production incident, not a tuning backlog item. That budget needs to account for network latency from the UAE to wherever the inference service runs, which is a real factor most teams underestimate until launch.

Cold-Start Handling for New Visitors and New Products

Two cold-start problems exist, not one: a new visitor with no history, and a new product with no interaction data yet. For new visitors, fall back to popular-in-category or trending-now, segmented by whatever context is available (referral source, device, time of day). For new products, seed initial ranking from catalog metadata (category, price band, attributes) until enough interaction data accumulates to switch to a learned signal.

Why Measure Incremental Lift Instead of Clicks?

A recommender can show high click-through while adding zero revenue, because it recommends what people would have bought anyway. Always test against a holdout and measure incremental lift. If the model can't beat 'no recommendations' on real money, it isn't earning its place.

Setting Up a Holdout Group Correctly

Carve out a small, randomized slice of traffic, typically 5-10%, that sees no personalized recommendations (or a fixed non-personalized baseline like best-sellers) instead of the model's output. Keep that holdout stable over the full test window, not rotated week to week, or the comparison stops being clean. Compare revenue per visitor between the two groups, not just conversion rate, since a recommender can shift what people buy without changing whether they buy at all.

Reading Lift Numbers Without Fooling Yourself

A positive lift number in the first week of a new model isn't proof it works, novelty and internal testing traffic both inflate early numbers. Run the comparison for at least a full business cycle, including any weekly pattern the store has, before trusting the result. And segment lift by traffic source; a recommender that lifts revenue for returning customers but does nothing for first-time visitors is a different, more limited win than the total number suggests.

The best recommendation isn't the one that gets clicked. It's the one that wouldn't have happened without it.

How Do You Respect the Customer's Limits?

Over-personalisation feels like surveillance. Diversify results, avoid creepy inferences, and give customers control. It's the same machine learning discipline that keeps any recommender defensible, not just accurate. Trust compounds, and a customer who trusts your recommendations buys from them for years.

Diversifying Results So the Model Doesn't Narrow the Store

A recommender optimized purely for click probability tends to narrow toward whatever the customer has already shown interest in, which shrinks the store to a tunnel of near-identical items. Explicitly inject diversity into the ranked list, adjacent categories, different price points, so the customer keeps discovering rather than just seeing the same five products reordered.

Giving Customers Visible, Usable Control

A 'why am I seeing this' link and a way to dismiss or downweight a recommendation category costs little to build and materially changes how personalization feels. Customers who can see and adjust the logic trust the system more than customers who experience it as an unexplained black box, even when the underlying model is identical.

What Does Real-Time Personalization Cost, and What's the ROI Timeline?

Cost scales with catalog size, traffic volume, and how much custom engineering the integration needs, not with the sophistication of the model itself. A retailer with a 2,000-SKU catalog and moderate traffic has a very different cost profile than one running 200,000 SKUs across multiple regional storefronts.

Where the Budget Actually Goes

The recurring cost is mostly inference and storage for embeddings, plus the engineering time to keep the offline pipeline feeding fresh data. The one-time cost is integration: wiring the recommendation service into product pages, cart, and checkout, and instrumenting the event tracking a good model depends on. Teams that underbudget the instrumentation step end up training a recommender on incomplete signal and blame the model when the real gap is upstream data.

A Realistic Timeline to Positive ROI

Expect 4-8 weeks to get a first version live with clean event tracking, then another 4-6 weeks of holdout testing before you have a trustworthy incremental-lift number. Retailers that skip the holdout step and declare victory off click-through alone routinely overstate ROI, then can't explain it when a board member asks for the number six months later.

What Changes for UAE and GCC Retail Specifically?

Three regional factors change how a recommendation engine should be built here, and most off-the-shelf platforms built for Western catalogs handle none of them well out of the box.

Bilingual Catalogs Need Bilingual Signal

Arabic and English product titles, descriptions, and search queries for the same SKU aren't just a translation problem, they're a signal problem. A shopper searching in Arabic and a shopper searching in English for the same product need to feed the same underlying interest signal, which most recommendation platforms built for single-language catalogs don't merge correctly by default.

Ramadan and Eid Traffic Break Steady-State Assumptions

UAE retail traffic and category mix shift sharply around Ramadan and Eid, gifting, modest fashion, and food categories spike in ways a model trained on steady-state behavior won't anticipate. Build in explicit seasonal retraining or at minimum a manual override for known high-traffic windows, rather than trusting the model to adapt on its own mid-surge.

How Should a Retail Team Evaluate a Recommendation Vendor?

Ask for a pilot against your own catalog and your own traffic pattern before signing anything. A demo running on the vendor's sample data tells you almost nothing about how the system performs on your bilingual catalog and your actual seasonal swings.

A Practical Evaluation Checklist

• Confirm native Arabic and English signal merging for the same SKU, not a translation layer bolted on after the fact.
• Ask how the system handles cold-start for new visitors and new products, with specifics, not a vague answer.
• Require a holdout-based incremental lift test on your own traffic before renewing past a pilot period.
• Check the latency budget end to end from your actual infrastructure, not the vendor's benchmark environment.

Talk to us about scoping a pilot against your own catalog and traffic before committing to a platform.

Frequently asked questions