Apple changed the rules. Again.
On 14 September 2026, Apple started rolling out iOS 27, and with it the Safari 27 identity block. Almost nobody in the industry saw it coming. Safari now refuses to talk to a list of identity providers, and many publishers only found out when bids and ads stopped showing up on iPhones.
Five weeks later, on 19 October, Apple published a note to explain itself. The message is clear: in Apple’s view, blocking third-party cookies is no longer enough. The cookieless identifiers that were meant to replace them are now in the line of fire.
For publishers, this is not just an ad tech story. It is a revenue story. And it raises a question most media groups still cannot answer: how much does Safari actually earn us, page by page?
What the Safari 27 identity block covers, and why it matters
Safari and WebKit 27 now block network access to what Apple calls identity resolution infrastructure: the services that turn an email address or a login into a persistent ID used across sites. The block applies on iOS, iPadOS, macOS and visionOS, in normal browsing and with default settings. In other words, desktop Safari is affected too, not only the iPhone.
Apple names no company. Industry reporting, however, has identified the domains on the list:
| Vendor | Role in the ad stack |
|---|---|
| Unified ID 2.0 (UID2) | Email-based ID backed by The Trade Desk |
| ID5 | Identity provider widely used in header bidding |
| LiveRamp (RampID, ATS) | People-based identity graph |
| Permutive | Publisher-side audience data |
| Audigent | Audience data and curation |
The Trade Desk’s own ad-serving domain was caught in the first wave as well. Apple has since pointed the company to the iOS 27.2 beta to restore access, but the identity vendors remain blocked.
Three points make this move different from previous ones. First, it is unilateral: Apple published no rules, no timeline and no appeal process before shipping it. Second, the list lives in WebKit and can grow without a new iOS release; reports already mention hundreds of ad tech, martech and data vendors under review. Third, Apple explicitly says it will keep allowing first-party personalization. The line is drawn between what a publisher knows about its own readers and what third parties stitch together across sites.
As mind Media points out, the real issue goes beyond privacy. By deciding alone which ad technologies may run in its browser, Apple acts as both referee and regulator, and publishers are reminded how dependent they are on its choices.
Publishers and trade bodies have been here before
The first reactions to the Safari 27 identity block came from the companies on the list. ID5’s co-founder Mathieu Roche called the change an attack on the business model of the open web, said Apple had refused to meet industry organizations, and urged regulators to take a closer look. IAB Tech Lab, for its part, warned that WebKit could soon let Apple add domains remotely, and is pushing publishers towards its Trusted Server, which moves ad requests from the browser to the publisher’s own infrastructure.
The trade bodies that represent publishers know this pattern well. In 2020, IAB Europe, the European Publishers Council, News Media Europe, ENPA and EMMA, together with the French Geste, SRI and Udecam, wrote to Tim Cook about the economic and competitive risks of Apple’s tracking policy on iOS. That fight ended before the French competition authority, the Autorité de la concurrence, which fined Apple €150 million over App Tracking Transparency in March 2025, after a complaint by Alliance Digitale, Geste, SRI and Udecam. Under that regulatory pressure, Apple has just announced a lighter ATT prompt in iOS 27.2 for France, Germany, Italy, Poland and Romania.
Safari itself is no stranger to these disputes. In October 2024, Alliance Digitale, the Alliance de la presse d’information générale (APIG), Geste, SRI, Udecam and Union des marques asked Apple to suspend Distraction Control, a Safari feature able to hide ads, consent banners and editorial content alike. Their letter warned that it threatened the economic balance of the media.
The sequence is telling. Apple loosens its grip on apps under regulatory pressure, and tightens it on the web at the same time. Whatever comes next from trade bodies and regulators, it will take months. Revenue decisions cannot wait that long.
Safari already earned less. The Safari 27 identity block targets the workarounds
Safari has blocked third-party cookies since 2020. Since then, publishers have lived with a structural gap: by default, Safari traffic earns 40 to 60% less in programmatic than other environments. That gap has two sources. Fewer buyers bid, because they cannot recognize the reader, so fill rate drops. And those who do bid pay less, so eCPM drops too.
Identity solutions were the industry’s answer. Publishers plugged UID2, ID5 or RampID into their header bidding setup, so that bid requests on Safari carried an identifier again. It never closed the gap, but it narrowed it on part of the inventory.
That is precisely what Safari 27 switches off. When an identity module cannot reach its domain, it returns nothing, and the bid request leaves without an ID. The campaigns that relied on that ID for targeting, frequency capping or measurement simply stop bidding on that impression.
The lesson is uncomfortable but simple. Every workaround that recreates cross-site tracking in Safari is now on Apple’s radar. Betting your Safari revenue on the next one is a bet on Apple’s patience.
The blind spot: monetizing every page as if browsers didn’t exist
Most publishers set their monetization rules once, for the whole site. Ad density, refresh, formats, paywall thresholds: the same settings apply whether the reader is on Chrome for Android or Safari on an iPhone. Yet the browser is one of the strongest factors behind what a page earns.
A site-wide RPM hides this completely. Safari’s share of traffic is not the same in every section, on every device or in every audience. A local news section read on the commute may be 70% iPhone. A business section read at the office may be mostly desktop Chrome. And most, if not all, Google Discover traffic comes from Chrome. Their average RPM looks fine; the Safari half of it may not.
And not every page reacts the same way. Pages that sell on contextual demand hold up better without identifiers. Pages that relied on addressable campaigns lose more. Without browser-level data, the impact of Safari 27 looks like a vague dip in revenue. With it, it becomes a list of sections, formats and traffic sources you can act on.
There is a second side to the story. A Safari reader who is worth little to programmatic buyers may still be worth a lot as a subscriber. Or not. If ads earn less on a given page in Safari, a stronger subscription offer there may be the better trade. Without data on both revenue and conversion, that decision is a guess.
What to measure after the Safari 27 identity block, browser by browser
The first step is to put revenue and audience side by side, split by browser, and to compare the weeks before and after 14 September. Six metrics tell most of the story:
| Metric | What it tells you about Safari |
|---|---|
| Page RPM | How much each Safari pageview earns compared with other browsers, section by section |
| Fill rate | Whether demand is disappearing on Safari inventory |
| eCPM | Whether the demand that remains is paying less |
| Revenue per session | Whether Safari readers browse enough to make up for lower prices |
| Active time | Whether Safari readers are engaged, whatever they earn in ads |
| Goal conversion rate | Whether Safari readers subscribe, register or sign up more or less than others |
The gap between fill rate and eCPM matters. A drop in fill rate means buyers have left, and contextual or direct demand is the lever. A drop in eCPM means buyers stayed but value the impression less, and ad density or format choices come into play.
The last line matters just as much. Ad revenue and subscriptions are two answers to the same question: what is this reader worth to us? Looking at one without the other leads to decisions that fix one line of the P&L by hurting the other.
How Alke Analytics gives you the browser view
Alke Analytics was built on one idea: audience and revenue belong in the same dashboard. Ad revenue is reconciled the next day and attributed down to the individual pageview, so every report can answer in revenue, not just in pageviews. Browser is one of the dimensions you can split or filter any report on.
In practice, that gives publishers four ways to handle Safari 27.
See the gap where it lives. Open the Monetization report, break it down by browser, then by section or content type. RPM, fill rate, eCPM and viewability appear side by side, from the property down to the article. Add an annotation on 14 September, and every chart shows the iOS 27 rollout as a reference line.
Find what really drives Safari revenue. Filters apply to every screen, including Revenue Insights. Filter on Safari, and the machine-learning model shows which topics, formats, channels and contexts lift or drag down RPM, with everything else held equal. The Opportunities tab then turns those drivers into projected revenue impact.
Weigh ads against subscriptions. Goal Analysis shows what leads readers to subscribe, register or sign up. Its arbitrage quadrant places each section on two axes, active time and RPM, colored by conversion rate. Filtered on Safari, sections with high engagement and low ad revenue land in subscription territory: the best candidates for a stronger paywall or a dedicated offer on that traffic.
Ask the question in plain language. With the Alke connector for AI assistants, a question such as “What was our Page RPM on Safari versus Chrome since 14 September, by section?” returns real figures from your dashboard, without building a report.
None of this depends on cross-site identifiers. Alke measures your own audience, on your own properties: exactly the first-party ground Apple says it will keep open.
Stop averaging. Start deciding browser by browser.
Trade bodies and regulators will have their say on the Safari 27 identity block, as they did on ATT. But Apple will not be the last platform to change the rules overnight. The list in WebKit can grow at any time, and publishers will not get a warning. What they can control is how fast they see the impact, and how precisely they respond.
That starts with refusing the site-wide average. Safari is not a rounding error for news publishers, and its revenue behaves differently from page to page. Publishers who can see revenue and conversion browser by browser will decide where to push ads, where to push subscriptions, and where to stop investing. The others will just watch their RPM slide.
Want to see how Safari 27 affects your own revenue? Start a free 7-day trial or request a demo, and we’ll walk you through your Safari numbers.
Sources: mind Media, 20 October 2026 · PPC Land, Safari 27 blocks identity firms · FASilytics, Safari 27 network-layer audit · PPC Land, ID5 CEO on the Safari block · iPhoneSoft, Safari 27 and the ATT fine · IAB Europe, 2020 letter to Apple · Usine Digitale, Distraction Control letter (2024)
