ASO optimization: the app exists, but there are no installs
The app works, reviews come in, support responds — but there are almost no installs from the stores. A user searches for a solution to their task, but the listing is not shown for those queries: the app's search visibility rests on the brand name that people already know.
Everything else is random traffic from adjacent categories, and it also brings irrelevant queries: people install the app, do not find the scenario they need, and delete it.
The second half of the problem is low listing conversion.
Even when there are impressions, the visitor sees the first screenshots without an explanation of value, a short or overloaded description, and leaves for a competitor that ranks lower but answers their question more clearly.
Then accumulation kicks in: weak conversion lowers positions in the store's search results, organic traffic loss grows, and the team compensates for it with paid channels, not seeing that the cause is in the listing, not in demand.
ASO optimization starts with semantics, not with text edits.
We collect real search phrases, divide them by intent and frequency, filter out queries that bring non-target users, and distribute the remaining ones across the listing fields: title, subtitle, keyword field, description. Then we check how each field reads to a human, not just to an algorithm.
Next we work on conversion: the icon and first screens must explain within five seconds what the person will get, reviews and rating must remove doubts, and localizations must match the market.
We track positions for each query group separately, and make changes one at a time so we can see the cause. We analyze how this is addressed.
What ASO optimization delivers: measurable effect
ASO changes two parts of the funnel: appearing in search results for target queries and the decision to download inside the listing. These are different mechanics with different metrics, and they cannot be mixed into one metric — otherwise the effect cannot be read.
Visibility grows from working with semantics: we collect queries for which the app is already shown and separately those where it is not indexed. We rewrite the title, subtitle, description, and keyword field, and add locales for specific markets.
Due to this, the app starts being found for phrases that previously did not work, and the share of organic installs in the total volume grows.
Listing-to-install conversion is measured most directly: split tests of the icon, first screen, and preview show differences within fractions of a percent given sufficient traffic volume. We test one element at a time — otherwise the change cannot be explained.
Reviews work alongside: their freshness and the team's responses influence the decision no less than the description text.
App Store and Google Play rank by different rules, so we calculate semantics and listing elements for each platform separately, rather than transferring one set to both.
Retention after the first session and lower acquisition cost are consequences: if the listing promises the same thing the person sees on the app's first screens, they do not leave on the second day.
Paid channels remain, but their share falls — we compare metrics on cohorts before and after changes, not on overall graphs.
Options for working with the app listing
An app listing is several independent levers. Some teams start with text metadata: title, subtitle, and keywords determine which queries show the app in store search.
Others take on visual assets — icon, screenshots, videos in the gallery: these are what turn an impression into an install. Still others go through localization for countries, work with reviews and ratings, or external traffic sources.
The choice depends on the bottleneck: few impressions, low impression-to-install conversion, or weak growth in new regions. Below is when each approach is appropriate and what it does not cover.
| Option | When it fits | Limitations |
|---|---|---|
| Text metadata of the listing | The app is not found for target queries | Growth in impressions does not produce installs without visual edits |
| Visual assets of the listing | There are impressions, but install conversion is low | Become outdated along with the interface; regular review is needed |
| Localization for countries | Entering a new country or weak positions there | Native speakers are needed: machine translation reduces trust |
| Work with reviews and ratings | A low average rating scares off new users | Responses do not replace fixing the causes of complaints in the product |
| External traffic sources | A quick influx of attention and growth in search positions is needed | The flow ends with the campaign if the listing does not retain users |
The levers work together: metadata brings impressions, visuals turn them into installs, reviews reduce churn, and external traffic strengthens the rest. We analyze the listing across these areas and propose an order of work where every step relies on data, not guesses.
Work stages: from listing audit to handover
ASO is a cycle, not a one-time description edit: we change the listing based on data, not inspiration. First we capture the current state of search results, then we edit what gives the greatest increase, and after each edit we look at metrics so as not to guess about causes.
- Store search results audit. We collect the semantic core, capture positions by query, listing impressions, and impression-to-install conversion. The output is a list of queries where the app is losing traffic.
- Competitor analysis in the niche. We analyze the top of search results: which fields are occupied by keywords, how the listing's first screen is structured, how often texts and graphics are updated.
- Listing edit plan. We distribute queries across fields taking into account frequency and relevance: first title and subtitle, then description, graphics, and work with reviews.
- Making changes. We edit the listing in store consoles in groups so that the effect of each group is separable from the others. Where listing tests are available, we roll out variants and keep the winner.
- Result verification. Two to four weeks after reindexing, we compare impressions, conversion, and top rankings for the core against the baseline snapshot, and record confirmed hypotheses.
- Handover. We hand over the core, metadata templates, update rule, and edit calendar — the team continues the cycle independently.
What the client retains after the project
The project's goal is not a one-time listing edit, but a set of materials that your team can then work with on its own.
Therefore, at the output we hand over not "ready texts for approval" but working documents: with a query map, formatting rules, and an update release procedure. Everything in a unified format so that any employee can make changes, not only the project author.
- Target query map — queries are divided into semantic clusters, with frequency, competition, and a note on which listing screen each should be addressed: in the title, subtitle, or description.
- Listing text templates — templates for the title, subtitle, description, and "what's new" block, with character limits and rules for inserting queries without keyword stuffing.
- Visual asset sets — icon, screenshots for different screen aspect ratios, and preview video, with an explanation of what task each frame solves and in what order they are shown.
- Update release procedure — frequency of edits, who approves, what is checked before publication, how the result is recorded, and how an unsuccessful change to text or visuals is rolled back.
- Instructions for your team — where to get layouts and texts, what can be changed independently and what requires approval, and how not to break the already working listing structure.
- Accesses and accounts — we hand over both store consoles with rights to publish and statistics, so that the data remains with you, not with the contractor.
- Experiment log — a table where the hypothesis, the change made, and its impact on installs are recorded: it shows which techniques work specifically in your category.
With this set, updating the listing stops being a project — it becomes a routine task of a couple of hours. Describe the task, and we will return with an estimate and work plan.
Case study: how the app's visibility grew
Baseline
The client came with an app where in-store search produced about a quarter of all installs, and paid traffic pulled the rest.
For forty target queries, the listing ranked in the 20–40 range, and install conversion after viewing was 2.4% — visitors came from ads and left before reaching the button.
Description edits were made selectively and without measurements, so it was impossible to understand which wording worked.
What we changed
We rebuilt the semantics: we separated queries by intent and by how well the listing can actually answer them — some high-frequency queries were inherently unable to produce target installs, and they were excluded from priority.
We rewrote the title and subtitle so that the entry query stood closer to the beginning, reshot the first three gallery screens for real usage scenarios, and moved the benefit to the first frame rather than the description.
The icon and order of screenshots were run through sequential comparisons, changing one element at a time: otherwise a spike cannot be attributed to a specific edit.
In parallel, we addressed the rating — responses to reviews and a rating prompt after successful order completion instead of first launch.
Result
Over two months, the app entered the top 3 for nineteen of forty queries and the top 10 for thirty-four, and listing conversion grew to 4.9%.
The share of installs from organic search grew from 24% to 58% with the same volume of paid traffic — acquisition costs stopped being the foundation of the funnel, and the App Store store began showing the listing for queries that we had not initially included in the semantics.
We also recorded checkpoints separately: we capture positions, conversion, and organic share regularly, so the next listing change is compared with a clear baseline, not with feelings.
How does working with listing text differ from working with visuals?
Text metadata — title, subtitle, keyword field, description — is the indexing layer. The store uses it to decide for which queries to show the listing, so edits here change impression volume: some queries appear, some disappear.
Text updates are picked up within hours, publication goes through without manual review, and split tests are launched directly in the store console — a hypothesis is tested in a few days on live traffic.
Visual assets — icon, screenshots, video cover, first screen — have almost no effect on indexing. Their task is different: to bring a person who has already arrived to an install.
But they take longer to prepare: a layout for each locale and screen size, moderation review, sometimes a new build. A significant result requires an accumulated sample, so an honest visual test takes weeks, and a conclusion cannot be made from one day of data.
The difference in the speed of hypothesis testing is the main thing to consider when planning. Text metadata gives a fast cycle: edit, several days of measurement, conclusion.
With visuals, the cycle is many times longer, so we first squeeze the text layer up to the demand ceiling and only then invest in graphics.
Effects must not be mixed: growth in impressions from text can easily be attributed to a new icon, and a conversion drop to an unsuccessful title. That is why we keep measurements separate — by impression volume and by install share — and change one layer at a time.
Then it is clear which layer drives visibility and which drives the user's decision to install the app.
Common technical doubts about listing promotion
Questions at this stage are almost always the same: what is visible from the outside at all, what is permissible to change in an already published app, and how listing edits coexist with paid traffic. Below are short answers that usually remove doubts before work starts.
Which store data is closed, and what do you replace it with?
Stores do not expose impressions for specific queries, the breakdown of installs inside the page, and some audience segments.
We rely on what is available to the owner from the developer console, plus our own measurements: share of organic installs, listing view-to-install conversion, and first-days retention by cohort. Before edits, we record a baseline — otherwise there is nothing to compare changes with.
Is a new release needed to change the listing?
No for most fields: title, subtitle, description, icon, frames, and screen texts are edited in the console and go to review without a build. A build is needed only if internal screens, in-app promos, or the set of purchases change. That is why we test the text and visual parts in parallel with the regular version release cycle.
How does this combine with paid traffic?
The ad and the listing work for one funnel: advertising brings a person to the page, and its conversion determines how many of those brought will install the app.
By improving relevance for queries, you raise the share of installs without paying per click, and campaigns begin to deliver results on a smaller volume of impressions. These areas do not need to be separated — they reinforce each other.
When is the effect visible, and is there a risk of ranking drops?
The first shifts for low-competition queries are noticeable after a few weeks, and a stable position on a horizon of two to three months, because the store recalculates search results gradually.
We edit in stages and with rollback: first isolated blocks, then metadata, then visuals — with position and conversion control at each step. Abrupt mass edits are the main cause of temporary loss of visibility.
Let's discuss the task: what to send for an estimate
To make the ASO optimization estimate specific rather than "plus or minus based on experience," we need data on the app and access. Below is what to send at the first step: with this set, we state the scope of work, stages, and timelines, not a range.
- Links to the app in App Store and Google Play, a list of markets and languages in which it is published.
- Developer console access with a role to view statistics — publishing rights are not required.
- An export of statistics for several months: impressions and installs, listing conversion, retention, traffic sources by channel.
- Current listing assets in source files: title and description, icon, screenshots, video preview, localizations.
- Semantics, if collected: queries by which the app is already found and queries you consider target.
- Goals and constraints: what we consider success — install growth, retention, a specific market; which wordings and visual elements the brand does not approve.
Based on this data, we review the listing funnel, find where installs are lost, and return with an estimate and work plan: a list of stages, the scope of edits to texts and visuals, the expected effect on metrics, and timelines.
We provide the estimate within two to three business days after receiving access — if something is missing, we will say right away, before the start.
In the plan, we specify the team composition: an app store promotion specialist, a copywriter-localizer, a listing designer, and an analyst who records metrics before changes and verifies them after. Describe the task in free form — we will return with an estimate and plan.