# Mobile App Attribution: SKAdNetwork and AdAttributionKit Explained

Canonical URL: https://www.martechdevs.com/blog/mobile-app-attribution

By [Jafrin Akter Alo](https://www.martechdevs.com/authors/jafrin-akter-alo)

Data Engineer and Co-founder, martechdevs

Published: 2026-04-27

Last updated: 2026-09-14

Mobile app attribution connects advertising activity with app installs and later outcomes under a defined set of rules. On iOS, SKAdNetwork and AdAttributionKit provide privacy-preserving signals with deliberate limits. A useful setup turns those signals into budget decisions while keeping missing detail, delayed reporting and first-party customer behavior distinguishable.

## Begin with the decision, then choose the measurement

An app growth lead may need to decide which campaign deserves more budget. A product manager may need to understand why new customers fail to activate. A founder may need to know whether acquisition spending produces enough retained revenue.

Those questions overlap, but one attribution chart cannot answer all three. You need advertising cost and campaign signals, trustworthy product events, and commercial outcomes such as paid subscriptions and refunds. Each source contributes a different piece of evidence.

Define the outcome before configuring conversion values. “Install” might be an early acquisition signal. “Completed the first useful task” may be a better activation outcome. “Paid and remained active through the first renewal” is a later business result that an early postback cannot directly represent.

A small team should choose one budget decision and one product outcome to implement first. That makes the initial system testable. Collecting every event without defining the decision produces a large tracking project and little clarity.

## What SKAdNetwork and AdAttributionKit do

[SKAdNetwork](https://developer.apple.com/documentation/storekit/skadnetwork) is Apple's framework for validating advertisement-driven installations and reporting eligible post-install signals. Its participants include the ad network, the app or site displaying an ad, and the advertised app. Apple's current documentation directs developers toward AdAttributionKit while retaining interoperability guidance.

[AdAttributionKit builds on that approach](https://developer.apple.com/app-store/ad-attribution/). App-install attribution is available from iOS and iPadOS 17.4; re-engagement support starts with later versions. Its signed campaign reports limit the information returned to protect privacy. Treat operating-system and integration support as part of the configuration, not a universal capability of every device.

A **postback** is the report sent after an eligible conversion process. It is not a normal analytics event containing your signed-in customer ID. It may arrive after a delay and with some dimensions or conversion detail unavailable.

Apple's [interoperability documentation](https://developer.apple.com/documentation/adattributionkit/adattributionkit-skadnetwork-interoperability) explains how the two frameworks work together and how conversion updates depend on the integrated frameworks. The system selects one winning impression for a conversion across eligible impressions. Do not implement independent reporting totals and assume they represent additional customers simply because their framework labels differ.

For a product or growth manager, the practical requirement is a maintained integration specification: supported app versions, networks, attribution paths, conversion updates and reporting destinations. Ask the engineering or MMP owner to demonstrate that specification against current documentation.

## Keep three reporting views separate

Use one view for **commercial truth**: valid orders, subscriptions, refunds and recognized business outcomes. Use another for **product behavior**: activation, feature adoption and retention within the identities you are allowed to measure. Use a third for **advertising attribution**: the credit assigned by a particular method.

![Campaign attribution, product behavior and commercial transactions inform a budget decision through separate reporting views.](https://www.martechdevs.com/assets/blog/mobile-app-attribution.svg)

These views can inform the same decision without pretending they have an exact customer-level join. In particular, do not reverse-engineer a private identity from an aggregate postback merely to make the diagram look connected.

An MMP dashboard, an ad network's own report and Apple's attribution view may apply different rules or represent overlapping activity. Decide which view governs each recurring decision. Keep the others as diagnostics with their definitions visible.

Write the denominator into the report name or description. Cost per attributed install, cost per first-party first open and cost per paid subscriber are different metrics. Changing the denominator while keeping the label “CAC” makes performance appear to change even when the business has not.

## ATT is a separate permission boundary

[Apple's tracking policy](https://developer.apple.com/app-store/user-privacy-and-data-use/) requires App Tracking Transparency permission for the cross-company tracking it defines. Replacing an advertising identifier with a hashed email does not bypass that requirement. Apple also prohibits deriving a unique device identity through fingerprinting.

The privacy-preserving attribution frameworks can be used without treating an ATT refusal as permission for other tracking. Review the behavior of the entire SDK integration, including deep linking and partner data sharing. The framework's availability does not approve every other operation performed by the same library.

Document what happens before a choice, after permission, after refusal and after a later change. These are implementation cases, not merely banner copy. Assign ownership for both the app configuration and the data sent to partners.

## Design conversion values around an early decision

A conversion value is a compact representation of meaningful activity. It is useful only when the people reading the report know what it represents.

[Apple's AdAttributionKit introduction](https://developer.apple.com/videos/play/wwdc2024/10060/) describes fine values from 0 to 63 and coarse values of low, medium and high. The app and its measurement partners need an agreed interpretation. Coarse information may be available where fine detail is not.

For a fictional subscription app, an original first-window mapping could be:

- Fine value 0: first open recorded; coarse value low.
- Fine value 10: account created; coarse value low.
- Fine value 20: first useful task completed; coarse value medium.
- Fine value 40: first validated purchase; coarse value high.

This is a planning example, not an Apple default or a universal optimum. It uses a few states because the initial question is whether campaigns bring people who reach value and pay. It does not need all 64 values simply because they exist.

Choose events that the app can confirm reliably while the relevant window is open. If payment validation happens on the backend, establish how the app receives the result in time for an eligible update. A button tap is not evidence that a transaction succeeded.

Define precedence when several events occur, what happens after a retry, and how mapping changes are deployed. Keep the mapping version beside the reporting model. Reinterpreting last month's value 20 under a newly changed definition corrupts historical analysis.

This original planning record gives the implementation owner a clear starting point. It is not SDK configuration:

```yaml
schema_version: subscription_app_v1
decision: compare_early_value_by_acquisition_campaign
window_scope: first_conversion_window
activation_event: first_useful_task_completed
purchase_event: purchase_validated
purchase_authority: subscription_backend
unknown_value_policy: retain_as_unknown
owner: app_measurement_lead
```

If the business outcome usually happens after the early window, choose a useful leading signal and validate its relationship with later outcomes using your first-party data. Do not rename an early proxy “lifetime value.” The [tracking plan guide](https://www.martechdevs.com/blog/tracking-plan) explains how to give events testable meanings and owners.

## Reporting delay changes when you can make a decision

For [eligible SKAdNetwork 4 reporting](https://developer.apple.com/documentation/storekit/receiving-postbacks-in-multiple-conversion-windows), Apple defines conversion windows spanning days 0–2, 3–7 and 8–35. The first postback has a randomized 24–48-hour delay after finalization; later postbacks have a 24–144-hour delay. Eligibility and privacy tiers affect which reports arrive.

Locking a conversion window finalizes its value early. It does not remove the delivery delay, and further updates in that locked window are ignored. The decision trades remaining observation time for earlier scheduling. Do not copy this timing into every framework, version and network report without checking its applicable specification.

That distinction changes an operating review. Yesterday's spend can be complete while its acquisition outcomes are still developing. Cutting a campaign because its newest cohort appears weak may compare mature spend with immature conversions.

Show cohort date, report-received date and the time the dashboard last refreshed. Mark recent cohorts as provisional according to the reporting path you use. Choose review intervals that allow the required outcome and reporting delay to occur; there is no single waiting period that makes every metric final.

Compare cohorts at the same age. A seven-day retention result for one campaign should not sit beside a two-day-old cohort from another without an obvious qualification. Keep later revisions so the team can learn how unstable early readings are for its own app.

## Unknown conversion values must stay unknown

A missing value is not a zero purchase and not proof of a broken SDK. It can reflect privacy-related limits, while operational defects can also produce missing information. Track those explanations separately when you have evidence.

Apple's [postback parameter reference](https://developer.apple.com/documentation/adattributionkit/identifying-the-parameters-in-a-postback) distinguishes optional conversion fields, the winning-attribution indicator and the postback sequence index. Your report needs those distinctions before it computes a conversion rate.

Consider an original, simplified set of 100 unique winning first postbacks, all interpreted using the same mapping. Suppose 60 contain fine values, 20 contain coarse values and 20 have no usable conversion value. Among the 80 with usable detail, 24 indicate a purchase under a mapping where that classification is explicit.

Reporting 24 divided by 80 gives 30% **among records with known detail**. Reporting 24 divided by 100 gives a 24% observed purchase-signal share across this set. If the 20 unknown records could all be either purchase or non-purchase, the share within this set lies between 24% and 44% under those assumptions.

That range is a missing-value sensitivity check, not a statistical confidence interval or the true purchase rate of all acquired customers. It does not correct unobserved installs, attribution coverage, delayed updates or incorrect event mapping.

The operational lesson is straightforward: show coverage next to the result. If coverage changes, investigate that before interpreting the entire movement as a marketing win or loss. Never silently remove unknown rows merely to produce a cleaner percentage.

## Count valid, unique reports at the right level

If you receive postbacks directly, use the applicable verification process. [AdAttributionKit verification](https://developer.apple.com/documentation/adattributionkit/verifying-a-postback) requires checking the signature and using the postback identifier to reject duplicates. Production and development messages use different verification keys. An HTTP request arriving at your endpoint is not sufficient evidence of a valid conversion.

[SKAdNetwork's verification procedure](https://developer.apple.com/documentation/storekit/verifying-an-install-validation-postback) is version-specific and uses its transaction identifier for duplicate handling. Preserve framework and environment boundaries rather than forcing every payload through a single guessed schema.

Separate unique messages from unique install counts. A later postback can be a valid additional observation from an existing attribution. A nonwinning report is not another winning install. A retransmitted copy is not new activity.

For example, an original ingestion fixture might contain eight deliveries: three distinct winning first postbacks, one repeated copy, one later-window postback, one nonwinning postback, one invalid message and one development message. The production first-postback count is three, not eight. That arithmetic assumes the messages have already been correctly classified and verified; it is not a substitute for cryptographic validation.

When an MMP handles collection, ask which of these operations it performs and what its export represents. Do not ingest the provider's processed count and your direct copies into one additive total. Retain provenance so an analyst can trace the report back to its selected source.

## Apple Ads has more than one measurement view

[Apple's attribution overview](https://ads.apple.com/app-store/help/attribution/0094-ad-attribution-overview) explains Apple Ads participation in its cross-network attribution system and says the AdServices API continues to provide additional Apple Ads information. Those views serve related purposes but should not be treated as independent piles of customers.

If the Apple Ads dashboard, AdServices output and MMP disagree, compare attribution rules, reporting dates, eligible traffic and outcome definitions first. Preserve the differences as a reconciliation question instead of picking whichever total makes acquisition look strongest.

The same principle applies to another network's self-reported conversions. Agree on the decision's reporting method and investigate substantial differences. Attribution consistency is valuable, but even perfect agreement does not establish incremental impact. Our [attribution, MMM and incrementality guide](https://www.martechdevs.com/blog/attribution-vs-mmm-vs-incrementality) explains which question each method can answer.

## Android needs its own implementation path

[Google Play Install Referrer](https://developer.android.com/google/play/installreferrer) can provide referral content and click/install timestamps from Google Play. It is a specific installation-source mechanism, not an iOS-style aggregate postback and not a complete cross-store measurement system.

Check how your SDK reads, persists and interprets the result, including unavailable or failed responses. Keep store, source and attribution method in the data model. A label such as “Android organic” should not conceal every case where collection failed.

Also remove obsolete roadmap assumptions: [Google's current Android Privacy Sandbox documentation](https://developers.google.com/admob/android/privacy/sandbox) marks that system deprecated as of 17 October 2025. An implementation plan should not present its Attribution Reporting API as an upcoming mandatory migration. Use current documentation for the actual distribution and advertising paths you operate.

## What an MMP adds, and what remains your job

An MMP can provide a maintained layer for network integrations, attribution processing, campaign reporting, postbacks, links and exports. The exact scope depends on its implementation and your package. Compare those capabilities against the work your team would otherwise maintain.

You still own event meaning, purchase validation, privacy configuration, cost reconciliation and the decision made from the result. An MMP cannot define a useful activation event by looking at your app name, and it cannot turn an unobserved customer journey into verified history.

A small app using few acquisition paths may start with direct platform reporting and a modest first-party measurement setup. As networks, journeys and operational requirements grow, the value of a common integration layer can increase. Evaluate maintenance capacity alongside subscription cost.

Our [AppsFlyer, Adjust and Branch comparison](https://www.martechdevs.com/blog/appsflyer-vs-adjust) covers current entry plans, billing units, deep-link tests and export questions. Use it after defining the required outcomes, so the purchase follows the measurement need.

## Launch a small, testable measurement scope

Start with one app, one important acquisition path and a short event mapping. Assign a named owner for SDK configuration and another accountable owner for the report's business definition, even if one person fills both roles.

Test installation, first launch, the chosen activation event and a validated purchase. Include refusal of tracking permission, unavailable conversion detail, repeated delivery and a delayed commercial outcome. Record expected behavior before examining the report.

[Apple's AdAttributionKit testing guide](https://developer.apple.com/documentation/adattributionkit/testing-adattributionkit-with-developer-mode) provides development-specific testing with shorter windows. Its documentation distinguishes development from production impressions and postbacks. A successful accelerated test is evidence about configuration; it does not establish production coverage or normal delivery timing.

Keep a release record containing the app version, SDK version, mapping version, partner configuration and test results. When a metric changes, this record helps distinguish business movement from instrumentation changes.

Before using the setup for material budget decisions:

## Checklist

- [ ] The business outcome and reporting denominator are written down.
- [ ] Supported operating systems and attribution paths are documented.
- [ ] Conversion values have a versioned, testable interpretation.
- [ ] Tracking permissions and SDK data flows match the intended behavior.
- [ ] Unknown values remain visible in coverage reporting.
- [ ] Duplicate, invalid, development and later-window messages are handled distinctly.
- [ ] Recent cohorts show their reporting maturity.
- [ ] Campaign cost and commercial outcomes have separate authoritative sources.
- [ ] An owner can explain a discrepancy from source to final report.

If you need help connecting acquisition signals with activation and subscription outcomes, our [product analytics services](https://www.martechdevs.com/product-analytics) can help build that measurement model and its implementation checks. The useful deliverable is a decision the team can defend, with the limits of its evidence visible.

## Frequently asked questions

### What is SKAdNetwork in plain English?

It is Apple's system for reporting eligible ad-driven app installations and selected later signals while limiting personal information. Reports can be delayed and incomplete by design. They should not be interpreted as a full customer-level event history.

### Has AdAttributionKit made every SKAdNetwork implementation obsolete?

No. Apple recommends AdAttributionKit and documents interoperability with SKAdNetwork. The appropriate configuration depends on the networks, app and operating-system versions involved. Maintain a supported integration plan rather than deleting an existing path solely because a newer framework exists.

### Do I need ATT permission for every attribution report?

No. Privacy-preserving attribution and the tracking that requires ATT permission are distinct. Review all SDK operations against Apple's policy; the ability to receive an attribution report does not grant permission for unrelated cross-company tracking.

### Why are some conversion values missing?

Privacy-related reporting limits can withhold detail, and implementation or processing problems can also affect what reaches your report. Preserve unknown states and inspect coverage, versions and collection health before assigning a cause. Missing information must not automatically become zero activity.

### Do I need an MMP to measure a small iOS app?

Not automatically. Compare the integrations and maintenance you need with your team's capacity to operate them directly. An MMP is more useful when it solves a specific operational burden. Either approach still needs dependable product events, commercial records and clear reporting definitions.

## Sources

1. [Apple SKAdNetwork documentation](https://developer.apple.com/documentation/storekit/skadnetwork)

2. [Apple ad attribution overview](https://developer.apple.com/app-store/ad-attribution/)

3. [AdAttributionKit and SKAdNetwork interoperability](https://developer.apple.com/documentation/adattributionkit/adattributionkit-skadnetwork-interoperability)

4. [Apple user privacy and data use](https://developer.apple.com/app-store/user-privacy-and-data-use/)

5. [Apple WWDC24: Meet AdAttributionKit](https://developer.apple.com/videos/play/wwdc2024/10060/)

6. [SKAdNetwork multiple conversion windows](https://developer.apple.com/documentation/storekit/receiving-postbacks-in-multiple-conversion-windows)

7. [AdAttributionKit postback parameters](https://developer.apple.com/documentation/adattributionkit/identifying-the-parameters-in-a-postback)

8. [AdAttributionKit postback verification](https://developer.apple.com/documentation/adattributionkit/verifying-a-postback)

9. [SKAdNetwork postback verification](https://developer.apple.com/documentation/storekit/verifying-an-install-validation-postback)

10. [Apple Ads attribution overview](https://ads.apple.com/app-store/help/attribution/0094-ad-attribution-overview)

11. [Google Play Install Referrer](https://developer.android.com/google/play/installreferrer)

12. [Android Privacy Sandbox status](https://developers.google.com/admob/android/privacy/sandbox)

13. [Testing AdAttributionKit with Developer Mode](https://developer.apple.com/documentation/adattributionkit/testing-adattributionkit-with-developer-mode)