The resource centre

How a report differs from a guide

Reports show a field as it was measured. Little narrative, many tables; they are written to be looked at and decided on rather than read through.

A guide tells you what to do. A report tells you what you are facing. After a guide you change your metadata; after a report you decide which category, which country, or which group of phrases to go into.

That difference sets a report's structure. A report has no steps, it has distributions. Instead of "do this" it says "there is this much density here". You make the decision, because the right decision depends on your product and your resources; the report only provides the map.

Every number in a report is a measured number. We can count how many apps in a category carry a phrase in their title, because titles are public. We can read the rating counts of the apps at the top, because those are public too. But we do not write the revenue or install counts of the apps in that category, because those are not public and estimating them would be inventing.

So the kinds of number you will see in our reports are limited: counts, distributions, relative values and changes over time. The kinds you will not see are just as settled: market share, revenue, install count, conversion rate.

The most expensive mistake when reading one

The most common mistake with reports is putting the most crowded phrases on the target list. High density looks like a sign the phrase is valuable - "if everyone is going there they must know something". In fact density is usually the residue of the past: a phrase was popular years ago, apps wrote it into their metadata, the phrase lost its popularity, and nobody took it out.

The second expensive mistake is reading the countries as one list. In a report the Turkey row and the Brazil row sit side by side, but they are not describing the same phrase. The same word being written differently, searched differently and associated with different categories in two countries is the rule, not the exception.

The third is ignoring the strength threshold. A phrase can look perfect: low density, high popularity. But if the rating count of the top 10 is a hundred times yours, that phrase cannot be taken with metadata. The report says so; the reader usually skips that column.

The fourth is forgetting the report's date. A category report is a photograph of the day it was measured. If months have passed the densities have changed. Reports carry a measurement date and that date is not decoration.

• Do not mistake density for value; it is usually a pile of stale metadata.
• Read the countries separately; sitting in the same table does not make them the same thing.
• If the strength threshold is far above your rating count, skip the row.
• Check the measurement date; a density from months ago is no longer a density.

The method behind the reports

A report's reliability depends on its method being repeatable. Every report here goes through the same chain, and every link of that chain also runs in the panel.

The first link is the category chart. Apple's category rankings are public; a category's first hundred apps are read from there. That list becomes the report's universe - the report says nothing about apps outside it and does not claim to.

The second link is reading metadata. Every app in the universe has its name, subtitle and description read. Phrase extraction happens here: which words appear in which apps, which two- and three-word phrases recur. The country's letter-folding rules are applied during that extraction, or the same phrase would appear as two separate rows.

The third link is search. Each extracted phrase is searched once in that country and the first 200 are read. Density, title share and band spread are all computed from that single search. Making one request per search matters: the requests per second to Apple are capped, and a method searching once per row would tie coverage to the number of users.

The fourth link is popularity. A relative value derived from search suggestions is added to every phrase. Where no suggestion returns, the field stays blank and appears in the report as a short dash.

The fifth link is assembly. All of it is written into one table and the table is published with its measurement date. Run the same method again a month later and you get a comparable table - and that is where a report's real value is: not in one photograph but in the difference between two.

The numbers not in the reports

Knowing what a report does not measure matters as much as knowing what it does. The numbers below are in none of these reports and will not be - because Apple does not publish them, and estimating them would mean presenting an estimate as a measurement.

No install count. Apple does not tell third parties how many times an app was installed. The estimates in circulation are computed backwards from rank and rating count; the error bars are very wide and vary by category.

No revenue. In-app purchase and subscription revenue are entirely closed. We can see an app's price; we cannot see how many people paid it.

No absolute search volume. Apple does not publish how many times a phrase is searched in a month. Our popularity values are relative and we write them as relative everywhere; we do not build a sentence like "12,000 searches a month".

No conversion rate. What share of the people who saw an app's page installed it is visible only in that app's own developer account. It cannot be measured from outside.

All of those gaps look fillable - by estimating. We do not fill them, because the moment you write an estimate into a table the reader takes it for a measurement and decides on it. Leaving a cell blank is better than filling it wrongly.