Preparing for the next phase of mobile analytics on iOS: Past, present, and future

As we get closer to iOS 16 being released, predictions and rumors are increasing around Apple finally forcing the mobile advertising industry to exclusively use SKAdNetwork as originally intended. While some are still theorizing about yet-to-be-endorsed alternatives that can still attribute device-level data, at Singular we have been investing a lot of time and effort into understanding what the next phase of privacy-safe mobile analytics and campaign optimization should look like for iOS.

Our vision for Singular’s SKAdNetwork product is to deliver a reporting experience that’s as close as possible to pre iOS 14 user acquisition, including ad spend and ROAS, cohort metrics, and as many relevant breakdowns as possible … all of which are needed by marketers to optimize their iOS performance. 

At the same time, it is our mission to support campaign optimization, and work with our partners to ensure campaigns can run at scale and deliver results. Ironically, one of the main challenges in SKAN is that these two often come at the expense of each other.

In this blog post we’ll describe how mobile analytics on iOS 14 has evolved in the last 2 years, clarify where it is today, and share why we are excited (or rather, not as worried) about where it’s going over the next few years.

The reporting versus campaign optimization tradeoff

One of the most meaningful things to understand about SKAdNetwork is that in contrast to iOS reporting pre-iOS 14, campaign optimization and reporting are tightly coupled. This is because the signals, i.e. conversion values, that an app reports to SKAdNetwork are used for both optimization as well as reporting. 

In other words, if I’m choosing not to optimize against a specific event, I will not have it in my UA report. This is a huge change compared to the past where everything was always available regardless of what events were sent via postbacks for the purpose of campaign optimization.

A few examples for this:

• Revenue vs. events: if the app is only reporting revenue amounts to SKAdNetwork, ad networks will only optimize based on these revenue amounts and other events won’t be available to directly deduce from SKAdNetwork conversion value data. Recently, Singular added an option to include both by using mixed conversion models where the main trade-off is using less events.
• Measurement periods: the standard today is for apps to update conversion values to SKAdNetwork for the first 24 hours. This allows ad networks to receive SKAdNetwork postbacks roughly 2 days after every install. On the one hand, using a longer measurement period can increase accuracy by introducing additional conversion values. However, this will increase the delay before which ad networks receive postbacks for campaign optimization, which can damage performance.

Reporting in the early days of SKAdNetwork

SKAdNetwork 2.0 introduced a variety of new functionalities vs. the older SKAdNetwork 1.0 and finally became functional enough, albeit very limited, for marketers to use for optimizing while also being able to create a report. 

The IDs available on the SKAdNetwork postback allowed marketers to report on app, campaign, and publisher ID, although pragmatically very few marketers reported on publishers given the extremely low volumes at the time. Getting the IP on the postback also meant that one could deduce the country from the IP address, which provided reasonable accuracy.

Outside of breakdowns, the big new thing for SKAdNetwork 2.0 was of course the new conversion value framework, which means that marketers can optimize and report on conversion events. Despite the limitations, this was a huge advancement for SKAdNetwork and encouraged a lot of new solutions.

In SKAdNetwork 2.2, which became available with iOS 14.5, marketers could run and report on view-through traffic, meaning conversions that Apple would attribute to an ad being viewed and not clicked. And later in SKAdNetwork 3.0, which became available on iOS 14.6, marketers could also understand if certain ad networks had an ad clicked while not being attributed to … AKA “loser postbacks.”

Reporting as it is done in Singular today

So what happened since iOS 14.5 and what marketers can see in Singular today? A lot. 

We can generally categorize our efforts into two main categories:

1. Enrichment with ad network data
2. Estimation and modeling

Enrichment with ad network data
We can extract a lot of information about the campaign from the ad network report. 

It starts with metrics such as Ad Spend as well as Cost, Impressions, Clicks, and breakdowns such as Country (since each campaign is targeting certain countries). Joining SKAN conversion data with ad networks’ campaign data also means that breakdowns such as Campaign Name, Ad Group and others are now available if the ad network tells us how they are mapped – which most of them do. 

Note that the default campaign-id field in SKAdNetwork postbacks is not the ad network’s campaign ID, but rather a “SKAN Campaign ID” whose values are limited to between 1-100 per partner. This SKAN Campaign ID often represents an ad network campaign, and sometimes may also represent a specific ad group and even a specific creative.

Enrichment of SKAdNetwork data with ad network data allows us to create a full-funnel report, connecting top of the funnel ad spend with bottom of the funnel conversions, which is the foundation of effective user acquisition reporting.

Estimation and modeling
In addition to limited metrics and breakdowns, SKAdNetwork also introduced the concept of privacy thresholds – a mechanism designed to protect user privacy and ensure that individual user info can never get exposed through the SKAdNetwork framework. The impact on marketers, however, is negative: some conversion value data is null instead of having a value that can be decoded back to its original meaning. 

On average, nullified data due to privacy thresholds takes approximately 20% of all data, which causes a meaningful accuracy decrease. 

To address this, we are now launching SKAN Advanced Analytics and are introducing the concept of modeling, where Singular is creating approximations for the missing data by leveraging the aggregated data it is able to access under Apple’s guidelines. This allows marketers to compensate for the signal loss, and our beta test customers achieved 87% accuracy.

What’s coming up (and why are we insanely excited)

So, after all of this, where do we stand now? 

The report that marketers access on Singular when running SKAdNetwork is fairly comprehensive, and many of our customers are happy with the performance of SKAdNetwork. However … SKAdNetwork-based user acquisition data doesn’t include Apple Search Ads or organic installs. This is since these data sets are not supported by SKAdNetwork and are reported or calculated differently. 

Metrics available in the report are totals (“actuals”) over 24 hours. This is due to the relationship between the conversions UA is trying to optimize versus. conversions it’s trying to report on. 

These are the truths in today’s SKAdNetwork reality that we are looking to redefine.

So what is the future we are envisioning? It is one where …

1. You can optimize campaigns for a desired measurement period, but reporting is not constrained by that time frame. Marketers should be able to calculate cohorts for any given time period.
2. You can view and optimize by the true KPIs that matter to your app. Whether it’s ROAS or CPA, we want to make sure mobile analytics can support the business metric.
3. You are able to get a single, consistent view of all channels and traffic types on the same table, using the same schema.

But why would this be possible? Well, we’re not certain it is, but we have every reason to believe so. 

In the current state of user acquisition on iOS, marketers rely on the limited data reported back by SKAdNetwork. However there are additional, high-resolution data sets which are left aside. This is where algorithms and estimation theory can come in and leverage additional sources of information to create estimates and predictions, solving for the missing gaps.

Let’s remind ourselves what are the data sets available to us as iOS marketers:

• SKAdNetwork data: This data set captures all paid traffic and provides the attribution source of truth as determined by a last-touch model.

• First-party data (i.e. IDFV data): This is a data set that every app developer collects, and a lot of it is already reported to MMPs and some other vendors (e.g. in-app analytics). It is highly granular and gives us an exact snapshot of device and user activity, minus the attribution information.

• Opt-in data (i.e. IDFA data): This is a data set that many apps who surface the ATT prompt continue to have, and is also, like IDFV data, highly granular. A key point to remember here is that SANs are no longer attributing to IDFA, so this data set is partial and provides a skewed image of reality where only non-SAN partners are attributed.

• Cost and campaign data: This is a fourth data set that is typically highly granular and is very useful for prediction algorithms. Methods such as Media Mix Modeling (MMM) heavily rely on this data set as the input to the marketing equation.

When we look at these data sets above, it is pretty clear that there’s a lot of information out there that our algorithms should be using. But why hasn’t this been done before? Because we didn’t need to. IDFA data was perfect (well, ignoring issues around last touch attribution models) and allowed marketers to calculate any metric needed. 

This also, at least intuitively, tells us about the huge potential for smarter technology used in the space of marketing measurement. The better we can use all of these four data sets, the better accuracy and detail we’ll be able to deliver back to marketers in the world of SKAdNetwork, privacy, and limited data sets.

We are excited about this future and can’t wait to let you try the new products that are coming up soon. As always, we highly value feedback and interest from customers looking to try these out as early adopters.