Select in what class to start the SDK

Select whether to start the SDK in the global Application class or the Activity class:

• Start the SDK in the global Application class: Generally, initializing the SDK in the global Application class/subclass is a good practice because the Application class is loaded and initialized before any app UI is displayed. This ensures that the SDK can start in any scenario, including deep linking.
• Start the SDK in an Activity class (deferred start) to allow users to opt-in to data sharing. This is because obtaining user consent requires a user interface (UI) rendered in an Activity class.

Select the opt-out/in scenario

Select an opt-out scenario outlining how to call start in a way that complies with privacy regulations such as GDPR and CCPA. For example, select between Opt-out at installation scenario, one-time opt-out scenario, or preventing data sharing with third parties scenario.

For more information on the opt-out scenarios available, including code samples, see Opt-in and Opt-out scenarios.

Android developer instructions

• Inform the developer of your decision on the following:
  • In what class - Application or Activity - to start the SDK?
  • Which opt-in/opt-out scenario to use?
• Send your developer the following reference links:
  • How to perform deferred start
  • Common opt-out and opt-in scenarios
  • Opt-out code samples

An AppsFlyer ID is automatically created for every new app install. No action is required by the marketer.

You can use this identifier to perform the following actions:

• Send server-to-server in-app events.
• Match the AppsFlyer ID with user records in your backend systems.
• Download the raw data in-app event report and use appsflyer_id to analyze user behavior and journeys.

Set your own Customer user ID (CUID) in the AppsFlyer SDK to cross-reference the unique ID from your BI system with the AppsFlyer ID and other identifiers. The CUID is available in AppsFlyer raw data reports. You can also use it in postback APIs for cross-referencing with your internal IDs. 

To learn more about CUID, see this article.

Google Play Install Referrer

The Google Play Install Referrer API improves attribution accuracy, protects from install fraud, and allows secure retrieval of referral data from Google Play (for example, the app's version at the time when the app was first installed). 

It is recommended that you provide your developer with instructions to add the Google Play Install Referrer API. 

GAID

Starting with SDK V4.8.0, AppsFlyer automatically collects this device identifier.

With AppsFlyer, you can attribute installs originating from third-party app stores, such as Amazon, Opera, GetJar, Baidu, and Huawei. This allows you to promote your apps and reach larger audiences in markets where Google Play Store is not available.

AppsFlyer supports attribution in the context of third-party app stores as follows:

• IMEI or Android ID: The SDK doesn't automatically collect the IMEI or Android ID. However, if there is a need to collect these identifiers (for example, for apps in the Chinese domestic market) your developer can implement one of the following collection types:
  • Manual collection: The app passes the IMEI or Android ID to the SDK (using the setImeiData or setAndroidIdData API). The SDK sends the data to AppsFlyer servers. 
  • Opt-in to device ID collection: Forces the SDK to collect the IMEI or Android ID. 
• OAID: Attributes installs from third-party Android app stores. For more information, see the guide to implementing OAID.
• Install referrers: The SDK supports retrieval of referral data from Samsung Gallery and Huawei AppGallery.

Background

Starting with iOS 14.5, IDFA collection requires user consent. Practically, it means IDFA access is governed by the App Tracking Transparency (ATT) framework. On iOS 14+ devices, the SDK uses the ATT framework to obtain access to the device IDFA. 

For an introduction to ATT, see ATT principles.

When attribution occurs using IDFA, it's important IDFA is sent on the first launch. For this reason, the SDK provides the waitForATTUserAuthorization utility.

waitForATTUserAuthorization overview

waitForATTUserAuthorization enables you to configure how long the SDK should defer and wait for ATT status before sending data to the AppsFlyer servers.

When a user launches the app, ATT status is notDetermined. During the waitForATTUserAuthorization timeout, the SDK queues the launch event and consecutive in-app events in-memory, similar to the way in which offline events are recorded:

• If the user consents to the ATT prompt (IDFA collection):
  • The SDK adds the IDFA to cached events.
  • The SDK starts and sends cached events with IDFA (without waiting for the timeout to end).
• If the user declines the ATT prompt: The SDK starts and sends cached events without IDFA (without waiting for the timeout to end).
• If the timeout ends and ATT status remains notDetermined: The SDK starts and sends cached events without IDFA.

Considerations

• Calling requestTrackingAuthorization without setting waitForATTUserAuthorization will result in launches and events being sent without IDFA for iOS 14+ devices.
• If the user moves the app to the background during the timeout:
  • The timer pauses until the app returns to the foreground.
  • Events are cached in-memory.
• If the user shuts down the app, it is killed during the timeout:
  • The timer is restarted on the next app launch.
  • Cached events are lost.

You can customize the ATT prompt. A message that clearly states the purpose of the request could help increase the opt-in rates for users.

Consider the following when creating your message:

• Use wording that best explains to your users why the app is asking for user consent.
• Inform users about how their data will be used. Learn more about user privacy and data use.

Once your message is complete, provide your developer with the text and implementation instructions.

See some external examples of ATT prompts.

SKAN is a class used by iOS to validate advertiser-driven app installations. The app install validation process involves the source app and the advertised app. 

A source app is an app that participates in ad campaigns by displaying ads from an ad network. Configuring your app to display ads is not within the scope of the AppsFlyer SDK. To configure, follow the Apple instructions.

For the advertised app (the app with the AppsFlyer SDK), the AppsFlyer SKAN solution uses SKAN to provide the attribution postback while AppsFlyer collects, translates, and aggregates the data while maintaining user privacy. When the app is launched for the first time, the AppsFlyer platform uses the configuration set by the marketer to instruct the SDK how to set the SKAN conversion value.

To use the SKAN solution:

• The marketer needs to configure SKAN measurement in AppsFlyer. The developer does not have to perform any tasks.
• The AppsFlyer SDK automatically calls the necessary SKAN APIs.
• Make sure to disable SKAN calls in other SDKs if you rely on AppsFlyer for SKAN attribution.
• There is no other action or registration process required by either the developer or the marketer in the App Store. 

To disable SKAN attribution, instruct your developer to disable it in the SDK. 

You can send revenue with any in-app event. Make sure you use the af_revenue parameter to include revenue. It is the only event parameter that AppsFlyer counts as real revenue on the dashboard and in raw data reports. Learn more.

For developer instructions, see logging revenue.

The AppsFlyer SDK provides server verification for in-app purchases. Validating an in-app purchase automatically sends an in-app purchase event to AppsFlyer. Sending this event yourself creates duplicate event reporting.

See our list of recommended in-app events per vertical, for example, travel, gaming, or eCommerce.

For users without your app installed, OneLink detects the device type and redirects them to the correct destination (for example, Google Play, Apple App Store, third-party app store, or web page). This is based on your OneLink template settings. Learn more

For users with your app installed, OneLink opens the app. In addition to opening the app, you can also deep link users to a specific activity or page within the app. This requires your developer to implement Unified Deep Linking (UDL).

Note:

• UDL requires SDK V6.1+.
• Customers already using OneLink for deep linking may be using the legacy method, instead of UDL.

See our guide on setting Deep linking and deferred deep linking.

For users without your app installed, OneLink detects the device type and redirects them to the correct destination: Google Play, Apple App Store, third-party app store, or web page. Once the user launches the app, you can use deferred deep linking to redirect them to a specific activity or page within the app.

This requires your developer to implement extended deferred deep linking.

Note:

• UDL requires SDK V6.1+.
• Customers already using OneLink for deferred deep linking might be using the legacy method, instead of UDL.

See our guide on setting Deep linking and deferred deep linking.