Migration › Knowledge Base › Context data
Context data
Think of data.__adobe.analytics.contextData as a diplomatic pouch; it carries your old labels through customs untouched, so the officers on the other side (your existing processing rules) still recognise them.
Many mature implementations lean on s.contextData[...] mapped to eVars and props by processing rules. Send those same keys via the data object's contextData and the Edge passes them to Analytics unchanged[36], your existing processing rules keep firing exactly as before, no rebuild required.
By contrast, a value sent through a custom XDM field group arrives as context data prefixed a.x., which then needs a processing rule to land in a variable. Context data of either kind is ephemeral: with no active rule to catch it, it's silently dropped.
For your migration: for a context-data-heavy implementation, the data-object path is a deliberate, low-effort bridge; it lets you migrate collection without rebuilding years of processing-rule logic. It's AA-only, though, so anything you'll want in CJA still belongs in XDM.
For AA-only continuity, send legacy context data via the data object so existing processing rules keep working. Anything CJA will need belongs in XDM.
The diplomatic pouch
Many mature implementations lean heavily on s.contextData[...] mapped to eVars and props by processing rules. The Web SDK gives you a migration-friendly path that preserves all of that: send the same keys via data.__adobe.analytics.contextData.<key> and the Edge carries them to Analytics unchanged, like a diplomatic pouch passing through customs untouched, so your existing processing rules keep firing exactly as before. No rule rebuild required.
The two paths, and when to use each
| Standard variable you control | XDM _experience.analytics..., auto-mapped, no rule, CJA-ready |
| Context-data key with an existing rule | data object contextData.<key>, rule keeps working, fast, AA-only |
| Custom XDM field group value | arrives as a.x.<tenant>... context data; map via processing rule |
The a.x. prefix, and a warning about ephemerality
Any custom XDM field that isn't auto-mapped reaches Analytics as a context-data variable prefixed a.x., for instance the ECID at a.x.identitymap.ecid.0.id. Context data of either kind is ephemeral: if no active processing rule catches it, it's silently discarded. So the data-object bridge only works while the matching rules exist.
The trade-off
This path lets a context-data-heavy site migrate collection without rebuilding years of processing-rule logic, a real, deliberate shortcut. But it's AA-only: the data object reaches CJA as noise. Anything you'll want in CJA still has to be modelled in XDM.