Skip to content
12 min read

Decoding SKAdNetwork: How iOS Measures App Conversions

Featured Image

A solid technical foundation is essential for all types of advertising and attribution. Especially for ads for apps on Facebook, Instagram, TikTok that use Apple's SkAdNetwork.

At its core, it's about how you can collect first-party data from your iOS app. This often takes the form of an SDK (Software Development Kit), which is embedded in the app and ensures data exchange between the platforms. Each advertising platform offers its own SDK. There is a Facebook SDK, a TikTok SDK, a Snap SDK, but also so-called MMPs such as Adjust, Appsflyer, Kochava, which take on a container function and connect several platforms at once, combined with aggregated data evaluations and marketing attribution.

Table of contents

Apple IDFA and Google AAID

What is Google planning for Android?

What is the Skadnetwork?

How does an app installation with the SKadnetwork work?

Changes with SKadnetwork 4.0

Fine and coarse values

Hierarchical source ID

Configuring the Skadnetwork in the Meta Events Manager

TikTok and the Skadnetwork

My experience with SKAN

What has happened so far: Apple IDFA and Google AAID

As in the browser web, identifiers are of fundamental importance for the optimization of social advertising campaigns on mobile apps such as Facebook, Instagram or TikTok. The collection of device IDs such as Apple's IDFA and Google's AAID has lent itself to advertising networks, DSPs and providers to develop targeting functions. This targeting based on individual device data was therefore more accurate and reliable than any web targeting via cookies could be.

With iOS14.5, Apple introduced an opt-in for this with ATT, App Tracking Transparency, i.e. users had to agree that their device ID could be passed on. They also offered an alternative API that transmitted user data in aggregated form. In short, device-based user data was largely eliminated because users only gave their consent in 25% of cases on average. In 2020, the opt-in rates were still only 16%.


A welcome step from a data protection perspective, even though Apple was primarily pursuing its own interests and pushing ahead with the development of its own Apple Search Ads platform. The opt-in queries were only partially applied to Apple's own apps, for example, or were given more inconspicuous texts that were more likely to tempt users to opt in.

And what is Google planning for Android?

Although Google still uses AAID for many things at the moment, this will be moved to Android's privacy sandbox by the end of 2024. And Google has not yet said that they will replace their AAID advertising ID with this sandbox. But their intention to replicate all functions with the sandbox indicates that they will do so at some point.

The core of the Privacy Sandbox is the Topics API. The Topics API allows ad network SDKs to target different users based on the topics associated with them. Almost like interest-based targeting - with the difference that in the specific implementation, the interests or topics are defined in such a way that no personally identifiable information is disclosed.


Each app is assigned up to 3 topics that can be "read" by the ad tech SDKs present in that app. If I as a user use the 7 apps listed above, the Topics API creates the list of my "topics" as a user. This means that a "topic" is defined for each user - based on their recent interactions with certain apps.


Google itself says:

The reason that each app gets one of several topics is to ensure that different apps get different topics, making it harder for apps to cross-correlate the same user. For example, app A might see topic T1 for the user, but app B might see topic T2. This makes it more difficult for the two apps to determine that this information is associated with the same user.

Obviously, the GAID no longer plays a role at all. But even if Meta and TikTok can overlay the topic data with their own data and apply their MLs to it, you must not forget: Non-purchase data has no correlation with actual purchases. The results of app ads via the Topics API will therefore inevitably be worse than with GAID.

The industry continues to criticize the Topics API:

The Topics API as proposed puts the browser in a position of sharing information about the user, derived from their browsing history, with any site that can call the API. This is done in such a way that the user has no fine-grained control over what is revealed, and in what context, or to which parties. It also seems likely that a user would struggle to understand what is even happening; data is gathered and sent behind the scenes, quite opaquely. This goes against the principle of enhancing the user's control, and we believe is not appropriate behavior for any software purporting to be an agent of a web user.

What is the SKAdNetwork?

StoreKit Ad Network or SKAdNetwork or SKAN is the API developed by Apple. It was introduced with iOS 14.5. It helps advertising networks and advertisers to measure their advertising activities (impressions, clicks and app installs) on an aggregated level without revealing data about individual users or devices.

How does an app installation via the SKAdNetwork work?


Let's go through the chronological process:

  1. An ad is displayed on Instagram. As soon as the ad is displayed, Instagram starts a 3-second timer and notifies the SKAdNetwork that it has started.
  2. When the ad is displayed for at least 3 seconds, Instagram notifies the SKAN that the 3-second timer has expired and this activity is recorded as a successful view.
  3. If the user installs the app and launches it within the SKAdNetwork attribution window, the installation is attributed to the ad network and the device sends the installation postback to the ad network and a copy to the advertiser.
  4. With SKAdNetwork, the attribution window can be up to 30 days between click and installation, depending on the ad type. Unlike standard postbacks, SKAdNetwork postbacks are not sent to the ad network and the advertiser immediately when the app is first launched.

Three postbacks with SKAdNetwork 4.0

SKAdNetwork postbacks are divided into three time windows with SKAN 4.0. Each postback can fall within a specific activity window:

  • 0-2 days
  • 3-7 days
  • 8-35 days

This allows advertisers to understand how users use their app over a longer period of time and get more information for estimating user value (and bid prices) than previously available. Important: These three postbacks are independent of each other. They cannot be linked across advertising platforms to form "user journeys".

Previously, there was only a single postback that was sent after the random expiry of a timer. Fun idea, unfortunately pretty worthless as a data point.

Anonymity of the crowd

Crowd anonymity is a new term Apple uses to describe the gradations in which the SKAN provides attribution data. Only Apple knows where these individual levels lie.

At the lowest level, i.e. low anonymity, advertisers do not receive any conversion values. This puts small advertisers at a disadvantage. It is to be hoped that, at least at the middle level, significantly more signals will be sent to advertisers to determine whether additional expenditure is justified in order to invest in the highest level of crowd anonymity.

At WWDC 2022, Apple said:

When the install count is low, we take extra steps to protect privacy by limiting the trackable information sent back. As the count scales up and the user's uniqueness starts to blend into the crowd, we send more data back. Finally, as the count reaches the highest tier, we are able to send the most data back while still preserving privacy.

In practice, this means that for a campaign with very few installs per day, Apple assumes that it is possible to trace the identity of a user. Let's assume that 2 users have completed a purchase and one has a conversion value of 50. Then one of these users will trigger a postback with a conversion value of 50 - and the other will trigger a postback without any conversion value.

So the lower the number of daily installs, the greater the number of users whose conversions are not sent - and the higher your CPA. According to a study conducted by Appsflyer, with less than 10 installs per day per campaign, almost 90% of conversion values are hidden, which is why CPAs can be very high.

Fine and coarse conversion values

coffee in fein, mittel und grob

When crowd anonymity is low, the conversion value is masked. If anonymity is medium, the postbacks contain a rough conversion value. And if anonymity is high, the postbacks contain a fine conversion value.

A fine conversion value is defined by 6 bits, which are binary, meaning they can be turned on or off (0 or 1). This opens up the potential for 64 measurement combinations within these 6 bits - from 0 to 63.

While 64 options isn't many, it still gives you plenty of options to work with to measure sales, engagement and more.

As long as you assign your conversion values correctly based on your advertising goals, these values can be used in any way you choose. You are in control and can assign them to the KPIs that are most valuable to you.

The 64 values, each of which has its own coding configured by the app developer/advertiser, are then mapped to the source of the install, allowing for campaign measurement and optimization.

SKAN 4.0 now introduces a new set of coarse conversion values, in addition to these 64 fine-grained values.

Coarse-grained conversion values are divided into 3 types: low, medium or high. These values are assigned by the advertiser to indicate different levels of user engagement and allow advertisers to obtain at least some attribution data in cases where the privacy threshold is not met (at lower levels of crowd anonymity).

Hierarchical source ID

Starting with SKAN 4.0, Apple will rename the Campaign ID field to Source ID and expand its range from 2 digits (representative of 100 options) to 4 digits (representative of 10,000 options).

Although Source ID is a single number, Apple encourages advertisers to use it as three hierarchical numbers so they can measure more parameters, such as ad placement, location, display and more.

As with the hierarchical conversion values, the privacy threshold set by Apple also applies to the hierarchical source IDs, i.e. the higher the level of anonymity of the audience, the higher the level of granularity provided.

It is therefore advisable to bundle the campaigns for SKAN as much as possible.

Configuring SKAdNetwork in the Meta Events Manager


There are three ways to configure the SKAdNetwork conversion schema. Which one you should choose depends on how you have already set up your app events. The three options are:

Use recommendations. Confirm the events that Meta suggests based on your available data. (This applies if you are using the Facebook SDK or the App Events API).

Import from partner app. If you are using a Mobile Measurement Partner (MMP), you can set your events on your partner's platform. This configuration is called an event configuration schema. You can then import your event configuration schema into Meta. Remember that you will need to edit your configuration on your partner's platform.

Customize. Select and configure each event and value set individually. (Select this option if you are using App Events API, Facebook SDK or a Mobile Measurement Partner and want to configure your events to match your event configuration on other platforms).

  • Go to the Events Manager.
  • Click on the Data Sources icon on the left-hand side.
  • Select the application you want to configure.
  • Click on the Settings tab.
  • Under Configure app events for SKAdNetwork, click Start setting up events.
  • Select how you want to configure events: Use recommendations, Import from partner app or Customize.
  • Click Next and make the appropriate settings.

TikTok and SKAdNetwork

TikTok does not offer these settings, but is the platform that AppsFlyers Performance Index found to be the most attuned to SKAdNetwork six months after Apple's ATT enforcement. TikTok had the fourth highest number of advertisers, the fifth highest number of postbacks and a good quality score. This led to first place in the AppsFlyer Power Ranking and fifth place in the Volume Ranking for SKAdNetwork.

The ideal SKAdNetwork configuration

Together with OBI, for example, I accompanied the migration from HeyOBI to SKAdNetwork, but also supported GetYourGuide in optimizing the settings. My experiences from this are:

  • Decide on the three most important events and stick to them. With the ability to set low, medium and high values for coarse-grained conversion values, there is a temptation to use different values for each of the three windows. However, as mentioned above, most apps are really optimized for three events, and for the sake of simplicity, it's probably best for most advertisers to use the same event for low, medium and high in the three conversion windows. With a little data analysis, it's quite easy for most apps to understand the three key conversion events and cohort windows in their monetization funnel and then set up SKAN 4.0 from there.
  • For example, a fintech app could be optimized for registrations, first deposit and deposits over €100 in cohorts D1, D7 and D30. Or a subscription app could be optimized for registrations, free trial and paid subscriptions on D2, D7 and D35, depending on the length of the free trial.
  • With a dual iOS/Android app strategy, it is important to understand what is and is not possible with which mobile OS platform. The measurement of app installs and in-app events in particular differs significantly.
  • Find out what the technological innovations mean for measuring success. The field is developing very dynamically with SKAdNetwork, Privacy Sandbox, Private Relay etc.. As are the possibilities of MMPs.
  • On iOS, Apple is pushing itself between the well-known social advertising platforms and users with SKAN and is continuously developing its own Apple Search Ads for the App Store. This is something to keep in mind.
  • The 24-hour timer is a major problem for subscription-based apps because, for example, a subscription can only take place well after 24 hours and therefore cannot be returned via SKAN. If a registration takes place in the first 6 hours, the user closes the app and does nothing, only to come back after 32 hours to start a "trial" - then the "trial" is not recorded as a conversion event by SKAN. The strategy must therefore be to prioritize the conversion events so that a 24-hour timer is always running (up to 48 hours in total):


  • To do this, you may also have to further differentiate the events before the subscription in order to get as close as possible to the subscription, even if it falls outside the 24 hours.

    - Registration as the lowest event
    - Complete onboarding
    - Trial
    - Engaged Trial

Then at some point the 48 hours have expired and postback 2 and 3 are triggered 7 and 35 days after install, albeit only with rough conversion values. And don't forget: Apple's randomized delay still applies: 24-48 hours for the first postback and 24-144 hours for the second and third postback. It therefore makes sense to close the Conversion Windows with the lock function as early as possible to avoid having to wait too long for results.

Whichever way you look at it, the data you get back from SKAN 4.0 is more complex than ever. To turn it into actionable insights, you need to optimize, adjust and merge it with different data sets such as media costs, predictive models and potential media mix models on a cross-channel level.

If this all seems complicated, I'd be happy to help you shed some light on it.

Incidentally, I believe that much more needs to be done to protect the climate.
Share this article