An ASO audit is a documented investigation of an app’s discovery, listing message and available performance evidence. Its output should be prioritised findings with evidence, limitations, owners and acceptance criteria—not just annotated screenshots or a generic score.
Your deliverable: Produce an evidence-backed audit with prioritised findings and a clear implementation handoff.
The first frame shows settings, while the headline promises a quick start.
INTERPRETATION
The opening may not demonstrate the promised ease of use.
MISSING EVIDENCE
Visitor context and a reliable baseline for the relevant audience.
PROPOSED ACTION
Develop an opening that shows the first successful action.
EVALUATION
Review comprehension and plan a suitable creative experiment.
Illustrative finding for a fictional app. The interpretation is a hypothesis, not a measured cause.
01
Define the question and comparison period.
“Why did installs fall?” is too broad to answer from a listing screenshot. Establish when the change began, which market and source are affected, and what else changed. Preserve the relevant reports and listing versions. If no performance data is available, state that the review is based on public material.
This boundary determines what the audit can conclude. A public review can identify confusing language; it cannot establish the cause of a private account’s acquisition decline.
02
Inspect the product promise.
Write down who the listing appears to address, what it promises and what evidence it offers. Compare the promise with an available product workflow. Record unsupported claims as accuracy findings and unclear messaging as hypotheses to investigate.
The InvoiceNest example below shows how to preserve that distinction in a finding with an owner and acceptance criteria.
03
Separate discovery from listing persuasion.
Review the relevance of the target search language, then inspect how the listing explains the product to the arriving audience. A broad keyword can create unsuitable traffic. A narrow, relevant audience can still encounter an unclear screenshot sequence.
Use keyword research for the discovery question and screenshot strategy for the visual argument. Keep the two analyses connected without assuming they are the same issue.
04
Write findings in a repeatable format.
For each important observation, record the evidence, interpretation, proposed action, confidence and owner. Include what would weaken your interpretation. If your only evidence is that a competitor uses a different design, the finding needs more work.
The example panel illustrates this structure. It deliberately distinguishes a visible mismatch from an unproven explanation of performance. That distinction prevents an opinion from turning into a misleading promise.
05
Prioritise and hand off.
Correct accuracy issues, identify necessary dependencies and group uncertain ideas into a test backlog. Consider importance, effort and the strength of evidence rather than pretending every recommendation has a precise expected uplift. Agree which team can act on each item.
The checklist helps organise the review. The consulting process shows how a diagnosis becomes an implementation handoff.
06
Make the review reproducible.
Save the store, country, date, screenshots and source report definitions alongside the findings. Another reviewer should be able to understand what you saw and why the recommendation followed. Keep the original baseline when later revisions are added.
If you want the investigation carried out with you, see the ASO audit service. Its scope can be tailored to the question rather than forcing every app through the same presentation.
WORKED EXAMPLE / FICTIONAL APP
An invoice app that promises more than it shows
InvoiceNest is a fictional freelancer invoicing app. Its title suggests simple invoicing, but its first screenshot is a reporting dashboard. Reviews mention confusion about sending the first invoice. You have access to the listing and public reviews, but no acquisition reports or product event data. The audit must make that evidence boundary visible.
How to reason through it
Capture the current store, locale, device context and date before writing recommendations. For each finding, separate observation, interpretation and proposed action. “The first frame shows a dashboard” is observable. “Visitors think setup is complicated” is an interpretation that needs evidence. A disciplined audit preserves this distinction even when the proposed redesign seems obvious.
The next practical move
Inspect the actual first-invoice workflow with the product team. If it is genuinely straightforward, brief a sequence showing creation, preview and sending. If it is difficult, raise a product issue rather than hiding it behind a promise of simplicity. Ask for segmented reports to decide whether the creative issue is also a commercially important bottleneck. Deliver a short priority list with owners and acceptance criteria.
Swipe horizontally to compare the decision map →
An invoice app that promises more than it shows: illustrative decision map
Decision area
What to inspect
What it means for the work
Observed
Opening frame shows reporting rather than invoicing
Save the dated screenshot
Hypothesised
A new freelancer may not understand the first action
Run a comprehension review with relevant users
Recommended
Show the supported creation-to-send workflow
Brief creative after product verification
The trap to avoid
Do not turn every personal preference into an urgent finding. A colour you dislike, an unfamiliar illustration style, or a competitor feature is not evidence of a user problem. Prioritise accuracy, comprehension and relevant measurable obstacles before aesthetic opinions.
When the situation gets more complicated
Separate a public listing review from a full performance audit. The former can inspect copy, visuals and positioning; it cannot establish private conversion, retention or revenue outcomes. Include a limitations section in the deliverable and identify which recommendations remain provisional until analytics or product access is available. This makes the audit more credible and easier to implement.
FROM METHOD TO DELIVERABLE
Turn findings into a usable issue register
Severity describes the consequence of a problem; confidence describes how well you understand it. Keep them separate. These editorial categories are a working rubric, not a statistical model or a prediction of revenue impact.
Swipe horizontally to read the complete example →
Editorial triage rubric: priority is not an estimated uplift.
Priority category
Example finding
Release or investigation action
Correct before promotion
Listing advertises a feature unavailable in the current product
Verify the claim; correct it and confirm the published version
Investigate promptly
A comparable audience appears to complete fewer defined actions
Check definitions and concurrent changes before proposing a cause
Plan an experiment or review
Opening screenshot may obscure the primary workflow
Document the mechanism and choose suitable evidence collection
Optional refinement
Reviewer prefers another decorative colour
Defer unless it addresses a documented user problem
A completed finding with acceptance criteria
Finding INV-01: the first screenshot of fictional InvoiceNest shows a reporting dashboard although the listing promises simple invoice creation. Evidence: a dated capture of the current listing. Interpretation: the opening may fail to demonstrate the first-use workflow. Confidence: high in the visible observation, uncertain in its effect on visitor behaviour. Owner: creative lead, with product review. Next action: inspect the actual create-to-send workflow and draft a supported opening.
Define “done” before handing over the finding
For INV-01, done means the creative brief identifies the intended audience, uses an available product workflow, includes readable captions and has a named approver. Publication is a separate milestone, and demonstrated performance improvement is a separate question again. This prevents a team from closing an issue merely because a presentation was delivered—or keeping it open indefinitely while waiting for an outcome it cannot guarantee.
Request access according to the question
For a public message review, preserve listing captures and product information supplied by the owner. For a performance investigation, request relevant report exports with definitions, dates, filters and the change timeline; use appropriate read-only access if needed. Request the minimum necessary information and do not ask for shared account passwords. If the evidence is unavailable, narrow the conclusion rather than inventing the missing explanation.
A stakeholder asks you to score the app 42/100 because that looks convincing in a presentation. How should the audit handle this?
Reveal the reasoning
Use a transparent rubric only if its criteria and limitations are useful. Do not imply that an invented score predicts growth. A documented high-priority finding, its evidence and the next decision are more actionable than an unexplained overall number.
Your working brief
Use your own app for this exercise. Fill in the six fields below and attach the evidence behind each answer. If you cannot complete a field, write the missing question and the person who can resolve it. Do not replace unknowns with optimistic assumptions.
Store, locale, date and review scope
Observation with evidence reference
Interpretation and confidence
Missing information or access
Action, owner and dependencies
Acceptance criteria and follow-up evidence
For each field, distinguish an observation from an interpretation. Add the date and source where available, then identify the decision that follows. A colleague should be able to trace your recommendation back to the evidence without needing you to explain the entire project again.
Place accepted findings on the roadmap according to dependencies and capacity.
The worked example is an original editorial framework. Its fictional app, decisions and scenarios are not an industry dataset or a claim of measured uplift.
