AdAttributionKit is not simply a renamed replacement for SKAdNetwork. Both frameworks provide privacy-preserving attribution and can interoperate, but SKAdNetwork 4 centers on multi-window install postbacks while AdAttributionKit adds new presentation methods, signed formats, attribution rules, and click-based re-engagement. Teams should plan around required capabilities, operating-system coverage, and partner support instead of treating the frameworks as a forced either-or choice.
What is the core mechanism of SKAdNetwork 4?
Apple made SKAdNetwork 4 available with iOS 16.1. An advertised app can update conversion values during three conversion windows, allowing the system to produce up to three postbacks. The windows provide limited signals from different periods after installation without depending on a freely joinable person-level identifier.
The advertised app developer may opt in to receive a copy of the winning postback when Apple’s requirements are met. That copy can support advertiser-side validation, but it remains a privacy-preserving postback. It should not be interpreted as a complete user event stream.
What does AdAttributionKit add?
AdAttributionKit postbacks combine a signed compact JWS with several unsigned fields. Apple defines conversion types for download, redownload, and re-engagement. The framework supports custom click ads, view-through presentations, SKOverlay, and SKStoreProductViewController. It also lets an advertised app customize attribution rules and use conversion tags to distinguish overlapping windows.
Re-engagement is a major extension. An eligible impression can use a universal link to open an already installed app at a relevant destination. Apple supports click-based re-engagement but not view-through re-engagement. As of iOS 18.4, an app can have multiple active re-engagement conversion windows, which makes conversion tags and event mapping more important.
How do the frameworks interact when both are present?
Apple describes AdAttributionKit as fully interoperable with SKAdNetwork. Only one impression can win a conversion, whether the qualifying impression comes from AdAttributionKit or SKAdNetwork. The frameworks therefore participate in one attribution decision rather than creating two independent wins for teams to add together.
This rule should shape reporting design. Store the framework and postback type, but do not treat framework labels as separate conversions unless the underlying conversion identifiers and rules prove that they are different events. Interoperability prevents the technology choice from becoming a license to double count.
How should a team prioritize implementation?
If the immediate requirement is established install measurement, begin with SKAdNetwork version coverage, conversion-value mapping, postback endpoints, and partner readiness. If the requirement includes re-engagement, universal links, custom presentation, or configurable attribution rules, add an AdAttributionKit workstream.
Review the ad network, publisher app, advertised app, server, analytics pipeline, and MMP together. A framework feature is operational only when every required participant supports the same flow. The implementation matrix should record operating-system requirements, supported interactions, conversion types, window handling, postback recipients, signature validation, developer testing, and fallback behavior.
What does a migration review usually miss?
Teams often check an SDK and stop before validating the server. A complete review follows the signal from signed ad data through presentation, click or view registration, conversion updates, postback delivery, signature verification, and reporting. Re-engagement also requires the universal link and destination experience to work as intended.
Another common mistake is reading postback count as user count. The correct unit depends on conversion type, conversion window, framework rules, and whether overlapping re-engagements exist. Use a test plan that names the expected postbacks for each scenario and compares them with received, validated, rejected, and delayed records before production reporting begins.
The plan should cover download, redownload, and re-engagement scenarios. For each one, record the expected interaction type, conversion-update timing, expected number of postbacks, recipients, and reporting destination. Apple provides developer tooling that shortens windows and reduces the waiting created by randomized timing. Development postbacks must remain clearly separated from production data.
After launch, monitor received records, signature failures, duplicates, delayed arrivals, and unmapped conversions. Define how each exception is counted before stakeholders use the dashboard. This makes it possible to distinguish real campaign movement from implementation failure. The meaningful framework comparison is therefore not a feature checklist alone. It is the end-to-end data quality that the team can observe and maintain.
Assign an owner to each handoff and keep a versioned schema so that operating-system or partner changes trigger a controlled revalidation.
