pLTV in iOS 14: How to make SKAdNetwork conversion postbacks totally rock

The biggest lie about SKAdNetwork is that you can only return one post-install conversion value out of a pool of 64 potential options. Or that it’s basically a mono-channel conveying only one type of message.

Conversely, the biggest opportunity to win with SKAdNetwork is to deeply understand what it actually provides … and optimize the hell out of every last bit of it.

I mean that absolutely literally.

SKAdNetwork is, of course, Apple’s privacy-safe mobile attribution framework. And while it has definite limitations in granularity and post-install events — and does, literally, have only 64 discrete post-install conversion values — the secret to optimizing mobile marketing after Apple turns SKAdNetwork fully on relies on using every iota of an unsigned 6-bit entity that Apple calls “conversion-value.” Only then can you optimize your SKAdNetwork conversion models.

Why?

Because understanding the value of acquired users is critical to estimating ROAS and building LTV models. And it has to be predictive.

pLTV: Predictive life-time value

You simply must get good at predicting LTV in SKAdNetwork, because SKAdNetwork gives you only one chance to get post-install conversion data on acquired users, with very strict timing constraints. If you can’t predict the estimated value of newly acquired users quickly — most likely within one to three days — your ability to optimize ad campaigns will be critically impaired.

Fortunately, there’s a very good way to do all of this. And while it does require some level of sophistication in strategy, Singular makes it incredibly easy in execution.

Ultimately, it’s all about bits and bytes.

While these days we tend to think of data storage in terms of gigabytes and terabytes, a bit is the smallest atomic unit of storage in an electronic system. It is literally either a 1 or a 0. On or off. Something or nothing. One bit then, gives you one of two potential pieces of data.

Each additional bit gives you twice as much, so six bits gives you a whopping 64 potential values. (Geek note: since nerds count from zero and not one, the 64 values start at 0 and end at 63.)

That’s precisely why many tend to think of SKAdNetwork as providing 64 values, and think of one value being a specified LTV range, for instance, and another value being a different range. Or, each value could be mapped to an actual or inferred action by a user.

Here’s a critical insight.

SKAdNetwork: 64 values versus 6 bits

You’re actually not limited to 64 values. You are limited to six bits. And that’s a totally different thing, because each bit is essentially its own complete universe, enabling smart advertisers to walk and chew gum at the same time, while also playing the banjo and maybe even splitting the occasional atom just for fun.

In other words: you can measure multiple things in parallel.

Now you’re cooking with gas.

How you want to think about and use your precious six bits is entirely up to you, so you can align it precisely with how your app works, what your business model requires, and — perhaps most importantly — what you know about the relationship between D1, D2, or D3 events in your app and revenue events farther downstream.

In this example, you can use two bits for cohort data — allowing up to three days — and four bits for up to 16 different revenue buckets.

In this example, you’ve got the same two bits for up to three days of cohort data, but you’re adding a potentially deterministic on/off signal for a conversion event — in this case a sign-up — and leaving three more bits for up to eight different revenue buckets.

Here you’re really amping up the potential by getting cohort data, the sign-up event we’ve already mentioned, a predictive event based on user behavior you’ve seen in-app, and still four separate revenue buckets. (None, little, lots, whale?)

And those are all simple examples of how to use the available bits to drive your SKAdNetwork conversion models.

Bits, bytes, and your app’s critical events

There’s nothing too complex happening here, but the amount of data you’re getting back from one lonely post-install conversion postback is already starting to look fairly robust. Now it’s time to think about your app and how you’re going to use your six bits.

• What are the early signals of eventual value?
• How can you optimize your app experience to surface them as soon as possible?
• What should you test in terms of usability and customer journey to get those predictive signals in the first few days?

What you return in your SKAdNetwork post-install conversion values doesn’t have to be actual events. It could be predictions. “Predictive,” after all, is not about the data that a platform supplies you. It’s about how you use that data, and match it up with what you alone know about your users and customers. In SKAdNetwork, you get to decide what each bit does: is it deterministic (X happened, or Y did not happen), or is predictive? And your app can relay data to your servers and query for a predictive score … which you can then update Singular with for reporting via SKAdNetwork.

If you find even one event that has predictive value, then you can create a model. If you can create a model, you can test it.

Once you’ve tested it — and now is a good time because you can look at SKAdNetwork data side-by-side with IDFA data — you know your user-level predictive capability.

And that’s an app marketer’s superpower.

You may not know it per-user by platform, but you know it in your app. So you can calculate your predictive accuracy, you can improve your model over time, you can grow your confidence in your predictions, and ultimately, you have greater power to optimize marketing investments. Tip: you can do entirely risk-free prediction testing by making predictions for conditions in the past. Predict X results for Y conditions for a 30, 60, or 90-day old cohort, and check your historical data. Fine-tune your predictions, and use them live when you’re ready to make future predictions.

When LTV prediction is hard

Even if you can’t find events with strong predictive capabilities, there’s still huge value.

For instance, maybe it’s hard to predict LTV in two or three days, or even seven days. But you can report deterministic values. And maybe you can commit to something weaker than a strong LTV prediction: a tiering of users into groups, perhaps.

In that scenario, you use two bits to assign users to weakly predictive tiers.

This isn’t a hard prediction or a specific event. It’s not a revenue level. It’s simply a grouping based on initial usage, and you can refine it as you go. But now you can generate reporting, assign a value to each tier, and measure predicted ROAS. Now you’ve got a system and process, and now your job shifts to simply using data science and machine learning to continually improve that system and process.

1% improvement each day makes you 40X smarter over the course of a year.

That might be a bridge just a bit too far (or two bits … sorry). But better is better, and whatever your improvement rate is, if you can engineer in continuous improvement at that rate … you’re going to get to the promised land.

Or, better ROAS.

Whichever you prefer.

Get more details on Singular’s SKAdNetwork solution here. Or, request a demo here.