# Lesson 10: How to build an ASO keyword seed list

Assemble candidate language from several sources without mistaking a long list for a strategy.

Prerequisite: Customer-language notes, search observations and review themes.

Teaching examples are fictional unless explicitly identified as platform definitions.

## Foundations

### Collect by source and meaning

Seed collection is discovery work. Include product capabilities, user jobs, problems, outcomes, category language and customer expressions. Keep the source beside each candidate. Separate terms you observed from terms you brainstormed or generated with assistance. An attractive phrase deserves investigation, but its existence in a spreadsheet does not establish demand or relevance.

### Normalize without erasing intent

Trim formatting and remove exact duplicates while preserving meaningful variants. “Walking diary” and “walk tracker” may overlap linguistically but imply different expectations. Record language and storefront before normalization. Do not aggressively merge singulars, plurals or spelling variants based on an assumed indexing rule; preserve the research evidence and make allocation decisions later.

### Make exclusions part of the library

An exclusion list prevents rejected ideas from returning every meeting. Record why a term is unsuitable: unsupported feature, wrong audience, ambiguous meaning or unresolved brand concern. Rejection is a strategic result, not wasted research. Keep the original candidate and rationale so new product capabilities can trigger a deliberate reconsideration rather than a forgotten assumption.

## Apply the method

### Collect concepts before forcing field formatting

A seed library is a research inventory, not the final iOS keyword field. Keep natural phrases such as walking diary, hiking memories and private journal intact while you investigate meaning. Record the source type: interview, support conversation, product terminology, competitor listing or an analyst hypothesis. Different sources establish different things. A customer phrase can support language relevance; it does not independently establish demand. Keeping concepts intact makes it easier to understand intent before later splitting or allocating terms for a specific store.

### Normalize without destroying useful distinctions

Create a normalized comparison form for case, whitespace and obvious duplicates, but preserve the original phrase. Do not merge different meanings merely because their strings look similar. “Trail log” and “training log” may serve distinct jobs. Store the locale with each candidate and avoid combining translated words into one language-neutral row. If two sources support the same concept, link both to a canonical research entry instead of copying rows that inflate the apparent breadth of the library. Version the library so rejected ideas can be traced later.

### Use status as a decision history

Give each candidate a status such as new, needs intent review, shortlisted or rejected. A rejection should include a reason and the evidence that would justify reopening it. “Unsupported navigation function” is useful; “bad keyword” is not. Assign the next research action to uncertain candidates. This turns a large list into a manageable queue. Before handing it to a copywriter, distinguish researched candidates from brainstorms, because attractive unverified terms often reappear in drafts when status is unclear.

## Procedure

1. Create columns for candidate, locale, source, intent, supporting feature and status.
2. Import customer language and product terminology before broad brainstorming.
3. Deduplicate formatting variants while preserving meaningful query differences.
4. Add explicit exclusions and questions for unresolved candidates.

## Worked example

Trail Notes collects “walk diary,” “hiking journal,” “route planner” and “private travel memories.” The route-planner candidate stays in the sheet with an exclusion because planning is unsupported. Private travel memories is marked unvalidated language rather than discarded merely for lacking a score. The library now records what the team knows, what it suspects and what it has ruled out.

| Candidate | Origin | Status |
| --- | --- | --- |
| Walking diary | Interview language | Inspect local results |
| Hiking memories | Product benefit workshop | Validate user wording |
| Offline navigation | Competitor observation | Reject: unsupported function |

A good seed library can be small. Thirty traceable entries with clear next actions are more useful than several thousand terms collected without context. In the example, walking diary has language evidence but still needs search inspection. Hiking memories has product relevance but weaker customer-language evidence. Offline navigation is retained in the rejection history to prevent repeated discussion. None of these statuses claims search volume, difficulty or a guaranteed ranking opportunity.

## Your ASO assignment

1. Build a 30-candidate library from at least three source types.
2. Mark ten candidates with specific product evidence.
3. Document five exclusions or unresolved questions.

You receive 2,000 tool-exported terms without locale or provenance. Design a triage process that first restores context, then deduplicates and reviews intent. Explain why immediately pasting the highest-score terms into metadata would skip necessary decisions.

## Handover

### Original candidates

Preserve the unedited phrase, locale and source reference so the origin is recoverable.

### Normalized index

Link duplicate expressions to a canonical concept while retaining meaningful variants and sources.

### Decision status

Label researched, unresearched and rejected entries explicitly, with reasons and review dates.

### Research queue

Assign a concrete next check to each unresolved candidate, such as local result inspection or product verification.

### Handoff boundary

State that the library is a research input and identify the separate approved shortlist for drafting.

## Check your work

- Every candidate has a source or is labeled as a brainstorm.
- The sheet preserves market and language context.
- Excluded terms include reasons that another analyst can evaluate.

## Common mistakes

- Presenting AI-generated phrases as observed customer searches.
- Deleting rejected terms without retaining the rationale.

## Knowledge check

Your tool suggests a high-volume term for a feature the app lacks. What should the library record?

Record the tool suggestion and its date, then mark the term excluded for current product mismatch. Do not allow a demand estimate to overrule product truth. If the feature later ships, reopen the candidate with fresh research and a new decision date.

## Sources

- [Apple — App Store search](https://developer.apple.com/app-store/search/) — Search presentation, relevant keywords and metadata guidance.
- [Google Play — Metadata policy](https://support.google.com/googleplay/android-developer/answer/9898842?hl=en) — Accurate, relevant metadata and prohibited presentation.

Platform references reviewed 29 September 2026.
www.asoagency.com