app-store-optimization git:20260901.49e89d6A

Immutable. This exact content is served forever at /api/v1/blob/f74230dc43f79510.

---
name: app-store-optimization
description: Improves visibility and conversion in the App Store and Google Play — metadata, keywords, screenshots, ratings, and the listing experience that turns an impression into an install. Use this to audit or optimize an app listing, plan a launch listing, diagnose poor install conversion, or improve store search visibility.
---

# App store optimization

Two levers, and they are separate problems: being **found**, and being **installed** once found.
Diagnose which is failing before changing anything.

## Being found

The stores index different fields, so the same metadata does not work on both.

- **App name / title** — the single heaviest field. Brand plus the primary descriptive term. Do not
  spend it on brand alone.
- **Subtitle and keyword field** — no repetition across fields; duplicated terms are wasted
  characters, not reinforcement.
- **Long description** — indexed on one store, effectively not on the other. Write it for the store
  that indexes it and for humans on the store that does not.
- **Category** — pick where you can rank, not where you technically belong.

Target terms with real intent. Ranking first for a term nobody searches is a vanity result.

## Being installed

Most visitors decide from the first screenshot and the rating, without scrolling or reading.

- **Screenshots** — the first two carry the decision. Lead with the outcome or the core screen, with
  a caption stating the benefit. Never lead with an onboarding or login screen.
- **Icon** — recognizable at actual size, distinct from category conventions. Test at real scale on
  a device.
- **Rating** — the strongest single conversion factor. Prompt for review after a success moment,
  never on launch or mid-task.
- **Video** — only if it demonstrates something a screenshot cannot. A weak one costs installs.

## Reviews

Respond to negative reviews specifically and without defensiveness, naming the fix and its version
where there is one. Prospects read the responses as much as the complaints, and a pattern of real
answers converts.

Watch review text for recurring themes — it is the cheapest continuous product research available.

## Testing

Change one element at a time and let it run a full weekly cycle; app traffic is strongly
day-of-week seasonal. Attributing a lift to the wrong change is worse than not testing.

## Tooling

The consoles are the source of truth: App Store Connect and Google Play Console, including their
own experiment features — product page optimization and store listing experiments — which test on
real store traffic rather than a simulation.

Keyword and competitor research: AppTweak, Sensor Tower, data.ai, AppFollow, and similar. Treat
their volume estimates as directional; the stores do not publish the underlying numbers.

Review management and reply workflows live in the consoles or in the same tools, and replying is
the part most teams skip.

## Never

- Chase a keyword the app does not deliver on. Installs from a mismatched query become one-star reviews and a worse ranking than you started with.
- Change metadata, screenshots, and the icon in the same release. Nothing that moves afterward can be attributed.
- Solicit ratings from a user mid-task. The prompt lands where frustration is highest and the score reflects that.
- Ignore reviews on the version you just shipped. They are the fastest signal you will get that a release broke something.