The filter rule *$removeparam=/^utm_/ strips every standard UTM parameter from every URL it touches. But ehgys=1276879? No filter list on earth knows what that is. That’s the core mechanic behind coded UTM parameters—and it’s why 42.7% of internet users running ad blockers (Statista, 2025) can strip your campaign data without touching a single coded string. Ad blockers don’t think. They pattern-match. And coded parameters don’t match.
Here’s exactly how filter lists identify and strip your UTM parameters, the specific regex patterns they use, and why randomized strings survive every one of them.
How Ad Blockers Actually Strip Your UTMs
Ad blockers aren’t scanning your URLs with artificial intelligence. They’re running your query strings through simple text-matching rules maintained in community filter lists. EasyList is the default filter list in Adblock Plus, uBlock Origin, AdBlock, and dozens of other blockers (EasyList documentation, 2025). When EasyList says “strip this parameter,” every major ad blocker obeys.
The rules themselves are straightforward. EasyList uses explicit parameter names:
*$removeparam=utm_source
*$removeparam=utm_medium
*$removeparam=utm_campaign
*$removeparam=utm_term
*$removeparam=utm_contentAdGuard takes it further with regex:
*$removeparam=/^utm_/That single regex rule catches every parameter starting with utm_. Your carefully constructed utm_source=facebook&utm_medium=cpc&utm_campaign=spring_sale? Gone before your page finishes loading.
You may be interested in: How Ad Blockers Detect UTM Parameters: Why Coded Links Survive
It’s Not Just Browser Extensions Anymore
UTM stripping has graduated from optional extensions to built-in browser features. DuckDuckGo, Safari, Brave, and Firefox all have built-in UTM stripping features that target known parameter names (Browser documentation, 2025). Your visitors don’t even need to install anything—their browser does the stripping automatically.
The Chrome UTM Stripper extension alone maintains lists of 50+ known tracking parameters (Chrome Web Store, 2025). That covers not just Google’s utm_ prefix but also fbclid, gclid, msclkid, and dozens of platform-specific identifiers. Every one of these parameters is named, documented, and added to filter lists within weeks of a platform introducing it.
Safari’s approach is particularly aggressive. WebKit’s Intelligent Tracking Prevention doesn’t just strip parameters—it limits cookie lifetimes to 7 days for any tracking classified as cross-site. Combined with UTM stripping, Safari users become effectively invisible to standard campaign attribution within a week of their first visit.
60% of users aged 18-24 run ad blockers (Statista, 2025). If your audience skews young, you’re losing the majority of your campaign attribution data.
Every filter list, every browser feature, every privacy extension targets the same thing: recognizable parameter names. They maintain lists of known tracking strings and strip anything that matches. Nothing more. This approach works because tracking parameters follow predictable naming conventions—conventions that coded parameters deliberately avoid.
Why ehgys=1276879 Survives
Consider two URLs hitting the same landing page:
yourstore.com/shoes?utm_source=facebook&utm_medium=cpc&utm_campaign=spring
yourstore.com/shoes?ehgys=1276879The first URL carries three parameters that every filter list recognizes. The utm_ prefix is a bullseye. AdGuard’s regex /^utm_/ matches instantly. EasyList’s explicit rules match each parameter by name. Result: all three stripped. Your analytics sees a direct visit.
The second URL carries a single parameter: ehgys=1276879. Let’s run it through every filter check:
- EasyList explicit rules: No match.
ehgysisn’tutm_source,utm_medium, or any known parameter. - AdGuard regex
/^utm_/: No match.ehgysdoesn’t start withutm_. - Chrome UTM Stripper 50+ parameter list: No match.
ehgysappears on no list. - Browser built-in stripping: No match. Brave, Firefox, and Safari target known identifiers only.
The string ehgys=1276879 encodes the same campaign data as utm_source=facebook&utm_medium=cpc&utm_campaign=spring—but it’s invisible to every filter list in existence.
You may be interested in: What Are Coded UTM Parameters?
The Regex Problem Filter Lists Can’t Solve
Filter list maintainers face an impossible tradeoff. They can target known parameter names—that’s safe and precise. But they can’t target all unknown parameters without breaking the web.
Think about it. Query parameters drive search results, form submissions, session management, product filtering, pagination, and authentication flows. A rule that strips “any parameter that isn’t on an approved list” would break online shopping carts, login pages, and search engines simultaneously.
Filter lists work precisely because they’re specific. That specificity is exactly what coded parameters exploit.
A coded string like ehgys=1276879 looks like any other functional query parameter. It could be a product ID. A session token. A search filter. Filter lists have no way to distinguish campaign tracking encoded in randomized strings from legitimate application parameters. And they never will—because the format is indistinguishable by design.
How Coded Parameters Carry Full Campaign Intelligence
A coded UTM string isn’t stripping information—it’s encoding it differently. The string ehgys=1276879 can contain your full campaign data: source, medium, campaign name, content variant, and term. The encoding happens before the URL is generated. The decoding happens server-side, after the parameter safely arrives at your server.
The encoding process is deterministic but not reversible by pattern matching. Each coded URL maps to a specific campaign configuration stored in a lookup table. The parameter name (ehgys) and value (1276879) are generated from that configuration. Without the lookup table, the string is meaningless—which is exactly what makes it invisible to filter lists.
This is where architecture matters. Client-side tracking tools can’t decode these parameters because they run in the browser—the same environment where ad blockers operate. A JavaScript-based decoder would need to reference the lookup table, exposing the encoding scheme to any extension that monitors network requests. Server-side decoding eliminates this vulnerability entirely. The parameter only needs to survive the journey from click to your server. Once it arrives, the encoded data is extracted and routed to your analytics platforms with full attribution intact.
Here’s the thing: the gap between “data collected” and “data lost” is widening every quarter. Each browser update, each new filter rule, each privacy feature chips away at standard UTM parameters. Coded parameters don’t just work today—they’re structurally immune to the pattern-matching approach that every blocker relies on.
Transmute Engine™ handles this automatically. The inPIPE WordPress plugin generates coded campaign URLs and captures the encoded parameters when visitors arrive. Events are batched and sent via API to your Transmute Engine server—a dedicated Node.js application running on your subdomain—where the coded strings are decoded and routed simultaneously to GA4, Facebook CAPI, Google Ads, and BigQuery with complete campaign attribution restored.
Key Takeaways
- Ad blockers use pattern matching, not intelligence. They strip what they recognize—
utm_prefixes,fbclid,gclid—and ignore everything else. - 42.7% of internet users run ad blockers, and browsers like Safari, Brave, and Firefox add built-in stripping on top of that.
- Coded strings like
ehgys=1276879match zero filter rules because they contain no recognizable tracking patterns. - Filter lists can’t adapt without breaking legitimate website functionality—the format is indistinguishable from normal query parameters.
- Server-side decoding restores full campaign attribution after the coded parameter safely passes through every blocker.
*$removeparam=/^utm_/ scan URLs for parameters starting with “utm_”. A random string like ehgys=1276879 doesn’t match any known tracking pattern, so every filter list ignores it completely.”},{“id”:”faq-question-b2f1c76b-3840-42a3-a231-a0f495a5e01b”,”jsonQuestion”:”What filter list rules target UTM parameters and how do I avoid them?”,”jsonAnswer”:”EasyList uses rules like *$removeparam=utm_source and AdGuard uses *$removeparam=/^utm_/ with regex. Both target the “utm_” prefix specifically. You avoid them by encoding your campaign data into randomized parameter names that contain no recognizable tracking patterns.”},{“id”:”faq-question-9aee6ebb-9a93-4745-b536-61db8a52d1e7″,”jsonQuestion”:”Can ad blockers eventually learn to strip coded UTM parameters?”,”jsonAnswer”:”Filter lists work by maintaining known parameter names. A coded string like ehgys=1276879 is unique per campaign—there’s no pattern to add to a filter list. Ad blockers would need to strip ALL unknown query parameters, which would break most websites.”}]} –>
Ad blockers use pattern matching, not intelligence. Filter rules like *$removeparam=/^utm_/ scan URLs for parameters starting with “utm_”. A random string like ehgys=1276879 doesn’t match any known tracking pattern, so every filter list ignores it completely.
EasyList uses rules like *$removeparam=utm_source and AdGuard uses *$removeparam=/^utm_/ with regex. Both target the “utm_” prefix specifically. You avoid them by encoding your campaign data into randomized parameter names that contain no recognizable tracking patterns.
Filter lists work by maintaining known parameter names. A coded string like ehgys=1276879 is unique per campaign—there’s no pattern to add to a filter list. Ad blockers would need to strip ALL unknown query parameters, which would break most websites.
Ready to make your campaign data invisible to ad blockers? Generate your first coded UTM with inPIPE Free.
