# Lesson 57: ASO handover: research, metadata and experiments

Deliver an ASO pack that another person can implement, verify and maintain without guessing.

Prerequisite: Completed research, approved drafts, asset versions and decision records.

Teaching examples are fictional unless explicitly identified as platform definitions.

## Foundations

### Design for the next person's task

The publisher needs exact strings and files; the analyst needs definitions and timing; the product owner needs claim evidence and unresolved decisions. A handover should serve these roles through a clear index rather than one large unstructured folder. Keep working drafts separate from approved release materials.

### Preserve the rationale

Include original candidates, important exclusions and the evidence supporting the approved direction. Without that history, a future editor may undo a deliberate choice or repeat rejected research. Explain where the evidence is strong, where judgment was used and what would change the recommendation.

### Verify receipt through a practical walkthrough

Ask the recipient to locate the approved locale pack, explain a major decision and describe the publication check. Resolve ambiguity before considering the handover complete. A transfer of files is not a transfer of operational understanding. Record the new owner and maintenance triggers.

## Apply the method

### Create a release index that answers practical questions

The first page should tell the recipient what is approved, where it goes and who owns unresolved decisions. Use a manifest with locale, field or asset, version, approval and destination. Link the research archive separately. Avoid ambiguous names such as final-new-final. The publisher should be able to select the exact file without interpreting the designer's folder history. The analyst should be able to identify the exposure date and metric definitions without asking the writer what changed.

### Explain important omissions as carefully as inclusions

The original candidate list and rejected alternatives preserve the decision path. Explain why a high-demand term was excluded, why an asset was deferred and which evidence remains missing. Include the approved name and subtitle beside the keyword field because those decisions interact. Record whether an open question blocks release or belongs to the next research cycle. This prevents a recipient from “fixing” an intentional omission or treating an unfinished idea as approved production content.

### Test the handover with a realistic task

Ask the recipient to prepare one locale from the pack, identify the previous live version and explain a major tradeoff. Then ask how they would verify publication and evaluate the result. Observe where they need clarification and improve the pack. This is an acceptance exercise, not a test of the recipient's memory. Record the new maintenance owner and the next review trigger. Completion means the work can continue reliably after the original author leaves.

## Procedure

1. Create an index organized by research, approved release and measurement.
2. Freeze exact approved strings and asset identifiers.
3. Add decision rationale, open questions and responsibilities.
4. Walk through one publication and one result-review scenario with the recipient.

## Worked example

A publisher finds three folders named final. The handover replaces that ambiguity with a release manifest naming the approved version, locale, files, reviewer and previous live copy. The research archive remains available but is clearly separate from the release pack.

| Recipient question | Handover item | Example |
| --- | --- | --- |
| What do I publish? | Approved manifest | Exact locale strings and asset IDs |
| Why this choice? | Decision rationale | Navigation excluded for product mismatch |
| What is unresolved? | Evidence register | Local term awaiting reviewer |
| How do I verify it? | Release and measurement plan | Storefront capture and metric definition |

A folder can contain every file and still fail these questions. The index and rationale make the files operationally useful. Keep the approved pack distinct from exploration while preserving both. A handover can be complete with open research questions if their owners and release implications are explicit. It cannot be complete when a publisher must guess whether a string is final.

## Your ASO assignment

1. Build a release-pack index for one locale.
2. Include one exclusion rationale and one unresolved dependency.
3. Ask another person to identify what they would publish and how they would verify it.

Write a one-page index for the keyword-field example that includes the original list, approved name and subtitle, exact field, inclusion/exclusion reasons, locale, review date and remaining gaps. Explain each item's purpose to the recipient.

## Handover

### Research archive

Preserve candidates, evidence and exclusion decisions with dates and locale context.

### Approved release

Provide exact strings, file IDs, counts and approvals for each destination.

### Open decisions

Name gaps, next actions and whether they block release.

### Verification

Specify console, live-store and measurement checks with owners.

### Ownership transfer

Record the walkthrough, resolved ambiguities and ongoing maintenance responsibility.

## Check your work

- The recipient can identify exact approved assets without asking.
- Open questions have owners and release implications.
- The previous live state and validation steps are preserved.

## Common mistakes

- Treating a shared folder link as a complete handover.
- Removing rejected candidates and losing the reasons behind the shortlist.

## Knowledge check

What makes a handover complete when a research question remains unanswered?

The gap is explicit, has an owner and next action, and states whether it blocks release. Completion does not require pretending every uncertainty is resolved; it requires making the next decision executable.

## 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