Jump to a section
Leave with a decision
Turn an observation into evidence, an action and an owner.
Start with the visual explanation, work through the example, then try the exercise on your app.
An audit finding needs an evidence chain
A screenshot of a problem is the start of the work.
Observation
The opening screenshot names a feature that no longer exists.
Consequence
A new visitor may expect something the product cannot deliver.
Decision
Correct the inaccurate claim before testing new creative.
Verification
Compare the exported asset with the current app and confirm the live listing.
Work through it · fictional example
An audit should end in work, not a report funeral.
A fictional expense app, Receipt Nest, shows “Export your tax report” in its opening screenshot. The released app only exports individual receipts.
Why this changes the decision
This is a confirmed mismatch, not a conversion hypothesis. Record the exact screenshot, app version and the product check. Rewrite the claim to match the supported export. Assign the listing owner and a release date. Keep a copy of the old asset in the audit record.
What to check before calling it a win
After release, verify the corrected asset in the intended store and market. Separately investigate whether export expectations appear in support tickets. Do not invent a low conversion score to make a visible accuracy problem sound more dramatic.
Your turn · a five-minute start
Make one useful decision for your app.
Write one finding using: observation → evidence → consequence → action → owner. Label it Fix, Investigate or Test.
What a useful answer looks like
An unsupported feature claim belongs under Fix. Unavailable conversion data belongs under Investigate. A proposed new benefit headline belongs under Test.
Quick triage: fix, investigate or test?
Begin with one store and market. A public listing review can reveal a confusing screenshot or an unsupported claim, but it cannot establish private conversion performance. Put each finding in the right category before assigning work.
| Finding | What you know | Next action |
|---|---|---|
| A screenshot shows a feature that is no longer available | The listing promise conflicts with the current product | Correct the claim |
| Visitors may not understand the opening screenshot | There is a plausible clarity problem | Prepare a specific creative hypothesis |
| Downloads changed after a release | Several causes may explain the movement | Review comparable traffic and release context |
| Conversion data is unavailable | Performance is unknown | Request the relevant report rather than assign a failing score |
1. Record the baseline before changing anything
Write down the store URL, market, language, app version and observation dates. Save the current listing and screenshots. Record store exposure, listing visits, downloads and the conversion metric available in your console, with its exact definition. Keep iOS and Android separate: similarly named metrics are not necessarily comparable.
Use a recent period with enough traffic to be useful and compare it with a similar period. Note releases, promotions, paid campaigns and seasonal events. A before-and-after change alone does not establish that ASO caused the difference. If you only have the public listing, mark conversion, retention and revenue as unknown.
| Question | Evidence to collect | Decision it supports |
|---|---|---|
| Are relevant people finding the app? | Search visibility and acquisition sources by market | Investigate discovery before redesigning the listing |
| Do visitors choose to download? | Store conversion, segmented where available | Identify a message or creative test |
| Do new users get value? | Activation, retention and revenue from your analytics | Check whether the listing promise matches the product |
Fix it, investigate it or test it?
Do not turn every opinion into an urgent ticket.
Can you demonstrate the defect?
Examples: unreadable copy, an outdated feature or the wrong locale.
Yes → correct it
Assign an owner and acceptance check. You do not need an experiment to remove a false claim.
No → gather evidence
If the problem is unclear, investigate. If you have a specific plausible improvement, define a test and success measure.
2. Check whether the keyword targets match the product
Build a shortlist from the problems your app solves, customer language and relevant competing listings. Separate your own brand from generic needs. For each candidate, record the market, user intent, current ranking if measured, competing apps and the feature that fulfills the promise. Treat third-party demand scores as estimates, not verified search counts.
- Reject terms that describe a feature you do not offer, even if they look popular.
- Inspect the results for each priority query. An unrelated set of apps can signal the wrong intent.
- Choose a focused set of relevant opportunities rather than maximizing the number of tracked keywords.
- Keep dated evidence. A ranking checked in one storefront is not a global ranking.
3. Review the metadata for the correct store
For the App Store, check the app name, subtitle, keyword field and category. Apple limits keywords to 100 characters and advises against repeating words already in the name, subtitle or category. Do not add competitors' names or irrelevant terms. Apple also supports assigning keywords to custom product pages: audit those assignments when used. See Apple's search guidance in the sources below.
For Google Play, review the title, short description and full description as a coherent explanation of the product. Check current requirements in Play Console before submitting. Do not paste an iOS keyword list into customer-facing copy or chase a target keyword density. Every claim should describe something the current app can do.
4. Audit the first impression
Open the listing on a phone and look at the assets at their actual display size. Can a new visitor identify the main use case and understand what they will receive? Record the first screenshot's promise, the evidence shown inside the app, text readability and the order of the remaining screenshots. Compare the message with the query or campaign that brought the visitor.
- Show the relevant product experience, not only decorative claims.
- Check whether the icon is recognizable at a small size.
- Check that screenshots match the current app and supported language.
- Review Google Play preview assets against its current asset requirements.
- Identify one specific uncertainty to test, such as whether a benefit-led opening communicates the use case more clearly.
5. Read reviews as product and messaging evidence
Sample recent positive and negative reviews and record how you selected them. Group recurring themes such as missing features, confusing onboarding or unexpected pricing. Distinguish a misleading listing from a product issue: copy cannot repair a broken feature. Avoid describing a few selected reviews as representative of every customer.
6. Prioritize markets before translating
Choose markets using observed demand, product availability, customer support and business value. Research local search language rather than translating an English keyword list word for word. Have someone fluent in the language check the copy and screenshot text in context. A country with many downloads may still be a poor priority if the product cannot serve those users well.
7. Turn findings into a test plan
Use Apple's Product Page Optimization or Google Play's store listing experiments where the asset and app are eligible. Define a hypothesis, a primary metric and a decision rule before launching. Check the console's current test settings and result guidance. Avoid changing unrelated assets during the experiment, and allow for an inconclusive outcome when traffic is insufficient.
Example hypothesis: a screenshot showing the app's core workflow will help first-time visitors understand it better than a general lifestyle image. Keep the remaining screenshots consistent, measure the test in the native console, and record whether the evidence supports keeping the change. This is an illustrative test, not a claimed client result.
8. Deliver a backlog your team can use
Give each finding an owner, evidence, expected effect, effort and validation method. Prioritize inaccurate claims and broken assets first, then evidence-backed opportunities in important markets. Keep speculative ideas in a separate list until you can investigate them. A numeric audit score is less useful than knowing which change to ship next.
| Finding (illustrative) | Action | Validation |
|---|---|---|
| Screenshots show a retired feature | Replace with current product screens | Check the published listing against the released app |
| First screenshot does not explain the main use case | Test a clearer opening screenshot | Read native experiment results and uncertainty |
| Generic keyword demand is unknown | Research relevant queries in the target market | Save dated observations and label tool estimates |
| Downloads increased during a paid campaign | Separate acquisition sources where possible | Avoid claiming the whole increase as organic lift |
Copy this audit record
- App, store, market, language, version and audit date
- Baseline period, traffic sources and metric definitions
- Finding and supporting evidence, or unknown
- Recommended change and expected user benefit
- Priority, confidence, effort and owner
- Test hypothesis, primary metric and decision rule
- Result, limitations and next review date
Revisit the backlog after releases, meaningful market changes and completed tests. Some apps need continuing experimentation; others need a focused repair and a monitoring routine. Choose the cadence from the evidence and your capacity, rather than assuming every app needs the same monthly package.
Sources and platform guidance
Platform documentation checked 28 September 2026. Verify the applicable console settings before publishing.
Questions and answers
Can I audit an app without paid ASO tools?
Yes. You can review the public listing, compare relevant competitors and use your store consoles. Paid tools can add keyword and competitor estimates. Label anything you cannot measure as unknown.
Is a public teardown the same as a full ASO audit?
No. A public teardown can identify messaging and creative hypotheses. A full audit also needs private acquisition and conversion data, and ideally product outcomes, to prioritize confidently.
How long until an audit improves downloads?
An audit itself changes nothing. Results depend on implementation, demand, traffic and the changes you test. Do not promise a fixed ranking lift or interpret a few days of movement as proof.
Which checklist item should I do first?
Fix inaccurate or broken listing elements, then establish your baseline. Use that evidence to decide whether discovery, conversion or the product experience needs attention first.
Work directly with Gabriel
Find the problem. Leave with the priorities.
Send your listing and the decision you are stuck on. I’ll scope an audit with annotated evidence, prioritized actions and a handover your team can use. A report without a next action is an expensive obituary.
Get Gabriel to audit my listing →Or email gabriel@asoprofessional.com. Bring your app link, market and the decision you need help with.
Want a first opinion? Get a free video teardown of your listing.