App Store keyword research starts with the jobs your app can actually do, then checks how people describe those jobs and what appears in the store for those searches. A small team can keep that work in one spreadsheet instead of chasing a large keyword list with unexplained scores.
These 10 steps focus on Apple’s App Store, starting with one territory and language. They take you from candidate phrases to a metadata draft and a repeatable review. Google Play needs its own research and field rules.
The examples use a fictional interval-timer app that supports custom workout rounds, rest periods, audible alerts, and saved routines. They illustrate decisions, not measured search demand, rankings, or download results.
1. Choose one market and record a baseline
Write down the store, target territory, metadata localization, device, current app version, and research date before collecting keywords. For example: Apple App Store, United States, English (U.S.), iPhone. Store territory and language are separate details; keep both in the record.
Start with a market your app genuinely supports. A translated listing cannot fix missing language support, unavailable services, or an unsuitable payment workflow. Apple explains how localized metadata is displayed, including what happens when a user’s language has no matching localization. Avoid assuming an extra localization gives every country extra keyword coverage.
For a live app, save the current metadata and export or record comparable search-source metrics before changing it. In App Store Connect, open the app, choose Analytics, then Acquisition → Sources. Record the date range, territory and device filters alongside unique impressions and downloads.
Apple’s acquisition documentation says App Store search includes views and downloads from search ads. Note whether ads are running. For a prelaunch app, label the baseline “not available”; competitor data is not your own starting performance.
2. Turn app features into search jobs
List the app’s working features, then translate each into a task someone might search for. Keep the feature and candidate phrase together so the team can explain why a keyword belongs.
| Working feature in the fictional app | User’s task | Candidate phrase to investigate |
|---|---|---|
| Custom work and rest periods | Time repeated exercise rounds | interval timer |
| Configurable short workout rounds | Run a specific interval routine | tabata timer |
| Audible round-change alerts | Follow a workout without watching the screen | workout timer with sound |
| Saved exercise routines | Reuse a training sequence | custom workout timer |
These are seed ideas, not confirmed App Store suggestions. Check that each implied use works before retaining it. The phrase “running coach,” for example, would misrepresent a timer that provides no coaching.
Apple lists text relevance and user behavior among its App Store search considerations. It does not publish a formula that lets a team turn one keyword placement into a guaranteed rank.
The useful principle behind matching content to search intent also applies here: the destination must fulfill the searcher’s task. Validate that task in the App Store rather than importing Google’s results as the answer.
3. Collect the words customers actually use
Read your app’s reviews and support questions, then a manageable sample of reviews for apps serving the same task. Look for recurring descriptions of the problem, desired outcome, and missing capability. Include complaints as well as praise.
A request for audio cues might suggest investigating “timer with sound.” A complaint about subscriptions might reveal a pricing objection rather than a new feature keyword. Neither establishes how many people search for that phrase.
Keep a source link or internal reference, date, and a short paraphrase. Do not paste private support conversations or customer identifiers into a shared research sheet. If the app has no users yet, label competitor-review evidence separately.
Copy this CSV header into a spreadsheet. The single row is an illustrative seed from the fictional app, not a customer quotation:
keyword_id,territory,locale,phrase,source_type,source_reference,observed_on,feature_fit,evidence_note
K01,US,en-US,interval timer,product feature,custom round settings,,confirmed,seed only; no demand measurement
Add real observations as new rows and retain their provenance. A phrase repeated in reviews is useful vocabulary; it is not automatically a popular search term. This ledger helps the next person distinguish what customers said, what the team inferred, and what still needs store validation.
4. Explore suggestions inside the App Store
On a device using the target App Store territory, enter each seed gradually and record any relevant suggestions that appear. Try a few meaningful prefixes and alternative wordings. Keep the original phrase rather than replacing it with the team’s preferred spelling.
For each observation, record:
- The typed prefix and exact suggested phrase.
- Territory, device, language settings, and observation date.
- Whether the phrase fits a working feature.
- A screenshot reference if the team needs to reproduce the observation.
If “interval” returns a useful phrase, investigate it in the next step. If it returns nothing useful, write “no relevant suggestion observed,” not “zero searches.”
Suggestions are a discovery source, not a measured monthly volume or an ordered list of the easiest keywords. Their presence does not prove your app can compete, and their absence does not prove nobody searches.
Google autocomplete can provide additional wording ideas for web research, but it is a different search surface. Do not label a Google suggestion as an App Store observation. At this stage, the deliverable is a dated list of phrases worth checking, with unsupported or irrelevant phrases removed.
5. Inspect the apps competing for each query
Search each promising phrase in the target store and inspect the results. Start with five relevant organic apps as a manageable research sample, expanding it if the results mix different tasks. Five is a workload choice, not an Apple requirement.
Separate advertised placements from organic results. Save the observation date and context so a future check can distinguish a changed result from a changed market or device.
| What to record | Decision it helps answer |
|---|---|
| App URL or ID and observed organic position | Which apps appeared in this particular check? |
| Name, subtitle, and visible feature language | What task does the result communicate? |
| Screenshots and description | Does it actually solve the same problem? |
| Relevant review themes and product limitations | What expectations must our app meet? |
| Differences from our app | Can we honestly satisfy this search? |
For “interval timer,” a set of exercise timers suggests a different task from a result dominated by employee time tracking. Investigate mismatches before changing metadata.
A competitor’s title shows visible wording, not its hidden keyword field or the reason it ranks. Review totals alone are also insufficient to predict your chances.
Use rival brands to identify research subjects. Apple’s keyword rules do not allow other app or company names in your keyword list. Do not turn competitor research into a copied brand target.
6. Expand only with useful modifiers
Now refine the promising seeds around an audience, setting, feature, or routine. The aim is to identify a more precise task, not generate every possible word combination.
For the fictional timer, compare these possibilities:
| Candidate | Decision before store validation |
|---|---|
| tabata timer | Investigate if the app can configure the required work/rest routine. |
| custom interval timer | Investigate because configurable rounds are a working feature. |
| interval timer for swimming | Hold until the actual device and workout experience support that setting. |
| interval timer with music | Reject if the app only provides alert sounds, without the implied music functionality. |
| interval timer for teams | Reject if there is no shared or synchronized group workflow. |
These are product-fit decisions, not search-volume findings. Recheck the retained phrases in store suggestions and results; a longer phrase is not automatically easier to rank for.
Keep different tasks separate even when they share words. “Workout timer” and “work hours tracker” should not become one target merely because both involve time.
For another language, repeat this exercise using local customer vocabulary and store observations. Translating an English list can help start research, but it does not establish that people in the new market use those phrases or want the same features.
7. Prioritize by relevance and evidence
Apply a relevance gate before comparing popularity or competition. Reject misleading features, prohibited terms, and phrases serving a different task. A large apparent opportunity cannot repair a mismatch.
For the remaining candidates, use three decisions:
- Investigate: product fit is confirmed, but store evidence is missing.
- Test in metadata: product fit and observed store intent support a specific field change.
- Hold: the evidence conflicts, the capability is uncertain, or another term serves the task more clearly.
Record demand separately. If you have no trustworthy App Store demand metric for that territory, mark it unknown. Do not manufacture a volume, turn an unknown into zero, or import Google search volume. Screpy’s guide to separating keyword data sources explains the broader data-quality principle; its website-search metrics do not measure App Store searches.
Use a decision sheet like this. All three rows are illustrative and deliberately lack observed store evidence:
keyword_id,phrase,fit,store_evidence,demand,decision,reason,owner
K01,interval timer,confirmed,not collected,unknown,investigate,core task; validate result set,app marketer
K02,tabata timer,conditional,not collected,unknown,hold,verify routine support before targeting,product owner
K03,interval timer with music,unsupported,not collected,unknown,reject,music functionality not provided,product owner
Retain source references from the discovery ledger using the same keyword ID. After validation, replace “not collected” with the observation reference and explain any decision change.
Choose a small set that fits the available metadata and a clear user promise. There is no need to fill a quota of target phrases or adopt another company’s universal difficulty cutoff.
8. Map the shortlist to App Store metadata
Give each selected idea a purpose in the listing. The name should identify the app clearly; the subtitle can explain another useful aspect. Use the keyword field for relevant terms that add coverage without repeating existing words.
Apple allows up to 30 characters for the app name and subtitle. Here is a compact fictional draft, using only the timer’s stated capabilities:
| Field | Illustrative text | Count |
|---|---|---|
| Name | Roundly: Interval Timer | 23 characters |
| Subtitle | Custom workout rounds | 21 characters |
| Keywords | exercise,rest,alerts,training | 29 ASCII characters / 29 bytes |
The keyword field is intentionally not full. Do not add unsupported phrases just to consume space. The example’s brand is fictional, not a claim that the name is available.
There is an important documentation detail: Apple’s public search guidance describes a 100-character keyword limit, while its App Store Connect field reference specifies up to 100 bytes and says each keyword must be greater than two characters. Characters and bytes can differ in localized text. The ASCII example fits both descriptions; validate your actual localized string in App Store Connect rather than assuming that every 100-character string will fit.
Before submission:
- Separate terms with commas, without spaces after the commas. Apple permits spaces inside multiword phrases.
- Remove words already present in the name, subtitle or category, and avoid duplicating singular/plural forms.
- Exclude other app/company names, unauthorized trademarks, irrelevant terms and filler.
- Keep descriptions readable instead of adding unnecessary keywords.
Promotional text does not affect App Store search ranking. Do not use it as overflow keyword storage. Nor should the draft imply that every possible combination of words will rank: placement is a relevance signal, not a promise of visibility.
9. Save the change set before submitting
Turn the keyword decision into a small release record. Save the old and proposed field values, the supported phrases being added, and what would justify keeping the change.
Copy and fill this template:
App / version:
Territory / metadata localization:
Owner:
Keyword IDs and supporting observation references:
Previous name / subtitle / keyword field:
Proposed name / subtitle / keyword field:
Hypothesis:
Submission date:
Date updated metadata was verified live:
Baseline window and filters:
Follow-up window and filters:
Ads / screenshots / pricing / product changes during the period:
Keep, revise or revert decision and reason:
A useful hypothesis is specific: “Clarifying custom exercise rounds should make this listing a better match for the validated timer queries.” It is not “all rankings will improve.”
Check the app’s current state and field permissions before submitting. Apple’s app information reference explains when the name can be edited; its product-page guidance ties subtitle updates to a new version submission. Follow the applicable review workflow instead of promising an instant metadata change.
Verify the updated listing is actually live in the intended localization, and measure from that date. Keep changes limited enough to interpret, while recording unavoidable product releases or marketing activity. Changing the keywords, screenshots, price and acquisition campaign together makes attribution much harder.
10. Review search results and downloads together
Repeat the store checks for the same target phrases, territory, and device. Compare those observations with the listing’s acquisition data using the same filters as the baseline. A rank observation answers where the app appeared in that check; a source report answers how acquisition performed across that source.
Apple defines the acquisition conversion rate as total downloads divided by unique impressions. Total downloads can include first-time downloads and redownloads. Do not silently replace that denominator with product page views.
For example, 12 total downloads from 400 unique impressions gives a 3% conversion rate. This is illustrative arithmetic, not a result from the fictional app. A movement of one or two downloads in a small sample needs more context before the team treats it as a meaningful improvement.
| Observation | Next investigation |
|---|---|
| Relevant positions improve, but search impressions barely change | Check sample size, territory coverage and whether those queries generate enough exposure. |
| Search impressions rise, but conversion falls | Recheck query fit and whether visible listing assets explain the promised task. |
| Downloads rise while paid search activity increases | Separate the campaign change from the metadata hypothesis; do not call the increase purely organic. |
| Results look unchanged | Verify the correct metadata is live, then reconsider phrase selection and the strength of the evidence. |
The App Store search source includes ads. Its totals do not identify which individual phrase caused a download. Separate rank observations, paid campaign reporting, and source-level acquisition rather than joining them into an invented per-keyword result.
Use comparable windows that suit the app’s traffic and weekday pattern, allowing more observation time when counts are sparse. A before-and-after comparison remains observational: seasonality, competitors and product changes can also affect it.
Finish by updating each keyword’s decision and reason in the same sheet. Keep well-supported targets, revise misleading wording, and return uncertain phrases to research. The useful output is a defensible next change, not a longer list.