The pre-launch tracking QA checklist (before you ship the new site)

A site relaunch is the single most common cause of broken tracking, because everything the tags depend on changes at once: URLs, markup, template structure, and the checkout. The tracking usually survives the design review and dies on launch day, discovered weeks later when someone notices conversions never recovered. This checklist is what to verify before the switch, on the staging site, while fixing things is still cheap.

Two weeks before: inventory what you have

You cannot verify a rebuild against nothing. Document the current state first:

1. Every tag currently firing on production, with its trigger and its purpose.
2. Every conversion action in every ad platform, and which tag feeds it.
3. Baseline numbers — daily sessions, conversions, and revenue for the last month. This is what you compare against after launch, and nobody ever has it when they need it.
4. Every URL that matters for tracking: the confirmation page, the thank-you pages, anything a trigger keys on.

If the new site changes URLs, get the redirect map now and check it against that list.

One week before: verify on staging

Everything here should be done on the staging environment, with a separate measurement ID so you are not polluting production data. Filtering staging traffic covers doing that properly.

Foundation

• The container loads on every template — home, category, product, cart, checkout, confirmation, blog, contact.
• window.dataLayer is initialised before the container, in the head. This one line causes an outsized share of launch-day failures.
• Consent defaults run before any tag. Denied by default, all four v2 signals.
• Only one GA4 measurement ID is present. Rebuilds frequently reintroduce a hardcoded tag alongside the container.

Events

Walk the real funnel and confirm each event fires once, with correct parameters:

• view_item with a populated items array.
• add_to_cart on the actual add, not on cart page load.
• begin_checkout.
• purchase, exactly once, with the correct value, currency, and transaction ID.
• generate_lead on every form, firing on success rather than on submit click.

Then refresh the confirmation page twice. No additional purchase events.

Advertising

• Google Ads conversion tag present on the converting page, with value and currency.
• Meta pixel initialised, with a deduplication event ID if you run the Conversions API.
• Any other platform pixel you actually pay for.

Consent

Test both directions, because testing one is how sites launch broken:

• Before choosing: no advertising cookies, consent-denied signals only.
• After accepting: tags fire, signals granted.
• After rejecting: tags do not fire, and the choice persists across pages.

Launch day: the thirty-minute check

Immediately after the switch, on the live site, in a clean browser profile:

1. Container loads on the live domain.
2. One GA4 ID, no duplicates. This is where a stray hardcoded tag reappears.
3. A real transaction end to end — a genuine low-value order, refunded afterwards. There is no substitute for this, and every team that skips it regrets it eventually.
4. Realtime reports showing traffic and the expected events.
5. No preview or debug parameters on the production container URL.
6. Redirects preserve query parameters — UTM tags and click IDs must survive, or paid attribution collapses on day one.

An external audit run against the live URL covers points 1, 2, 5, and the consent checks in seconds — what it checks.

Week one after launch: compare against baseline

This is the step that catches what the checklist missed.

• Daily sessions against the pre-launch baseline. A large drop usually means a template is missing the container.
• Daily conversions against baseline. A drop with steady orders means the tag, not the business.
• Reconcile revenue against your payment processor. Not GA4 against itself.
• Check every ad platform separately. They fail independently, and one silent pixel can run for a month.
• Check the hostname dimension for staging traffic leaking into production.

If something is wrong, the conversions-dropped runbook works through causes in the order that finds them fastest.

Who owns which check

A relaunch checklist fails when it belongs to everyone, so assign the columns before launch week rather than during it:

• Developers own container placement, dataLayer initialisation, and the ecommerce pushes. These are code, and they ship with the release.
• Whoever owns the container owns triggers, tags, consent configuration, and the Preview walkthrough.
• Marketing or the agency owns the ad platform side — conversion actions, pixel presence, and confirming that campaign links still carry their parameters through the new redirect chain.
• One named person owns the post-launch comparison against baseline, with a date in the calendar. Without this, week-one verification is nobody's job and does not happen.

Write the names down. The most common reason a relaunch breaks tracking is not that someone did their part badly — it is that a step sat between two roles and neither picked it up.

The three failures that account for most launch-day damage

A template missing the container. Usually a page type nobody thought to check — a search results page, a category listing, a legacy landing page still receiving paid traffic.

The confirmation page changed. A new URL pattern, a new markup structure, or a client-side confirmation view instead of a page load. Purchase tracking dies and nothing else does, so overall traffic looks fine.

Redirects stripping parameters. UTM tags and gclid lost in the redirect chain means every paid visitor arrives as direct. Attribution collapses while traffic looks normal.

FAQ

Should I use a separate GA4 property for staging?

A separate measurement ID at minimum, injected by build configuration rather than hardcoded. Otherwise every deploy test lands in your production data.

What is the most common tracking failure after a site relaunch?

A template missing the container, or a changed confirmation page breaking purchase tracking. Both leave overall traffic looking healthy, which is why they are found late.

Do I need to place a real test order?

Yes. Purchase tracking is the highest-value and most fragile part of the setup, and there is no substitute for a genuine end-to-end transaction. Refund it afterwards, and send the refund event too.

How long after launch should I keep checking?

Compare against baseline daily for the first week and weekly for the first month. Delayed conversions and weekly-cycle traffic hide problems that a launch-day check cannot see.

What if the new site changes all my URLs?

Audit every trigger that keys on a URL pattern before launch, and verify redirects preserve query parameters. URL-based triggers are the most common casualty of a restructure.

Run the outside check the moment you go live: the free tracking audit verifies tags, duplicates, consent, and preview leaks on any URL in seconds.