How does Google Play decide which apps rank higher?
Google Play ranks apps on relevance to the search or browsing context and on the quality of the app experience, and it says so in its own explainer, “How Google Play works”. It lists four factors: user relevance, quality of the app experience, editorial value, and user experience. On quality it states that apps with strong technical performance and a good user experience are generally favoured.
That short list hides a lot of detail Google does not publish, such as exact weights. What we can say with confidence is which signals feed those factors. Relevance comes from the words in your listing and how well users who search those words respond to your app. Quality comes from stability data (Android vitals), ratings and reviews, and whether people keep the app after installing it. Editorial value is Google’s own curation, which you cannot buy.
Google Play also shows ads in search, and its explainer says ads are well marked and shown alongside other content. Paying for ads does not change your organic position directly, though installs from ads can add to the momentum discussed below.
So when owners ask how to rank app on Play Store, the honest answer splits into what you control (listing words, stability, how you ask for reviews, what you test) and what you influence indirectly (installs, retention, rating). The rest of this guide takes each in turn.
You control directly
Title, short and full description, graphics, crash and ANR fixes, review replies, the in-app review moment, experiments, target API level.
You influence
Install volume and pace, listing conversion rate, retention and uninstalls, star rating, review text.
Outside your hands
Editorial picks, exact algorithm weights, competitor activity, seasonal demand.
Keyword research: finding the words people type into Play Store search
Start with the words your users type, not the words you use internally. A founder may call the product a “retail billing suite”; the shopkeeper searching for it types “bill banane wala app”, “GST invoice” or “billing app for shop”.
Three free sources give you most of what you need. First, Play Store search suggestions: type the start of a phrase and note the completions, which reflect what people search. Second, the titles and short descriptions of the apps ranking for your main term, which show the vocabulary the category has settled on. Third, your own reviews, where users describe your app in their words. Paid ASO tools add estimated volumes, but their numbers are modelled, not reported by Google, so treat them as rough guides.
Pick one primary phrase that describes what the app does and that you can plausibly compete for. A new app will not rank for “calculator” against apps with hundreds of millions of installs, but it might for “GST calculator for traders”. Add three to six supporting phrases for features and use cases. Write them down; this list drives every listing decision that follows.
- Primary phrase: what the app does, in the user’s words
- Feature phrases: specific tasks the app handles
- Audience phrases: who it is for (“for shop”, “for students”)
- Language variants: Hinglish spellings, Hindi or regional terms
How to rank app on Play Store with the title, short description and full description
Place the primary phrase in the app name, repeat it naturally in the short description, and use supporting phrases in the full description where they genuinely describe features. Google Play’s help for store listings sets the limits: 30 characters for the app name, 80 for the short description and 4,000 for the full description.
Thirty characters is tight, so every word must earn its place. A brand name alone (“Hisaab”) tells Play and users nothing; brand plus a descriptor (“Hisaab: GST Billing & Invoice”) does both jobs. The short description is the first text visitors read on your listing, so it has to sell as well as describe: what the app does, for whom, and one reason to pick it.
The full description has room for detail. Open with a two-line summary, then describe main features in short paragraphs or bullets, each naturally containing a relevant phrase. Mention the problems users have, the languages supported and what is free versus paid. Write for a person scanning on a phone.
Do not stuff. Google’s own listing help warns that repetitive or irrelevant use of keywords in the name or descriptions can create a poor user experience and lead to an app being suspended. Repeating “billing app billing software billing” may once have worked on some stores; on Google Play today it risks your whole listing. If your app has been flagged for metadata, see app rejected by Google Play.
Does install velocity help you rank on the Play Store?
A steady stream of genuine installs appears to help, because it tells Play that people who see your app want it, but Google does not publish how installs are weighted. Treat install velocity as a result of good relevance and conversion, and create it only through legitimate traffic. Any advice on how to rank app on Play Store that skips this caveat is overselling.
The practical logic is simple. Play shows your app to people searching a term. If a high share of them install, and they keep the app, Play has evidence your app satisfies that search. A launch that brings a burst of real installs in a short window gives Play that evidence sooner than a trickle spread over months.
Legitimate ways to create a burst: open pre-registration before launch and announce the release date; send your existing customers (from a website, shop counter or WhatsApp list) to the listing on launch day; publish a web page that ranks for your topic with a clear link to Play; and, if budget allows, run Google Ads app campaigns, which are labelled ads and bring real users.
What you must not do is buy installs from “install services” or pay users to install. Google Play’s policy on ratings, reviews and installs says developers must not attempt to manipulate placement by inflating ratings, reviews or install counts through illegitimate means. Bought installs also tend to uninstall quickly, which hurts the retention signals you were trying to build.
Listing conversion: the ranking lever most owners never check
Your listing conversion rate is the share of people who open your store page and then tap Install, and improving it helps both installs and ranking. Play Console shows it under Grow users, Store performance, where you can filter by traffic source, country and language.
Google has recently shifted these reports to count unique users who click Install, Open or Pre-register, which measures intent at the moment of the click. The practical use is unchanged: compare conversion from Google Play search with conversion from other sources, and compare countries or languages. If search visitors convert far worse than people arriving from your website, your listing is not persuading strangers.
The visual elements do most of the persuading. The icon is seen in search results before anything else. The first two or three screenshots are seen by nearly everyone who opens the listing; later ones by few. A good screenshot shows one benefit with a short caption in large type, using a real screen from the app rather than an abstract illustration. The feature graphic and video matter less for most small apps but should still be clean and accurate.
- Icon: simple shape, readable at small size, distinct from category leaders
- Screenshot one: the main benefit, stated in five words or fewer
- Screenshots two and three: the next two reasons to install
- Captions in the listing language, large enough to read on a phone
Do crashes and ANRs hurt your Play Store ranking?
Yes. Android’s developer documentation on vitals states that if an app exceeds a bad behaviour threshold, Play may reduce its visibility and may show users a warning on the store listing. For most apps this is the ranking factor with the clearest published rule, which makes stability the first stop in any plan for how to rank app on Play Store.
The core stability thresholds are specific. The user-perceived crash rate must stay below 1.09% overall and below 8% on any single phone model. The user-perceived ANR rate (the app freezing and showing “App isn’t responding”) must stay below 0.47% overall and 8% per phone model. Play measures these as a 28-day rolling average, so a bad release can hurt you for weeks after you fix it.
The per-device threshold catches many Indian apps out. An app can look healthy on average while crashing constantly on one popular budget model with little RAM, and that model alone can trigger a warning for users of it. Android vitals in Play Console lets you break the data down by device, Android version and app version.
The documentation also lists memory and bitmap memory usage as core vitals, with store visibility impact for apps exceeding those thresholds starting from February 2027. If your app is heavy on images or runs on entry-level phones, plan memory work now rather than when the rule arrives.
How to cut crash and ANR rates on budget Android phones
Most crashes and ANRs in small apps come from a handful of causes: work done on the main thread, unhandled network failures, memory spikes from large images, and third-party SDKs initialised all at once on startup. Fixing the top three issues by user count usually brings the rate under the threshold. If you are working out how to rank app on Play Store on a small budget, this is where the money goes furthest.
Start with data. Android vitals groups crashes and ANRs into clusters with stack traces; add Firebase Crashlytics if you want more context such as custom logs and the steps before a crash. Sort by affected users, not by event count, because one user crashing a hundred times matters less than a thousand users crashing once.
Then test where your users are. An app built and tested on a flagship phone behaves differently on a 3 GB RAM handset with a full storage and a patchy mobile connection. Test on a budget handset if you can get one, and use emulators with restricted memory and throttled networks to reproduce these conditions.
Ship fixes carefully. A staged rollout in Play Console releases the update to a small percentage of users first, so if the fix introduces a new crash you can halt it before it reaches everyone. Watch vitals for the new version for a few days, then widen the rollout.
Typical ANR causes
Database or file reads on the main thread, heavy work in broadcast receivers, slow app startup, blocking network calls.
Typical crash causes
Null values from APIs, out-of-memory on large images, missing permission handling, outdated libraries on new Android versions.
How many reviews do you need, and does replying to them help ranking?
There is no magic number; what matters is a steady flow of recent, genuine reviews and a rating that reflects the current app. Google Play’s help says the rating users see is weighted toward more recent ratings, so an app that improved last quarter is not stuck with the score of its first buggy release.
Replying matters for two reasons. First, it can change the review itself: Play Console help notes that after you reply, the user receives a push notification and an email, and users can update their rating at any time. A one-star review about a bug you have since fixed often becomes a four-star review after a polite reply saying the fix is live. Second, replies are public, so prospective users reading reviews see that someone answers.
You can post one public reply per review and edit it whenever you like. Keep replies specific, truthful and short. Name the fix and the version it shipped in; do not paste the same thank-you message under every review. For apps with high review volume, the Reply to Reviews API lets a support tool handle replies, within Google’s quotas.
Treat reviews as a bug tracker too. Read the one- and two-star reviews each week, group them by cause, and feed the top causes into the next release. Fixing what users complain about is the most reliable way to raise the rating that Play weighs. It is the least glamorous answer to how to rank app on Play Store, and the most dependable.
How to ask for Play Store reviews without breaking Google’s rules
Use Google’s In-App Review API at a moment when the user has just succeeded at something, and never offer anything in exchange for a rating. Google’s developer guidance and policy are clear on both points.
The In-App Review API shows a native rating card inside your app, so users can rate without leaving it. Google’s guidance says to trigger it only after the user has used the app enough to give useful feedback, not to prompt excessively, and not to ask any question before or while showing the card, such as “Do you like the app?” or “Would you rate us five stars?”. Play also applies a time-bound quota, so calling the flow several times within a short period may show nothing. For that reason Google advises against a “Rate us” button wired to the API.
Good moments are specific to the app: after a third successful invoice is sent, after a completed delivery, after a lesson is finished. Bad moments are on first launch, in the middle of a task or straight after an error.
On incentives, Google Play’s policy lists asking users to rate your app while offering an incentive as a violation. No coins, discounts or unlocked features for ratings. It is also a violation to submit ratings posing as users. These breaches can lead to removal, which is covered on our Google Play app suspended page.
Store listing experiments: test your way up the rankings
Store listing experiments let you show different versions of your listing to different visitors and keep the version that converts better. Play Console supports one default graphics experiment or up to five localised experiments at the same time for each app. Experiments turn how to rank app on Play Store from guesswork into evidence.
A default graphics experiment tests the icon, feature graphic and screenshots in your primary language. Localised experiments can also test the short and full descriptions, in up to five languages. You choose the metric (for example unique users who click Install), the minimum detectable effect and the confidence level. Lower effects and higher confidence need more traffic and more time.
The discipline is one hypothesis per test. “Screenshots with Hindi captions will convert better for Indian visitors than English ones” is testable. Changing the icon, captions and order all at once tells you nothing about which change mattered. Let the experiment run until Play Console reports a result, including at least one full week to smooth out weekday effects, and resist ending early because the first two days look good.
Small apps with little traffic face a real limit: an experiment may take many weeks to reach a verdict. In that case, test bold differences (a completely different first screenshot) rather than small tweaks, and put effort into traffic before testing.
Localised listings: how to rank app on Play Store in Hindi and regional languages
Add a translated listing for each language your users read, because Play shows the listing in the device language when one exists, and a listing in the user’s language is more relevant to searches typed in it. For many Indian apps, Hindi is the first addition; others need Marathi, Tamil, Telugu, Bengali or Gujarati.
Translation is more than swapping words. The keywords people type in Hindi may be English loanwords written in Devanagari, pure Hindi terms, or Hinglish in Latin script, and each behaves differently in search. Check Play suggestions in each language before finalising copy. Screenshots should use captions in that language too, since a Hindi listing with English screenshots undercuts itself.
Play Console offers translation help, including machine translation, but a fluent reviewer should check anything that goes live. You supply or approve the translated copy; we handle the structure, character limits and uploads, and can run a localised experiment to confirm the translated listing converts.
Keep app content consistent with the listing. If the listing is in Tamil but the app opens only in English, reviews will say so, and that hurts the rating you were trying to improve.
Why an app that is never updated slides down the Play Store
Abandoned apps lose ground because they stop meeting Google’s technical requirements, accumulate crashes on new Android versions, and gather stale reviews. Target API level rules are the hardest edge of this.
Android’s developer documentation sets the current requirement: from 31 August 2026, new apps and app updates must target Android 16 (API level 36) or higher. Existing apps must target at least Android 15 (API level 35) to remain available to new users on devices running newer Android versions; apps targeting older levels become unavailable to those users. Developers who need more time can request an extension to 1 November 2026.
In plain words, if your app targets an old API level, a growing share of new phones cannot find or install it, which shrinks your reach regardless of your listing. Raising the target level is not a one-line change: newer Android versions change permission, background work and notification behaviour, so each upgrade needs testing.
Regular updates also give you fresh chances to fix complaints and to refresh your “What’s new” text. We recommend a planned release at least every quarter, and more often while you are actively working on ranking. See mobile app maintenance services for what ongoing upkeep covers, and app maintenance cost in India for yearly budgets.
Shortcuts that get apps demoted or removed
Bought installs, fake or incentivised reviews, keyword-stuffed titles and misleading claims in the listing are the four shortcuts we see most, and each can end with the app removed rather than ranked. Google Play’s policies name them directly, and none of them belongs in a plan for how to rank app on Play Store.
Install and review manipulation is covered by the ratings, reviews and installs policy quoted above. Keyword stuffing and irrelevant keywords are warned against in the store listing help. Misleading titles, such as implying an official government app or using another brand’s name, fall under Play’s impersonation and metadata rules and are a common reason for rejection.
Less obvious risks come from copying a competitor’s listing, promising features the app does not have, and using screenshots from a different app version. Users notice, and their reviews say so.
- No paid install services or install-for-reward schemes
- No rewards, coins or discounts for ratings
- No repeated or irrelevant keywords in the title or descriptions
- No other brands’ names or “official” claims you cannot back up
- No screenshots showing features the current version lacks
If an update was rejected or the app has already been pulled, see app rejected by Google Play or Google Play app suspended before doing any ranking work.
How long does it take to rank an app on the Play Store, and how do you measure it?
Listing changes usually show an effect on search traffic within a few weeks; stability fixes take at least 28 days to fully show in Android vitals because of the rolling average; review improvements build over months. Expect a realistic ranking project to run for three to six months. Anyone who tells you how to rank app on Play Store in a week is usually describing ads, not organic ranking.
Measure from Play Console, not from screenshots of a search result. The acquisition and Store performance reports show visitors and installs by traffic source, including Google Play search, so you can see whether search traffic is rising after a title change. Android vitals shows the crash and ANR trend for each release. The ratings section shows the recent rating trend and review volume.
Keyword position tools can help you watch specific terms, but Play results are personalised and vary by device and location, so a position in a tool is an estimate. Search visitors and search installs in your own console are the numbers that matter.
Weeks 1–2
Audit of vitals, listing, reviews and acquisition; keyword list agreed; top crash clusters identified.
Weeks 3–6
New title and descriptions live, first stability release in staged rollout, review replies caught up.
Months 2–6
Experiments on graphics and copy, localised listings, in-app review prompt, target API upgrade, monthly reports.
How to rank app on Play Store for Indian users: devices, data and language
Indian Play Store audiences add three practical constraints: many users are on budget phones with limited RAM and storage, many watch their mobile data, and many prefer Hindi or a regional language. Each affects ranking through stability, installs or relevance.
Device limits turn into Android vitals problems when an app is built and tested only on high-end phones. App size matters too: a large download on a phone with little free storage is a common reason people skip an install or remove an app later. Keeping the download lean, using Android App Bundles so each device gets only what it needs, and lazy-loading heavy assets all help.
Across cities, the apps that rank well for local searches tend to be the ones that fit these realities. A tiffin service app in Thane, a coaching app in Kanpur, a billing app for traders in Rajkot, a tour guide app in Agra or Varanasi, a grocery app in Bhubaneswar, a service booking app in Mysore and a transport app in Siliguri each face different keywords and competitors, but the same levers apply.
Payments inside apps should support UPI where it fits the product, since a checkout that fails for users who expect UPI turns into poor reviews. We build UPI and card checkout into apps without tying you to a particular provider.
Worked example: ranking a GST billing app built in Rajkot (hypothetical)
Say a small team in Rajkot has a GST billing app with a few thousand installs, a 3.6 rating and flat search traffic. Here is how we would approach it. This is an illustration, not a client result.
Audit: Android vitals show a user-perceived crash rate above 1.09%, with most crashes on two budget phone models when generating PDF invoices. The title is just the brand name. Reviews complain about crashes and about Gujarati text printing incorrectly. Store performance shows search visitors converting much worse than visitors from the team’s website.
First month: fix the PDF memory spike and the Gujarati font issue, ship in a staged rollout, and reply to every review about those bugs with the version that fixed them. Change the title from the brand alone to brand plus “GST Billing & Invoice”, and rewrite the short description around the main benefit for shop owners.
Months two to four: add Hindi and Gujarati listings with translated screenshots that you approve; run a default graphics experiment on a first screenshot showing an invoice created in three taps; add the In-App Review API after the third invoice is shared. Raise the target API level ahead of the deadline. We would expect the crash rate to fall under the threshold once the 28-day window passes and search installs to improve, but we would report what the console shows, not promise a position.
How to rank app on Play Store: a checklist for this month
Run through this list in Play Console with your developer. The first three items protect you from demotion; the rest improve relevance and conversion.
- Android vitals: overall crash rate under 1.09% and ANR rate under 0.47%
- Android vitals: no single phone model above 8% for crashes or ANRs
- Target API level meets the current Google Play requirement
- App name includes a descriptive keyword within 30 characters
- Short description states the main benefit within 80 characters
- Full description covers features naturally, with no repeated keywords
- First three screenshots each show one clear benefit with a readable caption
- Every review from the last 30 days has a specific reply
- In-App Review API triggered after a success moment, with no incentive
- One store listing experiment running, with a written hypothesis
Website owners asking a similar question about AI assistants should read how to rank on ChatGPT. If you are still choosing who builds the app, compare costs on app development cost in India.