A Day in the Life of a SKAdNetwork Postback

February 23, 2021
Liftoff
A Day in the Life of a SKAdNetwork Postback

SKAdNetwork is Apple’s privacy centric attribution framework for measuring conversions. It’s very complex and different from what we’re used to so to simplify, let’s take a look at how postbacks work today and how it will work in SKAdNetwork.

This is how postbacks work today

Let’s say a user opens Flappy Bird, clicks on an ad and installs the advertised app:

  1. An install postback is sent in real time to the mobile measurement partner (MMP)
  2. The MMP attributes the data and forwards it to the demand side partner (DSP)
    • The postback contains the user’s IDFA and granular data

Now let’s say a few days later, the same user makes a purchase in the advertised app:

  1. A new event postback is sent in real time to the MMP
  2. The MMP attributes the data and forwards it to the DSP
    • The postback contains the user’s IDFA and granular data

Postbacks are granular (contain IDFA) and are sent in real time. The MMP is able to attribute clicks on a 1:1 user level and the DSP is able to use postbacks to train ML to bid on better performing inventory. Life’s good.

Now let’s take a look at how a SKAdNetwork postback works

SKAdNetwork introduces 4 new limitations:

  1. Conversion values – advertisers have to assign a numerical value to events they want to track
  2. 24 hour timers – there’s a 24 hour timer that begins after the user installs the advertised app that can a) restart if a defined event occur or b) expire if no defined events occur
  3. Random delays – there’s a 24 hour random delay between the the time the postback is locked and sent to the DSP
  4. Anonymized postback – you only get one postback per app per user that contains the install and the user’s final conversion value. The postback does not contain IDFA

Let’s illustrate:

Let’s say the advertiser uses conversion values to define the following events (conversion values):

0 = install, 1 = registration, 2 = add to cart, 3 = purchase

Now let’s say a user installs an app, clicks on an ad and installs (starting a 24hr timer):

  1. The user registers (conversion value gets updated to 1, 24 hour timer resets)
  2. The user adds to cart (conversion value gets updated to 2, 24 hour timer resets again)
  3. The user doesn’t do anything for 24 hours (conversion value stays at 2, 24 hour timer expires) (24 hr timer)

Once the postback has been locked, it doesn’t get sent right away.

There’s a 24 hour random delay, meaning that the postback can be sent anytime between 0 and 24 hours from the time the postback was locked (random delay)

After this random delay, the postback gets sent from the user’s iOS device to the DSP. The postback does not contain any user level information (including IDFA) or the final conversion value (2). No more postbacks will be sent for this user even if the user makes a purchase later (anonymized postback).

With SKAdNetwork, postbacks are delayed and anonymized to protect user privacy, making it impossible for advertisers to leverage user level information (including IDFA) to target users.

So what does this mean for advertisers practically?

  • Optimizing for ROAS will be more difficult (you get one postback per user per app which means that it will be harder to track down funnel events that take longer to occur)
  • Re-engagement will not be possible (no IDFA in postback which means you won’t know which user has already installed the app)
  • Incrementality testing will not be possible (no IDFA in postback which means you can’t measure lift – if a user saw an ad or not)
  • Reporting will be limited to geo and top source apps (limited information in postback which means less ability to track performance)

So there you have it – that’s how SKAdNetwork works in a nutshell.

Subscribe for best practices to market and monetize your apps on iOS14

Weekly email while it's relevant ✉️