A discussion thread started by Simo Ahava on LinkedIn has drawn attention to a significant development in the ongoing conflict between ad blocking tools and first-party tracking infrastructure: filter lists maintained by AdGuard and the EasyPrivacy project now include explicit rules targeting subdomains used by server-side Google Tag Manager deployments, including instances where those subdomains use the common sgtm. prefix.

The finding matters because server-side GTM has been positioned widely in the analytics and advertising industry as a way to improve measurement reliability by moving tag execution off the user's browser and onto a server under the advertiser's own domain. That architectural choice was expected to make tracking less visible to browser-level blockers, which traditionally target known third-party domains like googletagmanager.com. The blocklist updates suggest that assumption is now under pressure.

What the filter lists contain

According to the AdGuard tracking filter file tracking_servers_firstparty.txt, maintained as part of the AdGuard Filters repository, the list contains over 3,400 blocking rules targeting first-party tracking subdomains. Among those rules are 83 entries matching the gtm. subdomain pattern and 42 entries matching sgtm. prefixes - a naming convention adopted widely by organisations running server-side GTM containers.

The blocked subdomains are not generic patterns. They are specific domain entries, named individually. The list includes sgtm.simoahava.com, Ahava's own server-side GTM instance, which he noted in his LinkedIn post. It also includes sgtm.yubico.com, sgtm.ookla.com, sgtm.open.ac.uk, sgtm.depaul.edu, sgtm.kaspersky.de, sgtm.myprotein.jp, sgtm.tennis-point.de, and sgtm.fashionunited. among dozens of others spanning multiple industries and geographies. Beyond the sgtm. prefix, entries under the gtm. pattern include gtm.wise.com, gtm.temu.com, gtm.elementor.com, gtm.elisa.fi, and gtm.bswhealth.com.

The EasyPrivacy easyprivacy_specific.txt file, hosted publicly on GitHub under the easylist organisation, also contains a rule for gtm.wise.com. According to the file's commit history shown in the uploaded source material, the file spans 2,378 lines covering 67.5 kilobytes of specific blocking rules across thousands of domains. That file is the site-specific component of EasyPrivacy and is included by default in uBlock Origin in its standard blocking mode, alongside EasyList. EasyPrivacy is also bundled in AdBlock Plus, AdBlock, and a range of other browser extension filters.

How server-side GTM came to be on blocklists

The logic behind server-side GTM's supposed blocker-resistance rested on the fact that the tracking request would originate from the same registrable domain as the site itself. A visitor to example.com whose analytics events were routed through sgtm.example.com would appear to be making a first-party request - one that generic rules targeting googletagmanager.com would not catch.

That approach worked as long as blocklist maintainers confined themselves to targeting known third-party origins. It started breaking down as those maintainers adopted a different strategy: cataloguing specific subdomains that, while technically first-party, were identifiable as tracking infrastructure by their naming conventions or by their known function.

According to Ahava's post, the shift reflects what he described as ad blockers needing "a blunter sword to cut through the obfuscation efforts." The implication is that domain-level inspection, rather than request-pattern matching alone, has become a viable strategy for filter list authors who can identify infrastructure from public records, DNS lookups, or community reporting.

Denis Golubovskyi, founder and CEO at Stape, commented on the thread. Stape is a managed hosting platform for server-side GTM containers and operates its own subdomain infrastructure. The AdGuard filter list includes a rule for stape.brascast.com and gw.stape.fr, suggesting that Stape's infrastructure has also attracted blocklist attention in specific cases.

The technical architecture at stake

Server-side GTM works by deploying a tagging server - a container that runs Google's open-source tagging software - on infrastructure controlled by the website operator. That server receives events from the client-side tag (the JavaScript that runs in the browser) and forwards them to downstream destinations like Google Analytics 4, the Google Ads conversion API, or Meta's Conversions API. Because the initial request from the browser goes to the operator's own server, it avoids the direct call to googletagmanager.com that blockers have long flagged.

The arrangement has a secondary benefit for measurement: cookies set by a server running on the operator's domain are treated as first-party cookies by browsers, giving them longer expiry windows than those set by third-party scripts. Safari's Intelligent Tracking Prevention, which caps JavaScript-set cookies at seven-day lifespans, does not apply the same restriction to server-set cookies on the same domain.

Google has been actively expanding this approach through its tag gateway product, which routes Google tags through CDN infrastructure integrated with an advertiser's domain. The tag gateway reached general availability in May 2025 and has since added CDN partner integrations with Cloudflare, Google Cloud Platform, and Akamai. According to PPC Land's coverage, Google reported an 11% signal uplift from tag gateway implementations. A Fastly integration announced in April 2026 cited a 14% signal uplift figure for recovered tag loads compared to third-party delivery. Neither figure comes from a controlled study published by an independent party; both represent Google's own reporting on the proportion of tag loads recovered when first-party routing intercepts requests that would otherwise be blocked or degraded.

The Google tag gateway's May 2026 update also introduced the ability to randomise the serving path for GTM container IDs, addressing a separate vector by which ad blockers could identify GTM implementations even after first-party mode was enabled. Ad blocker filter lists had maintained rules targeting both the googletagmanager.com domain and patterns matching the static GTM-XXXXXX container ID format.

What the comments reveal about the industry debate

The LinkedIn thread that surfaced this issue attracted commentary from practitioners across analytics, ad tech, and digital marketing. The responses illustrate how divided the professional community is on the ethics and practicality of the arms race between trackers and blockers.

Geoff Atkins raised the consent question directly, noting that users who click "accept all cookies" may not understand what "other technologies" they are consenting to unless they read the fine print in a cookie policy page. François de Broissia called bypassing ad blockers "ethically questionable (and ultimately futile)" and questioned whether it was positive to see blockers adopting what looked like speculative rules. Ahava's response acknowledged the systemic problem: "it all stems from the fact that users are considered playing pieces and currency rather than self-determining individuals." He also described his own organisation's practice - generating randomly named server-side paths to reduce fingerprinting exposure - and emphasised that his team tracks "only data that the user has consented for us to track."

Witold Wrodarczyk raised the technical alternative of using a subdirectory rather than a subdomain, combined with Cloudflare proxying and full query encryption, as a more resistant approach. Under this method, a request like g/collect?v=2&tid=GYC7W4SRV41 would be transformed into an opaque path like /img/y4634gUh_TR54dfa..., making pattern matching significantly harder.

Nikita Savchenko, who described building an earlier tool called dataunlocker.com to protect GTM and other analytics from blockers around six years prior, observed that once that approach was fingerprinted, the remaining layer of defence was the JavaScript itself. Savchenko referenced a subsequent project called afterpack.dev focused on JavaScript obfuscation to make that layer harder to detect or patch.

Charles Troy, a senior technical product manager at 2K Games, noted that gaming sites run some of the highest ad blocker rates of any vertical and suggested the structural answer was building user trust rather than extending the cat-and-mouse cycle.

Same-origin setups and their limits

One conclusion that might seem to follow from the blocklist developments is that same-origin setups - where the tracking endpoint uses an identical origin to the main website, not a subdomain - would be safer. Ahava explicitly pushed back on this. He argued that a subdomain approach remains preferable because over-zealous blockers could flag entire websites if they misinterpret the main site as a tracking endpoint. "A separation of concerns," he wrote, "is still the best approach."

The comment thread also pointed to the Google Tag Gateway as a specific case that participants debated. Doğukan Ince raised the question of whether Google Tag Gateway should be viewed differently from other first-party domain setups because it is a standardised product built specifically for Google tags. The question matters because a standardised infrastructure - one that uses predictable path structures or DNS configurations - may be easier for filter lists to identify systematically than a one-off subdomain with a random naming convention.

Ahava's view, according to the thread, was that the gateway operates in a similar risk category to other first-party setups for path-based blocking. The key variable is not the product itself but whether its implementation leaves identifiable patterns.

Context: the measurement infrastructure arms race

The filter list updates do not occur in isolation. They represent one move in a longer sequence of adaptations between measurement infrastructure providers and privacy tool developers.

PPC Land's coverage of the tag gateway from January 2026 noted that the product was designed partly to address blocklist-related signal loss. The two-part GA4 and server-side GTM bug report from September 2025 documented how technical implementation gaps in server-side GTM could produce inflated event counts in GA4 and connected ad platforms, showing that the infrastructure is not without its own failure modes independent of any ad blocker activity.

The consent and compliance dimension adds further complexity. Server-side GTM does not change the legal basis for data collection. Under the German court ruling of March 2025, GTM cannot operate before explicit user consent has been obtained - a requirement that applies regardless of whether scripts load from Google's servers or from first-party infrastructure. First-party routing changes the technical origin; it does not change the regulatory obligation. Google's hidden data controls, surfaced by Simo Ahava in a December 2025 LinkedIn post, provided a separate mechanism for restricting data transmission at the tag settings level - a control that Ahava noted "has probably flown under the radar for most."

The filter list developments described in this article add a new pressure point. Organisations that deployed server-side GTM under the assumption that their custom subdomain would remain invisible to ad blockers now face a situation where that assumption is no longer reliable, at least for implementations using predictable naming conventions like sgtm. or gtm.. Randomised path generation and same-IP proxying remain available countermeasures, but each carries its own trade-offs in terms of implementation complexity and potential for collateral blocking.

For the marketing community, the signal loss implications are not abstract. Measurement gaps that reach into double-digit percentage points affect the inputs to automated bidding systems in Google Ads and Meta, which rely on event-level conversion data to optimise delivery. A consistent undercount of conversion events shifts those systems toward suboptimal decisions, misallocates budget across channels, and produces return-on-ad-spend figures that do not reflect reality.

Timeline

Summary

Who: Simo Ahava, co-founder at Simmer and partner at 8-bit-sheep, surfaced the development through a LinkedIn post. Contributing voices include Denis Golubovskyi (Stape), Geoff Atkins, Witold Wrodarczyk, Nikita Savchenko, and Charles Troy (2K Games). The filter lists are maintained by AdGuard and the EasyList project.

What: The AdGuard tracking_servers_firstparty.txt filter list contains over 3,400 blocking rules targeting first-party tracking subdomains, including 83 entries matching the gtm. subdomain pattern and 42 matching the sgtm. prefix used by server-side GTM deployments. The EasyPrivacy easyprivacy_specific.txt file includes a rule for gtm.wise.com. Named entries include sgtm.simoahava.com, sgtm.yubico.com, sgtm.ookla.com, gtm.wise.com, and dozens of others, indicating that blocklist maintainers are now cataloguing individual server-side tracking subdomains rather than relying on generic third-party domain rules.

When: The LinkedIn thread is dated approximately two weeks before May 31, 2026, based on participant timestamps. The filter list entries have accumulated over time, with the specific commit documented in the EasyPrivacy GitHub repository showing active maintenance through May 2026.

Where: The filter rules appear in publicly accessible GitHub repositories maintained by the EasyList and AdGuard projects. The easyprivacy_specific.txt file is hosted at github.com/easylist/easylist. The AdGuard file is part of the AdGuard Filters repository. These lists are consumed by browser extensions including uBlock Origin, AdBlock Plus, and AdBlock, as well as by DNS-level blocking tools.

Why: The development matters because server-side GTM was positioned as a way to improve measurement continuity by routing tag events through first-party infrastructure, reducing exposure to blocklist rules that target known third-party origins like googletagmanager.com. The inclusion of named sgtm. subdomains in major blocklists means that predictable naming conventions no longer provide reliable protection. For marketers and advertisers, accurate measurement data is the input to automated bidding systems; systematic undercounting of events from ad blockers affects campaign optimisation, budget allocation, and reported return on ad spend. The debate also touches on consent and ethics: where the boundary between legitimate measurement and privacy circumvention lies is contested, and different participants in this discussion draw that line in different places.

Share this article
The link has been copied!