For five years, denying App Tracking Transparency cost an Apple Ads advertiser one field. As of September 1, it costs them nothing — and a larger gate quietly took its place.
If you have read anything about iOS measurement since 2021, you know the shape of the Apple Ads argument: AdServices returns campaign, ad group, keyword and placement attribution regardless of the ATT answer, and an ATT denial costs you only the click timestamp. That was the asymmetry. It was accurate, it was well documented, and it is now out of date by eight days.
Apple’s live attribution documentation no longer contains the standard-versus-detailed payload distinction. Its current sample payload carries the timestamp with no ATT condition attached. A September 2026 changelog entry documents a different change entirely. And the only plain-English statement of what happened comes not from Apple but from a measurement vendor’s integration notes.
Apple published no announcement. This is the paper trail, what it means for your reported numbers, and the new gate that almost nobody is discussing.
01What changed on September 1
The clearest statement of the change is in Singular’s Apple Ads integration documentation, which exists to tell customers what will differ in their dashboards:
Starting September 1, 2026, all attribution claims will include a touchpoint timestamp evaluated against your configured lookback window.
The same page, a paragraph earlier, states the change in the vendor’s own planning language: “Effective September 1st, Apple will provide a touchpoint timestamp in addition to the existing fields currently included.”
Apple’s side of this is documented only by omission and by artefact. The current AdServices reference document, dated 2026-09-01 in its own URL, contains no standard-versus-detailed record distinction at all. The archived version 3 of the same document, dated 2025-03-25, did — it stated that the user’s ATT setting determined which attribution record type the server returned. Between those two dates the rule disappeared from Apple’s reference material without a note.
This is the second time in six weeks that Apple has silently revised a live advertising document. The last one was a weekly-visitor figure that changed from 650 million to 850 million with no changelog, which we documented at the time. The mechanism is the same: Apple’s advertising pages carry no dates and no version history, so the only defence available to anyone is dated third-party note-taking.
02What the payload contains now
Apple’s live help page publishes a sample attribution payload. Every field in it is worth reading, because this is the granularity that makes Apple Ads structurally different from every other channel on iOS:
| Field | Example value | What it gives you |
|---|
campaignId | 542370539 | Campaign-level attribution |
adGroupId | 542317095 | Ad group-level attribution |
keywordId | 87675432 | The search term you actually bought |
adId | 542317136 | Which creative variation served |
supplyPlacement | APPSTORE_SEARCH_RESULTS | Placement, added January 2026 |
claimType | Click | Click versus view-through |
clickDate | 2026-04-08T17:17Z | The field ATT used to gate |
conversionType | Download | Download versus redownload |
Note that clickDate is present in the sample Apple publishes today, and that Apple labels that sample as the response when age and gender targeting are off — not as the response when ATT is granted. The conditional has moved. Apple states separately that clickDate is rounded to the minute, and that impressionDate takes its place on view-through claims.
Keyword-level attribution surviving a privacy regime is the whole commercial argument for the channel. It is why buying declared intent on the App Store is measurable in a way that buying inferred intent elsewhere on iOS is not: you can see which query produced the user, and on a store where consumer spend per download runs several times the alternative platform, knowing the query is knowing the value.
03The five years that just ended
The rule that ended had been in force since AdServices replaced the old attribution API. Apple’s version 3 reference, archived at a dated URL, set it out: the ATT setting determined the record type, detailed records carried clickDate or impressionDate, and standard records omitted them. Everything else — campaign, ad group, keyword, placement — came through either way.
Singular’s documentation still describes the two states in the operational terms that mattered to practitioners. On an opt-out, attribution was claimed via a standard response “where the ‘click time’ or ‘impression time’ is not available,” and the install was matched via IDFV with timing defaulted to the window. On an opt-in, a detailed response arrived with the click time and the match ran on IDFA.
That is a real difference in machinery, and it is why the received wisdom held that Apple Ads “loses only a timestamp.” What almost nobody worked through is what losing a timestamp actually did to the numbers.
04The correction runs the wrong way
Here is the finding that inverts the story, and it comes from Adjust’s own help documentation rather than from anyone’s analysis:
It is not possible for Adjust to discard standard response engagements that happen outside of the 30-day Apple attribution window.
Follow that through. Apple Ads runs a 30-day click-to-install window and a one-day view-through window on non-pre-order campaigns. To enforce a window you need a timestamp. Without one, a measurement partner receiving a standard response could not tell whether the engagement it described happened three days ago or forty. It had to accept the claim.
So the missing timestamp did not cost Apple Ads credit. It prevented anyone from taking credit away. For five years, on the ATT-denied share of traffic, stale claims that fell outside the window were counted anyway.
Singular says the quiet part directly in its note about the change: with a timestamp now available to evaluate against your configured lookback, “you may observe a slight decrease in attributions attributed to Apple Ads.”
→ WHAT TO EXPECT IN YOUR DASHBOARD
A September step-down in Apple Ads installs is the fix working, not a delivery problem
If attributed installs dip in early September without a matching drop in taps or spend, check the date before you check your bids. A campaign that is genuinely under-delivering shows a different signature entirely — and Apple’s own troubleshooting guidance for that case still points at a control that no longer exists.
The size of the step-down is not knowable from public data, because it depends on your ATT-denied share, your organic download velocity and how much of your traffic genuinely arrives outside 30 days. Anyone quoting a percentage here is guessing. What is knowable is the direction, and the direction is down.
This also means five years of Apple Ads-versus-other-channel comparisons carried a small, undisclosed bias in Apple’s favour on the opted-out cohort. Not a large one, and not deliberate — but it belongs in any retrospective that compares channel ROAS across that period, including the cross-platform comparisons that are hard enough already.
05The gate that replaced it
Apple did not remove a condition from the payload. It swapped one. From Apple’s current help page, an ad group using age or gender settings returns this and nothing else:
{"attribution": false}
Apple’s AdServices changelog records the same thing for September 2026: the attribution payload returns attribution = false for campaigns using age or gender targeting.
Compare the two penalties. The old ATT gate cost you one field on a subset of users. The new demographic gate costs you the entire payload — no campaign ID, no ad group, no keyword, no placement, no timestamp — on every install from any ad group where you set an age or gender parameter. There is no partial state and no downgrade path. You either get the full record or you get a boolean.
0
fields returned when an ad group uses age or gender targeting. Not a coarsened payload — nothing. The trade Apple made in September was one small conditional for one very large one.
That is a genuine strategic change and it has had almost no coverage. Demographic targeting on Apple Ads has always been a blunt instrument, but it was free. It now carries a price denominated in measurement, and the price is total. For most accounts the correct response is to check whether any legacy ad group still carries an age or gender setting from a campaign build nobody has revisited, and to strip it unless the targeting is genuinely load-bearing. Ad groups are cheap; attribution is not.
06What ATT actually gates
The change is a good moment to correct the most common misconception in this category, because it has survived five years of repetition.
The folklore is that when a user denies ATT, a third-party network “falls back” to SKAdNetwork. Apple’s own FAQ answers the question of whether its attribution framework needs the ATT prompt with a single word:
No. AdAttributionKit allows advertising networks to attribute app installations while preserving user privacy, so you don’t need to use the AppTrackingTransparency prompt.
There is no fallback, because there was never a state in which the postback system was not running. A network was always on AdAttributionKit or SKAdNetwork. What an ATT denial removes is the parallel device-identifier path that ran alongside it — the deterministic, user-level layer that let a measurement partner reconcile the coarse postback against a real install.
Apple’s definition of the thing being gated is narrower than most people assume, too. Tracking, in Apple’s wording, is linking user or device data from your app with data collected from other companies’ apps, websites or offline properties for targeted advertising or measurement, or sharing data with data brokers. Apple carves out data linked to third-party data “solely on the user’s device” and not sent off it in an identifying way, plus fraud prevention and security.
Which is exactly why Apple can say of its own system: “AdServices does not engage in tracking as defined under the App Tracking Transparency framework, so it does not need to be listed as a tracking domain.” AdServices uses only Apple’s first-party data and returns no user or device identifier. It was never inside ATT’s scope. The timestamp gate was a policy choice layered on top, and in September Apple removed the layer.
→ FREE 10-POINT AUDIT
Find out what your Apple Ads numbers are about to do in September
We open your Apple Ads account, check every ad group for a legacy age or gender setting that now zeroes your attribution payload, and baseline your reported installs against the window correction so a September step-down doesn’t get misread as a delivery problem. One hour. Senior strategist. No pitch.
Book my free audit →
07What the other side of the asymmetry gets
Set the Apple Ads payload beside what a third-party network receives for the same install, and the gap is not subtle.
| Dimension | Apple Ads via AdServices | Third-party network via SKAN 4 |
|---|
| Granularity | Campaign, ad group, keyword, ad, placement | Source identifier, revealed in 2, 3 or 4 digits by volume |
| Conversion signal | Conversion type, plus your own first-party events | 6-bit fine value (0–63) or coarse none/low/medium/high |
| Timing | Timestamp rounded to the minute | Three windows, 24–144 hour randomised delays |
| Low volume | Full payload regardless | Crowd anonymity strips the conversion value entirely |
Apple describes the postback constraints in its own words. Crowd anonymity “sends less data in the postback when there are fewer conversions, to help prevent anonymized data being matched with a specific user,” and a deliberate delay is imposed between the conversion event and the postback, “reducing the ability to tie a specific postback to a device or user.”
One vintage correction while we are here, because it recurs in vendor decks: SKAdNetwork 5 never shipped. It was announced in 2023 and quietly abandoned; the re-engagement feature it promised arrived inside AdAttributionKit instead. SKAN 4 remains the terminal version. Apple has never published a cancellation notice — it simply stopped mentioning it — so treat any document describing SKAN 5 as live as unreliable on everything else too.
Apple is also unusually candid about the resulting double-count. From its help page: 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.” Apple names the tiebreak — AdAttributionKit provides the official last click among registered ad platforms — but the discrepancy is structural, not a bug, and Apple Ads itself registered with AdAttributionKit in April 2025.
For contrast on the far end, Google’s App Campaigns produce three non-agreeing install counts on iOS by design: modelled conversions subject to delays of up to five days, SKAN reporting where Google states plainly that “we currently do not support SKAN version 4’s coarse conversion values,” and null postbacks redistributed by a machine-learned inferred value distribution, applied only where the attribution credit equals “Won.”
08Vendor documentation has not caught up
As of this writing, Adjust’s Apple Ads attribution page still describes the world as it was in August: detailed responses contain an engagement time, standard responses do not, and the payload type depends on user consent. The page carries no last-updated date and no mention of a September change.
We are not calling that an error. Apple announced nothing, and a vendor updating documentation against a silent revision is doing archaeology. But it is a live and consequential disagreement between two documentation sets, and if you are reconciling numbers this month you should know which one your measurement partner is operating from. Ask them directly rather than reading their help centre.
This is the recurring cost of an undated documentation estate. Apple’s advertising help tree carries no publication dates and no changelogs on any page, so a practitioner cannot age a claim, a vendor cannot detect a revision, and the only durable record of what Apple said last month is whatever somebody wrote down at the time. The AdServices developer changelog is the honourable exception in this territory — and notably, it recorded the new age/gender gate while saying nothing about the removal of the old one.
09What we still don’t know
The gaps here are large and worth naming rather than papering over.
Apple never announced the removal. There is no news post, no changelog entry and no migration note recording that the ATT payload gate is gone. The change is evidenced by a dated reference document, a refreshed sample payload, and a vendor integration note. That is a sound evidentiary chain and it is not the same thing as an announcement. If Apple later says the behaviour is different from what these artefacts imply, the artefacts are what we had.
Nobody knows the ATT-denied share of Apple Ads conversions. Apple has never published it, in any form, so the magnitude of the correction cannot be estimated from public data even in principle.
There is no 2026-window ATT opt-in benchmark. The freshest credible figure remains Adjust’s 35% global rate, published July 15, 2025 on Q2 2025 data, against 34.5% and 34% in the two preceding years. AppsFlyer’s widely quoted 40% and 30% figures differ from each other purely on denominator — the lower one folds in legacy Limit Ad Tracking and restricted users. Every number in circulation predates 2026 data collection, and none of them is a German baseline, which matters because the Bundeskartellamt-ordered prompt redesign lands on a four-month clock running to roughly mid-December 2026 with no before-measurement anyone can point to.
Apple publishes no accuracy interval for anything. No error bars on SKAN modelling, no crowd-anonymity volume thresholds, no statement of what fraction of postbacks arrive null. Every published tier table is vendor-inferred. This is the same absence that makes causal measurement on Apple Ads impossible: better attribution is still not evidence that the install would not have happened anyway.
What none of this changes is the underlying case for the channel. Search placement on the App Store intercepts declared intent, and the attribution that comes back names the query. That was true in August and it is marginally more true now. What changed is that one old excuse for a discrepancy disappeared, a much larger new one appeared in its place, and the only way you would know either is by reading two documents Apple did not tell you it had edited.