The resource centre

Why this library exists

Every text in this library answers one question: what carries your rank on the App Store, and what does not? The answer comes from measurement rather than guesswork - and what we could not measure is written down just as plainly.

Most of what is written about App Store Optimization falls into two groups. The first speaks in numbers nobody measured: "this tactic lifts installs forty per cent", "putting a keyword in the title triples your rank". There is no measurement behind those sentences; they are one person's single observation, generalised. The second group speaks so generally it says nothing: produce quality content, listen to your users, watch your competitors. Neither tells you what to do next week.

Because rankcusp is a measurement tool, these texts are written in the language of measurement. If we give a number we say where it came from. If we cannot measure something we write that we cannot, rather than writing zero - because zero is a reading and people decide on readings. The same rule holds in the panel: a phrase whose popularity could not be measured carries a short dash, not a zero.

The library's second purpose is simpler: explaining what the tool does before you buy it. Every method described here corresponds to something running in the panel. The text about extracting phrases from rival reviews describes an extractor that actually runs. The text about wasted characters in metadata describes an audit that actually counts. None of it is something we will build later.

So you will not find a case study, a customer story or a growth percentage here. The data those need has not accumulated; it will be published when it does. Until then the only honest thing to describe is the mechanism itself - and the mechanism is the hard part anyway.

The formats, and when to read which

The library is split into three formats, and the split is not decoration. Each answers a different question, so each is written at a different length and depth.

Guides describe a job from start to finish. Finish the keyword selection guide and you hold a tracking list. Finish the metadata guide and you hold a rewritten title, subtitle and keyword field. Guides move in steps and each step leaves something you can check.

Reports show a field as it was measured. A category competition report says how many apps compete for the same phrase and which bands that competition clusters in. Reports carry more tables and less narrative; they are for looking at, not reading through.

Summaries exist so you can recall a subject you already know. They are read in ten minutes before a meeting and leave you with a few sentences. They do not aim to teach anything new; they put what you already learned in order.

New to this? Start with the guides; they have to be read in order and skipping does not work.
Entering a new category? Read that category's report first, the guide after.
Changed your metadata recently? Read the summaries; the guides will describe what you already did.
Reading as a team? Share the reports; let one person read a guide and apply it - a guide is work, not a decision.

The five things we measure

Every text in the library is built on the same five measurements. Whichever one you read you will come back to one or more of them, so they are worth defining up front.

RankWhere the app appears when a given phrase is searched in a given country. If it is not in the first 200 we write "outside 200" rather than inventing a large number. Rank is measured once a day and the history is kept; that is the only way to see the effect of a metadata change.
PopularityA relative value for how much a phrase is searched, derived from Apple's own signals. Not absolute search volume - Apple gives that to nobody, and the tools that do are estimating. Where we cannot measure it, popularity stays blank.
DifficultyHow strong the apps competing for a phrase are. How many carry it in their title, what the rating counts at the top are, and how many words the phrase has all come together. Difficulty is not a prophecy; it is a cost estimate.
RelevanceWhether Apple has associated your app with the phrase. If you appear in the first 200 it has; if you do not, you have to make it happen first. That distinction is what decides which keyword is cheap and which is expensive.
The rating curveHow the app's score and rating count move over time. It does not carry rank directly, but a drop after a release is the fastest signal that something in that release broke.

The 11-30 band: the idea at the centre

Most of the texts here come back to the same place, so the idea is worth setting out once in full.

Ranking for a keyword needs two separate things. The first is relevance: Apple associating your app with the phrase. The second is rank: placing you higher among the apps it associated. Those two cost very different amounts. Building relevance from nothing for a phrase you never appear on means rewriting metadata, probably rethinking positioning, and waiting weeks. For a phrase where you already sit at 24, relevance is long since built; the only thing missing is a few places of rank.

The first page is where almost all of a search ends. Users do not scroll; they open one of the first few results. So an app at 24 is effectively invisible for that phrase - but the invisibility is caused by a few places of distance, not by irrelevance.

That is why the band between 11 and 30 is an app's cheapest growth. For every phrase sitting there Apple has said "this app is about this phrase". The remaining work is moving it somewhere more visible in the metadata, taking a related phrase into the title, or rewriting the subtitle around it. When a single metadata move wins a few places, and those places are the crossing from the second page to the first, the traffic difference changes by multiples.

Most of the guides here are about finding that band, ordering it, and spending it one phrase at a time. The reports show how the band differs by category: in games it is crowded and every place is expensive; in a niche productivity category the top of the band can be surprisingly empty.

Rival reviews: the source nobody looks at

Every keyword tool feeds from the same pool: search suggestions, category charts, app titles. That pool is open to everyone, so everyone's list looks alike - and that is exactly where competition is densest.

Users do not search in your marketing language. You say "personal finance management"; they search "where is my money going". You say "language learning platform"; they search "10 minutes english a day". Those phrases are not in your metadata, nor in your rivals' - but they are in your rivals' reviews, because the person writing a review uses their own words.

rankcusp scans rival apps' reviews, breaks the sentences apart and pulls out the phrases that look like searches. The "look like searches" part matters. People write "it really helped me" in a review; the phrase is grammatically sound and frequent, but nobody searches it on the App Store. So phrases containing first- and second-person pronouns are dropped. The same goes for strings of conjunctions carrying no meaning on their own, repeats of the app's own name, and runs of digits.

What survives enters the pool and gets the same treatment as everything else: popularity measured, difficulty computed, current rank searched. Coming from a review gives a phrase no privilege; it only makes low competition more likely, because it came from a place no tool looks.

Review mining gives you the words of the people using your product - not your marketing team's.
The most productive source is the rival most like you but larger; their review volume is higher.
Bad reviews work too: a feature found missing is the word of the person looking for it.
It has to be done country by country; the phrases from one app's Turkish and German reviews do not overlap.

Metadata: half of the 100 characters is going to waste

The indexable space Apple gives you is limited: the app name, the subtitle, and the keyword field visible only to the developer. The keyword field is 100 characters and in practice half of it is wasted. The causes are dully mechanical, which is exactly why they are entirely fixable.

The most common waste is repetition. Writing a word that already appears in the app name into the keyword field again gains nothing; Apple has already indexed it. The second most common is a space after a comma: every space is a character and it does nothing. The third is plural forms - Apple does not keep singular and plural apart, so writing both burns space.

A less known but more expensive waste is word order. The words you write in the keyword field combine freely with one another to form phrases; writing "language, learn, english" also indexes "learn english". So writing that phrase whole is less efficient than writing the two words separately.

And then there are the empty country fields. Most developers write metadata for one language and stop. But every country Apple is open in has its own keyword field, and most of them are indexed independently. The phrases you want to rank for in Turkey are not the ones you want in Germany; writing them the same wastes one of the two.

rankcusp counts each of those wastes and tells you how many characters you get back. What it tells you is not an estimate but a count: "three words that already appear in the title repeat in the keyword field, you can recover 27 characters."

Waste	How much comes back
A word from the app name repeated	The word's own length, per word
A space after a comma	One character per comma
Singular and plural of one stem	All but the shortest
A two-word phrase written whole	The space between them once split
An empty country field	All 100 characters for that country

175 storefronts and what scale means

Apple's app store is open in 175 countries and regions. That is not a marketing sentence; it is a fact that shapes the work of measurement. The same keyword's rank differs in every country, its popularity differs, and often the phrase itself is written differently.

The most obvious difference is language. But there is a subtler one: the same language being searched differently in different countries. And a subtler one still, in letter folding. In Turkish and Azerbaijani a capital I becomes a dotless ı when lower-cased; everywhere else it becomes a dotted i. Get that detail wrong and the phrase "AI" is stored as "aı" in the Turkish pool and never matches a user searching for it. That is why the function normalising phrases always takes the country as a parameter.

Scale also brings a cost. Every rank measurement is a request to Apple, and the requests per second are capped. So rankcusp measures per keyword rather than per row: every app tracking the same phrase in the same country is read out of one search. Rivals' ranks mostly come free, because they are inside a search that was happening anyway.

The category reports in this library come out of that scale. A category looks different in Turkey than it does in Brazil; which phrases are crowded and which are empty changes by country. If you are thinking about opening a new storefront, the first place to look is how many apps compete for the same phrases there.

How to use these texts

Most resources get read and forgotten, because a week passes between reading and doing. We suggest tying this library to a weekly loop.

Monday: measureRecord the current ranks of your app and two rivals in the countries you track. Without a starting point you cannot see the effect of anything you change.
Tuesday: pull the bandList the phrases you rank 11-30 for and order them by popularity. That list is the week's work; do not touch more than the top three at once.
Wednesday: make one moveApply one metadata change for the phrase you chose. Change the title, the subtitle and the keyword field at the same time and you will never know which one carried.
Thursday and Friday: waitApple's index does not update instantly. A change usually takes a few days to reach the ranking, and a second change inside that window ruins the measurement.
The following Monday: compareMeasure the same phrases again and compare with the previous week. If you won, note the move; if you lost, undo it. The next week's list comes out of that comparison.

What we do not write

A source's reliability is measured by what it does not say as much as by what it does. Here is what is deliberately absent from this library.

No promise of a guaranteed rank. Apple's ranking algorithm has not been published; nobody can guarantee a first place for a phrase, and anybody who does is not telling the truth.

No exact search volume. Apple does not publish absolute search volume. Our popularity values are relative and derived from Apple's own signals; we do not build the sentence "this phrase is searched 12,000 times a month", because we cannot.

No promised growth percentage. Publishing the average effect of a tactic requires long measurement across many apps. That measurement will be published when it accumulates; until then, giving a percentage would be invention.

No unmeasured claim about rival tools. The comparison texts contain only what anybody can verify: which tool uses which data source, and what it shows and does not show.

Frequently asked

Do I need to use rankcusp to read these?: No. All of them can be read independently of the tool, and the methods they describe can be applied by hand. What the tool does is repeat those methods every day across 175 countries, which is not practical to do manually.
How often is this updated?: When we measure a change in Apple's indexing behaviour, the affected texts are updated. There is no calendar-driven publishing plan; rewriting a subject that has not changed gains the reader nothing.
Why are there no numbers in the content?: There are numbers we measured and there are numbers we did not. The rank and popularity values in an app's panel are real measurements. But the data needed to say "this tactic gains this much on average" has not accumulated, so we do not build that sentence.
Is there a report for my own category?: Category reports are listed by format in the library. If the one you want is missing, you can run the same method for your own category in the panel: add the apps in the category chart as rivals, extract the shared phrases, and look at how they spread across the bands.
Are these texts available in other languages?: These long texts are written in Turkish and English. In the other languages the pages are live as they are; the long texts will open there as the translation is completed. We do not publish a half-translated page, because part of a page appearing in another language is worse for the reader than an error.