Most production personalization still runs in batches. The model learns from the previous week's behavior, generates shopper affinity scores, and stores them in a lookup table until the next run. Page requests in between use what the model knew at training time, not what the shopper is doing now.
For many teams, that is sufficient. Batch is simpler to operate, its infrastructure is manageable, and a weekly visitor with stable preferences is not badly represented by a week-old profile.
Yet the shoppers who matter most to serve accurately are often those batch personalization misreads most.
Why the Latency Gap Matters More Than It Seems
Consider a shopper who spent fifteen minutes viewing camping cookware in your outdoor gear catalog last month. The batch model assigns a "camping cookware" affinity and highlights those products when the shopper returns today.
Today, however, they came from a social post about hiking trails and searched for "waterproof jacket" within their first thirty seconds. They want wet weather gear, not cookware. Because the batch model cannot see the current session, it relies on a snapshot that fits past behavior but misses present intent.
The latency gap is the distance between what the model knew at training time and what the shopper wants now. It is not response time measured in milliseconds, but information freshness: how old is the signal compared with the intent visible in the current session?
What Real-Time Personalization Actually Needs
Real-time personalization uses current-session signals in the ranking computation for each page call, rather than a pre-computed batch score. That is technically harder: a feature pipeline must extract, transform, and serve those signals within the page-load latency budget.
For product ranking, key session signals include current-session search queries, product detail pages viewed and dwell time on each, categories browsed, cart additions and removals, and engaged product price ranges. Together, they show what the shopper wants today, apart from their historical profile.
The strongest ranking combines session and historical data. Session activity shows intent, while history shows preference. A shopper who usually buys mid-priced homewares and searches for "serving bowl" can therefore see mid-priced serving bowls above premium and bargain options, since the model uses both price sensitivity and current explicit intent.
The Infrastructure Gap Between Batch and Real-Time
Real-time personalization is difficult less because of the inference model than because of the feature pipeline. Modern ranking models are fast. The pipeline must deliver session signals quickly enough for the complete system to fit an acceptable page-load budget.
A common production ranking target is sub-100ms end-to-end, from page request to returned ranked product list. Network round-trips, session signal extraction, feature vector construction, model inference, and result serialization consume that budget quickly. The session pipeline must be pre-built and event-driven, rather than calculated for each request.
We use an event stream for real-time session signals. Each click, search query, and page view is written to the stream in near real-time. A lightweight processor updates a session feature vector as events arrive. On a page call, the vector comes from fast cache, joins historical user features, and goes to the ranking model. The model reads the current state of an always-maintained vector instead of waiting for signal computation.
Our beta infrastructure reached the sub-50ms median ranking response we target by making session signal caching central to the pipeline. Inference tuning after the architecture is fixed rarely solves the problem. Real-time needs to shape the architecture from the beginning.
When Batch Still Fits
Batch personalization is not always wrong. Its latency gap may not affect outcomes for category-level affinity in email recommendations sent between visits, since those emails are created outside an active session. Weekly digest emails, abandoned cart sequences, and browse abandonment emails likewise reach shoppers who are not currently browsing, so current session context is unavailable. Batch affinity scores are appropriate there.
The same applies to catalogs where preferences stay highly consistent, such as consumable goods with predictable reorder patterns. For a shopper buying the same three products every six weeks, purchase history dominates, and the added complexity of real-time session signals contributes little over a well-tuned historical model. Session signals are noise by comparison.
Real-time helps most in high-intent browse sessions for categories with large assortments and cross-category discovery potential. There, the difference between current need and historical prediction is greatest, so fresh signals can improve ranking quality most.
How to Measure Real-Time Performance
The data can show whether real-time personalization works, provided you use the right metrics. Overall revenue per session lift is the objective, while revenue per session among high-session-depth sessions is the more useful diagnostic. These are shoppers who viewed multiple product pages before converting.
Deep browsers generate the richest current-session signals. If the real-time model captures and uses them, revenue per session lift should be higher for deep-browse sessions than shallow ones. Uniform lift across depths suggests the model is not ingesting those signals, or is not weighting them effectively against historical features.
The batch versus real-time latency gap becomes a missed-match rate: the share of visits where the ranking fails to reflect current intent because the model uses stale information. Across thousands of daily sessions, that rate compounds into measurable revenue left on the table each day.