tools / volume

volume

read-only

Keyword demand (Apple Search Ads popularity)

How much search demand does this keyword really have?

volume answers the demand question with the only demand number Apple actually publishes: Search Ads Search Popularity, a 5–100 index. When source is "apple", popularity is that number, served through the hosted service's Apple Ads integration — not a reconstruction of it.

Where Apple carries no signal — keywords below its threshold, storefronts outside Apple Ads coverage (~95 of 175 have it), or when no credentialed session is configured — the tool does not pretend. source flips to "proxy" and popularity is an independent estimate blending autocomplete-prefix probing, the rating mass of the top apps, competition depth and keyword-in-title saturation, with every component's value exposed. floored flags terms Apple reports only as “at or below 5”.

Either way you also get competition (how many apps the search surfaces, capped at 200) and medianTopRatings (incumbent strength) — demand means nothing without the other side of the ledger.

worked example

How much demand does “habit tracker” have in the US storefront?

tools/call → volume

{
  "name": "volume",
  "arguments": {
    "keyword": "habit tracker",
    "countries": [
      "US"
    ]
  }
}

volume → structuredContent

{
  "keyword": "habit tracker",
  "storefronts": [
    {
      "country": "US",
      "popularity": 82,
      "source": "proxy",
      "applePopularity": null,
      "floored": false,
      "estimate": 82,
      "label": "Very high",
      "competition": 189,
      "topAppsConsidered": 10,
      "medianTopRatings": 14002,
      "components": { "autocomplete": 100, "ratings": 55, "competition": 95, "titleMatch": 80 },
      "autocompleteProbes": [
        { "prefix": "habit", "weight": 0.5, "matched": true, "position": 1 },
        { "prefix": "habit tr", "weight": 0.3, "matched": true, "position": 1 },
        { "prefix": "habit track", "weight": 0.2, "matched": true, "position": 1 }
      ]
    }
  ]
}

real response, captured 2026-07-29 — trimmed only where marked with …

This response took the estimate path (source: "proxy"), so every input is on the table: the term autocompletes at position 1 from the bare seed (autocomplete: 100), the search is saturated (competition: 95), incumbents are strong.
When Apple's Search Ads carries the term and the hosted Apple Ads session is live, popularity is Apple's own number, source is "apple", and estimate still shows the independent read beside it.
applePopularity always tells the truth about what Apple said: a real value, 5 when floored, null when unavailable.

when to use it

Prioritizing keyword candidates: two phrases both “feel big” — this is the number that settles it, per storefront.
Weighting metadata decisions: feed popularity values into coverage as {phrase, value} weights so character-budget tradeoffs are made on demand, not vibes.
Judging long-tail terms honestly: floored: true tells you Apple sees near-zero demand — before you spend a title on it.
Not a Google Play or web-search volume tool — this is Apple's index for Apple's store, which is exactly why it is decision-grade for ASO.

description — as served to agents

Keyword demand (popularity 0-100) plus competition count, per storefront. popularity is Apple's real Search Ads Search Popularity (5-100) when source is "apple". Apple floors low-demand keywords at 5 and returns nothing for terms below its threshold or in storefronts outside Apple Ads coverage (~95 of 175 storefronts have it); source is then "proxy" and popularity is an independently-derived estimate blending autocomplete-prefix probing, rating mass of top apps, competition depth and keyword-in-title saturation (per-signal values in components). floored marks keywords Apple carries no signal for; applePopularity echoes Apple's raw value (5 when floored, null when unavailable); estimate is always the independent number. Costs one search plus up to 3 autocomplete probes per storefront (throttled ~1/s), plus a cached Apple Ads lookup when configured. competition saturates at 200 (the search API's cap).

input

keyword *

string

App Store search term

countries

string[]

2-letter storefront codes, e.g. ["US", "GB", "JP"]. Each storefront is queried separately; at most 25 per call.(default ["US"])

output

keyword *

string

storefronts *

object[]

country *

string

popularity *

integer

headline demand — Apple's real popularity (source apple) or the estimate (source proxy)

source *

"apple" | "proxy"

apple = real Apple Search Ads popularity; proxy = independent estimate

applePopularity *

integer | null

raw Apple Search Ads popularity 5-100; 5 when floored, null when Apple has no data

floored *

boolean

Apple floored the keyword at 5 (or had no data); popularity fell back to the estimate

estimate *

integer

the independent blended demand estimate (always computed)

label *

"Low" | "Medium" | "High" | "Very high"

competition *

integer

apps surfaced by the search (capped at 200)

topAppsConsidered *

integer

medianTopRatings *

integer

components *

object

per-signal 0-100 scores feeding the estimate

autocomplete *

integer | null

null when no probes ran

ratings *

integer

competition *

integer

titleMatch *

integer

autocompleteProbes *

object[]

prefixes probed against App Store autocomplete, shortest first; failed probes are omitted (the score renormalizes over the rest)

prefix *

string

weight *

number

rank weight of this prefix in the score

matched *

boolean

position *

integer | null

1-based suggestion position; null when not matched

note *

string

pairs with

suggestdiscover candidates before scoring them›coverageturn popularity numbers into character-budget decisions›auditvolume's scoring applied to every discovered candidate at once›

endpoint https://mcp.openaso.ai/mcp · auth Authorization: Bearer <key> · get a key