Real-time vs. batch
Most personalization infrastructure is batch underneath. The warehouse computes segments overnight, the CDP syncs them in the morning, the activation tool applies them on the next qualifying pageview. Every step is reasonable; the sum is a machine for reacting to visitors after they've gone. The visitor whose behavior triggered the segment membership left hours before the segment landed.
Real-time personalization collapses that pipeline to the moment of interaction: the signal is read, the decision is made, and the page changes within the same pageview or visit. For the majority of commercial moments — an anonymous visitor deciding in one session whether this site deserves their attention — real-time is not a premium tier of personalization. It is the only kind that arrives in time.
A latency claim, not a data claim
"Real-time" says nothing about what data feeds the decision — it only promises the decision is fast. A profile-based system can be real-time, applying a stored segment the instant a recognized visitor lands; an in-session system is real-time by necessity, since its only input is behavior happening now. The evaluation questions to put to any real-time claim: what feeds the decision, where does it run, and does it beat first paint — because a "real-time" decision that returns after the page renders is flicker with better marketing.
One thing real-time should not mean is a language model in the live path. The per-pageview decision runs thousands of times an hour with revenue attached; it should be deterministic and local, with generative AI operating upstream — authoring variants and configuring segments — rather than improvising per visitor at runtime.