I no longer pick store keywords myself: mine rival titles, verify with autocomplete, measure rank

When I choose the seed words, the result is "my idea of ASO". I switched to scraping the titles of apps that share our search results, keeping only words Play autocomplete confirms as real queries, and measuring where we rank for each. Includes the mistake where one-character prefixes made me miss every core keyword.

The previous post argued that the #1 title is the query string. That leaves the question of which queries to use. At first I chose them: words like "markdown", "tick", "golden hour". The result was unranked for most of them. The problem was that I had no evidence those were the words people actually type.

Three steps

This is the only process I use now.

1. Mine: scrape the titles of every rival app that appears in the search results where our app appears (or should), and count word frequency. These are words chosen by apps that already rank, so the set is finite and pre-validated.
2. Verify: feed each word to Play autocomplete and keep only the ones that come back as real queries.
3. Measure: for each surviving query, record where our app ranks today. That is the baseline, and after the change I measure again with the same list.

With this order, "manager's taste" has nowhere to enter.

The autocomplete endpoint

The old market.android.com/suggest/SuggRequest returns 404 now. What works is the batchexecute call the Play website uses (rpcid teXCtc), and it needs no authentication. It returns only the top 5 suggestions per prefix. That "5" caused the mistake below.

Never sweep with one-character prefixes

To build a broad vocabulary I swept autocomplete with single Korean characters and collected 2,839 suggestions. "Tick", "error code" and "markdown" were not among them. A one-character prefix returns only the five highest-volume completions (music services, airlines, TV brands). You need two characters before the "tick" family appears.

Not knowing that, I concluded "our queries do not exist in autocomplete", and I was wrong. A two-character sweep found all of them. If you do not know a tool's limit (top 5), you end up declaring things absent that are merely hidden.

Queries not to use

Mining turns up queries with volume for features the app does not have. "Study timer", "idle game" and "hidden camera detector" made the candidate list and were dropped. Bringing people in for a feature the app lacks comes back as uninstalls and low ratings, and can be flagged in store review as a misleading claim.

Re-measurement

I changed 13 apps on 4 September 2026 and set a single judgment date, 18 September. Scattered dates per app make comparison impossible. One thing to remember: the rank script skips queries it has already measured, so the results file must be deleted before re-running. I once forgot, and read "no change" from stale data.

Review campaigns did not turn into installs

One related finding. The benefits-calendar app collected a 5.0 rating with 10 reviews through a review exchange and climbed from #13 to #5 for "government subsidy", and installs stayed at 10+. If rank rises and installs do not follow, that query's real traffic is small. I stopped the review exchange.

Summary

• Seeds come from rival titles, not from me.
• Autocomplete verifies that a word is a real query. Use prefixes of two or more characters.
• Measure before and after with the same list. Delete the results file to re-measure.
• Drop queries for features the app does not have, whatever their volume.
• Rank and installs are different metrics. Measure both.