In today’s episode we will cover the mechanics of how conversion values get incremented in SKAdNetwork. This was one of the open questions from my session at the App Promotion Summit on How to implement SKAdNetwork in a Post-IDFA World. We couldn’t dive into this in detail in the main session – so I promised to cover this in a podcast episode – here it is!
(As a note: This is a 101 episode as it delves into some fundamental concepts that folks at the session asked for clarity on – so if you’re conversant with these fundamentals, please feel free to skip this.)
ABOUT ROCKETSHIP HQ: Website | How Things Grow | LinkedIn | Twitter | YouTube
KEY HIGHLIGHTS
📊 Understanding conversion values with SKAdNetwork
➕ How values are incremented 64 times
🚶♀️ Correlation the user journey to the conversion value
#️⃣ Binary vs decimal number systems
🧮 The math behind conversion
As a recap, a conversion value is the imputed value of a user within SKAdNetwork. It is as defined by the developer. This conversion value can be incremented 64 times – and I want today to dive into how these 64 values are encoded in SKAdNetwork in the form of the method updateConversionValue().
The 64 values can be incremented based on a user’s progression through their journey – say registration can be the lowest value, and the value can increase from 0 to 63 based on purchases or events completed in the app. For instance, you can set up your conversion value system by saying a value of 1 corresponds to registration, 31 to a first purchase, and 61 to a second purchase.
The less obvious part to notice is how these values are incremented in SKAdNetwork – as a part of the call updateConversionValue(). This is updated NOT from 0 to 1 to 2 to 3, but in bits (or based on the binary numeral system (with base 2 – with 0s and 1s as the only possible digits).
In our everyday number system (decimal), we use a base of 10 which means we have 10 digits with which we depict numbers: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9. However, the binary system uses base 2 with digits 0 and 1, which was used for programming computers because 0 = OFF and 1 = ON and that’s all computers really understand on a circuit level.
For our purposes, it makes sense to understand binary equivalents of numbers from 0 to 63. Each place in the number corresponds to a power of 2, just as in the decimal system each place corresponds to a power of 10 starting from 0 on the right.
In other words,
if your conversion value is 0, the value within the binary numeral system is still 0.
if your conversion value goes from 0 to 1, the value within the binary numeral system increments from 00 to 01 – because that is [ 0(2^1) + 1(2^0) = 1].
if your conversion value goes from 1 to 2, the value within the binary numeral system increments from 01 to 10. [1(2^1) + 0(2^0) = 2]
000000 => 0 => [0(2^0) = 0 ] => registration
000001 => 1 => [ 0(2^1) + 1(2^0) = 1 ] => complete FTUE
000010 => 2 => [1(2^1) + 0(2^0) = 2] => level 10
000011 => 3 => [1(2^1) + 1(2^0) = 3] => level 40
000100 => 4 => [1(2^2) + 0(2^1) + 0(2^0) = 4] => first purchase
…
11011 => 27 => 1(2^4) + 1(2^3) + 0(2^2) + 1(2^1) + 1(2^0) => second purchase
111111 => 63 => 1(2^5)+ 1(2^4) + 1(2^3) + 1(2^2) + 1(2^1) + 1(2^0) => third purchase
Here is a full conversion table:
Decimal | Binary | Decimal | Binary | Decimal | Binary | Decimal | Binary |
0 | 000000 | 16 | 010000 | 32 | 100000 | 48 | 110000 |
1 | 000001 | 17 | 010001 | 33 | 100001 | 49 | 110001 |
2 | 000010 | 18 | 010010 | 34 | 100010 | 50 | 110010 |
3 | 000011 | 19 | 010011 | 35 | 100011 | 51 | 110011 |
4 | 000100 | 20 | 010100 | 36 | 100100 | 52 | 110100 |
5 | 000101 | 21 | 010101 | 37 | 100101 | 53 | 110101 |
6 | 000110 | 22 | 010110 | 38 | 100110 | 54 | 110110 |
7 | 000111 | 23 | 010111 | 39 | 100111 | 55 | 110111 |
8 | 001000 | 24 | 011000 | 40 | 101000 | 56 | 111000 |
9 | 001001 | 25 | 011001 | 41 | 101001 | 57 | 111001 |
10 | 001010 | 26 | 011010 | 42 | 101010 | 58 | 111010 |
11 | 001011 | 27 | 011011 | 43 | 101011 | 59 | 111011 |
12 | 001100 | 28 | 011100 | 44 | 101100 | 60 | 111100 |
13 | 001101 | 29 | 011101 | 45 | 101101 | 61 | 111101 |
14 | 001110 | 30 | 011110 | 46 | 101110 | 62 | 111110 |
15 | 001111 | 31 | 011111 | 47 | 101111 | 63 | 111111 |
And of course each of these values map into different conversion events within the app. If you see the transcript for this episode, you’ll see this laid out visually for more clarity. If you’d like to dive in deeper into the basics of binary numerals, please also feel free to look at these tutorials
Understanding Binary Numbers for Beginners
Decimal & Binary Computer Number System – Conversion of Decimal to Binary & Binary to Decimal
What is Binary Number System? – Conversion from Decimal to Binary
In summary, I hope this episode helps you understand how your 64 conversion values from 0 to 63 will map to how the call updateConversionValue() records values within SKAdNetwork.
A REQUEST BEFORE YOU GO
I have a very important favor to ask, which as those of you who know me know I don’t do often. If you get any pleasure or inspiration from this episode, could you PLEASE leave a review on your favorite podcasting platform – be it iTunes, Overcast, Spotify or wherever you get your podcast fix. This podcast is very much a labor of love – and each episode takes many many hours to put together. When you write a review, it will not only be a great deal of encouragement to us, but it will also support getting the word out about the Mobile User Acquisition Show.
Constructive criticism and suggestions for improvement are welcome, whether on podcasting platforms – or by email to shamanth at rocketshiphq.com. We read all reviews & I want to make this podcast better.
Thank you – and I look forward to seeing you with the next episode!