The SKAN 4.0 Rundown
In typical Apple fashion, a new version of SkAdNetwork (SKAN) was unceremoniously released to the public. Coupled with the rollout of iOS version 16.1, SKAN 4.0 brings us the most substantial measurement changes to its attribution system since its original release in April 2021. The features of the update were announced earlier this year to much fanfare at WWDC 2022, but based on sentiment from the mobile app marketing community since its release, it has failed to meet expectations. In the rest of this post, I will cover why that is, as well as what has changed in this version.
Hierarchical Source Identifiers
This feature is an evolution to the campaign identifier, which was previously the only actionable data attribute outside of ad network that was attached to SKAN data and limited measurement to just campaign performance. Some publishers provided modeling at ad set and ad level to fill in the gaps, but even with those efforts, this limitation made it inefficient to adjust audience targeting and run creative tests. In this update, you are now given a minimum of two identifiers with an additional two identifiers available if you bypass the privacy threshold. This means you will have at least one more additional data attribute to segment your data by and up to four if you have enough install volume per campaign! These identifiers are a set of integer slots so the information you store for each value is up to you. These values could represent anything from ad set to geography to creative. This change is probably the most impactful improvement for marketers, unlocking additional data points that help to provide clearer insights that can guide optimization.
Coarse Conversion Values
The postback conversion value structure has been updated to include a second value type called “coarse”. Coarse conversion values are not integer values like the currently supported conversion values known as “fine”. They are a fixed list of string values, “low”, “medium” and “high”. These values are returned in two postback scenarios when the privacy threshold is not met for the first postback (previously no values were sent) and if you surpass the privacy threshold, provided as the values for the second and third postback. Since both the coarse and fine conversion values are set at the same time, you will decide which values are mapped to each other (e.g. low|15, medium|22, high|28). This is a welcomed update for mobile apps with smaller marketing budgets, who struggled with measuring performance because the privacy threshold forced them to only be able to report on installs. Outside of this scenario, it is difficult to tell how helpful this value will be for reporting. While any data is better than none, at the end of the day the coarse value only serves as a directional data signal rather than a measurable business metric. Because of this, it is unclear how this new data point will improve measurement outside of cases where it can be used as an additional signal for statistical modeling.
Two additional postback periods, 3-7 days and 8-35 days (excluding postback delay) will now be provided if the privacy threshold is met. A welcomed improvement over the currently limited postback window (0-2 days). This new feature creates exciting prospects for cohorting and improved LTV signals, but is unfortunately limited due to the coarse conversion type and a 24-144 hours (1-6 days) postback delay. Such limitations in reporting make it unlikely to be helpful when making real-time performance optimizations.
One of the more disappointing releases is web-to-app tracking. Web-to-app tracking is finally supported for click-based attribution…but only for Safari browsers. While the WWDC announcement highlighted the technical architecture utilized Apple’s WebKit browser engine, an engine supported by all major browsers, it appears that Apple still considers mobile browsers like Chrome and Firefox to be mobile applications that have to adhere to AppTrackTransparency and SKAN policies. Depending on the mobile browser your users adopt, this limitation could be a major blow to the utility this tracking will provide.
What to do Next
There is still a good amount that is unknown about the publisher and mobile measurement partner adoption. If you rely on both for your marketing efforts, then it is a waiting game to see what changes will need to be made to adopt this version of SKAN. If you are maintaining the SKAN SDK in your application, you are able to update the SDK today, but you are still limited by the fact that publishers have yet to indicate that they have updated their systems to support SKAN 4.0. Until announcements are made, you will have to sit tight and wait to utilize these features.
What to Think of the Update
While the update provides an improvement to get marketers excited about new reporting capabilities, there are still many inefficiencies with the attribution system that are holding back many organizations from expanding their paid marketing programs. Apple has mentioned that they are listening to the community when making improvements, but based on general community sentiment, it feels like most voices are going unheard. More SKAN development, at a faster rate, will be needed to get SKAN to an acceptable measurement state. Until then we will have to use what we are provided and come up with clever ways to fill in the gaps.