Migration › Prove parity
Step 12 of 13
92% complete
Prove parity
A clean payload proves the plumbing works; it does not prove the numbers match, and "the numbers moved" is the single sentence that can sink a migration. So before anyone trusts the new data, you run it beside the old: AppMeasurement on its live suite, the Web SDK on your validation suite, side by side, and you reconcile them. Small differences are normal and expected, timing, bot handling, link heuristics, so the discipline is to agree what "close enough" means before you start, then investigate anything outside that band. This step earns the business's trust, and it deserves more time than any other.
What to do
1
Report Analysis Workspace on the validation RSID, walk your inventory variable by variable.
2
Identity Capture the ECID on both sides into the same prop, Web SDK exposes it at
a.x.identitymap.ecid.0.id, legacy uses mid. Same ID = continuity confirmed.3
Reconcile Agree thresholds first (e.g. page views ±2%, conversions ±1%). Root-cause anything outside the band.
⚠ Common mistake
Declaring success on payload validation alone and skipping side-by-side parity. The discrepancies then surface in month-end reporting, in front of stakeholders, not in a test.
Reality check
Differences within threshold aren't failures. Chasing a 0.5% delta to zero burns the time you need for the genuine outliers. And never run both libraries on the same page, that itself inflates the numbers.
✓ You should see
Every in-scope variable within the agreed threshold of legacy, and identity confirmed continuous across both suites.