Keywords and screenshots solve different problems. Trace discovery, product-page response and first use before choosing which store element to change.
Find the stage that is constraining the journey
Change keywords when the evidence points to a discovery or relevance problem. Change screenshots when relevant visitors reach the product page but the page does not explain the app well enough. Investigate the product experience when the listing wins an install but the user does not reach the first useful outcome.
These stages interact, but they are not interchangeable. A broader keyword can increase exposure to people who do not need the app. A polished screenshot can improve presentation while leaving weak discovery untouched. An install increase can conceal a poorer activation mix.
Start with a dated store and localization scope. Apple and Google Play expose different fields and reports, so do not copy a procedure from one platform and label it universal. Record the storefront or country, language, traffic source and app version where available.
Trace one store journey from query to first value
Build a trace with seven fields: query or discovery theme, available impression signal, product-page view, visitor source, first screenshot promise, install or open signal, and downstream first-value event. Use stable definitions for the period you compare.
Apple says App Store search uses metadata such as the title, keywords and primary category, alongside customer behavior and other factors. Its product-page guidance says the first screenshots may appear in search results and should communicate the essence of the app. See Apple's discoverability guidance and product-page guidance.
Google Play advises developers to show actual in-app experiences, keep screenshot text restrained, localize text-bearing assets and avoid misleading claims. This is platform guidance, not proof that a particular creative will lift installs. See Google Play's store-listing practices.
Investigate keywords when discovery or relevance is weak
A keyword investigation is appropriate when the app is absent from relevant discovery paths, when observed search language does not match the metadata, or when the traffic reaching the listing is consistently misaligned with the product. Begin with actual product purpose and user language. Do not add popular terms that the app cannot satisfy.
For Apple, review the app name, subtitle, keyword field and category within current platform limits and policies. For Google Play, review the listing text and localization using Play Console's available acquisition reporting. Keep branded, category and problem-led discovery separate where the data allows it.
Do not diagnose weak discovery from installs alone. A listing can have limited exposure but a strong response among those who see it. It can also receive high exposure from a broad source and convert poorly. Use the closest available stage metrics and document what the store report does not reveal.
Investigate screenshots when presentation is the break
Review screenshots when relevant visitors reach the page but do not continue at the expected rate, or when the first visible assets fail to explain the app's value. Read the sequence as a decision story. What problem does the first frame recognize? What outcome does the next frame show? Does the displayed interface support the promise?
Use real interface states. If a benefit needs explanatory text, keep it short and localized. Check how many screenshots are visible without swiping on the devices and store surfaces that matter. Do not assume every visitor sees the complete sequence.
Connect the store promise to first use. If the first screenshot promises a finished budget in minutes but onboarding begins with an unexplained account configuration, the listing and product team share the issue. A new screenshot may set a clearer expectation, but it cannot repair a blocked workflow.
Use the symptom pattern to choose the first intervention
Scroll the table sideways to read every column.
| Observed pattern | First investigation | Why |
|---|---|---|
| App A | Keywords and discovery | Known product-page visitors respond well, but relevant non-brand search exposure appears limited in the available report. |
| App B | Screenshots and message | Relevant search traffic reaches the page, but the first frames show settings before they explain the useful outcome. |
These patterns are deliberately qualitative because stores, reports and app volumes differ. For App A, inspect language and metadata without promising that a keyword edit will change rank. For App B, write one presentation hypothesis and test it using the platform's available experiment method.
If both discovery and presentation are uncertain, choose the intervention that resolves the more consequential uncertainty with the cleanest observation. Changing metadata, screenshots, pricing and onboarding together prevents a useful diagnosis.
Write the decision card before changing the listing
Record the store, localization, source and date range. State the observed symptom without adding a cause. Write the working hypothesis, chosen element, expected platform observation and downstream quality check. Name competing changes such as a release, featuring event or paid campaign.
Choose an observation rule supported by the platform report rather than a universal seven-day or sample-size rule. Low-volume apps may need more time and may still remain inconclusive. Keep downstream activation, payment or retention separate from store conversion.
If necessary data is unavailable, label the gap. A team can still make a bounded editorial improvement because a screenshot is inaccurate or unclear. It should not describe the change as a measured conversion fix until an appropriate comparison supports that claim.
Handle the failure cases without changing everything
If store exposure is weak and there is no reliable query detail, do not manufacture a keyword conclusion. Review metadata against confirmed product purpose, collect the next period consistently and check whether category or localization choices are accurate. The action is evidence collection plus correctness, not a promised ranking change.
If product-page response appears weak but traffic sources are mixed, segment only where the platform allows a defensible comparison. Paid campaigns, featuring and branded search can bring visitors with different expectations. If the sources cannot be separated, state that the observed response belongs to the combined mix.
If installs rise but the first-value event falls, pause the claim that ASO improved customer acquisition. Check whether instrumentation changed, whether the product version is comparable and whether the store promise reaches the first-use flow. If the listing is accurate and the workflow is blocked, route the fix to product design.
If the team has too little traffic for a formal store experiment, use a documented heuristic review to correct factual and clarity problems. Keep it labelled as editorial judgment. A low-volume app still needs an accurate listing, but it may not be able to distinguish small performance differences.
Treat localization as part of the product decision
Do not choose keywords in one language and screenshots in another merely because the source files are easier to reuse. Search language, product terminology and the order in which people understand benefits can differ by market. Review each supported localization against the actual app interface and current product availability.
A localized screenshot should not promise a feature, price or workflow that the localized app does not provide. If the interface remains in another language after installation, make that experience visible enough for the team to evaluate the mismatch. Store conversion is not the only concern; the listing sets an expectation the product must keep.
Record which parts were translated, adapted or left unchanged, and who verified the meaning. Machine translation can support preparation, but it is not evidence of native editorial review. When no qualified review is available, restrict the claim and mark the localization gap before testing performance.
Route the diagnosed problem to the right owner
A discovery finding belongs with metadata and market research. A presentation finding belongs with store creative and product positioning. A promise-to-first-use break needs product and onboarding input. An attribution gap needs measurement work. Assigning every symptom to ASO hides the team that can actually resolve it.
After the change, review the platform result and the first-value cohort separately. A stronger store response with weaker activation may have widened the audience or overpromised the experience. A stable store result with stronger activation may still matter to the business.
Use this diagnosis before ordering new assets or rewriting every field. It gives the next change a reason, an observation plan and a failure condition. For help applying the method to a live listing, see MORE's ASO service.
