The ATT Prompt: Why Your iOS Numbers Are Incomplete By Design

The short version

App Tracking Transparency is the iOS system dialog asking permission to track a user across other companies' apps and websites. Whether a user accepts determines what measurement is available for them.

Granted. The device advertising identifier is available, and conventional cross-app attribution works for that user.
Denied. The identifier is unavailable. Measurement falls back to privacy-preserving attribution such as SKAdNetwork.

What ATT does not govern is your own first-party measurement. Understanding what a user does inside your own app is a different question from tracking them across other companies' properties.

Why the opt-in rate matters more than it appears

Every denied prompt moves a user into the coarse, delayed path. That means user-level attribution is unavailable, long-window LTV analysis at user level is unavailable, and audience building from that user's behavior is constrained.

But the point teams underestimate is this: the missing data is not evenly distributed. It correlates with who declines, which means the users you can measure are not a representative sample of the users you acquired. iOS reporting is not noisy — it is systematically incomplete.

The first ask is effectively the only ask

A declined prompt cannot be re-asked from within the app. The user has to change it in system settings, which almost nobody does.

That makes prompt timing a decision worth making deliberately rather than by default. The system dialog itself is fixed and cannot be altered; what you control is the context around it.

Timing. Asking before the user has experienced any value produces a predictable refusal. Asking after they understand what the app does is a different question.
Priming. An explanatory screen before the system prompt can set context, provided it does not misrepresent what the permission does.
Honesty of framing. Overstating benefit or obscuring purpose damages trust and can create policy exposure.

What this means for reading campaigns

iOS reporting is incomplete by design, and the incompleteness is not random.
Comparing iOS and Android performance directly compares two measurement regimes, not two audiences.
A drop in reported iOS conversions may reflect measurement rather than performance.
Trends within iOS over time are more reliable than iOS versus Android at a point in time.

Reading the patterns

iOS reported conversions well below Android, similar spend. Usually measurement rather than performance. Check the privacy-preserving path before concluding the channel is weak.

Reported iOS performance drops after a release. Check whether prompt timing or the priming screen changed before investigating campaigns.

Platform and MMP iOS numbers diverging further over time. Expected as the share of unmeasured users shifts. Track the gap rather than trying to close it.

Where this shows up in Playad

ATT is an app-side setting rather than a Playad surface. Its consequences appear in the measurement data: when an MMP is connected, cohort and SKAN views in Dashboards reflect what the privacy-preserving path can supply.

Common mistakes

Asking for permission on first launch, before the user knows what the app is.
Treating denied users as lost rather than as measured differently.
Comparing iOS and Android performance without accounting for the measurement difference.
Misrepresenting the permission in a priming screen.
Reading incomplete iOS data as a performance decline.

Practical rule

Ask after the user has experienced value, never on first launch, and read iOS performance as a trend within iOS rather than against Android. Plan measurement on the assumption that a meaningful share of users will decline.