QA Ultimate Stack
dataLayer, tag hit, cookie: the three layers of a form test
A form test checks three independent facts. Learn what each layer proves, why a passing dataLayer can hide a broken tag, how listeners survive page navigation, and how cookies and duplicate fires are judged.
Three facts, checked separately
A form conversion depends on three things happening, and each one can fail while the others succeed:
- The dataLayer layer (always checked): did the site's own code push each expected event, with every expected parameter non-blank? This proves the website did its job.
- The tag layer (optional): did GTM fire a real GA4 hit for each expected event, with its parameters? This proves a tag is configured and firing.
- The cookie layer (optional): did each expected cookie actually land in the browser? This proves the tags' side effects worked.
The layers aren't paired. A flow can push two dataLayer events and fire three GA4 hits; each expectation is checked on its own.
Three steps for one submission: the required dataLayer check, the optional tag hit check and the optional cookie check.
Why a passing dataLayer isn't enough
If you only check the dataLayer, a paused tag looks exactly like a working one: the site pushes generate_lead perfectly and nothing reaches GA4. The same goes for a trigger whose condition never matches. The tag layer reads the actual outbound GA4 request, including first-party server-side endpoints on the brand's own domain, so it sees what GTM really sent.
Two panels: the dataLayer-only check passes, while the tag layer shows no GA4 hit because the tag is paused.
Listeners that survive the thank-you page
Many conversions only fire on the confirmation page, after the browser has navigated away from the form. ODDVX attaches its listeners before the first page loads, at the browser level, so they keep capturing across every navigation in the journey.
It also catches the hits browsers send as the page unloads. gtag.js switches to beacon transport at that moment, and some interception methods miss those requests; ODDVX listens in two ways so they're recorded. One timeout budget (10 seconds by default) covers filling, submitting and waiting for every expected event.
Four steps: listeners attach, form_start captured on the form page, a beacon captured during submit, generate_lead captured on the thank-you page.
First-party and third-party cookies
Cookies are checked once, after the events, with a short settle wait for cookies written just after a tag fires. They're classified against the form's own domain:
- A missing first-party cookie fails the test. Cookies such as _ga or _gcl_au on the site's own domain should be there.
- A missing third-party cookie is informational only. Browsers' tracking prevention routinely blocks them with nothing wrong on the site.
Two panels comparing first-party cookies, where missing is a failure, with third-party cookies, where missing is informational.
Catch conversions that fire twice
A double-counted conversion is one of the most common GTM bugs, typically a trigger that matches both the submit and the thank-you page load. Turn on the duplicate-fire check and, once everything has matched, the run waits a short grace period and counts every matching push and hit. More than one fails the event as "fired more than once". It's off by default because the extra wait only matters where you ask for it.
Two bars comparing an expected single conversion with an observed double fire.
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.