Integrations
Web Behavioural Events into Marketing Cloud: Comparing Integration Patterns
Collection options for on-site behaviour, the latency each one really gives you, and what each pattern costs to run.
- Behavioural data
- Latency
- Architecture
"We want to trigger on browse behaviour" is one requirement sentence hiding four architectural choices: what you collect, how it is identified, how fast it needs to arrive, and how long you keep it.
The patterns
- Vendor collect script writing directly into Marketing Cloud — fastest to stand up, least control over the schema.
- Your own event endpoint, batched into a data extension — full control, more code to own, minutes rather than seconds.
- Tag manager into a customer data platform, then activated onward — best identity handling, most moving parts.
- Server-side events from your own backend — the most reliable of the four, and the only one browser privacy settings cannot quietly break.
Latency is a requirement, not a preference
Ask what the message is. An abandoned-cart reminder that arrives in twenty minutes is fine. A price-drop alert that arrives the next morning is not a price-drop alert. Write the acceptable delay into the requirement and most of the pattern choice makes itself.
Identity is where these go wrong
Anonymous events are cheap to collect and hard to use. If you cannot resolve a browsing session to the key your sends use, you have bought a very large table. Decide the stitching rule — logged-in id, hashed email from a form, or an explicit link event — before you collect anything.
{
"eventType": "product_view",
"occurredAt": "2024-11-01T09:14:22Z",
"anonymousId": "sample-anon-77",
"contactKey": null,
"sku": "SAMPLE-SKU-9"
}The cost nobody budgets
Behavioural data grows faster than every other table you own. Decide the retention window at design time, and make sure whatever you keep long-term is aggregated rather than raw.