Mobile attribution is in upheaval.
Tools like Apple’s SKAdNetwork (SKAN) and the Google Privacy Sandbox are changing how campaign reporting works at its most basic level.
But to make sense of these changes, marketers need to understand the fundamentals, including postbacks – the most essential element of mobile attribution.
Postbacks are notification signals that allow two parties to exchange information about an ad exposure associated with a conversion event, such as an app download or an in-app purchase.
Unlike pixel-based tracking, which occurs within a user’s web browser, postbacks involve a server-to-server exchange of data.
Attribution and optimization
But the information coded into a postback depends on what data a user consents to share, what the operating system allows and how an advertiser or the mobile measurement partner (MMP) working on its behalf packages and anonymizes the information.
A postback can contain nearly any conversion-related information, including the campaign creative that prompted a user to convert, the app in which the ad was placed, how much someone spent on an in-app purchase or the terms of a paid subscription.
Advertisers use this reporting to inform lookalike modeling and retargeting and to determine a user’s lifetime value. Ad networks use this information to bill advertisers for conversions.
Sometimes postbacks contain an identifier that can be tied back to a specific device, such as a mobile device ID or IP address, although device IDs have become harder to come by since Apple began requiring consent by default on iOS several years ago. Google also restricts the use of these identifiers.
Instead of device IDs, postbacks can use proxy signals that give advertisers insights into device type without specifically identifying a person, said Sara Camden, head of product marketing for InMobi’s DSP.
These signals can include everything from the operating system running on the device to its battery life and memory storage. However, the use of these signals could constitute fingerprinting, and Apple plans on restricting these use cases starting with its iOS 17 update in September.
How postbacks work
But how does this information flow between parties?
Historically, when someone clicks on an in-app ad, they get redirected to an app store where they can download the app. When they click to download, the ad network that served the ad – AppLovin or ironSource, for example – makes a note of the user’s device ID and passes it along to the MMP for attribution purposes.
Once that person opens the app for the first time, the developer’s MMP pairs the install with the successful ad impression and/or click, which it can do through its SDK integrations with the app and the ad network.
The MMP packages the information about the ad impression and the resulting click or install into a postback, which it sends to the winning ad network. The ad network can use the information in postbacks to determine the campaign responsible for the conversion, which helps it optimize future campaigns by targeting other devices with similar behavior and a higher likelihood to convert.
This process makes mobile campaign optimization possible, said Yevgeny Peres, EVP of product strategy at AppsFlyer, which operates an MMP. Without the conversion data feedback loop between the advertiser and the ad network, ad networks would have no real-time information to optimize against.
Generally, postbacks are only sent to an ad network if it’s responsible for serving an impression that results in a conversion, Peres said. However, ad networks sometimes want to receive postbacks on all conversions associated with a campaign, even those that happened outside their platform. That way, they can learn from what performed well on other platforms.
Postbacks can also be sent to third parties. For example, a customer relationship management (CRM) platform could receive a postback to track when someone adds an item to their cart but doesn’t purchase it. That way, the CRM can flag that user as a prospect for retargeting via push notifications and email campaigns.
Lastly, postbacks can also be sent directly to a server controlled by the advertiser, but this is less common, Peres said. Advertisers typically manage their attribution configuration and postback signals through an MMP.
This whole process works slightly differently on self-attributing networks (SANs), such as Facebook, Google and Twitter. Rather than sharing opted-in device IDs with an MMP by default, SANs require MMPs to provide the device ID for installations they’re trying to track. Once the SAN confirms an ID match within its own platform, it claims credit for the installation by providing attribution data from the ad to the MMP.
The evolution of postbacks
To be clear, postbacks aren’t anything new. Due to the lack of cookie- and pixel-based tracking for in-app ads, they’ve been part of mobile attribution at least as long as MMPs have existed, meaning well over a decade.
But these days, postbacks are frequently discussed in the context of Apple’s privacy-focused SKAN updates, since each new version of SKAN has tweaked how postbacks work on iOS.
In the most recent version, SKAN4, postbacks include a campaign ID that contains up to four digits. These digits serve as a code that the app and the ad network use to keep track of who’s clicking ads without having to pass device IDs.
The MMP is responsible for decoding the campaign ID provided by the ad network on behalf of the app developer. For example, if the network uses the number “5” to identify devices from APAC countries, the MMP would attribute those postbacks as part of the APAC campaign region.
SKAN4 postbacks also include a conversion value set by the app developer that’s based on post-install conversion actions a user has taken within an app. Users are assigned a fine conversion value between 0 and 63, or a coarse conversion value of low, medium or high.
But postbacks are widely used outside of SKAN, and the formatting varies.
Non-SKAN postbacks can contain more detailed data, said Levi Matkins, CEO of mobile DSP LifeStreet. For example, they can include a specific event name such as “purchase event” and an exact numeric value such as “$0.99.”
In addition to overhauling postback formatting, SKAN has changed several other fundamental aspects of how postbacks work in practice, said Katie Madding, chief product officer at MMP Adjust.
Via SKAN, Apple receives information about ad impressions that result in conversions before the MMP does, Madding said. Apple then applies its privacy protection features before sharing conversion data with the MMP.
The attribution reporting API in Google Privacy Sandbox likewise gives the mobile platform first crack at conversion data before an MMP receives it, Madding said. The network registers the ad impression or click, the MMP registers the conversion, and Google awards the attribution and sends postbacks to the MMP and the network.
How postbacks will be formatted in Google Privacy Sandbox, which is still in beta, is to be determined. But it appears Google will be using two different formats: “event-level reports,” which quantify user quality based on conversions, and “aggregratable reports,” which provide limited information about campaign performance.
What’s the takeaway here?
Mobile attribution is transforming, and Apple and Google are taking more control over what data can be included in campaign reporting. To keep tabs on these changes, advertisers should work closely with their MMPs to understand how postbacks work on the various platforms – and how the functionality is evolving.
