Your UTMs arrived on the page. Your analytics never received them. That’s not a bug—it’s how filter lists work. EasyList blocked your GA4 script before it could fire. Your utm_source parameter sat in the URL, completely ignored, while the visitor browsed and eventually purchased. Your conversion data shows the sale happened. It doesn’t show which campaign drove it.

This is the reality for 31.5% of global users running ad blockers (Statista, 2024). But the mechanism behind the data loss is poorly understood. There’s a critical difference between script blocking—where analytics never fires—and parameter stripping—where UTMs are removed from URLs entirely. Understanding how filter lists work is the first step to protecting your attribution.

Two Ways Filter Lists Break Your Attribution#

Filter lists don’t use a single approach. They employ multiple mechanisms depending on what they’re targeting. For marketers, two matter most:

Script Blocking: Your Analytics Never Fires

EasyList is the most widely used filter list for ad blockers. It’s the default list in Adblock Plus, uBlock Origin, AdBlock, and dozens of other blockers. When someone installs an ad blocker, they’re almost certainly running EasyList.

EasyList works by maintaining a database of known ad and tracking resources. When your visitor’s browser tries to load google-analytics.com/analytics.js or connect.facebook.net/en_US/fbevents.js, EasyList says no. The request gets blocked before it completes.

Here’s what happens to your UTMs: they arrive intact. The URL shows ?utm_source=facebook&utm_medium=cpc&utm_campaign=summer_sale. But your GA4 script never executes. Your Meta Pixel never fires. The UTM parameters sit in the address bar, untouched and uncaptured. Your analytics shows zero traffic from that visit—not just missing attribution, but a completely invisible visitor.

You may be interested in: GA4 Consent Mode Is Killing Your WordPress Analytics

Parameter Stripping: Your UTMs Get Deleted

AdGuard maintains separate filter lists for tracking and ads. This distinction matters. The AdGuard Tracking Protection filter doesn’t just block scripts—it actively removes tracking parameters from URLs using $removeparam rules.

A typical AdGuard rule looks like this: *$removeparam=utm_source. When enabled, this rule scans every URL for parameters named “utm_source” and strips them before the page loads. Your visitor clicks your Facebook ad, lands on your site, and by the time your page renders, the URL has been cleaned. The utm_source parameter is gone.

uBlock Origin takes a hybrid approach. uBlock Origin uses multiple filter lists by default, including EasyList for ad blocking and EasyPrivacy for tracking protection. Users can enable additional lists like AdGuard URL Tracking to add parameter stripping capabilities.

The pattern-matching logic is straightforward but effective. Filter lists contain rules targeting known parameter prefixes. Any parameter starting with “utm_”, “fbclid”, “gclid”, or other recognized patterns gets flagged for removal. The filter doesn’t need to know what the parameter contains—just that its name matches a known tracking pattern.

What’s Actually in These Filter Lists#

Filter lists are plain text files containing thousands of rules. Understanding their structure reveals why certain parameters get targeted and others don’t.

EasyList Structure

EasyList focuses primarily on blocking resources rather than stripping parameters. Its rules target specific domains and URL patterns:

Domain blocks prevent connections to known tracking servers. When your GA4 script tries to send data to google-analytics.com, the request dies before it starts. URL pattern blocks target specific file paths associated with tracking. Element hiding rules remove ad containers from pages visually while still allowing the underlying requests in some cases.

EasyPrivacy—a companion list often enabled alongside EasyList—adds more aggressive tracking protection including some parameter removal for known click IDs.

AdGuard’s Approach

AdGuard separates concerns into distinct filter lists. The AdGuard Base filter handles traditional ad blocking. The AdGuard Tracking Protection filter targets analytics and measurement. The AdGuard URL Tracking filter specifically addresses parameter stripping.

The $removeparam modifier is AdGuard’s key weapon against UTM tracking. Rules using this modifier strip specific parameters regardless of the domain. This means your first-party subdomain doesn’t protect you—if the parameter name matches the pattern, it gets removed.

You may be interested in: User Identification Without Cookies: The 4 Methods WooCommerce Stores Actually Have

The Script Blocking vs. Parameter Stripping Distinction#

This distinction is crucial for choosing the right protection strategy.

With script blocking: Your UTM parameters survive but are never read. The data exists in the URL but your analytics platform can’t capture it. Server-side tracking can help here because it captures data on your server before the browser blocks client-side scripts.

With parameter stripping: Your UTM parameters are deleted from the URL entirely. Even if your analytics script could run, there’s nothing to read. Server-side tracking alone won’t help because the parameter is gone before your server receives the request.

Many users run both mechanisms simultaneously. EasyList blocks your scripts while AdGuard URL Tracking strips your parameters. The attack is redundant but thorough.

Why Coded Parameters Bypass Filter Lists#

Filter lists work through pattern recognition. They maintain databases of known tracking parameter names and match incoming URLs against those patterns. The logic is simple: if parameter name equals “utm_source”, strip it.

Coded parameters break this assumption. Instead of using recognizable names like utm_source, utm_medium, and utm_campaign, coded parameters use randomized identifiers. A campaign tagged with “udyek=78256503&jwkrv=41925804&pkqmn=93847562” carries the same information as traditional UTMs, but the parameter names are meaningless to filter lists.

No filter list maintains rules for “udyek” because it’s not a recognized tracking parameter. The pattern matching fails. The parameters pass through untouched. Your attribution data survives.

The limitation is infrastructure. You need systems to encode parameters when generating campaign URLs and decode them when processing analytics data. The randomized names must map back to your actual campaign structure somewhere in your stack.

Combining Protection Strategies#

No single approach addresses all filter list mechanisms. Effective protection requires layered strategies:

Server-side tracking captures data before browser-based filters can intervene. When a visitor lands on your WordPress store, your server sees the full URL including all parameters. Even if client-side scripts are blocked, the server has already logged the attribution data.

Coded parameters protect against stripping mechanisms. Even aggressive parameter removal rules can’t target parameter names they don’t recognize. Your data arrives intact and gets captured before any filtering occurs.

First-party data collection reduces exposure to domain-based blocking. Requests to your own subdomain face less scrutiny than requests to google-analytics.com or connect.facebook.net.

WordPress Implementation Without GTM#

For WordPress and WooCommerce stores, implementing these protections traditionally required Google Tag Manager server-side containers, custom cloud infrastructure, and significant developer expertise. Most store owners couldn’t justify the complexity or cost.

Transmute Engine™ provides a different path. It’s a first-party Node.js server that runs on your subdomain—capturing parameters server-side before filter lists can intervene, then routing data to GA4, Facebook CAPI, and other platforms simultaneously. The inPIPE WordPress plugin handles event capture; the Transmute Engine server handles processing and delivery. No GTM dependency. No filter list vulnerabilities.

Key Takeaways#

• EasyList blocks tracking scripts entirely—UTMs arrive but analytics never fires to capture them
• AdGuard URL Tracking filter uses $removeparam rules to strip utm_source, utm_medium, and other parameters directly from URLs
• uBlock Origin combines multiple filter lists by default including both script blocking and parameter stripping capabilities
• Script blocking and parameter stripping require different protection strategies—server-side tracking helps with blocked scripts while coded parameters protect against stripping
• Coded parameters bypass filter pattern matching because randomized names like “udyek” aren’t in any filter database

Filter lists evolve constantly. Protect your attribution with infrastructure designed to stay ahead at seresa.io.