Who should own the conversion value in SKAdNetwork?
Until recently, very few people had ever heard of the term SKAdNetwork (or SKAd). Recent developments, however, have more and more people realizing that it’s going to play a major role in the marketing ecosystem in the post iOS 14 era.
In a recent blog post, we presented AppsFlyer’s solution towards SKAd, and how we overcame its limitations to maximize the values the ecosystem can get out of it. Our solution includes collection, validation, enrichment, enablement, and seamless integration with both advertisers and ad networks.
In the center of the SKAd mechanism, however, there is one special field: conversion value.
In this blog post we will explain why this field is so important, how to get the most out of it, and mostly answer one of the most frequently asked questions as of late: who should control/change the conversion value, and when?
The value of the conversion value
The conversion value is a field with the range 0-63 (integers only), fully controlled by the advertised app. The SKAd postback sent from Apple to the attributed ad network simply forwards that value. Simple, right? Then why is it so important?
To answer that question, let’s imagine what SKAd would look like without it. It’s actually not that hard to imagine, as V1 of SKAd worked precisely like that.
Without this field, SKAd insights would look something like this:
My app had 100 installs from Campaign A last week, and 200 installs from Campaign B. Does this mean that Campaign B is better? Not necessarily. Maybe the users from Campaign A are performing much better as far as my KPIs go?
That’s what the conversion value is all about. It enables the app owners to “grade” their end users. For example: how much revenue was generated from the user? How many levels did they complete in my game? How many times did they click on an ad?
With conversion values, marketing insights are far more, well, insightful. With conversion values, we can reach conclusions like this one: “Though Campaign B generated twice as many installs, the users from Campaign A generated far more revenue and are more engaged.”
Great, so conversion value is all you’ve ever needed, right?
Well, not quite.
First of all, all data needs to be “encoded” to a single field, with a range of 0-63. This means that app owners can’t measure everything. They need to choose what’s mostly important for them to measure.
Second, there are timing limitations based on the timer mechanisms of SKAd.
Without going into all the bits and bites:
- Measuring events which happen more than 24 hours post-install is complex. It requires the app to be opened every day until the event occurs, or some background thread to reset the timers periodically.
- Every update resets the timers, causing the (already delayed) postback to be delayed even more. Eventually, this delay makes short term optimization almost impossible.
So it’s controlled by the advertised app. Where’s the dilemma?
Right, eventually it will be controlled by the advertiser.
Can advertisers really maximize its value on their own? The answer is no, and app owners realize this as well. This is the reason big players in the ecosystem are already building solutions to help advertisers with this.
Before diving into the details, it’s important to note that if two separate entities try to control the conversion value in parallel, chaos will ensue; in fact, nothing will work. Even worse, no one will realize that nothing works, and misguided marketing decisions and optimization attempts occur.
App owners – make sure only a single entity is controlling this field on your behalf.
If you’re a provider aiming to control the conversion value – make sure the app owners name you the owners before making changes to conversion values.
Getting the most out of conversion values
As mentioned, getting the most out of conversion values actually means getting the most out of SKAd. Checking off the items below means you made the right choice.
1. Single management
Assumption: Conversion value mapping will be changed frequently by the app owner. As the 6 bits of data can answer only specific marketing questions, the UA manager will change them over time to validate that budgets are being spent efficiently.
Requirement: Mapping changes should be done in a single place, in one dashboard. App owners shouldn’t have to manage these in several places every time they change the configuration.
2. Full server-side encapsulation
Assumption: Conversion values can only be changed on the client side. Does it mean that you’ll need to change your app code for every mapping change? Well, no.
Requirement: Change mapping in a SaaS dashboard anytime you want. The actual mapping should be commanded immediately to the app side, without the need to release a new version to the app store.
3. Simple set up
Assumption: Conversion value mapping will rely on the already existing in-app events of the app.
Requirement: Conversion value configuration should be done by an entity that has already mapped these events, to ensure easy configuration and fewer errors.
4. Flexible configuration
Assumption: In order to get the most out of these 6 bits, full flexibility is needed.
Requirement: Unlimited set of options for the advertiser. Whether they want to measure revenue, conversions, engagement or a combination of these three.
For example:
- 2 bits for revenue, 3 bits for engagement, 1 bit for more precise install time
- 4 bits to measure conversions of 4 different events, 2 bits for user’s avatar type
Can this full flexibility coexist with simplicity? The answer is yes.
5. Parallel / multi-mode support
Assumption: App owners will have more than one marketing question they want to answer at any given point.
Requirement: Optimize and analyze campaigns for two KPIs in parallel, by splitting the end users, whether based on geo or on a random split.
Eventually, such a split can help app owners to measure revenue in high granularity in parallel to engagement and conversions. That’s priceless when having only one field of data.
NOTE: When using a random split, make sure your dashboard knows to scale up the results accordingly.
6. Configurable window length
Assumption: Some app owners need to focus on events that occur more than 24 hours post-install.
Requirement: Easy configuration (from server-side) of the attribution window length for changing the conversion value. As always, a modification shouldn’t require any code change or release of a new app version.
7. S2S and server triggered events
Assumption: Some advertisers generate events based on server/CRM logic.
Requirement: A flow to notify the client side based on server generated events, to change the conversion value accordingly (as this can only be done from client side).
8. Predict user quality based on their initial engagement
Assumption: Measuring events 24+ hours post-install is limited in SKAd, so there is immense value in understanding the quality of your users based on their initial engagement with the app.
Requirement: ML/AI algorithms predicting the long term LTV or ROI of a user based on their engagement in the first 24 hours.
9. Minimize potential manipulations on-the-go
Assumption: Advertisers don’t have direct access to the postbacks. To make it worse, the conversion value field isn’t signed by Apple, so they cannot be verified and could potentially be manipulated before being sent to the advertisers.
Requirement: The one controlling the conversion value should be someone you completely trust. Make sure they’re unbiased and represent your interests, and yours alone.
In addition, make sure they rotate the mapping frequently to make malicious manipulation more difficult to carry out. Eventually, fraudsters shouldn’t be able to assume the meaning behind the conversion value and shouldn’t be able to learn its patterns.
10. Validate data by correlating it with other attribution models
Assumption: Some players might still try to manipulate the SKAd data.
Requirement: Correlate SKAd data with additional attribution models. For example, if SKAd shows completely different numbers than the probabilistic model for a specific campaign, a fraud indication should be raised.
11. Data consumption
Assumption: some app owners would love to see their marketing insights through configurable dashboards, and some through API calls.
Requirement: Translating conversion values before sending them to the advertiser isn’t going to be an easy task. Mapping will change over time, and might differ between geos and users. Sometimes scaling up will be needed. Validate the entity doing that for you takes all of that into consideration.
12. Support campaign optimizations
Assumption: Ad networks need to translate the conversion value in order to optimize their performance upon the KPIs of each app.
Requirement: The entity controlling the conversion value must integrate with all ad networks, and translate to them the real meaning of the conversion value per each postback.
13. Support future changes by Apple
Assumption: v2 of SKAd will soon be replaced by v3, v4 and v5. SKAd will play a major role in the post iOS14 era, and improvements by Apple will surely follow.
Requirement: Work with someone that will stay on top of these changes, and can change logic without the need to update app code or release new versions.
Can advertisers do all of that on their own?
Some of it – Yes, other parts – absolutely not.
With substantial resources, advertisers can create a server-based entity which sends commands to the client side, collects the in-app events, calls the OS functions and rotates frequently. They can also look out for changes performed by Apple and adopt accordingly.
But then there’s the part where they need to collect postbacks from all of the different attributed networks. Can advertisers do it? Are they ready to go out and collect data from dozens of different networks, deal with the scale and the different integrations?
Even if advertisers theoretically do all of that, they now have an almost impossible mission: posting back the meaning of each conversion value to each of the networks for campaign optimization purposes. App owners simply do not have a mechanism for doing that, and it’s crucial! Without it, networks can’t optimize their campaigns for the benefit of the advertiser. App owners need someone who already has these integrations and mechanisms in place.
Get the latest marketing news and expert insights delivered to your inbox
So, bottom line: who should control the conversion value?
The immediate candidates are: ad networks, analytics tools, and MMPs.
Why ad networks can’t be the answer
We could say that they don’t have integrations with other networks, so campaign optimizations are at risk. We could say that attribution is not their expertise.
Why MMPs are the best choice
Trusted and unbiased – by definition, MMPs don’t have conflicting interests. Their only goal is to deliver reliable, accurate data to the advertiser.
Campaign optimization – MMPs are the only ones who already have these integrations with all networks. Without them, campaign optimizations can’t work.
Enrichment for the different attribution models – SKAd doesn’t exist in a vacuum, there are other attribution models out there. App owners want all models to enrich each other. Furthermore, only an entity that owns other models can ensure that SKAd data is aligned and that no manipulation has occurred. A “clean” environment is a key element for accurate marketing decisions.
One last recommendation
The entity controlling the conversion value should also control the entire SKAd flow.
If you own an app, choose an expert to work with. Choose a market leader. Choose someone who is experienced in optimizing these processes for tens of thousands of apps. They will maximize the benefit for you. Good luck!
