Postbacks and Conversion Tracking with SKAdNetwork

This is the second of a series of posts regarding mobile marketing industry changes presented by iOS 14. Read the first article about the SKAdNetwork framework here.

In my last article I went into detail about the structure of the SKAdNetwork framework. Today I'll continue by explaining how postbacks and conversion tracking work with this new framework.

Tracking Conversions with SKAdNetwork

This diagram explains how SKAdNetwork handles tracking conversions:

The initial user journey is the same: ads are served by ad networks to users, who click to install an app. The real changes begin when the user actually converts. There are two ways to send conversion postbacks via the SKAdNetwork API:

1. registerAppForAdNetworkAttribution()
2. updateConversionValue(_:)

The first method is recommended for when the user first launches the app. Once the app is launched, an activity window of 24 hours begins and the second method can be used to monitor user activity. SKAdNetwork allows you to attach events to 6-bit integers (numbered 1-64). When these events are triggered by the user, the integer is passed to the second method and the activity window restarts. This continues until 24 hours pass without the user triggering an event with a 6-bit integer value greater than before.

Example: SKN Games

Take a hypothetical gaming app, SKN Games, as an example. In this app, each level is mapped to a 6-bit integer value in SKAdNetwork (level #1 has a value of 1, level #2 has a value of 2, etc.). Whenever a user completes a level (through level 64) it triggers a conversion event. The conversion window would work something like this:

1. A user installs the SKN Games app, registerAppForAdNetworkAttribution() is called, and the 24-hour activity window begins.
2. The user clears level #1 within 24 hours, and updateConversionValue(_:) is called with a value of 1. The 24-hour activity window restarts.
3. The user continues clearing subsequent levels. As long as each level is cleared within 24 hours of the last, updateConversionValue(_:) will be called with a value that corresponds to the last level completed.
4. The user either does not clear a higher level within 24 hours, or reaches level 65 (64 is the highest possible 6-bit integer value). The activity window ends and a second timer begins with a random value between 0-24 hours. User activity is no longer being tracked.
5. The second timer elapses, and a postback is sent with all the information the user generated within the activity window.

Receiving the Postback

The postback received by the ad network will take the following JSON form:

{
  "version": "2.0",
  "ad-network-id": "com.example",
  "campaign-id": 42,
  "transaction-id": "6aafb7a5-0170-41b5-bbe4-fe71dedf1e28",
  "app-id": 525463029,
  "attribution-signature": "MDYCGQCsQ4y8d4BlYU9b8Qb9BPWPi+ixk\\/OiRysCGQDZZ8fpJnuqs9my8iSQVbJO\\/oU1AXUROYU="
  "redownload": 1,
  "source-app-id": 1234567891,
  "conversion-value": 20
}

This shows that for each converted user, the ad networks will only receive:

• The campaign ID associated with the user (NOT the adset or ad)
• Whether the user was a redownload or new download
• The highest conversion value that the user triggered within the activity window, up to 64

Conclusion

This new information is fundamentally different from the view-thru attributed data mobile marketers currently have access to. With no IDFA, aspects of campaign structure will need to change to make use of this new information.

But why is the IDFA no longer usable? To understand that, it's important to learn about AppTrackingTransparency, which I will explain in more detail in my next post.

To learn more about Xyla's reporting capabilities under iOS 14, reach out to us.