Visitor ID and identity stitching

A visitor ID is the identifier Adobe assigns to a browser or device so that hits can be grouped into visits and visitors; identity stitching is the process of joining those device-level identifiers - plus CRM IDs, emails, and offline keys - into a single person across channels. Get identity wrong and every downstream number about people is wrong with it.

The Adobe identity stack, briefly

Legacy implementations used the s_vi cookie per report suite. The Experience Cloud ID service (ECID) replaced it with one identity namespace shared across Adobe products. The AEP Web SDK generalizes this into an identity map: multiple namespaces (ECID, email hash, CRM ID) sent together, so Adobe Experience Platform can build an identity graph.

Stitching in Customer Journey Analytics

CJA connections choose a person ID per dataset - and that choice is the single most consequential setting in a CJA implementation. Field-based stitching (or graph-based, where licensed) re-keys device data to the person ID, joining pre-login and post-login behavior. Done well, cross-device journeys become analyzable; configured carelessly, sessions fragment or merge wrongly, and the corruption is invisible in the UI.

Why verification is not optional

Identity errors do not announce themselves. The symptom is subtle: visitor counts that drift from CRM counts, journeys that begin at login, conversion rates that differ by device in impossible ways. The only defense is reconciliation - counting people the same way in two independent systems and explaining every gap.

Frequently asked questions

What is the difference between ECID and a visitor ID?

ECID is a visitor ID - the specific one issued by Adobe's Experience Cloud ID service and shared across Adobe applications, replacing the older per-suite s_vi cookie. In the Web SDK era, ECID is one namespace inside a broader identity map rather than the whole story.