What AppsFlyer Collects

The AppsFlyer SDK initializes a session as soon as the host app starts and, by default, collects a bundle of identifiers and contextual signals: the device-level advertising identifier (IDFA on iOS, GAID on Android), the vendor-scoped IDFV on iOS, a generated AppsFlyer install ID that persists across sessions, IP address (used for geo-IP and for fingerprint-style probabilistic matching), user agent, device model, OS version, carrier, and timezone. After install the SDK reports the install event to AppsFlyer's servers, where it is matched against the click data forwarded by ad networks. Subsequent in-app events — Purchase, RegistrationComplete, Tutorial Complete, Custom — fire through the same SDK and inherit the same identifier set.

Regulators have been explicit that this is processing of personal data under the GDPR. The IDFA and GAID are personal data because they are persistent device-level identifiers. The probabilistic fingerprint matching that runs alongside is even harder to defend without consent because it is, by definition, an attempt to identify a user without their explicit cooperation. The CNIL, the Italian Garante, and the Spanish AEPD have all opened investigations against publishers whose attribution stacks fired before consent.

Native AppsFlyer Privacy Controls

AppsFlyer exposes a meaningful set of native privacy primitives. They are not a substitute for a real consent framework, but understanding them is essential because they are the levers a CMP uses to control SDK behavior.

The Start SDK API

The SDK supports an initialization mode where it is configured but does not transmit any data until start() is explicitly called. This is the single most important hook for consent gating — by default the SDK starts automatically on app launch, which is the wrong behavior for any jurisdiction with a prior-consent requirement. Set isStopped to true at initialization, or use the deferred-start API, and only call start() when the consent signal is recorded.

Stop API

If consent is withdrawn mid-session, calling stop() halts all further transmission. It does not retroactively delete data already sent. For full deletion you need to file a data subject deletion request through AppsFlyer's privacy portal — an integration teams should automate via the AppsFlyer API rather than a manual workflow.

setSharingFilter

This filters which downstream ad networks receive postback data. It is the right primitive for granular per-partner consent — for example, allowing attribution generally but blocking forwards to a specific network the user has rejected.

Apple App Tracking Transparency integration

On iOS, AppsFlyer reads the ATT authorization status and adjusts its behavior automatically — if the user declined ATT, IDFA is not transmitted. ATT is independent from GDPR consent, and many publishers conflate them. ATT controls a single iOS-level signal; GDPR consent controls everything else.

Integration on iOS

The reliable pattern on iOS is to install the AppsFlyer SDK but defer initialization until both ATT and the in-app consent flow have completed. The minimal sequence is: app launches, the SDK is configured with isStopped = true, the in-app consent banner displays, the user accepts the relevant categories, the SDK's isStopped flag is cleared and start() is called. If the app also needs ATT (which it does for any user where IDFA is meaningful), the ATT prompt is shown alongside or after the in-app banner. Most CMPs that support mobile have a callback-based API that delivers the consent decision; that callback is the right place to call start().

Integration on Android

The Android implementation parallels iOS with two differences. First, there is no ATT equivalent — GAID is available unless the user has invoked their device-level "Delete advertising ID" setting, which most users do not. Second, Android's lifecycle is more aggressive about backgrounding, so the SDK initialization needs to be tied to the consent state stored persistently. Read the consent state from local storage at app launch, configure the SDK accordingly, and re-check on resume in case the user updated their choice while the app was backgrounded.

Integration on the Mobile Web

AppsFlyer also operates on the mobile web through its smart banner and OneLink products. These are essentially web-side analytics and deep-link tools that drop cookies and call AppsFlyer servers from the browser. They follow the same rules as any other web tracking surface: gate them behind the CMP's marketing category, do not let the smart banner script run before consent is granted, and ensure that any OneLink-triggered events from email or push campaigns honor the user's consent state.

Common Pitfalls

Four integration mistakes show up repeatedly in audits of AppsFlyer deployments.

Treating ATT as GDPR consent

ATT and GDPR consent are different signals with different scopes. A user who accepts ATT has authorized IDFA use for cross-app tracking; they have not authorized everything else the SDK does. For EU and UK traffic both signals are required, with the in-app banner being the binding one and ATT being a iOS-specific layer on top.

Letting the SDK initialize on launch

This is the most common single defect. The default integration calls start() immediately, which fires the install event with full identifier payload before the user has seen the consent banner. The remediation is straightforward: configure isStopped = true at integration time and call start() only from the consent callback.

Forgetting to handle withdrawal

If a user accepts and later revokes, the SDK needs to be told to stop transmitting. Use the stop() API and update the persisted consent state so the next app launch respects the new decision.

Ignoring server-to-server postbacks

AppsFlyer forwards conversion events to a long tail of integrated ad networks via server-side postbacks. Each forward carries personal data and inherits the consent scope of the original event. Use setSharingFilter to ensure that forwards only go to partners covered by the user's consent choices, not to every partner in your AppsFlyer dashboard.

Audit Checklist

Six concrete questions to answer for any AppsFlyer deployment touching EU, UK, or California traffic.

• Does the SDK wait for consent? On a fresh install in a EU-located test device, confirm no AppsFlyer endpoint receives any request before the user has accepted the banner.
• Is ATT separated from in-app consent? Confirm the in-app banner is the controlling consent signal and ATT is treated as an additional iOS-specific layer.
• Is partner forwarding scoped to consent? Confirm setSharingFilter is configured to exclude partners the user has not authorized.
• Does withdrawal halt the SDK? Confirm calling stop() works on consent revocation and that the new state persists across launches.
• Are server postbacks audited? Confirm the AppsFlyer dashboard's "Configured integrations" list maps cleanly to the marketing partners disclosed in the banner.
• Is data deletion automated? Confirm DSAR requests trigger AppsFlyer's deletion API, not a manual ticket.

Where AppsFlyer Fits in a Consent-First Stack

Mobile attribution is one of the most identifier-heavy surfaces in the marketing stack, and AppsFlyer's SDK is one of its most consequential single integrations. The good news is that the platform exposes the primitives — Start SDK, Stop, sharing filters, deletion APIs — needed to make consent enforcement clean and verifiable. The work for publishers is to wire those primitives to a CMP that owns the binding consent decision, treat ATT as a complementary signal rather than a replacement, and make sure server-side partner forwarding cannot escape the consent envelope the banner recorded. Done correctly, the result is an attribution stack that satisfies regulators while preserving the install and event data user acquisition teams depend on.