5 wrong assumptions advertisers have about SKAdNetwork
Apple announced some dynamic changes this past year and pushed a revival of an older attribution channel solution.
From a two-year-old technology that was barely discussed beforehand, SKAdNetwork has quickly become the hottest topic, driving both hope and concern for advertisers facing the upcoming privacy shifts from Apple. Advertisers are expressing extensive concern about SKAdNetwork; there is uncertainty in how to use it in day-to-day marketing decisions.
There are complexities in the setup (aggregate data, conversion values, timers), and uncertainty as to how this ties into the bigger picture from Apple.
Over the last few months, we have conducted extensive discussions about SKAdNetwork with hundreds of advertisers globally, ranging in fields from gaming to e-commerce, finance, food delivery, and from enterprise and SMBs. Based on these broad discussions, we’ve prepared a list of the most frequent, wrong assumptions existing in the industry about SKAdNetwork.
1. The timer misconception
Let’s start with timers, extensions, and delays which are a fairly easy misconception to explain. SKAdNetwork has a 24hr timer attached to it, which begins when the SK function is called for the first time (usually upon first app launch). After the 24-hour timer expires, the conversion value is locked in.
The good news is, advertisers can still play around with the timer using timer extensions and methods to delay the locking mechanism.
Timer extension
In some cases, advertisers require more than 24 hours of post-install user activity for optimizing campaign effectiveness; one example might be a gaming app, where an advertiser wants to optimize based on day 5 revenue.
The workaround for timer extensions is simple: if an increase in conversion value is triggered by an app open, the timer will be reset for an additional 24 hours. This function can be carried out numerous times; in theory, you could continue resetting this timer for up to two months.
The problem with this approach is that it depends on a user launching the app daily (within the 24-hour window). Should they not open the app for one day, the timer will not reset, thus cutting the loop.
What’s more, this approach will generate a biased audience, where measurement and optimization are heavily based on the activity of your most engaged users; hardly representative of the entire user base.
This approach also delays the single SK postback beyond the usual 1-3 days and requires an allocation of bits of the conversion value for the extension mechanism (for example a 7-day delay requires 3 bits, leaving only 3 bits for actual measurable data).
Timer delay
Another solution to the timer limitation is a timer delay, which ensures the measurement and optimization of events occurring down-funnel (such as subscriptions after a 7-day trial or a first in-app purchase).
You can delay the timer to start only when the initiation of an event occurs. This is done by delaying the first call to registerAppForAdNetworkAttribution and updateConversionValue functions.
As mentioned above with each of these workarounds there is a tradeoff. On the one hand, delaying the timer prompt ensures measurement of the chosen event, but if the user churns before the event occurs, no postbacks will be sent.
In other words, you’ll get 100% coverage of the number of users who performed this event, but you won’t know how many downloaded the app and churned before the event was completed.
2. The 6 bits misconception
Indeed, the conversion value is a very limited resource. A single field of 64 values, that must contain every detail about the user’s journey. Though limited, one field can still decode different KPIs. There isn’t a ‘one size fits all’ approach here, and strategy will differ between apps and KPIs.
There are two methods to approach this: bit splitting and the 64-segment approach.
Bit splitting
Bit splitting is used to enable the measurement of several KPIs in parallel: revenue, engagement, conversion, retention, and more. Advertisers can allocate different numbers of bits for each KPI, but it’s important to remember that the more bits you split, the less granular the KPI data will be.
You could, for example, allocate your bits this way: 3 bits for revenue, 3 bits for level completion. However, this will only grant you 8 levels of granularity per KPI, rather than the 64 you’d have for a single KPI. If you split your bits 6 ways, you’ll only get 2 levels per each KPI (binary).
The 64-segment approach
The 64-segment approach enables you to measure more than six different in-app events while grading end-users based on segments instead of directly allocating a bit per event.
This can be done by defining 64 different segments of users. For example, a single bucket can hold the following data:
- event1 happened 2-6 times
- event2 happened more than 10 times
- total revenue is $20-$60.
With this method, you can define an unlimited number of KPIs and events for each segment. The tradeoff with this approach is that you won’t be able to decode back the value to a specific KPI (such as revenue).
It also requires you to be extremely careful in validating these 64 segments, making sure they cover the entire range of app users with no duplication between segments. Basically, each user must fall into only one segment, always.
3. The configuration change misconception
Server-based solutions for SKAdNetwork (like AppsFlyer’s) enable advertisers to change the conversion value configuration in the cloud, where a command will be sent instantaneously to the SDK. This ensures that customer logic is always up-to-date with the desired configurations.
As with many things in SKAdNetwork, tradeoffs are a key element here. In this case, each configuration change triggers a short period of time in which it’s impossible to determine whether incoming postbacks relate to the old configuration or the new one, creating extra “noise” in the measurement.
That’s why we don’t recommend changing strategies too frequently (more than once a week, for example).
We’ve got some good news for you: there’s a workaround for this. It requires you to dedicate 1 of the 6 bits to indicating if the postback relates to the old configuration or the new one.
However, as with SKAdNetwork, this introduces another tradeoff: if you want the flexibility to frequently change strategies, you’ll have to compromise on the level of granularity you can measure for your KPIs.
4. The parallel strategy misconception
There is a way to activate different strategies for different segments of users. The basic requirement is that the parameter that distinguishes the groups will be known both on the client-side (when changing the conversion value) and on the server-side (to know how to decode the value).
A couple of recommended segmentations:
Segmentation based on geo
Measuring different KPIs for different geographical regions. For example, measure revenue for users in France and engagement for users in the US.
Segmentation based on random splitting
By dividing the end-users randomly into A/B groups, you can measure your KPIs in parallel without compromising on granularity. The technicalities of random splitting require that one bit be allocated for the A/B decoding; e.g. bit 1 indicates to the server-side what bits 2-6 are measuring.
Unfortunately, not all types of group splits are possible; a split based on a media source, for example, can’t be done, as this parameter is still not known on the client-side when changing the conversion value (as attribution data is known only on the server-side).
It’s important to note that random split results must be scaled up, as must postbacks to the networks. This can be carried out automatically by AppsFlyer’s split solution. Make sure your MMP supports this as well.
Get the latest marketing news and expert insights delivered to your inbox
5. The server events misconception
A cloud-based solution can forward events to the client-side, changing the conversion value accordingly. However, this type of flow has another limitation not presented for client-based events: even if the server-based event was triggered before the SKAdNetwork timer expires, the end-user must reopen the app again before the timer expires in order for that event to affect the conversion value.
For this reason, we recommend sticking with client-generated events wherever possible.
If, despite this limitation, you would like to measure and optimize based on your servers/CRM logic, make sure that your SKAdNetwork framework supports this option. AppsFlyer is proud to be the first server-to-server compatible SKAdNetwork solution.
Gaining opportunity out of a challenge
There’s no question: SKAdNetwork presents new challenges to marketers. No more “measure everything” and “optimize campaigns based on everything”. That doesn’t mean, however, that this is the end of marketing optimization. There are still plenty of opportunities to measure, optimize, and excel.
Getting comfortable with all the bits and bytes of the conversion value (pun intended), proper planning, testing, and validating assumptions will ensure you’re making the most out of a less-than-perfect solution. Advertisers can set themselves miles ahead of the competition by taking strong action and working with the best framework to support their measurement needs.
Clearing up these 5 misconceptions is a great start, isn’t it?
