ATT Signal Processing (iOS)

ATT Signal Processing (iOS)

Apple's App Tracking Transparency (ATT) framework gives users control over whether apps may track them across other apps and websites. Because ID5 integrates via server-to-server (S2S), it processes only the data and signals that publishers route to our endpoint; ID5 does not independently access device-level ATT status. Publishers therefore retain full control over how ATT authorisation interacts with identity processing and must configure their integration to reflect their specific platform obligations.

Signal Processing Hierarchy

ID5 evaluates consent signals only where no opt-out has been detected. Where a user is not opted out, signals are evaluated in the following order of precedence:

1. Consent string — if a valid consent string is present in the request (IAB TCF, GPP, or ID5 Allowed Vendors), ID5 uses this as the primary basis for ID generation.
2. ATT signal — where no valid consent string is available, ID5 falls back to the device-level ATT authorisation passed via the att parameter

ID5 requires either a valid consent string or positive iOS device-level authorisation to generate and transmit an ID5 ID.

Passing the ATT Parameter

Publishers should retrieve the user's ATT authorisation status using Apple's AppTrackingTransparency framework and map it to ID5's att parameter before sending requests to the ID5 endpoint.

The att field should be used for iOS requests only, It's the iOS equivalent of GAID (Google Advertising ID) on Android, or RIDA on Roku.

See the Mobile In-App Integration page for full details on the att parameter.

Enforcing a Hard Stop on Denied ATT

To ensure that a denied ATT signal always blocks ID generation regardless of CMP consent, configure your integration to drop the call to the ID5 ID endpoint when a user denies ATT authorisation.