iOS 27 Broke Identity Vendors, Not Your Ad Account

Apple's restriction landed on the identity layer, and the identity layer is not where your conversions get counted. The correct first move after this week's reporting is a measurement of your own account across two equal windows — not a rebuild of your stack.

On October 28, Digiday reported that the Safari restrictions which took effect in September hit a named set of vendors: Audigent (an Experian company), ID5, LiveRamp (now part of Publicis Groupe), Permutive, and The Trade Desk's ad server, per live tests run during the week of October 19. The industry response is already visible — ID5 is migrating more of its identity infrastructure server-side, and others are lining up behind IAB Tech Lab's Trusted Server Framework.

Both of those are things vendors do to keep their own products working. Neither one tells you whether your ad account lost a single conversion.

The block was never aimed at your pixel

Read Apple's own explanation, reported by Digiday on October 20, and the target is stated plainly: identifiers derived from things like email addresses, used to recognize the same person across different websites without explicit consent. The complaint is that a third party sitting invisibly on pages where people type an email address can build a profile that survives logging out, unsubscribing, and switching devices.

That is a description of an identity graph. It is not a description of a conversion event.

Digiday's own testing found most of the ad-tech web addresses it checked were still loading, and that the block had caught a handful of companies. The same reporting notes The Trade Desk's ad server was caught up by accident and switched back on. In other words: the list is narrow, partly accidental, and unstable. Anybody who rebuilt their tracking stack in the first week of October was reacting to a vendor incident, not to their own data.

What is blocked, and what is not

The distinction that matters is between recognizing a person and recording an event. Apple went after the first. Your conversion reporting depends on the second. When those two things live in the same tag container — and in a lot of CDP setups they do — you get collateral damage that looks like an identity problem and behaves like a measurement problem.

Three multipliers decide your real exposure

Exposure is not a yes or no. It is roughly the product of three things, and if any one of them is near zero, so is your exposure.

1. Apple share of your traffic. Safari's share varies enormously by market and by audience. A B2B audience in the US and a consumer audience in Brazil do not carry the same iOS weight. If you do not know your Safari share by device and geography, you cannot size this story at all — and every headline you read about it is somebody else's audience.

2. Dependence on third-party identity. Lookalike seeds built from vendor segments, enrichment appended to form fills, CDP audience syncs, cross-site frequency capping. If your targeting is first-party lists, broad targeting and creative-led prospecting, you had very little to lose here.

3. Whether your conversion call is browser-only. A browser-only pixel in a Safari session is the fragile case. Pixel plus Conversions API with deduplication is the resilient one, which is why accounts already running both absorbed the September change as noise.

Multiply those three and you get a number between "this is not my problem" and "I lost signal in a measurable slice of my traffic." Almost nobody who panicked in October had actually done the multiplication.

The two-window test

This is the order we run when a client's conversion volume moves without a campaign change. It takes an afternoon and it answers the question before anybody touches architecture.

Step 1 — CRM first, then platform. Pick two equal windows of at least 14 days each, with the first reports of the Apple change as the boundary. Do not let a promotion, a price change or a holiday sit inside either window. Pull platform-reported conversions and CRM-verified leads or orders for both. Then compute the ratio between them.

The ratio is the instrument. Volume moves for a dozen reasons — seasonality, budget, creative, auction pressure. The ratio between what the platform claims and what your CRM confirms moves for one reason: the measurement path changed.

Step 2 — Set the threshold from your own history. Take the eight weeks before the change and compute the week-over-week swing of that ratio. You now have the account's normal variance. If the post-change delta sits inside that range, you have no signal — you have weather. If it sits outside it, and it holds for two consecutive weeks, you have a fault worth acting on.

This is the step everyone skips. They compare this October to last October and call the difference a trend.

Step 3 — Read event coverage and match quality as a direction, not a score. Event Match Quality and event coverage are diagnostic, not absolute. A coverage number falling while CRM-verified leads stay flat points at the browser call dropping events. A coverage number that has been flat for months says nothing about September. If you want the mechanics of that signal, we broke down how EMQ actually moves performance and what Meta's automatic events do to coverage.

Step 4 — Check audience composition before architecture. Seed sizes, matched audience counts, reach on lookalikes. Identity vendors feed this layer, so a shrinking seed is the first place a block shows up — and it shows up as unstable delivery, not as an error message.

Only if steps 1 through 3 all point the same way do you touch architecture. And by then you know which layer to touch, which is the whole point.

The decision by advertiser type

The pattern is consistent: the further your spend sits from a direct response event, the more likely you were exposed — and the less likely the exposure shows up in a dashboard you check daily.

Why "we're going server-side" is not your fix

This is where I part company with most of the coverage. Server-side is being sold as the answer to two different problems, and it only solves one of them.

For measurement, server-side works, and it works for a boring reason: the request Safari would have intercepted never originates in the browser. That is real, it is durable, and it should already be your default. We laid out the layer-by-layer version in the domain audit we run on client stacks.

For identity, server-side is not a fix. It is relocation. Mathieu Roche, ID5's CEO, told Digiday the quiet part out loud: "Going server-side is more resilient because you're not on the device anymore, so there's nothing the device can do to block you." That is an accurate description of resilience against a browser control. It is also a description of moving cross-site identity resolution somewhere Apple's browser cannot see it — which is the exact practice Apple's explanation objects to.

The critics of IAB Tech Lab's Trusted Server Framework make the same point from the other side: added infrastructure, more dependence on cloud providers, fingerprinting concerns, and a real risk that publishers invest heavily in a workaround Apple has already signalled it dislikes. A cat-and-mouse round is not a stable foundation for a measurement plan.

So when a vendor tells you they are moving server-side, the correct translation is: we are protecting our product's continuity. Ask what it changes about the events you can verify in your own CRM. If the answer is nothing, it is not your project.

What to do this week

Do not rebuild. Run the ratio. If the ratio held, you spent an afternoon and learned that your account is healthier than the news suggested — which is worth knowing, because the next story like this will arrive in about six weeks and you will run the same test in an hour.

If the ratio broke, fix the narrow thing: move the conversion call off the browser through the platform's own server-side endpoint, add deduplication — the same pattern behind our 2026 attribution rebuild — and stop there. Identity and audience repair is a separate decision with a separate budget, and it deserves a vendor conversation rather than a sprint.

If you want a second read on which of the three multipliers is actually yours, that is the conversation we have with clients before any rebuild gets scoped — our paid media team does it as a diagnostic, not a pitch. The accounts that came through September intact were not the ones with the newest stack. They were the ones that knew what a normal week looked like.

FAQ

Is my Meta pixel affected?

No public reporting puts the Meta pixel or the Conversions API on the restricted list. The named companies are identity and audience infrastructure. If your Meta-reported conversions fell, start with event coverage and deduplication in your own setup before assuming a browser blocked you.

Should I pause spend in Safari-heavy markets until this settles?

No. The auctions did not change; in most accounts the measurement layer did, if anything at all. Pausing hands competitors the delivery history you paid to build, and it removes the data you need to run the test in the first place.

How often should I re-run this test?

Once per platform change that names measurement, and once a quarter regardless. The value is not the single reading — it is having a baseline for what normal variance looks like, so the next headline takes an hour instead of a week.