Mobile attribution is changing dramatically.
Tools like Apple’s SKAdNetwork (SKAN) and Google’s Privacy Sandbox are changing how campaign reporting works at the most basic level.
But to understand these changes, marketers need to understand the basics, including the most important element of mobile attribution: postbacks.
A postback is a notification signal that allows two parties to exchange information about ad exposure related to conversion events such as app downloads and in-app purchases.
Unlike pixel-based tracking, which takes place within the user’s web browser, postbacks involve data exchange between servers.
Attribution and optimization
However, the information coded into the postback does not reveal what data the user has consented to be shared, what the operating system allows, and whether the advertiser or mobile measurement partners working on the advertiser’s behalf ( MMP) depends on how they package and anonymize information.
Postbacks can include almost anything related to a conversion, including the campaign creative that prompted the user to convert, the app the ad was placed in, the amount spent on in-app purchases, the terms of paid subscriptions, and more.
Advertisers use this report to provide lookalike modeling and retargeting information to determine user lifetime value. Ad networks use this information to bill advertisers for conversions.
Postbacks may contain identifiers that can be tied to a particular device, such as mobile device IDs or IP addresses, but ever since Apple began requiring consent by default on iOS several years ago, device IDs have been became difficult to do. Google also restricts the use of these identifiers.
InMobi’s head of DSP product marketing Sarah Camden said instead of device IDs, Postbacks can use proxy signals that give advertisers insight into device types without personally identifying them.
These signals can include everything from the operating system running on the device to battery life and memory storage. However, the use of these signals can constitute fingerprinting, and Apple plans to restrict these use cases starting with his iOS 17 update in September.
How postbacks work
But how does this information flow between parties?
In the past, when someone clicked an in-app ad, they were redirected to the app store where they could download the app. When a user clicks to download, the ad network that delivered the ad (such as AppLovin or IronSource) notes the user’s device ID and passes it to her MMP for attribution purposes.
When that user opens the app for the first time, the developer’s MMP pairs an install with a successful ad impression and/or click. This can be done through SDK integration with apps and ad networks.
MMPs package information about ad impressions and resulting clicks or installs into postbacks and send them to the winning ad network. Ad networks can use the information in postbacks to identify the campaign that caused the conversion. This allows you to optimize future campaigns by targeting other devices that behave similarly and are more likely to convert.
This process enables optimization of mobile campaigns, said Evgeny Perez, vice president of product strategy at AppsFlyer, which operates the MMP. Without the conversion data feedback loop between the advertiser and the ad network, the ad network doesn’t have the real-time information it needs to optimize.
Generally, postbacks are only sent to ad networks responsible for delivering impressions that lead to conversions, Perez said. However, ad networks may want to receive postbacks for all conversions associated with their campaigns, including conversions that occur outside of their platform. That way you can learn from what has shown good performance on other platforms.
Postbacks can also be sent to third parties. For example, a customer relationship management (CRM) platform can receive and track postbacks when someone adds an item to their cart but doesn’t make a purchase. Your CRM can then flag that user as a retargeting lead through a push notification or email campaign.
Finally, you could send the postback directly to a server controlled by the advertiser, but that’s less common, Perez said. Advertisers typically manage attribution settings and postback signals through an MMP.
This whole process works slightly differently for self-attributed networks (SANs) such as Facebook, Google, and Twitter. Rather than sharing default opted-in device IDs with MMPs, SANs require MMPs to provide device IDs for installations they want to track. Once SAN confirms an ID match within its own platform, SAN claims credit for the install by providing his MMP with attribution data from the ad.
The evolution of postbacks
Just to be clear, postbacks are nothing new. Since in-app advertising lacks cookie- and pixel-based tracking, it has been part of mobile he attribution for at least as long as MMPs have existed, i.e. for over a decade.
Lately, however, postbacks are often discussed in the context of Apple’s privacy-focused SKAN updates, as each new version of SKAN tweaks the behavior of postbacks on iOS.
With the latest version of SKAN4, postbacks include a campaign ID of up to 4 digits. These numbers act as codes that apps and ad networks use to track who clicks on ads without passing the device ID.
MMPs are responsible for decoding campaign IDs provided by ad networks on behalf of app developers. For example, if the network uses the number “5” to identify devices in her APAC countries, the MMP will recognize those postbacks as part of her APAC campaign region.
SKAN4 postbacks also include conversion values set by the app developer based on the post-install conversion actions the user has taken within the app. Users are assigned a fine conversion value from 0 to 63, or a low, medium, or high coarse conversion value.
However, postbacks are widely used outside of SKAN and come in many different forms.
Levi Matkins, CEO of mobile DSP LifeStreet, said non-SKAN postbacks may contain more detailed data. For example, you can include a specific event name such as “Purchase Event” or an exact number such as “$0.99”.
In addition to overhauling the postback format, SKAN also changed some other fundamental aspects of how postbacks actually work, according to Katie Madding, Chief Product Officer at MMP Adjust.
Through SKAN, Apple gets information about which ad impressions lead to conversions before MMPs, Mading said. Apple then applies privacy protections before sharing conversion data with his MMP.
The Google Privacy Sandbox’s Attribution Reporting API will similarly provide mobile platforms with an initial crack before conversion data is received by MMPs, said Mading. The network registers an ad impression or click, the MMP registers a conversion, Google gives attribution and he sends a postback to the MMP and the network.
It’s unclear how postbacks will be formatted in the Google Privacy Sandbox, which is still in beta. However, Google says it will use two different formats: “event-level reports” that quantify user quality based on conversions, and “aggregatable reports” that provide limited information about campaign performance. is.
what’s the point here?
Mobile attribution is changing, and Apple and Google now have more control over what data can be included in campaign reports. To monitor these changes, the advertiser will need to work closely with her MMP to understand how postbacks behave across different platforms and how the functionality is evolving. there is.