February 3rd, 2021
This article was originally published on February 3, 2021, but has since been updated.
Apple issued a number of changes on January 28, as part of Data Privacy Day. While the AppTrackingTransparency enforcement details got most of the initial mobile privacy buzz, they also teased a couple new pieces of attribution-related functionality:
Sure enough, Apple dropped the first iOS 14.5 beta the following Monday morning with both features included, along with technical documentation. Let’s unpack these new concepts, and take a look at what they mean for mobile marketers.
First of all, with these introductions, Apple is beginning to close some of the gaps in their new world order of mobile attribution. As the table below shows, there are still many things left to do before the new systems are even close to replacing what was possible pre-iOS 14 (and that’s not even counting the loss of data granularity and reporting transparency), but at least Apple seems to be making an effort.
* There are notes in the PCM update indicating Apple may add support for these later, but that they do not yet have “privacy-preserving solutions.”
** Apple SKAdNetwork offers a redownload parameter beginning with v2, however most re-engagement campaigns are designed to drive in-app activity, not re-installs.
Prior to SKAdNetwork 2.2, the only way to trigger a SKAN “touchpoint” was displaying a StoreKit-rendered ad via the SKStoreProductViewController framework. We’re all familiar with this experience by now: you tap (click) on an ad, and a view of the App Store pops up inside a modal view.
To enable view-through support, Apple has added two new concepts to SKAN:
There are a few other interesting tidbits in the updated SKAdNetwork documentation:
This page notes that view-through impressions must last a minimum of 3 seconds, likely as a brute-force attempt to cut down on potential fraud:
This page mentions a limit of 15 view-through ad impressions per source app:
The limit appears to apply regardless of what the source app is advertising, which could present a problem for a high-density ad implementation (i.e., if a game shows view-through ads for 16 different apps over the course of a 1-hour play session, the first touch point will be discarded).
Finally, this page summarizes the details of Apple’s attribution windows for SKAN. Most of it is not new information, but it’s helpful to finally see this centralized in one place:
Adding support for the new view-through SKAN ad types will mostly fall to publisher apps and their supply-side partners — ad networks and MMPs like Branch will need make minor changes to any logic that handles incoming SKAdNetwork postbacks (Branch already deployed this change yesterday, and the new parameter will be visible in dashboard reports shortly), but this doesn’t change anything fundamental about how SKAdNetwork works. In particular, there is still only ever a single postpack per install, regardless of the touchpoint type.
Apple’s PCM framework was originally developed by the WebKit team as an alternative to the cookie-based measurement blocked by ITP (Intelligent Tracking Prevention). It was pitched as a standard for web-to-web attribution, but iOS 14.5 extends this to support app-to-web attribution.
This new functionality is useful primarily to large publisher apps (for example, Facebook) that show in-app ads leading to web conversion. In the past, these campaigns would typically have been measured via URL parameters, but Apple appears to consider this a violation of the AppTrackingTransparency policy.
In-app support for PCM gives these publishers a policy-compliant way to attribute app-to-web campaigns, without requiring users to opt in via the AppTrackingTransparency prompt first. However, for a typical mobile marketer focused on app acquisition, this new app-to-web attribution functionality is largely irrelevant.
While these new additions are good, it’s also useful highlight a few examples of common conversion paths that PCM/SKAdNetwork still do not currently support:
It’s encouraging to see that Apple continues to iterate on this (though the frequent, code-level changes really expose the pain of Apple’s model of relying on app-side implementation changes for every new piece of functionality), and hopefully there will soon be solutions for the remaining gaps.