QA Ultimate Stack
A tracking QA run for every release
Combine the spec, parity, form tests, delivery checks and page speed into one repeatable release check, run before and after deployment, with a sign-off record.
One release, five checks
Most tracking breaks arrive with a website release: a redesigned form, a renamed field, a new consent banner, a tightened security policy. A release QA run checks every link of the chain on the pages that matter, in order:
- Spec: did the release change what the dataLayer should push? Update the template first.
- Parity: run the saved parity checks for the changed pages.
- Forms: validate every form config, then one real run of the main conversion with Anonymous Run on.
- Delivery: inspect the key pages for failed, blocked or missing hits.
- Speed: re-measure the same pages as last release and compare.
Six steps of a release QA run ending with a human sign-off gate.
Run it before and after
Run the playbook on staging before the release (where the site is publicly reachable) and on production straight after. Breaks that only appear on production, such as a CDN rule, a production-only security policy or a different container, are common. Comparing the two runs side by side shows exactly what the release changed.
A grid comparing parity, form, delivery and LCP results before and after a release.
When something breaks, start at the right link
Debugging goes faster when you start with the module that tests the link most likely to be broken, instead of opening DevTools on every page:
- An event is missing in GA4: was it pushed at all? Run parity, then a form test if it's a form event.
- An event arrives with wrong or missing values: compare the captured push with the spec in parity, then read the hit's payload.
- Conversions dropped after a release: run the form test. A renamed field, a new step or a confirmation page that moved will show as a specific status.
- A whole brand went silent: inspect its key pages and read the page diagnosis.
- Hits are delivered but GA4 is empty: check the Measurement ID and the consent state in the payload, then GA4's own filters.
- Pages got slower: re-run the Performance Test with the same runs and compare medians.
A table mapping tracking symptoms to the first question to ask and the QA module that answers it.
Record the sign-off
Keep a short record per release: the release, the checks run, the issues found and who owns them, the retest, and who signed off. Mark events Verified in brand status once they pass on production.
A release QA record form with the release, checks run, issues, owner, retest and sign-off.
ODDVX for Windows
From the page to the hit, proved.
Start free with one saved form, one page and one parity check. Premium adds batch runs, exports and scheduled QA.