When DTC brands evaluate personalization vendors, they tend to ask questions about algorithm quality, integration complexity, and pricing. The question fewer teams ask — but one that turns out to matter a great deal — is whether the personalization system operates in real-time or in batch.
The distinction sounds like an infrastructure implementation detail. It isn't. It determines whether the recommendations a shopper sees reflect their current intent or their intent from yesterday. For a store category where shopper intent can shift within a session — apparel, home goods, seasonal categories — the gap between real-time and batch is the gap between a recommendation that feels uncanny and one that feels irrelevant.
What "Batch" Actually Means in Practice
Most first-generation personalization systems — and several current mid-market vendors — operate on a batch processing model. Here's the mechanics: behavioral data collected throughout the day (page views, clicks, add-to-carts, purchases) is aggregated and processed in a scheduled job, typically nightly. The output of that job is a set of precomputed recommendation lists per user, stored in a lookup table. When a visitor's session begins, the system pulls their precomputed list and serves it.
The batch model has real virtues. It's computationally efficient because heavy model scoring happens once per cycle, not on every page load. It's predictable — the system state is deterministic at any point in time. And it's easier to audit, because you can inspect exactly what recommendations were computed and why for any user in the batch output.
The limitation is data latency. A batch that ran at 2:00 AM is serving recommendations based on yesterday's behavior when a shopper visits at 8:00 PM the following night. For a shopper whose interests shift across a season (they were browsing summer dresses in the morning, they're looking at transitional outerwear now), the batch model can't respond to that shift within a session. It's still showing them items correlated with the morning behavior pattern.
What "Real-Time" Actually Means
Real-time personalization means the recommendation scoring happens — or at minimum, the recommendation retrieval is filtered and reranked — based on within-session behavioral signals at the moment of each page load. The system doesn't just fetch a precomputed list; it applies the current session's behavioral context as a modifier to whatever base recommendation set exists.
The key word here is "modifier." Fully real-time personalization — where a from-scratch model inference runs on every page request — is computationally expensive and architecturally complex. What most production real-time systems actually implement is a hybrid: a base recommendation set (which might be precomputed or generated at session start) that is dynamically reranked based on within-session signals as they accumulate.
In Revlance, the architecture works like this: when a session begins, we generate a base ranked item set for the user (combining their historical preference vector and inventory state). As the session proceeds and behavioral events fire — a hover, a PDP view, a scroll depth event — those signals update a session-local preference delta that is applied as a reranking weight on the base set. The next page load gets the updated ranking. The latency on the reranking step is under 50 milliseconds, which puts it well within page render timing for any standard frontend implementation.
When Batch Is Good Enough
We want to be direct about this: for some DTC contexts, batch personalization is entirely adequate, and the added operational cost of real-time infrastructure isn't justified.
The primary case where batch is fine is email. Email is inherently batch — it's sent on a schedule, the recommendations are computed before send, and the recipients engage hours or days after computation. Even a "personalized" email recommendation block is operating on a profile that's at most a few hours old. Real-time infrastructure doesn't help here; what matters is the quality of the batch profile computation.
The secondary case is stores with slow-moving catalog and infrequent inventory changes. A furniture store where catalog changes happen quarterly and purchase cycles are measured in weeks has low within-session dynamics. A shopper who arrived looking for a sectional sofa will still be looking for a sectional sofa at page three. The recommendation set doesn't need to shift much within the session. Batch is adequate here.
Where batch fails is precisely the context most DTC brands operate in: fashion and apparel with weekly new arrivals and high stockout rates, home goods with seasonal trend cycles, beauty and wellness where a single influencer mention can make a specific SKU relevant overnight. In these contexts, a 12-18 hour stale recommendation set is showing shoppers things that may be out of stock, below the wave of current trend, or simply behind what the shopper's intent right now indicates.
The Inventory Staleness Problem
This deserves specific attention because it's the most concretely damaging failure mode of batch personalization in high-turnover DTC: recommending items that are out of stock.
A batch system that ran at 2:00 AM computed its recommendations before the store sold through 40% of its inventory during the next business day. A specific size of a popular jacket might have had 12 units in stock at 2:00 AM and 0 units by 11:00 PM. A batch system will keep recommending that jacket — including the exact size the shopper would order — until the next batch run, 3-5 hours later.
The shopper experience: you see a recommended jacket, you click through, you select your size, you get an "out of stock" message. Best case, you're annoyed. Worst case, you leave and buy it somewhere else.
Real-time inventory filtering solves this. The recommendation ranking incorporates a live inventory lookup, so SKUs with zero units in the shopper's likely size range are excluded from the recommendation set before it's served. This requires a product catalog integration that supports size-level inventory queries in low-latency — not all catalog APIs do this efficiently, but it's solvable and it's something we built support for in Revlance specifically because the batch failure mode was showing up so frequently.
Session Continuity: The Clearest Argument for Real-Time
The most compelling argument for real-time personalization isn't inventory filtering or trend responsiveness. It's session continuity — the ability for recommendations to evolve meaningfully within a single session as the shopper's revealed preferences become clearer.
Consider a concrete scenario: a visitor arrives on the homepage of a home goods store. Batch recommendations show them a mix of products based on historical profile. They click into the kitchen category, hover on two different cutting board products for several seconds each, then click through to the PDP for one. At this point, their revealed preference for kitchen accessories — specifically wood-toned, functional kitchen tools — is quite strong.
In a batch system, the recommendation rail that appeared on the homepage still shows the original mix. On the PDP they're now viewing, the "recommended for you" section shows items from their historical profile that may have nothing to do with kitchen accessories. The system hasn't updated.
In a real-time system, by the time the shopper lands on the cutting board PDP, the session-level preference signal has already shifted the recommendations. The "complete your kitchen" cross-sell rail shows items that are coherent with what the shopper just demonstrated they're interested in. The session feels responsive rather than generic.
This coherence — the sense that the site is tracking what you care about within a visit — is something shoppers don't articulate explicitly, but it shows up clearly in session depth and conversion rate comparisons between real-time and batch cohorts.
The Technical Tradeoffs to Know Before You Buy
If you're evaluating personalization vendors and "real-time" is on your requirements list, there are a few implementation details that determine whether the real-time claim is substantive or marketing.
First: where does the reranking happen? Client-side reranking (JavaScript running in the browser) is cheap to implement and puts no server load on the vendor. But it means the initial page load serves the batch recommendations, and they're only updated after the JavaScript has run and API calls have returned — typically 200-500ms after page render. For most pages this is fine. For the homepage on a fast mobile session, the initial render with stale recommendations is what the shopper sees first.
Server-side reranking, where the recommendation API returns an already-reranked set before the page renders, eliminates the flash of stale content. It requires a more sophisticated API integration and tighter latency requirements on the vendor side, but it produces a perceptibly better experience.
Second: what's the event pipeline latency? A real-time system is only as real-time as the time between a behavioral event firing and that event affecting the next recommendation. If the pipeline has a 30-second processing lag, the system isn't really real-time for most session interactions. Ask vendors for their p95 event-to-recommendation-update latency under realistic load conditions.
Third: how does the system handle the tradeoff between real-time signal weight and historical profile weight? A system that overweights within-session signals can swing recommendations wildly based on a single click, showing behavior that feels jittery and untrustworthy. A system that underweights them defeats the purpose. The right balance varies by context, and the ability to tune that balance per store or per page type is something to ask about explicitly.