ABOUT KEVIN BRAVO: LinkedIn  | 2nd Potion  | Elixir




ABOUT ROCKETSHIP HQ: Website | LinkedIn  | Twitter | YouTube

KEY HIGHLIGHTS

🛠️ The mechanics of how SKAdNetwork works 

🖱️ The journey of a user from click to conversion

🌐 How ad signatures enable user attribution

⏳ The tale of two timers: understanding how postbacks work

💾 The two functions that are critical for tracking on SKAdNetwork

📨 How to use your 64 bits of information wisely

⛰️ How identifying what makes a high value user high value is key to making the most of SKAdNetwork

🔢 Different models for picking conversion values

📱 Selecting the right in-app events to send signals

💰 Understanding your how your LTV curve is shaped plays a big role in determining the right conversion value model

🎛️ What is mixed modelling: tracking revenue and engagement events

🧲 How to pick conversion models for ad monetized games

⏰ Using some of the 64 bits to connote time elapsed.

🎨 How subscription apps can get creative by using events other than free trial and subscription 

📏 One size doesn’t fit all: conversion streams play dictate how bits can and should be optimised

KEY QUOTES

How does SKAdNetwork work?

SKAdNetwork works by calling a function that is called registerAppForAdNetworkAttribution(). And so you use this to basically tell Apple: “I want to attribute this user. Can you check if a signature is here? Did he click on a specific ad? Do you know where this user is from?” If Apple can find the signed ad—if they can get back the signature—they’re going to start a 24-hour timer. 

The information received during after the timers

If you look at what Facebook is going to get back—because they’re receiving the signal; it’s going from the device to Facebook—they will have a postback. It’s just an API call with some data attached to it. So you’ll get a network ID, if it’s a first install or a redownload, a campaign ID, an install signature, and also if the source where the ad was displayed.

Privacy has led to ambiguity

This postback that you sent from the device is only sent once per user per install. And there is no way to tie this postback to any specific user. Because there is no timestamp on the install, there is no user ID, and you can’t attach anything else. It’s just one signal; Facebook knows, okay, there’s been one install.

There are limitations to the postback

And since you don’t have a time of install timestamp for the postback, it means that every time you call a big conversion value, you are making it harder for you and for the network to understand when the install actually occurred, because you cannot delay the moment of the postback being sent.

The structure of the postback

It’s not only a numerical value; it’s actually a binary. So it’s one value between 0 to 63 is actually a set of six binary digits, so either 0 or 1. And so what you can do is split the binary and say I’m going to use 3 binary values for progress events, like level 1, level 10, and so on. And the other ones for purchase events, like in-app purchase or even ad-based data. 

Two important functions of SKAdNetwork

Both the functions registerAppForAdNetworkAttribution() and updateConversionValue() can only be triggered from the app on the device. But yeah, you can trigger them as much as you want. 

Predicting LTV using touch points

So you have banners, interstitial rewarded videos, and then also in-app purchases, you have a mixed model. In this case, what they were doing was they were defining a weight for each touch point, so a banner will be maybe worth 0.2, and interstitial will be 1.5, and so on, and then they count how many touch points the user has for each. So if he saw 20 banners and 10 interstitial, then they have this weight, and they can calculate the overall value. And then it goes into buckets of predicted LTV, and then they have the conversion value. 

How to account for geos

Geo: again, in the postback, you don’t have geodata. So there are a couple of ways you can get geo and location. First one is that you have your campaign structure, which is based on that. So for example, you are going to have different campaigns for each country, or just packets of geos based on performance. It is structured in your campaigns; one campaign is for a specific geo. 

FULL TRANSCRIPT BELOW

Shamanth: I’m very excited to welcome Kevin Bravo to the Mobile User Acquisition show. Kevin, welcome to the show. 

Kevin: Hey, thanks. Happy to be here.

Shamanth: Yeah, I’m thrilled to have you, Kevin, because you’re among the few people that have actually thought deeply about SKAdNetwork; about how measurement will work in iOS 14. And not only have you thought deeply about all of these things, but you’re also building something to solve some of these problems. So I feel you have a very unique perspective on everything that is going to unfold. So, I’m thrilled to tap into your insights today. 

For somebody that’s looking to understand the mechanics of how SKAdNetwork works, can you explain what happens from the point a user clicks on an ad to when a user completes conversion events?

Kevin: Yeah, sure. Happy to give a bit of context. 

So basically, let’s say a user sees an ad on Facebook, for example, and SKAdNetwork is configured for your app. So what’s going to happen is that he’s going to see the ad, click on it, and then get redirected to the App Store where he can decide to install the app. The first thing to keep in mind is, when the ad is displayed on Facebook, Facebook is actually loading the ad with a signature. The ad is somehow tracked, and the signature is going to follow the user during this kind of install journey. 

So when the user is going to open your app for the first time, the signature will be there, accessible, but you won’t be able to get it yourself. By using SKAdNetwork, you can actually tell Apple: “Okay, I want to attribute this user.” And

the way you do this is simply by calling a function that is called registerAppForAdNetworkAttribution(). And so you use this to basically tell Apple: “I want to attribute this user. Can you check if a signature is here? Did he click on a specific ad? Do you know where this user is from?” If Apple can find the signed ad—if they can get back the signature—they’re going to start a 24-hour timer. 

And when I say ‘they’, I’m talking about what happens on the device, because everything is happening at the device level. So if signatures are available, if the user is coming from an app, a 24-hour timer is going to be started. And after this timer, there is a second one, which is kind of tricky. We’ll talk about it in a minute, I guess. But yeah, basically two timers: first one, 24 hours; and the second one is a random timer from 0 to 24 hours. At the end of these two timers, what happens is a postback is sent to the ad network. So in this case, it’s Facebook. So basically, the user installs the app, let’s say on Monday, a timer is randomly set. And then a second one. So the earliest you’ll see the install on Facebook will be by Tuesday morning; the latest being Wednesday, for example, if you just use this score. 

And so,

if you look at what Facebook is going to get back—because they’re receiving the signal; it’s going from the device to Facebook—they will have a postback. It’s just an API call with some data attached to it. So you’ll get a network ID, if it’s a first install or a redownload, a campaign ID, an install signature, and also if the source where the ad was displayed.

So in this case, it would be Facebook. You also have some additional data for validation purposes, and a conversion value that we’ll talk about in a bit. 

The other thing to keep in mind is that

this postback that you sent from the device is only sent once per user per install. And there is no way to tie this postback to any specific user. Because there is no timestamp on the install, there is no user ID, and you can’t attach anything else. It’s just one signal; Facebook knows, okay, there’s been one install.

Shamanth: Definitely, and it is a very different paradigm from what we have been accustomed to prior to iOS 14, which is why this is so important to understand and internalise completely. So when you’re setting up conversion values, what are some of the considerations that you suggest keeping in mind?

Kevin: Yep. So as you said, say there is a conversion value; it’s one of the data points that is attached to this postback. And the way you can set it is to call a second function. So there are two: the first one is registerAppForAdNetworkAttribution(). And the second is called updateConversionValue(). And so what you can do is attach a defined value from 0 to 63; which is 64 different values that can be attached to the call. And then when Facebook receives the install data, they will also have this like value attached to the install. 

I like to think about it like a signal. You can add kind of a context to the user. It’s like answering the question: “How valuable is this user to me?” You can call the method as many times as you want. The way it works is that it resets the timer—the first one of 24 hours. So as long as the user keeps coming back into your app, you can still keep calling the conversion value method. 

There are a couple of things to consider: First one, it can only be higher. So if you log a conversion value of 10, the next time you call the method, you have to call 15, for example, or 20, and so on. So that’s the first thing to keep in mind. The second thing to keep in mind, as I said, is that every time you log it, the timer resets.

And since you don’t have a time of install timestamp for the postback, it means that every time you call a big conversion value, you are making it harder for you and for the network to understand when the install actually occurred, because you cannot delay the moment of the postback being sent.

Conversion values are still enough, and you can do different things. You can attach an event like finished onboarding. Or like maybe create a different combination of events; we can talk about this in a bit. 

The main considerations you want to keep in mind are:

1. Your business model: Are you subscription-based, ad-based? How are you making money? 
2. Vertical you are in: You’ll see like many companies in fitness, for example, are going to do the same thing and so on. So that’s something you can get inspired by. 
3. How do you differentiate low-value users and high-value users in their first session: Trying to understand what does a user need to do for me to feel he is valuable, because it’s early, so you don’t have that much time. But you can still get some signals.  
4. How were you historically optimising your ad campaigns: I don’t think you can just switch and keep the same system, but maybe you can learn from the past, the way you are doing it, so you can build a new model for this new solution.

Shamanth: I think the two things you said that jumped out at me: The longer you wait, the harder it is to attribute it to the timestamp. So you really want to look at the first session and say: “What signal can I find that tells me – this is a high value; that is not a high value user.”

Kevin: Yeah, I think it’s changing, because some apps will just say: “Well, my signal is if you come back the next day.” If you take games, for example, second day retention will already be a big signal for them in some cases. So that’s also the challenge. It’s not only about events, but also the kind of time they spend in the app. That can also be a signal you want to use.

Shamanth: Yeah. Right. And there can be very many approaches to setting up these conversion values. So can you tell us about what the possible approaches or models are to picking conversion values? And also tell us how an app developer should be thinking about picking a model?

Kevin: Yeah. Again, the first thing to consider is the business model, and all the things we talked about before. But then you think about all the ways you can use them. This is not all of the ways; these are the ones I either heard of or I feel could be interesting. 

So the first one is just to track events and assign them directly to conversion values. So let’s say sign up is 10; started trial, 20; subscribes is 30; and so on. That’s one way to do it. The other one you can do is—again, keep in mind that you only get one conversion value; the last one you sent—kind of incremental. Sign up will always have to be the earliest one. So like the lowest value, whereas subscribe, which is a higher signal should be the highest value. And another way you can do this is to say: “Okay, I’m going to look at the LTV for the first couple of days and put it as a conversion value.” So for example, for the revenue figure, you have a conversion value of 15 which can equal one euro and 50 cents. That’s just a broad example. 

You can have buckets. We can also define clusters based on your knowledge and understanding of how LTV spreads over a couple of first days. And this approach is to use predicted LTV, which is fairly different. This is I guess for bigger apps. It’s like saying: “Okay, I have enough past data and understanding of my user LTV across time, to know how much I’m going to predict, in terms of value for the user, after he did a specific set of actions or specific things in there.” This is tricky. Because first, you don’t have that much time, especially if you keep the conversion value method; it is just 24 hours, it’s going to be super tricky. 

Sure, in three days, maybe you will have more signals. But again, it’s tricky. And also it’s super hard to see if the model that you built is accurate. Because once you have this data in Facebook, you won’t be able to look at what’s happening later for this course. You won’t be able to see if the predicted LTV is the one that is actually occuring for the users in the bucket. So it’s kind of a guessing game, which is quite challenging, especially when you don’t have that much volume.

Shamanth: Yeah, yeah. And I think it comes down to how you can make informed guesses knowing that it may not be accurate.

Kevin: I think there are two more I’d like to talk about that I think are interesting as well. The first one is what we call mixed modelling. And that’s the one I use for the tool I built, Elixir. You have events and you have revenue information. So if you take, for example, a mid-core game, you’re going to have different levels. So you may want to understand how many levels have been done by the user after a couple of hours. And you may have in-app purchases. And if the user does in-app purchases early, that’s really valuable for you. So you can have both and the way it works is with the conversion values. 

It’s not only a numerical value; it’s actually a binary. So it’s one value between 0 to 63 is actually a set of six binary digits, so either 0 or 1. And so what you can do is split the binary and say I’m going to use 3 binary values for progress events, like level 1, level 10, and so on. And the other ones for purchase events, like in-app purchase or even ad-based data. But yeah, that’s also a way you can do it, which makes sense.

Shamanth: Right. So the signal you’re sending doesn’t always just have to be revenue-linked. You can and you should actually combine revenue and some sort of engagement event, which could be in this case, obtain a level for a mid-core game.

Kevin: Yeah, exactly. My understanding and my kind of feeling is—and I think Eric Seufert also said that in fact—some events may need to be created. I don’t think that all the apps and all the games will be able to just take events they’re already tracking on the product, and just use them as conversion values. I think it would be a mix. And, you know, we’ll be learning as we go how to best mix the signals, but you know, the long game will be that companies that can actually have a really accurate mixed signal, and keep optimising towards this value.

Shamanth: Sure. And it’s also my understanding, and please correct me if this is wrong, that a signal can be sent even if there is no event. If a user is doing nothing, you can still send a signal. 

Kevin: Exactly,

both the functions registerAppForAdNetworkAttribution() and updateConversionValue() can only be triggered from the app on the device. But yeah, you can trigger them as much as you want.

If, for example, the user comes in on day two and you want to add this information, you can fire this conversion value. Just call one value greater; if you had 20 on Thursday, you can have 21, for example. That’s feasible. 

Shamanth: Sure, that makes a lot of sense. And if you look at ad monetized apps, what might be some of the ways in which they might be able to pick conversion values?

Kevin: Yeah. So I saw a spreadsheet from Ruby Games, and they had this super interesting idea. I think it makes sense, but I don’t know how hard it would be to integrate for any game, but basically what they were doing is that they said: “Okay, so our game is ad-based; we have different kinds of monetization touch points.”

So you have banners, interstitial rewarded videos, and then also in-app purchases, you have a mixed model. In this case, what they were doing was they were like defining a weight for each touch point, so a banner will be maybe worth 0.2, and interstitial will be 1.5, and so on, and then they count how many touch points the user has for each. So if he saw 20 banners and 10 interstitial, then they have this weight, and they can calculate the overall value. And then it goes into buckets of predicted LTV, and then they have the conversion value.

It’s quite complex, but when you think about it, it’s just a matter of how much was each touch point. And then I do a calculation. That’s one way to put it.

Shamanth: Yeah, so you’re basically looking at high value placements, which could be rewarded video or interstitials, and the lower value ones, which can be banners: you assign them conversion values. You’re also saying, look, maybe 10 banner views or 20 rewarded video views equals X number of conversion values.

Kevin: Yeah, it’s similar. The only difference is that you don’t assign them directly to conversion value. You just have kind of a bucket; it’s like a score. So you calculate the number of touch points, you have a score, and then you have a maximum score of 64 that you define based on past behaviour, and a minimum that is 0. And then you just define the conversion value based on how high the score is.

Shamanth: Right, depending on how many touch points they’ve had, with how many banners, how many rewarded videos, how many interstitials, etc. Gotcha. And as we talked about, the conversion event does not have to get fired, when there is actually an event; you can basically fire it, even if the user doesn’t come in or the user does nothing.

Kevin: You still have to have the user in a session because you have to do it on the device. But you don’t have to wait for the user to do anything else apart from opening the app.

Shamanth: Okay, the user still has to open the app. Yeah. Okay. Got it. One solution that I’ve seen proposed is to use the first couple of bits to connote the amount of time that’s elapsed. So, say the first couple of bits are how many days have passed since install and use the remaining bits to include other conversion events, which could be revenue or level or ad monetization touchpoints as you mentioned. So what do you see as the advantages or disadvantages of using some of those 64 bits to connote time elapsed?

Kevin: Yeah. So basically, I think Algolift had this kind of idea of saying: “Okay, we’re just going to have a time window, day 1 to day 3. So you have two bits that can be 000110 or 000101.” And I think that’s good, because we need to get better accuracy and measurement capabilities across tools and not only for the ad network. Because you’ll be able to understand that this is installed within this day and this one. I think it’s valuable. 

But a couple of things to consider before setting this up. First of all, you have less space; you have only four bits left. So it means fewer conversion events. But that’s not a problem for everyone. You don’t all have to do this. For example, if you take subscription apps, most of the signals will occur within the first day. So maybe you just want to stick with the first day; maybe you just don’t want to keep updating conversion values, because, as I said, you have to wait for the user to open the app but you don’t have to if you don’t want to. So I can decide only to update conversion values during the first 24 hours of the user’s usage. That’s also a way to do it. 

Another thing is that some networks may already require you to do so. For example, if you take Facebook, I think from the documentation they were specifying around like 24 hours. So Facebook may tell you, you have to, not only stop sending big conversion values after a specific delay, but use the SDK also. And also the events may be limited, so they may have a say in the events we track, the same way they have now with app event optimization campaigns, where you have like 12 different events you can use. And yeah, and just to finish off on this, I think you should stick with one day; it’s easy to measure. But you definitely have fewer signals. So, I think it’s going to be a case by case. But I guess the only thing I would say is that this can work, but I would first consider and understand how networks work with it. Because the way you’re going to approach this bit management will be relying on the way the ad networks you work with are using the conversion value tomorrow.

Shamanth: Got it. Yeah, I think it makes sense to do that on a case by case basis, just because it may not be appropriate for every single app to reserve some bits for the days yet. And like you said, some apps may be more front-loaded; subscription apps are an example, some may not be. So I think it makes sense to really look at what their conversion stream is, and then make that decision. 

So you did speak about subscription apps, and we know that most of the free trials happen within the first 24 hours, which means out of the 64 bits, they may not necessarily need to use the vast majority of the bits. So are there ways in which they can and should use the remaining bits at all, or should they just use one bit for free trial and just forget about the rest?

Kevin: Yeah, well, a couple of things. Because the first one is, there’s a threshold. We’re not yet sure about it, but Apple said that there may be a threshold that will impact the conversion values. Saying that, if you don’t have enough occurrences of specific conversion values that may not seem sends a signal. That’s something that is super not clear right now; it’s kind of blurry in the documentation, but that’s something we may need to consider in the future. The second thing is networks, because some networks may say, you can choose a conversion value as you please, unless you don’t want us to optimise the way we do like Facebook. 

But then, if you put this aside, you just think about what else can I do? You have time of day, of course. Some companies may want to use usertype. Take for example marketplaces; they may want to understand from a specific ad—even if usually ads are targeted—and want to make sure that they get a supplier or on the supply or demand side. That’s something they can use a bit for. 

Geo: again, in the postback, you don’t have geodata. So there are a couple of ways you can get geo and location. First one is that you have your campaign structure, which is based on that. So for example, you are going to have different geos for each country, or just packets of geos based on performance. It is structured in your campaigns; one campaign is for a specific geo.

The challenge with that being that, for example, Facebook will only allow 9 campaigns with an iOS 14 account, when you start with SKAdNetwork. You can use a bit to for geos, if you can have some information at the device level. So that’s also something you can do; that’s what I have in mind now.

Shamanth: Yeah. And I think that’s what I’m also taking away is that there are creative ways to use the conversion value framework. And developers really need to think through what makes the most sense for them. Kevin, this has been very insightful. And clearly, this shows exactly how deeply you’re thinking about all of the changes that are coming to us. This is perhaps a good place for us to wrap. And before we do that, can you tell folks how they can find out more about you and everything you do?

Kevin: Yeah, sure. I actually run a consultancy agency for apps and games, mobile apps and games called 2nd Potion. So we work on activation, retention, segmentation, and so on. And yeah, you can find more about me on LinkedIn or our website.

Shamanth: Excellent. And you’re also building a tool for iOS 14.

Kevin: Yeah, exactly. Actually, it’s an open source tool to handle conversion values. It’s for apps that don’t have an MMP, a mobile measurement partner, or that want to take care of the conversion value management themselves. It’s called Elixir; it has no website, kind of a work in progress, but the code is free and open source. So you can look it up on GitHub.

Shamanth: Excellent. We will link to your GitHub. And of course, we’ll link to 2nd Potion and everything you do in the show notes as well. Kevin, thank you so much for being on the Mobile User Acquisition show. Very excited to put this out into the world very soon.

Kevin: Cool. Thanks a lot.

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!