App Store Keyword Research

Collect language before scoring it

Begin with first-party material: the product’s features, onboarding copy, reviews, support conversations, and sales or research notes. Add terms from category browsing and relevant competitor listings, but do not assume a competitor’s wording describes your product accurately.

Separate phrases by intent. Someone looking for a general category may be exploring, while someone naming a task or constraint may have a narrower need. This distinction helps prevent a broad, attractive phrase from displacing a more truthful and useful one.

• Core category terms
• Task and outcome terms
• Audience, format, and constraint terms

Evaluate fit and evidence

A keyword tool can provide directional signals, not a promise of demand or placement. Inspect the search results yourself: what kinds of apps appear, what language is repeated, and does your app solve the apparent need? Relevance is a product decision, not a numerical setting.

Prioritize a manageable set. For each candidate, note the intended user, proof in the product, the listing field where it may fit, and the reason it is distinct. This makes it easier to reject terms that sound popular but would create an inaccurate expectation.

Turn research into a backlog

Map selected concepts across title, subtitle or short description, keyword fields where available, long description, and screenshots. Avoid mechanically repeating words. Each field has a reader and a purpose; a readable listing generally communicates more clearly than a dense list of variants.

Revisit the backlog after releases and feedback cycles. New capabilities can earn new vocabulary, and old terms may no longer describe the product. Keep local language and cultural meaning in mind when researching markets beyond the one you know best.

Research the result set

For a promising phrase, capture what the results appear to offer, not merely their names. Look for the implied task, audience, business model, and feature expectations. This is a quick way to spot a term that has a misleading secondary meaning.

Use category browsing to find adjacent language, then return to the product. An adjacent phrase belongs in research only when a user could reasonably find the advertised outcome after installing.

• Search in the target country.
• Note intent mismatches.
• Separate branded terms from generic language.

Maintain a research brief

A short brief can hold the target audience, product proof, candidate themes, exclusions, market, and date. It turns scattered notes into a decision artifact that writers, designers, and product owners can use.

Mark uncertainty plainly. A phrase may need user research, localization review, or a feature decision before it is ready for a public listing. Uncertainty is more useful than a confident but unsupported label.

Use evidence without overstating it

A store listing is one part of a wider product system. When reviewing its performance, begin by defining the question in plain language: what did a shopper see, what did they appear to be trying to do, and what changed in the app or listing at the same time? This framing is more useful than starting with a desired conclusion. It also helps separate an observation about a page from a judgment about the whole product.

Keep raw context with any report: the storefront, language, date range, release state, asset version, query or browsing path, and known campaign or seasonal activity. A number without this context is difficult to interpret later. Qualitative evidence matters too. Review excerpts, support themes, usability notes, and direct customer language can explain why a listing is clear or confusing in a way that an aggregate measure cannot.

Decide in advance what would make you revisit a choice. It might be recurring confusion about a feature, a localization concern, an outdated screenshot, or a product change that makes the present promise inaccurate. Then choose the smallest responsible next step: verify the product, review the live page, revise one message, or conduct further research. Small, documented decisions are easier to learn from than sweeping changes made under pressure.

Do not turn a correlation into a promise. Store presentation, search results, customer needs, and platform behavior can all change. The durable goal of ASO is a truthful, useful product page that helps the right person understand the app. That goal remains valuable even when the available signals are incomplete or ambiguous.

• State the question before opening a dashboard.
• Record market, timing, version, and related changes.
• Read customer language alongside quantitative signals.
• Identify uncertainty instead of filling gaps with assumptions.
• Choose a reversible, supportable next action.
• Review the live listing after publication.

Interview the language behind a query

When possible, listen to people describe the problem before asking them to choose from a keyword list. Ask what they were trying to accomplish, what they tried before, and what words they would use to explain the task to a friend. Their phrasing may reveal the outcome that matters more than category jargon.

Treat interviews and reviews as qualitative evidence, not a vote on exact copy. Look for recurring concepts, then check whether the app truly fulfills them and whether the relevant storefront results share the same intent. Preserve quotations with context so a memorable phrase does not become a misleading generalization.

• Capture the task before the proposed solution.
• Note audience and situation with each phrase.
• Separate a complaint from a desired outcome.
• Check whether the feature is available today.
• Ask localization reviewers about natural wording.
• Retain rejected phrases and the reason.

Frequently asked questions

Further reading

• Apple: Product page metadata
• Google Play: Create and set up your app