What visitor ID stitching is
Inside AudienceStream (the CDP tier), visitor ID stitching decides when two or more identifiers - an anonymous cookie ID, a hashed email, a loyalty ID, a device ID - represent the same person, and merges their event history into a single profile when that condition is met.
When you actually need it
Any journey that crosses a device or channel boundary and needs to be measured as one person, not several -
- Mobile browsing that converts on desktop, or the reverse
- An in-store loyalty scan that should retroactively connect to prior online browsing
- A login event that should merge anonymous pre-login activity into the now-known profile
How to implement it properly
Define which identifiers are authoritative and in what precedence order - a verified login ID should outrank a device ID, which should outrank an unauthenticated cookie. Decide the merge rule deliberately: deterministic matching on a verified identifier is safer than probabilistic matching, and the choice should be a documented decision, not a default nobody examined. Set retention and decay rules for anonymous-to-known merges, and be explicit in reporting about what happens to pre-merge anonymous history - stitching changes historical attribution, which stakeholders need to understand before they see a number move.
How to verify it worked
Force a real test merge - a test login event with a known prior anonymous session - and confirm the two profiles collapse into one with combined attribute history, not merely that the new login event was recorded. Stitching logic and its available merge-rule options have changed across Tealium releases; confirm current behavior against your license tier and the current documentation rather than assuming legacy behavior still applies.
The claim that needs verifying, not assuming: that a merge actually combined history, rather than simply recording a new identifier alongside an unchanged old profile. Check the combined profile's attribute history directly.