“ASO is not working” can mean several different things.
Your app may not appear for relevant searches. People may see it and keep scrolling. They may open the product page and decide not to download. Or they may install, open the app once, and leave before reaching value.
Those problems need different fixes.
If visibility is weak, changing onboarding will not create impressions. If downloads are healthy but activation is poor, adding keywords can send more users into the same product problem.
The first job is to find the earliest stage that is materially weak.
Define “not working” with a number
Do not begin with a tactic.
Write down:
- the app and version
- storefront and language
- date range
- traffic source
- metric that looks weak
- comparison period or baseline
- important releases, campaigns, and external events
Replace:
Downloads are bad.
With:
US first-time downloads from App Store search fell after the June 18 listing update, while impressions were roughly stable.
The second sentence gives you somewhere to investigate. The first invites random changes.
Check the data before diagnosing the listing
Many ASO investigations start with a reporting problem.
Before interpreting a decline, check:
- The same metric is being compared. First-time downloads, redownloads, total downloads, installations, and product-page views are not interchangeable.
- The same storefront and source are selected. A global total can hide opposite changes by country.
- The periods are comparable. Weekends, holidays, featuring, and seasonality can change demand.
- The app version and release dates are recorded. Product and listing changes may overlap.
- Analytics thresholds and consent limits are understood. Apple currently exposes App Store metrics after at least five first-time downloads or pre-orders, download metrics after five first-time downloads, and usage metrics after at least five active devices in the selected period. Usage totals cover users who opted in to share analytics.
- Third-party estimates are labeled. Keyword positions, competitor downloads, and revenue estimates are useful clues, not first-party truth.
Apple's current metric definitions are worth keeping open. For example:
- Impressions count when the app is viewed on supported App Store surfaces for more than one second and include product-page views.
- Product Page Views count views of the App Store product page, including StoreKit-loaded pages.
- First-Time Downloads are different from redownloads.
- Total Downloads combine first-time downloads and redownloads.
- Conversion Rate uses total downloads and pre-orders divided by unique-device impressions.
Apple's Conversion Rate is not a product-page-view-to-download rate. It starts with unique-device impressions across supported App Store surfaces, and users can download from a result without opening the full page. If you calculate a page-view ratio for an investigation, label it as a directional diagnostic rather than Apple's conversion metric or a clean user-level funnel.
Use the metrics as related signals, not as a perfect clickstream.
The short decision tree
Start at the top and stop at the first branch with credible evidence of a problem.
| What you observe | Investigate first | Do not change yet |
|---|---|---|
| Little relevant visibility | Search intent, metadata, storefront, competition, and market demand | Full screenshot redesign |
| Impressions but weak interest or downloads | Search-result promise, query fit, ratings, icon, screenshots, price | More broad keywords |
| Product-page views rise while downloads do not | Screenshot sequence, trust, offer, expectation, localization | Onboarding flow |
| Downloads but weak activation | Traffic quality, listing promise, onboarding, product reliability | Keyword volume alone |
| Activation but weak purchase | Offer, paywall, pricing, timing, user value | App name and keyword field |
| Apple Ads spend but poor users | Search terms, targeting, page match, activation, unit economics | Higher budget |
| Rankings rise but business does not | Query relevance, demand, source mix, and downstream quality | Celebrating the rank as the result |
This is a routing system. It does not prove the cause. Each branch should end with a hypothesis you can disprove.
Branch 1: The app has little relevant visibility
First confirm that visibility is actually missing for the intended market and query.
Check:
- App Store Connect impressions by territory and source
- important keyword positions over the same date range
- whether the app is indexed for the intended term
- metadata in the relevant localization
- competitor results for that storefront
- category and seasonal demand
- app availability, device support, and any account or release issue
Possible causes
The keyword does not match the product. A popular term can still be irrelevant. Apple and users both receive weak signals when the listing describes a different job.
The metadata does not express the intent clearly. The app name, subtitle, and private keyword field may omit useful language or waste space on repetition.
The target is unrealistic for the current app. A new app may be competing against established products for a broad category term. A narrower, better-matched query can provide a more useful first signal.
The wrong storefront is being evaluated. Metadata, competitors, and demand vary by market.
Demand changed. Search interest can fall even when the listing stays the same.
Next investigation
Use the keyword research playbook to build one relevant cluster. Compare competitors by user choice rather than category rank. Record the baseline before changing metadata.
Do not change yet
Do not redesign every screenshot because impressions are low. Screenshots may affect conversion and expectation, but they do not answer whether the current metadata targets a relevant, reachable query.
Do not add a long list of broad terms. More theoretical coverage can make the listing less focused without solving the competitive problem.
Branch 2: The app appears, but the visible result earns little interest
The user may see the icon, app name, subtitle, rating, and leading creative before opening the full page—or download directly from the result.
Look at the exact surface and query.
Ask:
- Does the app name explain the category or purpose to someone who does not know the brand?
- Does the subtitle add a useful outcome or differentiator?
- Does the first visible screenshot continue the search intent?
- Does the icon look credible and recognizable beside direct alternatives?
- Is the rating or review volume creating a trust gap?
- Is the result localized for this storefront?
- Does the query describe a use case that belongs on a custom product page?
Possible causes
The query and visible promise disagree. The metadata may contain the term, but the result looks like a different product.
The positioning is generic. “Better productivity” gives the user little reason to choose one result over another.
Trust is weak. Ratings, reviews, price expectations, or an unfamiliar brand may need clearer evidence.
The main use case is buried. A custom product page may be a better destination for a distinct keyword group.
Next investigation
Take a screenshot of the search result beside the three most relevant alternatives. Write what each result promises in one sentence.
If your sentence could describe all four apps, the position is not specific enough.
Use the custom product pages guide when the query represents a real, distinct use case.
Do not change yet
Do not raise Apple Ads bids before checking the result and page. More impressions can make an unclear message more expensive without making it clearer.
Branch 3: People evaluate the page but few download
Now inspect the buying decision.
Segment the data by storefront, source, device, and time period where possible. Do not assume all product-page views have the same intent.
Do not use Apple's overall Conversion Rate as proof that the product page itself is the weak step. Because that metric is based on unique-device impressions and includes direct downloads from App Store results, use product-page views, downloads, source context, and the visible page together.
Check:
- first three screenshots at actual phone size
- screenshot sequence and caption specificity
- app preview and poster frame, if present
- rating and recent review themes
- subscription, purchase, or price expectations
- description opening and privacy-sensitive claims
- app version and screenshot accuracy
- local language, units, currency, and examples
- source-specific pages and campaign promises
Possible causes
The first screenshots do not answer “Is this for me?” They may list features without explaining a result.
The page does not prove its claims. The caption promises an outcome while the visible interface shows an unrelated dashboard.
The traffic is wrong. A low conversion rate can be a keyword or campaign problem, not only a creative problem.
The offer surprises the user. Price, trial, subscription, or required account details may not match the expectation created earlier.
The page is technically correct but locally wrong. A direct translation can miss the phrase, convention, or trust concern in that market.
Next investigation
Run a short comprehension check on the first three frames. Ask someone unfamiliar with the app what it does, who it serves, and what they expect after download.
Use the screenshot guide to turn the confusion into one treatment. Use the Product Page Optimization guide when the app has enough traffic for a controlled comparison.
Do not change yet
Do not call the screenshots the cause because conversion is low. First check traffic intent, price, ratings, and storefront. Creative is one part of the decision.
Branch 4: Downloads arrive, but users do not activate
This is where listing work meets the product.
Define activation as the first action that shows the user reached meaningful value. Opening the app is usually too early.
Examples:
- completing the first focus session
- creating and sharing the first list
- importing the first document
- saving the first meal plan
- finishing the first lesson
Then compare activation by:
- acquisition source
- campaign or keyword group where attribution supports it
- storefront
- app version
- new versus returning user
- product page or campaign path where available
Possible causes
The listing overpromises. The page attracts the download with a result the app cannot deliver quickly.
The right feature is hard to find. The user arrives for one use case and lands in a generic onboarding path.
The traffic is too broad. More installs are arriving, but fewer belong to the intended audience.
The product is failing. Crashes, account creation, permissions, loading, or paywall timing may block the first result.
Activation is defined incorrectly. A vanity event can hide the real point where value is reached.
Next investigation
Use the ASO-to-activation guide to connect acquisition cohorts with the first useful action. If the loss is inside the first session, use the onboarding drop-off playbook.
Read recent reviews for expectation language. Compare it with the first screenshots and onboarding screens.
Do not change yet
Do not add more keywords or increase paid spend until you know whether the current users are wrong for the app or the app is failing the right users.
Branch 5: Users activate but do not pay
ASO may have done its job.
If relevant users discover the app, download it, and reach initial value, the next constraint may be monetization.
Check:
- where the offer appears relative to first value
- whether paid value is clear
- trial and introductory-offer behavior
- price by storefront
- paywall view, start, purchase, renewal, cancellation, and refund signals
- whether the listing creates a free-product expectation
- whether the acquired use case has paid value
Possible causes
The audience values a free feature but not the paid outcome. The keyword can be relevant for usage and weak for the business.
The page hides the business model. Users feel surprised at the paywall.
The offer arrives before trust or value. The right user has not yet seen enough reason to pay.
The price or package is wrong for the market. Global conversion can hide a storefront-specific issue.
Next investigation
Inspect the path from activation to offer. Separate acquisition quality from paywall quality. Do not rewrite metadata to solve a pricing problem unless the listing truly sets the wrong expectation.
Do not change yet
Do not optimize for a cheaper install while ignoring paid conversion. Lower acquisition cost can make the dashboard look better while revenue quality gets worse.
Branch 6: Apple Ads spends money but produces weak results
Separate the paid path:
Search query → impression → tap → App Store download → activation → purchase or retention
Then find the earliest weak point.
Few impressions
Check keyword status, match type, bid, budget, relevance, country, audience restrictions, and campaign state.
Impressions but few taps
Check query intent, visible search result, rating, brand recognition, and ad variation.
Taps but few downloads
Check the search terms, product-page message, custom product page, price, and trust.
Downloads but weak activation
Check query quality, Search Match or broad-match discoveries, expectation, and onboarding.
Activation but weak economics
Check cost per acquired activated or paying user, not only cost per install.
Use the Apple Ads starter guide to separate controlled intent from discovery, inspect actual search terms, and maintain negative keywords.
Do not change yet
Do not increase the budget because the campaign has a low reported cost per install. Confirm what those installs do after download.
Branch 7: Rankings improved, but the business did not
A keyword rank is an intermediate signal.
The rank can rise without a meaningful business result when:
- the query has little demand
- the query is broad but poorly matched
- the app appears but does not earn downloads
- downloads come from another source
- the ranking is measured in the wrong storefront or device context
- acquired users do not activate or pay
- third-party rank tracking differs from real user exposure
Ask:
- Did impressions from App Store search rise in the same market?
- Did first-time downloads rise?
- Did the source mix change?
- Did activation and paid conversion hold?
- Is the result large enough to distinguish from normal variation?
Do not discard the ranking improvement. Treat it as one stage that may need better conversion or may simply belong to a small query.
Do not change yet
Do not chase the next rank before connecting the current visibility to users and value.
A worked diagnosis
The example below is hypothetical. It shows the method, not a claimed result.
Initial assumption
The app needs more keywords because downloads fell.
Evidence
- US App Store search impressions were stable.
- Product-page views were also roughly stable.
- First-time downloads fell after a screenshot update.
- Apple Ads spend and keyword set were unchanged.
- The first screenshot changed from a specific shared-list promise to a broad organization claim.
- Comprehension checks described the app as a personal to-do list.
Revised diagnosis
Visibility was not the earliest weak stage. The page had lost a clear reason for the intended user to download.
Test
Restore collaboration as the first promise and show the shared-list mechanism in a PPO treatment.
Primary metric and guardrail
- Primary: first-time-download conversion in the tested localization
- Guardrail: first shared-list creation after download, where attribution supports it
The important step was not the screenshot idea. It was ruling out the original keyword assumption with first-party evidence.
Write the diagnostic hypothesis
Use this format:
I believe [specific issue] is limiting [specific stage] for [storefront, source, or user] because [evidence]. I will investigate or test [change]. I expect [primary metric] to move while [guardrail] remains acceptable. The idea is wrong if [disconfirming result].
Example:
I believe broad discovery queries are lowering activation for US Apple Ads users because installs rose while completed focus sessions fell, and the search-term report contains unrelated productivity queries. I will add negatives and move relevant terms into an exact group. The idea is wrong if activation remains weak for the controlled queries.
This is more useful than “improve ASO.”
Keep a diagnosis log
For each investigation, record:
- symptom and date detected
- app, version, storefront, and source
- metric definition
- baseline and comparison period
- data-quality checks
- earliest weak stage
- evidence for and against the hypothesis
- change and owner
- primary metric and guardrail
- observation window
- result and next decision
The log prevents the team from repeating the same unproven explanation every time downloads move.
What to do next
Open App Store Connect and choose one app, one storefront, one source, and one comparable date range.
Find the earliest weak signal you can support:
- visibility
- visible-result interest
- product-page conversion
- activation
- purchase
- paid economics
Then write one diagnostic hypothesis.
Do not change the listing until you can explain which stage the change is supposed to affect and what result would prove the idea wrong.
Use the complete App Store ranking guide when you have identified the stage and need the full operating sequence around the next change.