How do you audit your data layer before an ecommerce replatform?

In short: auditing your data layer before an ecommerce replatform is not about checking that the tracking works today. It is about producing three things before the site changes: a frozen reference of what is currently collected, a quantified baseline of your volumes per event, and validation criteria that will tell you, after go-live, whether the gap comes from the new site or the new tracking. Without those three, the question is undecidable.

Two weeks after the relaunch. Conversions are down 22%. The question lands in the steering meeting: is it the site or the tracking?

Nobody can answer. Not because the team is weak, but because two variables changed on the same day and there is no reliable point of comparison. The tracking was rebuilt at the same time as the journeys, so the thermometer changed at the same time as the temperature. Three weeks then go into arguing instead of fixing, and meanwhile media budgets keep optimising against data nobody can vouch for.

This scenario is avoidable, but not after the fact. It is avoided beforehand, and that is what this article is about: what a pre-replatform audit has to produce, when to start it, and the traps specific to changing platform.

Why a replatform is the worst moment to discover your tracking

An ordinary release touches part of the site. A replatform touches everything at once: the CMS, the DOM, the URLs, often the GTM container, almost always the CMP. Every one of those is a direct dependency of the data layer.

But the real risk of a replatform is not that tracking breaks. That is ordinary, and it can be QA'd. The risk specific to a replatform is losing comparability. Until you can isolate the variable, no post-launch decision is sound: not "let's roll back", not "let's leave it, it will recover".

Our own measurements show a regression takes an average of two weeks to be noticed, except when it hits revenue directly. On a replatform, those two weeks land exactly inside the window where you are supposed to judge whether the new site performs.

The line to remember: a replatform does not just break events, it breaks your ability to prove what happened.

What a pre-replatform audit has to produce

A pre-replatform audit is not a report you read once. It is three deliverables that get used after go-live:

1. The frozen reference. The exact state of what is collected today: events, variables, typical values, destinations. If you have an up-to-date tracking plan, that is it. If not, the audit starts by reconstructing one from the existing site, and that is time to budget for.
2. The quantified baseline. Volumes per event over a stable period, typically 30 days. Not "add_to_cart exists", but "add_to_cart fires roughly 42,000 times a month, with value populated in 98% of cases".
3. The validation criteria. What the new version of the site must reproduce to be accepted. Written beforehand, agreed with the product and media teams, and enforceable on go-live day.

It is the third point that is almost always missing, and the only one that turns the argument about the data into a decision. A validation criterion reads like this: "purchase volume must not deviate by more than 5% from the volume normally observed, at comparable traffic".

When to start the audit

Six to eight weeks before go-live, not the week before.

That duration is not comfort, it is mechanics. The baseline needs 30 days of stable data, so it has to start before anything moves. Reconstructing a missing reference takes rounds with the developers. And above all: validation criteria have to be agreed cold, not in the panic of a new site launch, or they will be revised downwards at the exact moment they become inconvenient.

An audit started the week before the switch produces an observation. It does not produce a usable reference.

The pre-replatform audit, step by step

Freeze the reference

Document what the current site collects, event by event, with the variables and a real example value. Date the document and stop touching it: its value comes precisely from describing the before.

Measure the baseline over a stable period

Across 30 days, record for each event the volume, the fill rate of the key parameters, and the mobile/desktop split. Avoid sale periods or promotional peaks, which make the later comparison arguable.

Reference what has to be kept

Not everything deserves to be carried over. This is the moment to decide: which events genuinely serve a decision, and which were added for a need nobody remembers. A replatform is the rare opportunity to reduce scope rather than port it wholesale into the new platform.

Write the validation criteria

For every critical event, an acceptable deviation threshold and how it will be measured. Include revenue, consent rate and the fill rate of monetary parameters, not only event volumes.

QA staging before going live

As soon as staging is ready, hold it up against the reference site rather than against intuition. Replay the real journeys, including the account area, internal search and payment error states. Confirm too that the data actually reaches the tools, not just the data layer.

Check at day zero, day one, then day seven

On switch day, a full pass over the critical journeys. A week later, a quantified comparison against the baseline. It is that second check which catches the regressions manual browsing never shows: a parameter empty on one traffic segment, an event that only fires in one browser.

The validation table

Here is the structure we use to arbitrate a go-live. One row per indicator, compared against the baseline:

Reconciling against the back office is the most important row and the most often missing. It is the only one comparing your collection to an outside truth rather than to itself.

The attribution row is the one that surprises people most after a switch. A replatform changes the URLs, therefore the redirects, and a badly configured redirect loses the query string: the UTM parameters disappear en route and the traffic lands under "(direct) / (none)". Event tracking can be perfect and attribution still wrong, which moves the problem onto media budgets without touching the conversions you collect.

Traps specific to a replatform

• The new DOM breaks the triggers. GTM triggers based on CSS classes or element paths do not survive a theme change. They do not throw an error, they simply stop firing.
• The GTM container migration leaves two containers live. During the switch both coexist and every event is counted twice. It is one of the most common errors and one of the most flattering: traffic looks excellent.
• The CMP is reimplemented, and the order changes. New integration, new timing, and tags firing before consent where that was not previously the case.
• New URLs break trigger conditions. Any rule containing a URL fragment has to be rewritten, exclusions included.
• Navigation becomes client-side. Moving to SPA rendering changes how page views fire. The historical page_view either disappears or duplicates, depending on the implementation.
• The new funnel changes event semantics. A one-page checkout instead of three no longer has the same steps. The validation table then has to be explicitly adjusted, and that adjustment has to be written down, not improvised.

After go-live: the window where it is decided

The two weeks following a switch are when tracking is most fragile and least watched, because all the attention is on the site. They are also when a regression costs the most, since rollback and media budget decisions get made exactly there.

That window is what MayIA° covers. The reference produced during the audit becomes executable: LLM agents replay the journeys like a user, compare every observed event against what the reference declares, and the alert lands when the gap appears, not at the week-two steering meeting. In practice it turns the validation table above into an automatic control rather than a manual task nobody has time for during a launch. If you are at the stage of comparing approaches, we have covered the automated dataLayer QA tools and what separates them from QA done by hand.

In closing

Preparing an ecommerce replatform on the tracking side is not about checking that things work. It is about producing a frozen reference, a quantified baseline, and validation criteria written cold. Those three deliverables cost a few days before go-live, and they are the only thing that will let you answer in an hour, rather than three weeks, the question that will inevitably come: is it the site or the tracking?

Replatforming in the next few months and want the collection secured before the switch? Let's talk — we are happy to look at it with you.

FAQ

How long before a replatform should you audit the data layer?

Six to eight weeks before go-live. That is not comfort margin: the baseline needs 30 days of stable data, so it has to start before anything moves, and validation criteria have to be negotiated cold rather than in launch panic.

What is the difference between a pre-replatform audit and data layer QA?

QA checks that an implementation is compliant at a point in time. A pre-replatform audit additionally produces a frozen reference and a quantified baseline, which are used after go-live to determine whether a gap comes from the new site or the new tracking. QA looks at the present, the audit prepares the comparison.

Should you rebuild all the tracking during a replatform?

No, and it is actually the moment to reduce scope. A replatform is the rare opportunity to delete events added for campaigns nobody remembers. Mechanically porting everything into the new platform means paying maintenance on collection nobody uses.

How do you tell whether a post-replatform conversion drop is the site or the tracking?

By comparing collection against an outside truth, in practice the back office. If back-office transaction counts are stable while collected purchase events fall, the problem is in the collection. Without that reconciliation you are comparing two versions of the same measurement, which settles nothing.

What is a validation criterion?

An acceptable deviation threshold, written before the switch, between the new version and the baseline. For example: purchase volume must not deviate by more than 5% from the observed average, at comparable traffic. Written beforehand it is enforceable; improvised afterwards it gets revised downwards.

What are the most common tracking problems after a replatform?

GTM triggers based on CSS classes that stop firing after the theme change, two live GTM containers during the switch doubling the counts, a reimplemented CMP that changes firing order, and rules containing a URL fragment that have become obsolete.