AdServices: The Attribution Apple Kept for Itself

AdServices: The Attribution Apple Kept for Itself
You are running Apple Ads. Your reports show installs by campaign, and that is where the trail stops. Which keyword produced a paying subscriber, and which produced an install that never opened the app again, is the one question the dashboard will not answer.
Everywhere else on iOS that question is genuinely hard, and it is hard for a structural reason: Apple put the advertising identifier behind a consent prompt in 2021, and what replaced it arrives bucketed, delayed, and redacted further the smaller your campaign is. The attribution problem, and how the industry works around it, is the piece before this one.
This piece is about the exception. Apple built the restriction, and then built itself a way around it on its own ad channel.
That way is AdServices, a first-party attribution API that returns keyword-level data on every download, at no extra cost, including on users who declined tracking. It has been available since iOS 14.3, and it is routinely left uncalled by teams already paying for the channel it measures.
Why Apple's Own Channel Escaped the Problem
Apple runs both the ad and the store. There is no gap for an identity to cross, so there is nothing for a consent prompt to break.
Every attribution problem the rest of the industry manages comes from the same root. An ad happens on one company's surface, the install happens on Apple's, and connecting the two requires an identifier most users have declined since 2021. On Apple Ads, both events happen inside Apple. Nothing has to be matched across a boundary, because there is no boundary.
The old iAd framework proved the point by failing. It sat behind the tracking prompt, so when a user declined it returned nothing. Apple retired it outright on 7 February 2023. AdServices replaced it and inverted the logic: it returns data on every download, consent or not.
Which raises the obvious question. If consent no longer gates it, what actually changes when a user says no?
What AdServices Returns
The payload is eleven fields. Here it is from a user who allowed tracking:
- attribution
- orgId
- campaignId
- adGroupId
- keywordId
- adId
- conversionType
- claimType
- supplyPlacement
- countryOrRegion
- clickDate
And here it is from a user who declined:
- attribution
- orgId
- campaignId
- adGroupId
- keywordId
- adId
- conversionType
- claimType
- supplyPlacement
- countryOrRegion

Read the two lists again. The only thing you lose is the timestamp. On a tap-through that field is clickDate, on a view-through it is impressionDate, and claimType tells you which one you are looking at.
Everything that matters survives. You still get keywordId from a user who declined tracking.
Set that against the world the rest of this series describes, where a small advertiser's reports arrive redacted because the campaign was not big enough to clear a privacy threshold. On Apple's own channel there is no threshold. The small advertiser and the large one receive the same fields, on the same download, on the same day.
One honest exception. When Apple matches your app to a search you never bid on, the download is attributed but arrives without a named keyword, because there was no keyword to name.
One field is worth more this year than last. supplyPlacement tells you where the ad ran, returned as a value like APPSTORE_SEARCH_RESULTS. Until March 2026 that was close to a constant. Now that a single query can return more than one ad slot, it is the field that tells you which placement actually produced the download.
Getting It Out
Two calls.
Your app asks the AdServices framework for a token, which is valid for 24 hours. Your server posts that token to https://api-adservices.apple.com/api/v1/ and Apple returns the payload above.
Then the part people miss. The payload contains identifiers, not names. You get keywordId: 87675432, not "meditation timer". Turning that number into the actual keyword takes a second call, to the Apple Ads Campaign Management API, which reads your campaign structure and returns the mapping.
Neither call is hard. Teams get stuck because they build the first one, get a number back, and have nothing to match it against.
You may not have to build either. If you already run Adapty, RevenueCat, or Superwall, their SDK is in your app and the token is already passing through it. All three surface the Apple Ads identifiers in some form, because doing so costs them almost nothing. Before you write a line of integration code, open the tool you are already paying for and look for the Apple Ads filters. The data is rarely missing. It is usually one filter nobody opened.
Our own SDK does this too. If you are using OWA, Apple-side conversion measurement arrives without either integration.
The point of listing four ways to get the same data is that it stops being the interesting part. On this one channel, getting the numbers is close to a solved problem.

The One Thing AdServices Cannot Do
It measures Apple's own ad channel and nothing else.
AdServices uses only Apple's first-party data. It has no knowledge of whether a user saw or clicked an ad anywhere outside the App Store: not on Meta, not on TikTok, not on a web referral. For those channels you are back in the redacted world the rest of this series is about.
So be precise about the claim. AdServices does not replace an MMP. It makes an MMP unnecessary for one channel. That is a smaller claim than "measure everything for free", and unlike that one, it is true.
It is also a claim worth more this year than last, because the channel it covers just got bigger.
Why This Matters More in 2026
Apple Search Ads became Apple Ads in April 2025. The rename signalled wider ambitions, and the inventory followed.
On 3 March 2026, Apple began rolling out additional search placements. A single query can now return two ads instead of one, starting in the UK and Japan and reaching all markets by the end of that month, on iOS and iPadOS 26.2 and later. It is the first time more than one ad can appear within a single set of search results since the platform launched in 2016, and we covered what it changes for bidding in Apple Is Expanding Search Ads in 2026.
More inventory means more advertisers competing on the same high-intent keywords. When a keyword costs more, knowing whether it produced a subscriber or just an install stops being a curiosity and becomes a budget decision.
Which is where the actual problem starts.
What Measurement Cannot Do
Everything above is measurement. AdServices hands you the data, an MMP hands you the data, the subscription tool in your app hands you the data, and so does our SDK. Four routes to the same eleven fields.
None of them makes a decision.
Knowing that "meditation timer" produced forty subscribers and "sleep sounds" produced three is not a decision. It is a row in a table. The decision is what you do on Monday: which keywords to bid harder on, which to stop paying for, and, hardest of all, which keyword you have never tried but should, because it resembles the ones that are working.
That last question is the one no report answers, because answering it means reading across the data instead of down it. A dashboard can rank what you already bought. It cannot tell you what to buy next.

This is the half we built OWA for. Attribution on this channel is close to solved and getting cheaper every year. What still costs teams money is the part after the export, where somebody has to look at forty rows and work out what they mean.
FAQ
Does Apple Ads attribution work without ATT consent?
Yes. The AdServices framework returns attribution data on every download regardless of tracking consent. When a user declines, you lose only the timestamp, which is clickDate on a tap-through and impressionDate on a view-through. Campaign, ad group and keyword identifiers all survive. This is the key difference from the retired iAd framework, which returned nothing when a user declined.
What is the AdServices framework?
AdServices is Apple's first-party attribution API for Apple Ads. It reports which campaign, ad group and keyword drove a specific app download, using only Apple's own data from the ad interaction and the store install. Because both events happen inside Apple, it does not depend on the advertising identifier or on tracking consent to function.
Can I get Apple Ads attribution without an MMP?
Yes, for Apple Ads specifically. Your app requests an attribution token, your server sends it to Apple's attribution API, and Apple returns the payload. To map keyword IDs to real keyword names you make a second call to the Apple Ads Campaign Management API. This covers Apple Ads only, and no other channel.
What is the difference between AdServices and SKAdNetwork?
AdServices attributes downloads driven by Apple's own ad channel, using Apple's first-party data, at keyword level and with no privacy threshold to clear. SKAdNetwork attributes installs from third-party ad networks, with thresholds that redact and delay reports for smaller advertisers. AdServices covers one channel deeply. SKAdNetwork covers many channels with heavy limits.
The Channel You Can Actually Read
Every other channel on iOS asks you to accept less than you want to know. This one does not.
The data is already flowing through your app. Two calls, or one filter, or an SDK you already have. What happens after that is not a measurement problem, and it never was.
And for every channel Apple's own attribution can never see, there is a different answer, which is the next piece in this series.
