The optimal usage of ConversionValue in SKAdnetwork

As we continue to develop our probabilistic attribution solution for iOS14, we want to share our thoughts on the optimal use of SKAdnetwork’s ConversionValue.

As we continue to develop our probabilistic attribution solution for iOS14, we want to share our thoughts on the optimal use of SKAdnetwork’s ConversionValue. It’s an important topic, as the performance marketing ecosystem seems concerned about the limited scope of modeling post-install performance using this value. In this post, we’ll talk more about what ConversionValue is, what it allows for, and what we believe the optimal usage is.

What is ConversionValue?

With the iOS14 privacy update, Apple announced an API called SKAdnetwork, an attribution solution provided for when users don’t explicitly share their Identifier For Advertisers (IDFA). SKAdnetwork removed the ability to attribute individual users to campaigns and limited the richness of down-funnel events such as revenue and in-app engagements. Instead, Apple introduced ConversionValue as a solution that balances user privacy while providing some level of insight into a campaign performance after an install.

ConversionValue is a 6-bit value (integer from 0 to 63) that can be mapped onto in-app events to track an unknown user’s engagement after installing an advertised app from a SKAdnetwork-tracked campaign.

Once the user has installed the app, a 24-hour timer starts during which the advertiser needs to update the ConversionValue. This 24-hour timer resets every time the value is updated. When the timer runs out, the postback is sent by Apple to the ad network that delivered the install between 0 and 24 hours later. (This timing is random.)

What uses does ConversionValue have?

ConversionValue has two core uses:

1. Providing an early indication of in-app revenue, engagement, or retention from which an advertiser can judge early performance
2. Generating a value that gets sent to the ad network from Apple to power campaign optimization

How to think about ConversionValue:

There are a few ways to think about ConversionValue and how one might encode useful information into the postback. Some considerations we took into account were:

1. How do we encode behavior that leads to high LTV (revenue, engagement, retention)?
2. When is the optimal time to send the final ConversionValue while balancing recency and power of post-install data?
3. Is it possible to use a consistent approach that works across all types of app monetization (IAP, subscriptions, ad revenue, eCommerce, etc.)?

Optimal usage of ConversionValue:

After researching various combinations of 6-bit values, we believe the optimal use of ConversionValue is to pass back the user-level predicted LTV (pLTV). More specifically, we advise that the breakdown of the 6 bits should look as follows:

• Use 2 bits for an observation period of ~3 days after the install. This approach ensures that the ConversionValue is sent within a reasonable amount of time after the install, but not so long that the data is stale. Encoding days after install into the first 2 bits also ensures the timer won’t expire if the user exhibits no activity, and ensures a consistent measurement period of 3 days for all installs.
• Use 4 bits to separate pLTV into 16 bins to stratify a user’s predicted future revenue. The bins don’t necessarily need to be on a linear scale; they should be defined based on an app’s specific distribution of pLTVs.

Figure 1: The proposed optimal bit usage for Apple’s SKAdnetwork “ConversionValue”

Example of bits:

An example of mapping bits to in-app events is given in Figure 2. This illustrates 3 of the 16 different bins for pLTV. The “pLTV Bin Range” column has more granular ranges for low LTV and larger ranges for high LTV. The mapping can reduce the bin size where clustering of pLTVs exists to ensure that maximum granularity is achieved.

Figure 2: A sample mapping of the 6-bit value to the time lapse and an associated pLTV bin

Dimensions required for user-level pLTV for ConversionValue:

At this point, it’s important to share the data we use to model user-level LTV; Figure 3 is a table that outlines the data we employ. When users don’t share their IDFA with publisher and advertiser apps on iOS14, the model has no access to user-level source and campaign dimensions as highlighted on the table. However, for the purposes of passing back ConversionValue this is not a problem, as the ConversionValue is common for all ad networks, and SKAdnetwork handles anonymous campaign and source attribution.

Figure 3: Data used to model user-level pLTV

The elegance of our approach to ConversionValue is that:

• Predicted LTV is the best indicator of campaign performance. LTV is able to encompass all early behavioural signals including revenue, engagement, and retention into a single user-value metric.
• LTV applies to all app monetization types including IAP, Subscriptions, ad revenue, eCommerce and more, and provides an early, directly attributed performance signal that is universally applicable.
• User-level LTV provides a single signal to fuel probabilistic attribution that encompasses all user behavior. Utilizing this approach, we’re able to probabilistically update predicted campaign ROAS as cohorts mature further beyond the time window used to capture ConversionValue. More details on this are here.
• Predicted LTV is the correct metric for ad networks to optimize against. pLTV is the best indicator of long-term user value and ROI than any of the individual short-term metrics that can be captured with ConversionValue, such as early event completion and revenue. Now that advertisers are limited to a single post-install metric for networks to optimize against, it’s critical to choose the best one.

The optimal alignment between Advertiser and Ad network:

Today’s most successful user acquisition leverages an ad network algorithm to optimize campaigns towards a post-install metric, such as an in-app event or D7 return on ad spend (ROAS). In both cases, these metrics are proxies for LTV and not the true goal of the advertiser, because the ad network algorithms need a fast feedback loop from early post-install behavior to inform the ongoing algorithm performance.

Most advertisers have a long-term ROAS goal that they wish to meet. With user-level pLTV as the ConversionValue, the advertiser is completely aligned with all partner ad networks toward the outcome of advertising campaigns. It’s then the role of the ad network to maximize ConversionValue.

Why early revenue isn’t sufficient for ConversionValue:

We believe pLTV to be a better use of ConversionValue than measuring early revenue, for the following reasons:

• Early revenue will often be $0 for most users in mobile gaming or for subscription apps with free trials. In this case, a ConversionValue based on early revenue would not convey much information and would likely have to be combined with some other engagement metric.
• pLTV provides a better idea of long-term performance (what we refer to as pROAS), as opposed to benchmarks on early ROAS (i.e., hitting 5% ROAS by Day 3). It is, therefore, a better signal to pass back to ad networks for their own optimization of campaigns.
• pLTV provides a more discriminating signal to probabilistic attribution, as it encompasses all user behaviour.

AlgoLift predicts user-level LTV and leverages this data to automate user acquisition. For more details on how AlgoLift is solving probabilistic attribution for iOS14, read the following:

• Probabilistic attribution for iOS14 — a deeper dive
• Why a user-level LTV model is essential for post-iOS14 user acquisition