What is SKAdNetwork Conversion Value?
SKAdNetwork Conversion Values (CVs) are anonymized in-app events that are collected and sent out to ad networks for campaign optimization. These events are represented in the range of numbers from 0 to 63 and it’s not possible to pinpoint which user did forward an in-app event. The mechanism of Conversion Values is an essential part of SKAdNetwork.
In order to start using SKAdNetwork Conversion Values, advertisers need to make sure that:
- Their app is configured to send out Conversion Values. In order to do that they need to make sure that this Apple instruction is followed or they have one of the MMP (Mobile Measurement Partner) SDK installed,
- The ad network that advertiser uses supports SKAdNetwork.
Binary view for CVs
In order to maximize the flexibility 64 available values (0 also counts) can be also turned into a binary value. For example, 30 can be converted as a binary value of 100000. This transformation works, because SKAdNetwork 6-bits values can be presented both in decimal (standard numbers) and binary values.
| Decimal | Binary | Decimal | Binary |
| 0 | 0 | 16 | 10000 |
| 1 | 1 | 17 | 10001 |
| 2 | 10 | 18 | 10010 |
| 3 | 11 | 19 | 10011 |
| 4 | 100 | 20 | 10100 |
| 5 | 101 | 21 | 10101 |
| 6 | 110 | 22 | 10110 |
| 7 | 111 | 23 | 10111 |
| 8 | 1000 | 24 | 11000 |
| 9 | 1001 | 25 | 11001 |
| 10 | 1010 | 26 | 11010 |
| 11 | 1011 | 27 | 11011 |
| 12 | 1100 | 28 | 11100 |
| 13 | 1101 | 29 | 11101 |
| 14 | 1110 | 30 | 11110 |
| 15 | 1111 | 31 | 11111 |
| Decimal | Binary | Decimal | Binary |
| 32 | 100000 | 48 | 110000 |
| 33 | 100001 | 49 | 110001 |
| 34 | 100010 | 50 | 110010 |
| 35 | 100011 | 51 | 110011 |
| 36 | 100100 | 52 | 110100 |
| 37 | 100101 | 53 | 110101 |
| 38 | 100110 | 54 | 110110 |
| 39 | 100111 | 55 | 110111 |
| 40 | 101000 | 56 | 111000 |
| 41 | 101001 | 57 | 111001 |
| 42 | 101010 | 58 | 111010 |
| 43 | 101011 | 59 | 111011 |
| 44 | 101100 | 60 | 111100 |
| 45 | 101101 | 61 | 111101 |
| 46 | 101110 | 62 | 111110 |
| 47 | 101111 | 63 | 111111 |
Coarse vs Fine Conversion Values
After SKAdNetwork 4.0, there are two types of Conversion Values:
- Fine-grained
- Coarse-grained
Fine-grained is follow the same decimal (0-63) or binary format (0 – 111111). All possible values are listed above in the table.
Coarse-grained is the new type of Conversion Values that become available after SKAdNetwork 4.0 (iOS 16.1+ users). There are three possible values for coarse-grained Conversion Values:
- low
- medium
- high
Conversion Values as Installs in decimals
For the first example, we will take a look at the advertiser that only tracks the installs for their apps. In most cases, the initial Conversion Value is going to be an install and it’s marked by default as Conversion Value = 0. It should be also noted, that the ‘install’ means the first app open and not the actual installation of the app on a device. There is no way to track Conversion Values before a user has opened an app.
| Conversions Value = 0 (Installs) | |
| Campaign A | 56 |
| Campaign B | 87 |
| Campaign C | 110 |
| Campaign D | 23 |
As you can see, the reporting of the installs is straightforward and is not much different from what was used before SKAdNetwork. However, if an advertiser wants to track events and metrics beyond install, it’s getting more complicated.
Conversion Values as revenue in decimals
This one is also pretty straightforward, but a very popular method to map Conversion Values. Each Conversion Value is mapped to the actual revenue that you receive.
- $1 – Conversion Value = 1
- $2 – Conversion Value = 2
- …
- $63 – Conversion Value = 63
The challenge of this approach is that you rarely get the first purchase on the first day after the install. And you can’t really afford to wait longer if you want to effectively optimize your traffic. SKAdNetwork creates data delays (eg obligatory random timer that can reach 24 hours) to preserve users’ privacy.
Conversion Values as revenue buckets in decimals
For those rare cases when $63 is not enough, advertisers can map the revenue to ‘revenue buckets’. Here is an example:
- $1-$5 – Conversion Value = 1
- $5 – $10 – Conversion Value = 2
- …
Bucket size might vary depending on the type of your app economy.
Ad Revenue in Conversion Values
Both methods above can also work to pass not only IAP revenue but also advertising revenue. This is going to be a bit more complicated because a developer needs to fetch the ad revenue data either on impression or user level directly from a client (on a device).
When the data is not provided, developers can estimate how much they get for a specific type of ad shown in their app. This can be done based on historical data. Let’s say one impression of an interstitial ad costs $0.4 and one rewarded video impression costs $0.6. A developer can check the type and amount of ads and make the final computation programmatically. This can also be enhanced with GEO data to increase accuracy. Once the final calculation is complete, the revenue can be sent in Conversion Value.
Conversion Value event mapping in decimal format
In our next example, we will take a look at the hybrid app (monetized both via In-App Purchase and In-App Advertisement). For the sake of simplicity here, we introduce only two new events:
- Ad viewed – Conversion Value = 21
- Purchase – Conversion Value = 35
Conversion Values are assigned here randomly, but it’s always more intuitive to assign higher values for more important events. In my case, Purchase > Ad viewed.
| Conversions Value = 0 (Installs) | Conversion Value = 21 (Ad viewed) | Conversion Value = 35 (Purchase) | |
| Campaign A | 56 | 21 | 3 |
| Campaign B | 87 | 45 | 5 |
| Campaign C | 110 | 53 | 8 |
| Campaign D | 23 | 16 | 3 |
Conversion Value event mapping in binary format
In some cases, you might want to see combinations of events that a user completed.
For this, we are going to use binary format instead of decimal.
- 10 – Ad viewed
- 01 – Purchase
- 11 – Ad viewed and Purchase
You can pass up to 6 events like this in a binary format – 111111.
Conversion Value split mapping in binary format
Six available digests in binary format (111111) can be split in half – 3 bits in each.
Again, there are a couple of variations of this that would rely depending on your app and your goals.
Let’s say that we have a hybrid app that is monetized via in-app purchases (IAP) and advertisement.
Split Conversion value to pass IAP and ad revenue
The first three digests are going to be used to ad revenue pass according to the buckets:
- 000 – no revenue
- 001 – $1 – $2
- 010 – $2 – $5
- 011 – $5 – $10
- …
The same or modified buckets can be used to pass IAP revenue in the second part of Conversion Value. For the sake of example let’s imagine that our ad revenue and IAP buckets are the same. Here is what it can look like:
- 000001 – No ad revenue, $1-$2 IAP
- 001010 – $1 – $2 ad revenue, $2 – $5 IAP
The split method can also be used with in-app events and in combination with revenue.
Split Conversion value to pass install time
The first 3 digits are allocated to indicate the install date. This enables ad networks and advertisers to build user cohorts based on install date more accurately.
Some MMPs are using this mapping by default. Examples: Kochava, Singular.
SKADNetwork and Conversion Value management with Elixir:
Conversion Values postback
Apple pings ad network that were involved in user interaction with advertising via postbacks that includes an array of data including the Conversion Values. Both winning ad network and non-winning ones are eligible to receive the postback. Up to five ad networks may receive a non-winning postback.
Read more about the SKAdNetwork postback in the dedicated page.
Conversion windows
This form is currently undergoing maintenance. Please try again later.