Safari's Intelligent Tracking Prevention (ITP) and Firefox's Enhanced Tracking Protection (ETP) block third-party tracking cookies by default, and Chrome is phasing them out too. That kills any website visitor identification method that depends on a cross-site cookie surviving a page load. It does not touch IP-to-company matching or identity-graph-based identification, because neither one needs that cookie in the first place. If your match rate looks fine in Chrome and quietly collapses on Safari and mobile traffic, this is almost always why.

What ITP and ETP Actually Block

ITP and ETP were built to stop cross-site ad trackers, not B2B identification tools, but they don't distinguish between the two. Both browsers now block third-party cookies outright and cap the lifespan of some client-side, script-set first-party cookies (Safari has enforced a 7-day cap on script-set cookies since ITP 2.1). Chrome's Privacy Sandbox is walking toward the same end state on a slower timeline.

The practical effect: a visitor loads your site in Safari, a script tries to set a tracking cookie to stitch that session to future visits, and the browser either blocks it outright (third-party) or throws it away within a week (client-side first-party). Any identification method that depends on that cookie surviving loses the visitor. Nothing else about your site changes, so this is easy to miss unless you're segmenting match rate by browser.

Which Identification Methods Actually Survive

Not every method is exposed the same way. The risk depends entirely on whether the method needs a client-side, cross-session cookie to work at all:

• 🔴 Third-party cookie matching - dies immediately under ITP/ETP default settings; the cookie never gets set to begin with, so there's nothing to match on Safari or Firefox traffic.
• 🟠 Client-side JS fingerprinting alone - degrades over time as both browsers actively randomize or block the signals (canvas, font enumeration) fingerprinting relies on.
• 🟡 First-party cookie set client-side + enrichment - works on the first visit, but Safari's 7-day cap on script-set cookies means multi-session matching quietly decays for repeat visitors.
• 🟢 First-party cookie set server-side (HTTP response header) - Safari treats a cookie set by your own server as a legitimate first-party cookie with a normal lifespan, so this survives largely intact.
• ⚪ IP-to-company matching and identity-graph-based person matching - doesn't depend on a persistent client-side cookie surviving at all, so ITP and ETP have essentially nothing to block.

This is why "does your vendor use cookies" is a more useful question than "what's your advertised match rate." A tool built on cookie-matching can post a great number in its own Chrome-heavy demo environment and still lose a third or more of real-world traffic once you factor in Safari and Firefox share. Knock2's identification runs on IP-to-company matching plus person-level matching against an identity graph built from a consent-based publisher network, not a cookie you have to hope survives, which is also why we publish the same benchmark regardless of browser mix: 93%* account-level and 62%* person-level (US traffic) identification, measured against engaged sessions.

How to Test Your Own Exposure This Week

You don't need your vendor's cooperation to check this. Here's the self-test:

1. Open your site in Safari (or Firefox with ETP on "Strict") in a private window.
2. Open DevTools → Application/Storage → Cookies, and reload the page from a different referring domain (paste the URL into a new tab rather than clicking a same-site link).
3. Look for your identification vendor's tracking cookie. If it's missing, or it's present but stamped with a short expiry, that's your Safari/Firefox exposure.
4. Cross-reference against your CRM: pull identified contacts/accounts from the last 30 days and check what share came from Safari or Firefox user agents versus Chrome. If that split is dramatically lower than your actual traffic mix (check Google Analytics' browser breakdown), your match rate is browser-dependent, not just lower overall.

This takes under 20 minutes and tells you more about your real exposure than any vendor's published accuracy claim. If you want the deeper methodology for vetting a vendor's numbers generally, we've written about that here.

This gap is easy to carry for months without noticing, because nothing about it looks like an error. Sessions render normally, your CRM keeps filling with contacts, and the aggregate match rate a vendor reports doesn't break out by browser unless you ask for it. In practice, teams tend to find this the same way: they pull identified contacts for an unrelated reason, like reconciling a target-account list against what actually got identified, and notice their Safari and iOS numbers are thin relative to their real traffic mix. That's the pattern worth watching for, not a vendor dashboard alert, since no vendor's dashboard is built to flag its own blind spot.

It's also worth separating this from a related but different problem. B2B traffic has always leaned less on third-party cookies than B2C to begin with, since most B2B identification never ran on ad-tech cookie matching the way retargeting and programmatic display did. That means the browser-level cut here isn't the 40 to 60 percent drop some consent-driven analytics setups see. It's narrower, concentrated specifically on whichever slice of your stack still depends on a client-side cookie surviving, which is exactly why segmenting by browser matters more than watching your aggregate number move.

What This Means for Your GTM Stack

The honest takeaway isn't "switch tools." It's "know which layer of your stack is exposed." If your identification vendor is cookie-dependent, the fix isn't a setting you can flip; it's structural, and the browser vendors aren't reversing course. Apple and Mozilla have both been explicit that tracking prevention is a permanent product direction, not a temporary policy.

If you're evaluating tools or auditing your current one, ask directly: does this rely on a client-side cookie surviving across sessions, or is it matching at the network/identity-graph level? That single question predicts more about your real-world match rate than any case study. It's the same failure mode we've covered with ad blockers and VPNs and corporate networks. Different mechanism, same lesson: know what your vendor's method actually depends on before you trust the aggregate number.

This also compounds with the mobile blind spot we've written about before, since Safari on iOS is both a mobile browser and an ITP-enforcing one, so it's worth checking your mobile Safari numbers specifically, not just desktop Safari.

Frequently Asked Questions

Does Safari block website visitor identification?

Safari blocks third-party tracking cookies by default and caps the lifespan of some client-side first-party cookies. That breaks cookie-dependent identification methods, but not IP-to-company matching or identity-graph-based person matching, which don't rely on that cookie surviving.

Does Firefox's Enhanced Tracking Protection stop B2B visitor ID tools?

It has the same effect as Safari's ITP on cookie-dependent tools: third-party cookies are blocked outright. Non-cookie identification methods are unaffected by ETP for the same structural reason they're unaffected by ITP.

Will Chrome's third-party cookie phase-out affect website visitor identification?

For any method that depends on third-party cookies, yes, on the same timeline Chrome ships its changes. For IP-based and identity-graph-based methods, Chrome's phase-out changes nothing, since those methods were never built on that mechanism.

Is IP-based company identification affected by browser tracking protection?

No. IP-to-company matching happens at the network request level, not through a stored client-side cookie, so there's no cookie for ITP or ETP to block.

How do I know if my current visitor ID tool is losing Safari or Firefox traffic?

Run the DevTools cookie check above, then compare the browser mix of your identified contacts against your actual traffic's browser mix in Google Analytics. A large gap between the two is the tell.

Ready to see identification that doesn't depend on a cookie surviving? See how Knock2's workflows turn identified visitors into pipeline.

*Identification rates measured against engaged sessions (any visit lasting 10 seconds or longer, or including 2 or more pageviews). Results may vary by traffic profile, geography, and industry.