How much spend are you wasting on inaccurate data?

Ad blockers do not just hide banners. They stop tracking scripts from loading at all: the pixel never fires, the event never exists, the sale happened but no tool ever heard about it. This is not an edge case. Roughly a third of web users browse with some form of ad blocking, and among young, tech-affine, higher-income audiences, exactly the people many brands pay the most to reach, the share is far higher. On top of the classic blockers, entire browsers now block trackers by default.

Missing data leads to false attribution, and false attribution leads to bad decisions. For attribution, the channels your blocked visitors came from get too little credit, so you shift budget away from campaigns that actually work and pay twice: once for the conversion you could not see, once for the budget you moved to the wrong place. For your CRM, visitors that never enter your tracking never enter your flows, so segments stay smaller and triggered emails stay unsent. And for your postbacks, the ad platforms optimize on the conversions they receive: feed them seventy percent of reality and their algorithms bid on distorted signal, your audiences stay smaller, and every learning phase takes longer than it should.

Even when a script loads, the browser decides how long a visitor stays recognizable. Safari's Intelligent Tracking Prevention caps identifiers written by JavaScript at seven days. Firefox's Enhanced Tracking Protection isolates or removes known tracking identifiers entirely. Roughly a quarter of your visitors browse with one of these limits active, and granting cookie consent changes none of it, because these are browser behaviors, not consent settings.

Identification is where attribution is actually won. A customer who logs in or types an email is easy to recognize. The art is everything before that moment: recognizing and stitching anonymous visitors across sessions and devices until they become a known customer. That stitching runs on identifiers, and identifiers are only useful if you can collect them reliably and keep them alive.

In practice, a customer journey is held together by a handful of identifiers: click IDs from the ad platforms (gclid, fbclid, ttclid) that connect a session to the exact ad click; first-party visitor IDs in cookies and localStorage that connect sessions to each other; the email address and phone number, usually hashed, that connect a profile to CRM and to the platforms’ match keys; customer and order IDs from your shop system that connect all of it to real revenue.

The point is not any single identifier. The point is being able to collect them at all times. A click ID is only valuable if it is still connected to the visitor ID two weeks later when the purchase happens. An email captured at checkout is only valuable for attribution if the anonymous sessions before it were preserved and can be stitched to it retroactively. Every identifier that expires early or never gets collected is a broken link in that chain, and the chain is only as strong as its weakest link. This is why the seven-day cap is so much more expensive than it sounds: it does not delete one cookie, it cuts every journey longer than a week in half.

Some tools answer the identifier problem with fingerprinting: combining screen size, fonts, IP address, and dozens of other signals into a probabilistic guess that two sessions belong to the same person. It sounds clever, but it is a guess, and it decays. Fingerprints change with every browser update, every new device, every network switch. Browsers actively randomize the signals fingerprinting depends on, and regulators treat it as the most invasive form of tracking, which is why blocklists flag fingerprinting-heavy vendors first. A guess that is eighty percent right sounds fine until you realize it silently merges different people and splits real customers into strangers, and you cannot audit which is which. Fingerprinting can support identity resolution at the margins. It cannot be the backbone. The backbone has to be deterministic: identifiers you set, own, and keep.

"First-party tracking" has become the label every vendor claims, but the differences underneath decide whether your data actually survives. A script served from your own domain still gets removed if the domain pattern it forwards to is publicly known. A first-party subdomain that is just a thin alias for a vendor’s server is transparent to browsers that resolve where traffic really goes, and Safari caps cookies set through such constructions at seven days anyway. And an identifier written by JavaScript is capped at seven days no matter how first-party the domain looks.

Real resilience needs all three layers at once: collection on infrastructure that is genuinely yours, identifiers set server-side so browser caps do not apply, and identity stitching that happens on the server, where no blocker or browser policy can touch it. That is the difference between first-party as a marketing label and first-party as an architecture. Your scan shows the difference in practice: tools with the label lose a quarter of their data anyway, tools with the architecture lose none.

We open your page in a real browser, record every network request and cookie, accept the consent banner, and record again. No guesswork from static HTML: the report shows what actually fires for a real visitor.

Every detected tracker is evaluated against the behavior of the major ad blockers and the identity limits in Safari and Firefox, so you see which share of visitors each tracker loses and where identifiers get cut short.

The findings roll up into three category scores for attribution, email marketing, and postbacks, plus one overall score from 0 to 100. Each category weighs how much data its trackers lose and how well they can identify returning visitors.

Yes. The checker loads one public page the same way a normal visitor's browser would, and only looks at what the page itself sends: scripts, requests, and cookies. Nothing is stored beyond a short-lived result cache, and no personal data is collected from the scanned site.