SKAdNetwork and AdAttributionKit are Apple's privacy-preserving attribution frameworks for app advertising. They let eligible ad interactions be associated with app installs—and, with AdAttributionKit, reengagement—without putting user- or device-specific tracking data in the signed postback.
For marketers, the important consequence is not that iOS measurement disappears. It changes shape. Data arrives after defined conversion windows and random delays, campaign detail can be reduced to protect crowd anonymity, and post-install behavior has to be expressed through limited conversion values. These signals support attribution and optimization, but they do not identify a person and they do not prove incrementality.
SKAdNetwork and AdAttributionKit: the short answer
- SKAdNetwork (SKAN) is Apple's earlier framework for privacy-preserving install attribution on the App Store. Apple now directs new app advertising work toward AdAttributionKit while documenting interoperability between both systems.
- AdAttributionKit (AAK) builds on the model, supports the App Store and alternative app marketplaces, and includes app reengagement measurement.
- A winning install attribution can produce up to three postbacks across conversion windows of days 0–2, 3–7 and 8–35 after first launch. Eligibility and content depend on the framework and data tier.
- The first postback can contain a fine conversion value from 0 to 63 or a coarse value of low, medium or high. Later postbacks use coarse values when the required data tier is met.
- Low volume does not simply mean "no attribution." Apple can reduce campaign and conversion detail; at the lowest data tier, the first postback may still contain limited source information while later postbacks are not sent.
- The first postback is delayed. After a conversion window is finalized or locked, Apple's documented random delay is 24–48 hours; second and third postbacks can be delayed 24–144 hours.
- Ad network dashboards may combine Apple postbacks with modeled data and their own definitions. Reconcile the layers instead of expecting identical totals.
- Use attribution for allocation and optimization, then use experiments to answer the causal question: did the advertising create incremental outcomes?
What SKAdNetwork measures
SKAdNetwork validates advertisement-driven app installations. Registered ad networks sign eligible ads, source apps or supported web placements present them, and the advertised app updates a conversion value after launch. Apple selects the attributed impression and sends cryptographically signed postbacks.
SKAN 4 can produce up to three winning postbacks when the participants and implementation support it. It also uses hierarchical source identifiers, which let an ad network encode dimensions such as campaign or placement within a four-digit value. Apple may return only part of that identifier depending on the postback data tier.
The framework does not send a user ID, device ID or an event stream. It sends a constrained report about an attributed conversion. That report can contain fields such as the ad network, advertised app, source identifier, conversion value, whether the attribution won and the postback sequence index. Some fields are conditional.
SKAN can be used regardless of App Tracking Transparency authorization because the postback does not carry user- or device-specific data. That does not exempt other tracking in the app. If the app or SDK tracks people across apps or websites owned by other companies, Apple's ATT rules still apply to that tracking.
What AdAttributionKit changes
AdAttributionKit is Apple's newer framework for app ad attribution. It supports advertising across the App Store and alternative app marketplaces and extends measurement to reengagement—when someone who already has the app interacts with an ad and returns to it.
For install attribution, its operating model remains familiar: signed ads, winning and eligible nonwinning postbacks, conversion values, three conversion windows, data tiers and delayed delivery. For reengagement, there are important differences:
- reengagement requires a click interaction; view-through impressions do not create reengagement postbacks;
- the app must already be installed;
- a registered universal link can reopen the app;
- conversion tags can help the app update the correct postback when reengagement conversion windows overlap;
- one ad network may receive winning reengagement postbacks for multiple conversion windows.
AdAttributionKit and SKAdNetwork can coexist. Apple's interoperability documentation explains that impressions from both systems can enter the same attribution decision and only one impression wins for a conversion. Click-through takes precedence over view-through, and recency is used within those groups. If a measurement stack supports both frameworks, the advertised app may need to update values through both APIs according to the integration.
Do not label AdAttributionKit as an instantaneous replacement switch. Support depends on the app, operating system, ad network, publisher inventory and measurement provider. The migration plan should document which traffic uses which framework and how reporting deduplicates it.
How Apple selects an attributed impression
Attribution answers which eligible ad interaction receives credit under Apple's rules. It is not a causal experiment.
When AdAttributionKit and SKAdNetwork impressions coexist, Apple currently gives click-through impressions priority over view-through impressions and uses the most recent eligible impression within each group. The system considers a limited number of impressions. Attribution and incrementality can therefore disagree: an ad can receive credit for a conversion that would have happened anyway, while an influential earlier exposure may receive no credit.
Use precise language in reporting:
- attributed install means the framework assigned credit under its rules;
- observed postback means a signed report was received;
- modeled conversion means a platform estimated an outcome using its methodology;
- incremental conversion means an experiment estimates the outcome would not have occurred without the advertising.
These are useful but different measurements. Calling every attributed install "caused by ads" overstates what the framework establishes.
Conversion windows and reporting delays
For install attribution, Apple documents three conversion windows beginning when the person first launches the app:
| Window | Period | Potential signal | Delivery after close or lock |
|---|---|---|---|
| First | Days 0–2 | Fine value where the data tier permits it, otherwise coarse or more limited detail | Random 24–48-hour delay |
| Second | Days 3–7 | Coarse value where the data tier permits it | Random 24–144-hour delay |
| Third | Days 8–35 | Coarse value where the data tier permits it | Random 24–144-hour delay |
The app can update the conversion value during a window. It can also lock a value to finalize that window early, after which later updates in the same window are ignored. Locking trades future observation time for earlier postback preparation; it does not remove the random delivery delay.
This makes same-day completeness impossible. A Monday acquisition cohort may continue producing framework signals weeks later. Evaluation schedules should distinguish:
- operational checks that confirm spend and delivery;
- early indicators used by bidding systems;
- first-window performance after expected postback maturity;
- longer-term value after the second and third windows;
- finance outcomes from server-side subscription or purchase systems.
Never compare an immature recent cohort with a fully matured historical cohort without adjustment.
Fine and coarse conversion values
A conversion value is not a purchase record. It is a code the app updates to represent relative post-install value.
The fine conversion value is a 6-bit integer, giving 64 possible values from 0 to 63. A coarse conversion value has three levels: low, medium and high. Apple may include a fine value in the first postback when crowd-anonymity conditions permit; at lower tiers it may provide a coarse value or omit that detail. The second and third postbacks use coarse values where eligible.
The app business defines what the values mean. Common schemas include:
- event progression: launch, onboarding, registration, trial, purchase;
- revenue ranges: no revenue, low, medium and high early value;
- engagement: sessions, completed lessons, game level or activated feature;
- predictive value: early behavior associated with later retention or subscription;
- hybrid mapping: event milestone plus revenue or engagement band.
The best schema is not the one that fills all 64 values. It is the one that remains interpretable, occurs often enough to produce useful signal and aligns with the business outcome.
How to design a conversion-value schema
Start with the decision the signal needs to support. A gaming app optimizing early payer quality needs a different map from a subscription app with a seven-day trial.
- Define the commercial outcome. Use retained subscriber value, contribution, qualified lead or another metric—not installs by default.
- Map the event timing. Identify what can realistically happen in days 0–2, 3–7 and 8–35.
- Assess event volume. A theoretically perfect event that occurs rarely may provide little usable detail under privacy tiers.
- Choose monotonic value. Higher values should normally represent equal or greater expected business value, so the network and analysts can interpret them consistently.
- Design coarse values first. Low, medium and high should remain useful because fine values are not always returned.
- Handle revenue carefully. Use net or contribution-relevant bands where possible, account for refunds and avoid ranges dominated by a few outliers.
- Document every mapping. Store the version, effective date, event logic, currency treatment, lock behavior and owners.
- Plan change control. Version the schema when business logic changes and avoid comparing cohorts across versions as if definitions were identical.
For subscriptions, an early trial start may be common but only weakly predictive of paid retention. Combine it with onboarding completion, payment method, engagement or later coarse signals when evidence shows those improve prediction. Do not encode sensitive characteristics or invent value relationships that have not been validated.
Crowd anonymity and data tiers
Apple uses a postback data tier to determine how much detail can be returned while protecting crowd anonymity. The tier can depend on the combination of the publisher app or source domain, advertised app, country and hierarchical source identifier.
Higher tiers can return more digits of the source identifier and more conversion detail. Lower tiers reduce fields. In SKAN 4 and AdAttributionKit install measurement:
- Tier 3 can provide the most source detail and fine first-window value, plus selected conditional fields;
- Tier 2 can still provide fine first-window value with less contextual detail;
- Tier 1 returns a shorter source identifier and a coarse first-window value if provided;
- Tier 0 provides very limited first-postback detail and no second or third postback.
Apple does not publish a simple universal install threshold that marketers can use as a guarantee. Avoid claims such as "you need exactly X installs" or "small campaigns report nothing." The practical implication is that fragmentation across too many low-volume source identifiers can reduce detail, but consolidation should still respect different countries, economics, creative hypotheses and campaign objectives.
What you can measure
With correct support and implementation, the frameworks can provide:
- attributed downloads and redownloads for eligible ads;
- attributed reengagement through AdAttributionKit-supported flows;
- winning and selected nonwinning postbacks;
- limited campaign or source information through hierarchical identifiers;
- click-through versus view-through context where supported by the postback;
- early post-install quality through fine or coarse conversion values;
- later coarse value signals across additional windows;
- cryptographically signed postbacks that can be verified;
- aggregate trends by framework, source and matured acquisition cohort.
An advertiser or developer can opt to receive a copy of winning postbacks at a configured server endpoint. This can improve transparency and reconciliation, although the advertising network and MMP remain important for decoding, normalization and campaign operations.
What you cannot measure from these postbacks alone
The frameworks do not provide:
- a user-level journey from impression to install to purchase;
- an advertising identifier or device identifier in the signed postback;
- unrestricted event names, timestamps and exact revenue for each individual;
- complete creative, placement, country and publisher detail at every volume level;
- immediate final reporting;
- conventional user-level multi-touch paths across networks;
- deterministic lifetime value by campaign for every acquired person;
- proof that the attributed conversions were incremental;
- perfect reconciliation with platform, MMP, analytics, subscription and finance systems.
Some ad platforms model outcomes beyond observed postbacks. That may improve bidding and reporting, but it does not change what Apple delivered. Reports should label observed, decoded, modeled and first-party business data clearly.
SKAdNetwork, ATT and an MMP are different layers
These concepts are often mixed together:
| Layer | Role | What it does not do |
|---|---|---|
| ATT | Governs permission for app tracking under Apple's rules | It is not an attribution report |
| SKAN / AdAttributionKit | Produces privacy-preserving signed attribution postbacks | It does not provide user-level cross-company tracking or causality |
| Ad network | Serves ads, receives postbacks, bids and may model additional conversions | Its dashboard is not a neutral finance ledger |
| MMP | Implements and normalizes measurement across partners, decodes values and supports reporting | It cannot bypass Apple's privacy controls |
| Product/finance data | Measures app behavior, subscriptions, refunds and recognized revenue | It often lacks deterministic campaign linkage for non-consenting iOS users |
| Experiments | Estimate incremental impact through a counterfactual | They do not provide person-level campaign paths |
Choose an MMP based on framework support, transparent definitions, postback access, schema management, data export, privacy controls and reconciliation—not a promise to recover data Apple intentionally withholds. See how to choose a mobile measurement partner.
A reporting model that works
Use several views because no single dashboard answers every question.
Delivery view: spend, impressions, clicks, platform-reported installs and creative delivery. Use it for pacing and obvious operational failures.
Apple attribution view: received postbacks by framework version, conversion type, source identifier, data tier, postback index and fine/coarse value. Track null or limited fields rather than silently excluding them.
Matured cohort view: acquisition-date cohorts with a fixed maturity point. Compare day-3, day-8 and day-36 views only when the applicable postbacks have had time to arrive.
Business outcome view: App Store receipts, subscriptions, renewals, refunds, first-party events and contribution. This is the financial truth layer even when campaign attribution is partial.
Incrementality view: holdout, geo or other controlled tests for the question attribution cannot answer. Our incrementality testing guide explains the method.
Connect the views with ranges and reconciliation notes, not fabricated precision. A management report should state which figures are observed, which are modeled, the maturity date and the active conversion-schema version.
Campaign optimization under privacy constraints
Campaign consolidation can increase the probability of richer detail and give bidding systems more events, but "fewer campaigns" is not a universal rule. Consolidate where separate structures do not represent a genuine budget, market, objective or testing decision.
Set campaign guardrails before launch:
- minimum spend and time before performance decisions;
- expected first-, second- and third-window maturity dates;
- which early conversion values predict the commercial outcome;
- how modeled platform reporting will be compared with Apple postbacks;
- when a creative or campaign can be stopped for delivery or risk reasons;
- when an incrementality test is required before scaling.
Creative testing also needs adequate allocation. If many source-identifier dimensions each receive little activity, the account may retain superficial granularity while losing usable conversion detail. Test fewer meaningful hypotheses, record creative IDs consistently and avoid changing campaign structure faster than delayed data can mature.
Implementation and QA checklist
- Inventory support. Record minimum OS, framework version, ad networks, MMP SDK and postback endpoints.
- Define responsibilities. Assign the app, backend, MMP, media and analytics owners.
- Design the conversion schema. Include fine and coarse mappings for all three windows and reengagement where relevant.
- Implement both required update paths. Follow Apple's interoperability guidance if campaigns use SKAN and AdAttributionKit.
- Configure postback copies. Secure the endpoint, verify signatures and store raw postbacks for audit where appropriate.
- Test compressed timelines. Use Apple's testing tools or Developer Mode rather than waiting for production delays.
- Validate edge cases. Test install, redownload, reengagement, no qualifying event, lock behavior and schema transitions.
- Reconcile IDs. Document how source identifiers map to network, campaign, ad set, creative or placement dimensions.
- Separate observed and modeled data. Make this visible in dashboards and exports.
- Monitor after every release. Alert on postback volume, null fields, schema distribution, endpoint failures and unexplained framework shifts.
Privacy and security review should cover SDK data collection, consent behavior, data retention, server access and vendor contracts. A working postback pipeline does not by itself establish legal or platform-policy compliance.
Common mistakes
| Mistake | Better approach |
|---|---|
| Saying low-volume campaigns receive no attribution | Explain that data tier can reduce fields and later postbacks; inspect actual postbacks |
| Calling attributed installs incremental installs | Use experiments to estimate causality |
| Encoding only rare purchase events | Design useful coarse and early signals based on real volume and predictive value |
| Comparing recent and mature cohorts | Use fixed maturity windows and allow for random delivery delays |
| Treating an ad network total as raw Apple data | Separate observed postbacks, decoding and modeling |
| Changing the value map without versioning | Document definitions and analyze schema versions separately |
| Assuming an MMP can restore user-level data | Evaluate implementation quality, transparency and export access |
| Consolidating every market and objective | Balance signal density with genuine commercial differences |
| Using SKAN and AdAttributionKit terms interchangeably | Record framework, version, conversion type and interoperability behavior |
| Combining iOS and Android as if measurement were identical | Use platform-specific methodology and explain differences |
FAQ
What is SKAdNetwork? SKAdNetwork is Apple's privacy-preserving framework for attributing eligible ads to App Store installs. It sends signed, delayed postbacks without user- or device-specific data and can include limited campaign and conversion-value information.
What is AdAttributionKit? AdAttributionKit is Apple's newer ad attribution framework for apps on the App Store and alternative marketplaces. It builds on SKAN concepts and supports install, redownload and reengagement measurement.
Is AdAttributionKit replacing SKAdNetwork? Apple now recommends AdAttributionKit for app ad campaigns, but the frameworks are interoperable and can coexist during adoption. Implementation depends on participating apps, ad networks, inventory and OS support.
Does SKAdNetwork require ATT consent? SKAN and AdAttributionKit postbacks can operate without ATT authorization because they do not include user- or device-specific data. Any separate tracking activity in the app may still require permission under Apple's rules.
How many SKAN postbacks can an install produce? SKAN 4 and AdAttributionKit install attribution can produce up to three winning postbacks across days 0–2, 3–7 and 8–35. Older SKAN versions, Tier 0 data and nonwinning attribution have fewer postbacks.
Why is the conversion value missing? The app may not have updated it, the integration may have failed or Apple's postback data tier may not permit that detail. Inspect raw postbacks, implementation logs, framework/version and the active value schema before assuming the campaign had no valuable users.
Can SKAN report exact revenue? The postback carries a defined conversion value rather than an unrestricted transaction record. Advertisers often map revenue ranges into fine and coarse values, then use first-party subscription or purchase data for actual aggregate revenue.
Does AdAttributionKit measure reengagement? Yes, for supported click-through flows. Reengagement is not attributed from view-through ads, and the app, universal link, network and framework implementation must support the flow.
How long should you wait before evaluating an iOS campaign? There is no single number for every decision. The first postback can arrive after the first conversion window and a random delay, while later value can take more than 35 days plus delivery time. Define early and mature evaluation points based on the active framework, schema and business model.
Is Android attribution the same? No. Google Play Install Referrer and Android privacy or attribution systems have different data flows and policies. Report iOS and Android with platform-specific definitions rather than assuming one is universally more complete.
Sources and further reading
- Apple Developer — measuring ad performance with AdAttributionKit
- Apple Developer — AdAttributionKit documentation
- Apple Developer — SKAdNetwork documentation
- Apple Developer — framework interoperability
- Apple Developer — receiving postbacks in multiple conversion windows
- Apple Developer — receiving ad attributions and postbacks
- Android Developers — Google Play Install Referrer
Key takeaways
- SKAN and AdAttributionKit provide privacy-preserving attribution signals, not user-level journeys or proof of incrementality.
- AdAttributionKit extends the model to alternative marketplaces and reengagement while interoperating with SKAN.
- Conversion values, data tiers and delayed windows determine how much useful post-install information is available.
- Low volume can reduce detail; it does not support a universal claim that a campaign will return nothing.
- Design fine and coarse schemas from business value, event timing and real volume, then version every change.
- Reconcile Apple postbacks, network modeling, MMP outputs and first-party revenue as distinct layers.
- Use fixed-maturity cohorts for optimization and controlled experiments for causal decisions.
How we connect app acquisition with reliable measurement is explained on our web analytics page and in mobile game and app user acquisition.
Continue reading
adclick.g.doubleclick.net: What It Is and When to Worry
adclick.g.doubleclick.net is part of Google's advertising click infrastructure, not software installed on a device. Learn why it appears in browser history, network logs or GA4, which findings are harmless, and how to diagnose genuine attribution loss without hiding the symptom.
LinkedIn Insight Tag: What It Enables and How to Implement It
The LinkedIn Insight Tag supports website conversion tracking, retargeting, Website Actions and audience insights. Implement it only on approved pages, with consent, conversion and QA rules defined first.
How to Choose a Mobile Measurement Partner (MMP)
Choose an MMP by defining the decisions it must support, then verify platform integrations, privacy-framework coverage, event governance, raw-data access, security, deep linking, cost and migration risk.
