Home / Guides

Testing tracking without polluting production analytics

Test purchases end up in real reports. How to stop the hits at the browser, in one tab only, and still see everything that would have been sent.

Published 10 August 2026

Verifying a purchase tag means completing a purchase. Do that a dozen times before launch and the reports carry a dozen orders that never happened, at real revenue, in a month somebody will later analyse.

The usual answers, and where each one leaks

• An internal traffic filter on your IP. Works until you test from home, from a phone, from a CI runner, or from a client's office. It is also applied at processing time, so anything that slipped through before you set it up is already in the data permanently.
• A separate staging property. Fine when the bug is in staging. Useless when the thing you have to reproduce only happens on the live checkout.
• Google's opt-out add-on. Stops Google Analytics and nothing else. Your test purchase still reaches Meta, TikTok and the affiliate network — which is where the money reporting hurts most.
• Rejecting consent. Changes the behaviour you are trying to observe. You wanted to know what the tags send when consent is granted.

Stopping the request instead

The alternative is to let every tag fire exactly as it normally would and stop the request in the browser, before it leaves. Nothing arrives, so there is nothing to filter afterwards and nothing to explain to whoever reads the report next quarter.

Three properties make this usable rather than a blunt instrument:

• Per vendor. Block Meta and the affiliate pixel while leaving GA4 alone, because GA4 is the one you are actually testing.
• One tab. The rules are bound to the tab you are debugging, so the rest of your browsing behaves normally — including the other tab where you have the client's live dashboard open.
• Nothing persists. They are session rules: they exist for as long as the browser session does and then they are gone. There is no state to forget about and no way to leave a colleague's machine quietly dropping conversions next week.

You still see what would have been sent

A blocker that hides the request is useless for debugging — the request is the thing you came to read. A blocked hit is still captured and still decoded, so you can check the value, the currency, the item list and the event ID of a purchase that never reached anyone's servers.

This is the part that makes testing on production reasonable. You get the full payload and the platform gets nothing.

The opposite tool: GA4 DebugView mode

Sometimes you want the hit to arrive, just somewhere visible. Adding _dbg=1 to /g/collect makes GA4 treat the traffic as debug traffic and show it in DebugView, without touching the site's own configuration.

Be clear about the trade: this still sends the hit. Debug traffic is real traffic to GA4. Blocking and DebugView mode are opposites, and using both at once means the blocked hit never arrives to be debugged. Pick the one that matches the question you are asking.

A routine for testing on production

1. Decide what you are testing. Everything else gets blocked.
2. Block the rest before you start the funnel, not after the purchase.
3. Walk the funnel and read the blocked hits as you go — they carry the same payload they would have sent.
4. When you need the hit to actually arrive, unblock that one vendor and repeat only the final step.
5. Check the platform's own console afterwards for the one you let through.

What blocking does not fix

Two limits worth stating. If the site also sends the event server-side — a Conversions API call, a server-side GTM container relaying onward — blocking the browser request stops half of it, and the server half arrives regardless. And a blocked hit tells you what the browser intended to send, not whether the platform would have accepted it; a malformed payload looks identical either way until something actually receives it.

Related guides

• A GTM click trigger the next deploy will not break
• Google Tag Gateway: checking that it actually works
• When GA4 says the traffic came from somewhere else