# App Store Keyword Research: Build Your First Keyword List

Canonical page: https://www.aso.guide/blog/app-store-keyword-research/
Author: ASO Guide
Published: 2026-09-15

App Store keyword research is the process of finding the searches your app can satisfy and choosing which ones deserve further investigation. The result should be a short list of relevant queries, with evidence and a reason for keeping each one.

Start with the task someone wants to complete. A person searching for a habit tracker may want reminders, a daily checklist, or a history of completed habits. Those expectations overlap, but they can lead to different product choices.

In our [introduction to ASO](https://www.aso.guide/blog/what-is-aso/#the-two-jobs-of-a-listing-discovery-and-conversion), we separated discovery from conversion. Keyword research connects them: a query can bring the right person to your listing only if the listing and product fulfill its promise.

This guide builds a research shortlist for one storefront. You can complete the exercise with a spreadsheet and manual research; a paid tool is optional.

## Define the product before collecting keywords

Use one sentence to set the boundary:

> This app helps people build a consistent daily routine through reminders, a daily checklist, and a history of completed habits.

This is our **fictional habit-tracking app**, used throughout the series. It does not provide guided workouts, automatic sleep measurement, or a calendar for scheduling a whole day. All candidate queries and decisions below are illustrative, not findings from live App Store searches or customer interviews.

Write a short list of supported tasks and missing capabilities. It gives you a way to reject an attractive query before spending time investigating it.

For each candidate, ask: “If someone downloaded the app after searching for this, what would they expect to do first?” If that action is unavailable, remove the query from your current targeting shortlist.

Research the product you can deliver now. Keep future features in a separate backlog.

## Turn user problems into seed terms

Seed terms are starting points for investigation. Generate them from three angles:

- **Task:** what the person wants to do, such as track daily habits.
- **Outcome:** what they want to achieve, such as maintain a routine.
- **Mechanism:** how they expect help, such as reminders or a checklist.

For the example app, these angles suggest `habit tracker`, `daily routine`, `habit reminder`, and `daily checklist`. They are hypotheses about search language. Writing them down does not establish demand.

Keep the complete phrase while researching. “Routine” alone leaves more room for interpretation than “morning routine checklist.” A longer phrase can express a clearer need, but length does not establish that it is popular or easy to rank for.

Apple describes search as supporting everyday language and using several relevance and behavior signals. That makes understanding the intended task useful beyond collecting isolated words. [Apple: App Store search](https://developer.apple.com/app-store/search/).

Aim for a few distinct needs first. Generating fifty near-identical variations can create work without teaching you much about the audience.

## Collect language with a traceable source

Expand the seeds using evidence you can revisit.

### User conversations and feedback

Review support questions, research notes, and conversations with prospective users. Record how people describe the problem before introducing your own feature names.

An interview participant might describe forgetting an evening routine. That can inspire a reminder-related query, but it is not evidence that they typed that phrase into the App Store. Keep those two observations separate.

When copying language into your worksheet, remove personal details. A short paraphrase and an internal reference are usually sufficient.

### Public listings and reviews

Inspect how comparable apps explain the same task. Collect recurring descriptions of needs, frustrations, and expected outcomes.

A phrase appearing in several listings is evidence of shared positioning language. It does not reveal how often people search for it or whether those listings convert well. Reviews offer another perspective, but reviewers are a self-selected group rather than a representative sample of everyone searching.

Record the listing URL, date, and storefront. Never label a phrase found in a description as a verified competitor keyword.

### Search hints and optional advertising reports

If App Store search hints suggest a phrase, record the exact hint and context. Treat it as a candidate to inspect, not a volume measurement. Absence from hints is not enough to prove there is no demand.

If you already use Apple Ads, its search-term reports can provide additional language from searches associated with advertising activity. Apple distinguishes these search terms from the keywords used in campaign management. [Apple Ads: reporting definitions](https://ads.apple.com/app-store/help/reporting/0023-reporting-options-and-definitions).

Keep advertising evidence labeled. A term performing well in a paid campaign does not establish your organic ranking opportunity. You do not need to launch a campaign to complete this first research exercise.

## Inspect results in one named storefront

Choose a research scope before comparing queries. For this exercise, use **the United States storefront, English, on iPhone**. This is an example scope, not a recommendation that every app should target the US first.

Search each promising phrase and record:

1. The exact query, observation date, storefront, device, and research method.
2. The types of apps and other content returned.
3. The main task promised by the app listings you inspect.
4. Whether your app could meet the same expectation with its current features.
5. Ads separately from the organic results you are studying.

Use a consistent inspection window, such as the first five organic app results. That is a manageable research sample, not a special ranking threshold. Record when your method cannot distinguish placements or when fewer results are available.

For `daily routine`, ask whether the observed results emphasize repeating habits, scheduling, or guided routines. Let the observation inform your interpretation; do not decide what the search means from the phrase alone.

Repeat uncertain searches before making a substantial decision. If you switch to a web lookup or another tool, record that change rather than treating the outputs as identical observations.

Keep different storefronts in separate views. Reusing an English phrase in another market is a new hypothesis to validate.

## Separate relevance, demand, and opportunity

These three questions need different evidence.

**Relevance:** can your app satisfy the intended task? Assess this against the actual product and the expectations you observed.

**Demand:** is there evidence that people search this way? Record the source and its limits. User language, search hints, advertising reports, and vendor estimates do not measure the same thing.

**Opportunity:** is there a credible reason to investigate this query for your app? Look for an audience or task you can serve convincingly. A crowded result set may still contain distinct needs, while an unusual phrase may have little demonstrated demand.

Apple Ads provides search-popularity information in its reporting context. Keep the country or region and report definition attached to that observation. [Apple Ads: Insights](https://ads.apple.com/app-store/help/reporting/0091-explore-and-visualize-insights).

Third-party tools may provide their own popularity, volume, or difficulty estimates. Check the provider's definition, data source, scale, and update date. A vendor estimate is not automatically an official Apple metric, and difficulty is not a guarantee of the position your app can reach.

Do not average unrelated scores or convert a popularity value into monthly searches without a documented basis. When evidence is missing, write “unknown.”

### Reject an attractive query when the intent is wrong

Suppose a tool labels `sleep tracker` as having high demand. This is a hypothetical example; no search-volume claim is being made here.

Our habit app can remind someone to follow a bedtime routine, but it cannot measure sleep. If the investigated intent is sleep measurement, reject the query regardless of its apparent popularity.

Keep the rejection and reason. If automatic sleep measurement is added later, the team can reopen the question with a clear record of what changed.

## Build a worksheet you can defend

Create one record per query. Include these fields:

| Field                    | What to record                                                  |
| ------------------------ | --------------------------------------------------------------- |
| Query and intent         | Exact phrase and expected first task                            |
| Feature fit              | Supported capability or specific missing feature                |
| Evidence source          | Listing URL, research note, search observation, or named report |
| Date and scope           | Observation date, storefront, language, device, and method      |
| Demand evidence          | What the source supports; unknown where unmeasured              |
| Uncertainty              | The main assumption still needing a check                       |
| Decision and next action | Investigate, hold, or reject, with a reason                     |

Here is a worked record, deliberately based on the fictional product brief rather than invented customer evidence:

- **Query:** `habit reminder`.
- **Intent hypothesis:** get prompts to complete a recurring habit.
- **Feature fit:** the example app supports reminders.
- **Evidence source:** fictional product brief in this article; no live search observation yet.
- **Prepared:** September 15, 2026. Planned scope: US storefront, English, iPhone.
- **Demand:** unknown.
- **Uncertainty:** whether the observed search results emphasize habit prompts or broader reminder management.
- **Decision:** investigate. Inspect results and compare the expected reminder behavior with the product.

This record supports a next action. It does not yet support a claim that the term should become your primary keyword.

For the other seeds, the initial decisions could be:

| Candidate         | Initial decision and reason                                                                                   |
| ----------------- | ------------------------------------------------------------------------------------------------------------- |
| `habit tracker`   | Investigate: direct product fit; demand and competitive opportunity unverified.                               |
| `daily checklist` | Investigate: checklist capability exists; confirm whether searchers expect recurring habits or general tasks. |
| `daily routine`   | Hold: clarify the intended task before prioritizing.                                                          |
| `sleep tracker`   | Reject for sleep-measurement intent: required capability is absent.                                           |

These are research decisions, not a ready-to-paste metadata recommendation.

## Choose a small shortlist and preserve the rest

Use a simple sequence to prioritize:

1. Remove unsupported intents from the active list.
2. Investigate terms with clear feature fit and traceable evidence first.
3. Hold plausible terms whose main ambiguity could change the decision.
4. Select a small set you can observe consistently and explain individually.

Five to ten queries is a practical starting workload for a solo developer, not an Apple requirement or a performance formula. A smaller justified list is useful if it covers the product's main needs.

Keep rejected and deferred terms in the worksheet. Include what evidence would make you reconsider them. This prevents the same unsupported ideas returning every time someone imports a new keyword export.

Your shortlist is separate from the keyword field in App Store Connect. Research preserves full queries and reasoning; metadata preparation decides how to express the selected positioning within Apple's field constraints. Apple recommends accurate, specific keywords and prohibits irrelevant terms and competing app names in that field. [Apple: choosing keywords](https://developer.apple.com/app-store/search/).

## Finish with a research decision, then examine competitors

Before ending the session, check that you have:

- One documented product boundary and research scope.
- A small active shortlist with a reason for each query.
- Sources and observation dates separated from assumptions.
- Rejected terms with explicit reasons.
- One next action for each important uncertainty.

For an app already available, save a baseline for the selected queries using a consistent observation method. For an unpublished app, keep the research record without inventing ranking or conversion data.

The next question is more specific: **which promises already dominate the results for your shortlisted searches, and what can your app credibly offer?** That becomes the input to competitor analysis, the next article in this series.