Test mobile SDK integration with the app – Help Center

At a glance: Test your Android/iOS app integration with AppsFlyer.

Testing and debugging the SDK integration

Test SDK integration before submitting an app to the app store. In this article, SDK refers to both the AppsFlyer iOS and Android SDKs.

Special cases of testing and debugging

Smart TV: The SDK is compatible with Android-based Smart TVs and Apple TV (tvOS). Test smart TV apps using the instruction in this guide.
Unpublished tvOS apps: see Testing tvOS integration before publishing.
Amazon Fire TV: see Testing alternate Android stores.

Why should I debug and test?

Carefully tested integration ensures accurate and comprehensive data collection. By testing the SDK integration, you ensure that installs and in-app events are recorded and attributed correctly.

Testing and debugging SDK integration

Use one of the following methods to test and debug SDK integration:

Basic testing:
- Testing the integration using attribution links.
- The AppsFlyer attribution model utilizes attribution links. Conducting tests using attribution links is recommended.
- When you test SDK integration using attribution links you get an in-depth insight into the AppsFlyer attribution model. This gives you the opportunity to optimize your marketing operation and analysis.
Advanced testing:
- Debugging directly from the development environment.
- The SDK integration test section only tests a limited set of features. Test the following in the development environment using the debug log:
  - Purchase validation
  - Conversion data
  - Errors in SDK setup. You can test these in the development environment with the help of the debug log.

Related reading for ad networks: Ad network integration testing.

Using the SDK Integration Tests page, to locate integration issues in your project. Use it to test installs, in-app events, and deep linking.

Testing SDK integration

To test SDK integration:

Prepare a device (iOS or Android) that does not have the app installed. If needed, uninstall the app from the device.
Register the device as a test device.
In the dashboard, select the app.
Go to Integration > SDK Integration Tests.
The SDK integration tests page opens.
Select a testing option:
- Non-organic installs
- In-app events
- Deep linking
Use the testing procedure that follows according to the selected test type.

Testing organic installs

Install the app on a registered test device.
Launch the app.
The app dashboard displays a new organic install.

Testing non-organic installs

Select Non-organic install.
Select a listed device.
Select the app source:
- Android:
  - Google Play
  - Other (Out-of-store, Android Studio, .APK file, etc.)
- iOS:
  - App Store
  - Other (XCode, TestFlight, etc.)
Scan the QR code with the registered test device and follow the instructions on the device.
Wait until the non-organic install is registered on the SDK Integration Tests page indicating the test is successful. This can take up to 2 minutes.
If the app does not record a non-organic install by that time, see the troubleshooting section that appears on the SDK Integration Tests page.

To test LAT installs:

Enable LAT mode on your device.
Perform a non-organic install test.

To test no ATT consent (without IDFA) installs:

In the ATT consent dialog, click Ask App Not to Track.
Perform a non-organic install test.

Testing in-app events

Click on Run test under In-app events.
Select a registered test device from the drop-down menu, click Next.
Launch your app and start generating in-app events.
You will see a log of these events as they are registered in real-time.

Testing deep links

OneLink must be defined for your app in order to test deep linking. See our OneLink guide here. It is important to note that the SDK Deep Linking implementation is highly recommended, as outlined in the deep linking integration guide.
Verify that the retargeting is turned on.
Click on Run test under Deep linking.
Select a registered test device from the drop-down menu and click Next.
Select Test Type:
- OneLink - Select the OneLink you want to test from the Select a OneLink dropdown.
- URI scheme - specify the URI scheme that you want to test. For example, greatapps://cars.
Scan the QR code with your registered test device and follow the instructions on your device.
After these two tests are completed, the Deep Linking Test is registered as successful.

Testing the SDK integration using debug apps

When performing tests using attribution links, data is recorded in the app dashboard. Once data is recorded, it can't be deleted. If you don't want test data to be recorded as part of a real app, you can test the SDK integration using debug apps.

If you do not require a test app, or if you are not concerned about mixing test data and real data, skip this section.

Debug apps are exact copies of apps that are published in the app stores. By running SDK integration tests on debug apps, you don't pollute real data with test data.

Debug apps differ from production apps in that they:

Have a different app ID
Have their own dashboard
Are not published in app stores

Creating an Android test app

Duplicating your Android app

Make a copy of the Android project folder and rename it.
Open the newly copied project in Android studio.
In Android Studio, expand the folders until you reach the package.
Right-click on the package name, choose Refactor and then Rename.
Rename the package.
In the app-level build.grade change the applicationId to the new package name.

Add the Android test app to AppsFlyer

Follow the instructions to add a new app to your AppsFlyer dashboard. Make sure that the package name is the same as the package name of the newly created test app, and not the original app's package name. Also, make sure to set the app status to Pending approval or unpublished.

You can now run tests on the new test app.

Creating an iOS test app

Add the iOS test app to your AppsFlyer dashboard.
Follow the instructions to add a new app to your AppsFlyer dashboard. Make sure to set the app status to Pending approval or Unpublished.

In the AppDelegate class, inside didFinishLaunchingWithOptions add the following code:

bool isDebugApplication = false;
...
if(isDebugApplication) {
    [AppsFlyerLib shared].isDebug = isDebugApplication;
    [AppsFlyerLib shared].appleAppID = @"11111xxxx"; // Testing app ID
  } else {
    [AppsFlyerLib shared].appleAppID = @"PROD_APP_ID"; // Production app ID
  }

var isDebugApplication = false
...
if(isDebugApplication) {
      AppsFlyerLib.shared().isDebug = isDebugApplication
      AppsFlyerLib.shared().appleAppID = "1111xxxx" // Testing app ID
    } else {
      AppsFlyerLib.shared().appleAppID = "PROD APP ID" // Production app ID
    }}

Note

The app ID is the ID that is given to the app once it is published to the app store. However, since this is a test app, you can give it whatever ID you want as long as it is not taken by another app. The format should be 11111****. For example, 111117538.

Make sure the ID is 9 digits. Start the id with four 1s. The remaining digits should be random. See ID example above.

Tests using attribution links

This section demonstrates how to test the integration with the help of attribution links.

Before you begin:

Register devices that you use for testing.
When testing re-attributions, make sure to remove the registered device from the allowlist.
If you are testing attribution of apps available via third-party Android app stores you must set the af_r parameter on the attribution link to reference the specific app store.

You can test the SDK integration even if the app is still pending (meaning, not listed in Google Play or Apple Store)

Topics covered in this section:

Testing install attribution
Testing in-app events
Testing retargeting (re-attribution and re-engagement)

Testing install attribution

Testing installs allows you to determine that AppsFlyer SDK is able to correctly attribute installs to various media sources.

Step 1:

Copy the link below:

https://app.appsflyer.com/<app_id>?pid=Test&c=Test&advertising_id=<GAID>

https://app.appsflyer.com/<app_id>?pid=Test&c=Test&idfa=<IDFA>

Change the app_id parameter to your app id (including the id prefix. For example: id0123456789).

The c parameter specifies the name of the campaign.
The pid parameter specifies the name of the media source to which the install is attributed.
If you are testing an app available via a third-party Android store: add the af_r parameter to the attribution link.

If testing the click from a computer, add the GAID for Android (Google Advertising ID) or IDFA for iOS.

Step 2:

Copy the link, send it to the test device, and navigate to the link using the browser.

Note

In iOS, use iMessage or email to send the link to the device. Don't paste the link in the iOS Notes app and then click on it because it might break the link.

If the app is live, proceed to install.
If the app is pending, install the app from your development environment:
-- For Android - install from Android Studio or ADB shell
-- For iOS - install from XCode

Step 3:

Allow up to two minutes for the install to appear in the app's dashboard. You should see an install that is attributed to the media source Test under the campaign Test.

For more elaborate verification, download the installation raw data report:

In AppsFlyer, go to Reports > Export Data.
In the Raw Data Reports section download the Installation raw data report.

See our article about the installation raw data report for more information.

Testing in-app events

You can test in-app events to see that they show the revenue that is associated with them, and that they are attributed to the media source that generates the install.

After installing the app using the attribution link, trigger a few in-app events. Allow up to two minutes for the events to appear in the dashboard. Open the app's dashboard and go to Events in the left-hand side menu.

You should see the events, their revenue (if revenue is associated with them), and the media source with which they are associated.

For a more elaborate verification, you can download the in-app events raw data report.

In the app's dashboard click on Export Data under Reports. In the Raw Data Reports section download the In-App Event raw data report.

See our article about the in-app events raw data report for more information.

Testing OneLink

OneLink allows you to set a single attribution link for both iOS and Android. OneLink recognizes the user's device and redirects them to the relevant app store.

In addition, OneLink enables deep linking. Deep linking allows you to open the app in a specific app activity while serving customized content.

For more information, see our guide on testing OneLink URLs.

Testing retargeting

Prerequisites for testing retargeting

OneLink template - see OneLink template configuration
Enable retargeting in the app's settings.
In the app's dashboard, click on App Settings and turn on Enable Re-Targeting Campaign Measurement.

Android iOS
A non-registered device

Testing retargeting is straightforward. Create a custom attribution link out of a OneLink template. Make sure to turn on Re-Targeting Campaign.

Once the custom attribution link is ready the following screen appears where you can retrieve the long URL version:

Another way to retrieve the long URL version is through the Link Management page.

In the Link Management page, locate the attribution link.
On the right-hand side, click the three dots under Actions.
Click View Link Details.
Copy the Long Link.

Important!

When testing retargeting (re-attribution and re-engagement), the advertising ID must be specified in the attribution link URL.
Retargeting reinstalls (AKA re-attribution) can't be tested using registered test devices. Meaning, user devices which are listed in the test device list. You can use any other device for this purpose.
To view GAID or IDFA, follow the instructions in the registering a test device article. Note!

The final OneLink is as follows:

https://go.onelink.me/2rAD?pid=Test&c=Test&is_retargeting=true&advertising_id=<GAID>

https://go.onelink.me/2rAD?pid=Test&c=Test&is_retargeting=true&idfa=<IDFA>

Testing re-attribution

You can test re-attribution to verify that you can record installs of your app by users who reinstall the app after uninstalling it at some point in the past.

Make sure your test device is NOT registered.
If the app was just installed, wait for a few minutes.
Uninstall the app from the device.
Repeat the same steps for testing install attribution - use the OneLink format above.
Allow up to two minutes for the retargeted install to appear in the dashboard.
Open the app's dashboard and click on Re-Targeting in the left-hand side menu.
You should see the re-attributed install attributed to the media source Test under the campaign name Test.

For a more elaborate verification, you can download the conversions raw data report.

In the app's dashboard click on Export Data under Reports. In the Re-Targeting Reports section download the Conversions raw data report.

Testing re-engagement

Re-engagement occurs when a user who has the app installed, engages with a retargeting campaign and launches the app.

Testing re-engagement via app open

Re-engagement via app open means that the user is redirected to the app store where they are presented with an open app button. If they click the open button and launch the app, a re-engagement is recorded.

To test re-engagements, follow the steps below:

Make sure the app is installed on your test device and has been launched several times.
If the app was just installed, wait for a few minutes.
Use the same OneLink as used for testing re-attribution.
Add the device ID to the link and send it to your mobile device.
Navigate to the link using a browser.
Manually open the app via the Open button in the store or from the device launchpad.

You should see a re-engagement attributed to the media source Test under the campaign name Test.

Testing re-engagement via deep linking

Re-engagement via deep linking allows you to have the app launched immediately after the user clicks the attribution link. The benefits of using re-engagement with deep linking:

Better user experience - the user is not redirected to the store and the app launches automatically
Better campaigns - you can have a specific campaign-related activity open up and this way maximize the results of the retargeting campaign

You can test re-engagement attribution using deep linking. It is the same procedure as testing re-engagement with an attribution link. The only difference is that the attribution link contains a parameter af_dp that redirects the user to a specific activity in the app.

To test re-engagements using deep linking, follow the steps below:

Make sure to configure your app for deep linking.
Make sure the app is installed on your test device and has been launched several times.
If the app was just installed, wait for a few minutes.
Generate a retargeting link with the device ID.
Add the af_dp parameter and to it add the schema that you configured in step 1.
Navigate to the link using a browser.
If the app is installed, the link launches the app in the activity that is specified in the link.

You should see a re-engagement attributed to the media source Test under the campaign name Test.

For more information follow our guide on Testing Deeplinking.

Additional ways to test the SDK integration

There are two additional ways to test the SDK integration:

This section demonstrates how to debug the SDK integration. Reference this section to conduct advanced testing and to troubleshoot issues with integrating the SDK.

Debugging for Android

Debugging the SDK gives you an in-depth perspective of how it integrates with your app. Debugging helps you solve issues with in-app event recording, conversion data, and purchase validation.

Enabling Android SDK debug mode

To start debugging the Android SDK, add the following line to the AFApplication class:

AppsFlyerLib.getInstance().setDebugLog(true);

Warning!

Debugging should be restricted to development phase only. Do not distribute the app to app stores with debugging enabled. This poses major security and privacy risks.

Viewing debug output

To view the debug output, open the Logcat terminal in Android studio. Choose the application package name as the debuggable process, set the log level to Debug, and filter by "AppsFlyer_".

Troubleshooting common issues with Android SDK

Install always attributed to organic

Scenario

You are testing attribution using attribution links. You've implemented the SDK conversion listener but the log always shows that the install is organic. In addition, no non-organic install is recorded in the dashboard.

Possible reasons

Your dev key is incorrect - if you specify an incorrect dev key, the install cannot be attributed.
The attribution link you are using is incorrect. See our guide on attribution links.
Make sure that the device you are testing on is registered.
A non-proper channel is defined in the manifest

Install not detected or attributed

Scenario

You are testing install attribution but the log doesn't show any data about the install such as type, first launch, etc.

Possible reasons

Make sure that the startTracking and init methods are called in the AFApplication class.
Make sure that the device you are testing on is registered.

I'm getting a 404 on install or event recording

Scenario

You are testing in-app events to see that they are attributed to the correct media source. However, the log shows response 404 for both the install and when you send in-app events. Neither the install nor the in-app events appear in the dashboard.

Possible reasons

A 404 response indicates that the app ID is incorrect. Make sure that the app ID in the applicationId parameter in the build.gradle file is the same as the one in your dashboard.

Revenue is not recorded properly

Scenario

You are testing in-app events with revenue. The events appear in the dashboard but revenue is not recorded

Possible reasons

The revenue parameter is not formatted correctly. Do NOT format the revenue value in any way. It should not contain comma separators, currency sign, or text. A revenue event should be similar to 1234.56, for example.

The log shows "AppsFlyer's SDK cannot send any event without providing devkey" when I test in-app events

Scenario

You are trying to see in-app events in the log. When you trigger events the log only shows "AppsFlyer's SDK cannot send any event without providing DevKey".

Possible reasons

You call the startTracking method without passing the dev key as a parameter. Pass the dev key to the method.

The log shows "not sending data yet, waiting for dev key" in the log when I test in-app events

Scenario

You are trying to test in-app events in the log. When you trigger events the log only shows "Not sending data yet, waiting for dev key".

Possible reasons

You call the init and you pass the dev key as an empty string. Pass the dev key to the method.

I get response 400 when I test in-app events

Scenario

You are trying to test in-app events in the log. When you trigger events you see response 400 in the logs.

Possible reasons

This might indicate an issue with the dev key. Check that the dev key is the correct one. Also, make sure that the dev key contains only alphanumeric characters.

The log shows "warning: Google play services is missing"

Scenario

The logcat shows the warning message "WARNING: Google Play Services is missing".

Possible reasons

The app is missing the Google Play Services dependencies. This might prevent the SDK from collecting the GAID which might cause issues with attribution.

Add the following lines

implementation 'com.google.android.gms:play-services-base:15.0.1'
implementation 'com.google.android.gms:play-services-ads:15.0.1'

In the module (app) level build.gradle file.

I get response 403 on install or event recording

Scenario

You are trying to test installs and other conversion events in the log. When you trigger these events, you see response 403 (forbidden) in the logs.

Possible reasons

This might be because you have the Zero package, which does not include attribution data; only data on clicks and impressions. To start receiving attribution data, learn more about the different AppsFlyer packages, and update as needed. You can also contact our customer engagement team at hello@appsflyer.com if you have questions about our packages.

Debugging for iOS

Enabling iOS SDK debug mode

To start debugging the iOS SDK, add the following line in the didFinishLaunchingWithOptions method:

Add the following line in AppDelegate.m:

[AppsFlyerLib shared].isDebug = true;

Add the following line in AppDelegate.swift:

AppsFlyerLib.shared().isDebug = true

Warning!

Debugging should be restricted to the development phase only. Do not distribute the app to the App Store with debugging enabled. This poses major security and privacy risks.

Viewing debug output

To view the debug output, open the debug terminal in XCode and filter by "AppsFlyer".

Troubleshooting common issues with iOS SDK

Installs and events are not recorded

There could be several reasons why installs and events are not recorded:

If you specify an app ID in the wrong format, installs and events are not recorded. When setting the app ID in the delegate file, make sure that it is comprised of numbers only.

You can find your dev key in AppsFlyer Dashboard inside App Settings:

Correct:

[AppsFlyerTracker sharedTracker].appleAppID = @"340954503";

Incorrect:

[AppsFlyerTracker sharedTracker].appleAppID = @"id340954503";

Incorrect:

[AppsFlyerTracker sharedTracker].appleAppID = @"com.appslyer.sampleapp";

In case the app ID is in the wrong format, the log displays the following error:

[ERROR] AppsFlyer: -[AppsFlyerTracker validateAppID] 
AppsFlyer Error: appleAppID should be a number!

If you specify an app ID that doesn't exist in your account, install and events are not recorded. The log shows the following error:

AppsFlyer: -[AppsFlyerHTTPClient sendRequestEventToServer:isRequestFromCache:appID:isDebug:
completionHandler:]_block_invoke sent information to server, status = 404

The 404 error indicates that the SDK is unable to find the app in your account.

If you specify an incorrect dev key ID, installs and events are not recorded. The log shows the following error:

AppsFlyer: -[AppsFlyerHTTPClient sendRequestEventToServer:isRequestFromCache:appID:isDebug:completionHandler:]
_block_invoke sent information to server, status = 400

The 400 error indicates that the SDK is unable to authenticate the request to record installs and events. Check that the dev key is the correct one. Also, make sure that the dev key contains only alphanumeric characters.

App ID and dev key are correct but install is not recorded

Scenario

The app contains the correct app ID and dev key but installs are not recorded.

Possible reasons

The SDK is not initiated correctly. Make sure to call trackAppLaunch method in applicationDidBecomeActive:

- (void)applicationDidBecomeActive:(UIApplication *)application { 
	[[AppsFlyerTracker sharedTracker] trackAppLaunch]; 
}

func applicationDidBecomeActive(application: UIApplication) { 
	AppsFlyerTracker.shared().trackAppLaunch() 
}

The log shows "AppsFlyer dev key missing or empty. aborting"

Scenario

You are trying to see installs and in-app events in the log. The log shows "AppsFlyer dev key missing or empty. Aborting".

Possible reasons

The dev key is not set. Make sure to set it in appDelegate in the didFinishLaunchingWithOptions method:

[AppsFlyerTracker sharedTracker].appsFlyerDevKey = @"YOUR_DEV_KEY";

AppsFlyerTracker.shared().appsFlyerDevKey = "YOUR_DEV_KEY"

Install always attributed to organic

Scenario

Possible reasons

The attribution link you are using is incorrect. See our guide on attribution links.
Make sure that the device you are testing on is registered.

Revenue is not recorded properly

Scenario

You are testing in-app events with revenue. The events appear in the dashboard but revenue is not recorded

Possible reasons

The revenue parameter is not formatted correctly. Do NOT format the revenue value in any way. It should not contain comma separators, currency signs, or text. A revenue event should be similar to 1234.56, for example.

I'm getting a 404 on install or event recording

Scenario

You are testing installs and in-app events to see that they are attributed to the correct media source. However, response 404 appears for both install and in-app events. Neither the install nor the in-app events appear in the dashboard.

Possible reasons

A 404 response indicates that the app ID is incorrect. See Installs and Events are not recorded.

I get response 400 on install or event recording

Scenario

You are trying to test in-app events in the log. When you trigger events you see response 400 in the logs.

Possible reasons

This might indicate an issue with the dev key. Check that the dev key is the correct one. Also, make sure that the dev key contains only alphanumeric characters. See Installs and Events are not recorded.

I get response 403 on install or event recording

Scenario

You are trying to test installs and other conversion events in the log. When you trigger these events, you see response 403 (forbidden) in the logs.

Possible reasons

Debugging for Unity

Enabling debug mode in Unity

To start debugging the Unity SDK, add the following line to the start method in the AF GameObject

AppsFlyer.setIsDebug (true);

Warning!

Debugging should be restricted to the development phase only. Do not distribute the app to app stores with debugging enabled. This poses major security and privacy risks.

Viewing debug output

Viewing the debug output is done through Android Studio or XCode.

Troubleshooting common issues with Unity SDK

Unity simply builds Android and iOS apps. Refer to common issues with each platform more info:

Common issues with Android SDK
Common issues with iOS SDK

Note

When you're done testing and debugging the SDK integration, switch off the SDK logs.