ASO keyword research is the process of finding the terms people type into an app store, deciding which of them your app can honestly claim, and placing those terms where each store can use them. The outcome you are buying is qualified organic discovery — people who find the app, install it, and stay — not a higher position on a term nobody valuable searches.
Settle one thing early: the same keyword logic does not transfer cleanly between Apple and Google. Research overlaps almost entirely, but the stores expose different metadata and reward different writing. A term you can place quietly on iOS may be one you cannot justify writing into an Android listing.
This guide covers where keywords live on each store, what makes one worth targeting, a six-step workflow, how many terms to keep, and the mistakes that cost the most.
What Are ASO Keywords?
ASO keywords are the terms your app store metadata is written to be relevant for. They help the App Store and Google Play match your app to what someone is searching for. The comparison to web SEO is useful mainly for where it breaks down.
A web page can be long, link out, earn links back, and cover many topics. An app store listing is short, closed, and judged partly by what happens after the tap. Mobile app keywords work inside tight character limits, against a page that sells in one screen, with install and retention behavior feeding back into how the store treats you. There is far less room to hedge.
That produces a chain worth stating plainly, since most keyword mistakes are a break somewhere in it.
| Keyword signal | What it should describe |
|---|---|
| Relevance | What the app genuinely does, in the words users apply to it |
| Visibility | Where the store can surface you for terms you are relevant to |
| Conversion | Whether the listing convinces the people that visibility brings |
| Organic installs | Whether those visitors become users worth having |
Break relevance and the rest degrades in order: you may still win visibility, but conversion falls, and the installs you get behave worse than the ones you had.
Where Keywords Matter on the App Store and Google Play
Both stores read your metadata; they just give you different surfaces to write it into. This is the distinction most guides gesture at and few make operational.
Apple App Store Metadata
Apple gives you a name and subtitle that users read, plus a keyword field they never see. Apple’s documentation puts the name and subtitle at 30 characters each and the keyword field at 100 bytes, with each keyword longer than two characters. It also notes that your app is already searchable by app name and company name, so repeating those in the field wastes the space (Apple, app information reference). Names of other apps or companies are not permitted.
Two consequences. The field is measured in bytes, not characters, so accented and non-Latin terms consume more room than they appear to. And because it is invisible, app store keywords placed there carry no conversion cost — which makes it tempting to fill, and easy to fill badly.
Google Play Metadata
Google Play has no hidden equivalent. Every term lives in the title, the short description, or the long description — 30, 80, and 4,000 characters respectively in Google’s store listing guidance. Google also asks you not to repeat the short description inside the full description, and to avoid repetition of words. A block of words in a list, it says plainly, is not helpful to users (Google, best practices for your store listing).
So on Android, keyword choice and conversion copy are the same decision. Anything you want indexed has to survive contact with a reader. We cover the Android side in depth in our guide to Google Play keywords.
| Metadata surface | Store | Discovery role | Writer implication |
|---|---|---|---|
| App name / title | Both | Highest-weight visible text | Brand plus one earned descriptive term; no keyword stacking |
| Subtitle | App Store | Second visible line under the name | One sharp benefit that also carries a term |
| Keyword field | App Store | Invisible input to search | Byte-budgeted; no name or company duplication; no competitor names |
| Short description | Google Play | Above-the-fold pitch | A value proposition, not a keyword list |
| Long description | Google Play | Full listing body | Natural language; no word blocks; never repeat the short description |
What Makes an ASO Keyword Worth Targeting?
A keyword earns a place when it is relevant, reachable, and likely to bring users who stay. Five inputs decide that, and only one of them is the number most teams lead with.
- Search demand — whether anyone looks for it. Treat vendor volume figures as relative indicators, not counts.
- Product relevance — whether the app genuinely does the thing. This is a yes or no, not a slider.
- Ranking feasibility — whether this app, at its current strength, can plausibly appear against who is there.
- Current position and competitor landscape — where you sit today, and whether the term is contested by far larger apps.
- Expected downstream quality — what happens after the install for someone who arrived on this term.
Priority = relevance × feasible visibility × expected user quality
Figure 1. Written as a multiplication so that one weak factor cannot be averaged away.
This is a decision aid, not a ranking model. Apply your own scale, validated against your own results — there is no defensible universal weighting, and anyone publishing one is guessing. Apple makes a compatible point about paid search: rather than bidding on an exhaustive list of every possible keyword, focus on the most relevant ones (Apple Ads, keyword best practices). The same instinct applies to organic metadata, where the space is even tighter.
Two of the five deserve more weight than they get. Ranking feasibility is where teams flatter themselves: a term is attainable not because it is relevant, but because the apps ranking for it are within reach of yours. Look at who occupies the results, not at a difficulty score alone.
Expected downstream quality is the input tool-led guides omit, because no keyword database holds it. It comes from your own cohorts: do people arriving on this kind of term activate, convert, and stay at rates you are happy with? A term that brings volume and churn is a liability dressed as a win, and no ranking report will show it as one.
How to Do ASO Keyword Research: A 6-Step Workflow
Start with your product and audience, widen into a candidate list from store suggestions, competitor metadata, reviews, and tools, then validate before you commit. The order matters more than the tooling.
Figure 2. Steps 1–2 widen the list; steps 3–4 narrow it; steps 5–6 commit and check.
1. Start With the Product, Audience, and Jobs to Be Done
Write down what the app does, who it is for, and the situation someone is in when they need it. Then collect the language that already exists around it: features, benefits, category vocabulary, reviews, support tickets, and onboarding questions.
Reviews and support tickets are the most useful and least used inputs. They contain the problem in the customer’s own words, before a marketer reworded it, and they surface use cases you never designed for.
2. Build a Broad Candidate List
Collect widely now and judge later. Store autocomplete shows how real queries complete as people type. Competitor titles and subtitles show which terms rival teams spend their most constrained fields on. Reviews and category vocabulary add phrasing no tool suggests, and ASO tools contribute demand and difficulty estimates. Apple Search Ads is a legitimate discovery input. Apple recommends turning Search Match on in an ad group dedicated to keyword discovery, then moving the high-performing search terms into campaigns focused on brand, competitor, or category keywords (Apple Ads, keyword best practices).
Note the boundary. Paid search terms tell you what language converts when you pay for the impression. They do not prove your organic metadata can earn that impression. Use paid data to find candidates, not to skip validating them.
3. Separate Brand, Category, Feature, and Problem Keywords
A flat list hides the fact that these four groups need different decisions. Splitting them turns a spreadsheet into a portfolio.
| Group | Example shape | What it is for | The decision it needs |
|---|---|---|---|
| Brand | Your app name and misspellings | Defending traffic already yours | Confirm you own it; escalate if a competitor bids |
| Category | The generic name of what you are | Baseline discovery | Judge feasibility honestly; usually contested by bigger apps |
| Feature | A capability you ship | Reaching people who know what they want | Check the feature is prominent, not buried |
| Problem | The situation the user is in | Reaching people who cannot name the solution | Verify the store results actually match your app |
4. Audit Current Metadata and Competitor Gaps
Before adding anything, look at what you have. Record current ranks for shortlisted terms, read your own metadata as a stranger would, and note which terms you rank for without having tried.
Then look outward. Which terms do close competitors carry in their titles and subtitles? Which concepts does the category word one way and your listing another? The gap worth finding is rarely a term everyone missed. It is usually one the category words differently than your product team does.
5. Score and Select a Focused Portfolio
Score the shortlist, then cut it. An example — a language-learning app with three candidates:
| Candidate | Relevance | Feasibility | Decision | Reasoning |
|---|---|---|---|---|
| learn spanish | High | Low | Defer | Accurate and central, but the results are held by apps with far greater brand strength; revisit as the app grows |
| spanish for travel | High | Moderate | Accept | A real use case the app is built around, narrower than the category term and genuinely winnable |
| spanish translator | None | High | Reject | The app teaches; it does not translate text on demand. Demand does not rescue a promise the product will not keep |
The rejected row is the one worth keeping. A term with strong demand and no honest claim behind it is not a near miss to revisit later. It is a decision you should be able to point to when someone asks why the obvious keyword is missing.
6. Deploy, Measure, and Iterate
Use a protocol rather than an impulse: baseline, hypothesis, one controlled change set, evaluation. Record current metadata and performance before touching anything, and write down what you expect to change and why. Then ship one coherent set of edits. Rewriting the title, the subtitle, and the screenshots in the same release makes the result unreadable.
Track rank alongside conversion and installs, never rank alone. A term that lifts impressions while store conversion falls has made the listing less relevant, not more. For the paid side of the same audience, use your measurement partner’s documented cohort methodology (AppsFlyer, cohort and retention dashboard). On timing: review when the evidence has matured and when something has actually changed — a release, a competitor rewrite, a seasonal shift — rather than on a fixed monthly cadence chosen for tidiness.
How Many ASO Keywords Should You Target?
There is no universal number. The answer depends on the app, the store, the locale, how much metadata surface you have, and how much evidence you have that a term is working. The task is to prioritize, not to maximize count.
Hold two lists. The core portfolio is the small set your metadata is built around — terms you would defend in a review meeting, each with a reason and a place. The research backlog is everything else: deferred candidates, seasonal ideas, terms you are not strong enough for yet.
The core portfolio is deliberately small because your metadata is small. Thirty characters of title cannot serve twelve priorities, and a subtitle that tries to carry four terms carries none of them convincingly. The backlog can be as long as you like, because nothing in it costs you anything until you promote it. Keeping rejected terms with their reasons matters just as much: it means the next cycle starts from a decision record rather than a blank page, and it stops the team arguing over the same bad candidate every quarter. That constraint is easier to accept when organic discovery is one input among several rather than the whole plan, which is how it sits inside a broader mobile user acquisition system.
Common ASO Keyword Research Mistakes
- Choosing volume over relevance. The most common and most expensive error. A high-demand term the app does not deliver on converts badly and brings users who leave.
- Copying competitor metadata literally. Their terms reflect their product, their strength, and their bets — including the bad ones. Read competitors for vocabulary, not for instructions.
- Treating iOS and Google Play identically. A term that sits harmlessly in an invisible keyword field may be one you cannot write into an Android title at all.
- Ignoring localization. Translated keywords are not researched keywords. The term a category is known by is often a borrowed English word in one market and a native compound in another.
- Replacing winning metadata without a baseline. If you did not record what performance looked like before, you cannot tell whether the change helped, and you cannot roll back with confidence.
- Keyword stuffing. Google states directly that a block of words in a list is not helpful to users. On Android it also damages the conversion you worked to earn.
- Measuring rank without conversion or user quality. Position is an input, not an outcome. Rank up with retention down is a worse listing, not a better one.
- Treating paid search terms as proof of organic fit. What converts when you pay for the impression may not be a term your metadata can earn.
Most of these share a root: a gap between what the listing promises and what the product delivers. Keeping metadata, screenshots, and creative messaging describing the same product is what closes it — the store-side version of why great media buying can’t fix an unprepared product.
ASO Keyword Research Checklist
- Record baseline metadata, current ranks, and store conversion before changing anything.
- Build themes from product, audience, reviews, support tickets, and category language.
- Widen the candidate list with autocomplete, competitor metadata, tools, and paid search discovery.
- Classify candidates as brand, category, feature, or problem terms.
- Validate each shortlisted term against the real store results before scoring it.
- Score on relevance, feasible visibility, and expected user quality; log every rejection with its reason.
- Place terms per platform — App Store keyword field and subtitle, Google Play copy — and check limits.
- Ship one controlled change set, then review rank, conversion, and retention together.
- Review when evidence has matured or conditions changed, not on a fixed calendar cadence.
Conclusion: Research Is a Decision Process, Not a List
Keyword research is recurring work that connects store visibility to acquisition quality. Terms shift, competitors rewrite their listings, and your product changes what it can honestly claim. The teams that compound results keep a decision record, reject candidates on purpose, and read rank next to conversion and retention — because the number that matters is not the position, it is whether paying users, not installs, came out the other end.
