Safari 27 Blocks Email-Based Tracking IDs: What Should Stores Check?
On October 19, 2026, WebKit announced that Safari 27 blocks network access to identity resolution infrastructure, the third-party services that turn an email address entered at login or sign-up into a persistent tracking ID. First-party personalization is not the target, so a store should check which ad and audience tools depend on those IDs.
The WebKit post, signed by John Wilander, Charlie Wolfe and Matthew Finkel, is short and names no companies. That leaves store teams to work out which of their own tools might be affected. This post explains what changed and gives a short list of checks.
- Safari 27 blocks third-party identity resolution at the network level, per WebKit's October 19, 2026 post.
- First-party personalization is explicitly outside what WebKit says it aims to prevent.
- WebKit names no companies and published no domain list.
- Stores should find which ad and audience tools rely on email-keyed IDs and compare Safari results since mid-September.
What did Apple change in Safari 27?
Starting with iOS, iPadOS, macOS and visionOS 27, Safari and WebKit block network access to identity resolution infrastructure. WebKit describes the pattern this way: third parties collect the email address a person enters at login or newsletter sign-up, create an opaque tracking ID permanently linked to it, and return that ID to the page. Blocking happens at the domain level, so changing the request structure does not get around it.
WebKit's own wording on the boundary is: "First party personalization is not tracking, and is not what our technologies seek to prevent." A central resolver still counts as a third party even when it handles only one company's data.
- A third party collects the email a shopper enters at login or sign-up
- It returns a persistent ID linked to that email
- Blocking is by domain, so changing the request structure does not avoid it
- A central resolver still counts as a third party, even when it handles one company's data
- A store recognizing its own logged-in customers
- Personalization offered to a store's own users
- Websites keep the ability to personalize for their own users, per WebKit
Why does it matter for paid campaigns and ROAS?
When a blocked resolver cannot return an ID, a Safari session carries no identifier from it. Trade press reporting on the change says bid requests then go out without the ID and audience segments keyed to it stop matching. Safari is a large share of the traffic stores buy: Ecommerce Paradise, citing StatCounter, reported Safari at 46.38% of US mobile browser traffic in September 2026.
For an online store the consequence is on the measurement side. If a campaign's reach or match rate on Safari falls, the cost per order can change without anything on the site changing. Comparing paid traffic against what shoppers then do on the store, and scoring return on orders instead of clicks, separates an audience problem from a site problem. Related reading: how to improve ROAS from the site side and what to check when paid traffic is not converting.
What should a store check now?
Relevant Audience's analysis of the WebKit post suggests a list of audits, which are adapted below. They are suggestions, not requirements from Apple.
- Segment Safari by OS version. Find out how much of your traffic and how many of your conversions already come from Safari 27, since the block is tied to the operating system release.
- Scan login, checkout and newsletter forms for identity scripts. Include scripts loaded through a tag manager or an ad platform integration, because an email field is where these services collect the address.
- Compare Safari reach and match rates since mid-September. A drop in audience match rate on programmatic campaigns is the signal to investigate, not proof of cause on its own.
- List which audiences depend on email-keyed identifiers. Separate those from audiences built on your own first-party data.
- Confirm how conversion data reaches ad platforms. The WebKit post does not address server-side conversion uploads, so treat that path as something to verify with each platform.
How can Noibu's ROAS agent help?
Noibu's ROAS agent follows ad spend from visit to order. It compares paid traffic quality with on-site behavior, scores ROAS on orders and not just clicks, and recommends where to shift spend and targeting. Nothing changes without your approval, and the agents work in the Noibu console and in AI tools such as Claude Cowork, Microsoft Copilot and OpenAI Codex. Teams that want to see what shoppers do after an ad click can read how to see what shoppers do on your site after they click an ad.
To start with your own data, run Noibu's free website audit, which ranks where shoppers drop off from cart to completion and names the cause behind each one.
Frequently asked questions
What did Apple change in Safari 27?
Does Safari 27 stop first-party personalization?
Which companies are blocked?
How could this affect paid campaigns?
How can a store tell whether it is affected?
Noibu is AI for ecommerce operations, the always-on optimization system that keeps online stores running at their best. A team of supervised AI agents finds what's broken, slow, or leaking revenue, does the work, and hands results back for human approval. Trusted by retailers like Free People, Guess, Liquid I.V., and Ariat.
