iOS 14: use ad revenue impression data to get the most out of SKAdNetwork conversion

February 19, 2021

Tags: Publishers, Marketers, Industry Perspectives, 2021

Mobile app campaign attribution is changing, but there are ways to pivot

The upcoming privacy changes for Apple iOS 14 and the user permission requirements for IDFA collection are coming. These changes are part of the larger updates that Apple has announced around app privacy, which also include aspects like event reporting and data “nutrition label”-style submissions. While there's no official date yet for when the new user opt-in prompt will appear, the iOS 14.5 beta is out with App Tracking Transparency (ATT) implemented, and signs point to early spring 2021 as the tentative time frame.

MoPub aims to dissect the latest performance measurement guidelines in the face of these ATT changes —including SKAdNetwork’s impact —  and showcase how per-impression information can provide a complete attribution picture post iOS 14.5.

State of the art performance measurement

Over the last few years, we’ve seen the user acquisition (UA) industry take advantage of state-of-the-art tools to measure the lifetime value (LTV) of each user. Publishers and developers can then compare LTV with their cost of acquisition in order to measure the return on ad spend (ROAS) of each user. Optimizing a campaign for ROAS is one of the most common UA strategies for many buyers today.

In order to accelerate acquisition feedback, buyers typically approximate user LTV with a limited-window value. The window lengths vary significantly by title, but typical windows are 1, 7, or 30 days. These windows allow buyers to predict whether a user is likely to achieve their long term revenue target. For example, if a user is playing a game and makes an in-app purchase (IAP) within the first 30 days, that’s usually a good indicator that the user will likely continue to make in-app purchases. Or, if a hyper-casual game app tracks that a user has watched 10 ads on the first day, that indicates that the user is already generating revenue, and is likely engaged in the game.

SKAdNetwork’s impact on performance measurement

The ATT shift will likely cause SKAdNetwork to become the predominant attribution method for all iOS user acquisition campaigns and even all users (not only those without an IDFA). Even if a small portion of a publisher's iOS users opt out, it will dismantle clear, holistic attribution for that OS and for the larger performance attribution. IDFA attribution can only be done if the IDFA is available in both the publisher and marketer targeted apps. Because they will not know at the time of serving the ad whether a user will opt-in within a target app, buying partners will likely shift to using SKAdNetwork for all app install and user acquisition campaigns.

The limitations imposed on the collection of post-install events by SKAdNetwork puts much of the industry’s current approach in jeopardy. Apple’s conversion value system currently has 3 main limitations:

  • It only allows for 64 different values
  • There is a variable amount of time to update values, but once its been sent it cannot be changed
  • The value must be chosen on the device

These tight constraints require rigor on behalf of ad buyers to make sure they can get the most useful performance measurement from their users. For apps that monetize users through ads, however, MoPub has a solution which can help buyers meet the criteria. Meet impression-level revenue data (ILRD).

How MoPub’s impression-level revenue data can help

Released in early 2019, MoPub’s impression-level revenue data provides user monetization metrics, in real time, on the device. After every impression, developers receive a callback with the value of each ad shown within the app. Some simple code can keep a running sum of ad value as a new user navigates their app journey within a session, day, or throughout the lifetime of the user. This allows a developer to help understand their own ads LTV for their users, and could be combined (where applicable and permissible) to an IAP counter to understand total user LTV. This is the best way to understand revenue performance on-device. Ad revenue in particular has a much faster feedback cycle than most other forms of monetization.

Choosing the appropriate measurement window

Once buyers have defined a user’s value and set a conversionValue using Apple’s API, a local timer is set. After 24 hours, if they have not updated it, that value will be sent in the conversion postback to the buyer that drove the install. However, if they update the conversionValue with a value greater than its current state, they will reset the 24 hour timer. Increasing the user’s value after each ad watched might seem like a natural first thought, but given that different users may watch ads with different time intervals, there is a risk that each user’s measurement window is different. This makes it harder to compare performance.

With that in mind, buyers may want to consider setting a single window for all users. One way to ensure this is to use an ad revenue “buffer”, which can keep its own timer while having its value amended. Once that internal window is complete, marketers can push the value from the buffer into the conversionValue once, and 24 hours later the postback will be dispatched.

Different apps have different user journeys and therefore may have different optimal windows for gauging performance. Some hyper-casual apps are able to assess user value within the first few hours, whereas other apps may need a couple of days. If a buyer’s ideal window is more than 24 hours, they may need to use the left-most one-or-two bits to serve as a way to keep resetting the conversionValue timer, thereby stopping the postback from being dispatched. In the ideal case, a user will have to have an active session 24 hours later, but as this cannot be guaranteed one may wish to reset the timer more frequently, like every 12 hours. A side benefit of using these bits is that an approximate time window comes attached in the postback, which can be used by the buyer to understand the user’s point in the life cycle.

Squeezing user value into 6 bits

Even without sacrificing bits to extend the conversion window, 6 bits of data is not a lot to play with. With 64 total possible values, providing user value down to the cent is not realistic. Instead, most buyers will likely want to use the bits to create buckets of users. Each bucket has a different value attached.

One simple form of this could be to use each bit to represent increments of $0.05, allowing for values between $0 and $3.15 when using MoPub’s impression-evel revenue data (see below figures).

How many bits the buyer may want to reserve for their measurement window, and how large their bucket sizes should be, will vary depending on their title. They may also want to consider whether their buckets should be uniform or non-uniform - if their app provides a $9.99 in-app purchase option, they will probably want a bucket to denote very high value users.

Getting to the endgame

The model described above is a useful way to start thinking about using the SKAN conversionValue, but in reality there may be an even more efficient way to use it. Another use of the conversionValue is one which minimizes “waste” of bits. Ideally, all 64 buckets are frequently used to declare and distinguish value. 

One idea for a more sophisticated model would involve a user LTV prediction model, and five steps:


Determine the measurement window for when a user has arrived in the app. Look to collect additional signals relevant to LTV, including ad revenue data using MoPub’s impression-level revenue data.


Use short term behaviour data to predict the user’s long term value, based on past user behaviour data.


Map that user’s p(LTV) into one of N buckets. The buckets should be set such that you seek to have an even number of users in each bucket. Given typical LTV distributions these are unlikely to be uniform.


Set the conversionValue of that user to specify which bucket they are predicted to fall into, to allow the original buyer to optimise campaigns. Give buyers the mapping of the conversionValue bits →  average revenue for that bucket.


Continue monitoring user’s LTV over the long term to help enhance the p(LTV) model

Moving forward

Other ideas for useful ways to use the conversionValue will be tested and developed as these changes come to light. Since many developers will find it time consuming to manage these experiments, most will want to work with an industry partner to help manage the lifting involved. Ultimately, however, the task remains the same: use a limited time window to best get an understanding of the user’s value so that buyers can optimize. For apps that use ad revenue in their revenue mix, MoPub’s impression-level revenue data can be an important tool for quickly determining a user’s monetization value. For those interested in learning more about the tool and how it can potentially help them as their monetization strategy shifts, please reach out to us at

About the author: David Gregson, Sr. Product Manager

David joined MoPub in 2017, and works on our mediation and exchange offerings. Before MoPub he worked at Vungle for four years where he held positions in Sales and Engineering before finding his “just-right” porridge in Product. He was creatively uninspired when he chose the handle @davidgregson


Contact us

Contact us

Ready to maximize your mobile revenue?

Girl with phone