The Reason Why Most Ad & Conversion Tracking Tools Are Not Working

E-commerce brands, operators, and performance marketers spend millions on advertising and thousands on tracking and attribution tools every year. Most of those tools miss 30 percent or more of the sessions they’re supposed to measure.

That’s not an attribution problem. It’s a tracking problem, and most teams don’t realize it because the two get conflated.

Tracking is not attribution

Tracking is the moment a script fires in a user’s browser and writes data, either to your servers or to the user’s device. Everything downstream depends on that one event. Attribution. Conversions API feedback to Meta, Google, TikTok. Klaviyo abandonment flows. A/B test results. On-site behavior analytics.

If the script doesn’t fire, none of it exists. The user is invisible. The session never happened in your data.

Attribution is the layer where you decide which touchpoint deserves credit for a conversion. It’s a modeling problem, and it’s a hard one. But every attribution model in the world starts from the data tracking collected. If tracking captured 60% of sessions, your attribution is running on 60% of reality. You cannot model your way out of that.

This is the part that gets missed in every vendor sales pitch. Most attribution tools spend their time talking about modeling logic, identity graphs, walled garden reconciliation. Important work. But it all sits on top of tracking, and if tracking is leaky, the rest is theater.

Technological hurdles for ad & conversion tracking

The share of users browsing in a tracking-prevention environment is larger than most teams assume. Two categories stack into the same outcome: tracking prevention shipped by the browser itself, and adblocker extensions users install on top of it.

Browser tracking prevention

Four major browsers ship with some form of tracking prevention enabled by default. The mechanism differs in each case, but the effect on a typical vendor’s tracking script is the same: requests dropped, cookies capped, cross-visit recognition collapsed.

1. Safari Intelligent Tracking Protection (ITP). On by default in every Safari install. Uses algorithmic detection of cross-site trackers, not a public blocklist. ITP can catch a script that no blocklist has flagged.

2. Firefox Enhanced Tracking Protection (ETP). Default on in every Firefox install. Uses the Disconnect.me blocklist.

3. Brave Shields. Built into the Brave browser. Uses multiple public filter lists; the most aggressive of the four by default.

4. Microsoft Edge Tracking Prevention. Edge ships with tracking prevention enabled at the “Balanced” level by default, using Microsoft’s Trust Protection Lists. The lightest of the four, but still blocks known third-party trackers for users who never adjust their settings.

The table below shows what each environment does to a tracking script and the cookies it sets.

Source: cookiestatus.com, the reference for adblocker and browser tracking-prevention specs.

Safari is the row to watch. The other three rely on public blocklists, which a clean domain can route around. Safari’s ITP uses algorithmic detection instead: even a blocklist-immune setup can get flagged if a vendor serves the same tracking script across thousands of customer sites. ITP recognizes the cross-site pattern and starts limiting it. And the 7-day cookie cap on detected cloaking quietly collapses cross-visit recognition, even in a first-party context, the moment any vendor fingerprint shows up in the domain.

Browser-level penetration, per StatCounter, April 2026:

• Worldwide, all devices: Chrome 68%, Safari 17%, Firefox 2%.
• Worldwide, mobile: Safari is 26% of mobile sessions, second only to Chrome at 66%.
• Germany, all devices: Chrome 51%, Safari 19%, Firefox 10%, Edge 9%. Safari and Firefox together account for ~29% of German traffic.
• Germany, mobile: Safari is 30% of mobile sessions; Firefox another 3%.

Ad blockers

On top of browser-level prevention, a meaningful share of users install adblocker extensions that block the same infrastructure. The most common:

• uBlock Origin (open source, dominant on Firefox and Chrome)
• Ghostery (privacy-focused, tracker-aware)
• AdBlock Plus (historically the most installed, especially on Chrome)
• AdGuard (cross-platform, system-wide blocking)
• Disconnect (also the source of the blocklist bundled into Mozilla products)

Around 30% globally and 31.5% in Germany of internet users run one (GWI, Q2 2025). The share is higher among the technically literate audiences most DTC brands actually want to reach.

All of these (and Firefox ETP and Brave Shields too) work the same way under the hood: public blocklists. You can read them yourself; cookiestatus.com is one place to start. The lists are long, public, and aggressively maintained. Domains and URL fragments associated with known tracking infrastructure get added. Browsers and extensions reference the lists and block matching requests.

Two things follow from this.

First, the lists target third-party domains. They identify infrastructure shared across many sites. Your own customer-facing domain, the one users typed into the address bar, is by definition not on the list. It cannot be. Blocking it would mean blocking the website the user just chose to visit.

Second, the lists are pattern-matched, not just exact-matched. If your tracking script loads from a domain containing recognizable strings (a vendor name, common tracker patterns), it’s a candidate for the list even if the specific subdomain is new.

This is the entire answer to “why is my tracking missing 30% of my traffic.” Vendors run their scripts from domains they control. Those domains end up on blocklists. The scripts get blocked. The traffic vanishes from your reports.

Even after subtracting overlap (Safari and Firefox users who also run adblockers), the combined share of sessions running through at least one tracking-prevention environment sits comfortably above 30% globally and around 50% in Germany and similar privacy-aware markets. That is the share of your visitors whose browsers are actively trying to prevent the data collection your stack depends on.

Regulatory hurdle for user tracking

GDPR and § 25 TDDDG (Germany’s TTDSG successor) make user tracking with intent to recognize someone across visits consent-required. No exceptions. No clever workarounds. A user who declines consent is not trackable for long-term recognition, full stop.

Every attribution vendor sits in the same boat as Meta and Google on this. No vendor solves the regulatory problem. The differences between vendors here are zero.

This matters because it’s the part of the conversation that gets the most airtime in sales calls, and it’s also the part where nobody has an advantage. Move on.

What good tracking comes down to

Strip away the marketing layer, and good tracking comes down to one question:

In how many browser environments does your tracking script actually fire and persist data?

That’s it. Not “is it server-side.” Not “is it first-party.” Not “do you have a Conversions API connector.” Just: does the script run, and does the data it writes survive long enough to matter.

The single question that cuts through every vendor pitch

Forget every other framing. “Server-side tracking” doesn’t matter if the client-side script that fires the server-side event is blocked. “First-party context” doesn’t matter if the implementation still routes data through a vendor subdomain that pattern-matches a blocklist. “Fingerprinting” doesn’t matter if the script that collects the browser characteristics never runs in the first place.

CNAME cloaking, where a vendor sets up a CNAME record like track.yourbrand.com pointing to tracking.vendor.com, looks first-party on the surface. In practice it often gets caught anyway:

1. If tracking.vendor.com or its parent domain is on a blocklist, the resolution gets caught.
2. If the subdomain you create still contains the vendor name (something like vendor-tracking.yourbrand.com), pattern matching catches it.
3. Safari’s ITP specifically penalizes detectable CNAME cloaking with a 7-day cookie cap instead of the standard 400 days. Cross-visit recognition collapses.

The single test that cuts through all the vendor pitches:

Does the tracking script load from a URL on a domain you actually own and use elsewhere, with no vendor naming anywhere in the domain?

If yes, you’re in the small minority of setups that fire across the >50% of environments running blocking tech.

If no, you’re losing data. The exact percentage depends on your traffic mix, but 20 to 40% session loss is the realistic range for most DTC brands.

The Shopify trap nobody talks about

Specifically for Shopify merchants, there’s a sharp version of this that catches a huge number of brands.

Shopify offers two places to install tracking scripts:

• The theme <head>, which loads scripts from whatever domain you point them at.
• Customer Events pixels, which run inside Shopify’s pixel infrastructure.

Customer Events pixels are convenient. They feel like the “right” way to install tracking in 2025. They are also routed through Shopify’s pixel domains, which are on blocklists. If your only install point is a Customer Events pixel, your tracking is blocked for the majority of users.

Many vendors quietly recommend Customer Events as the primary install because it shortens their time-to-live. The hidden cost is that the data you start collecting is significantly leakier than what the same vendor would deliver via a proper theme-header install on a customer-owned domain.

How to test it yourself in five minutes

Open the vendor’s documentation, or look at the vendor’s reference customers on their website and check which domains their scripts load from. If you don’t want to dig through docs, paste them into an AI assistant with the question “what domains does this vendor’s tracking script load from in production.” You’ll get the answer in seconds.

Install an adblocker (Ghostery, uBlock Origin, anything mainstream) on a clean browser profile. Visit one of the vendor’s reference customer sites. Open DevTools, go to the Network tab, filter by the vendor’s domain.

You’ll see one of two things:

• Red X marks next to the tracking requests. The script is being blocked. The vendor is losing this user.
• Green status codes. The script is firing. The vendor is collecting this user.

Toggle the adblocker off and reload. The blocked requests should fire. Toggle it back on and they stop again. That’s your A/B test.

Repeat in Brave for the strictest possible environment. Repeat in Safari and check Application → Storage → Cookies to see what cookie expirations actually look like in practice.

If a vendor sales rep cannot or will not tell you the exact domain their script loads from, that itself is the answer.

What you gain when tracking is clean

The numbers compound through the stack:

• 20 to 40% more sessions captured, the direct inverse of the blocking rates above.
• 20 to 30% more conversions reported back to ad platforms via Conversions API. Meta, Google, TikTok, Taboola, Outbrain. More signal means better bidding, better lookalikes, lower CACs.
• 20 to 30% more abandonment and behavior flows triggered in Klaviyo or your CRM, because the user events that trigger them are now visible.
• Cleaner A/B test reads, because most testing tools (VWO, Chameleon, and similar) also operate in third-party context and miss the same chunk of traffic. Run your tests through clean tracking and the variance drops.
• Honest on-site analytics, where the funnel reflects the actual user base instead of the subset whose browser permits the tracking script.

This is the leverage that vendor pitches gloss over. Attribution modeling, identity resolution, walled-garden reconciliation: every one of these problems is real and worth solving. But they all build on tracking. A 40% data loss at the foundation cannot be modeled away by clever logic at the top.

What we’re building at Adtribute

The tracking layer is built around a single principle: the script loads from a domain the customer owns, with no vendor fingerprint in the subdomain. No CNAME cloaking pointing back to an adtribute.io parent. No shared third-party infrastructure that ends up on a public blocklist after a year of growth.

That setup is invisible to blocklists because it cannot end up on one. It is invisible to Brave for the same reason. It runs full 400-day cookies in Safari because it is a real first-party context, not a cloaked one. The result is the inverse of the loss numbers above: 20 to 40% more sessions tracked than the same brand would see on a typical bolt-on stack.

Identity resolution and attribution sit on top of that. Both matter. Both are easier when the base layer is honest about what it can see.

Cookies, fingerprinting, server-side relays, post-purchase surveys: all of these are downstream identity techniques. They operate on whatever the tracking script captured. If the capture rate is leaky, every one of them inherits that leak.

The question to ask your current vendor

One question, sent to your account manager:

Can you show me the exact URL my tracking script loads from in production? And: is that domain on EasyList, EasyPrivacy, or Disconnect?

The answer tells you almost everything you need to know about how much of your traffic your current stack is actually capturing.

If the answer is uncomfortable, the right move isn’t to switch attribution models. It’s to fix tracking first.