# Mobile app attribution: the limits that change the model choice

This is a pointer, not a mobile guide. Hand mobile work to the mobile-attribution-fundamentals, skan-conversion-value-design and mmp-selection skills. If they are not installed, use this file to set the limits in the brief, read the MMP's and Apple's live docs for anything beyond them, and say in the brief that conversion value design and MMP choice were not reviewed. What matters for choosing an attribution view:

## iOS: SKAdNetwork and AdAttributionKit

Checked against Apple's ad attribution page (2026-10-17 and 2026-10-18) and the AdAttributionKit pages on multiple conversion windows and on configuring attribution rules (2026-10-20). For tiers, update calls, postback verification and counting rules, use mobile-attribution-fundamentals.

- AdAttributionKit builds on SKAdNetwork and interoperates with it. It attributes installs without tracking individual users across other companies' apps, by limiting what the postback contains.
- AdAttributionKit attribution needs iOS or iPadOS 17.4 or later; Apple's page applies that requirement to both click and view attribution.
- Default windows: an install within 30 days of tapping an ad that leads to the product page, or within 1 day of viewing an ad. These are defaults, not fixed. The advertised app can set click windows of 1 to 30 days and view windows of 1 to 7 days in its Info.plist (`AdAttributionKitConfigurations` > `AttributionWindows`), globally or per ad network, and an `AttributionCooldown` of 0 to 720 hours after install or re-engagement conversions. Ad network settings override global ones, which override the system default. Read the app's configuration and record it in the inventory's `mobile` block before comparing iOS attribution with an MMP or a network.
- Attribution goes to the most recent tapped ad, or the most recent displayed ad if none was tapped.
- Crowd anonymity: Apple decides per download which data tier the postback gets. The publisher item ID and conversion values appear only when thresholds are met and can be null.
- Three conversion windows, counted from first launch: days 0 to 2, 3 to 7 and 8 to 35. Each postback is prepared when its window ends, or earlier if the app locks the value, then sent after a random delay of 24 to 48 hours for the first postback and 24 to 144 hours for the second and third. Unlocked, the first postback arrives 3 to 4 days after first launch and the third up to about 41 days after.
- Fine conversion values appear only in the first postback, at Tiers 2 and 3. Tier 1 first postbacks and all second and third postbacks carry coarse values (low, medium, high). Tier 0 gets the first postback only, and non-winning attributions get one postback.
- Re-engagement attribution (iOS 18 and later, click-through) can send up to three postbacks.

Consequences for model choice:

- There is no user-level path for most attributed iOS installs, so user-level multi-touch attribution across channels is not available for them. A "linear" or "data-driven" cross-channel app view built from device IDs covers only the consented minority and is biased toward it.
- SKAdNetwork and AdAttributionKit are last-touch by design (most recent tap, else most recent view). They do not share credit.
- Postback timing: first-postback data for installs in the last 4 days is incomplete, and second and third postback data (later revenue, retention) stays incomplete for up to about six weeks. Treat iOS value-based reads as provisional until 41 days after the last first launch in the period. Small campaigns get null values; report thresholded volume separately rather than spreading it.
- Decisions about app budget across networks lean on aggregate evidence: postback reporting by campaign, MMP aggregates, incrementality tests and MMM.

## Android

- Google Play installs can be attributed at click level: the Play Install Referrer API returns the referrer URL of the installed package and the time of the referrer click and of the install start. MMPs and networks use it, subject to the app's consent handling and the MMP's own rules.
- So the iOS postback limits above do not apply to Play installs. A cross-channel app view can be closer to user level on Android than on iOS; report the two platforms separately rather than blending them.
- Android privacy changes are in progress; check the current state on Android's developer docs at run time. Hand Android detail to mobile-attribution-fundamentals.

## MMPs

- An MMP (AppsFlyer, Adjust, Branch, Airbridge and others) applies its own attribution rules and windows across networks and deduplicates installs that several networks claim. Its numbers are another platform view, not a ledger. Read its configured windows and rules before comparing them with a network or GA4 for Firebase.
- MMP vendors ship MCP servers that read aggregated reporting; their capabilities and access requirements vary and change quickly. Confirm the tool list at run time before relying on one.
- Web-to-app journeys (an ad click on the web leading to an app install) need explicit design; most web attribution views lose the user at the store.

## What to write in the brief for an app decision

- Which iOS share of outcomes is visible only through postbacks.
- The app's AdAttributionKit attribution windows and cooldowns, global and per ad network, or "system defaults" if none are set.
- The date iOS postback values mature: 41 days after the last first launch in the period.
- The MMP's windows and rules, read on the date of the brief.
- Whether the question is operational (campaign tuning inside a network), descriptive (aggregate postback trends) or causal (budget), and the evidence each needs.