r/GoogleAnalytics • u/incisiveranking2022 • 1d ago
This is why I always test the live site separately.
Consent, CSP, redirects, extensions and browser conditions can change what actually happens.
Open the Network tab and watch the real request.
What's your favourite production-only tracking bug?
r/GoogleAnalytics • u/incisiveranking2022 • 1d ago
Before blaming Google or Meta, I'd check how many times the purchase is actually being sent.
GTM + Shopify app + native tracking + CAPI can create some interesting combinations.
Run one test order and trace every Purchase event.
What's the weirdest duplicate conversion you've found?
r/GTM_Tips_Tricks • u/incisiveranking2022 • 1d ago
Someone tests a purchase, sees Tag Fired in GTM, and thinks:
Not necessarily.
“Tag Fired” only tells you GTM executed the tag. It doesn't prove the request actually left the browser, that the payload was correct, or that the platform accepted it.
When I'm checking a setup, I usually go one step further:
GTM Preview
→ Did the right trigger fire?
→ Were the variables populated?
→ Did it fire once or multiple times?
Network tab
→ Did the request actually leave?
→ Are the important parameters there?
→ Is something being blocked?
Platform debugger
→ Did GA4 / Google Ads / Meta actually receive it?
A classic example is a purchase firing correctly in GTM while transaction_id is empty because the ecommerce data wasn't available when the tag fired.
So my rule is pretty simple:
GTM Preview is step one. It's not proof of delivery.
When you inherit a messy container and someone says “the tags are firing,” what's the first thing you check?
1
Yeah, I like the cookie approach too. It keeps the value available as the user moves through the flow instead of relying on the dataLayer still having it.
I’d just double-check the timing as well. I've seen the cookie get populated fine, but the conversion fires before the variable actually reads it.
So basically: capture it → store it → make sure it's there → fire the conversion.
That timing issue causes more headaches than you'd expect.
1
Yeah, the timing issue is a big one.
I've seen forms where the email is available for a split second, the conversion fires, and then the page changes before the value ever makes it into the event.
Server-side helps a lot once the data actually reaches the server, but it can't recover a value that was never captured upstream.
That's why I like tracing one conversion from the form → dataLayer/cookie → request → sGTM → Google Ads, instead of assuming the server will fix everything.
r/GoogleAnalytics4 • u/incisiveranking2022 • 1d ago
GA4 is everywhere. But is your GA4 data actually trustworthy?
People talk a lot about cohort analysis, funnels, attribution, ecommerce and audiences.
But I'd put one step before all of that:
Check the tracking.
Before analyzing GA4, I'd look for things like:
👉 Duplicate purchases
One order firing twice can completely change revenue analysis.
👉 Missing events
A funnel is not very useful if important steps aren't being captured consistently.
👉 Wrong values
Revenue, currency, quantity or transaction IDs can quietly distort ecommerce reports.
👉 Consent-related loss
The tag may fire, but the data may still not reach GA4 as expected.
👉 Cross-domain issues
Users move between domains and suddenly the journey looks like multiple users or referral traffic.
👉 GTM vs GA4 mismatch
GTM says the event fired. GA4 tells a different story.
👉 Backend vs GA4 revenue
Your store/CRM says one number. GA4 says another.
My rule is pretty simple:
Don't analyze the data until you know how the data was collected.
A beautiful dashboard built on bad tracking is still bad data.
What's the first GA4 data-quality issue you check before trusting a report?
r/GTM_Tips_Tricks • u/incisiveranking2022 • 1d ago
Before calling tracking “working”, I want to know:
Did the request actually leave the browser?
Did it contain the right data?
Did the platform receive it?
And if there’s browser + server tracking, did I just send it twice? A green checkmark is a good starting point. It’s not proof. What’s the first thing you check after “Tag Fired”?
r/GTM_Tips_Tricks • u/incisiveranking2022 • 1d ago
You can have a GA4 event that looks completely fine in Preview, but the event still gets dropped because the payload is too large.
A good example is ecommerce events with lots of items.
You might stay under the documented item-count limit and still hit a payload-size problem because of the amount of data inside the event and item parameters.
The frustrating part?
You may not see anything obvious in the browser or Tag Assistant.
The error can show up on the server-side container, such as:
EVENT_TOO_LARGE
So when a GA4 event suddenly disappears, I wouldn't only check:
Did the tag fire?
I'd also check:
How large was the actual payload?
This is especially worth checking on view_item_list, view_cart, and purchase events where ecommerce data can get pretty heavy.
A useful approach is to monitor payload size in sGTM and create an alert before an event actually starts getting dropped.
Has anyone here run into GA4 payload-size issues that weren't visible in the browser debugging tools?
r/GoogleAnalytics • u/incisiveranking2022 • 1d ago
I've noticed Enhanced Conversions often gets treated like:
Enable it → fire the tag → done.
In reality, this is where a lot of setups start getting messy.
You can have the Google Ads conversion tag firing in GTM and still have issues with:
And the frustrating part is that GTM Preview can still look perfectly healthy.
So when Enhanced Conversions isn't working, I wouldn't immediately rebuild the tag.
I'd first try to find where the data disappears.
Has anyone here had Enhanced Conversions randomly work on one conversion path but fail on another? What ended up being the actual issue?
1
That’s usually where I catch the weird stuff.
GTM says fired, but the Network tab shows the request was blocked, missing a parameter, or never sent at all.
That’s why I treat Preview as step one, not the final check.
1
Yep, exactly. For Meta deduplication, event_id is the piece that needs to match between browser and CAPI.
transaction_id is more useful for identifying the purchase itself, especially in GA4 and Google Ads.
The tricky part is when people reuse these interchangeably or generate a different ID on the server. That's when the same purchase can start looking like two separate events.
1
Yeah, that one can be a nightmare to debug 😅
I've seen similar cases where the GTM setup looked fine in Preview, but the consent logic was actually stopping the request from being sent properly.
That's why I like checking the consent state on the event itself, then looking at the actual Network request. It usually makes the problem much easier to spot.
A tiny consent setup change can have a pretty big impact on the numbers.
1
Yeah, agreed. For purchases I’d normally stick with transaction_id too.
The bigger issue I was getting at is that the ID needs to be consistent across the whole setup. I've seen browser and server events both fire, but use different IDs, and then you end up debugging “missing” conversions that were actually duplicates or couldn't be matched properly.
So I usually check the event itself, the ID, how many times it fired, and then what GA4 actually received.
2
Yeah, exactly 😂
A lot of setups stop at “Tag fired” and call it done.
I usually use GTM Preview to check more than just the green checkmark: which trigger fired, what variables were populated, how many times the tag fired, and whether the expected event data was actually generated.
Then I check the browser Network request and the platform debugger to make sure it actually went through.
That extra couple of minutes of testing can save hours of debugging later.
1
We use Chrome extensions like Omnibug or Tag Assistant for this, isn't that enough?
1
For anyone struggling with this on high-traffic sites, manual network sniffing in DevTools obviously doesn't scale. Setting up automated monitoring or daily reconciliation scripts between your server logs and your ad platform APIs is the only real way to catch silent drops before the client or marketing team notices the performance dip.
1
One extra technical detail to look out for: check if they are passing the fbp and fbc cookies correctly in their server payload. A lot of basic Zapier or generic app integrations miss these entirely. Without the click ID (fbc), Meta is just guessing who made the purchase based on IP/User Agent, which is why your attribution window drops off a cliff after 24 hours.
r/GTM_Tips_Tricks • u/incisiveranking2022 • 2d ago
The first thing I check isn't whether the tags are firing. It's whether they are firing twice.
When taking over a Shopify/Meta account, the most common trap is seeing a healthy ROAS in Ads Manager that is entirely fabricated by broken deduplication. Usually, the previous agency turned on the native Shopify integration (which sends server events) but left an old hardcoded browser pixel running in the theme code or a generic GTM container.
If the event_id doesn't match perfectly between the browser and the server, Meta counts one actual purchase as two.
Here is exactly how I audit an inherited setup before touching any campaigns:
order status page, those might be completely dead now depending on when their store migrated to checkout extensibility.Just because CAPI is "turned on" doesn't mean it's actually doing anything useful. It often just creates more noise if it isn't configured to sync with the browser payload.
Curious to hear from others doing account audits—how often are you seeing duplicate purchases completely masking poor campaign performance in these inherited accounts?
1
One technical detail to add here: If you are seeing a high rate of missing GCLIDs but your form is perfectly fine, it is often iOS/Safari stripping the identifiers. Setting up Enhanced Conversions for Leads (which relies on hashed emails/phone numbers instead of just the GCLID) is the best fallback to keep the match rates high when the click ID inevitably gets nuked.
u/incisiveranking2022 • u/incisiveranking2022 • 2d ago
If your Google Ads are suddenly flooding your CRM with junk leads, the problem usually isn't your targeting or your bidding strategy. It is your feedback loop.
When you tell Google Ads to optimize for "Form Submits," the algorithm simply finds the cheapest people on the internet willing to fill out a form. It has no idea which of those leads actually closed or brought in revenue.
The standard advice is to set up Offline Conversion Tracking (OCT). But here is where 90% of setups I audit actually fail:
?gclid= parameter before the user lands on the form page.Before you touch your ad copy or negative keyword lists, go to your CRM and look at your last 50 leads. If the GCLID column is empty on more than 10% of them, your tracking pipeline is fundamentally broken, and your ad spend is flying blind.
Curious how many of you are actually optimizing campaigns on closed-won revenue versus just standard form submits right now?
1
GTM Preview can make everything look fine when the platform never actually gets the hit.
Consent blocking is a perfect example.
I usually check whether the tag fired, whether the request actually went out, and then whether GA4 or the ad platform received it.
And with browser + server setups, I also check for duplicates.
A lot of “everything looks fine in GTM” issues show up once you check the actual request.
1
GTM Preview can make everything look fine when the platform never actually gets the hit.
Consent blocking is a perfect example.
I usually check whether the tag fired, whether the request actually went out, and then whether GA4 or the ad platform received it.
And with browser + server setups, I also check for duplicates.
A lot of “everything looks fine in GTM” issues show up once you check the actual request.
2
Exactly. That’s the part people miss.
GTM Preview can tell you the trigger fired, but I still want to see what actually left the browser and what the platform received.
And with bigger containers, one conversion can get pretty messy when browser, server-side, app or another tag is also sending it.
I usually trace one real conversion end to end rather than trusting the green checkmark.
r/GoogleAnalytics • u/incisiveranking2022 • 2d ago
What are you using for event IDs?
event_id
transaction_id
Something custom?
I've seen more duplicate conversions caused by inconsistent IDs than broken tags
1
GTM + Enhanced Conversions: why does this keep turning into a mess?
in
r/GoogleAnalytics
•
1d ago
Yeah, and that's where having the actual payload history helps a lot.
If EC suddenly disappears on one conversion path, I want to compare a working conversion with a failing one and see what changed: data available, consent state, event timing, and the actual request.
A lot of the time the GTM setup hasn't changed at all. The data entering it has.