Publishers reported double-digit revenue drops after Safari 27 started blocking identity-resolution domains at the network level, according to Refacto. If you're running B2B paid media and relying on third-party identity vendors to stitch anonymous web sessions to CRM records, your Safari traffic just went partially dark. That's not a future risk. It's a current gap in your pipeline attribution.

What Apple Actually Did

Apple's WebKit team published a technical explanation on October 19: Safari and WebKit in iOS, iPadOS, macOS, and visionOS 27 now block network access to identity-resolution infrastructure at the domain level. The mechanism is specific. A visitor enters an email on a site. A third-party service converts that email into a persistent tracking identifier and returns it for cross-site recognition. Safari now kills those network calls outright.

Trade-press testing identified several vendors caught in the block: LiveRamp, ID5, The Trade Desk's UID2-related domain, Permutive, and Audigent (Experian), as PPC Land reported. Digiday noted The Trade Desk's ad-serving domain was initially blocked but later partly restored, while identity-service blocking remained in place.

Zach Edwards, founder of DecryptAds and an ad tech and cybersecurity researcher interviewed by AdExchanger, framed the dynamic bluntly: no technical workaround will stay permanently beyond Apple's reach. The industry should focus on consent and safer identity schemes rather than the next clever bypass.

Why B2B Pipeline Teams Should Care More Than Publishers

The publisher revenue story gets the headlines. For B2B SaaS marketing ops, the consequences are quieter and arguably worse. Identity resolution in B2B feeds multi-touch attribution models, account-based enrichment, and the handoff between marketing automation and CRM. When Safari blocks the identity call, you don't lose an ad impression. You lose the link between an anonymous session and a known contact.

That means more "unknown" traffic in your attribution reports. More pipeline that appears to come from direct or organic with no touchpoint history. eMarketer estimates Apple's US ad sales at $8.85 billion, per PPC Land's reporting. Apple controls the browser on every iPhone, iPad, and Mac. Vendor documentation consistently notes Safari and iOS resolution rates run lower than Chrome even before this block. After it, expect a wider gap, and expect your vendor's "match rate" number to mean even less than it already did.

Match Rate Is the Wrong Metric

Vendor-reported match rates aren't comparable across providers. The denominator varies (all traffic vs. addressable traffic vs. cookie-present traffic). The confidence threshold varies. The identity type varies (deterministic email match vs. probabilistic fingerprint). Safari's block makes this worse because it creates a browser-segmented reality. A vendor might report a 70% match rate, but if that number is weighted toward Chrome traffic and your high-value accounts browse on Safari (common in enterprise, where Apple device penetration skews higher), the effective match rate on the traffic that matters could be far lower.

The diagnostic: segment your identity-vendor reporting by browser. If your vendor can't do that, you have a measurement problem before you have an identity problem.

Server-Side Won't Save You (Entirely)

ID5's CEO told Digiday the company is preparing to move more identity infrastructure server-side, with revised integrations being tested with selected publishers. That's the reflex across the industry: move the processing off the browser, out of Apple's blocking reach.

Reasonable engineering response. Not a complete answer. Digiday's own reporting highlights skepticism that server-side shifts fully resolve the underlying privacy and platform-control issues. You're moving where the code runs, not changing what the code does. Apple's WebKit team described the blocked behavior as cross-site tracking infrastructure built on email-derived identifiers. If server-side solutions replicate that behavior, the privacy objection remains. The trade-off: you buy time on Safari addressability, but you increase ops complexity and governance overhead across marketing ops and engineering teams that are already stretched.

One more variable just shifted. Publicis Groupe completed its acquisition of LiveRamp on November 2. Campaign reports some brands are already beginning to exit LiveRamp as Publicis ownership tests industry trust around client neutrality. If your identity stack depends on LiveRamp's graph, you now have a vendor-neutrality question on top of a browser-blocking question.

The Measurement Architecture That Assumes Breakage

Setup: Pull your last 90 days of web-to-CRM match data. Segment by browser family. Calculate the percentage of sessions that resolve to a known contact in each segment. Compare the ratio before and after October 19 for Safari specifically.

Success = a quantified gap you can present to leadership as a measurement risk, not a vendor-feature request. Guardrails = don't reallocate budget based on this analysis alone; it's a diagnostic, not a decision. Stop-loss = if your vendor can't segment by browser, switch to a provider that can, or instrument the segmentation yourself via GA4 or your CDP.

What to measure: browser-specific resolution rate, touchpoint coverage by browser, and the delta in attributed pipeline between Safari and Chrome cohorts. What not to over-interpret: aggregate match-rate numbers that blend all browsers into a single figure.

Identity resolution built on email-derived cross-site IDs was always a borrowed-infrastructure play. Apple just called the loan. The teams that build measurement around consented, first-party data capture (not vendor match rates) will read their pipeline with less noise. Everyone else will keep arguing about whose dashboard is lying.