QA Ultimate Stack
Debug tracking end to end, from the page to the hit
The complete guide to tracking QA with ODDVX: write the dataLayer spec, check live pages against it, prove real form conversions, confirm every hit was delivered and measure what tags cost in page speed.
Tracking breaks in more places than one
When a conversion goes missing, the question "is tracking broken?" hides at least five different questions. Did the site push the event? Did GTM pick it up and fire a tag? Did the browser send the request, or did a security policy or a blocker stop it? Did the endpoint accept it? And did GA4 process it into a report? Each link can break on its own, and each one needs different evidence.
The QA Ultimate Stack is the set of ODDVX modules for that evidence. They test the chain link by link, the same way every time, across every brand you look after. This guide explains each link, which module tests it, and where to go next.
Five links in a row: the page pushes to the dataLayer, the tag fires, the browser sends the request, it is delivered, and it is reported, with CSP, blockers and consent marked as risks on the request.
Which module tests which link
Four modules cover the chain:
- DataLayer Governance & Parity holds the specification of what the site should push, tracks each brand's implementation, and checks live pages against it.
- Synthetic Form Test walks through real forms in a real browser and checks three layers: the dataLayer push, the GA4 tag hit and the cookies.
- Network Requests Inspector records every GA4 collect request a page sends, with full headers and payload, and says whether each one was delivered.
- Performance Test measures Core Web Vitals and, optionally, how long every Google tag takes to load.
A grid of the four QA modules against the dataLayer, tag firing, delivery, cookies and speed.
The one-by-one problem in DevTools
Most tracking QA is still done by hand: open the page, open DevTools, do the journey, filter the Network tab for "collect", read the payload, take a screenshot. That works for one page. It doesn't work for every key page and form on every brand, before and after every release, and it leaves no consistent record.
ODDVX keeps the pages, forms and expectations as saved checks. Each run applies the same checks the same way, and the result is pass or fail per brand, with the evidence attached.
A comparison: manual DevTools checks repeated for six brands, against saved ODDVX checks producing one report.
Read-only checks, and the one that submits
Almost everything in the QA stack only reads. Parity, the Network Requests Inspector and the Performance Test open pages the way a visitor would and never fill or click anything. The tags on those pages do fire, as they would for any visit.
The Synthetic Form Test is the exception. In Validate mode it fills every field but never clicks submit. In Run Test mode it submits real forms, and the brand's CRM receives them. That mode needs your explicit confirmation every time and is never available to a schedule. See Run real submissions safely.
A list of QA checks from read-only to real submissions, with the form test's Run Test mode marked as submitting real forms.
Debugging in the right order
Work down the chain and stop at the first broken link:
- Is there a spec? Without an agreed list of events and parameters, "wrong" has no meaning. Write the dataLayer spec.
- Does the page push what the spec says? Check a page against the spec.
- Does the conversion journey work end to end? Set up a form test.
- Did the hit leave the browser and arrive? Inspect every collect request.
- Did anything stop it? Content Security Policy, a blocker on the test machine, or a console error.
If all of those pass and GA4 still looks wrong, the problem is after delivery, in GA4's own processing or configuration. The GA4 Ultimate Stack picks up from there.
A branching diagram from tracking looks wrong to four questions, each leading to the module that answers it.
Free and Premium for QA
Every QA module works on Free, one at a time: one saved form config, one saved page for the Performance Test, one page per Network Requests Inspector run, and one dataLayer template with one saved parity check. Premium removes those limits so you can run many forms and pages together, export results to Excel or CSV, email them and schedule them. Compare the plans.
Two panels comparing the QA limits on Free and Premium.
What the QA stack can't prove
- That GA4 processed a hit. Delivered means the endpoint accepted it, not that it will appear in a report.
- Real-user speed. The Performance Test is a lab measurement; field data comes from real visitors.
- Forms inside third-party iframes such as HubSpot or Marketo. They are detected but not filled.
- Private or internal addresses. ODDVX only opens public web pages by default.
- Nested dataLayer values in parity. Parity checks top-level keys; values are checked by form tests and payloads.
- Every visitor's consent choice. Test each consent state deliberately.
A list of limits: delivery not processing, lab not field speed, third-party iframes, private addresses, nested values, consent and scheduled submissions.
Choose your workflow
| If you need to… | Read |
|---|---|
| Agree what the site should push | Write the dataLayer spec |
| Know which brand has implemented what | Track brand implementation |
| Check a live page against the spec | Check a page against the spec |
| Test a conversion form end to end | Set up a form test |
| Understand what a form test proves | The three layers of a form test |
| Submit real forms without polluting data | Run real submissions safely |
| Make sense of a failed form test | Read form test results |
| See exactly what a page sends | Inspect every collect request |
| Know whether a hit was delivered | Read delivery verdicts |
| Find hits blocked by the site's security policy | Find tags blocked by CSP |
| Check Meta, Google Ads and other pixels | Ad pixels and console errors |
| Explain a page that sends nothing | When the test machine blocks tags |
| Measure page speed | Measure page speed |
| See what each Google tag costs | Time every Google tag |
| QA a release | QA for every release |
| Get told when tracking breaks | Schedule QA that fails loudly |
Questions people ask first
Will QA runs show up in GA4?
Read-only runs load pages like a visitor, so their tags fire normally. Form tests can block GA4 hits with Anonymous Run, which is on by default. Filter the test machine's IP as internal traffic if you run QA on production often.
Will a form test create leads in the CRM?
Only Run Test submits, and only after you tick "I understand". Use obviously fake QA_TEST_ values and agree a filter with the CRM owner first. Validate mode never submits.
Can it test staging sites?
Yes, if they are publicly reachable. Private or internal addresses are refused by default.
Does it handle consent banners?
Treat consent as part of the journey: add the banner click as a form step, or test each consent state as its own run.
Do I need Premium?
Not to use any QA module one item at a time. Premium is for batches, exports, email and schedules.
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.