At a glance: Integrate AppsFlyer Probabilistic modelling solution with your network and become an AppsFlyer integrated partner.

Ad network integrations with AppsFlyer
Successful integration between AppsFlyer and an ad network means that:
- Mobile attribution between the ad network and the app owner completes flawlessly in a few minutes, rather than weeks.
- Ad networks gain access to their attributed data in realtime.
Guide contents:
- Ad Network Integration Setup Steps
- Ad Network Integration Testing: test your general integration with AppsFlyer
- Advertiser Integration Testing: test a specific advertiser's campaign configuration with your ad network
- FAQs and Troubleshooting
Ad network integration steps
The ad network integration with AppsFlyer has five steps:
Step 1: Define the Ad Network Global Click URL/impression URL (attribution link) parameter placeholder/macros
The first step is to define your AppsFlyer click URL. When a user clicks on an ad, a redirect is put in place from your ad network attribution link to AppsFlyer attribution link.
Below is the redirect flow from the end-user click to the final destination (Appstore):
The click URL should be in the same format for all future campaigns.
See below AppsFlyer's base attribution link with a detailed explanation per macro:
https://app.appsflyer.com/app_id?pid=mediaName_int&c={campaign}
AppsFlyer Base URL | Description |
---|---|
https://app.appsflyer.com |
AppsFlyer End-Point |
app_id |
Application Unique ID - Dynamic value changed per app (provided automatically by AppsFlyer) ExampleAndroid - com.appsflyer.sample iOS - id1234123412 |
pid= |
Media source name concatenated with _int to identify integrated networks (provided by AppsFlyer) |
In addition to the above, ad networks can specify available macros by adding parameters to the URL. For example: Click ID, Publisher ID, Campaign ID, Ad Type, Cost etc. These macros are then used by AppsFlyer when sending postbacks to the ad network.
By using macros, the ad network specifies what data it wants AppsFlyer to include in the postbacks.
Below is a list of the most important macros:
Name | Description | Parameter name convention |
Field type and char limit |
---|---|---|---|
Campaign Name |
Campaign name |
c |
String 100 |
IDFA (iOS only) |
The IDFA of the iOS device from which the click/impression is received |
idfa |
String 40 |
GAID (Android only) |
The Google Advertising ID (GAID) from which the click/impression is received |
advertising_id |
String 40 |
Click ID |
The ad network unique click identifier |
clickid |
|
Publisher ID |
Ad network publisher id. If the network works with several different publishers they can be identified by using site ID |
af_siteid |
String 24 |
Sub Publisher ID |
Ad network sub_publisher id. If the network’s publishers have additional sub_publishers or site ids, they can be identified by using sub_site ID |
af_sub_siteid |
String 50 |
Cost 1. Cost model (i.e. CPI, CPC, CPA) 2. Cost value (the actual cost in numbers – i.e. 1.99) 3. Cost currency (i.e. USD) |
The cost of the campaign/ad-set/ad. This is important so advertiser can see ROI and eCPI |
Cost
|
|
Ad type |
Please use one of the following name conventions: |
af_ad_type |
String 24 |
Incent or non incent campaign |
true/false |
is_incentivized |
|
Server side click or AppsFlyer redirect |
true/false |
is_s2s |
|
For the full list of available macros, see here.
Example:
Base Attribution Link Template:
https://app.appsflyer.com/com.appsflyer.sample?pid=mediaName_int
Android attribution link parameter example:
https://app.appsflyer.com/com.appsflyer.sample?pid=mediaName_int&clickid={clickid}
&c={campaign}&advertising_id={advertising_id}
The final attribution link looks like this:
https://app.appsflyer.com/com.appsflyer.sample?pid=mediaName_int&clickid=123456
&c=test_campaign&advertising_id=1a11a11a-2b2b-3c3c-4d4d-111a1a11a111
iOS attribution link parameter example:
https://app.appsflyer.com/id123412312?pid=mediaName_int&clickid={clickid}&c={campaign}&idfa={idfa}
The final attribution link looks like this:
https://app.appsflyer.com/id123412312?pid=mediaName_int&clickid=123456
&c=test_campaign&idfa=AAA11AA-B2BB-333C-D4444444444
Note
Attribution links can be created outside AppsFlyers dashboard/UI. Instead of configuring the macros in the AppsFlyer UI each time, advertisers can copy and paste the name of the macro into the correct place.
- All Macros {} can be changed according to your system configuration.
Impression Attribution
AppsFlyer also allows ad networks to get attributions based on impressions.
To send impression data to AppsFlyer you can use the same structure as in the above attribution link. The same parameters used for click URLs are used for impression attribution, except:
1. URL base - replace http://app. with http://impression.
2. Lookback parameter - replace af_click_lookback with af_viewthrough_lookback
In order for AppsFlyer to attribute an install from an impression, ad networks must include the device ID in each call.
For more information, refer to this article.
Step 2: Define the Ad Network Global Install postback endpoint and parameter placeholder/macros
Example:
http://YourDomain.com/postback?clickid={clickid}&af_siteid={affiliate_id}
The base install postback structure can be changed according to specific ad network preferences.
For the full list of available parameters, click here.
Note
When sending the postback URLs to AppsFlyer for integration purposes it is mandatory to use AppsFlyer's macros as specified in the above link.
AppsFlyer can also provide static parameters per install conversion postback. Such parameters can be advertiser ID and key or password for allowing postbacks.
These parameters are added by the advertiser in the AppsFlyer UI.
In addition to the attributed installs, AppsFlyer can also send a postback for every non-attributed install. These postbacks can be marked with a specific parameter called “can claim”.
&can_claim=1 indicates an install that is attributed to the ad network.
&can_claim=0 indicates an install that is attributed to another network or organic source.
http://yourdomain.com/AppsFlyer?clickid={clickid}&can_claim={1\0}
Non-attributed installs are missing specific parameters such as the click ID which is available only when reporting attributed installs.
Step 3: Define the Ad Network Global In-App Events postback endpoint and parameter placeholder/macros
The third step is to define the global in-app events postback endpoint and macros.
An in-app postback is a request to the ad network notifying them of a successful in-app conversion. When AppsFlyer measures an in-app conversion, it determines which ad network is responsible for generating the specific event based on the install conversion. AppsFlyer then attributes the in-app event to that ad network.
Global in-app event postback example:
http://YourDomain.com?clickid={clickid}&event_name={event-name \ mapped-iae}¤cy={currency}&value={revenue}
All install parameters are also available in the in-app event postback.
For the full list of available macros, see here.
You can either pre-configure the event tags to standardize the information the advertisers can send you, or you can leave the event tag open for advertisers to enter free text.
Example of Free Text Event Tag:
Example of Pre-Configured Event Tag:
Step 4: Define the Ad Network Global Re-attribution postback endpoint and parameter placeholder/macros
Re-attribution - having the targeted user engaging with the retargeting campaign and causing them to re-install the app.
Define which postback you want to receive for re-attributed users.
You can choose between:
- Your install postback, including a unique flag for the re-attribution
- Your in-app event postback, including a unique flag for re-attribution
- A custom postback
For more information about retargeting (re-attribution and re-engagement) including the structure of the attribution link and relevant parameters, see here.
Note
You can define one postback for both re-attribution and re-engagement with a flag that will indicate whether the user is re-attributed or re-engaged.
Step 5: Define the Ad Network Global Re-engagement postback endpoint and parameter placeholder/macros
Re-engagement - when an existing user that has the app installed engages with the retargeting campaign.
Define which postback you wish to receive for re-engaged users.
You can choose between:
- Your install postback, including a unique flag for the re-engagement
- Your in-app event postback, including a unique flag for re-engagement
- A custom postback
For more information about retargeting (re-attribution and re-engagement), including the structure of the attribution link and relevant parameters, see here.
Note
You can define one postback for both re-attribution and re-engagement with a flag that will indicate whether the user is re-attributed or re-engaged.
Finalizing your registration
- If you currently have an integration with AppsFlyer contact us at partners@appsflyer.com
- If you do not currently have an integration with AppsFlyer, complete the ad Partners Registration application here.
Testing the integration
Once the integration with AppsFlyer is complete, you can proceed to test it:
- Ad Network Integration Testing - to test your integration with AppsFlyer
- Advertiser Integration Testing - to test an advertiser's campaign configuration with your ad network
Ad network integration
This section demonstrates how to test your integration with AppsFlyer.
Prerequisites
Before you can start testing the integration, there are a few prerequisites:
- An up and running integrated partner account
- Your endpoint server for receiving postbacks for installs and in-app events
Getting started
Open your AppsFlyer's Dashboard. In the App Search screen, enter the following app ID: com.appsflyer.adNetworkTest. This is the app for testing your integration with AppsFlyer.
Once the green tick appears in the input field, click on the blue arrow.
The app's dashboard opens up. In this dashboard you can see installs of the test app that are attributed to your ad network.
Testing install attribution
Now that the app is added in your dashboard, you can start testing install attribution. Follow the steps below to generate an install.
Generate an attribution link
Copy the attribution link that follows:
https://app.appsflyer.com/com.appsflyer.adNetworkTest?pid=YOUR_PID&c=YOUR_CAMPAIGN
&af_click_lookback=7d&af_click_lookback=7d&clickid={clickid}
Change the following parameters:
- pid (YOUR_PID) - your partner id (supplied by AppsFlyer)
- c (YOUR_CAMPAIGN) - any campaign name
- clickid - a random number or id
Tip
The parameters in the attribution link above are the basic parameters. You can include other parameters in the attribution link if you need to. For more information, see AppsFlyer attribution link Structure and Parameters.
Installing the app through the attribution link
Send the attribution link to the test device. Open the link in the browser and install the app.
Once the app launches the following screen appears:
If you don't see this message, make sure that the attribution link is formatted correctly. Uninstall the app and reinstall using the attribution link.
Tip
For more elaborate results, repeat the installation process using the attribution link. Uninstall the app, change the parameters in the link (mainly the campaign name and click id), and install again by navigating to the URL (simulating a click).
Testing in-app events
The steps below explain how to record in-app events of apps whose install is attributed to your ad network.
Mapping events
Before you can start testing in-app events, you need to map AppsFlyer events to events as they are defined by your ad network.
Important!
Event mapping is required in order for in-app events postbacks to be sent, and for in-app events data to be populated in the in-app events postbacks raw data report.
In your AppsFlyer dashboard, click on Integrated Partners and choose your ad network. Under the Integration tab scroll down to In-App Events Settings. Choose the in-app event and map it to the corresponding event:
Scroll down and click Save.
Triggering in-app events
In-app events that are sent to AppsFlyer are also attributed to the ad network that generates the app install. You can test in-app events attribution directly from the app.
Once the app launches, click on EVENT TRACKING TEST.
In the next screen, click on any button to trigger an in-app event:
Note
In-app events and related revenue cannot be viewed in the dashboard. You can export in-app events related to data from the Export Data section.
After exporting the in-app events postbacks report, you can look into the report to verify the following:
- The event is attributed to you as an ad network, under the field Media Source
- The event name is correct, under the Event Name field
- The postback, if enabled, contains the event name and value, under the Postback URL field
- In-app events are mapped correctly under the Postback URL field
Testing retargeting attribution
You can also test Retargeting attribution. The process is almost the same except for one parameter that you add to the attribution link.
Generate a new attribution link and add the parameter is_retargeting=true
to it.
Example
https://app.appsflyer.com/com.appsflyer.adNetworkTest?pid=YOUR_PID&c=YOUR_CAMPAIGN&af_click_lookback=7d
&clickid={clickid}&is_retargeting=true
Install the app using the retargeting link. The flow is the same as described in testing install attribution.
Viewing retargeted installs in the dashboard
Access your AppsFlyer dashboard and click on Re-targeting in the left-hand side menu.
Exporting raw data
Data related to apps whose install is attributed to your ad network can be exported in CSV format.
The data includes the following:
- Installs
- In-app events
- Retargeting installs
- In-app events of apps installed from retargeting campaigns
To export raw data:
- In AppsFlyer go to, Reports > Export Data.
- Select the date range.
- Select a report.
The report downloads within a few minutes.
Verifying postback data
Every install generates a postback that is sent to your servers. To verify the postback url, its structure and the parameters that are appended to it, export the Installation Postbacks report.
The Installation Postbacks report contains a column titled Postback Url. This column lists the postback URLs as generated for each and every install.
Review the data in that column to verify the following:
- The URL endpoint is the correct one
- The parameters appended to the URL correspond to those appended to the AppsFlyer attribution link
- The Postback Error Message column is empty
Advertiser integration
This section discusses how to test an advertiser's campaign with your ad network.
Prerequisites
Before you can start testing the advertiser's integration with your ad network, there are a few requirements:
- Allowlist devices: you need to ask the advertiser to allowlist any devices that you use for testing
- The app should include AppsFlyer's SDK
- If the app is not live (not featured in Google Play or the App Store) you need to ask the advertiser to provide you with the app
- Whether the app is live or not, it must be listed in the advertiser's account
Getting started
Open your AppsFlyer's Dashboard. In the App Search screen, enter the advertiser's app ID:
Example
Android - com.example.app
iOS- id1234123412
Once the green tick appears in the input field, click on the blue arrow. Clicking the arrow opens the app's dashboard.
Testing live apps
In the app's dashboard, click on Integrated Partners in the left-hand side menu. Choose your ad network and click on Attribution Link.
Important!
If the options under Attribution Link are grayed out, ask the advertiser to enable ad network permissions. The required permissions are Allow to configure integration and Allow to configure in-app events postbacks.
Alternatively, you can ask the advertiser to provide you with the attribution link.
Installing the app through the attribution link
Now you can generate an attribution Link to test install attribution.
Add parameters to the attribution link according to your requirements and the data that you want to record.
Tip
To learn more about the parameters that you can add to the attribution link, see AppsFlyer attribution link Structure and Parameters.
Testing install attribution
Send the attribution link to the test device. Open the link in the browser, install the app and launch.
Launching the app is crucial for the attribution flow. If the app is not launched, no attribution is recorded.
You can then view the install in your dashboard.
Testing apps in development
You can test an advertiser's campaign integration with your ad network even if the app is not live. However, you need to ask the advertiser to provide you with the app (an apk or ipa file) so you can install it on your test devices.
Generate an attribution link
Generate an attribution Link. You can use the same instructions as listed above. Send the attribution link to the test device and navigate to it using the device's browser.
The following screen appears:
This is the expected result. Since the app is not live, the attribution link doesn't lead to any app store. However, the attribution link is still valid for attribution purposes. the attribution link and its parameters are recorded by AppsFlyer's servers and the data is used for attribution.
Installing the app
Install the app on the test device using the file that the advertiser provides you and then launch the app. Delete the app and repeat the process (to generate several installs). You can then view the installs in your dashboard.
Testing in-app events
Note
You can test in-app events postbacks for both live apps and apps in development.
Before you can test in-app event postbacks, you should contact the advertiser to learn about the type of in-app events that they record and how you can trigger them from the app.
Mapping events
If the advertiser enables the permission Allow to configure in-app events postbacks, you can map AppsFlyer events to the events that you log in your servers.
In your AppsFlyer dashboard, click on Integrated Partners and choose your ad network. Under the Integration tab scroll down to In-App Events Settings. Choose the in-app event and map it to the corresponding event:
Triggering in-app events
Once you know which in-app events the advertiser records, and event mapping is in place, trigger a few events from the installed app.
Note
In-app events cannot be viewed in the dashboard. You can export in-app events related data from the Export Data section.
In the in-app events postback report you can find data such as the postback URL and mapped parameters. Use the data in the report and compare it with the data in your servers (from the postback) to make sure that data from postbacks is accurate and properly recorded by your servers.
After exporting the in-app events postbacks report, you can look into the report to verify the following:
- The event is attributed to you as an ad network, under the field Media Source
- The event name is correct, under the Event Name field
- The postback, if enabled, contains the event name and value, under the Postback URL field
- In-app events are mapped correctly under the Postback URL field
Viewing installs in the dashboard
Once you install and launch the app, you can see the results in your dashboard.
Important!
In order to generate several installs, the device must be allowlisted.
Access your AppsFlyer dashboard and click on Overview in the left-hand side menu.
Filter by your ad network. You can see the number of clicks and installs that are attributed to your ad network.
Data related to clicks and installs appears at the top of the Overview screen. The Overview screen also includes Breakdown by Campaign and Aggregated Performance Report. Verify that campaigns that appear in these sections correspond with the campaign parameter in the attribution link.
Verifying postback data
Every install that is attributed to your ad network generates an install postback. If in-app events postbacks are enabled, events that come from an app whose install is attributed to your ad network, also generate postbacks.
Open the Export Data section and export the two reports:
- Installation Postbacks
- In-App Events Postbacks
Both reports contain a column titled Postback URL. This column lists postback URLs for installs or in-app events (depending on the type of report).
Review the data in that column to verify the following:
- The URL endpoint is the correct one
- The parameters appended to the URL correspond to those appended to the AppsFlyer attribution link
- For in-app events postbacks, the events are correctly mapped i.e.
sdk_event=af_purchase&mapped-event=purchase
sdk_event=af_login&mapped-event=login
- The Postback Error Message column is empty
What counts as a view? Should a banner appear on a screen or only a part of it? Does the user need to watch the full video or are a few seconds enough to be considered a view? Even when it comes to clicks, it is not so straightforward: what should happen after or before the click so it is considered viable?
This article provides information about the following:
- AppsFlyer's recommended standards on defining a click or view
- How to send AppsFlyer the details of ad visibility during the engagement
Definition of Clicks and Views
Different ad networks can define clicks and views differently. This can cause inconsistent and incomplete data.
Example
AwesomeApp's owner runs a campaign that includes a video ad that is 10 seconds long.
A user sees the ad on two different networks — first on Network A, then, after a while, on Network B. Each time the user watches it for 4 seconds.
After seeing the ad on Network B, the user decides to download AwesomeApp and goes straight to the app store.
Network A counts a View for a video ad when at least 4 seconds of it has been watched.
Network B counts a View for a video ad as 50% of duration.
Network A is reporting this as a view and gets the attibution. Network B doesn't report it, although most likely it motivated the user to download the app.
If both networks had the same definition of a View, both would have reported the engagement, and the last one would receive the attribution.
For fairness and consistency, AppsFlyer recommends that its partner networks adopt the following standards:
Ad Type | View | Click |
---|---|---|
Interstitials and banners | 50% of the ad unit is visible for 1 second | A click that takes the user directly to the app store |
Rewarded videos |
Video is watched for 2 seconds |
A click that takes the user directly to the app store |
Playable ads |
The playable element is launched |
A click that takes the user directly to the app store |
Standard video |
Video is watched for 2 seconds |
A click that takes the user directly to the app store |
In addition, we encourage ad networks to send the ad visibility data during each click or view. This valuable information can give advertisers a better understanding of user engagement and help them optimize their marketing efforts.
Read about how various networks define clicks and views.
Cool
Partners who send the full spectrum of engagement parameters, and follow AppsFlyer’s Engagement Standards, get to be showcased in the AppsFlyer platform, marketing materials, and consultations with clients.
How to Send Engagement Parameters
The af_ad_type
parameter should be appended to the click/view URL along with the relevant value corresponding to the type of the ad that brought a click or a view (see URL examples below).
Depending on the ad type, you can attach the relevant engagement parameters that provide details of the engagement (e.g. how much of a video a user has watched).
af_ad_type
values
This is a list of possible values for af_ad_type
and the engagement parameters available for each ad type:
Value | Description | Recommended Additional Parameters |
---|---|---|
|
An ad unit containing only text, e.g. a search result |
|
|
A basic format that appears at the top or bottom of the device screen |
|
|
A full-page ad that appears during breaks in the current experience |
|
|
A standard video, i.e. non-rewarded |
|
|
An ad unit offering in-app rewards in exchange for watching a video |
|
|
An ad unit containing an interactive preview of the app experience |
|
|
A link included in a piece of sponsored content, like an advertorial article |
N/A |
|
An audio ad |
|
Engagement parameters and values
The engagement parameters should be passed with the following values:
Parameter | Value Format | Description |
---|---|---|
|
seconds (e.g. "30") |
The length of the video |
|
seconds (e.g. "2") |
How much of the video was viewed |
|
seconds (e.g. "30") |
How long the playable element is played once fully loaded |
|
seconds (e.g. "1") |
How long the ad unit is visible on the screen |
|
% (e.g. "75") |
The maximum percentage of the ad unit that is visible on the device screen |
|
seconds (e.g. "30") |
The length of the audio |
|
seconds (e.g. "2") |
How much of the audio is heard |
URL Examples
- Impression URL
A user watches a rewarded video ad of AwesomeApp (total length of 30 seconds) for 7 sec, and leaves without clicking:
https://impression.appsflyer.com/com.coolcompany.awesomeapp?pid=mediaName_int &af_ad_type=rewarded_video&af_video_total_length=30&af_video_played_length=7
- Click URL
A user sees 75% of AmesomeApp's banner ad and clicks on it after 8 seconds:
https://app.appsflyer.com/com.coolcompany.awesomeapp?pid=mediaName_int &af_ad_type=banner&af_ad_time_viewed=8&af_ad_displayed_percent=75
A user listens to an audio ad of AmesomeApp and clicks on the ad after listening to 6 seconds of it (out of 10 seconds):
https://app.appsflyer.com/com.coolcompany.awesomeapp?pid=mediaName_int &af_ad_type=audio&af_audio_played_length=6&af_audio_total_length=10
This section discusses FAQs and troubleshooting issues.
FAQs
I want to become an integrated partner
If you wish to work with AppsFlyer clients, you need to be an AppsFlyer integrated partner.
In order to register for an Appsflyer Partner account please fill in this form, and a member of the partner development team will be in touch. When filling in the form, please specify an email address that has never been used before on AppsFlyer. Alternatively you can contact them directly through partners@appsflyer.com.
How can I update my integration?
If you need to update your integration with AppsFlyer (for example, updating the postback endppoint), please contact integrations@appsflyer.com with your integration update request. Please make sure to include your integrations PID.
What are the partner permissions?
An advertiser can grant permission to a partner to configure the integration with that partner.
It's easier for you as a partner to test campaign configuration if you have permissions to edit and change the integration the advertiser setup with your ad network.
The permissions are (depending on the advertiser's account):
- Integration Parameter Configurations
- In-App Event Configuration
- Retention Reports
- Protect360 Dashboard
For more information, visit our guide on Providing Permissions to Ad Networks.
How long does it take results to appear in the dashboard?
Installs appear in the dashboard up to two minutes from the moment of install.
Reports for installs and in-app events take up to 15 minutes to be produced.
Troubleshooting
I cannot add the advertiser's app in the dashboard
If you are unable to add an app in the App Search screen, make sure that the advertiser adds the app to their dashboard first.
Test installs don't appear in the dashboard
If you run test installs with a client but don't see any installs on your Appsflyer dashboard:
- Make sure the advertiser allowlisted the devices you are using for testing.
- If you run campaigns using S2S probabilistic modeling, ensure that your integration is validated by AppsFlyer. Please contact your PDM.
Install postbacks are not sent to my servers
If you believe that postbacks are not sent to your servers:
- Make sure that the postback endpoint is active
- Make sure that the postback endpoint is the correct one - contact your PDM if it is not the correct endpoint
In-app events postbacks are not sent to my servers
In-App Events postbacks must be enabled in your configuration with the advertiser:
Can't see in-app events postbacks setup of agencies
Ad networks get visibility to their set up done by advertisers, but not when it's done by agencies. Therefore, when an agency, but not the advertiser, maps in-app events for postbacks to a network, the ad network sees this section as inactive, although it is actually active for the agency.
Example
Yuval is the marketer of the com.fused app, which is a client app of the Sonnet ad network. Yuval maps the af_purchase event to be sent as postback to Sonnet, when an attributed user to Sonnet performs a purchase.
Sava, an agency permitted to work with com.fused, also configures Sonnet to work with, and maps the af_completeregistration event to be sent as postback.
When Sonnet logs into the dashboard of com.fused, they see only the af_purchase event mapped with them, but not the af_completeregistration event. However, when users attributed to Sava perform registrations the af_completeregistration event is sent to Sonnet.
Click data is missing
If click data is missing from postbacks, make sure that the AppsFlyer link has all the data that you want to be returned to you in the postbacks. See our attribution link guide for more information.
If the advertiser configured the ad network to receive all postbacks, postbacks for events not attributed to the ad network don't contain click data.
Revenue data is missing
If revenue data is missing or appears as N/A in the advertiser postbacks, there could be two possible reasons:
- The advertiser has decided not to share revenue data.
- The advertiser has defined the in-app event incorrectly.
I see installs in AppsFlyer, but not on my internal servers
You need to place the AppsFlyer attribution link as the redirect URL on your servers. Then you need to use your servers own attribution link to run a full test.
Make sure to map the parameters of your network's attribution link to AppsFlyer's attribution link.
Dashboard data is missing
If you see data in the dashboard but that data is missing in your servers, verify that advertiser provides the necessary credentials or keys when configuring the integration with your ad network.
The advertiser should add any credentials, key or tokens in the General Settings section of the Integration tab.
If your network requires credentials or key for integration and the advertiser doesn't provide them, postbacks from AppsFlyer are rejected by your servers. Data cannot be posted to your server and is therefore missing.
Data from advertiser is missing or incorrect
If you test integration with an advertiser and no data (installs, in-app events) is available, follow the suggestions below:
- If the issue happens with any advertiser, contact your PDM
- If the issue happens with only one advertiser or a few advertisers:
-- verify with the advertiser that they implemented the AppsFlyer SDK in their app
-- verify with the advertiser that the SDK implementation is correct
I cannot configure the integration with the advertiser
The advertiser asks you to configure the integration but the configuration is locked and all the options are grayed out.
Ask the advertiser to grant your network permission to setup the integration.