Practical QA guides updated

Test your analytics before launch

A loaded analytics snippet can still record nothing. What breaks before launch — and how to check a beacon actually fires, not just that the tag is there.

An analytics snippet in your <head> is not analytics. It’s a promise that analytics might work — and on launch day, for far more teams than expect it, the promise breaks silently. The page loads, a visitor reads it, they leave, and no record of any of it ever left the page. You find out weeks later, staring at a dashboard that says zero, that the single largest traffic spike your product will ever get went completely unmeasured.

The way to test your analytics before launch is to stop checking whether the snippet is present and start checking whether a beacon actually fires: load the page, watch the network, and confirm an analytics event leaves it — then confirm it isn’t misconfigured in one of the four ways that quietly corrupt the numbers. In a June 2026 audit of 49 fresh web launches, no-analytics-at-all was the single most common finding: 38 of the 49 sites sent no analytics events whatsoever. This piece is what breaks, ranked, and how to verify each one.

Why a view-source check and a quick glance miss this

The free “Google Analytics checker” tools miss it because they read your page’s HTML and look for the snippet. That’s a view-source check, and it answers the wrong question. The snippet being present tells you the code shipped; it tells you nothing about whether a request left the browser. The two come apart constantly — most commonly when a tag container loads (so view-source looks perfect) but no tag inside it ever fires. A view-source check passes that site with flying colors. A network log catches it in one reload.

The manual tools miss it from the other direction. Opening GA’s Realtime view, installing Tag Assistant, or watching the DevTools Network tab all work — but they require you to have set everything up correctly first, they’re Google-Analytics shaped, and they give you no pass/fail. You have to know what a healthy request looks like, remember to check, and check in the right browser state. On a page you’ve seen a thousand times, the day before launch, you won’t. The good news is the same as with signup flows and mobile rendering: the surface is small and bounded. A handful of things break with analytics. You can know all of them.

The things that break with analytics at launch

In rough order of how often they show up on real launches:

  1. No analytics event fires at all. The most common finding by a wide margin: the page loads, the browser captures every outgoing request, and nothing resembling an analytics event is among them. Why it happens: the snippet was never actually added, was lost in a redesign or a framework migration, or sits in a code path that doesn’t run on the deployed build. Verify it: open DevTools → Network, reload, and look for the event request to your analytics host — for GA4, a request to /g/collect; for others, an /e, /capture, or /track endpoint. If the only analytics request is the script loading and no event follows, you’re blind.

  2. A tag container loads but fires no events. The subtle, nasty version: your GTM (or gtag) container loads — so view-source and the “is the snippet there” checkers all look fine — but no tag inside it ever fires an event. Why it happens: the container is installed but empty, or its tags have triggers that never match. Verify it: this one is invisible to the eyeball test by design. The only way to catch it is to watch the network and confirm that an actual event — not just the container library — leaves the page. Three of our 49 audited sites had exactly this.

  3. A dead Universal Analytics property still firing. The page is dutifully sending events to a UA-... property that stopped processing data in July 2023. Why it happens: an old snippet that survived the GA4 migration, or a copy-paste from a years-old template. Verify it: check the account ID your beacons carry. If it starts with UA-, every event is going into a void — you have the feeling of analytics and none of the data. Migrate to a GA4 (G-...) property and remove the UA snippet.

  4. The same page view fires more than once. Every visit gets counted twice (or more). Why it happens: the tag is hardcoded in the page and fired again through GTM, or a single-page-app router re-fires the page-view on a route change. Verify it: count the page-view events for a single load. If GA4 sends two page_view events for one visit, your traffic reads double its real size, your conversion rate reads half of reality, and any ad spend optimizes against both wrong numbers. Double-counting is worse than no data, because it looks plausible.

  5. Data split across two accounts. Two GA4 (or two Meta) account IDs are both receiving events. Why it happens: an old property and a new one both wired up, a staging ID that shipped to production, or two teams that each added tracking. Verify it: if beacons for the same vendor carry more than one account ID, neither property sees the full picture — your numbers are split and every report is partial.

How Prufa checks analytics

Prufa runs the same pattern here it runs everywhere: an LLM does the navigation, plain code does the verification. During the audit it opens your page in a real browser and captures every outgoing network request, then normalizes those requests against a table of vendor signatures and asserts deterministic facts about what fired. The findings above map one-to-one onto checks the audit runs — a dead UA property, a double-fire, conflicting accounts, and a container that loads with no events are all reported as verified findings, because each is a fact plain code can prove from the captured traffic (a dead property still firing and a double-fire are criticals; conflicting accounts and an empty container are warnings).

The one case Prufa deliberately does not call verified is total absence. When the capture provably worked and no recognized beacon fired, the audit flags it — but as an advisory, not a red verdict. The reason is honesty about what the tool can and can’t know: the signature table is incomplete by design (new vendors, region-specific endpoints, and first-party collectors exist that it doesn’t recognize — GitHub, for instance, collects to its own collector.github.com, which no generic table knows, yet GitHub is very much tracking). Claiming verified that “you have no analytics” would be a false positive waiting to happen — so the audit says “no recognized analytics beacons, worth a look,” and leaves the verdict to you. The static checkers that confidently declare you fine (or broken) from your HTML are the ones crying wolf; the restraint is the point.

What the free 60-second audit does for analytics

The tracking check runs in the free audit on prufa.dev — no card, no signup. Unlike the authenticated flow checks (signup, login, checkout) that need a credential the anonymous tier doesn’t have, reading the beacons a public page fires needs nothing but the URL. So the free audit already loads your page, captures the traffic, and tells you whether analytics is absent, double-firing, split across accounts, or loading a container with no events — alongside the rest of the pre-launch checks. It turns “I’m pretty sure I set up GA” into a specific answer.

Keeping it working after launch is the paid tier’s job: Starter ($29/mo) re-verifies your site daily and on every deploy. That matters because a redeploy is exactly when a tracking tag gets dropped — a refactor moves the snippet, a build strips it, a consent change blocks it — and analytics is the one bug you won’t notice by using your own site, the same silent rot that hits an app after launch.

What the audit doesn’t do (honest limits)

The audit checks that your analytics fires and isn’t misconfigured — not that it’s semantically correct. It won’t tell you your GA4 revenue matches your billing system, that a custom event carries the right parameters, or that your funnel is defined the way you meant: that’s data-layer and analytics-QA work a network log can’t do. The total-absence flag is advisory, not a verdict, for the first-party-collector reason above. And the audit reads what fires on your public pages in one session — consent-gated tracking that only fires after a cookie banner is accepted is a separate concern (which is also why you should check your analytics in a private window, not just your own consent-dismissed browser). If you want the mirror-image problem — your own monitoring polluting the analytics you’re trying to protect — that’s a different piece. For the full pre-launch surface, see the website QA checklist before launch, whose first item is this exact check, ordered first for a reason: 38 of 49 launches we audited failed it. The mechanism — why the LLM navigates but never grades the result — is in how Prufa verifies a flow.

What to do before you launch

In order of impact:

  1. Watch the network, not the source. Open DevTools → Network, reload, and filter for your analytics host. Confirm an event request leaves the page — not just the script or container loading. This one check catches the two most common failures at once.
  2. Do it in a private window too. Your everyday browser has your consent banner long-since dismissed. A clean profile shows you what a first-time visitor’s browser actually sends — which may be everything, or nothing, depending on your consent default.
  3. Confirm you’re on GA4, not a dead UA property. If the account ID your beacons carry starts with UA-, the data is going nowhere. It should be G-....
  4. Trigger one real conversion and watch it land. Sign up, click the CTA, or submit the form, and confirm the event arrives in your tool’s realtime view. Absence here is the difference between “the tag loaded” and “the thing I care about is measured.”
  5. Run the free audit — then keep it checked on every deploy. It reads the beacons for you and flags absence, double-fires, conflicting accounts, and empty containers in one pass, and re-running it on each deploy catches the tag you drop three weeks from now.

Get those right and launch day — the most informative traffic your product will ever get — stops being the day your data quietly goes missing.

Frequently asked questions

How do I check if my analytics is working before launch?

Don't just confirm the snippet is in your HTML — that only proves the code is present, not that it fires. Open DevTools → Network, reload, and filter for your analytics host (GA4 sends to /g/collect); you're looking for the event request, not the script loading. Do it in a private window too, and trigger one real conversion to confirm it lands in your tool's realtime view.

Is a Google Analytics checker tool enough?

No. Most free GA checkers read your page's HTML for the snippet and report present or absent — a view-source check. The snippet can be present and still fire nothing: a tag container loads but no events follow. That bug passes every view-source check and fails only a network-traffic check. To know your analytics works you have to watch what actually leaves the page, not what's written in the markup.

Why does my analytics snippet load but record no data?

The most common cause is a tag container (like GTM) that loads but has no tag or trigger firing an event — so the library is present but nothing is measured. Other causes: a dead Universal Analytics property (UA-...) that stopped processing data in July 2023, a consent banner blocking the tag by default, or the event firing to a different account than the one you're checking. All are invisible in view-source and visible in the network log.

Does the free audit test analytics?

Yes. Prufa's tracking check runs on the free 60-second audit — no card, no signup — because reading the beacons a public page fires needs only the URL. It captures all outgoing network traffic and flags analytics that is absent, double-firing, split across accounts, or loading a container with no events. Misconfigurations (a dead UA property, double-fires) are reported as verified findings; a total absence of recognized beacons is flagged as advisory, not verified.