Apple's Privacy Changes and Their Impact on AdTech and MarTech

Apple has spent the better part of a decade repositioning itself as a champion of user privacy — and the downstream effects on AdTech and MarTech have been substantial. This article maps the key privacy features Apple has built into Safari and iOS, explains how each mechanism works technically, and outlines what practitioners in digital advertising and measurement need to understand.

Apple's Ecosystem at a Glance

Before getting into the privacy specifics, it helps to understand the breadth of Apple's platform. Privacy decisions made at the OS or browser level ripple across an enormous installed base.

Devices

• iPhone
• Macintosh
• iPad
• Apple TV
• iPod
• iWatch

Products and Services

• Safari web browser
• App Store
• iCloud
• Apple Pay
• Apple TV+

Safari Privacy Features

Apple released Safari for Mac computers in 2003 and for iOS in 2007, alongside the first iPhone. Safari runs on the Webkit browser engine, which is also the team responsible for shipping most of Safari's privacy features.

Intelligent Tracking Prevention (ITP)

In September 2017, Webkit released version 1.0 of Intelligent Tracking Prevention (ITP) — a feature designed to prevent cross-site tracking. Since then, Webkit has shipped numerous updates that have closed workarounds and progressively made it harder for ad technology companies to identify and follow users across different websites.

ITP incorporates a machine-learning model called the Machine Learning Classifier, which is trained on browser-collected statistics to identify which domains have the capability to track users across sites. Any domain that gets classified as a tracking domain faces restrictions on the data it can store in Safari.

Here is how ITP handles the various browser storage mechanisms:

• Third-party cookies are blocked by default.
• First-party cookies created via the JavaScript document.cookie API expire in 7 days.
• If a visitor arrives via a link containing a query string or fragment identifier, and the referring domain has been classified as a tracking domain, any first-party cookie set via document.cookie on the destination site expires in 24 hours.
• Under the same conditions (tracked referrer with query strings or fragment identifiers), data stored in localStorage expires in 7 days.
• All cookies created by a third-party CNAME-cloaked HTTP response expire in 7 days.

The practical effect of blocking third-party cookies by default was immediate and negative for behavioural ad targeting, frequency capping, measurement, and attribution. Subsequent ITP updates systematically closed every workaround that vendors attempted — CNAME cloaking, localStorage abuse, and link decoration among them.

Privacy Preserving Ad Click Attribution

Safari has not proposed any replacement for ad targeting or frequency capping, but it has put forward a mechanism intended to preserve limited attribution in a privacy-respecting way: Privacy Preserving Ad Click Attribution.

The flow works as follows (using a simplified example):

1. A user clicks on an ad on supershoes.com. Webkit's Privacy Preserving Ad Click Attribution uses two new anchor elements — adDestination and adCampaignID — which are included in the ad's markup and passed to the advertiser's landing page.
2. The user arrives at basketballshoes.com and converts (e.g., completes a purchase). When the conversion occurs, a tracking pixel fires back to supershoes.com. The .well-known/ad-click-attribution/21/25 path is passed to Safari, registering that a conversion has taken place.
3. Somewhere between 24 and 48 hours after the recorded conversion, Safari sends the conversion data to both supershoes.com and basketballshoes.com via a stateless POST request. A header referrer (basketballshoes.com) is included in the request to supershoes.com, so both sites know a conversion occurred for that ad click.

This architecture is conceptually similar to what Google Chrome's Privacy Sandbox is pursuing — attribution performed by the browser itself rather than by a third-party intermediary via cookies, without relying on individual-level identification.

For AdTech and MarTech practitioners, the implications are clear: the volume of attribution data will be reduced. That said, it remains possible to identify which ad drove a conversion and which publisher delivered the click, provided the conversion happened within the 24–48 hour reporting window. Conversions that occur outside that window will not generate attribution data.

Safari's Privacy Preserving Ad Click Attribution proposal is still being discussed and refined within the W3C privacy group. As of now, no published standard exists, and it remains unclear whether other browsers will adopt the mechanism.

iOS Privacy Features

Apple released iOS in 2007 with the first iPhone. iOS also powered earlier versions of the iPad and Apple TV before those devices received their own dedicated operating systems.

Apple's IDFA

At its Worldwide Developers Conference (WWDC) in June 2020, Apple announced privacy updates to iOS that fundamentally changed how in-app advertising and measurement work — centred on changes to the Apple IDFA.

What Is the IDFA?

Apple's Identifier for Advertisers (IDFA) is a string of numbers and letters assigned to Apple devices — iPhones, iPads, and Apple TVs. Advertisers and AdTech platforms use the IDFA to identify iOS, iPadOS, and tvOS users across apps in order to deliver personalized and targeted advertising, enforce frequency caps, measure campaign performance, and attribute impressions and clicks to app installs.

An IDFA looks something like this:

7D902I08D-7846-4CA4-TE6P-83369125YFDC

How AdTech Uses the IDFA

App developers can access a device's IDFA and pass it to their AdTech and measurement partners. SSPs, DSPs, ad networks, and mobile measurement platforms (MMPs) rely on the IDFA to power:

• Ad targeting and retargeting
• Frequency capping
• Campaign measurement
• Attribution
• Ad fraud detection

What iOS 14 Changed

With iOS 14, Apple introduced the App Tracking Transparency (ATT) framework, which requires explicit user consent before an app developer can access a device's IDFA.

• If the user grants permission, the IDFA is passed as normal.
• If the user denies permission, the IDFA is zeroed out, making it entirely unusable for identification purposes.
• App developers can only request IDFA access once per app install. There is no second chance.

SKAdNetwork

SKAdNetwork is Apple's framework for privacy-preserving app install attribution. Its goal is to provide conversion data to advertisers without exposing any user-level or device-level information.

Key characteristics of SKAdNetwork:

• The IDFA is not passed to AdTech platforms or MMPs, even when a user has opted in to tracking.
• All attribution data flows through SKAdNetwork before reaching the AdTech platform or MMP.
• SKAdNetwork only attributes app installs using a last-click model — view-through conversions are not supported.
• Campaign IDs are capped at 100 per AdTech platform (per ad network or MMP).

The combination of no IDFA, last-click-only attribution, and a 100-campaign cap represents a significant constraint on the granularity of data that mobile advertisers have historically relied on.

ITP Extended to All Browsers in iOS 14, iPadOS 14, and Safari 14

iOS 14, iPadOS 14, and Safari 14 were released on September 15, 2020, and they introduced two additional privacy-relevant changes:

• Privacy Report: Users can now see exactly how many trackers Safari blocked on any given page, along with additional detail about those trackers.
• ITP for all web browsers on iOS: ITP is no longer exclusive to Safari. On iOS 14 and above, Intelligent Tracking Prevention applies to all web browsers installed on the device — not just Safari.

This last point deserves emphasis. Developers and publishers who assumed that users on alternative iOS browsers (Chrome for iOS, Firefox for iOS, etc.) were outside the reach of ITP need to revise that assumption. The WebKit engine underpins all browsers on iOS due to Apple's platform restrictions, and ITP travels with it.

Practical Takeaways

Apple's privacy changes form a coherent, long-running programme rather than a series of isolated updates. The trajectory is consistent: reduce or eliminate the data signals that third-party AdTech relies on, perform whatever attribution is permitted within the browser or OS itself, and give users visibility into what is being tracked.

For AdTech and MarTech practitioners, the operational implications span both web and mobile:

• Web: Third-party cookies are gone in Safari. First-party cookies set via JavaScript carry a 7-day (or 24-hour) shelf life depending on the referral context. CNAME workarounds are also capped at 7 days. Any measurement architecture that depended on persistent Safari cookies needs a rethink.
• Mobile: IDFA-dependent workflows — targeting, retargeting, frequency capping, attribution — require consent under ATT, and most users decline. SKAdNetwork provides a narrow, last-click, install-only fallback.
• Attribution: Browser-side attribution via Privacy Preserving Ad Click Attribution is still evolving and has no published standard yet. Platforms building measurement solutions should monitor the W3C privacy group for updates.

The broader direction Apple is pursuing — mirrored in different form by Google's Privacy Sandbox — points toward a future where deterministic cross-site and cross-app identification is the exception rather than the rule.