SKAN Schema Builder · Maria Atamanova

TL;DR

The schema follows when the money happens. A subscription with a trial has no revenue at 48 hours, so postback 1 codes the stage and the plan; a game earns from day one, so postback 1 codes revenue buckets.
SKAN 4 gives up to three postbacks – for the first 48 hours, for 48–168 hours and up to day 35 after first launch; a fine value of 0–63 only in the first, low / medium / high after that, each arriving 24–48 or 24–144 hours after its window closes.
Every row says why, and every assumption is tagged B (checked source) or A (assumption): no vendor bucket numbers, no invented crowd-anonymity thresholds, and the self-test runs in the page at #test.

Jargon: SKAN, AAK, postback, fine and coarse values, tier, non-install session, lockWindow, MMP, SAN / SRN, AEM

SKAN – SKAdNetwork, Apple's privacy-safe attribution for app installs from ads · AAK – AdAttributionKit, its successor with the same postback model · postback – the message Apple sends the ad network (and your MMP) about one install · conversion window – the period a postback covers, counted from first launch. Apple calls them days 0–2, 3–7 and 8–35; in hours that is 0–48, 48–168 and 168–840 · fine value – a number from 0 to 63 (6 bits), only in postback 1 · coarse value – low, medium or high; the only value in postbacks 2 and 3, and what small sources get in postback 1 · tier – the crowd-anonymity level Apple gives a source; it decides whether you get a fine value, a coarse one or nothing · non-install session – any app open after the first launch; the usual Low condition in postbacks 2 and 3 · lockWindow – closing postback 1 early so it is sent sooner · MMP – mobile measurement partner (AppsFlyer, Adjust and others) · SAN / SRN – self-attributing network, or self-reporting network in AppsFlyer's terms: claims installs through its own API (Meta, Google, TikTok) · AEM – Meta's Aggregated Event Measurement.

How to use – 30 seconds

Pick your product: a subscription app, or a game that earns from purchases, ads or both.
Answer the product questions. Subscriptions: where people pay, trial length, when trials start, your one or two plans, purchases without a trial and upsells. Games: how far revenue buckets should reach and which early events matter.
Read the schema: postback 1 as six bits plus a coarse fallback, postbacks 2 and 3 as coarse values. Every row says why. Click the bits, or try a player, to see how one value is built.
Optional: tick your iOS channels to see how much SKAN matters for you. They don't change the schema; they only settle the lockWindow advice.
Follow the steps for your MMP.

Questions this tool gets asked

What is a SKAN conversion schema?
The mapping your MMP uses to turn what a user did after install into the values Apple sends back: a fine value from 0 to 63 (six bits) in postback 1, and a coarse value – low, medium or high – in postbacks 2 and 3 and for small sources. You set it once, in the MMP, for every network that buys iOS installs.

What are the SKAN 4 conversion windows?
Three, counted from the first launch, not from the install: days 0–2 (the first 48 hours), 3–7 and 8–35. Postback 1 arrives 24–48 hours after its window closes; postbacks 2 and 3 arrive 24–144 hours after theirs. Only postback 1 can carry a fine value, and only on crowd-anonymity tiers 2–3.

Why is there no revenue in postback 1 for a subscription app with a trial?
Because a trial has charged no one by 48 hours. Postback 1 codes the stage and the plan – a trial started on the monthly or the annual plan – and the money goes to the postback whose window holds the first charge: postback 2 for a 3–5-day trial started in the first 48 hours, postback 3 for a 7- or 14-day trial. A 1-month trial charges too close to day 35 for any postback to see it.

Should I lock postback 1 early?
Not at launch. A lock at 24 hours sends postback 1 about a day sooner and loses everything between 24 and 48 hours after first launch. It is worth testing later only when your own data shows almost all of the optimization event within 24 hours of first launch, a meaningful share of budget goes to ad networks that optimize on SKAN, and those networks agree. Meta optimizes on AEM and Google on its own model, so for them the speed of the postback matters little.

Does SKAN work without tracking consent?
Yes. Apps can call the SKAN APIs regardless of their tracking authorization status, so SKAN counts installs from ads whether users consented or not. It does not see organic installs, networks that don't use SKAN, or installs that are never opened.

SKAdNetwork or AdAttributionKit?
Both work, with the same postback model: three windows, the same delays, a fine value only in postback 1. On its SKAdNetwork page Apple writes: “Use AdAttributionKit for app ad campaigns on the App Store and alternative marketplaces.” The SKAdNetwork class itself is not deprecated, and a schema carries over as it is.

Is anything I type sent anywhere?
No. The schema is computed in your browser and nothing you enter leaves the page. The tool is not affiliated with Apple, AppsFlyer or Adjust.

Why set up SKAN at all?

Short answer

If you buy mostly Meta and Google, SKAN isn't what you optimize on – they, and since 2025 TikTok, run on their own data. It's insurance you set up before you need it: ad networks without their own measurement officially have nothing else, clean SKAN data takes weeks to build up, and it's an independent cross-check on what the platforms report.

If Meta optimizes on AEM, Google on its own model, and part of the money comes through the web, why bother? Three reasons, and one honest limit.

Ad networks without their own measurement run on it. AppLovin, Unity, Moloco and similar networks work through MMP links. For users who said no to tracking, SKAN is officially the only signal they have. You may not buy them today – but the day you scale iOS beyond Meta and Google, they're often next.
Set it up before you need it. Postbacks for an install keep arriving for up to about 41 days, and a schema is only trustworthy once you have seen it on real traffic. Set it up now, and the day you add a network that relies on SKAN, it starts on a schema that is already checked – instead of six weeks of learning what your own numbers mean.
It's an independent cross-check. Apple signs every postback, and it doesn't depend on tracking consent or on what a platform reports about itself. It has its own blind spots – its own attribution rules, delays, empty postbacks at low volume, no organic installs – so treat it as a second opinion, not a referee.

Honest limit: Google uses SKAN as one input to its iOS modeling and shows a separate SKAN report – how much weight it gets, Google doesn't say.

Skipping the schema doesn't switch SKAN off – installs still get reported, just with no value attached, so networks bidding on SKAN can only optimize for installs, not for trials or revenue. That's why the schema matters – and why you only want to design it once.

Why set it once

Changing the schema no longer pauses Meta ad sets, as it did in 2021–23. It still costs about six weeks of mixed data and a break in the series, so you design it once.

Old reason vs today

The old advice was "if you change the schema, everything stops for a few days". The conclusion still holds; the reason changed.

	Old reason (2021–23)	Today (2025–26)
What happened when you changed the schema	Meta paused the affected iOS ad sets that ran on SKAN. There, SKAN was the only optimization signal.	No pause. Meta optimizes on AEM, which does not use the SKAN schema. TikTok can run without SKAN. Google and Apple never paused.
Where the cost is	Campaign downtime: lost money and volume.	Data. Postbacks from installs made under the old schema keep arriving for up to about 41 days (a 35-day window plus up to 144 hours of delay), and your MMP decodes them with the new schema. Networks that bid on SKAN relearn. Before/after comparison breaks.
Who it hurts most	Anyone buying iOS on Meta through SKAN campaigns. The pause was Meta's own; Google and Apple didn't pause.	Anyone buying through networks without their own measurement: games, ad networks.
So	Set the schema once and leave it.	The same. Design it once with spare bits, change it rarely and on purpose, and treat the next six weeks or so as a break in the series.

Setup

Product

Subscription app Game: purchases Game: ads Game: hybrid

Where do people pay?

In the app (App Store) On the web, before the store Both

Free trial?

Trial length only decides which postback gets the first charge. The App Store starts charging in the 24 hours before a trial ends, so a trial started in the first 48 hours charges between T−1 and T+2 days after first launch. A 3–5-day trial charges inside postback 2 (48–168 hours). A 7-day trial can charge on the last day of postback 2's window, but the charge reaches SKAN on the next app open, so the money goes to postback 3. A 14-day trial charges inside postback 3. A 1-month trial charges after day 28, too close to day 35 for the app to report it (the 28-day cutoff is this tool's assumption).

When do trials start??

Mostly on install day Spread over the first two days Mostly after day 2 Don't know

This decides whether trial bits in postback 1 fill up, and whether locking postback 1 early pays off. For reference: in RevenueCat's State of Subscription Apps 2026, 78–90% of trials start on the day of install, depending on the category, and another 5–12% on days 1–3. SourceB

How many plans do you sell?

One Two More than two

and

Which of the two brings more money per new subscriber??

Not always the longer one: a weekly plan can bring more per subscriber than a monthly one. The more valuable plan gets the higher bit and the High coarse level.

Can people buy right away, without a trial?

No Yes

Is there an upsell in the first 48 hours??

No Yes

Each "yes" here and in the question above takes one bit of postback 1 from the cheapest funnel event: first onboarding_start, then signup_successful.

Funnel steps in your app?

Untick what your app doesn't have. Rename to the event names you use in your MMP.

These are the funnel events of postback 1 and its coarse fallback, from the cheapest to the deepest. A step you untick frees its bit for your key events below. The names are placeholders until you type your own. Sign-up is not used when money is taken on the web: there the app measures the login to the account bought on the web.

Your two key product events?

Placeholders until you type your own.

The feature people subscribe for, and a second one that shows deeper use. They fill the engagement levels of postbacks 2 and 3.

How to encode the six bits of postback 1?

Flags suit most subscription apps. Stage × quality is for when you need more detail.

Postback 1 can carry one number from 0 to 63 – six bits. There are two ways to fill them.

Flags – one event per bit.

Each bit answers yes or no: signed up, started onboarding, finished onboarding, saw the paywall, started a monthly trial, started an annual trial.
The number is just the set of ticks.
Plus: easy to read and to set up in any MMP.
Limit: a flag can't say "how much" – how many sessions, for example – and there's no room left to tell direct purchases apart by plan.

Stage × quality – two parts in one number.

Stage: how far the user got – install, onboarding, paywall, trial or purchase per plan, optionally a direct purchase and an upsell. The exact list follows your Setup answers: up to nine steps.
Quality: how many sessions in the first 48 hours, four levels.
Value = quality + 4 × stage, so a later stage always outranks more sessions and a bigger number means a more valuable user. The schema below shows your numbers.
Plus: keeps each plan's direct purchase apart and adds an engagement signal.
Cost: harder to read, and your MMP must support counting sessions.

Advanced

Flags Stage × quality

Needs an MMP that can count sessions in the first 48 hours: Adjust and AppsFlyer both can.?

The quality part of the value is the number of sessions in the first 48 hours. So every value has to say "reached this stage and had 2–3 sessions", and your MMP has to be able to set a condition on the session count.

Adjust: yes. In 63 CVs mode each value can take a Session count condition with Min and Max, next to the event for the stage. HelpB
AppsFlyer: yes. In Conversion Studio an In-app event measurement can count how many times an event happened (engagement, in ranges), and sessions use the af_app_opened event. HelpB
On AppsFlyer: the help doesn't say how a Funnel for the stage and a session count share the six bits of one value. Watch the Conversion-value capacity bar, and fall back to flags if the grid doesn't fit.A

Checked against the MMPs' help on 28–30 Sep 2026.

How far should revenue buckets reach?

Up to $A example – replace with your number

Even steps Finer at the low end

Postback 1 splits revenue from days 0–2 into buckets up to this amount; everything above lands in the last bucket. A good anchor is a high percentile (for example P95) of your own day 0–2 revenue per player – per paying player in a purchase game, per player in an ad-monetized one – where differences stop changing buying decisions. Ranges are in USD.

Finer at the low end helps when most players who bring money in the first days bring small amounts. Check your own distribution.

Bits for early engagement?

None One Two

Every engagement bit halves the number of revenue buckets. Use them if players who haven't paid yet still need to be told apart.

Hybrid: keep a bit for "made a purchase"?

No – one combined revenue Yes – separate payers from ad viewers

Default: one combined revenue (purchases + ads). Networks optimize on the value of a player, and separate buckets for each kind of money eat bits. The option spends one bit to tell payers from players who only watch ads.

Revenue lines for coarse values (revenue so far)?

by day 2 $ by day 7 $ by day 35 $ A

High-value lines. Example values, not benchmarks.

by day 2 $ by day 7 $ by day 35 $

Medium lines, optional. Empty: Medium uses your engagement events.

Coarse "high" means a player has spent or generated at least this much by the end of the window. Take the lines from your own revenue by day. With ads almost every player brings some revenue, so "more than $0" can't be the middle level: set a medium line, or leave it empty and Medium uses your engagement events.

Results update as you change the setup.

Your first 35 days

Trials start in the first 48 hours; a 7-day trial first charges 6–9 days after first launch. Postback 1 covers the first 48 hours, postback 2 runs to 168 hours, postback 3 to day 35.

Windows count from the first launch.?Windows count from the first launch, not from the install. Postback 1 arrives 24–48 hours after its window closes; postbacks 2 and 3 arrive 24–144 hours after theirs.

Postback 1

first 48 h · fine value + coarse fallback

Stage and plan, not money.?

At 48 hours a trial has no revenue yet, so postback 1 codes the stage and the plan, not money. You configure both the fine and the coarse value; Apple decides which one arrives, by tier.

Fine value: six flags

Click the bits to build a value.?

The most valuable event sits on the highest bit, so a bigger number always means a more valuable user.

Conversion value 47 = 32 + 8 + 4 + 2 + 1 · trial_annual_started + paywall_view + onboarding_end + onboarding_start + signup_successful

Value	Event	What it means
32	trial_annual_started	started a trial on the annual plan? You said the annual plan brings more money per subscriber. One shared trial_started would make the network treat an annual trial and a monthly trial as equal, and it would bring both just as happily. This is the most expensive pair of bits in the schema.
16	trial_monthly_started	started a trial on the monthly plan? Its own bit, so a monthly trial isn't confused with an annual one.
8	paywall_view	reached the paywall? Mid-funnel diagnostics: separates people who saw the offer and passed from people who never got there.
4	onboarding_end	finished onboarding? The strongest non-money sign of intent in the first 48 hours.
2	onboarding_start	started onboarding? Separates people who opened and left from people who began.
1	signup_successful	created an account? The cheapest event in the funnel.

Coarse fallback

Arrives when the source is too small for a fine value.?

Apple decides by crowd-anonymity tier whether postback 1 carries the fine value or only this coarse one. Small sources get coarse, so the coarse ladder has to make sense on its own.

Level	Condition	Value	What it means
Low	Session	Install	installed, nothing else? Something has to sit on Low, and 'installed and nothing more' is the one condition every install meets.
Medium	Event	trial_monthly_started	trial on the monthly plan? Coarse arrives exactly where volume is lowest. Keeping the plan split here means optimization isn't blind on the smallest sources.
High	Event	trial_annual_started	trial on the annual plan? The same plan split as the fine value. paywall_view drops out of coarse on purpose: losing mid-funnel diagnostics is cheaper than losing the difference in value.

lockWindow for postback 1

Don't lock at launch.?

A lock at 24 hours sends postback 1 about a day sooner, but everything between 24 and 48 hours after first launch is lost for it: trials and purchases on day 1, later funnel steps, sessions. It can pay off only for ad networks that optimize on SKAN (AppLovin, Unity, Moloco and similar), and only once your own data shows almost all trials within 24 hours of first launch. Meta optimizes on AEM, so for Meta alone the speed of the postback doesn't matter. Tick your channels further down to see whether a lock is worth testing. For reference, RevenueCat 2026: 78–90% of trials start on install day, another 5–12% on days 1–3 (see Setup, Source). Install day is a calendar day, not the 24 hours after first launch, so check this in your own data.

In the MMP: AppsFlyer Conversion Studio locks by time or when the high coarse value is reached. Adjust generally advises against lock windows and suggests agreeing with the network first.

Postback 2

48–168 h · coarse only

Engagement in the trial.?

A 7-day trial started in the first 48 hours charges 6–9 days after first launch: the App Store starts charging in the 24 hours before a trial ends, so a large share of charges, possibly most when trials start on install day, falls on the last day of postback 2's window. But a charge happens on Apple's server and reaches SKAN only when the user next opens the app, often after 168 hours, so postback 2 would see only part of the money. The money goes to postback 3 and postback 2 measures engagement in the trial. Charges before 168 hours count in postback 3 only if your MMP maps it by the state so far; if your data shows most conversions reported before 168 hours, add the conversion to High of postback 2 as well.

Level	Condition	Value	What it means
Low	Session	Non-install session	came back to the app after install? You can't map the absence of an event, only something that happened. A session after install is the floor that still says the user came back.
Medium	Event	core_feature_1_used	used the main feature? The feature people subscribe for. Using it in the trial is the earliest predictor of conversion you control.
High	Event	core_feature_2_used	reached the second key feature? Moving on to a second feature means the person explored the product, not just looked once. If your MMP allows a count condition, repeat use of the main feature is a good alternative: habit predicts conversion better than a single action.

Postback 3

168 h – day 35 · coarse only

Money: the first charge.?

First charge 6–9 days after first launch, reported on the next app open: the money is here.

Level	Condition	Value	What it means
Low	Session	Non-install session	came back, but no paid subscription? You can't map the absence of an event, only something that happened. A session after install is the floor that still says the user came back.
Medium	Event	trial_monthly_converted	paid subscription on the monthly plan? The plan you said brings less sits on the middle level, so the two kinds of money stay apart.
High	Event	trial_annual_converted	paid subscription on the annual plan? This mirrors postback 1. If you optimize on annual trials, this is where you check that annual money followed. Measuring 'any conversion' here would leave nothing to check.

What this gives the buying team

Where a network optimizes on SKAN, optimize on postback 1: many signals, fast. Postbacks 2 and 3 are for checking, not for optimizing. When they diverge, that is a signal: postback 1 grows and postback 3 doesn't, so trials don't reach money; annual trials grow but trial_annual_converted doesn't, so the problem is the annual offer, not the buying.

Where this schema will be blind

Renewals fall after day 35 or too close to it (annual: day 371–374, monthly: day 36–39)?

The annual plan renews around day 371–374, after the window closes. The monthly plan renews around day 36–39, after the window closes. Don't spend a value on them; they will stay empty.

Check how your MMP maps postback 3?

Part of the first charges can happen before 168 hours, in postback 2's window. They count in postback 3 only if your MMP maps it by the state so far, not only by events inside the window; the help pages don't say which, so check it in your account.

Small sources get less or nothing?

Apple sends a fine value only on the higher crowd-anonymity tiers; lower tiers get coarse or no value, and Apple doesn't publish the thresholds. Fewer, larger campaigns get more data, and the schema has to make sense on coarse alone.

Server-side events still need an app open to be reported?

A trial converting or a renewal happens on Apple's server, but it only reaches postbacks 2 and 3 if the user opens the app later in the same window and the app reports it then. Log the conversions and renewals you map from the app on its next open; a server-to-server event can't update SKAN by itself.

Changing the schema breaks the series?

Postbacks from old installs keep arriving for up to about 41 days and get decoded with the new schema. Keep spare values now.

How much does SKAN matter for you?

Optional. Doesn't change your schema.?The schema follows your product, not the platform: one schema for every network. Your channels only settle one setting, the lockWindow advice for postback 1.

Tick the channels you buy on iOS and, if you like, type rough shares of your iOS budget.

Tick the channels you buy on iOS to see where SKAN sits for each of them.

Set it up in your MMP

AppsFlyer Adjust Other / none

7 steps in AppsFlyer, from AppsFlyer's help pages, checked 28 Sep 2026. Your screens may differ.?

Screen names from AppsFlyer – SKAN Conversion Studio (last updated April 26, 2026), checked 28 Sep 2026. MMP screens change; the help page is the source of truth. Tags: B – checked source (vendor help or published report) · A – assumption.

Step by step in AppsFlyer

Open Settings → SKAN Conversion Studio. In the options menu (⋮) check that SKAN measurement is on, pick SKAN 4.0, press Continue.B
Window 1 (1-2 days), fine CV → + Add measurement → In-app event for each flag, most valuable first: trial_annual_started, trial_monthly_started, paywall_view, onboarding_end, onboarding_start, signup_successful.B Check Conversion-value capacity after each one; the help doesn't say how many bits one event takes, so the capacity bar is your guide.A Optionally turn on Single Source of Truth (SSOT).B
Coarse tab (only Revenue and In-app event are available here): Low: user session · Medium: trial_monthly_started · High: trial_annual_started. AppsFlyer recommends a user session on Low, otherwise the postback may not be sent at all.B
Lock window: leave off. The two conditions are Time and High coarse value.B
Window 2 (3-7 days): Low: user session · Medium: core_feature_1_used · High: core_feature_2_used.B
Window 3 (8-35 days): Low: user session · Medium: trial_monthly_converted · High: trial_annual_converted.B
Save, then check that partner postback mappings match the events you used here.B

Take it with you

Reference

What SKAN sees, and what it doesn't

It counts installs from ads whether users consented to tracking or not. Apple: apps "can call these APIs regardless of their tracking authorization status."

It does not see:

organic installs, at all;
networks that don't use SKAN, for example TikTok with SKAN switched off;
installs that are never opened: the user has 60 days to launch the app, and without a launch there is no postback.

So "SKAN covers every install" is wrong. The accurate version: SKAN sees everyone who came from an ad, consented or not. It doesn't see organic installs or networks without SKAN.

Postbacks, windows, delays, fine and coarse values, tiers, lockWindow

Postback	Window	Delay after the window	What arrives
1	days 0–2 (first 48 h)	24–48 h	fine value (0–63) on tiers 2–3, otherwise coarse
2	days 3–7 (48–168 h)	24–144 h	coarse only
3	days 8–35 (from 168 h)	24–144 h	coarse only

Windows count from the first launch, not from the install. The delay is random.
You set the fine and the coarse value in one call; Apple decides which one arrives, by tier.
If the value was never updated, the field is missing. That is not 0 and not "low".
Postbacks 2 and 3 need a value update inside their own window, and a value can only be updated while the app is open. No app open on days 3–7 means postback 2 is empty or doesn't come.
lockWindow (SKAN 4): the system prepares the postback at once and ignores later updates in that window; the random delay still applies. SKAN 3 had a rolling 24-hour timer that restarted with every higher value; SKAN 4 has fixed windows and no timer.

Tier	Postback 1	Postbacks 2–3
0	2-digit source identifier, no value	not sent
1	2 digits + coarse	2 digits + coarse
2	2, 3 or 4 digits + fine	2 digits + coarse
3	as tier 2 + source app ID (in-app ads) or source domain (web ads), optionally country code	2 digits + coarse

Apple does not publish tier thresholds in installs. The tier can't be configured and can change between periods. It depends on the crowd size of the placement, the advertised app, the country and the identifier itself.

Web ads: since iOS 16.1 a click-through ad in Safari itself (not in an app's built-in browser) can be attributed too, but only when a registered ad network serves it as an attributable web ad: a special App Store link with a one-time nonce and a signed response from the network's server. An ordinary web-to-app landing page doesn't qualify. The user has 30 days to install. Money taken on the web before the store never reaches SKAN. Attribution windows: 30 days from click to install, 24 hours for view-through, 60 days to first launch. With AdAttributionKit on iOS 18.4, the developer can set them: click 1–30 days, view 1–7 days, plus a cooldown of 0–720 hours.

Channels: SAN / SRN and networks without their own measurement

Channel	SAN / SRN?	How it sees iOS users who didn't consent	SKAN role
Meta	Yes	AEM, Meta's own aggregated protocol.	Secondary
Google Ads	Yes	Modeled conversions: IDFA of users who consented, on-device measurement, and SKAN as one input.	Input
TikTok	Yes, since 2023	Data your MMP shares about all users: matched for users who consented, modeled for the rest. SKAN is a switch you can turn off.	Optional
Apple Ads	Own attribution (AdServices)	The AdServices token, which attributes without ATT. Apple Ads registered with AdAttributionKit in April 2025, starting with SKAN versions 1–3.	Own attribution
Ad networks AppLovin, Unity, Moloco, ironSource, Mintegral, Liftoff	No – MMP links	Only SKAN. They work through MMP links, so for users who said no to tracking there is nothing else.	Core
Web funnels web2web; web2app with payment on the web	–	Pixel and Conversions API, click IDs, matching by login.	Not in path

TikTok moved like Meta: a SAN since 2023, and SKAN is now a switch.

It has been a SAN since 2023 (earlier it worked through MMP links). Its iOS campaigns now run on data the MMP shares about all users; SKAN is a switch in TikTok, and with it off the iOS campaign quota is unlimited (TikTok help, checked 30 Sep 2026).

Networks without their own measurement see users who said no only through SKAN.

AppLovin, Unity, Moloco, ironSource, Mintegral, Liftoff and similar networks work through MMP tracking links. A link carries a click ID and, if there is one, the IDFA. For users who consented, the MMP matches click and install. For users who didn't, the MMP has no identifier to match, and fingerprinting is against Apple's rules, so the install usually lands as organic in the MMP. For them the only official trace is the SKAN postback. The difference between SRN and non-SRN is not "SKAN or no SKAN", it is what covers users who said no: an SRN has its own protocols and modeling, a non-SRN has only SKAN.

Double consent

For a deterministic match on a paid install, the IDFA has to be available in two apps: the one that showed the ad and the one being advertised. The user has to allow tracking in both. So deterministic data on paid installs covers fewer people than your app's own opt-in rate suggests. This is one more reason SKAN matters for networks that have no other signal.

What a schema change really costs

Your MMP decodes postbacks with the latest schema, while postbacks from installs made under the old one keep arriving for up to about 41 days (35-day window plus up to 144 hours of delay). Postbacks 2 and 3 suffer most.
Networks that optimize on SKAN relearn.
Before/after comparison breaks: it is a break in the time series.
In 2021–23 Meta paused affected iOS ad sets on SKAN when the configuration changed. Today Meta optimizes on AEM, which doesn't use the SKAN schema, so that pause no longer applies.

SKAN and AdAttributionKit

The SKAdNetwork class is not deprecated (only its old methods are). On its page Apple writes: "Use AdAttributionKit for app ad campaigns on the App Store and alternative marketplaces."
The two work together: only one impression wins, whether it came from AdAttributionKit or SKAdNetwork.
Same model: three windows, the same delays, a fine value in postback 1 on tiers 2–3, coarse otherwise. A schema carries over.
AdAttributionKit adds re-engagement postbacks (iOS 18), configurable windows and cooldown, conversion tags and development postbacks (iOS 18.4).
Apple Ads registered with AdAttributionKit on April 10, 2025, starting with SKAdNetwork versions 1–3.

Three eras of iOS attribution

Era	What it was	SKAN	For buying
Before ATT (until iOS 14.5, April 2021)	IDFA by default for everyone who hadn't switched it off	not needed	Per-user deterministic attribution; revenue tied to campaign and creative
ATT without enforcement (2021–23)	ATT prompt; fingerprinting against the rules but not checked in practice. MMPs kept probabilistic matching	SKAN 2–3: one postback, 6 bits, a 24-hour timer restarted by each higher value	For many, SKAN was a formality
The closed door (2023/24 to now)	Privacy manifests and required-reason APIs, enforced from spring 2024; for users who said no, attribution moved to SKAN, platform modeling and aggregates. SRNs cover opted-out users with their own protocols and modeling	SKAN 4 (iOS 16.1): up to three postbacks, fine only in the first, coarse after, lockWindow instead of a timer. AdAttributionKit (iOS 17.4): same model	For non-SRN networks SKAN is the main signal, so games depend on it most. Subscription apps with web funnels can barely notice it

This tool describes only the third era. Anything about a timer or a single postback belongs to history, not to the logic here.

Design decisions

The schema follows when the money happens. A subscription with a trial has no revenue at 48 hours, so postback 1 codes the stage and the plan. A game has revenue on day one, so postback 1 codes revenue buckets. Revenue-bucket templates made for every vertical don't fit a trial.
The most valuable event sits on the highest bit, so a bigger number always means a more valuable user.
Flags by default, stage × quality on a switch.
One or two plans. The classic pairs are monthly + annual or weekly + annual. You say which of the two brings more money per subscriber; it is not always the longer one. More plans come in a later version.
Purchases without a trial and upsells are optional bits. Each takes the place of the cheapest funnel event: first onboarding_start, then signup_successful.
Your funnel, your names. Untick the funnel steps your app doesn't have and rename the rest. Bits left free go to your key product events rather than staying empty; for trials that start after 48 hours, early feature use is the best predictor you have.
Games with ads: Medium is never "more than $0". Almost every player brings some ad revenue, so Medium takes your medium revenue line, or an engagement event if you leave it empty.
Channels don't change the schema. It follows the product, not the platform, and is one schema for every network. Channels only decide whether locking postback 1 early pays off.
Hybrid games: one combined revenue by default, with an optional "made a purchase" bit.
No vendor bucket numbers and no invented crowd-anonymity thresholds. Bucket edges and revenue lines come from your inputs; Apple doesn't publish tier thresholds.
Postback 3 mirrors postback 1 where money arrives there, so you can check that optimizing on a valuable trial brought valuable money.
Only the current era. SKAN 4 and AdAttributionKit share the model; SKAN 2–3 logic is history.

Sources

Tags: B – checked source (vendor help or published report) · A – assumption. Platform facts checked 27–28 Sep 2026. Run the built-in self-test.

Apple – Receiving postbacks in multiple conversion windows (windows, delays, fine/coarse, tiers, lockWindow)
Apple – updatePostbackConversionValue(_:coarseValue:lockWindow:)
Apple – Receiving ad attributions and postbacks (60 days to first launch, web ads, attribution windows)
Apple – SKAdNetwork (works regardless of tracking authorization)
Apple – AdAttributionKit: postbacks in multiple windows · configuring attribution rules · interoperability
Apple Ads – Ad attribution overview
RevenueCat – State of Subscription Apps 2026 (trial starts by day) B
RevenueCat – iOS attribution: SKAN, AEM, probabilistic (AEM doesn't use SKAN)
Google Ads Help – iOS App campaign measurement and reporting · SKAdNetwork conversion value schema
TikTok – iOS real-time conversion reporting · SAN for app advertisers (2023)
AppsFlyer – SKAN Conversion Studio · SRN list
Adjust – Set up SKAN 4 mapping

Not affiliated with Apple, AppsFlyer or Adjust. Nothing you enter leaves this page. Other tools: Unit Economics Estimator · LTV Calculator.