Conversion tracking QA: a test plan you can run on every release
The short answer: keep a written list of the events that matter, test each one on every platform in each consent state, before and after every release that touches the site. Then automate the parts a script can check, so the test actually happens every time.
Tracking rarely breaks on its own. It breaks when something else ships. QA belongs at the moment of shipping.
Software teams would not ship a checkout change without testing checkout. They routinely ship it without testing that the purchase is still tracked, and find out weeks later from a dip in a dashboard. This is the test plan that closes that gap.
Step 1: the test matrix
List the events that carry money, the platforms that should receive them, and the consent states you support. Every cell is one check.
| Event | GA4 | Google Ads | Meta | Consent states |
|---|---|---|---|---|
purchase | ✓ | ✓ | ✓ | default, accepted, rejected |
begin_checkout | ✓ | – | ✓ | accepted |
add_to_cart | ✓ | – | ✓ | accepted |
| lead / sign-up | ✓ | ✓ | ✓ | default, accepted |
Keep the matrix short enough that someone will actually run it. Purchase in every consent state matters more than twenty upper-funnel events.
Step 2: what each check verifies
- Fires: the event reaches the platform (DebugView, Meta Test events, Tag Assistant).
- Once: exactly one event per action; reloading the confirmation page does not resend.
- Payload: value (a number), currency, transaction_id and items present and correct.
- Consent: behaves as designed in each state, including nothing firing before consent where that is the rule.
- Attribution survives: UTM parameters and click IDs such as
gclidstill reach the landing page after any redirect.
Step 3: before release, on staging
Run the matrix on staging with a test payment method. This is where a check should block a release: a purchase event that no longer fires, or a dataLayer push that fails its schema, is a defect like any other. See dataLayer testing for the schema side.
Need a quick baseline before you write a test plan? AuditTag lists the tracking it can detect on your public pages in about a minute. Run a free audit →
Step 4: after release, in production
Staging and production differ: different tag manager environments, different consent configuration, apps that only run live. After each release, run a short production check: one real low-value purchase, watched in each platform's debug view, then refunded. Record the result and the release it belongs to, so when numbers move later you can see which release was last verified.
Step 5: automate what a script can check
A headless browser can do most of this without a person:
- Load key templates and assert which tags are present.
- Walk the path to checkout, capture
window.dataLayer, and validate each push against the schema. - Record outgoing tracking requests and assert the purchase request is sent once, with a value.
Run it in CI on every pull request that touches templates or tags, and on a schedule against production. The schedule matters because many changes, such as app installs, tag manager publishes and platform updates, never pass through your deploy pipeline. That is the difference between QA and monitoring, and you need both.
The release checklist
- Does this release touch templates, checkout, tags, consent or apps? If yes, tracking QA is required.
- Matrix run on staging; purchase checked in every consent state.
- dataLayer schema passes for every ecommerce event.
- Released.
- Production test purchase watched in GA4, Google Ads and Meta; refunded.
- Result logged against the release.
How AuditTag handles it
What AuditTag checks
- Tag presence across your public pages (free audit)
- dataLayer ecommerce events against a schema, with exact failure paths (Guardrails)
- A post-deploy trigger URL your pipeline can call, so a check runs straight after each release (Guardrails)
- A CI template for running checks against staging (early access)
What this doesn't prove
AuditTag does not complete real payments, so the production test purchase is still yours to do. Automated checks prove the site sends what it should; only the platforms' own debug views prove what they received. Guardrails is in early access and onboarded hands-on.
Make tracking part of shipping
Start with the free audit of your public pages. If you want your checks re-run after every deploy, Guardrails is built for exactly that.
Run a free audit →Questions people ask
What is tracking QA?
Tracking QA is testing that analytics and advertising events still fire correctly after a change to a website, the same way software QA tests that features still work. It covers which events fire, what data they carry, whether they fire once, and whether consent is respected.
When should tracking be tested?
Before and after any change that touches the purchase path or the tags: theme or template changes, checkout changes, new apps or plugins, consent banner updates, tag manager publishes and platform migrations. Those changes cause the large majority of tracking breaks.
Can I automate conversion tracking tests?
Much of it. A headless browser can walk the purchase path, capture the dataLayer and outgoing tracking requests, and assert on them. What is hard to automate is completing a real payment in production, so most teams automate against staging with a test payment method and do a short manual check in production after release.
Who should own tracking QA?
Whoever ships the change should run the test, and one named person should own the tracking plan it tests against. When tracking belongs to everyone, marketing assumes development tested it and development assumes marketing would notice, and nobody does either.