How App Store search matches metadata

This is the model the openaso server teaches your agent. It is also the part of ASO most tooling gets wrong — worth understanding even if an agent does the work.

One pool, three fields

For each localization, Apple indexes the title (30 characters), the subtitle (30), and the hidden keyword field (100) as one combined word pool. An app can rank for any query assembled from words across those fields: photo in the title plus resize in the keyword field can rank for "resize photo".

Title words weigh most, then subtitle, then keyword field.
Word order and case do not gate what can rank — a phrase kept intact in the title or subtitle is a mild extra relevance signal, nothing more.
Repeating a word in a second field adds nothing. That budget is wasted.
Storefronts may index extra localizations — the US storefront also indexes Spanish (Mexico) — expanding the usable pool beyond one localization's budgets.

Keyword-field mechanics

Commas count toward the 100 characters, and spaces around commas are pure waste: a,b not a, b. A space that is a word's only separator costs the same as the comma replacing it.

Optimize the pool, not phrases

A word's search value is the sum of every phrase it can combine into — photo serves photo editor, photo maker, and take photo at once. But a phrase's value accrues to each of its words, so compare words by marginal unlock and at-risk value, not by summing phrase totals. The coverage tool computes all of this locally for a draft: pool, duplicates, budgets, keyword-field waste, per-phrase coverage, and per-word value when you pass volume-weighted phrases.

coverage → per-phrase verdicts (excerpt)

{
  "phrase": "resize photo",
  "covered": true,
  "via": { "resize": "keywords", "photo": "title" },
  "note": "cross-field combinations tend to rank weaker than same-field phrases — verify with rank"
}

Caveats the tools surface

rank covers the top 200 search results — the public API's cap.
volume returns Apple's real Search Ads popularity when source: "apple"; where Apple floors low-demand keywords or carries no signal, source: "proxy" is a transparent independent estimate with per-signal components.
The live keyword field and subtitle are not exposed by any public API — tools infer around that honestly rather than pretending to read them.
revenue is a modeled order-of-magnitude band from public grossing ranks. Agents are told to report it as an estimate, never as fact.
Google Play is not covered.

Go deeper

This page is the model in one sitting. The ASO reference takes each mechanism apart:

Title & subtitle weighting — the two strongest fields, and when changes take effect
Keyword field mechanics — the 100-character accounting in full
Cross-localization indexing — the extra budget most listings never claim
Search ranking factors — what orders the candidates metadata qualifies
Search popularity & autocomplete — where demand numbers actually come from
Ratings & reviews — per-storefront ratings and the conversion loop
Top charts — velocity ranking and the one public monetization signal
Revenue estimation — the power-law methodology, in the open

Terms

combined word pool — The set of words a storefront indexes for an app across title, subtitle, and keyword field (and any extra indexed localizations) — queries match against the pool, not against fields in isolation.
field weight — The relevance hierarchy among indexed fields: title heaviest, then subtitle, then keyword field.
coverage — Whether a target phrase can be assembled from a draft's word pool, and at what cost — computed per phrase, per word, per field.

markdown mirror: /docs/concepts.md · full corpus: /llms-full.txt