About self-reporting networks

At a glance: Self-reporting networks (SRNs), also known as self-attributing networks, communicate attributable events via API. SRNs don't use AppsFlyer attribution links.

blobid0.jpg verizonmedia.png

Self-reporting networks

  • SRNs communicate events (like new installs and in-app events) to AppsFlyer via API.
  • Each SRN has a unique attribution policy and reporting method. This leads to differences in how and what SRNs report to AppsFlyer.
  • Non-SRNs (ad networks) report events using AppsFlyer attribution links. 
  • SRN user-level data use and retention restrictions. 

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. 

Example A

SRN_1.png

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.

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.

Example B

This example continues Example A, above.

SRN_2.png

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 (CPI) and Cost per Action (CPA)—these are based on clicks or impressions that occur within a 14-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.

Advertiser 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 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.

FAQ

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

Click is performed in the SRN environment but without an AppsFlyer attribution link. Therefore, some SRNs don't give click and impression data to AppsFlyer.  

Facebook and Google give some aggregate data to AppsFlyer.

Set up a campaign with an agency and 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 a 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 are already an existing user. 
mistargeted_users.png

Solve 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.

Was this article helpful?