# Lesson 16: ASO metadata strategy: allocate keywords across fields

Translate a keyword portfolio into readable field roles for each store.

Prerequisite: The prioritized portfolio and current field requirements.

Teaching examples are fictional unless explicitly identified as platform definitions.

## Foundations

### Assign the communication job first

The name establishes identity. Supporting text qualifies the promise and explains value. A hidden keyword field, where available, serves a different function from visible copy. Plan these roles before counting characters. Field limits constrain the draft, but maximizing capacity is not itself the objective. A shorter clear title can be better communication than a full but awkward string.

### Treat stores as different systems

Do not carry an iOS hidden keyword-field workflow into Google Play, which has a different listing structure. Keep separate drafts and rule checks for each store. Use current official documentation for supported fields and submission constraints. Observed ranking behavior is not a license to present undocumented algorithm weights as facts or to overstuff visible prose.

### Protect meaning during editing

Every compression changes emphasis. Review whether the shortened copy still names the product and sets the right expectation. Avoid deleting qualifiers that prevent a misleading promise. Check the draft aloud and at small display sizes, then confirm that the selected language connects to the opening screenshots. Metadata and creative should reinforce the same product identity.

## Apply the method

### Give each field a communication job

Start with the visible promise: what should a stranger understand from the name and supporting text? Then decide how remaining fields support discovery and explanation on the selected store. Treat Apple and Google as separate production systems rather than copying one field plan into both. Space limits, visibility and platform guidance differ. The keyword map should guide the writing, but natural language and product truth still govern the final strings. A mathematically efficient allocation that reads like a list of unrelated search terms is a weak listing.

### Review concept coverage and duplication together

Build a matrix of concepts against proposed fields. On iOS, follow Apple's guidance against repeating words already covered in the name or subtitle in the keyword field. Do not expand that into an unsupported universal rule about every kind of repetition on every platform. Google Play descriptions must remain useful prose; a normal repeated product term is different from keyword stuffing. Record the reason for each allocation and check the full set after edits, because moving a word into a visible field can make a previous keyword-field entry redundant.

### Count exact strings after editorial decisions

Keep one source of truth for the approved strings, including punctuation and locale. Recount after every revision and validate in the console before submission. For multilingual text, code points, bytes and visible characters can differ. A tool count is preparation rather than a guarantee of platform acceptance. Never trim a field by deleting a necessary qualification or changing a truthful promise into a broader unsupported one. If the draft does not fit, revise the communication plan rather than compressing it until it becomes unreadable.

## Procedure

1. Assign a primary purpose to each supported field in the selected store.
2. Place core identity before optional supporting language.
3. Check counts and overlap with the tools, then edit for meaning.
4. Review the full listing as a single promise and log the rejected alternatives.

## Worked example

Trail Notes drafts “Trail Notes: Hiking Journal” as a recognizable identity and uses supporting copy to explain private memories. Adding “maps navigation routes tracker” would broaden coverage in appearance but distort the product. The final allocation deliberately leaves some candidates unused. The keyword map records why: space was assigned to truthful relevance and clarity rather than maximal phrase inclusion.

| Concept | Visible role | Supporting decision |
| --- | --- | --- |
| Hiking journal | Name communicates the core task | Avoid redundant iOS keyword entry |
| Walking memories | Subtitle explains the benefit | Keep language understandable |
| Diary and logbook | Candidate keyword concepts | Review relevance and final format |

The matrix separates meaning from formatting. It does not claim that every combination will be indexed or ranked. After approving the visible strings, reassess remaining concepts and any overlaps according to the current store guidance. The final handover should include the exact proposed strings and the reasoning behind their roles. A colleague should not need to reconstruct the strategy from a character-count screenshot.

## Your ASO assignment

1. Create separate iOS and Play field-role tables.
2. Draft one coherent set of fields for your primary market.
3. Record three wording tradeoffs and their reasons.

A reviewer adds journal to the iOS name after the keyword field was approved. Identify the dependent checks and explain why reviewing only the edited field can leave avoidable duplication elsewhere.

## Handover

### Field plan

Name the store, locale and communication role of each field before giving the final strings.

### Approved strings

Preserve exact text, punctuation and version so counts and reviews refer to the same proposal.

### Coverage matrix

Show where important concepts appear and why intentional exclusions or repetitions remain.

### Validation

Record field counts, current platform reference and unresolved console checks.

### Change implications

Explain which other fields need rechecking if a visible name or subtitle changes.

## Check your work

- Each field serves a clear communication or discovery role.
- The draft preserves necessary qualifiers.
- Excluded candidates remain documented instead of being forced into copy.

## Common mistakes

- Reusing the same field strategy across stores without checking their structures.
- Confusing every repeated word with a proven ranking penalty.

## Knowledge check

A long qualifier uses valuable space but prevents a false expectation. Remove it?

Not just to fit another keyword. First find a clearer formulation that preserves truth. If no concise alternative works, retain the qualifier or narrow the claim. Relevance gains are not worthwhile when the resulting promise misrepresents the product.

## Sources

- [Apple — Platform version information](https://developer.apple.com/help/app-store-connect/reference/app-information/platform-version-information/) — Field definitions and submission constraints, including keyword bytes.
- [Google Play — Create and set up your app](https://support.google.com/googleplay/android-developer/answer/9859152?hl=en) — Listing fields, language and text limits.

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