How to fully leverage SKAN 4’s coarse values, measurement windows, postbacks, and lockWindow

Meta’s current threshold for getting a conversion value instead of CV=null is set at 88 installs per campaign per day. As testing continues, the limits and thresholds for SKAN 4 will also be uncovered, meaning we’ll be able to determine the point at which you’ll receive a fine value, a coarse value, or a CV=null. For SKAN 4, the limits will depend on the individual app. Smaller apps will be more likely to be placed into a lower tier and therefore receive less information, meaning the SKAN 3 practice of spending the majority of ad budget on very few campaigns (or even just one) will likely still be relevant.

At the other end of the spectrum are larger apps, which are better positioned to utilize the new source ID digits (allowing dimension reporting up to 10,000 digits instead of SKAN 3’s campaign IDs which only allowed 0-99) for more powerful targeting. They have the opportunity to target beyond campaign level to ad group and creative levels, as well as more granular geo targeting.

Measurement window 1

This is the “make-it-or-break-it” window where you decide whether you want to pause or scale a campaign. A clever way to utilize the coarse values here is to divide users into three main buckets:

• High-value users: A high share indicates a green light to scale the campaign.
• Medium-value users: A high share indicates a yellow light to keep the campaign at the same level.
• Low-value users: A high share indicates a red light to pause the campaign. Note that in Measurement window 1, coarse value = low will be reserved for a session, in the same way that with fine values, CV=0 is reserved for a session. This way, we will always get a postback when a user has had their first session/can be attributed.

To leverage this approach, app marketers and developers must first identify which events in the app user journey during the first 0-2 days (length of measurement window 1) are key indicators for long-term user behavior. These events will be highly dependent on both the app vertical and the monetization model.

Apps that monetize mainly via ad revenue typically use their 63 conversion values to map revenue ranges, where the higher conversion values map to the higher ranges, and vice versa. In this case, the most straightforward use of the coarse values would be to make a less granular version of the mapping done for the fine values.

Apps that monetize via in-app-purchases (IAP) can take the same approach. It’s a little more complex as early revenue via IAP isn’t always indicative of later stage user behavior but other non-revenue related events can be. It’s important to focus on the essentials/what’s going to help the most. Assigning conditions with several events into one coarse value is an additional option here if you’ve already got deeper insights about user behavior.

Subscription apps typically don’t expect users to convert within the first few days, so for the first measurement window, mapping non-revenue events to the available coarse conversion values is the most straightforward thing to do.

Apps that rely on monetization outside of the app itself (e.g. a mobile network app) focus on metrics like retention as their main goal, meaning the number of sessions is a key indicator for high-value user behavior, as well as general activity within the app.

Measurement window 2

In this window (3-7 days), users have now had the app for a considerable amount of time. For this reason, your expectations around what is considered “good” user behavior have probably changed. If, for example, a user had an abandoned cart or didn’t start a subscription after the trial, the likelihood of them buying the item or subscribing is significantly lower than it was in measurement window 1. The events you considered indicative of high, medium, or low value users in measurement window 1 will probably be brought down a bucket in measurement window 2. Thinking about this in practice, if ‘tutorial completed’ was indicative of a medium value user in measurement window 1 but they didn’t convert, this will probably be a low value event in measurement window 2. What you assign to the high basket here is probably something users don’t usually do in the first two days, e.g. subscription started.

For app developers doing predictive analysis on their users where early event behavior is used to work out probabilities for long-term user value, this window can be used to receive a confirmation that the analysis was correct or for course correction of the prediction made.

Measurement window 3

Here we are well into the user journey, looking at day 8-35. The user will have either deleted the app, will not be logging sessions, or will be performing a set of events that are indirectly or directly connected to high LTV. So, we essentially follow the same logic as in the second window, with the difference being that users would have gone further into their app journey. Coarse values in this window should be mapped to key events that happen after day 8, a certain revenue being reached, or users being retained.

As with the second window, the information received via the third postback can serve as a course corrector for any predictive analysis being done in the first days.

The key pitfall of this is that for the lock to be triggered, the user has to be online. This means that for any inactive users, the lock won’t be applied, and datasets will be skewed toward higher value users who are triggering events or are active in-app.

There are, however, strong use cases for lockWindow. For example, you can set a static lockWindow for your app. This means that if you know the time post-install when the bulk of your users perform key events, you’ve got a sweet spot identified and can lock the postback and receive it sooner. Alternatively, you could choose to implement a dynamic lockWindow, where the lock is only applied once a certain event has been performed, meaning it would be different for each user depending on their activity level.

The most strategic use of lockWindow will be within the first measurement window, during the ”make-it-or-break-it” phase. For the other windows, you should ideally already know if the campaign is converting well or not and try to get as much information as possible in the second and third postbacks by allowing the measurement window to run its course.