How SKAdNetwork actually works: an iOS analytics guide without rose-tinted glasses

Dilshat Rakhimov
May 2026 · 5 min read

When iOS 14.5 shipped with the App Tracking Transparency (ATT) prompt, the usual IDFA-based attribution broke. Today, Apple's SKAdNetwork (SKAN) is the only way left to estimate iOS ad effectiveness at all. We all had to forget about tracking individual users and learn to work with aggregated cohorts and delayed data. If your team learns to properly link SKAN, MMP, and Firebase data together, you stop pouring budget into a void and can actually optimize CAC.

Context: what we are dealing with

Before ATT, everything was simple: the user clicked an ad, the ad network sent the device ID (IDFA) to the MMP, and after install the MMP joined the click and the conversion with 100% accuracy.

The new SKAN reality looks different:

1. Aggregated data: we no longer see individual users. Data arrives in bulk batches.
2. Delayed postbacks: conversion notifications are intentionally delayed by 24-48 hours (sometimes longer), so we cannot identify a user by install time.
3. Event limits: we now have Conversion Values. It is simply a number from 0 to 63. And you have a very narrow window to encode the most important information into that number.

The natural question is: how do you optimize ad campaigns quickly when results arrive only a couple of days later and in such a stripped-down form?

Deep dive: how this works under the hood

To work with SKAN properly you need to understand the full data path from click to dashboard. It involves the device (iOS), Apple itself, the ad network, and your MMP.

The logic of timers and Conversion Values (CV)

At the core of SKAN is the Conversion Values (CV) system. As soon as a user opens the app for the first time, a 24-hour timer starts. Any meaningful action (a registration or a purchase) can update the CV, but only upward.

One important nuance: every successful CV update resets the 24-hour timer. We collect more behavioral data but push the postback even further into the future.

Once the user stops doing the actions you care about and the timer expires, iOS starts a second, randomized timer (0 to 24 hours). The postback goes to the ad network and the MMP only after that timer runs out. That random timer is why ad-account numbers always lag.

The integration path (SKAN + MMP + Firebase)

Without proper infrastructure, SKAN data will stay as opaque numbers between 0 and 63. Our job is to decode them, tie them to ad spend, and store them inside the core analytics (Firebase, GA4, or BigQuery).

The role of the MMP (AppsFlyer, Adjust, Branch)

The MMP acts as the central hub:

• CV mapping configuration: inside the MMP dashboard you define the rules. For example, CV 1 = "Registration", CV 2 = "Purchase < $10".
• Postback collection: networks deliver SKAN postbacks to the MMP, which decodes them by your rules.
• Data joining: the MMP joins this data with its own attributions and the spend from the ad accounts.

Integration with Firebase and BigQuery

Because SKAN postbacks contain no user_id or app_instance_id, we cannot just bind them to user sessions in Firebase. The right architecture goes through a warehouse:

Instead of trying to push SKAN events directly into Firebase, we export the raw data from the MMP (via Data Locker or the Pull API) and the raw events from Firebase into a single store — BigQuery. And then, inside BigQuery, we build aggregated reports such as Blended ROAS.¹

Optimizing campaigns in real time is a bad idea. Because of SKAN delays, you can only assess a cohort honestly on day 3-4 after install. Give campaigns time.

What to do next

For marketers:

• Evaluate campaigns in 3-7 day windows and forget about daily optimization.
• Focus on LTV prediction (pLTV). Find the in-app actions during the first 24 hours that predict future purchases best and tie them to Conversion Values.
• Watch Blended ROAS (total revenue / total spend) to see the full picture.²

For analysts:

• Set up a Raw Data export from the MMP to Google BigQuery.
• Build a single data model that ties ad-account spend, SKAN postbacks, and Firebase events together.

For developers:

• Make sure the MMP SDK initializes immediately on app start. Otherwise you lose the beginning of the install window.
• Show the ATT (App Tracking Transparency) prompt at the right moment in onboarding so that users are more likely to grant tracking consent.

The trick is to step beyond the old attribution metrics and build a BigQuery-based stack that keeps working even under strict privacy rules.

Dilshat Rakhimov
Growth Analytics & Digital Architecture

¹ Firebase & BigQuery Integration Guide
² Blended ROAS is calculated as the ratio of total ad spend to all generated revenue.