Measurement audits: how to confirm GA4, GTM, and conversion pixels are capturing the right events

Executive brief

Key takeaways

• Detecting an analytics script in the page source confirms the tag exists, not that it fires or sends the right parameters.
• GA4 DebugView and Google Tag Manager's Preview mode are Google's own tools for confirming firing and payload in real time.
• Ad blockers, consent banners, and client-side navigation without a new page_view event are the most common causes of dropped events that a source-code-only check misses.
• A complete measurement audit cross-checks three layers: presence in code, confirmed firing, and event consistency with the actual user action.

A marketing dashboard shows zero conversions attributed to a campaign that, according to sales, generated real deals that same week. The first suspect is usually the campaign. The more common cause sits one layer below: the conversion event never reached the measurement tool, or reached it with the wrong parameters.

That kind of gap rarely shows up in a quick look at the page source. A Google Analytics or third-party pixel script can be present in the HTML and still never fire for a real visitor. This guide separates the two questions a measurement audit needs to answer: does the tag exist in the code, and is the right event captured when someone actually acts on the page.

What can be observed, and what each layer proves

A measurement audit combines three sources of evidence, each with a different limit:

1. Page source. Confirms a script matching a known tool's signature (Google Analytics via gtag, Google Tag Manager, Meta Pixel, TikTok Pixel, CRM tracking such as HubSpot, or the LinkedIn Insight Tag) is present in the initial HTML response. This check is fast and needs no account access, but it doesn't prove execution.
2. Real-time browser behavior. GA4 DebugView shows, event by event, what a GA4 property received from a session flagged as debug. Google Tag Manager's Preview mode shows which tags fired, which triggers were evaluated, and why a tag didn't fire when expected. Used together, they answer "does the tag exist" and "did the data arrive" in the same test session.
3. Event consistency with the actual user action. Confirms the event name, parameters, and value sent actually describe what the person did — for example, that a form-conversion event only fires after confirmed submission, not on the mere load of a thank-you page.

None of the three layers replaces the others. A tag present in the code without a firing check is an assumption, not a measurement.

Method: from presence to a verified event

1. Inventory the tools installed per page

List every measurement tool detectable in the source of key pages (landing pages, checkout, lead forms). An evidence-first site audit treats this as the starting point for prioritization: without knowing what's installed, there's no way to decide what to verify first.

2. Turn on debug mode and reproduce the real action

Open GTM Preview mode and GA4 DebugView side by side. Perform exactly the action that should generate the business event: submit the form, complete checkout, click the conversion button. Don't simulate with a random click — the goal is to reproduce the visitor's actual path.

3. Compare what fired against what should have fired

In Preview mode, every tag shows whether it fired and which trigger evaluated true or false. In DebugView, every event shows its parameters. An event that fires without its value parameter, or that fires on the wrong page, is just as much a problem as an event that never fires.

4. Test the scenarios that most often hide silent failures

• Ad blockers and restrictive browsers. Third-party pixels (Meta, TikTok, LinkedIn) are the most common targets of extension-based and cross-site tracking blocks. Also test in a window without extensions.
• Consent triggers. If a tag depends on an accepted consent category, test the flow both declining and accepting consent to confirm both behaviors.
• Client-side navigation in single-page applications. A route change without a full reload doesn't generate a new page_view by default. Confirm whether the application fires that event manually on every relevant route change.

False positives and limitations

• Presence in code is not firing. A script can sit on a page real users never visit, or be gated behind a trigger condition that's rarely satisfied.
• Confirmed firing in a test session is not guaranteed firing in production. DebugView and Preview mode use a session flagged as debug; neither has visibility into the real-world failure rate for visitors who aren't being observed.
• Multiple conversion tools tracking the same goal (for example, a Google Ads conversion tag and a GA4 event for the same form) can look like safe redundancy when each actually has its own firing condition and can fail independently.

Action plan

1. Inventory the measurement tools present on the pages with the highest commercial value. Suggested owner: Marketing + Engineering.
2. Verify firing for every critical event with DebugView and GTM Preview mode, reproducing the real user action.
3. Document the owner of each tag and the date of its last verification, so a future page change doesn't silently break measurement.
4. Re-verify after any page redesign, CMS migration, or consent-policy change — the three most common causes of silent measurement breakage.

This same gap — something present but unconfirmed — is why turning technical problems into financial impact requires evidence of actual behavior, not just a technical inventory. Remountly identifies which measurement tools are present in a public page's source code and flags the absence of any of them as a point worth investigating; the event-by-event firing check described here is a complementary manual step that no public URL audit replaces on its own.

Direct answers

Frequently asked questions

If Remountly finds the GA4 script in the HTML, does that already guarantee measurement is correct?

No. Remountly detects known patterns (gtag, googletagmanager.com/gtm.js, the Meta Pixel, TikTok Pixel, CRM tracking, and the LinkedIn Insight Tag) in the initial HTML response. That confirms the script loaded in the source, not that the correct event fired for a real visitor. Confirming firing requires DebugView or GTM Preview mode in an actual browser session.

Why can an event not show up in GA4 even with the tag installed?

The most common causes are: the trigger depends on a consent condition the visitor never accepted, a browser ad blocker prevented the network call, the page is a single-page application and the route changed without firing a new page_view, or the Tag Manager trigger is configured against a condition that doesn't match the real page element.

What should you do when several tagging tools are installed on the same page?

Document each tool with its stated purpose, the event it should capture, and evidence that the event reaches the destination platform. Tools without a clear owner or a recent verification tend to accumulate silently as pages get redesigned.