Migration › Knowledge Base › xdm vs data object
xdm vs data object
Two ways to speak to Adobe Analytics through the Edge. The xdm object is emigrating and learning the language, hard up front, but you belong, and every service understands you. The data object is travelling with a phrasebook, instant, but you stay a tourist.
The xdm object holds structured, schema-validated fields like xdm.web.webPageDetails.name; the Edge auto-translates recognised XDM into Analytics variables, and the same data is natively readable by CJA and RT-CDP. The data object lets you nest legacy names under data.__adobe.analytics[36][T4] (eVar1, events, products) and the Edge forwards them to Analytics almost verbatim[34].
The catch is reach: the data object lands in Adobe Analytics beautifully and arrives at CJA as gibberish. Every field you park there is a field you must hand-map in Datastream Data Prep later[22], and only for future data, never retroactively.
For your migration: go hybrid, weighted to xdm. Put everything with a clean home in XDM; reserve the data object for genuine awkward survivors, most often merchandising eVars and complex product strings. Treat anything in the data object as known, documented debt.
Use XDM by default. Use the data object only for documented edge cases, merchandising eVars and awkward product strings, and log every exception in the inventory.
The same data, two passports
Every Analytics value you send can travel in one of two containers. The xdm object carries structured, schema-validated fields, xdm.web.webPageDetails.name, xdm._experience.analytics.customDimensions.eVars.eVar1, which the Edge auto-translates into Analytics variables and which CJA and RT-CDP read natively. The data object carries your legacy names verbatim under data.__adobe.analytics[36][T4]: pageName, eVar1, events, products, even contextData.
Why the difference matters
Both reach Adobe Analytics correctly. The divergence is everything downstream: the data object reaches CJA as unusable noise, because CJA reads XDM and only XDM. Every value you place in the data object is therefore a value you will hand-map in Datastream Data Prep later[22], and Data Prep only fixes future data, never the records already collected. So the data object isn't wrong; it's deferred debt, and you should take it on deliberately.
The recommendation: hybrid, weighted to xdm
| Use xdm | for everything with a clean home, page details, the standard eVars/props/events via the Full Extension, identity, geo. The bulk of your implementation. |
| Use data | for genuine awkward survivors, most often merchandising eVars and complex product strings that don't ride productListItems cleanly. |
The cost of the hybrid is small, during debugging you check two places instead of one, and the payoff is large: migration velocity now and a CJA-ready foundation. Record the choice per variable in your inventory so the debt is documented, not accidental.