SKAdNetwork and Apple Search Ads — What Really Attributes in 2026
How SKAdNetwork attribution interacts with Apple Search Ads in 2026. SKAN 4.0 postback windows, Ad Services API as the first-party path, and when ASA-only operators do not need an MMP.
TL;DR
Apple Search Ads has two attribution paths in 2026:
- Ad Services API (first-party) — Fast (minutes), deterministic, ASA-only, no MMP required.
- SKAdNetwork (SKAN) — Slower (hours to days), privacy-preserving, cross-network, typically routed through an MMP.
For ASA-only optimization, use Ad Services API as the primary signal — it is more granular and faster than SKAN. For cross-channel attribution, layer SKAN through an MMP for apples-to-apples comparison across ASA, Meta, Google, TikTok, and other networks.
This guide covers how the two paths work, when to use which, and the SKAN 4.0 changes that matter for operators.
The two attribution paths
Ad Services API
Apple’s first-party attribution API specifically for Apple Search Ads:
- How: On first session after install, app calls
AdServices.attributionToken→ posts to Apple’s endpoint - Returns: JSON with campaign ID, ad group ID, keyword ID, org ID, storefront, click timestamp, conversion timestamp
- Latency: Minutes
- Determinism: Yes (Apple confirms the ASA tap → install link in its own ecosystem)
- User identifier: None (no IDFA required)
- Scope: ASA installs only
SKAdNetwork (SKAN)
Apple’s privacy-preserving cross-network attribution framework:
- How: Ad networks register signed payloads with each impression; iOS associates installs with those payloads; Apple sends randomized-delay postbacks to ad networks
- Latency: 0-2 days (window 1), 3-7 days (window 2), 8-35 days (window 3) in SKAN 4.0
- Determinism: Aggregated (campaign-level) with crowd anonymity tier suppression
- User identifier: None
- Scope: Cross-network — ASA + Meta + Google + TikTok + others
Why ASA has two paths
ASA installs technically have both paths active simultaneously:
- Apple’s own ecosystem can deterministically know the ASA-tap-to-install link because Apple operates both the ad and the App Store. This drives the Ad Services API.
- The SKAdNetwork framework treats Apple Search Ads as one of many ad networks. SKAN postbacks fire for ASA installs in addition to non-Apple networks.
In practice, most operators use:
- Ad Services API for ASA-specific dashboards and optimization
- SKAN through MMP for cross-channel attribution and fraud detection
The two paths produce slightly different numbers for the same campaign because:
- Ad Services API includes some installs SKAN suppresses (Tier 0 low-volume)
- SKAN includes some installs Ad Services misses (if the token request failed on first session)
- Time windows differ (Ad Services is near-real-time; SKAN is bucketed)
A 5-15% gap between the two on the same campaign is normal. Larger gaps suggest implementation issues.
SKAN 4.0 — what changed in 2022 and what’s mature in 2026
SKAN 4.0 (iOS 16.1+, widely adopted by 2026) introduced four major improvements:
1. Three postback windows
| Window | Timing | What it measures |
|---|---|---|
| Window 1 | 0-2 days post-install | Initial activation events |
| Window 2 | 3-7 days post-install | Early retention and first purchase |
| Window 3 | 8-35 days post-install | Long-term retention and Day 30 LTV |
This is the most strategically important change. Pre-SKAN-4.0, you only knew Day 0 behavior; now you can measure Day 35 LTV under privacy.
2. Hierarchical conversion values
- Fine conversion value: 6 bits (64 possible values) — encodes specific events
- Coarse conversion value: 3 levels (high / medium / low) — fallback when fine isn’t available
- Coarse is reported even at lower crowd anonymity tiers; fine requires higher volume
3. Source identifier
4-byte source identifier (10,000+ unique values) replaces the SKAN 3.0 100-campaign-ID cap. Larger ad networks like ASA benefit by being able to attribute more granularly.
4. Crowd anonymity tiers
To prevent reverse-identification:
| Tier | Volume threshold | What’s reported |
|---|---|---|
| Tier 0 | <5 conversions | Source app name only, no campaign detail |
| Tier 1 | 5+ conversions | + Coarse conversion value |
| Tier 2 | 25+ conversions | + Fine conversion value |
| Tier 3 | 100+ conversions | + Source identifier |
Small ASA campaigns (low-volume keywords or new launches) typically sit at Tier 0 or 1 — limited SKAN data. The Ad Services API is unaffected by these tiers.
Conversion value mapping (SKAN)
You decide what events map to what conversion values. The mapping is app-side configuration — the OS doesn’t dictate it.
Fine value mapping example (64 values)
Value 0: No conversion event
Value 1: Onboarding completed
Value 5: First content interaction
Value 10: First purchase ($0.99-$4.99)
Value 15: First purchase ($5-$9.99)
Value 20: First purchase ($10-$19.99)
Value 25: First purchase ($20+)
Value 30: Subscription started (trial)
Value 35: Subscription converted (paid)
...Coarse value mapping
Map fine values to high / medium / low:
- High: paid subscription, large purchase, strong retention signal
- Medium: trial started, moderate purchase
- Low: install only, no monetization event
Operator considerations
- Lock the mapping early. Changing conversion value definitions mid-campaign causes measurement discontinuity.
- Cover Day 35 events in mapping. Don’t reserve all 64 values for Day 0; allocate proportionally across windows.
- Test your mapping before relying on it. Many MMPs have testing tools for SKAN conversion value validation.
Practical implications for ASA operators
For ASA-only optimization
Use the Ad Services API. It is more granular and faster than SKAN. Configure your
app to call AdServices.attributionToken on first session and post to Apple’s
endpoint. Join the returned attribution to your backend’s event data.
Optimize ASA campaigns (bidding, negatives, structure) based on Ad Services attribution.
For cross-channel attribution
Set up SKAN through an MMP (AppsFlyer, Adjust, Kochava, Branch). The MMP aggregates SKAN postbacks across all ad networks including ASA and produces cross-channel attribution reports.
Use this for channel mix decisions (how much budget on ASA vs Meta vs Google) — not for ASA-internal optimization.
For LTV-based bidding
The 3-window SKAN postbacks enable true Day 35 LTV measurement under privacy. Map your LTV-relevant events into the SKAN value structure and use postback data to inform campaign-level decisions.
For small accounts
Accounts spending under ~$5K/day per SKAN source will see Tier 0 or 1 limitations in SKAN data. The Ad Services API is unaffected by these tiers — small ASA accounts still get full per-keyword attribution via the first-party path.
Common implementation mistakes
1. Relying only on SKAN for ASA
If you only set up SKAN-based attribution and skip the Ad Services API, you lose granular ASA optimization data. SKAN’s randomized delays and tier suppression are not suited for daily optimization.
2. Conversion value mapping locked too early
Locking the mapping before your app has monetization data leads to coarse mappings that don’t differentiate high-LTV users from low. Pilot for 30 days, then lock based on observed data.
3. Ignoring window 2 and window 3
Many operators only optimize against window 1 (Day 0) — undercounting LTV from subscription apps where conversion happens days 3-7.
4. Comparing Ad Services and SKAN data 1:1
The two paths have different scope and methodology; a 5-15% gap is expected. Treat them as complementary, not redundant.
5. Forgetting the token request
If your app crashes or the user uninstalls before the Ad Services token is requested and sent, the attribution is lost. Implement the request very early in app initialization.
How ASAPilot uses both paths
ASAPilot reads ASA attribution via the Ad Services API for campaign-level optimization data. For cross-channel reporting, ASAPilot integrates with MMPs via webhook so your MMP’s SKAN-aggregated data can enrich ASAPilot’s audit findings with multi-channel context.
You don’t need an MMP to use ASAPilot for ASA-only operations. See pricing for plan tiers.