AppsFlyer and Apple ATT: review attribution and tracking

Start with your attribution design

AppsFlyer supports mobile measurement and attribution, but an SDK selection does not describe your complete data flow. Your integration may process device or advertising identifiers, campaign attribution, in-app events, or your own customer user ID. Consent state, ATT behavior, partner configuration, and privacy-preserving modes can change what is available in the published app.

Map the production flow before making an ATT decision. Identify the AppsFlyer SDK version, initialization options, conversion-value or privacy settings, partner integrations, and event calls in the iOS release build. Check when the SDK starts, what happens before and after the ATT prompt, and whether a server sends additional identifiers or event data.

Declora organizes this review in an App Passport with App Facts. The AppsFlyer Service Profile suggests attribution analytics as likely, device identifiers and advertising identifiers as possible, and cross-app tracking as configuration-dependent. Those suggestions help you find questions; you confirm the App Facts against your production configuration. Declora does not decide your ATT response for you.

Separate attribution from tracking

Apple's tracking concept focuses on linking data about a user or device with data from third-party apps or websites for advertising or measurement purposes. Attribution alone does not answer that question. Review the purpose, recipients, identifiers, and linkage in your actual integration instead of treating every marketing measurement flow as identical.

Ask who receives the identifier, what other-company data it can be combined with, and why the link is made. Check AppsFlyer partner settings, campaign measurement, retargeting or audience features, and any advertising SDKs that share identifiers. If the integration measures installs for your own campaigns without cross-app linkage, that fact still needs a careful review, but it is not settled by the SDK name.

Keep an App Fact for cross-app tracking separate from facts about device identifiers and advertising identifiers. You can know that an identifier may be processed without knowing whether your production flow uses it for Apple's defined tracking purpose. You can also have in-app event data without using it for cross-app measurement.

Review identifiers and events

Inspect the identifiers your app makes available to AppsFlyer. Depending on configuration, this can include a device identifier, an advertising identifier, an AppsFlyer identifier, or a customer user ID supplied by your account system. Confirm which values are collected, when they are sent, and whether they are reset or withheld after a user changes consent.

In-app events are developer-defined. Review event names and parameters for purchases, sign-ups, subscriptions, content views, and custom values. A marketing event can include an account ID, email, phone number, or free-form metadata if your code adds it. Search shared event helpers and server-side forwarding paths, not only the screen where the event originates.

Test with synthetic values in a production-like build. Capture the sequence before consent, after consent, and after a user declines where your implementation supports those states. Inspect logs and dashboards for the fields that actually arrive. Record evidence for each App Fact, and do not infer that a field is absent merely because it is not visible in one dashboard view.

Consent and ATT are implementation details

The ATT prompt is one part of the decision, not a substitute for reviewing your data flow. Confirm when your app requests authorization, which SDKs initialize before the response, what happens after denial, and whether your configuration changes identifier access or partner sharing. Review the user-facing explanation your app provides and keep it consistent with the behavior of the release build.

If your team uses privacy-preserving attribution features, inspect their settings and the events they support. Do not assume that a privacy mode means every identifier or every partner path is disabled. Likewise, do not assume that a user granting permission makes every data use acceptable; the purpose and linkage still need to match your reviewed implementation.

If a fact is unclear, leave it awaiting confirmation in Safe Mode and ask the owner of the attribution setup to verify it. Catalog guidance is a suggestion with evidence, not a declaration or a legal conclusion.

A practical AppsFlyer and ATT review sequence

1. Identify the AppsFlyer SDK version, initialization path, partner settings, and privacy controls in the iOS release build.
2. Inventory device identifiers, advertising identifiers, AppsFlyer identifiers, customer user IDs, and event parameters.
3. Trace when data is sent relative to ATT authorization, denial, sign-out, and consent changes.
4. Test representative attribution and in-app events using synthetic values.
5. Inspect recipient and partner paths for cross-app or cross-company linkage used for advertising or measurement.
6. Confirm separate App Facts for identifiers, events, consent behavior, and tracking purpose.
7. Compare the confirmed facts with your ATT implementation and run a Consistency Check before release.

When configuration changes, repeat the review. Adding a partner, enabling retargeting, forwarding a new event, or changing initialization timing can alter the facts even if the app's visible screens stay the same.

Public Pages and responsible decisions

Public Pages can help your team communicate the reviewed data flow using confirmed App Facts. They do not replace Apple's ATT requirements, your consent implementation, or an examination of AppsFlyer events and partner settings. Keep the explanation current with the release version it describes.

Declora is not a law firm and cannot guarantee store approval. Its App Passport, App Facts, Public Pages, Safe Mode, and Consistency Check help you organize evidence and surface mismatches; you remain responsible for confirming production behavior and making the final ATT and store decisions.

FAQ

Does using AppsFlyer automatically require the ATT prompt?

Not automatically. Review whether your production integration links user or device data with data from other companies' apps or websites for advertising or measurement purposes. The SDK name alone cannot settle that question; confirm the tracking App Fact against your configuration.

Are attribution identifiers and tracking the same thing?

No. An identifier may be processed for attribution without establishing Apple's defined tracking use, while a tracking decision requires a review of linkage and purpose. Confirm identifier collection and cross-app purpose as separate App Facts.

What should I inspect if the ATT behavior changed after an SDK update?

Compare initialization timing, identifier access, consent handling, partner settings, event forwarding, and privacy-preserving options in the new release build. Run controlled tests before and after authorization states, then update the App Facts supported by the evidence.

Can Declora guarantee the result of an Apple review?

No. Declora is not a law firm and cannot guarantee store approval. It helps structure confirmed App Facts and run a Consistency Check, while you make the final implementation and submission decisions.