Jump to a section
Leave with a decision
Make approve, reject and investigate decisions with a reason attached.
Start with the visual explanation, work through the example, then try the exercise on your app.
Turn a phrase into a defensible keyword candidate
The list gets shorter as evidence gets stronger.
Job
What is the person trying to do? Example: track shared household expenses.
Language
Collect how that audience describes the job: split bills, shared budget.
Relevance
Keep phrases the actual app can satisfy. Remove attractive but misleading terms.
Priority
Use store and market evidence to decide what to investigate and test first.
Work through it · fictional example
Reject the attractive keyword your app cannot serve.
Trail Notes records completed walks. Its candidate list includes hiking journal, route planner and walking diary. These are illustrative candidates, not measured demand estimates.
Why this changes the decision
Hiking journal names the supported job. Route planner implies a capability the app lacks. Walking diary sounds relevant, but the team still needs to inspect how the intended audience uses the phrase and what competing results promise. Store the locale, source, observed intent and decision beside each term.
What to check before calling it a win
Review actual search results and user language for the selected store and market. Revisit decisions when the product or audience changes. Do not treat a plausible phrase, website search volume or a tool’s popularity estimate as guaranteed app-store demand.
Your turn · a five-minute start
Make one useful decision for your app.
Pick five candidates. For each, write the user’s expected job, the matching feature and an approve/reject/investigate decision.
What a useful answer looks like
Reject a term when its central promise is unsupported. Investigate when the promise may fit but the evidence is incomplete.
Start with the job your app performs
Write the problem the app solves in the words a potential user would use before knowing its name. Gather candidates from support questions, interviews, reviews and relevant competing listings. Record where each candidate came from. A keyword map is a decision record, not a spreadsheet made impressive by its size. A term only belongs on the shortlist if the current product can fulfill its promise.
Inspect intent in the target storefront
Look at the apps shown for a candidate query in the market you care about. Are they solving the same problem? If the results are dominated by a different use case, investigate before using the term. Keep brand and generic searches separate. Your own brand can behave very differently from a category term. Do not assume that a term popular on the web has the same demand inside either store.
Same word family. Different intent.
Fictional expense app: keyword similarity does not equal product fit.
“Invoice generator”
A freelancer wants to create an invoice for a client. A shared-bills app cannot fulfil that job.
“Split household bills”
Housemates want to record expenses and divide what they owe. This matches the product.
Label your evidence
Record the store, language, market, observation date, current position if measured, competing results and business relevance. If a provider supplies demand or difficulty scores, keep the provider name and label those values as estimates. Missing data is not zero demand. A public competitor listing also does not expose its private keyword field or conversion performance.
Prioritize before writing
Reject irrelevant candidates first. Then compare business relevance, evidence of demand and the practical strength of competing apps. A focused term serving a valuable use case can be more useful than a broad aspirational phrase. Keep the rationale: why this term, for this app, in this market, now? Revisit assumptions when product capabilities or search results change.
Map terms into readable metadata
Draft the name and supporting fields as customer-facing communication. Use the keyword-field builder for formatting and overlap checks on iOS, not for automated strategy. It cannot tell you which candidate will convert. After publishing, record the exact changes and review performance alongside source mix and other releases. A position change alone does not prove incremental business value.
A keyword shortlist you can actually use
Illustrative example: Trail Notes is a private hiking journal with notes and photos. Before comparing popularity estimates, decide whether each candidate describes the released product and the job a visitor wants to do.
| Candidate | Intent | Decision and reason |
|---|---|---|
| hiking journal | Record walks and memories | Keep: the core product does this |
| walking diary | Keep a personal record | Investigate: relevant language, then inspect the target-store results |
| offline navigation | Get directions without a connection | Reject: navigation is not part of this fictional product |
| hiking weather | Check conditions before a walk | Reject unless the app genuinely provides weather information |
This is a relevance exercise, not a ranking prediction. Next add the source, market and observation date for each surviving term. Inspect the actual results, then use any research provider estimates with their labels intact.
The common mistake: treating the export as the strategy
A long export only tells you what was collected. The useful handover explains what to target, what to reject and where the selected terms belong. Give the copywriter a short decision record, not an unexplained spreadsheet.
Your next steps
- Create columns for query, intent, relevance, source, date, market and next action.
- Reject at least one attractive but irrelevant term.
- Draft a shortlist with a written reason for every inclusion.
- Map the shortlist to fields and keep a copy of the old listing.
Sources and platform guidance
Platform documentation checked 29 September 2026. Verify the applicable console settings before publishing.
Questions and answers
Can this be done without a paid tool?
You can begin with user language and direct storefront observations. Paid data may broaden coverage, but it does not replace relevance checks.
Can I discover a competitor’s hidden keyword field?
Not from the public product page. Keep public observations separate from estimates or data the developer explicitly shares.
Work directly with Gabriel
Turn the keyword list into an actual listing.
Work directly with me on relevant keyword choices, your app name and subtitle, and screenshot priorities. You get drafts to review and reasons for the choices. The spreadsheet can finally stop pretending it is the deliverable.
Review my keyword shortlist →Or email gabriel@asoprofessional.com. Bring your app link, market and the decision you need help with.
Want a first opinion? Get a free video teardown of your listing.