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 (delete) the app from the device.
- Register the device as a test device. Note! iOS: If you use TestFlight to install the app, there is no need to register the device.
- In AppsFlyer, 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)
- iOS:
- App Store
- XCode
- TestFlight
- Android:
- Scan the QR code with the registered test device and follow the instructions on the device.
- Wait until the non-organic install is registered in 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, refer to the troubleshooting section that appears in 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 devices 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. Refer to 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 the retargeting toggle is turned on.
- Click on Run test under Deeplinking
- 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 in 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
Duplicating your iOS app
- Open the project folder in finder
- Duplicate the folder
- Open the duplicated project in XCode
- In the
AppDelegate
class, inside thedidFinishLaunchingWithOptions
method, set a new app ID:Objective C
Swift
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 five 1s. The remaining digits should be random. See ID example above.
Add the iOS test app to your AppsFlyer dashboard
Follow the instructions to add a new app in your AppsFlyer dashboard. Make sure that the app ID is the same as the app ID of the newly created test app. Also, make sure to set the app status to Pending approval or unpublished.
You can now run tests on the new test app.
Tests using attribution links
This section demonstrates how to test the integration with the help of attribution links.
Before you begin:
- Registered devices that you use for testing
- When testing re-attributions, make sure to remove the registered device from the allowlist.
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 campaign.
- The pid parameter specifies the name of the media source to which the install is attributed.
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 a more elaborate verification, download the installation raw data report:
- In AppFlyer, go to Reports > Export Data.
- In the Raw Data Reports section download the Installation raw data report.
Refer to our article about 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.
Refer to our article about 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 deeplinking. Deeplinking 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 toggle on Enable Re-Targeting Campaign Measurement.
- A non-registered device
Testing retargeting is straightforward. Create a custom attribution link out of a OneLink template. Make sure to toggle 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.
- In 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 reattribution) 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 in 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 he or she 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 launch pad
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. 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. Refer to 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
andinit
methods are called in theAFApplication
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 regarding 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 comprises 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 inapplicationDidBecomeActive
:
- (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
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
- the attribution link you are using is incorrect. Refer to 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 sign, 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. Refer to 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. Refer to 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
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 regarding our packages.
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 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:
Note
When you're done testing and debugging the SDK integration, switch off the SDK logs.