What is the impact of App Tracking Transparency (ATT) on tracking?

Apple’s App Tracking Transparency (ATT), introduced in iOS 14, requires user consent to track activity across other companies’ apps and websites. In Piano Analytics, the impact of ATT depends primarily on which visitor identifier you have configured in the SDK.

Summary of impact (based on your SDK identifier)

• If you use UUID or IDFV as your visitor identifier, you are not affected by ATT, because these identifiers are not advertising identifiers.

• If you use IDFA (Apple’s advertising identifier), iOS 14+ causes a significant (but gradual) decrease in measurable, deduplicated traffic as users update their OS and choose not to allow tracking.

Why metrics can shift after ATT (even if overall traffic is stable)

When users refuse ATT, an advertising identifier such as IDFA is not available. Without a stable identifier, Piano Analytics may be unable to deduplicate visits to a single visitor, which can lead to changes such as:

• A decrease in “visits per visitor” (the same person may be counted as multiple visitors over time)

• An apparent increase in unique visitors, while overall traffic volume remains similar

This is especially visible in visitor-centric metrics (for example, app “new visitors” type metrics).

Identifier options and their behavior under ATT

IDFA (Identifier for Advertisers)

• Intended for advertising use cases.

• When a user refuses ATT, IDFA becomes unavailable.

• In that situation, the SDK will, by default, treat the user as OPT-OUT, which reduces measurement capabilities.

Because IDFA is dedicated to advertising, it also represents additional legal/compliance risk (Apple/Google provide the identifier but do not assume responsibility for how it is used). Additionally, ATT opt-in rates are typically low, making IDFA unavailable in the majority of cases.

UUID (SDK-generated identifier)

• Generated by the SDK and not an advertising identifier.

• Not blocked by ATT in the same way as IDFA.

• Typically remains stable for an installation, and may change after:

  • an app reinstallation

  • a change of identifier type in the SDK configuration

  • an identifier renewal period (by default, UUID is renewed every 13 months; this duration can be adjusted depending on your SDK configuration)

Using UUID can allow measurement in an exempt mode when tracking is refused, provided that you respect all conditions set by applicable local authorities.

IDFV (Identifier for Vendor)

• Generated by Apple.

• Can allow identification across multiple apps from the same vendor.

• Not impacted by ATT in the same way as IDFA.

Recommended approach

Piano recommends using a non-advertising identifier such as UUID (or IDFV depending on your use case) rather than IDFA.

If you are currently using IDFA, expect a significant decrease in measurable traffic as iOS 14+ adoption increases and users refuse tracking. Switching to UUID/IDFV mitigates this.

ignoreLimitedAdTracking: fallback from IDFA/AAID to UUID

The SDK includes a sub-option called ignoreLimitedAdTracking. When enabled, this behaves as follows:

• If IDFA/AAID is unavailable (for example, due to tracking refusal / limited ad tracking), the SDK can fall back to UUID instead of forcing an OPT-OUT situation.

• This helps you maintain visitor measurement (typically in exempt mode) when users refuse advertising tracking, assuming you meet the applicable regulatory requirements.

If you want the SDK to avoid losing measurement due to advertising identifier restrictions, enable ignoreLimitedAdTracking and verify that your identifier strategy is consistent with your privacy/compliance posture.