iOS keyword field optimization: selection and QA

1. Preserve the original candidates and their provenance

Create a research sheet before deleting or rearranging candidates. Give each row a stable identifier. Record the exact term, where it came from, when it was collected, its language or market context, its likely user intent and the supporting product capability. Keep a separate column for your interpretation. A quotation from a customer, a vendor estimate and your own brainstorm are different kinds of evidence.

For example, row K-006 might contain camping, source analyst brainstorm, locale en-AU, intent record a camping experience, and status unvalidated. That is useful research bookkeeping. It must not be rewritten as “customers search camping” unless actual evidence supports that statement.

Preserve excluded rows. A future colleague may suggest navigation again after seeing an attractive demand score. The existing record should explain that the current product cannot provide directions and identify which product owner confirmed that limitation. This saves repeated research and makes the decision revisable if the feature later ships.

Acceptance check: Ask a colleague to select any three candidates and explain where they came from without asking you. If they cannot, the provenance is incomplete.

2. Freeze the exact name and subtitle context

Record the exact strings, locale, app version, draft identifier and approval state used for the keyword decision. Do not write “use the latest title”; that instruction becomes ambiguous as soon as another draft exists.

In this example the name is Trail Notes: Hiking Journal and the subtitle is Keep your walking memories. They are example copy, with approval pending. Apple’s search guidance says not to repeat words already present in the name, subtitle or category. That makes the overlap review dependent on this exact metadata context, not on an abstract app identity.

Suppose the subtitle later changes to remove “walking.” The keyword review may need to be reopened. The correct procedure is to version the new metadata, compare the affected decisions and rerun the allocation review—not publish an old keyword pack beside a new subtitle silently.

Acceptance check: Can the publisher identify a single approved name/subtitle/keyword combination? If several combinations are possible, the pack is not ready.

3. Save the field and the validation evidence

The teaching fragment is diary,logbook: 13 ASCII characters and 13 UTF-8 bytes. The comma counts. This fragment demonstrates documentation; it is not a completed allocation recommendation. There are unresolved candidates and no claim that two terms exhaust the opportunity.

Save the exact proposed string as plain text. Record how it was counted, the checker version or review date and the outcome of final console validation. Keep “local check passed,” “owner approved” and “accepted by the console” as separate states. They answer different questions.

Apple’s search page describes a 100-character allowance, while the platform-version reference describes 100 bytes. The examples in the graphic show why the distinction matters: cafe uses four bytes, precomposed café uses five, and 日記 uses six. These are encoding demonstrations, not recommended keywords. Record both counts, flag a field exceeding 100 UTF-8 bytes conservatively and check the actual console rather than pretending the documentation wording is identical.

Acceptance check: Can someone copy the saved string and reproduce the count? Does the record clearly distinguish draft validation from permission to publish?

4. Make the reasoning specific enough to challenge

Use a decision log rather than a column containing only “good” or “bad.” A useful row has candidate, decision, reason, evidence reference, owner and a condition for reconsideration.

Product capability supports relevance; it does not establish search volume. The “include” decisions remain provisional until the broader research and approval work are complete. Evidence references such as screens/entry-history-v3.png or research row R-014 should point to real artifacts in a real project. Do not manufacture convincing-looking evidence IDs to hide missing work.

Acceptance check: A reviewer should be able to disagree with the reasoning and identify what new evidence could change it.

5. Record scope, responsibility and dates separately

iOS / en-AU describes the intended platform and locale context for the example. It does not prove that every Australian visitor sees this exact localization; actual display and fallback behavior must be checked for the relevant store context. Record the product version and surface as well.

Name who researches, who confirms product truth, who approves the pack, who publishes and who verifies the visible result. In a small team one person may perform several roles, but the responsibilities should still be distinguishable.

Keep research date, approval date, submission date and actual publication date separate. Performance analysis needs the date the change became available, not merely the date the spreadsheet was created. If publication timing is uncertain, record an observed interval rather than inventing a precise timestamp.

Acceptance check: The handover should answer “Who can resolve this question?” and “Who can authorize publication?” without relying on unwritten assumptions.

6. Turn evidence gaps into assigned work

An open question needs a next action and a decision consequence. “More research needed” is insufficient. For camping, write: inspect relevant storefront results for the specified context, collect authentic user language, verify that the app serves the intended job, and bring the findings back to the shortlist review. Assign the task to the ASO lead with a review date.

Define the release gate: the shortlist has been reviewed, the product owner has approved truthful copy, the exact field has passed the applicable checks, and the publisher has the coordinated pack. If a weak candidate remains unresolved, exclude it from the approved version and document the decision rather than filling space by default.