Safari 27 and Ad Tracking: What Changes for Conversion Data

What Apple said

A WebKit blog post on 19 October 2026 clarifies that Safari and WebKit in Apple's version 27 operating systems block network requests to third-party identity-resolution infrastructure at the domain level. These are services that invisibly collect email addresses to link people across websites or devices. The post says this does not prohibit ordinary first-party personalisation, such as a store that recognises its own logged-in customers.

Who this affects

• Brands using identity-graph vendors to stitch visitors across sites.
• Ad tech and retargeting setups that rely on third-party scripts calling those services.
• Less likely affected: sites that measure conversions with first-party tags, server-side events and consented first-party data.

Do not assume you are in either group. Test.

How to test your tracking on Safari

1. Use a Safari 27 device or a current Apple test device once available to you, and place a test lead or order.
2. Check events end to end. Confirm that the Meta Pixel and Conversions API event, the Google tag and your CRM record all show the test.
3. Open the browser's network tab and look for blocked or failed requests to third-party domains. Note which scripts they belong to.
4. Compare Safari vs other browsers in your analytics for the same period. A sudden Safari-only drop in conversions points to a tracking problem, not demand.
5. Review every third-party script in your tag manager. Remove anything you do not use.

Strengthen first-party measurement

• Send conversions from the server as well as the browser (for example Meta Conversions API and Google enhanced conversions), with consent where required.
• Collect clean first-party data with permission, such as the email and phone number a customer gives you in a form.
• Use unique event IDs so browser and server events are deduplicated, not counted twice.
• Keep your CRM as the source of truth for qualified leads and sales.

A related Google change to watch

An advertiser email surfaced publicly on 18 October saying Google Ads Data Manager will stop requiring pre-hashed SHA-256 customer data from 16 November 2026, using encrypted processing and normalisation inside a trusted execution environment instead. It would cover CRM connections, cloud imports, file uploads and the Data Manager API for Customer Match and enhanced conversions. Google's confidential-matching documentation supports the technology, but we did not locate a dated public product notice. Audit your upload workflows and consent controls, and do not assume existing hashed pipelines will break or that match rates will automatically improve.

If you want your tracking checked on Safari and everywhere else, request a free account review, or read about our Meta and Google set-ups.