Every playable ad guide tells you to test creative variants and let the data decide. On iOS, that advice quietly stopped working the way it used to. SKAdNetwork replaced device-level attribution with an aggregated, delayed, privacy-preserving postback, and creative-level reporting — knowing which of your four playables produced the installs — became something you have to deliberately design for rather than something that arrives in a dashboard. This guide covers what is still measurable, how to structure for it, and what to stop expecting.
What actually changed
Before, an install could be tied back to the exact impression that produced it, including which creative. Under SKAdNetwork, Apple's framework sends a signed postback after an install, and that postback carries a deliberately limited payload with no device identifier. Three properties make it awkward for creative testing:
- It is aggregated. You get counts, not individuals, and Apple applies privacy thresholds that can null out fields when volume is low.
- It is delayed. Postbacks arrive after a randomised timer, so same-day creative decisions are not possible.
- It is limited in dimensions. There is a fixed, small amount of space to encode everything you want to know about where the install came from.
That last point is the crux. On iOS, your creative dimension has to compete for room with campaign, geo, placement and audience — and the space is finite.
The source identifier is where creative lives
The field formerly called campaign ID is now the source identifier, and SKAdNetwork 4.0 widened it from two digits to four — from 100 possible values to 10,000. That expansion is the single most useful thing that has happened for creative measurement on iOS, because it makes it viable to encode more than one dimension.
The practical approach is to treat the four digits as a structured code rather than an opaque number. A common pattern is to allocate digit ranges to dimensions — some digits for campaign, some for creative concept, some for variant. Then a postback carrying a source identifier can be decoded back into "campaign 12, concept 4, variant 2".
Plan the encoding before the campaign
The scheme has to be decided up front and shared with whoever configures the campaigns, because it is baked into how source identifiers are assigned. Retro-fitting a scheme onto identifiers that were allocated arbitrarily is not possible — the historical postbacks cannot be re-decoded.
Hierarchical values and why coarse data appears
SKAdNetwork 4.0 introduced hierarchical source identifiers and hierarchical conversion values, which exist because of Apple's privacy thresholds. When install volume for a given combination is high enough, you receive the full-resolution value. When it is not, you receive a coarser one — or the field is withheld entirely.
This has a direct consequence for how you test playables: splitting spend across many creative variants fragments volume, and fragmented volume falls below the thresholds, and below the thresholds you get coarse or null data. The instinct to test eight variants at once is actively counter-productive on iOS. Two or three well-differentiated variants with enough spend behind each will tell you more than eight starved ones.
Multiple postbacks change what you can ask
SKAdNetwork 4.0 supports up to three postbacks at different time windows. That lets you separate the install from early engagement and from a later in-app action — which matters for playables specifically, because the format's claimed advantage is user quality rather than raw install volume.
The argument for playable ads has always been that a user who played a sample of your product knows what they are installing, so they retain and monetise better. Under a single install-time postback, that advantage is invisible and playables look expensive per install. With a later postback carrying a retention or purchase signal, the advantage becomes measurable. If you are buying playables on iOS and only measuring the first postback, you are measuring the format on the one dimension where it is weakest.
Design conversion values around the playable's promise
- Decide the post-install action that reflects why you ran a playable — tutorial completed, first level finished, first purchase, subscription trial.
- Encode that action in the conversion value, and make sure the timing window is long enough for real users to reach it.
- Keep the schema stable across a test. Changing what a conversion value means mid-flight makes the two halves incomparable.
- Accept the delay. Postback timers mean iOS creative decisions run on a weekly cadence, not a daily one.
Do not port your Android cadence to iOS
Android still supports faster, more granular creative feedback. Teams that run one testing cadence across both platforms end up either moving too slowly on Android or making iOS calls on data that has not stabilised. Run them as two different rhythms.
What you genuinely cannot get back
Some things are gone and no configuration recovers them: user-level paths from impression to install, unlimited creative dimensions in a single report, real-time creative optimisation, and reliable measurement of very small segments. Vendors offering to restore user-level iOS attribution are describing something that either does not work or does not comply.
The realistic posture is to use SKAdNetwork for directional creative decisions at low resolution, lean on Android and web for higher-resolution creative learning, and transfer those learnings across where the creative is the same. It is less satisfying than the old model and it is what is actually available.
Where deep linking fits
One related point that is often conflated: SKAdNetwork governs attribution, not the click. Carrying a user's in-ad choices into the destination is a separate mechanism, handled through your MMP's tracking link, and it still works on iOS. What SKAdNetwork restricts is your ability to report on it at user level — not your ability to deliver a personalised first session. Those are different problems and worth keeping apart. See our deep linking guide for the delivery side.
A workable iOS creative testing method
Given the constraints, here is a structure that actually produces decisions rather than noise.
- Test two variants, not eight. Fragmenting volume across many variants pushes each below Apple's privacy thresholds, and coarse or null data is worse than a slower test.
- Make the two genuinely different. A different mechanic or a different opening, not a different button colour — small differences need statistical power you no longer have on iOS.
- Allocate enough daily spend per variant to clear thresholds consistently. It is better to test two variants properly over two weeks than six variants badly over the same period.
- Encode the variant in the source identifier using your pre-agreed scheme, so postbacks can be decoded.
- Wait a full postback window plus the conversion-value window before reading anything. Reading early is reading a partial picture that will move.
- Decide, then start the next pair. A slower cadence of clean decisions beats a fast cadence of ambiguous ones.
Use Android as the discovery environment
The most effective pattern most teams land on is to treat the two platforms as having different jobs. Android, with faster and more granular feedback, becomes where creative learning happens — where you narrow eight ideas to two. iOS becomes where you confirm the survivors at scale.
This works because creative insight generally transfers between platforms even when measurement does not. If a particular opening hook or end-card framing wins clearly on Android, that is usually a fact about the creative rather than about Android users. Discovering it where discovery is cheap and confirming it where confirmation is expensive is simply better use of both.
Keep the creative identical across platforms
If the Android and iOS versions of a creative differ — different art, different length, different end card — the transfer argument collapses and you are running two unrelated tests. Change one thing at a time across platforms too, not just within them.
Create playable end cards in minutes—no code required.
Open Playable Ads Maker