The #1 app in Play search has the query in its title, verbatim: how one middle dot killed our keyword matching

Published 2026-09-16Measured 2026-09-04About 3 min readelta · EltaCrew

I measured 157 Korean Play search queries by hand. The top-ranked app always carried the exact query string, spacing included, in its title. Our apps had been invisible for QR queries because I had joined words with a middle dot to make the title look nicer. The evidence behind retitling 13 apps.

Most store-optimization advice stops at "put keywords in". I only saw the actual rule after measuring, for 157 queries, where our apps and the competitors rank. The #1 app's title was the query string itself.

What I measured

One app, 핸드폰 사용시간 - 스테이프리(StayFree) ("Phone usage time - StayFree"), held #1 for six queries at once: usage time, phone usage time, usage time management, usage time measurement, usage time limit, screen time. All six strings are in the title.

The pattern repeated:

유통기한 관리 - Scanoid (expiry-date management): #1 for five expiry-date queries
로또복권 당첨확인 - QR코드 (lottery result check - QR code): #1 for four lottery queries
일출 및 일몰 시간 (sunrise and sunset time): #1 for five sunrise/sunset queries

Our apps behaved the same way. 픽스코드 - 가전 에러코드 조회 (FixCode - appliance error code lookup) was #1 for "appliance error code", #3 for "error", #4 for "boiler error code", #5 for "error code". Only queries whose string appears in the title show up. An app with 100+ installs held #1 for "error code". String match is the first gate, ahead of install count.

The middle dot breaks matching

The counter-example hurt more. The document-scanner app's short description and body said QR·바코드 ("QR·barcode"), but people type qr코드 ("qr code"). A string joined with a middle dot does not match qr코드. In 935 characters of body text the query "QR code" appeared zero times, and the app was unranked for every QR query.

More of the same:

AdMob·애드센스 does not match 애드몹 (the Korean spelling of AdMob). Latin and Hangul are different strings.
골든아워·일출일몰·달 does not match 일출일몰시간 (sunrise-sunset time).

The middle dots I had added to make titles look tidy were killing search matching wholesale.

What changed

Across 13 apps I put the query strings into the title, short description and body exactly as typed, spacing included. Brand names moved to the back or out. An app with fewer than a few thousand installs has effectively no brand search volume, so there is no reason to spend the front of the title on it.

One mistake along the way: in the AdMob dashboard app's Korean title I dropped the Latin AdMob and kept only the Hangul 애드몹, and the app fell out of the top 50 for admob. The description mentioned AdMob nine times, but that put it behind 50 apps that had the token in the title. Korean autocomplete showed 5 suggestions for admob and 2 for 애드몹, so the Latin spelling went back into the title. Follow the spelling people actually type, not a house style.

English: same rule, different situation

Top English apps also use the query as the title: QR & Barcode Scanner, AdMob Dashboard, StayFree - Screen Time. But our English titles already contained the target strings and were still outside the top 30: Dog Tick Finder, Phonest: Screen Time Report, FixCode - Appliance Error Code. Unlike Korean, the problem was not a missing string; the competition is simply much deeper. Expect less from retitling in English. The one exception was the Markdown viewer at #19 for "markdown viewer" and #20 for "markdown editor".

How to measure

Open the Play web search results page for each query and count where your package appears. I keep the query list in a file and run it with a script; it skips queries already measured, so for a re-measurement you delete the results file first. I judge the effect two weeks after the change with the same list.

Summary

1 app title = query string. I found no exceptions.
Middle dots, Latin-versus-Hangul spelling, and spacing differences are all different strings.
Query before brand. Small apps have no brand search volume.
Autocomplete decides the spelling, not my taste.
English follows the same rule but with far deeper competition, so lower the expectation.

ASOGoogle Playstore optimization

R8 on, build green, app broken: five runtime traps that actually hit across 15 appsI enabled R8 in 15 apps for Play's 2027 code-optimization requirement. Every build passed, but 2 of the first 7 I installed broke at runtime. Gson deserialization, getIdentifier resource lookups, Room _Impl classes, and debuggable builds that silently disable R8: the kinds of failure that never show up in a crash log.One merchant account blocked releases for all 21 of my apps: Korean individual developers and Play Console's "additional information required"Right after I set up a merchant account to test a donation in-app product, Play Console demanded a business registration number and an e-commerce license number and blocked every release on the account. Deleting the products did not help, deleting the payout account did not help, and support's final answer was "this cannot be reversed". How an individual developer avoids this trap.Data safety forms with zero declarations are getting caught: auditing 21 apps and fixing them with CSV and the APIA phone number the user types in by hand, belonging to someone else, still counts as "phone number collection" to Google. After one rejection I compared all 21 apps' data-safety declarations against their source: 11 were wrong, and 3 had declared nothing at all. Why ad-only apps cannot declare zero, and how to fix the form with CSV and the API instead of the five-step wizard.