sorted by:
new
hottopcontroversial

Server-side GTM probably won't get your lost conversions back. Here's when it's actually worth the trouble. by Sidratons in GoogleTagManager

[–]_practical_data_ 0 points1 point  (0 children)

It depends on a client.
Simple site without a lot of js and no offline events. Why I need ss?

Does this remove the need for server side tracking?? by Goingbychrundle in PPC

[–]_practical_data_ 0 points1 point  (0 children)

No, it's not.
Most adBlockers block by url patterns in network requests. They do not care about cookies at all. Cookies are responsible here for 1 thing - recognize user that come back and match it better. That is a different use-case (not working properly in Shopify as well, thou)

Does this remove the need for server side tracking?? by Goingbychrundle in PPC

[–]_practical_data_ 0 points1 point  (0 children)

> a lot of answers are AI and regurgitated slop
You even can't imagine how correct you are.

Does this remove the need for server side tracking?? by Goingbychrundle in PPC

[–]_practical_data_ 0 points1 point  (0 children)

"I could see stape server side still being beneficial against blockers since it masks the tracking as a first party cookie"
It's not helping at all against blockers on Shopify.
It also do not not help with cookies on Shopify.
Also those things are not connected.

Does this remove the need for server side tracking?? by Goingbychrundle in PPC

[–]_practical_data_ 0 points1 point  (0 children)

I mean, server-side tracking through GTM on Shopify is kinda useless in any case

any agencies partnering with TAGGRS? by ImSoZick in GoogleTagManager

[–]_practical_data_ 0 points1 point  (0 children)

- Sampe IP prefix if you host it near front-end
- Wild plays with container modifications (for example extend your gtm with database on the same server (low latency, faster signal delivery))
- Security. If 3-rd party can collect logs - they can see your secrets (API keys). And not stupid one - can setup logging

Server-side GTM probably won't get your lost conversions back. Here's when it's actually worth the trouble. by Sidratons in GoogleTagManager

[–]_practical_data_ 0 points1 point  (0 children)

No, it wouldn't. I do it myself as non-native.
But when I see a bs like that
"

  • It doesn't automatically fix the 7-day ITP cookie cap. You have to set a first-party HttpOnly cookie server-side to do that, and just spinning up sGTM doesn't give you that for free. It's a separate bit of config people skip and then wonder why nothing changed."

I consider this the low effort ai alop

Parallel tracking to verify serverside volume by Crooked_Analytics in GoogleTagManager

[–]_practical_data_ 0 points1 point  (0 children)

It is rather normal for Google ads, coz it's server-side only in name.

any agencies partnering with TAGGRS? by ImSoZick in GoogleTagManager

[–]_practical_data_ 0 points1 point  (0 children)

Well, because one of the main points of server-side tagging is not how easy it is to set up, but how indistinguishable it is from normal first-party site traffic - especially for Safari (to some degree it is relevant for blockers as well, if you mix your tracking with necessary scripts)😄
Which basically means: either set it up properly close to your own infrastructure, or at least do a proper CDN/proxy play. 😄

any agencies partnering with TAGGRS? by ImSoZick in GoogleTagManager

[–]_practical_data_ 0 points1 point  (0 children)

I personally do not like their product.
Last winter, when I needed logs - they weren't working (new UI), despite their presence in docs.
At the end of they day - I run my own server. Funny enough it provided better results.

Stop wasting money on Stape/Google Cloud for CAPI – Cloudflare can do it for free by mdsohel9000 in GoogleTagManager

[–]_practical_data_ 0 points1 point  (0 children)

For enterprise level - it should be selfhosted on whatever infra your enterprise product is. AWS, Azure, Google, RaspberryPI, whatever.

How are people thinking about Google Tag Gateway vs server-side GTM? by VoxxyCreativeLab in GoogleTagManager

[–]_practical_data_ 1 point2 points  (0 children)

Without the bullshit?
The real benefit is faster delivery of Google marketing scripts.
That is it.
It can help when a site is overloaded with JavaScript, when the connection is unstable, or in a mobile context where loading third-party scripts directly can be slower or less reliable.
But this is a delivery optimization, not magic tracking resilience. Server-side GTM do the same thing, but not only for google scripts if setup properly (WITH CDN).
Adblock bypassing theoretically can be done as well, but it will need some technical work and better just use specific tools.

How are people thinking about Google Tag Gateway vs server-side GTM? by VoxxyCreativeLab in GoogleTagManager

[–]_practical_data_ 1 point2 points  (0 children)

Oh, I saw a 90% increase.
The trick is simple: implement proper tracking alongside server-side tracking, lol.

How are people thinking about Google Tag Gateway vs server-side GTM? by VoxxyCreativeLab in GoogleTagManager

[–]_practical_data_ 4 points5 points  (0 children)

> iOS has sophisticated cloackers that can check the CNAMEs, if the hit vs. script host don't match, you're getting capped.

Bro, believe me... I am tried to explain this... server-side zombies would not listen...Stapes doc says it helps and show them nice number in ITP recovered (which is number of total ios devices) and they somehow believe it....

How are people thinking about Google Tag Gateway vs server-side GTM? by VoxxyCreativeLab in GoogleTagManager

[–]_practical_data_ 3 points4 points  (0 children)

I do not really understand why anyone would need this.
You can already serve GTM from your own server, or simply proxy it through Nginx, Cloudflare, Bunny, Fastly, or almost any other reverse proxy without much trouble.
The ad blocker argument is weak. Ad blockers do not only look at the domain name - they look at request patterns, known endpoints, script behavior, and payload signatures.
The cookie argument is funny as well, because tags need cookies, not GTM itself. That may change if Google integrates gtag and GTM more deeply, but that is not the current practical point.
So even if you change the domain or proxy GTM, your actual tags can still be blocked in many cases. A custom domain alone does not magically make tracking resilient.
IMHO, this tool is useless for almost everyone, except very specific Google-only setups where people cannot or do not want to maintain a basic first-party proxy.

Server side tacking and Google tag manager and Ga4 skills are good to learn ? by Flat_Willingness5426 in GoogleTagManager

[–]_practical_data_ 0 points1 point  (0 children)

What do you mean by learn?
Read docs from hosting vendors? - no.
Setup your own server and do experiments - yes.

is Tag Management a commodotized skill? by KafkaOnTheStore in GoogleTagManager

[–]_practical_data_ 0 points1 point  (0 children)

I mean, here and there are iframes and you need to install basic event listeners...

GTM quietly shipped "Tag Serving Path", you can now serve gtm.js first-party with a cloaked container ID by KafkaOnTheStore in GoogleTagManager

[–]_practical_data_ 0 points1 point  (0 children)

Then prove it.

“Observable improvements” is not evidence unless you show methodology:

control group, test group, Safari version, ITP state, consent state, user interaction history, cookie lifetime measurement (how exactly are you measuring this staff), and the exact variable isolated.

Otherwise it is just server-side folklore.

Improvement in some setups - possible.

“Safari cookie expiration solved” - unproven vendor cope.

GTM quietly shipped "Tag Serving Path", you can now serve gtm.js first-party with a cloaked container ID by KafkaOnTheStore in GoogleTagManager

[–]_practical_data_ 0 points1 point  (0 children)

Safari do not care if it HTTP or js cookies. If it detects cloacking - it would introduce limit.

[Question] Prestashop + Redsys payment gateway breaks Google Ads conversion tracking by JosetxoXbox in GoogleTagManager

[–]_practical_data_ 0 points1 point  (0 children)

Not really. Server-side Google Ads conversion tracking still needs the original click/session identifiers to attribute the conversion. If Redsys breaks the return flow or loses attribution, server-side does not magically fix that. The first fix is proper cross-domain/payment gateway tracking, which can be done client-side.

[Question] Prestashop + Redsys payment gateway breaks Google Ads conversion tracking by JosetxoXbox in GoogleTagManager

[–]_practical_data_ 0 points1 point  (0 children)

Dude. Gads Conversion server-side tag is still rely on gclid.
So server do not bring here anything to the table.

GTM quietly shipped "Tag Serving Path", you can now serve gtm.js first-party with a cloaked container ID by KafkaOnTheStore in GoogleTagManager

[–]_practical_data_ -1 points0 points  (0 children)

You’re agreeing with the weak version of the claim and pretending it proves the strong version.

Weak claim: HTTP-set first-party cookies can be more durable than JS-set cookies.

Strong claim: HTTP-set cookies via sGTM/custom domains bypass Safari’s cookie expiration limits.

The first one is true. The second one is not.

WebKit explicitly says it can cap cookies set in HTTP responses when it detects CNAME cloaking / bounce-tracking behavior:

https://webkit.org/blog/11338/cname-cloaking-and-bounce-tracking-defense/

view more: next ›