SKAN 4.0 anomalies explained: zeros, “none” conversion values and more
In the past two weeks, the industry has been abuzz with discussions about SKAN 4.0 and the issues it’s causing. There’s a lot of information going around, so let’s dive into the details:
What’s the fuss all about?
- A couple of months ago, AppsFlyer notified customers that Apple Search Ads (ASA) was initiating SKAdNetwork, causing issues for SKAN 4.0. We covered this update in an email to customers and a blog post on SKAN 4.0 testing. Additionally, we raised the matter with Apple in June.
- During our testing of SKAN 4.0, we noticed a large number of “none” coarse values — an undocumented conversion value option (read on to learn in which circumstances SKAN generates a “none” conversion value).
- Since Meta migrated to SKAN 4.0, multiple apps have experienced a surge in conversion value “0” postbacks. As a result, on August 3rd, Meta reverted back to SKAN 3.0.
SKAN 4.0 and decreasing conversion values
One of the latest features of SKAN 4.0 was the introduction of a new ability to decrease conversion values. As part of this feature, SKAN 3.0 conversion value updates and registrations for installs override SKAN 4.0 updates(basically, any CV update overrides the preceding one).
Why is this a problem?
Potentially, assuming only one SDK controls SKAdNetwork from within the advertiser app, this design by Apple wouldn’t have been an issue (since, presumably, if only one party updates SKAN then this party knows what they’re doing and doesn’t mix SKAN 3.0 and SKAN 4.0 updates). But, we know this is not the case. Multiple SDKs initiate or update SKAdNetwork.
In our case, due to the above explanation that SKAN 3.0 updates override SKAN 4.0 updates, this causes a major issue of either “none” conversion values or an inflated number of “0” conversion values.
Why so many zeros?
In previous versions of SKAN, as mentioned above, conversion values could only go up. As a result, different SDKs decided to initiate SKAN by default. On SKAN 3.0, this isn’t a problem. The initiation of SKAN creates conversion value 0 by default.
Let’s consider a scenario where AppsFlyer’s SDK updates the conversion value based on the advertiser’s definitions in Conversion Studio, and it has been set to 35. Now, let’s assume that “SDK two” attempts to initiate SKAN every time the app is opened. In SKAN versions 2.0 to 3.0, this behavior of “SDK two” wouldn’t cause any issues. However, in SKAN 4.0, “SDK two” overrides AppsFlyer’s SKAN updates and resets the conversion value to zero.
Where did “none” come from?
On SKAN 4.0, Apple introduced two types of conversion values: fine conversion values and coarse conversion values. When the first postbacks are generated, they can either include fine conversion values, coarse conversion values, or null, depending on privacy thresholds and tiers.
The party that determines if the postback is going to be SKAN 3.0 or SKAN 4.0 is the ad network (when signing the ad).
Let’s consider a situation where the privacy tier dictates that the postback should return a coarse conversion value. However, if an SDK from the advertiser app updates conversion values based on SKAN 3.0, then SKAN 4.0 can’t provide a coarse conversion value as none was set. Consequently, the postback will be returned with the coarse conversion value “none”.
What does it have to do with Apple Search Ads (ASA)?
It’s worth noting a peculiar situation regarding ASA and its interaction with SKAN. ASA doesn’t have an SDK and isn’t directly connected to SKAN, so why is it causing issues with SKAN 4.0?
Well, in order for an install to be eligible for attribution by ASA, the app developer or an SDK needs to activate ASA. During extensive testing back in June, we found that ASA activates SKAN 3.0, resulting in an increased number of “none” conversion values.
Regarding why ASA activates SKAN, our educated guess, based on Apple’s statement, is that if an ASA click was the last one before an install, SKAN will not send a postback to any other ad network. Our assumption is that product behavior is related to why ASA activates SKAN.
What should I do next?
As we suggested to our customers, it’s a good idea to update your SDK version to 6.12.1 to prevent ASA from overriding SKAN 4.0 updates.
AppsFlyer is actively conducting continuous tests and will keep you informed of any new findings. Make sure to subscribe to our blog post for regular updates.
