Your iOS campaign probably did not get worse on Tuesday. You just read Tuesday's numbers on Tuesday, and the SKAdNetwork postback delay means Tuesday's numbers were never finished.
This is the single most common way we see good iOS campaigns killed. A media buyer checks a two-day-old cohort, sees a cost per install well above target, panics, and turns off an ad set that would have corrected itself by the weekend. The data was not wrong. It was just incomplete, and incomplete SKAN data is always incomplete in the same direction: it undercounts.
Reading iOS performance well means knowing exactly how late your data is, and building decision rules that wait for it. Here is how the lag actually works and what to do about it.
Key takeaways
- A SKAdNetwork postback delay is a privacy feature, not a reporting fault: Apple randomises when conversion data is sent so it cannot be tied back to an individual.
- Under SKAN 4 the first postback lands roughly 72 to 96 hours after install, and the later two windows report days or weeks later.
- Recent days are always undercounted, so fresh iOS data reads pessimistic. Installs backfill upwards and CPI falls as postbacks arrive.
- Judge iOS on a seven-day rolling window, never on a single day, and give new creative at least seven days before calling it.
What a SKAdNetwork postback delay is
A SKAdNetwork postback delay is the randomised gap Apple inserts between the close of a conversion window and the moment the postback is actually delivered to the ad network. SKAdNetwork is Apple's privacy-preserving attribution framework for iOS: instead of telling Meta which user installed your app, it sends an aggregated, delayed signal saying that an install happened and roughly what the user did next.
The delay is deliberate. If postbacks arrived the instant a conversion occurred, the timing itself would identify the user, and the whole point of the framework is that it should not be possible to reconstruct an individual from ad data. Apple pays for that privacy with your timeliness, and you inherit the bill in Ads Manager.
The three windows, and when data actually lands
SKAN 4 gives you up to three postbacks per install, each tied to a measurement window and each with its own randomised delay (documented by Apple and summarised well by Jampp and Airbridge):
- Postback one: measures days 0 to 2, then waits a random 24 to 48 hours. It typically arrives 72 to 96 hours after the install.
- Postback two: measures days 3 to 7, then waits a random 24 to 144 hours.
- Postback three: measures days 8 to 35, then waits a random 24 to 144 hours.
The practical number to hold in your head is 24 to 72 hours of lag on the first read. Anything you look at inside that window is a partial cohort. It will fill in, and it will only ever fill in one way: upwards on installs and events, downwards on cost per install.
What the lag does to your CPI read
Spend is real time. Installs are not. That mismatch is the entire problem, because cost per install divides a number that has already finished by a number that has not started arriving yet.
Yesterday's iOS CPI is therefore always inflated, and the day before is still slightly inflated. Judged on the day, a healthy campaign can look like it is running at double its true cost, which is exactly the moment inexperienced operators intervene. For what those numbers should settle at once the postbacks are in, our mobile app CPI benchmarks for 2026 are the reference we use.
The same distortion is why iOS and Android should never be compared on same-day numbers. Android reports fast and iOS reports late, so a fresh dashboard makes Android look artificially efficient. Shifting budget on that comparison is one of the more expensive mistakes available to you.
What the lag does to your fatigue read
Creative fatigue is a trend, and the SKAdNetwork postback delay bends the end of every trend line downwards. The last two or three days of any iOS chart will always slope towards worse performance, whether or not the creative is actually tiring.
If you read that slope literally you will diagnose fatigue on perfectly healthy ads, refresh far too often, and pay the calibration cost of new creative every time. The fix is to cut the tail: when assessing fatigue on iOS, ignore the most recent three days entirely and read the trend up to that point. Upper-funnel signals help here too, because impressions, hook rate and frequency are all reported in real time and are not subject to the delay at all. That is one reason we lean on them as the early warning system in our guide to creative fatigue for mobile apps.
Meta is reading the same delayed data
It is easy to assume the lag is a reporting inconvenience and that Meta's delivery system sees something cleaner underneath. It does not. Meta's optimisation is working with iOS conversion data that is one to three days stale, a point Segwise makes clearly in its comparison of Meta AEM and SKAN.
That has a direct consequence for how you operate. The algorithm needs more elapsed time on iOS to reach the same confidence it reaches quickly on Android, so the standard advice to give a campaign three or four days to settle is simply wrong for iOS. It needs seven to ten. It also means the ranking system is judging your creative on partial evidence early on, which is worth understanding alongside how Meta's Andromeda retrieval engine selects ads in the first place.
Decision rules that respect the lag
The operating fix is not clever modelling. It is patience, applied consistently, as rules rather than as instinct. These are the four we hold ourselves to on iOS accounts.
1. Seven-day rolling, always
Never read a single day of iOS performance. A seven-day rolling view absorbs the lag, smooths the weekday pattern, and moves slowly enough that a genuine change is obvious when it happens.
2. Discard the last three days for decisions
Look at them for spend pacing and delivery health, never for cost or conversion judgements. Treat that window as provisional in the same way you would treat unreconciled accounts.
3. Give new creative seven days minimum
A new concept needs enough elapsed time for its first postbacks to land before you can honestly compare it to anything. Killing on day three is killing on the delay, not on the creative.
4. Set a floor spend before judging at all
Time is necessary but not sufficient. A concept also needs enough spend behind it that the postbacks arriving represent a meaningful number of installs rather than a handful. We set that floor per account against the client's target CPI rather than using a universal number, because the same spend buys very different evidence at £1 and at £7.
None of this is sophisticated. It is just the discipline of not reacting to numbers that have not finished arriving, and across the accounts we audit it is one of the most common gaps between a team that thinks its iOS campaigns are unprofitable and one that knows they are not.
Frequently asked questions
What is a SKAdNetwork postback delay?
A SKAdNetwork postback delay is the randomised waiting period Apple applies between the end of a conversion window and the moment the postback is sent to the ad network. Apple adds the delay deliberately so that a conversion cannot be timed back to an individual user. The result is that install and event data reaches Meta hours or days after the activity actually happened.
How long is the SKAdNetwork postback delay?
Under SKAN 4, the first postback carries a randomised delay of 24 to 48 hours after its 0 to 2 day conversion window closes, so it typically lands around 72 to 96 hours after the install. The second and third postbacks are delayed by 24 to 144 hours after their windows close. In practice most operators plan around a 24 to 72 hour lag on the first read.
Does the postback delay affect Meta's optimisation as well as my reporting?
Yes. Meta is not exempt from the lag, it is subject to it. The delivery system is making bidding and audience decisions on iOS conversion data that is one to three days old, which is part of why iOS campaigns need a longer calibration period than Android before their numbers mean anything.
How long should I wait before judging an iOS campaign?
Give a new iOS campaign or a new creative at least seven days before you treat its numbers as real, and judge it on a seven-day rolling window rather than on single days. Three or four days is enough for Android but it sits inside the SKAdNetwork postback delay on iOS, which means you are reading an incomplete picture and usually a pessimistic one.
Why do my iOS installs keep getting revised upwards?
Because postbacks arrive after the fact and get attributed back to the day the install happened. Yesterday and the day before are always undercounted at the moment you look at them, which is why a campaign that looked broken on Tuesday morning often looks fine by Friday. Backfill is normal behaviour, not a bug or a tracking failure.
Want this run for you?
Most iOS accounts we take over are not underperforming. They are being read wrong, then managed against the misreading, which produces real underperformance a few weeks later. Fixing the reading is usually the cheapest win available.
If you run a mobile app spending £25k or more per month on Meta and want creative and measurement handled by a team that plans around the lag rather than reacting to it, apply to work with us. We take a small number of mobile app clients per quarter.