Two attribution frameworks run on the same phone, written by the same company. One tells an advertiser which keyword produced the install. The other declines to say which app the ad appeared in unless enough strangers convert first.
This is not a conspiracy story. Apple documents both frameworks openly, and the privacy reasoning behind the second one is coherent and publicly argued. But the consequence is rarely stated plainly: an advertiser comparing Apple Ads against any other iOS channel is not comparing two measurements. They are comparing a measurement against an estimate, and the estimate is degraded by rules the estimating party does not control.
That asymmetry is the quiet reason Apple Ads reads so well in a last-touch dashboard — and it is also, separately, a real advantage worth having. Both things are true, and keeping them apart is the whole discipline of this article.
01Two frameworks, two different questions
AdServices is Apple’s first-party attribution API. It exists so that an app can ask Apple, at first launch, whether this install followed an ad Apple itself served. Because Apple served the ad, sold the placement and hosts the store, no third party has to be trusted and no identifier has to be shared.
AdAttributionKit is the framework Apple provides to everyone else. Its job is harder by construction: to tell an ad network that one of its impressions produced an install, without letting that network learn anything that could identify the person. Apple’s own overview describes it as measuring campaigns “in a way that preserves user privacy,” accomplished “by limiting the data included in the attribution postback.”
Those are different questions with different answerable precision. Apple’s question — did this install follow one of my own ads, and which one — is a lookup in its own records. The network’s question — did my impression cause this install — has to be answered across an aggregation boundary designed to prevent exactly the kind of joining that would make it precise.
Nothing about that is unfair on its face. It becomes an advertiser’s problem at the moment those two answers are placed in adjacent columns of the same spreadsheet and treated as comparable.
02What AdServices returns, field by field
Apple’s help page “Measuring ad performance on the App Store,” accessed September 2, 2026, states that the AdServices attribution API “supports campaign, placement, ad group, and keyword-level attribution.” The payload also identifies Apple Ads as com.apple.ads and encodes placement in the campaign ID, with search results mapped to 10, the search tab to 20, the Today tab to 30 and product pages to 40.
Four properties of that sentence do the work.
- It is deterministic. The answer arrives when the user opens the app, tied to a specific install, not modelled from a population.
- It reaches the keyword. Not the campaign, not the ad group — the individual search term you bid on, which is the unit at which App Store search advertising is actually managed.
- It is unconditional on volume. Nothing in Apple’s description makes campaign, ad group or keyword identity contingent on how many other people converted.
- It is short-lived but complete. Apple’s attribution overview states AdServices data “is retained for up to 21 days to support relevant campaign measurement.”
Apple also states the scope limit honestly: AdServices “does not have information about whether or not a user viewed or clicked on an ad outside of the App Store.” It is a first-party record, not a view of the world. The attribution window for downloads and redownloads is 30 days from a tap or one day from a view; pre-orders run 90 days from a tap and 61 from a view. And Apple counts a store-verified download, while a measurement partner counts a first app open — a definitional difference that produces a permanent, structural discrepancy between the two numbers even when both are working perfectly.
03What an AdAttributionKit postback returns — and what is conditional
Apple’s advertiser-facing page for AdAttributionKit lists the postback fields explicitly. Read the list for the word “conditional.”
The advertised item ID — the app being promoted — is always present. The conversion type, which identifies whether the install was a redownload, is always present. The source identifier, carrying campaign information, is present, though its granularity varies. Then the two that matter most:
The publisher item ID — the app where the ad was shown — is, in Apple’s words, “conditional and only displays when privacy thresholds are met.” The conversion values, which are how an advertiser expresses that this user turned out to be worth something, are “conditional and only displays when crowd anonymity thresholds are met.”
Apple then tells advertisers what happens when the thresholds are not met, in a sentence worth quoting in full: “In the absence of a conditional value, your network (or any advertising partner’s networks you work with) might represent the value as ‘null.’”
The postback is also delayed — Apple says advertisers “can receive a postback within 24-48 hours of a user launching the app” — and carries no click timestamp at all. Up to 64 signals of user value can be encoded, and up to three postbacks arrive for a click-through re-engagement on iOS 18 and later. Apple’s crowd-anonymity description is candid about the mechanism: “Apple performs a real-time check for a particular download to determine the postback data tier and the level of information that will be included in the postback.”
→ THE ASYMMETRY IN ONE LINE
Your volume decides your visibility — but not on Apple Ads
A smaller advertiser buying a third-party network gets less information than a larger one buying the same inventory, because crowd-anonymity tiers key off conversion volume. The same smaller advertiser buying Apple Ads gets keyword-level attribution on install one. Apple says this itself, describing AdServices data as “particularly valuable for smaller developers who may receive limited information back from AdAttributionKit due to its crowd anonymity thresholds.”
04The ATT answer costs Apple Ads exactly one field
Most advertisers assume the App Tracking Transparency prompt is the dividing line between good and bad iOS measurement. For Apple Ads, it is very nearly a rounding error.
Apple’s wording is unambiguous. The payload is either “standard” or “detailed,” and “the difference between the two payloads is the clickDate or impressionDate field.” If a user asks an app not to track them, AdServices returns the standard payload without that timestamp. If they allow tracking, the detailed payload adds it, “rounded to the minute.”
Campaign, ad group, keyword, placement, creative set, conversion type and country come back either way. An Apple Ads advertiser facing a total refusal of the tracking prompt loses the ability to measure time-to-install. They do not lose the ability to see which keyword bought the user.
This is the point the German competition authority’s ATT decision did not touch. The Bundeskartellamt made Apple’s prompt neutral and aligned its wording with Apple’s own advertising prompt — a real remedy to a real problem — but the reporting gap described here is a different asymmetry, and it survived the decision untouched. It was one of four named in 2021; the prompt was the only one addressed.
05The comparison nobody publishes
Both columns below are sourced from Apple’s own pages, accessed September 2, 2026. We have found no published side-by-side of this kind anywhere else.
| Field | Apple Ads via AdServices | Other networks via AdAttributionKit | Conditional on |
|---|
| Campaign | Always | Present, granularity varies | Crowd-anonymity tier |
| Ad group | Always | Not a field | — |
| Keyword | Always | Not a field | — |
| Placement | Always (encoded 10/20/30/40) | Publisher app, conditional | Privacy thresholds |
| Conversion value | Not applicable | Conditional, may be null | Crowd-anonymity thresholds |
| Click timestamp | Detailed payload only | Never | ATT permission |
| Timing | At app open | 24–48 hours after launch | — |
| Basis | Deterministic, per install | Aggregated, thresholded | — |
Read down the “conditional on” column. Every constraint on the right-hand channel is a function of somebody else’s behaviour: how many other people converted, in what window, on what app. The only constraint on the left-hand channel is a single user’s answer to a single prompt, and it costs one field.
06Apple’s own admission on double claiming
The most useful sentence Apple has published on this subject is not a benchmark. It is a warning.
“AdAttributionKit may be able to register a click from a third-party network that AdServices is, by design, unaware of, so both the third-party network and AdServices could claim the conversion in that instance. AdAttributionKit provides the official last-click amongst registered ad platforms.”
Two consequences follow. First, any reporting layer that adds Apple Ads installs to network installs without a deduplicating single-source-of-truth is overcounting, by construction, in a direction nobody has measured. Second, the tie-break rule is stated: AdAttributionKit is the official last click among registered platforms — which means Apple’s own first-party number is not automatically the authoritative one, even though it is the more precise one.
Apple’s interoperability documentation goes further on the mechanics. Where an app carries impressions from both frameworks, “the system sorts both of them and decides the winner. Only one impression can win for a conversion.” The most recently tapped ad wins; absent any tap, the most recently viewed one does. A maximum of six impressions is considered for any conversion. Ad network identifiers are compatible across the two frameworks, so no network needs a separate ID for each.
That is a coherent design. It is also a design in which the number your finance team sees depends on which layer of the stack produced it — an issue we worked through from the other direction in the comparison of Apple Ads and Google App Campaigns on iOS, where Google generates three non-agreeing install counts for the same spend entirely within its own systems.
07The 77% that is not an adoption figure
Apple’s attribution overview contains a striking claim: “Since its introduction in 2018, AdAttributionKit (formerly referred to as SKAdNetwork) has become a backbone of the advertising ecosystem, covering 77% of all referral-based conversions to the App Store.”
Against that, Kochava’s June 2026 write-up says AdAttributionKit “has negligible traction despite being in market since 2024,” reporting that 27% of surveyed respondents had not heard of it and only 7% had an active plan and were testing its features.
These look irreconcilable and are not. Apple has applied the AdAttributionKit name retroactively to the entire SKAdNetwork lineage, dating the framework to 2018 in the same sentence — so the 77% is a coverage figure for the whole family, not an adoption figure for the newer API. Kochava is counting adoption of the 2024 API specifically. Both can be accurate; neither should be quoted as if it answers the other’s question.
Apply the usual scepticism to both. Apple publishes no methodology, no date range and no definition of “referral-based conversions” for the 77%. Kochava discloses only that it “recently surveyed a cohort of mobile marketers and app owners,” with no sample size, fielding date or sampling method — so every percentage in it is self-reported vendor research and should be attributed as such rather than cited as measurement. The naming collapse, not either number, is the finding.
→ FREE 10-POINT AUDIT
Are your channels being compared on the same evidence?
We map what each of your iOS channels can actually observe, where your dashboard is double-counting, and which comparisons your data genuinely supports. One hour. Senior strategist. No pitch.
Book my free audit →
08Apple Ads has not migrated its own product
Here is the detail that ought to end several vendor sales conversations.
Apple’s own help page states: “Apple Ads is currently registered with SKAdNetwork versions 1.0, 2.0, and 3.0 for click-through attribution. Apple Ads will register at a later date with the AdAttributionKit API.” Apple’s attribution overview dates the registration step to April 10, 2025, describing it as registering with AdAttributionKit “beginning with SKAdNetwork versions 1-3.”
So as of September 2026, Apple’s own advertising product sits on SKAdNetwork 1 through 3 — not even 4 — with full AdAttributionKit registration described as a future event with no date attached. Trade coverage noted at the time that the April 2025 registration announcement followed eleven days after the French competition authority’s €150 million fine over Apple’s ATT implementation; that is adjacency rather than demonstrated causation, and the publication reporting it drew no causal link either.
The same page states Apple’s intent for the older framework: “Apple will continue to maintain the AdServices API, as augmenting AdAttributionKit with the AdServices attribution API provides additional information for developers to optimize the campaigns they’re running on the App Store.” That is a commitment to keep the first-party channel, not to fold it into the shared one. The asymmetry is not a transitional artefact awaiting cleanup. It is the stated architecture.
09Where SKAdNetwork actually stands in 2026
A brief status check, because the vendor commentary is muddy.
SKAdNetwork is not deprecated; Apple has announced no deprecation date, and it remains a documented framework with active conversion-value APIs. The highest version that ever shipped is 4, which arrived with iOS 16.1 in October 2022. Version 5 was previewed in 2023 and never shipped — Apple introduced AdAttributionKit instead in 2024. Any 2026 guide referring to SKAN 5 as a live specification is describing something that does not exist.
Apple’s last substantive attribution release was WWDC 2025, which brought configurable attribution windows in place of the fixed 30-day click and one-day view periods, multiple simultaneous re-engagement conversion windows from iOS 18.4, a country-code postback field, and developer-mode postbacks creatable from the iOS Settings app. Apple was explicit that the new country field is itself thresholded: postbacks “will only contain country code if there has been enough volume for similar conversions within the same country.”
WWDC 2026 brought nothing. Adjust’s June 9, 2026 recap states plainly that “unlike WWDC25, Apple did not announce significant updates to AdAttributionKit or SKAdNetwork (SKAN), attribution windows, postbacks, crowd anonymity tiers, or re-engagement measurement capabilities.” An absence is a finding: the framework advertisers are told to migrate toward received no development in the most recent cycle, while the first-party channel it competes with kept shipping — new bidding, a second search slot and a rebuilt API all landed in the same twelve months.
10What the asymmetry should change in your plan
Four practical positions follow, and none of them is “move everything to Apple Ads.”
Stop comparing channels on attributed installs alone. A last-touch table ranking Apple Ads against a network is comparing a deterministic per-install record against a thresholded aggregate. The ranking is partly an artefact of the measurement, and the direction of the artefact favours Apple. Say so out loud in the deck.
Treat the keyword-level record as a buying advantage, not a scoring one. The genuine value of AdServices is that it lets you find which declared intent produced a high-value user and buy more of exactly that — the mechanism behind the high-ARPU case for the channel. That is a targeting capability. It does not make the channel more incremental, and no published incrementality study of Apple Ads exists to settle the question either way.
Audit your stack for double counting. Apple has told you both frameworks can claim the same conversion. Confirm your measurement partner is deduplicating, and confirm the same install is not appearing in a channel report and an Apple Ads report that are later summed.
Do not budget for a migration Apple has not scheduled. Apple’s own ad product has not completed AdAttributionKit registration, no deprecation date exists for SKAdNetwork, and the 2026 developer cycle brought no attribution changes at all.
11What is genuinely unknown
The honest list, and it is longer than the industry’s confidence suggests.
No rigorous public figure exists for how often crowd anonymity suppresses a conversion value, what share of postbacks arrive null, or what proportion of ad networks have adopted the newer API. The numbers in circulation are vendor estimates without disclosed methodology: one widely-cited 10–15% null rate describes SKAdNetwork 3, not the SKAdNetwork 4 crowd-anonymity regime, and the tier structure most often reproduced comes from a measurement vendor’s description rather than an Apple page. ATT opt-in rates quoted in 2026 range from roughly 25–30% to 69.7% depending on the denominator, which tells you how unstable that literature is.
Apple publishes no threshold values. The crowd-anonymity tiers are described qualitatively and never numerically, so no advertiser can predict in advance whether a given campaign will return conversion values. Apple’s help pages carry no dates or changelogs, so none of them can be aged against the 2026 changes. And several Apple developer documentation pages could not be retrieved directly during this research; where that happened we have cited only what was confirmable on a reachable Apple page, and the field list in section 3 comes from Apple’s advertiser-facing page rather than the framework reference.
What survives all of that is the structure, and the structure is not in dispute because Apple wrote it down. One channel reports the keyword every time. Every other channel reports what a threshold permits, when a delay allows. If you are choosing where to buy the highest-value iOS users, that difference is worth understanding before it silently decides for you — and it is the first thing we look at in the free 10-point audit.