Migration › Knowledge Base › Validation & parity
Validation & parity
Don't trust, verify, at three layers, in parallel, against thresholds you agree in advance. This is where migrations actually succeed or fail.
The three layers answer three different questions. The AEP Debugger shows what left the browser, the exact xdm/data JSON[25]. Assurance / Edge Trace shows what the Edge did with it[26], accepted, or dropped against the schema, with the offending field named. Analysis Workspace shows what landed in the validation suite.
Then you prove the numbers, not just the plumbing: run AppMeasurement and the Web SDK side by side (live RSID vs validation RSID) and reconcile[T3]. Capture the ECID on both into the same prop, Web SDK exposes it at a.x.identitymap.ecid.0.id, legacy as mid, to confirm the same visitor is seen as one identity. Agree variance bands first (say, page views ±2%) so a 0.5% delta doesn't trigger a fire drill.
For your migration: a clean payload is not proof the numbers match. Skipping side-by-side parity is how discrepancies surface in month-end reporting, in front of stakeholders. And never run both libraries on the same page, that alone inflates counts.
Agree variance thresholds before testing. Validate payload and parity, a clean payload is not proof the numbers match. Never run both libraries on one page.
Three layers of truth
Validation answers three different questions in sequence. The AEP Debugger shows what left the browser, open the Network tab[25] and read the exact xdm/data JSON. Its best trick: lock to your production domain and swap in your Dev tag library, so you can test new rules on the live site for your session only, with zero risk to real users. Assurance / Edge Trace shows what the Edge did, open Edge Trace[26] from the Debugger's Logs tab and watch the Edge validate and fan out; a schema violation is flagged and the payload reported dropped, with the offending field named. Analysis Workspace shows what landed in the validation report suite.
The parallel-run parity method
A clean payload proves the plumbing, not the numbers. So run both implementations side by side, AppMeasurement on its live suite, the Web SDK on the validation suite[T3], and reconcile. Capture the ECID on both into the same prop (a.x.identitymap.ecid.0.id vs mid) to prove the same visitor is seen as one identity. Build a real-time report comparing the two suites on key dimensions. Crucially, agree variance thresholds before you start (e.g. page views within ±2%, primary conversions ±1%), differences are normal, and a band keeps a 0.5% delta from triggering a fire drill.
Running both libraries on the same page simultaneously is unsupported; it causes duplicate identities and inflated metrics. Parallel validation means separate report suites; phased rollout means one library per page, never two.
When data is missing, trace the pipe
Don't guess; walk the layers in order, and the first failing one is your culprit:
| 1 · Rule | Did it fire? Right event, right Order, "run components in sequence" on? |
| 2 · Data element | Does %DL - X% resolve? Test _satellite.getVar('DL - X'). |
| 3 · Payload | Is the field present in the Debugger? If not → steps 1–2. |
| 4 · Datastream | Right ID for this environment? Analytics service on, correct RSID? |
| 5 · Edge | Accepted, or dropped for a schema violation? Which node? |
| 6 · Processing rule | For context-data paths, is the rule active? No rule = lost. |
| 7 · Workspace | Right suite, date range, latency elapsed? A reporting artifact, not collection? |