How AdAttributionKit measures Apple Ads installs

What AdAttributionKit replaces and keeps#

AdAttributionKit is the forward path for Apple Ads measurement on iOS 17.4 and later, built to succeed SKAdNetwork while keeping its privacy guarantees: no device identifiers, aggregated reporting and signed postbacks. Apple still publishes no deprecation date for SKAdNetwork, so teams run both frameworks side by side during the transition.

What changes most is re-download support: AdAttributionKit can credit reinstalls by returning users, which SKAdNetwork never handled cleanly. The AdAttributionKit documentation sets out the supported marketplaces and OS versions. Start from the Apple Ads hub if the rename from search centred buying still confuses the team.

What stays is the philosophy: delayed postbacks, privacy thresholds and coarse values instead of row level device data. Read our SKAdNetwork legacy guide for the system being replaced, and our partner integration guide for how measurement partners consume both frameworks.

Re-download measurement, finally#

Re-download attribution is the headline reason to adopt AdAttributionKit: lapsed users who reinstall after a winback tap can now be credited to the campaign that brought them back. Under SKAdNetwork those events were largely invisible, which punished re-engagement budgets in reporting even when the product work was sound.

Eligibility depends on OS version and storefront, so model the upside per market rather than assuming global coverage on day one. Teams with large dormant bases across the 91 supported markets feel the difference first. Pair the rollout with our re-engagement guide to separate returning users from new installs in reporting.

Keep expectations honest: re-download counts arrive through the same delayed postback machinery, so intraday reads stay jumpy. Judge winback tests weekly, as our postback windows guide explains.

How the signed postback flow works#

Every credit arrives as a signed postback carrying a coarse conversion value and source identifiers, never a device ID. The device holds the attribution, waits out the privacy delay, then delivers the payload to the registered endpoint where your partner platform or server picks it up.

Signatures use JWS so receivers can verify that payloads genuinely came from the device and were not forged in transit. Server teams should validate signatures before trusting any value, a step the postback verification reference documents in full. Developers new to the flow should read our conversion values guide first.

Map the flow end to end in staging: tap, install, value update, delayed delivery, partner ingest. Most integration pain comes from untested endpoints, not from the framework itself.

What changes in app code#

Engineers adopt the AdAttributionKit APIs, register attribution endpoints and update conversion value logic for the new value ranges. The work is measured in days for a clean codebase and weeks where attribution calls are scattered across legacy modules.

Keep SKAdNetwork calls in place while you migrate: dual running is the supported posture until Apple announces otherwise, and ripping out the legacy path early only blinds reporting on older OS versions. The SKAdNetwork reference remains the authority for the old path. Coordinate the app release with campaign changes using our first campaign setup.

Test on device across OS versions, including the 17.4 boundary, and confirm postbacks land in the partner sandbox before release. The checklists in our AppsFlyer setup guide and our Adjust setup guide cover partner side verification.

Partner setup for AdAttributionKit#

Your measurement partner must enable AdAttributionKit reading alongside SKAdNetwork before any credit flows into its dashboard. That usually means toggling the framework in the partner dashboard, shipping the partner SDK update that supports it and mapping the new value schema to your events.

Confirm the partner version supports dual framework ingest, then run a closed test cohort and reconcile device side postbacks against dashboard rows. Our partner integration guide compares the options, while our reconciliation guide shows how to match partner rows to Apple Ads reports.

Do not judge performance during the test window: small cohorts trip privacy thresholds and inflate null shares, as our null rates guide explains. Talk to folkfox if dual reporting looks inconsistent.

Reading framework data beside console data#

AdAttributionKit credit and Apple Ads console credit answer different questions, so read them as complements rather than rivals. The console attributes taps and views inside its own windows; device postbacks reflect framework rules, delays and thresholds.

Expect timing gaps of days between a spend change and its postback reflection, and never optimise intraday on framework data. Placement reporting helps split console reads by inventory, and our Attribution API guide covers the token based middle path for owned apps.

Build one weekly view that shows console installs, framework installs and partner installs side by side with null shares annotated. That single table ends most attribution arguments.

Frequently asked questions#