Your real-time personalisation is late because your stack reacts in batch, hours or days behind the action. The fix is not to make everything real-time. It is to run real-time only where speed changes the outcome, cart recovery, in-session next-best-action, service recovery, and let batch handle the rest.
A customer browses trainers in your app on the train, checks a review on the web at their desk, then walks into your store at lunch. Three touchpoints, one person, one buying moment. Your system sees all three. It just responds to the first one the following morning, by email, about the trainers they already bought.
Why the message always arrives after the moment
Most stacks were built to process data on a schedule. Overnight jobs pull the day’s events, refresh the segments, and load the campaign platform. It is tidy, cheap, and hours late.
That delay was fine when personalisation meant a weekly newsletter. It is not fine when the customer is moving across app, web, store, and connected TV inside a single session. The signal that matters, the action they just took, is exactly the signal a batch stack cannot see until tomorrow.
So the message fires against yesterday’s picture of the customer. It recommends the thing they viewed and already bought. It offers a discount on the item they returned. It reads as tone-deaf, because it is answering a question the customer stopped asking hours ago.
The common response is to badge the existing batch flow as “real-time” and trigger it a bit faster. That does not close the gap. A campaign triggered fifteen minutes late is still late for the moments that need seconds, and it is over-engineered for the moments that were fine at a day old.
The evidence
Two numbers explain why this stays broken. 43% of companies struggle to maintain accurate, real-time customer data (Contentful). And 29% cannot give internal teams a single source of truth (Contentful). Those are the same wall, seen from two sides. If the data is not current and not agreed, a fast response has nothing reliable to fire from.
This is why the ambition is common and the delivery is rare. Nearly every brand wants to react in the moment. Far fewer have the resolved, current customer record that makes an in-moment reaction correct rather than just quick.
Is this you?
Five quick checks. Answer each yes or no.
- Does a customer get an email about a product they already bought earlier that day?
- Do your abandoned-cart messages arrive the next morning, not within the hour?
- When someone acts on the app, can the store or web experience reflect it in the same session?
- Is “real-time” in your stack actually a batch job you scheduled to run more often?
- Can you name which moments in your funnel genuinely lose money to a delay?
Three or more yes answers means you are paying batch prices for a real-time promise you are not keeping.
What the delay costs
The cost is quiet, because a late message still counts as a message sent. The reporting looks busy. The revenue does not follow.
It shows up as abandoned revenue. A cart recovered within the hour converts far better than one chased the next day, and every hour of delay bleeds intent. It shows up as wasted contact. You spend a send, and a slice of customer patience, on an offer the moment has already answered. And it shows up as mistrust. A customer who is recommended the thing they just returned learns that your “personalisation” is not really watching, it is guessing on old data.
There is a second cost on the other side: over-building. Teams who feel the sting of lateness often buy streaming infrastructure and apply it everywhere, including the weekly emails that were perfectly fine on batch. That is real money spent to make slow things fast that nobody needed fast.
Three moves that actually work
You do not fix this by making the whole stack real-time. You fix it by being precise about where real-time earns its cost.
Name the moments that need speed. Walk your funnel and find the points where a response minutes late lands after the moment has closed. In practice it is a short list: cart recovery while intent is warm, in-session next-best-action while the customer is still browsing, and service recovery right after something breaks. Everything else can wait for the next batch without losing a cent.
Fix the foundation before the speed. A real-time response is only as good as the record it fires from. React fast to an unresolved or stale customer and you react fast to the wrong person. This is why the difficulty here is high: real-time sits on top of two problems you have to solve first, resolving the customer across touchpoints, identity resolution, and trusting the data you hold, data quality. Sequence in that order or the speed just multiplies the error.
Leave the rest on batch, on purpose. For every use case outside the short real-time list, keep the scheduled flow and stop apologising for it. A day-old product recommendation is not a failure. Spending streaming budget to shave hours off it is. The discipline is not “make everything fast”, it is “make the three moments that matter fast, and be honest that the rest are fine slow.”
Get those three right and the perception of your personalisation shifts, because customers judge you on the moments that felt watched, not the ones that were a day old. That gap between how good you think your personalisation is and how good it feels to the customer is its own obstacle, the personalisation perception gap.
Get the full real-time personalisation playbook.
Go deeper on customer data maximization
Three ways forward. Pick the one that fits where you are.
- Get the playbook. Practical notes on turning the customer data you already own into revenue, straight to your inbox. Join the newsletter at the foot of this page.
- Take the assessment. Score your customer data maximization in four minutes and see your top revenue blockers. Start the assessment →
- Book a meeting. Bring your data problem. Leave with a prioritised fix, not a platform pitch. Book a call →
Post 14 of 25 in the Customer Data Maximization series. Previous: How do you personalise without crossing the creepiness line?. Next: How do you keep messaging consistent across every channel a buyer uses?.
Frequently asked questions
What is real-time personalisation?
Real-time personalisation reacts to what a customer is doing right now, inside the same session, rather than acting on data collected hours or days ago. It means the next message or offer reflects the action they just took, while they are still in the moment that prompted it.
Why is my real-time personalisation always late?
Because most stacks process customer data in batch, on a schedule that runs hours or days behind the action. The intent that triggered the message has passed by the time it sends. The problem is rarely the message. It is the delay between the action and the response.
Do I need real-time for all personalisation?
No. Most personalisation runs fine on batch. A weekly product recommendation or a lifecycle email does not lose value if it is a day old. Paying for streaming infrastructure on use cases that batch handles well is wasted spend. Reserve real-time for the moments where speed changes the result.
Which use cases actually need real-time personalisation?
Three earn it: cart recovery while intent is still warm, in-session next-best-action while the customer is still browsing, and service recovery right after something goes wrong. In each, a message minutes late lands after the moment. Everything else can wait for the next batch.
Why does real-time personalisation depend on identity and data quality?
Because a real-time response is only as good as the record it fires from. If you cannot resolve the customer instantly across app, web, and store, or the data you hold is stale, you react fast to the wrong person or the wrong context. Speed multiplies whatever quality you already have.