How to monetize with IAP on iOS 14.5+
Mobile marketing got a shake-up in April when Apple introduced its long-awaited AppTrackingTransparency (ATT) rules.
For apps that drive revenue through in-app purchases, ensuring they are making data-driven decisions has gotten more difficult, as there is less deterministic data to rely on.
In terms of actual revenue, iOS 14.5+ won’t impact how much users spend in-app. In-app purchases will still cost the same; users can still pay for in-app goods like gold coins or extra lives. However, the lack of deterministic attribution for opted-out users could make it harder for app publishers to know exactly how much revenue each campaign generated.
It’s now harder to tie each in-app purchase to an initial install or reattribution, so it can be harder to work out what user acquisition channels are performing, and also harder to predict LTV at the user level.
But there are strategies you can use to make the most of what data you do have in the post-IDFA world. By maximizing the number of users that opt-in you can maintain a baseline of deterministic data to work from, for modeling or forecasting purposes. And by identifying key signals to optimize for, you can make Apple’s SKAdNetwork system work for you.
SKAdNetwork for in-app purchases
SKAdNetwork was introduced by Apple in 2018, though it saw little adoption. The philosophy behind SKAdNetwork is that it provides a type of campaign measurement where data at the user level is not available. With iOS 14.5+, Apple has made the SKAdNetwork framework — with some expanded features — the only way to access advertising performance data in cases where users choose to restrict developers’ access to the IDFA.
SKAdNetwork provides space for 6-bits of downstream metrics, a number between 0 and 63 (or between 000000 and 111111 in binary), with an initial 24-hour timer. This ‘conversion value’ can be assigned any value that can be expressed in binary. Every time the conversion value is updated, to a fresh six-bit code defined within the app, the timer window is extended an additional 24 hours.
Once this conversion value window expires, a second 24-hour timer for attribution starts counting down. Within this 24 hour window, the SKAdNetwork randomly returns the attribution data. The idea behind this random timer is to obfuscate the time of install, so that event triggers cannot be linked to individual users. The SKAdNetwork system shares this data in the aggregate, with no granular data accessible at the user level.
For apps that monetize via in-app purchases, the short window into user behavior can be a problem. For many games, onboarding a user and explaining the value of in-app purchases can take longer than 24 hours. If a user is willing to pay for extra lives, that urge might not happen until they reach the more challenging levels. That’s difficult to track if you only have a 24 view post-install.
It is possible to extend the timer by using a bit to prolong the conversion window, simply triggering a conversion value update (for instance from 000001 to 000011 and so on) periodically to gain another 24 hours — but it requires the user to log in every day so that the conversion value trigger can run with the app in the foreground. If the user doesn’t open the app again in the window, the conversion value can’t update, meaning that you lose out on the data you were hoping to prolong the timer to collect.
Making SKAdNetwork work for IAP
Depending on the level of precision you require, you can track in-app purchase (IAP) behavior with SKAdNetwork in two main ways.
The first is using a ‘bit masking’ approach, where you assign each of the six bits to an event, and whether that corresponding bit is set to a 0 or a 1 tells you whether that event occurred. This approach is supported by our simple conversion value mapping.
If you’d like to track six or fewer IAP events, then this technique can be used, where a bit is simply linked to each event, and you can track these conversions. If you’re planning on optimizing towards key milestones — for instance “complete tutorial”, “complete level one” and “make a purchase” — then a bit masking approach is perfect.
However, if you want more detailed insights into ranges or scales of values, you can create buckets of “purchases” or some other metric. A bucket-based conversion value system allows you to define values that track how much users are spending in the first 24 hours. For gaming, e-commerce, delivery, or travel booking verticals, Average Order Value (AOV) is a commonly-used KPI that measures the amount spent by users in-app. If you’re optimizing towards AOV, it’s good to use buckets that encompass different total purchase values.
In a bucket-based approach you might set up ranges between $1-$5, $6-$10 and so on, with a value returning in the conversion value postback that corresponds to each of these buckets.
Predictive LTV modeling uses the behavior of a user on their first day of using the app to predict revenue going forward in the medium term. Such predictive modeling works better when used for broader buckets or categories. You want to create wide definitions of possible success and filter users into these based on their behaviors. Using buckets to do broad strokes, like dividing users into ‘whales’ or ‘not-whales’, is possible using their initial behaviors.
Maximizing the number of opt-ins you get is the first step in acquiring deterministic data that you can use to model, forecast and most effectively work with SKAdNetwork. With this data, you can then successfully track IAP behavior by bit masking or creating buckets of purchases - it’s all about how you set up and define your strategy, and which (and how many) IAP events you choose to focus on and track.