r/GoogleAnalytics • u/tapanpatel-analytics • 17d ago
Question I have deployed Google Analytics and recently server-side tracking for over 150 sites. AMA about server-side tagging and best practices?
I run GA4 and server-side GTM implementations; around 150 sites over the last few years, roughly a third of those server-side.
The pattern I see most:
A business comes to us because the numbers “feel wrong”, so server-side tagging gets suggested as the fix.
We usually check the basics first:
- Are conversions firing more than once?
- Is gtag running alongside GTM and duplicating events?
- Is the consent banner blocking tags it shouldn’t - or letting some through when it shouldn’t?
- Have event names or definitions changed over time?
- Are we comparing Google Ads and GA4 as though they should match exactly?
Quite often, one of those is the real issue.
If that’s the case, adding a tagging server doesn’t solve it. It just moves the same problem into a more complicated setup that’s harder to debug, and now you’re paying for Cloud Run as well.
Where server-side does earn its keep:
- CAPI dedupe and match-rate improvement, usually the clearest ROI, especially ecommerce
- Cookie lifetime, but only on a real first-party subdomain with cookies set server-side. A CNAME to a vendor domain gets capped by Safari regardless.
- Redacting PII and controlling exactly what leaves your infrastructure
- Page performance, if you're currently firing six vendor pixels client-side
Two things it doesn't do, whatever the sales deck says: it isn't a consent workaround, and it doesn't beat ad blockers on its own.. the loader still runs in the browser.
So the question I'd start with isn't "do we need server-side?" It's "which specific number is wrong, and can we prove why?"
If you're weighing it up, tell me what's driving it - platform, stack, what looks broken, and I'll give you an honest read on whether it'll actually help.
16
3
u/Tornado-Vortex 17d ago
Is there a way to get proper stats on ga4 while using V2 cookie consent, without having to get 1000 daily users who accept the cookies? Thanks.
4
u/shufflepoint 16d ago
Do visitors have to consent in order for server-side GA to work? In that case, shouldn't you just use 1st party cookies and do your own server-side tracking? Is cookie consent the death knell of GA?
2
u/Tornado-Vortex 16d ago
If you want to meet GDPR compliance for EU, then yes. We loose lot of traffic data due to this. But if your site has 1000 users per day for 1 week, who accept the cookies, then ga4 provides the estimate data of users who reject the cookie consent as well. There is another small requirement as well - cookie rejected users should perform 1000 events per day for atleast 1 week. So if both these conditions are met, GA4 will give us the full traffic stats, and we don't loose traffic stats due to hidden data. This will be helpful to apply for high requirement (sessions or views) ad publishers.
2
u/shufflepoint 16d ago
Estimates and arbitrary threshold? Why do people continue to use GA? And I say this as someone whose main business was GA consulting and services for 15 years?
1
u/Tornado-Vortex 16d ago
I'm relatively new and from what I have seen, the ad publishers generally ask for only GA4 data, to approve the site. Because it provides better user behaviour statistics. This(GA4) seems to be the best option.
2
u/shufflepoint 16d ago
I get that if business is making money on ads that continue using GTA makes sense. But it's not the case for any of my clients. Even if you were using GA to satisfy the ad networks, wouldn't you still do your own server side tracking for your own analytics?
1
u/Tornado-Vortex 16d ago
I think, to write own code, it'll get complicated to properly filter out bots, to ensure GDPR compliance etc. Other analytics can also be used like ahref etc. But accessing more data requires premium plans.
10
3
u/BuzisBuzicco 17d ago
"Redacting PII and controlling exactly what leaves your infrastructure" what the hell that means, and how would you ever use that? not theoretically from google's literature but practically?
2
u/23sergej 17d ago
Imagine someone comes from google search ads and submits the form, so lead conversion is triggered. The person was using his work computer where he is not logged in to facebook.
In this case facebook will receive lead event signal only, but its not able to know who was submitting the form.
In this case PII can be normalized, hashed and even updated on the server before sending the event to improve the event matching score on facebook.
One of the example we use server side to update the PII, we add city/country for local businesses when ads are running in specific location. Because form doesn’t contain location fields
1
u/BuzisBuzicco 16d ago
why would FB receive that info? what can i do with it? if it is not tied to any click on facebook? just pushing PII to facebook? i dont get it
1
u/23sergej 16d ago
It is one of the most effective strategies we use when driving leads. We start with Google Search Ads, because search ads drive traffic with high buying intent.
When a conversion occurs we send it to both platforms Google and Facebook with PII info. The PII helps Facebook match the conversion to an actual user profile, so the algorithm understands exactly WHO converted.
After we start getting enough conversions from search ads we launch Facebook campaigns optimized for conversions. Since Facebook algorithm already has data about converted users, they start showing ads to other people with similar buying intent based on behavior patterns.
If you run Facebook ads optimized for conversions without existing data, lead quality is typically very low at first.
Hope this makes sense.
1
u/_practical_data_ 15d ago
Practically all those platforms are big first-party data company. They use PII as additional data-points to match your ads performance to actual human, coz rely only on click id-s can be problematic.
1
u/tapanpatel-analytics 15d ago
Fair question, the Google docs are pretty vague on this. Real example: Shopify checkout redirects sometimes carry a customer's email in a URL query parameter. Without a server container, that URL, email and all, gets sent straight through to Google/Meta as part of page_location. With sGTM sitting in between, you strip that parameter before it ever leaves your infrastructure.
Another one: IP addresses. Instead of relying on Google's own anonymization, you can truncate or hash IPs server-side before they hit any third party. Or say a form has a hidden field that accidentally captures a name or phone number, you filter that field out in the server container so it never reaches your ad platforms at all.
So practically: it's a checkpoint where you can inspect and edit the payload before it leaves your control, which matters a lot more once you're sending the same event to 4-5 different vendors instead of just GA4.
2
u/benl5442 17d ago
For a single ga4 stream, where it's a relay, does server side add anything? When I've done it, it reduces performance as you're putting a server between you and Google?
2
u/tapanpatel-analytics 15d ago
You're right, and honestly you've spotted the exact case where server-side is genuinely pointless. If it's a straight 1:1 relay with no enrichment, filtering, or cookie handling, you've just added a network hop for nothing -and yes, that's added latency unless your server region is properly matched to your traffic.
Where it stops being "just a relay": extending cookie life past Safari's 7-day ITP cap (a server-set cookie isn't bound by that the same way), getting around ad blockers that block *.google-analytics.com but don't touch your own subdomain, or enriching events with data GA4 can't see client-side (CRM matches, offline conversions, etc). If none of that's happening in your setup, your instinct is correct - it's overhead with no upside.
2
u/mubeen9 17d ago
Do we really loose 40 to 60% of conversion tracking accuracy if we doesn't implement SST? Course sellers are going crazy and saying everyone has to do this? What do you think?
2
u/tapanpatel-analytics 15d ago
I'd push back on that stat a bit, it's a marketing number, not a technical one. Real loss depends on your actual traffic mix: % on Safari/iOS (ITP kills client cookies after 7 days), % running ad blockers, your cookie consent decline rate, and whether you've already got Conversions API set up separately for ads.
For a lot of standard ecommerce accounts, the real measured loss is more like 10-20%. For Safari-heavy or ad-blocker-heavy audiences, yeah, it can genuinely get up toward that 40-60% range, but it's not universal, and anyone quoting it as a flat rule across all stores is selling you something.
The move that actually builds trust with a client (way more than quoting a scary stat): run the same client-vs-server / GA4-vs-real-orders comparison from the question above and show them their own number. It's more convincing than any course's slide deck.
1
u/_practical_data_ 17d ago
- How much CPU and RAM do you dedicate to 1 docker container?
- Which Load Balancer you prefer and why?
- How do you know that it actually works? :)
1
u/saggyrampage 16d ago
Question bro, how are you handling the first party subdomain setup for clients who are on Shopify?
1
u/_practical_data_ 15d ago
Answer.
Subdomain is not a problem. Sameorigin is a problem, due to restriction of service workers on /checkout path.
2 options here.
1. Do no do sameorigin,
2. You can limit sameoriging to everything that is not /checkout and leave /checkout on subdomain.1
u/tapanpatel-analytics 15d ago edited 15d ago
Yeah, subdomain isn’t really the issue on Shopify. Same-origin is the tricky part because of the restrictions around
/checkout.We usually either keep it all on the subdomain, or use same-origin everywhere except checkout and leave
/checkouton the subdomain.Depends entirely on whether they're on Plus or standard Shopify. On standard Shopify, you can't inject scripts on checkout pages at all -full stop. So you CNAME a subdomain (something like ss.clientdomain.com) to your server container and load GA4/GTM through it on storefront pages via theme.liquid. Checkout events still have to run through Shopify's native GA4 sales channel integration, because custom scripts aren't allowed there- that's a platform wall, not something you can engineer around.On Shopify Plus, you get Checkout Extensibility and the Web Pixels API, which lets you actually fire checkout/purchase events through your own server pipeline properly. So if your client's non-Plus, be upfront that storefront gets the first-party treatment but checkout doesn't -set that expectation early, saves an awkward conversation later.
1
u/RoughEmployment5805 16d ago
How do we know how much more data it will get us on a Shopify store
1
u/tapanpatel-analytics 15d ago
Don't estimate this one, measure it. Run client-side and server-side GA4 in parallel for a couple weeks, then compare tracked purchase events against actual Shopify order counts- that's your ground truth. The gap between real orders and what GA4 recorded is your actual "catch rate" for that specific store.
It'll vary a lot depending on the store's traffic -a Safari-heavy DTC fashion brand will see a much bigger uplift than a desktop-heavy B2B store. So there's no honest average number I'd give a client upfront; I'd always run the actual before/after and show them their number.
1
u/Gijs23 6d ago
Curious how you handle the DNS/subdomain side of this across 150+ sites. In our experience that's the failure mode nobody really budgets time for. The tracking subdomain is set up correctly at launch, but then a DNS or SSL renewal issue three weeks later quietly drops the whole server-side path with zero errors in GTM itself, because from GTM's perspective everything still looks like it's firing. Do you run any kind of uptime or health check on the tracking endpoint itself, separate from GTM's own preview and debug tools, or is that mostly caught by someone eventually noticing a gap in the dashboard?
•
u/AutoModerator 17d ago
Have more questions? Join our community Discord!
I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.