git:20260901.b973f20 to git:20260901.49e89d6

12 added, 0 removed. Audit A to A.

---

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.