The profile is accurate, complete, and a day old. That’s the whole problem.

TL;DR — Real-time marketing on Data 360 is three components: ingestion (stream the behavioural event in), unification (resolve it to a person), and activation (act on it through Marketing Cloud Personalization). The constraint that shapes everything: real-time unification matches on strong keys only and appends — so it rides on the identity your batch stage already resolved, it doesn’t fix identity. The three-box diagram is simple; the dependency-ordered implementation is the work. This post maps the what and why — not the how.

You did the hard part. You stopped celebrating your match rate, went after the customers a single strong key couldn’t reach, and pulled them back into whole profiles. The view in Data 360 — the platform Salesforce renamed from Data Cloud — is finally honest.

And it’s still a day behind.

Because a profile can be right and still be stale. You know exactly who this customer is — what they bought, what they’re worth. What you don’t know is what they’re doing this minute, so you act on a photograph taken last night. The abandoned basket you email about tomorrow, once they’ve bought elsewhere. The churn signal you catch in next week’s refresh, after they’ve already gone quiet. The product they bought yesterday that your ads are still chasing them with today. Right answer, wrong moment.

Fixing that isn’t a single feature you switch on. Real-time marketing on Data 360 is a three-part flow: get the behaviour in (ingestion), resolve it to a person (unification), and act on it while the moment is open (activation). This post maps those three components — and why standing them up is a strategy, not a switch.

Component 1 — Ingestion: the behaviour has to arrive live, not overnight

The first thing that changes is the kind of data coming in, and how fast.

At this stage a genuinely new data type shows up: the behavioural event stream — page views, sessions, clicks, the live texture of what someone is doing right now. It arrives by streaming, through the Web and Mobile SDKs or server-to-server, event by event, as it happens.

It’s worth being precise here, because it’s easy to think you already had this. Earlier, you pulled a device or cookie ID out of your web analytics — but only as a static signal for matching, a clue to help decide whether two records were the same person. That is not the same as ingesting the events themselves. This is where the live behaviour actually flows in, as its own stream, not as an identity hint. Streaming, not the nightly bulk load.

Component 2 — Unification: real-time resolves on strong keys only, and rides on the identity you already built

This is the component everyone underestimates, because it carries a constraint that shapes everything else.

The resolution logic is the same logic — the same ruleset that unifies your data in batch. What changes is when it runs and, crucially, what it’s allowed to do at speed. At the real-time tier, matching happens on strong, exact keys only. The fuzzy, multi-signal recovery that pulled back your guest checkouts and two-email customers — the hard-won part of your batch work — does not run in real time. Real-time is also append-only: new behaviour is attached to a profile, not re-resolved from scratch. And an event that arrives without a resolvable key doesn’t get rescued live — it quietly falls back to the batch pipeline.

Read that constraint carefully, because it’s the whole point: real-time unification doesn’t fix identity. It appends live behaviour onto profiles your batch stage already resolved. The platform itself will not do real-time on a customer you haven’t already stitched together the slow, careful way. Which means the batch work isn’t a phase you finish and leave behind — it’s the foundation the real-time component stands on.

Component 3 — Activation: a current profile is worth nothing unless something acts on it

Resolving behaviour in under a second buys you nothing if the thing downstream still moves at the pace of a nightly job.

The third component is where the value is actually realised. Marketing Cloud Personalization consumes the resolved, up-to-the-second profile and drives the next message or experience while the moment is still open — the recommendation on the page they’re on now, the journey that reacts to what they just did, the ad that stops the instant they buy. Event in, resolved to a person, acted on — before the customer has moved on.

If activation is still batch, sub-second resolution is speed you paid for and can’t spend. The loop only pays off when it closes end to end.

The flow is a diagram. The implementation is a sequence.

Three boxes — ingestion, unification, activation — and an arrow between each. On a slide it looks trivial. It isn’t, because the boxes have an order and hard dependencies between them.

A trustworthy batch identity has to exist first, or real-time simply amplifies whatever fragments it inherits. The event stream has to be identity-aware — carrying a resolvable key — or it never resolves live at all. The anonymous-to-known behaviour has to be bridged, so pre-login activity attaches to the right person once they sign in. Only then do the real-time data graph and a real-time-capable activation layer earn their keep. Get the sequence wrong and you don’t get fast, right decisions — you get fast, confident, wrong ones, at a velocity that’s much harder to catch.

We’re not going to walk through that sequence here — the how is a piece of work in its own right, specific to your data and your stack. The point of this post is the shape of the thing: the flow is the easy part; earning it in the right order is the work.

Where this leaves you

Real-time marketing on Data 360 is three components — ingestion, unification, activation — and one uncomfortable truth sitting under them: the diagram is simple, and the implementation is a sequenced, dependency-ordered build that the platform will punish you for rushing.

Your profiles aren’t wrong. They’re late. And late has a price you’ve probably never itemised — every message that arrived a step behind the customer it was meant for.

Getting from batch to real-time is a sequenced implementation with hard dependencies — trustworthy identity first, identity-aware ingestion, a real activation loop. If you want a detailed real-time (L3) implementation plan mapped to your Data 360 setup, talk to us. We’ll show you the order it has to happen in, and where your current stack already helps or gets in the way.