3.App store keyword research and discoverability

In this chapter: how to check whether people can find your app, what each store console can and cannot tell you about search, and why a keyword rank is not the same thing as demand for that keyword. You will finish with a source checklist for your own app.

The problem

Keyword tools make discoverability feel precise. You see that your app is ranked 7th for "budget planner" and 41st for "expense tracker", with a difficulty score and a popularity score next to each. It is tempting to rewrite your subtitle every week to push those numbers.

Three problems hide behind the precision:

1. A rank is a position, not traffic. Ranking 3rd for a phrase almost nobody types brings almost nobody.
2. Third-party popularity scores are estimates. They are useful for comparing terms with each other; they are not counts of searches, and different tools disagree.
3. Search is only one way people find apps. Browse lists, referrals from websites, links shared in communities, ads and brand searches (people who already know your name) all bring visitors. If most of your visitors come from somewhere other than generic search, keyword work is not your first lever.

What is going on

What the stores say about search

Apple says App Store search results depend on text relevance — matches for your title, subtitle, keywords and primary category — and on user behavior, such as downloads and ratings and reviews [S02]. You control the first part directly and the second only indirectly.

On the App Store your text fields are limited: the app name and the subtitle can each be up to 30 characters, and the keyword field holds 100 characters in total [S01]. Apple's guidelines ask for keywords that describe the app accurately and forbid packing metadata with trademarks, other apps' names or irrelevant phrases [S06].

On Google Play there is no separate keyword field. The app name (up to 30 characters), short description (up to 80) and full description (up to 4,000) carry your text, and Google warns that repetitive or irrelevant keywords can get an app suspended [S13]. Play's metadata policy rules out ranking claims such as "#1" or "App of the year" in the title, icon and developer name, and lists them among common violations in other listing text and images [S14].

What the consoles can show you

This is the most useful part of the chapter, because the consoles already hold better evidence than most keyword tools.

App Store Connect. The acquisition view splits impressions, product page views and downloads by source type: App Store search, App Store browse, app referrer, web referrer and others, filterable by territory and device [S23]. Note that App Store search includes views and downloads from ads shown in search results [S23] — if you run Apple Ads, part of your "search" traffic is paid.

Play Console. The store listing report can be filtered by traffic source, country, language and search term — the term a user searched before visiting your listing [S12]. Watch the definitions closely:

• Google Play search covers visitors who searched for your app's name or a closely associated brand [S12]. It measures people who already know you.
• Google Play explore covers people who found you while browsing — home pages, suggestions, charts — or by searching for a category of apps, such as "racing game" [S12]. Generic keyword discovery on Play shows up here, not under "search".

That single definition changes how you read a Play chart. A rise in "search" may mean more people heard your name elsewhere; a fall in "explore" may be a visibility problem for category terms.

Rank versus demand

Keep three different questions apart:

A good discoverability decision needs at least two of the three. A high rank for a low-demand term is a vanity number. High demand where you rank 60th is an opportunity only if your app really matches what those people want.

Custom pages widen your options

Both stores let you show a different page to different visitors. Apple's custom product pages (up to 70) can have their own screenshots, promotional text and app previews, their own keywords, and unique URLs [S03]. Google Play's custom store listings (up to 50) can target countries, search keywords, a unique URL or a Google Ads campaign [S11]. For discoverability this means you do not have to bend your main listing towards one audience to test a second one.

Worked example

Fictional example · E3 · Fernpath · tags: android, discoverability

Situation. Fernpath is an Android app for planning hikes with offline maps, made by a solo developer. It is available in several English-speaking countries, with most installs from the UK. A keyword tool shows Fernpath dropping from 5th to 14th for "offline hiking map" in the UK over three weeks. The developer plans to rewrite the app name to "Fernpath: Offline Hiking Map" and the short description around the same phrase.

Observations (Play Console, UK, last 28 days vs the 28 days before):

• Store listing visitors: roughly flat (−3%).
• By traffic source: Google Play search (brand) slightly up; Google Play explore down about 9%.
• Search-term dimension: "offline hiking map" brought 4% of visitors in both periods. The largest non-brand terms were "walking routes uk" and "trail planner", which together brought about three times as many visitors, and both held steady.
• Click-through rate on the listing: unchanged within its normal weekly range.

Hypotheses.

1. The rank drop for "offline hiking map" costs meaningful traffic. Weak: the term brings a small, unchanged share of visitors.
2. Explore traffic fell because of seasonality (autumn in the UK). Plausible; the developer's data from last year shows a similar dip from September.
3. A competitor's update pushed Fernpath down for several category terms at once. Possible; explore fell, but the two biggest category terms held.

What would change the decision. If "walking routes uk" or "trail planner" lost rank and visitors, that would be a real visibility problem for terms that matter to this app.

Decision: No rename. Test one thing. Keep the app name, which is also what brand searchers type. Create one Play custom store listing targeted at the search keyword "offline hiking map" [S11], whose first screenshot shows offline map download — a feature the app has. Its numbers show how people searching that term respond to that page; they cannot be compared fairly with the default listing, because the audiences differ. To judge the screenshot itself, run a store listing experiment on that custom listing — Play allows experiments on custom listings as well as the default one [S10] — with the current screenshot as control. Check explore traffic against last year's seasonal pattern at the same time. The rename is off the table unless explore keeps falling after the seasonal window and the main category terms lose visitors.

Do this now

1. Split your visitors by source for one market and the last 28 days: App Store Connect source types [S23], or Play traffic sources [S12]. Write down the share of each.
2. If generic search/explore is under about a third of your visitors, note that keyword work is probably not your first lever; check chapter 4 (conversion) and chapter 9 (distribution) first. This cut-off is a prioritizing habit, not a rule from either store.
3. List your top 10 non-brand terms from Play's search-term dimension, or your best estimate on iOS (search terms from your own search ads if you run any; otherwise a keyword tool, labelled "estimate").
4. For each term, fill three columns: demand (source), your rank (market, date), conversion if known.
5. Check your metadata for rule problems: competitor names or irrelevant terms in keywords [S06], ranking claims on Play [S14], repeated keywords [S13].
6. Pick at most one change — a keyword swap, a subtitle test on a custom page, or a Play custom listing — and write its test brief (chapter 4).

Don't change anything yet when…

• The term you lost rank for brings a small share of your visitors, or you do not know its share.
• The only evidence is a third-party popularity score.
• Brand search is your largest source; your name is working — renaming risks it.
• The drop coincides with a known seasonal pattern or a store-wide change you cannot see into.
• You changed metadata in the last few weeks and the stores have not settled yet; measure the last change before making the next.
• The only way to rank for the term would be to describe a feature the app does not have.

Worksheet

Discoverability source checklist — sources, their definitions, what each can and cannot tell you, and a demand/visibility/conversion grid for your top terms.

Optional: Next Move can compare your public listing with one competitor's for a chosen market and goal. It reads public listing data only (on the stores it supports) — text, visuals, ratings and a sample of reviews; it does not see your search terms or traffic sources, so it will not claim a keyword is worth ranking for.

Sources

• S01 — Creating your product page (Apple Developer) — https://developer.apple.com/app-store/product-page/
• S02 — App Store search (Apple Developer) — https://developer.apple.com/app-store/search/
• S03 — Custom product pages (Apple Developer) — https://developer.apple.com/app-store/custom-product-pages/
• S06 — App Review Guidelines (Apple Developer) — https://developer.apple.com/app-store/review/guidelines/
• S10 — Store listing experiments, Play Console Help — https://support.google.com/googleplay/android-developer/answer/12053285
• S11 — Custom store listings, Play Console Help — https://support.google.com/googleplay/android-developer/answer/9867158
• S12 — Acquisition reports, Play Console Help — https://support.google.com/googleplay/android-developer/answer/9859173
• S13 — Create and set up your app, Play Console Help — https://support.google.com/googleplay/android-developer/answer/9859152
• S14 — Metadata policy, Play Console Help — https://support.google.com/googleplay/android-developer/answer/9898842
• S23 — Acquisition, App Store Connect Analytics (Apple Developer Help) — https://developer.apple.com/help/app-store-connect-analytics/acquisition/acquisition/