Retargeting afterATT: what stillworks on iOS.

What ATT requires

App Tracking Transparency is Apple's framework for consent to tracking. In Apple's usage, tracking means linking data about a person collected in one app with data from other companies' apps or websites, for targeted advertising or measurement, or sharing that data with a data broker. An app that does this must show a system prompt asking the person for permission. The wording of the prompt is the app's to supply, but the prompt itself and the choices in it belong to the operating system.

The person can allow or decline, and can change the decision later in Settings. The decision is made app by app. Allowing it in one app says nothing about another, and a person may also switch off the request for all apps at once.

The IDFA and when it is available

The IDFA, the identifier for advertisers, is a device-level code that lets separate systems recognise the same device. It is what made classic retargeting on iOS work: an advertiser's list of lapsed devices could be matched to ad requests that carried the same code.

Under ATT, an app receives a usable IDFA only if the person has allowed tracking for that app. If they have declined, or have not been asked, the app is given a value made of zeros, which identifies nobody. The identifier still exists, and it is available again whenever permission is granted. Nothing about it can be recovered by working around the prompt, and any approach that tries to do so conflicts with Apple's rules.

Why both apps need permission

Device-level matching has a requirement that is easy to miss: it needs the identifier on both sides of the match. The advertiser holds a list of lapsed people, keyed by the IDFA their own app collected. The publisher's app sends ad requests that carry the IDFA of whoever is using it. A match happens only when both contain the same code.

Permission is granted per app, so two separate permissions must exist. The person must have allowed tracking in the advertiser's app, or the advertiser has no IDFA to put on a list. And the person must have allowed tracking in the publisher's app, or the ad request arrives with zeros and nothing to match. If either has said no, there is no device-level match.

This explains why the addressable share of iPhone traffic is smaller than the traffic itself, and why it varies by app. Some apps, because of their audience or how they ask, have more permissions in place than others. A buyer cannot assume that a lapsed person and a publisher's request line up. A system built for the post-ATT world checks the permission state on every request.

SKAdNetwork and AdAttributionKit

Measurement had to change alongside targeting. SKAdNetwork, Apple's attribution framework, lets the operating system confirm that an ad led to an install and report it to the ad network without exposing who the person was. Its limits come from the design. Reports arrive in aggregate, with a delay, and carry a small amount of information about what happened after the install. Detail is reduced when the number of people involved is small, to protect individuals.

AdAttributionKit is Apple's newer framework in the same family. It keeps the privacy model of aggregate and delayed reporting and adds support for re-engagement, meaning attribution when an ad brings back someone who already has the app. That matters for retargeting specifically, since earlier frameworks were built around installs. The extent of the support and the detail it returns should be checked against Apple's current documentation, because the frameworks continue to change.

The practical effect for an advertiser is that iOS results from these frameworks are coarser and later than device-level reports. They are best used for direction and for comparing campaigns against one another, and they combine well with a randomised holdout, which measures lift without needing to follow any individual.

Contextual and on-device signals

When a person is not addressable, advertising can still be relevant by using what the situation already reveals. Contextual signals describe the app and the moment: the category of the app, the format of the slot, the time of day, the general location the request is rooted in. None of them identifies a person.

Some decisions can also be made on the device, with the data staying on the phone. An advertiser's own app can recognise that a user has been away and prepare a message from information it already holds. Used this way, retargeting becomes an inference made locally, with nothing sent to a third party.

These methods reach less precisely than a device match. They have the advantage of working for everyone, including the many people who have declined tracking.

First-party channels beside paid retargeting

The person who declined tracking in an advertiser's app has not left the relationship. The advertiser may still hold a push permission, an email address given at sign-up, or the ability to show messages while the app is open. These are first-party channels: the person dealt with the advertiser directly, and no outside identifier is involved.

• Push notifications reach people who have installed the app and granted notifications. They cost little to send and fit a message tied to something the person did.
• Email reaches people who shared an address and works well for longer gaps and uninstalled users.
• In-app messages reach only people who are already inside, so they suit offers and nudges for people who are around but not fully engaged.

Paid retargeting then covers what these cannot: people who turned off notifications, who never shared an address, or who have removed the app. The strongest plans treat first-party channels and paid reach as one programme, with suppression shared between them so a person is not pursued twice.

Planning iOS and Android budgets

The two platforms differ in what can be done, and the budget should follow the difference rather than assume the two behave alike.

On Android, the advertising ID is available by default and can be cleared or deleted by the person at any time. Where it is present and consent has been given, device-level matching can work in the way it always did, and reporting is more detailed. On iOS, the addressable portion is limited to people who have granted permission in both apps, and measurement is aggregate.

Three habits follow. Measure each platform on its own, with its own holdout, since a blended number hides a difference that matters. Expect to reach fewer people with identity on iOS and plan the rest through context and first-party channels. And judge iOS on lift and on cost per incremental result. Attributed events are fewer and later by design, so their volume is a poor yardstick.

Privacy Sandbox on Android

Google has been developing Privacy Sandbox on Android as a set of proposals for advertising that avoids cross-app identifiers, including approaches to measurement and to interest-based reach. The direction is toward less device-level matching on Android as well. The details, the timing and the extent of adoption have shifted before and may shift again.

The sensible stance is to watch it and to wait before committing to it. Build the capabilities that serve every outcome: lift measurement that needs no identity, first-party channels, contextual relevance and consent checks on each request. A programme built that way adapts to whatever the platforms decide.