At a glance: Learn about self-reporting networks (SRNs), AKA self-attributing networks, which communicate attributable events via APIs, vs. attribution links used by non-SRNs.
|Google Marketing Platform||Apple Search Ads||Google Ads||Snapchat||Tencent Social Ads||Yahoo! Search Ads||Verizon Media|
- Communicate events (like new installs and in-app events) to AppsFlyer via API.
- Each has a unique attribution policy and reporting method. This leads to differences in how and what SRNs report to AppsFlyer.
- Have user-level data use and retention restrictions.
- Non-SRNs (ad networks) report events using AppsFlyer attribution links.
- iOS 14.5 SRN implications: Use SKAN dashboard in considering SRN performance. Expect a reduction in installs attributed to SRNs in the traditional dashboard; use the SKAN dashboard.
How do SRNs work?
Potential app users see and interact with multiple ads before they install an app. In general, attribution providers offer advertisers last-touch attribution—this attributes an install to the last click made before the actual install.
When an app is first launched:
- AppsFlyer checks if, in the platform, the app is set to receive traffic from SRNs.
- If yes, AppsFlyer uses the advertising ID (device ID) to query SRNs (API).
- AppsFlyer performs attribution based on the returned results.
Monday: Network A reports a user click.
Tuesday: Network B reports a video engagement.
Wednesday: Network C reports a click on a playable ad and, 30 minutes later, there is an install.
AppsFlyer attributes the install to Network C and gives Networks A and B credit for assisting with the install.
AppsFlyer gives advertisers assist data (unattributed engagements that occur before an install). This lets advertisers customize their multi-touch or fractional attribution models. See this short explanation.
Note that in the case of Apple Search Ads (ASA), AppsFlyer gets the attribution information from within the SDK. If available, AppsFlyer sends back to ASA only the time and date of the app launch.
Third-party attribution providers and SRNs
SRNs use a different attribution methodology. Their approach is as follows:
- Use an API to communicate with attribution and measurement providers (instead of reporting on attribution links).
- When attribution providers detect an install, they query the network about an advertising ID.
- SRN reports the details of any relevant ad clicks or impressions.
- AppsFlyer uses its standard attribution logic to sequence the relevant impression and click data.
- AppsFlyer attribution is based on both last-touch and multi-touch methodologies.
This example continues Example A, above.
Network D (SRN) reports a click a few minutes before Network C.
Network C uses standard attribution integration.
AppsFlyer attributes the install to Network C as they had the last click.
SRNs and attribution windows
Attribution windows include lookback and view-through. Some SRNs charge advertisers for an install based on Cost per Impression (CPM) and Cost per Action (CPA)—these are based on clicks or impressions that occur within a 1-28 day period.
AppsFlyer attributes install, activity, Effective Cost per Install (eCPI), and Effective Cost per Action (eCPA) based on an advertiser’s preferred attribution methodology and lookback windows.
Advertisers may have to pay for installs based on SRN attribution lookback windows and view-through models.
- Advertisers expect the AppsFlyer third-party universal attribution methodology to optimize and allocate their ad spend.
- Why? Because AppsFlyer reports actual eCPI and eCPA based on advertiser-defined terms.
- SRNs may benefit in the short term as they often define their own payment terms. But, advertisers correct this by using third-party attribution providers.
Deep linking with SRNs
To simply open the app when the link is clicked, you just need to set up App Links/Universal Links/URI scheme.
However, deep linking or deferred deep linking to a specific page/activity in the app is different. SRNs have their own proprietary methods for deep linking, which don't involve attribution links of external attribution services.
So how can you deep link your users and get the relevant data from SRNs?
Direct deep linking with SRNs
SRNs use their own methods to perform deep linking. This means that the AppsFlyer deep linking method isn't called when a user device performs deep linking from an SRN. As such, if there's a need for direct deep linking data within the app, this needs to be done using SRN methods to get it upon app launch.
Deferred deep linking with SRNs
In contrast, deferred deep linking with SRNs is possible.
AppsFlyer always receives the conversion data and makes it available to the app on the first launch.
New users that install after clicking on a deep linking/retargeting campaign on an SRN can be redirected within the app upon launch, by using the conversion data.
However, with SRNs, the regular AppsFlyer deep linking parameters, such as af_dp, are not present as part of the deep link data. To use this data within the app, the developer needs to employ further logic based on available parameters, such as campaign, ad set, or single ad names.
Jill, the mobile marketer of greatapp, decides to run a deep linking campaign on Facebook, targeted for general audiences.
The campaign redirects any clicking users to a "bonus" activity.
Jack, the mobile developer, adds this logic after getting the conversion data:
1. Is it Facebook originated ("is_fb=true")?
2. If true - get the value of the ad group parameter.
3. If the value contains the word "bonus" send the user to the "bonus" activity.
Using Facebook's methods, existing users clicking the ad are redirected to the activity directly, while new users get the same experience using AppsFlyer's conversion data.
Alternately, if your app also includes the SRN's SDK, you may be able to directly fetch deep linking data from it, for example, with Facebook Ads.
Why is the Original URL field empty in raw data reports?
Click is performed in the SRN environment but without an AppsFlyer attribution link. Therefore, the click's associated Original URL data is not available to AppsFlyer.
Dashboard doesn't show SRN clicks and impressions
Set up a campaign with an agency and SRN
How does retargeting work with SRNs?
Retargeting clicks from non-SRNs are easily identifiable by the existence of the
is_retargeting=true parameter in the retargeting attribution link.
With SRNs, there is no similar indication. Instead, to enable attributing re-engagements from SRNs, AppsFlyer uses another logic:
- On the App Settings page, turn on Enable retargeting.
- In the Integrated Partners page, select the SRN, turn on Retargeting.
- With each app launch, AppsFlyer queries the SRN about recent engagements of the device ID with campaign ads for the app.
- If the SRN responds back with engagement details, AppsFlyer validates the engagement is within the lookback window and beyond the minimum time between re-engagements.
- Validated engagements are recorded as re-engagements and attributed to the SRN.
What is SRN mistargeting?
SRN campaigns should target a specific audience, but this doesn't always happen: Non-users in user-acquisition campaigns and existing users in retargeting campaigns.
If one SRN is used to run both user acquisition and retargeting campaigns, this can lead to user mistargeting. As a result, you pay for unintended traffic.
Scenario: An SRN in the AppsFlyer platform is enabled for a user-acquisition campaign.
- After each app launch, AppsFlyer queries the SRN to check if the advertising ID (user) had a recent engagement.
- If yes,
- SRN replies with the campaign name.
- AppsFlyer determines if it was the first launch (or not) and attributes accordingly:
First launch: A new install is attributed to the campaign.
Second or later launch: A retargeting event is attributed to the campaign.
Conclusion: It is wasteful to get retargeting events from a user acquisition campaign.
Is mistargeting a problem?
AppsFlyer data analysts checked Facebook user acquisition campaigns during a given month.
- Retargeting was enabled.
- In 30% of campaigns, at least 15% of targeted users were existing app users.
- In 5% of campaigns, at least 40% were existing app users.
- Conclusion: In SRN user-acquisition campaigns, 1 in 10 targeted users is already an existing user.
Solving the mistargeting problem
Basic solution: Don't include existing app users in a user acquisition campaign.
- SRN will only target potential new users.
- Maximizes new user acquisition results for the same budget.
- Periodically (and manually) update the campaign, for example, once a month.
- However, time gaps mean that existing users may be targeted in user-acquisition campaigns during the first month after they install an app.
Audiences, an AppsFlyer premium feature, lets you automatically send, on a daily basis, any segment of your user base to dozens of ad networks.
AppsFlyer research shows that solving mistargeting can have a dramatic impact on your marketing and user acquisition efforts.
iOS 14.5 SRN attribution implications
Starting iOS 14.5 expect as follows:
- Most SRNs support SKAdNetwork and have the necessary integration with AppsFlyer.
- SRN installs:
- Can reflect in both SKAdNetwork and traditional dashboards if users give ATT consent in both the advertiser and publisher apps (aka dual consent).
- Are recorded in the SKAdNetwork dashboard. Note! The dashboard updates with a lag of 48-72 hours after the install.
- Installs brought by Apple Search Ads (ASA) aren't attributed in the SKAdNetwork dashboard.
Overall expect a decrease of installs attributed to SRNs with a matching increase of organic installs.
Does iOS 14 impact event postback sending to SRNs?
- Currently, SRNs receiving event postbacks rely on the inclusion of the device ID in the postback. This enables SRNs to self-attribute reported user actions.
- Many iOS 14 users are non-consenting—don't allow access to their device ID (IDFA).
iOS 14 impacts SRNs as follows:
- A decrease in the number of event postbacks to SRNs
- Discrepancies in the number of event postbacks between SRNs and AppsFlyer; who log all events.
- Click ad networks are not affected, as they use their own transaction IDs, and not device IDs, to self-attribute event postback information.