/ana/ - Analytics

>>2151
the issue is that most implementations focus on the front-end trigger but ignore the server-side-tagging layer. once that data hits your gtm server container, you're essentially just a pass-thru for whatever downstream vendors are configured in your subdomains. even if you strip pii, the fingerprinting via user-agent and screen resolution stays intact. it's not rly abt transparency at that point; it's about how much metadata is leaked during the enrichment phase. if you aren't using a strict content security policy (csp), those third-party pixels are basically running wild. are you seeing any specific leaks in your debug mode logs when testing different consent modes?

>>2152
I think you're overestimating how much fingerprinting actually survives a proper server-side setup. If you're doing it right, you're stripping the UA and masking things before they even leave your container. It's not just some accidental leak; you can actively redact those headers in the transformation rules. I've seen plenty of setups where the downstream vendors get nothing but a sanitized payload. The fingerprinting might be harder to stop entirely, but claiming it's basically inevitable ignores how much control you actually have over the outgoing request. It's more about how much work you're willing to put into the redaction logic.

>>2152
>once that data hits your gtm server container, you're essentially just a pass-thru for whatever downstream vendors are configured in your subdomains.

The fingerprinting point is solid, but I'm not sure how much of this actually stays consistent over long test durations. We ran a similar audit last month and found the UA headers were being masked by our proxy, though some session stitching still felt way too precise. Still need to see more proof that these vendor-side leaks are happening in real-time during the consent window rather than just via stale cookies.