Shipping to the Store Is Not Distribution: An ASO Checklist

How Store Search Actually Works

App store search is structured differently from web search. The text that gets indexed is limited to a handful of fields the store defines, and ranking reflects not only word overlap with the query but also whether people who arrived through that query installed the app and stayed. App Store and Google Play draw the boundaries of these two axes differently.

The first axis is relevance: how much the words a user types overlap with the words in your listing. The second is performance: whether people opened the product page, installed after opening it, and kept the app. Work only on relevance and impressions rise while installs do not follow. Work only on performance and you never appear in results at all.

On the App Store the indexed surface is narrow. The app name, the subtitle, and a keyword field invisible to users carry most of the weight, and the developer name and in-app purchase item names are also believed to contribute. The product page description, by contrast, has long been understood in the field as not part of the search index. Apple does not publish its full indexing rules, so treat that as working knowledge rather than settled fact and check the App Store Connect help directly.

Google Play has no separate keyword field. The app title, the short description, and the full description are all read for search. Work on the App Store side resembles composing a list: fitting distinct words into a tight character budget. Work on the Google Play side resembles writing prose: sentences that read naturally while containing the terms people actually search. Pasting the same paragraph into both stores costs you on both sides.

One illusion shows up constantly on the performance axis: mixing branded queries with generic ones. Someone who already knows your exact app name converts at a high rate, and blending that into the average makes generic-query performance look better than it is. Separate the two before judging whether a listing change did anything.

The verification path differs by store. Google Play Console reports which search terms brought users in, so start there. App Store Connect does not offer query-level acquisition data the same way. What you have instead is the keyword tool in Apple Search Ads, which shows approximate popularity for a term, plus the manual check of searching for your own app on a real device. Set the storefront country and device language to your actual target market when you do. The ranking on an App Store account registered in Korea is not the screen a Vietnamese user sees.

Before ordering the work, look at where your installs actually come from. Your own platform split matters more than market-wide share statistics, and if iOS and Android are heavily skewed one way, that store's rules come first.

Name, Subtitle, and the Keyword Field: What Goes Where

The places you can put text differ by store. The App Store splits them into app name, subtitle, and a keyword field users never see. Google Play reads the title, the short description, and the full description all for search. Each slot plays a different role, so repeating the same word into every slot wastes the space.

Character limits are adjusted by the stores. The long-standing figures are 30 characters for the App Store name, 30 for the subtitle, and 100 for the keyword field; on Google Play, 30 for the title, 80 for the short description, and 4,000 for the full description. Do not write from memory. Check the counters attached to the actual input fields in App Store Connect and Play Console.

The app name is where brand and category language sit together. Brand alone means only people who already know the name can find you, and too long a string of category words truncates into something unreadable in a results list. The test is what people actually type: for an attendance app, the phrase an office manager puts in a search box rather than the formal internal term; for a job app, what a job seeker types rather than industry jargon.

The subtitle holds what did not fit in the name, so repeating a word already used there is waste. Rather than listing features, write one line that makes clear who uses this app for what. The subtitle is both indexed and visible, and that dual role is worth the time.

The keyword field has fairly clear rules. Separate with commas only and skip the spaces, since spaces consume characters. Do not repeat words already present in the name and subtitle. Apple assembles phrases by combining the terms in the field, so entering whole phrases is unnecessary, and adding singular and plural side by side is usually redundant. Putting a competitor's brand name in the field invites trademark trouble.

The Google Play full description has to be text written for a reader. Forcing the same word in repeatedly is treated as a policy violation and does not help ranking. The first two or three sentences appear alongside the short description in the collapsed state, so the most important thing belongs there. The rest explains features and use situations in real sentences, naturally including the expressions users reach for.

Each locale is its own unit of work. Every storefront has its own set of fields, and leaving one empty cuts your indexed text in that market. Langtori supports Korean, Vietnamese, and English locales with Vietnamese as the primary one, which makes the Vietnamese listing its main front. Job Connect VN serves the Vietnamese market only, so the decision is simple. onSpots supports multiple languages and is not tied to one country, so the vocabulary shifts market by market. Covering every storefront with a single English listing drops the words local users actually type out of the index.

One caution. The character counts and field structures described here change with store policy, so open the current screens and the official help before any large rewrite.

The First Three Screenshots Decide the Install

On a search results screen, what a person sees is the icon, the name, and the first few screenshots. Even after they reach the product page, what is visible before scrolling ends somewhere around the third image. If it is not clear what the app does by then, the remaining images never get opened.

In App Store results, a layout of three portrait screenshots or one landscape screenshot has held for a long time, so portrait slots one through three are effectively search-results assets. Google Play leans on the icon and title in results, with screenshots carrying more weight on the product page. These presentation formats get changed fairly often, and opening a real device to see how it renders right now is more accurate than any document.

The first image should carry the single largest benefit: not a feature name but the outcome the user gets. For an attendance app, lead with what the manager stops having to do each month rather than how records are captured. The second image shows one core screen that proves the claim is built. The third works well when it dissolves whatever makes people hesitate: how long setup takes, whether it works without a connection, whether this is a solo tool or something a team uses together.

Copy laid over screenshots has to be short. It must read at the reduced size of a results list, which puts the ceiling around five to seven words, and small explanatory text becomes a grey smudge once scaled down. The screens shown must be real app screens. Illustrating a feature that does not exist can be flagged in review, and even if it passes, the first wave of reviews contradicts you on exactly that point.

Screenshots need preparing per locale. If the Vietnamese storefront shows an English interface, users conclude the app has no Vietnamese support even when it does. Getting number formats, date formats, and currency notation right inside the frame changes how credible the listing reads.

If you plan to add a preview video, check how each store plays it first. App previews on iOS frequently autoplay muted, so the first three seconds have to make sense with no sound, and Google Play promotional videos attach in a different position. A weak video is worse than none.

The check itself is simple. Take a real device, go to the storefront of your target market, and search for your own app with several different terms. Look at it on a handset, not a simulator, and beside the other apps in the same results. Screenshots that look fine enlarged on their own often become indistinguishable inside a competitive list.

Handling Reviews and Ratings Honestly

Let me draw the line first. Buying reviews, offering rewards in exchange for star ratings, and filtering out users likely to rate low so they never reach the store are all prohibited on both the App Store and Google Play. When caught, reviews are removed, visibility is restricted, and repeat behavior gets the developer account suspended.

Holding that line is not only an ethics question. It also does not work. A manipulated rating can push installs, but it cannot manufacture behavior after the install, and store performance signals do not stop at the install. When the praise in reviews diverges from the real experience, the users who read product pages most carefully are the ones who leave.

The permitted methods come from the stores themselves. iOS provides a system-presented review request API, and Android provides the In-App Review API. In both cases the store controls whether and how often the prompt appears, and the developer cannot force it. Building a custom interface that imitates a rating dialog is treated as a guideline violation.

Timing is a design decision. Right after a user completes something successfully is a good moment: a full month of attendance recorded, a connection made with the person they were looking for. The worst moments are immediately after an error screen, a failed payment, or first launch, which asks for a judgment from someone who has nothing yet to judge.

Unhappy users need their own channel. Put a contact button in the app that stays available and handle the problem there first. This is not a review gate. A review gate asks for a star rating and forwards only the likely high raters to the store; a contact button is open to everyone regardless of rating. The first is prohibited, the second is ordinary product design.

Reply to the reviews you receive, and to one-star and two-star reviews every time. Confirm the facts, ask politely for the information needed to reproduce the problem, and update the reply once the fix ships. Google Play notifies the author when a developer responds, and some users raise their rating on their own once they learn the issue was handled. Replies are public documents: the next person reading your product page sees that exchange.

Rating mechanics also differ. Apple offers the option to reset your rating when releasing a new version, a card to play only after a substantial rewrite, because accumulated reviews disappear with the score. Google Play is understood to weight recent ratings more heavily, so a bad stretch dilutes over time, provided later versions genuinely improve. Confirm the current rules in each store's official documentation.

Finally, treat reviews as product input. Pulling the three most repeated complaints out each quarter and putting them at the top of the backlog is enough on its own to move the rating slowly. It is the kind of improvement that does not reverse.

Measure and Iterate: What to Change and What to Wait For

ASO is not a one-time setup but a loop of changing, waiting, and reading. Change one element at a time and compare the metrics the store gives you before and after. Four baseline numbers carry most of the weight: search impressions, product page views, installs, and the conversion rates between them.

App Store Connect breaks impressions, product page views, units, and conversion out by source type. Arriving from store search, store browsing, a web link, or another app are entirely different behaviors, and merged together the effect of a listing change gets buried under an ad campaign. Isolate search-sourced traffic at minimum.

In Play Console, work from the acquisition reports, store listing visitor counts, and the search terms report. Google hands you query data, so not reading it leaves value on the table. If people arrive through terms you did not anticipate, fold that language naturally into the short and full descriptions.

Both stores include A/B testing: product page optimization on iOS, store listing experiments on Android. Results only mean something with sufficient traffic, and running a few days on thin traffic then picking a winner is adopting noise. With low volume, apply one large change wholesale and compare a long enough window before and after.

The two stores also move at different rhythms. App Store name, subtitle, and keyword fields are tied to submitting a new version, so they cannot be edited whenever you like, while Google Play listings can be edited relatively freely with a review step attached. It is often practical to test wording on Play first and carry the conclusion into the next iOS submission.

Build the waiting into the plan. A listing change typically takes several days to reach the index and another one to two weeks before rankings settle. Looking at three days and rolling back teaches you nothing. Screenshots and icons move conversion fairly quickly, so those can be called earlier. Separate the slow levers from the fast ones and set different expectations for each.

Record the things that contaminate the reading. Holidays, the start of a school term, external ad spend, press coverage, and a competitor's major update all shake the numbers. Without a note of those events you will look at the chart weeks later and draw the wrong conclusion.

The cheapest and most frequently skipped tool is a change log: date, store, field edited, previous value, new value, what you expected, which metric you will read, and when you will call it. A spreadsheet is enough. Without that record there is no iteration, and without iteration ASO is guessing.

Yeowubie Interaction runs this work in a different order for each product. onSpots is used across several countries, so it has to be read locale by locale. Job Connect VN operates in one market, which simplifies the decision while making phrasing differences inside that market more important. Langtori has two kinds of users, people learning and people teaching, who search with different words, so the listing has to hold both sides in balance. Lifting a formula that worked for someone else's app will not fit.