Your campaign is running, the dashboard shows a conversion rate, and the next question is whether that number is any good.
That question is visible in the search traffic. Pulled from Google Trends on 20 August 2026, twelve-month worldwide window: around the seed "apple search ads", the top related query is "apple search ads api", and "apple search ads cr" is flagged Breakout. Interest in the plain seed fell over the same window, from an opening eight-week average of 50 to a closing average of 32 on Trends' 0–100 relative index. Those are relative-interest figures, not volumes — Trends publishes no volumes. The pattern is people who have stopped asking what Apple Ads is and started asking what its numbers mean.
Two answers before anything else. Apple defines two conversion rates that share a denominator and differ in the numerator, so "CR" is ambiguous before any comparison starts. And both are computed inside your Apple Ads account, from taps and installs Apple attributed to your ads. There is no public dataset from which CR can be derived — not for a competitor, and not for you.
The funnel, and the fields behind it
Every rate Apple reports is a ratio of two counts it recorded for your ads. The counts are impressions, taps and installs; everything else is division.
| Apple's UI calls it | The ratio | Field in Campaign Management API 5 | Field in Platform API 1.0 |
|---|---|---|---|
| TTR | taps ÷ impressions | ttr | ttr |
| CR (tap-through) | tap-attributed installs ÷ taps | tapInstallRate | tapInstallRate |
| CR (total) | total installs ÷ taps | totalInstallRate | totalInstallRate |
| Average CPT | spend ÷ taps | avgCPT | cpt |
| Average CPA (tap-through) | spend ÷ tap-attributed installs | tapInstallCPI | tapInstallCPI |
| Average CPA (total) | spend ÷ total installs | totalAvgCPI | totalAvgCPI |
Field names are from Apple's SpendRow reference for API 5 and its AppsMetrics reference for the Platform API. The two install counts behind those rates are attributed on different clocks:
| Install type | Counted when | Window |
|---|---|---|
| Tap-through | someone tapped your ad, then installed | 30 days |
| View-through | someone saw your ad, did not tap, then installed | 1 day |
Apple's glossary also carries a general attribution-window entry of 30 days; the one-day figure belongs specifically to view-through installs.
Two conversion rates, one denominator
Read the second and third rows of that first table together. Tap-through CR divides tap-attributed installs by taps. Total CR divides all installs — tap-through plus view-through — by the same taps.
The numerator changes. The denominator does not.
So total CR counts installs from people who never touched the ad, over a denominator of people who did. It is installs-per-tap where some of the installs did not come from a tap. Two consequences follow from the arithmetic alone: total CR is never lower than tap-through CR for the same period, and nothing in the definition holds it below 100%, because the numerator can count events the denominator never counted.
Neither number is wrong. They answer different questions, and a figure labelled only "CR" does not say which one it answers.
What the API renamed, and what happens if you miss it
Anyone wiring up the API meets a second version of the same ambiguity. Apple's SpendRow reference for API 5 lists tapInstallRate and notes, of that field: "Prior to API 5, this was the conversionRate field." The same page carries the same note for tapInstalls (was installs), tapInstallCPI (was avgCPA), tapNewDownloads and tapRedownloads.
No reporting response in API 5 carries a field named conversionRate, and none carries one named avgCPA. Every metric in every report row comes from SpendRow or its dated sibling ExtendedSpendRow, and neither name appears in either.
That is a quiet failure mode rather than a loud one. A client written against the older names still parses a v5 response perfectly — the keys are absent, and whatever your code does with a missing number, it does without complaint. If you maintain an Apple Ads integration, grep it for conversionRate and avgCPA before you trust a dashboard built on it.
The naming settled rather than reverted. The Apple Ads Platform API, whose changelog records version 1.0 as released in August 2026, uses no such field either: its AppsMetrics object keeps tapInstallRate and totalInstallRate, and shortens avgCPT and avgCPM to cpt and cpm. Both changelogs carry the same notice — the Platform API supersedes Campaign Management API 5, which will be sunset on 26 January 2027.
If you are building now, that date is the one to design around, and a port is a port rather than a base-URL swap. The new API documents RateLimit-Limit, RateLimit-Remaining and RateLimit-Reset headers on every response, where the older API's rate-limit guidance describes exponential backoff and no headers at all.
Why nobody can compute this for another app
Every reporting call in Campaign Management API 5 carries a required X-AP-Context: orgId=<orgId> header. The API answers for one organisation: yours. The Platform API narrows the same header further, to X-AP-Context: adAccountId=<id>, and requires it on every ad-account-scoped endpoint. There is no parameter on either API that points a report at somebody else.
The one place Apple gives you a number computed against other advertisers is the Impression Share report. It returns your share of the searches on a term in the countries and regions you are running in, and a rank against other apps expressed as 1 to 5, or greater than 5. Apple's own two descriptions of the granularity disagree: the glossary describes an exact percentage up to 90% with everything above that shown as a 91–100% band, while the CustomReportResponse reference describes a daily aggregation in deciles. Check what your own report returns rather than trusting either page. Either way, both figures are about your placement. Neither is another advertiser's spend, bid, or conversion rate.
Apple does publish an ad repository — required in the EU under Article 39 of the Digital Services Act, and reachable at adrepository.apple.com. Apple's DSA legal page describes it as containing information about Apple-delivered advertising on the App Store in European Union countries and regions. That is a disclosure of ads that ran, not of how they performed. It shows advertising; it does not show results.
And Apple's nearest thing to a volume signal, search popularity, is an indicator from 1 to 5. It is relative, it lives inside the ads account, and it is not a volume. Nothing on this site reports search volume for the same reason: it does not exist publicly.
So any product claiming to show a rival's Apple Search Ads bids, budget, creatives or CR is not reading it from Apple, because Apple does not publish it.
The benchmark tables, and why there is none here
Search for an ASA conversion rate benchmark and you will find several, each a different figure. Two of the most visible were fetched on 20 August 2026: AppTweak's Apple Ads benchmarks page and Adapty's. Both state a sample — thousands of apps and tens of thousands of campaigns in one case, over a million ad groups in the other — and both state the countries and categories covered. Neither states which conversion rate it aggregated.
Given the section above, that omission decides the number. Two accounts with identical performance report different CRs depending on whether the tap-through or the total column was summed, and the gap between them is exactly the view-through installs. A blended figure across placements moves it again: Apple's glossary lists four places an ad can run — the Today tab, the Search tab, the top of search results, and relevant product pages — and a single averaged CR mixes all four.
This post publishes no benchmark conversion rate, because there is no source for one that survives those two questions. The comparison that does work is your account against itself: same placement, same countries, same CR column, different weeks.
What this post cannot tell you
- Not whether your CR is good. No public figure exists to compare it against, and the published ones do not say what they measured.
- Not what a competitor pays, bids, or converts at. Reporting is scoped to your own organisation and Apple publishes nothing else.
- Not your own numbers. No CPT, CPA or spend figure for any account appears in this post or anywhere on this site outside your own connected account.
- Not whether an attributed install would have happened anyway. Apple's glossary defines last-touch attribution as crediting the ad last seen or tapped before the download. That records a sequence. It does not establish that the ad caused the install, and a high CR on your own brand term is the clearest case of the difference.
- Not which CR your third-party dashboard shows. Ask the vendor which field it reads. There are two, and the answer is not obvious from the label.
The work
Appstro's Apple Search Ads targets scores keywords from public data only — search-term traffic weighted by how badly you place organically today, since an ad slot renders above organic #1 — and marks a term as a negative keyword when you do not rank for it and at least 60% of its top ten belongs to a different genre. Its competition score is a relative proxy for how contested a term is, never a price, and the CSV it exports has no bid column, because a bid inferred from public data would be invented.
When you want the real numbers, the connected Apple Ads account reads them from your own account, with the .p8 key held encrypted server-side and never returned to the browser. That page and the keyword scorer are deliberately separate: one shows a bill, the other shows an inference, and the difference between them is the subject of this entire post.