Migration › Knowledge Base › Identity & ECID
Identity & ECID
The ECID is a name tag your visitor keeps wearing between visits. The danger in this migration isn't losing data; it's accidentally handing everyone a fresh, blank name tag overnight.
The Experience Cloud ID (ECID) identifies a device across visits. AppMeasurement stored it via the Visitor API in the AMCV_ cookie; the Web SDK manages it natively in kndctr_ cookies. Left to itself, the Web SDK would generate brand-new IDs, and every returning visitor would look new.
The safeguard is idMigrationEnabled (the "Migrate ECID from VisitorAPI" checkbox), which defaults on[7]. It reads the existing AMCV_ cookie and reuses that ECID, provided the Web SDK runs under the same Org ID and same domain. Cross-domain continuity is handled separately, by appending identity to outbound links[8].
For your migration: this is the "visitor cliff." Teams skip validating it because the checkbox looks trivial[T1]; weeks later unique visitors spike and returning-visitor trends collapse. The build was correct, continuity was never confirmed. Verify in the Debugger that a returning visitor's ECID matches their old value.
Keep ECID migration ON and verify continuity in the Debugger before go-live. "Default on" is not "confirmed working."
The ECID, and where it lives
The Experience Cloud ID (ECID) is the identifier that lets Adobe recognise a device across visits. Under AppMeasurement it was managed by the Visitor API and stored in the AMCV_<org> cookie. The Web SDK manages identity natively and stores it in kndctr_<org>_identity, a different cookie. That difference is the whole risk: if the Web SDK simply starts fresh, every returning visitor gets a brand-new ECID and looks like a first-time visitor.
idMigrationEnabled, the bridge
The safeguard is idMigrationEnabled, surfaced in Launch as the "Migrate ECID from VisitorAPI to the web SDK" checkbox, and it defaults on[7]. With it enabled, the Web SDK reads the existing AMCV_ cookie and reuses that ECID, so identity is continuous across the switch. Two conditions must hold: the Web SDK must run under the same Org ID the Visitor API used, on the same domain where AMCV_ was set.
Teams treat the checkbox as trivial and never validate it. Three weeks after go-live, unique visitors spike and returning-visitor trends collapse. The implementation was technically perfect, identity continuity was simply never confirmed. "Defaults on" is not "verified on."
Proving continuity
During parity testing, capture the ECID on both implementations into the same prop. The Web SDK exposes it as context data at a.x.identitymap.ecid.0.id; legacy AppMeasurement uses mid. If a returning visitor shows the same ID on both, migration is working.
Cross-domain and authenticated users
Cross-domain stitching moves from the old appendVisitorIDsTo to the Web SDK's appendIdentityToUrl command[8] on links to your other domains, so the ECID rides the navigation. Authenticated users (a CRM ID) are handled by creating a custom identity namespace and populating it in the payload's identityMap[9].