App store optimization that turns impressions into installs

What app store optimization actually covers

App store optimization is three jobs that regularly get confused with one another, and confusing them is why most ASO engagements disappoint.

The first is visibility: whether the listing appears at all when someone searches a term, browses a category, or is served a recommendation. The second is conversion: of the people who do see it, how many tap the install button. The third is quality: whether the people who install stay, because both stores read that back into how often they show you to anyone else.

Almost every proposal covers the first. Fewer cover the second properly, which is odd, because that is usually where the larger and faster gain sits — a conversion improvement applies to the impressions you already have rather than to impressions you hope to earn. Almost nobody treats the third as ASO at all, which is how an app sitting above the Google Play crash threshold ends up paying an agency to research keywords.

We do all three, and we will tell you which of them is your actual constraint before you commission any of them.

A note on the acronym

The letters ASO have meant app store optimization for well over a decade. They are now also being attached to agentic search optimization — getting a brand surfaced and cited inside AI assistants and generative answers. That is a real discipline and an entirely separate one: different surfaces, different retrieval, and nothing resembling a 100-character keyword field.

This page is about apps, in the App Store and on Google Play. If what you need is to be present inside an AI answer, the page you want is generative engine optimization, and saying so now saves you the next two thousand words.

The two stores do not rank apps the same way

This is the most useful thing to understand about ASO and the most commonly ignored. It is why a single “store listing” written once and pasted into both consoles is always at least half wasted.

What the App Store reads

Apple states that App Store search results are based on a number of factors including text relevance — matches for the app name, subtitle, keywords and primary category. That is the whole indexed surface, and the fields are small: an app name of up to 30 characters, a subtitle of up to 30 characters, and a keyword field limited to 100 characters with terms separated by commas and no spaces.

Roughly 160 characters of indexed text, then. Everything else on the product page exists to persuade rather than to rank. Apple is explicit that promotional text does not affect search ranking, so the widespread habit of loading it with keywords achieves nothing at all — and it wastes the 170 characters sitting at the top of your description, which is the one field you can update without shipping a new version.

Search results are also shaped by downloads, ratings and reviews and other behavioural signals, and a result can display up to three screenshots or app previews alongside the app. The creative sits inside the search result, not just behind it.

What Google Play reads

Google Play behaves much more like a search engine, because it is one. Google’s guidance on getting discovered on Play tells developers to apply SEO principles to the description while staying inside content policy, to keep the title unique and avoid common terms, misspellings and excessive special characters, and to put key information above the fold. The long description is indexed. There is no separate keyword field to fill in.

Play ranking also incorporates ratings, reviews, download volume and behavioural feedback, and the advice attached to that is refreshingly blunt: build a quality experience, update regularly, encourage feedback, answer your users.

The practical consequence

You write the listing twice. On the App Store you are allocating a very small number of characters with something close to precision, and the description is purely a conversion asset. On Google Play you are writing readable prose that carries your vocabulary naturally, and the description does both jobs at once. Anyone quoting you for “store listing copy” as a single line item has not thought about this.

Keyword research that starts with language, not volume

Store keyword tools estimate volume and difficulty by observing rankings from the outside; none of them see Apple or Google internal data. They are genuinely useful and they are estimates, and we label them that way rather than presenting a modelled number as a measurement.

The bigger problem with volume-first research is that it produces a list for an app nobody described. The better starting point is the language your users already use — the phrases in your one- and two-star reviews, the words in support tickets, what someone types when searching for the problem rather than for the product category. Check that vocabulary against the tools afterwards, rather than the other way round.

Building the keyword field

The 100-character field rewards discipline more than cleverness. A few rules recover characters that most listings throw away: do not repeat a word already present in your app name or subtitle, because the store combines terms across fields; do not put spaces after the commas; leave out your own brand name if you already rank for it; drop a plural when the singular is already there; and skip the name of your primary category, which is indexed separately.

The field is not a list of phrases. It is a bag of words the store assembles into phrases, which is why three separate short terms will usually earn more coverage than one long one.

Writing the fields in the order people see them

The name and subtitle are read in a list, at small size, next to competitors. They are ranking assets and positioning assets simultaneously, and there is a permanent temptation to make them ranking assets only.

Guideline 2.3.7 of the App Store Review Guidelines is the boundary: choose a unique app name, assign keywords that accurately describe the app, and do not pack metadata with trademarked terms, popular app names, pricing information or other irrelevant phrases. Apple reserves the right to modify inappropriate keywords itself. We write to that line rather than up against it, because a rejected submission costs more calendar time than any single term was ever worth.

The Google Play title does the same job with a different search model behind it, and the short description is the line most users genuinely read. In the long description, put the useful content first — most people never expand it, so a well-argued fourth paragraph is one nobody sees.

Creative: the icon and the first two screenshots

Assume the visitor does not scroll and does not read. Under that assumption your listing is an icon, a name, a star rating and two screenshot frames. Design for that, then add the rest for the minority who go further.

The icon carries more weight than most teams credit, because it appears in search results, in browse, in the update list, and on the home screen for as long as the app survives there. It has to be legible at very small sizes, distinguishable from the conventions of your category, and independent of text.

The screenshot set is a sequence, not a gallery. Frames one and two carry the value proposition and the single most compelling capability; frames three onwards handle objections and detail. Apple allows up to ten screenshots and up to three app previews of up to thirty seconds each, and very few apps need ten of anything. What almost every listing does need is for the first two frames to be readable on a phone without zooming, with captions stating a benefit rather than naming the screen being shown. If the frames need producing rather than specifying, that is graphic design work — though if the flows inside the screenshots are the real problem, no caption will rescue them.

Testing: what each store will actually let you do

Both stores run experiments natively, and native is what you want — the traffic split comes from the store, on real store traffic, rather than from a survey panel reacting to mock-ups they were paid to look at.

On the App Store, product page optimization tests up to three treatments against your original page, using alternate app icons, screenshots and app previews. You choose what share of total traffic enters the test, it is divided evenly between treatments, and a test can run for up to 90 days. Note what is absent from that list: it does not test text.

On Google Play, store listing experiments run up to two variants against your current listing, can include text as well as graphics, and stop automatically after six months. You choose the deciding metric from unique user install clicks, open clicks or pre-registration clicks.

Plan around the asymmetry. Your App Store copy will be settled by keyword evidence and argument; your Google Play copy can be settled by experiment. On both platforms, change one variable at a time — a test that moves the icon and the screenshots together tells you only that the pair won.

There is a harder constraint that tool vendors rarely mention: honest testing needs traffic. A listing with few impressions may never accumulate enough data to separate two variants, and running the test anyway produces a decision dressed as evidence. When that is your situation we will say so, fix the obvious problems on judgement, and recommend you spend the money on earning impressions instead.

Localisation is research, not translation

Sending your English keyword list to a translator produces a listing that is grammatically correct and commercially useless, because search vocabulary does not translate. People in different markets describe the same problem with different words, the competitive set is different, and the terms that carry buying intent are different again.

Done properly, localisation means researching terms in the target language, writing new metadata rather than translated metadata, and reviewing the creative for anything that does not travel. Do it for the markets you can actually support. A beautifully localised listing that leads to an English-only interface converts once and then uninstalls, and both halves of that get read by the store.

Ratings, reviews and the line we will not cross

Ratings sit next to your app in every search result, which makes them a conversion factor before they are ever a ranking factor. Both stores also say they inform ranking.

The legitimate lever is timing. Apple allows a rating prompt up to three times in a 365-day period, which means the moment you choose matters far more than the wording you choose: after a completed task, never on launch, never mid-flow. Apple also lets you reset the summary rating when shipping a new version — occasionally the right call after a genuinely fixed problem, though written reviews remain visible and starting again from very few ratings carries its own cost.

Review responses are underrated. You can reply to every review, and a specific reply naming the fix and the version it shipped in does more for the next reader than for the person who wrote it.

What we will not build is a flow that asks satisfied users for a public review and routes dissatisfied ones to a private form. Google Play policy prohibits incentivised ratings, deceptive pop-ups and forcing users to rate; Apple can remove a developer from its programme for manipulating reviews. The upside is a temporary decimal point on an average. The downside is your distribution.

Retention and stability are ASO problems

Android vitals defines a set of core vitals that directly affect an app’s visibility on Google Play, and publishes the thresholds. A user-perceived crash rate of 1.09% and a user-perceived ANR rate of 0.47%, measured on a 28-day rolling basis, are the points at which Play may reduce the visibility of your title and may show users a warning on your store listing.

That is a ranking factor living in your codebase. No amount of keyword work outranks a warning printed on your own listing. So when we audit, crash rate, ANR rate, uninstall rate and rating trend are reviewed in the same pass as the metadata, and when the finding is that the build is unstable we say that rather than selling screenshots. Repairing it is Android engineering work; the equivalent conversation on the other platform is iOS engineering.

Paid and organic in one plan

Paid placement in App Store search is the fastest honest way to learn which terms convert, because you can buy impressions against a term before committing any of your scarce indexed characters to it. Custom product pages extend that: you can create a large number of alternative versions of your product page, each varying screenshots, promotional text and app previews at its own URL, and use them for search results ad variations — so what someone sees after tapping matches the term they just typed.

Paid does not fix conversion. It buys the conversion rate you already have, at volume. If the listing converts badly, the correct order is listing first, budget second, and any agency reversing that order is selling you media rather than growth.

What to measure, and what to ignore

The chain is impressions, then product page views, then installs, then retained users — and only the two ends of it matter to your business. We report:

• Impressions and page views, per store and per country, so a change in installs can be attributed to visibility or to conversion rather than guessed at.
• Conversion rate, which is where most reporting stops and where most misreading happens. A conversion rate that improves while impressions fall is not a success; it is usually a narrower listing.
• Keyword ranking, as a diagnostic rather than a target. A screenshot of a number one position for a term nobody searches is decoration.
• Retention and uninstall rate, because the stores read them, and because an install deleted on day two cost you money without earning anything.

The baseline is recorded before anything changes, which is the only reason any later claim about the work can be checked — including by you, against us.

What drives the cost

No figures here, because a number produced before scope is known is a guess that somebody eventually absorbs. The variables are not secret, and knowing them lets you brief better and compare quotes honestly.

One store or two. Close to double the metadata work, because almost nothing transfers between them.

How many markets. Each localisation is research plus writing plus a creative review, and the creative review is the part people forget to budget for.

Whether creative is produced or specified. A brief handed to your existing design team costs a fraction of a produced screenshot set and preview video.

Whether you have the traffic to test on. Listings with substantial impressions support a real experiment programme. Listings without one need a different and cheaper engagement, and being told that early is worth more than being sold the expensive version.

How much is broken underneath the listing. If the vitals are bad, part of the useful work is engineering, and we would rather scope that plainly than optimise around it.

Where this sits next to the rest of the work

ASO is the last few seconds of a mobile acquisition funnel and it is rarely worth doing on its own. It belongs next to the app build itself, because stability and retention are decided there and the store is only reporting them; and next to paid app campaigns, because paid and organic land on the same product page and share its conversion rate.

If you are not certain which of those is your constraint, send us your store numbers and we will tell you which one we would fix first — including when the answer is that none of them is where your problem actually is.