# Real-time serving vs real-time decisioning

> Real-time serving and real-time decisioning sound alike but differ in when the decision is computed. Serving is how fast a stored decision reaches the page; decisioning is whether the choice uses what the person is doing right now.

_Last updated 2026-11-01. From The Personalization Guide, https://personalization.guide_

Real-time serving and real-time decisioning sound like the same thing and are not: serving is how
fast a decision reaches the page, while decisioning is whether the decision was made from what the
person is doing right now. The two get sold together as "real-time personalization," which hides the
part that actually matters.

## The distinction that gets blurred

Every personalization decision has two separate clocks. One is how long it takes to deliver the
decision once the request arrives. The other is how recent the data behind the decision is. Vendors
tend to advertise the first, because sub-second serving is easy to measure and easy to demo. The
second is the one that decides whether a system can react to intent.

**Distinguishing test: when was the decision made?** A batch decision is precomputed on a schedule and
served from a store, so it can be delivered in milliseconds and still be based on yesterday's data.
Real-time, or in-session, decisioning uses signals from the current session, so the decision would
change if the user's last click seconds ago had differed. Fast serving of a stale decision is not
real-time personalization.

## Why batch can still feel instant

A batch system computes its decisions ahead of time: overnight, or every few hours, it scores users,
builds segments, and writes the results to a store. At request time it does a fast lookup and returns
the stored answer. That lookup can be very fast, which is why batch personalization often feels
instant even though nothing about it is reacting to the moment. For many jobs this is the right
trade. A weekly lifecycle email or a segment-based banner draws on stable history and does not need to
know what the visitor did ten seconds ago.

## What in-session decisioning needs

In-session decisioning reads events from the current visit and folds them into the choice as it
happens. It needs a path that gets those events into the decision within the latency budget, which is
a different and more demanding architecture than a batch lookup: a streaming event pipeline, features
that are fresh at serving time, and a decision layer that can run per request. The payoff is that the
system can follow a browse path, rerank results as the session develops, and respond to intent the
moment it appears.

## The visitor that forces the issue

The clearest place the distinction bites is the first-time, anonymous visitor. That person has no
stored history, so a batch system has nothing to look up and falls back to a default. All the signal
there is lives in the current session: the search they just typed, the pages they are moving through,
the item in front of them. Only in-session decisioning can use it. Since anonymous and first-session
visitors are a large share of real traffic, "we do real-time personalization" means very different
things depending on which clock it refers to.

## Why it matters

When you evaluate a system, ask when its decisions are computed, not how fast they are served. Fast
serving of a day-old segment is a solved problem and a modest capability. Deciding from live,
in-session signals is the harder thing, and it is what the word "real-time" is usually meant to imply.
The freshness and identity questions underneath this are covered on
[the data and identity layer](/data).