Why GA4 Events Look Clean But Can Still Be Wrong
Explaining the 'Green Checkmark Trap' in GTM/GA4. Real stories of duplicate fires, cross-domain breakage, and session logic failures.
The Green Checkmark Trap
I define a conversion event in GTM. I go to Preview Mode. I click the button.
"Tags Fired." The beautiful green checkmark appears in GTM.
I go to GA4 user debug view. The event appears: generate_lead.
I mark it as a Key Event (Conversion).
I assume everything is perfect. I launch the campaign.
Two weeks later, the client calls. "Facebook says we have 100 leads. GA4 says we have 12. And our backend says we have 45. What is happening?"
This is the classic "Green Checkmark Trap." Just because an event fires techically doesn't mean it's counting logically.
Hidden Problem 1: The Double Fire
I once audited a setup where the purchase event was seemingly fine. But when we exported the raw event data to Google Sheets to audit the Transaction IDs, we noticed duplicates.
The Issue: Users were reloading the "Thank You" page. Every refresh re-triggered the GTM tag. GA4 logic (or properly configured GTM) should deduplicate this, but the developer hadn't implemented a unique transaction flag layer.
The Insight: GA4 reports aggregate data. You won't see "Order #1234 fired twice" in the standard report. You only see "2 Purchases." exporting to Sheets and counting duplicates by Transaction ID is the only way to catch this.
Hidden Problem 2: Cross-Domain Chaos
A client had a main site (example.com) and a booking site (book.example.com).
The event begin_checkout fired on the main site. The purchase fired on the booking site.
In GA4, we saw lots of checkouts and lots of purchases. But the Session Conversion Rate was near zero.
The Issue: The cross-domain tracking wasn't configured correctly. When the user moved to the booking subdomain, GA4 treated them as a new user.
So User A (Session 1) started checkout. User B (Session 1) finished purchase. No attribution. The events looked "clean" in isolation, but the user journey was broken.
Hidden Problem 3: The "Session Start" Phantom
In GA4, every session must start with a session_start event. If you have a single-page application (SPA), sometimes a user navigates, stays idle, and then clicks something 40 minutes later.
GA4 starts a new session. But if your event configuration doesn't account for this "mid-stream" re-engagement correctly, you end up with "Direct" traffic spikes because the referral data is lost in the second session.
I spent weeks debugging a "high Direct traffic" issue only to realize it was just aggressive session timeouts on a video platform.
How to Audit This (Without Losing Your Mind)
Stop trusting the GA4 interface for debugging.
- Use the DebugView heavily, but test edge cases (reload the page, switch tabs, wait 30 minutes).
- BigQuery / Sheets Export: This is non-negotiable. Pull the raw event rows.
- Check Timestamp Deltas: If two key events happen within 5 milliseconds of each other, it's a bot or a bug. Humans don't click that fast.
An event is a signal. Your job is to make sure it's a signal, not just noise.
Trust, but verify.
Your green checkmarks might be lying to you. I specialize in deep-dive GTM and GA4 audits to find the broken logic hiding behind successful tag fires.
Audit My Tracking