An explanation of the keyword methodology

Why a method document is needed

The method document for a metadata audit: what it counts, what it does not, and where every number comes from. Nothing here is an estimate; all of it can be verified by hand.

When an audit tool tells you "you can recover this many characters", you need to know where that number came from. If you do not, you are either trusting it blindly or not at all - and both are bad.

This document writes down every step of the metadata audit. The point is not only transparency; the real point is that you can run the same audit by hand. A tool that automates something you could do yourself is one you can trust; a tool doing something you cannot is not.

The document's second job is drawing a boundary. There are things the audit cannot measure, and they are written down too. A tool saying what it does not measure earns trust in what it does.

The third is consistency. As long as the method stays fixed, two audits taken on different dates can be compared. When the method changes this document changes, and the change is recorded.

Count one: repeats from the name and subtitle

This is the largest waste item and the simplest to compute.

Step one: the app name and subtitle are lower-cased by the country's own letter-folding rules. This step is critical - in Turkish and Azerbaijani a capital I becomes a dotless ı, everywhere else a dotted i. Applied wrongly, the same word looks like two different words and the repeat is never found.

Step two: the words in both fields are split out. In writing systems that do not separate words with spaces - Chinese, Japanese - a separate boundary-finding step runs, because word boundaries are not marked by spaces.

Step three: the words in the keyword field go through the same process and the two sets are intersected.

Step four: the length of every intersecting word is summed, with the separating commas added. The resulting number is the recoverable character count.

This count is entirely verifiable. Put the app name and the keyword field side by side, count the shared words by hand, and you will arrive at the same figure.

Count three: stem repeats

The third item is the most language-dependent, and the one that finds the most in languages with rich suffixes.

Apple does not keep different forms of the same stem apart. Singular and plural, close inflections, near forms derived from the same root - writing all of them spends the characters of everything but the shortest.

The audit finds this by normalising the words in the keyword field and grouping the ones that reduce to the same stem. Where a group holds more than one word, everything but the shortest is flagged as waste.

Normalisation here is also country-dependent. Fold the same word one way in one country and another way elsewhere and you get two separate groups, both of them wrong.

This count has a limit: stem-finding is not equally reliable in every language. It finds more waste where suffixes are rich and less where they are sparse. The audit does not flag groups it is unsure about - a wrong suggestion is worse than no suggestion.

Count five: unused space

The fifth item is the most invisible form of waste: characters never used at all.

The keyword field is 100 characters, and not filling it is a loss too. Every character left empty is a word that was never indexed.

The audit shows how full the field is and how many characters are free. But with a warning: adding irrelevant words to fill the field is worse than leaving it empty. Ranking for a phrase describing something your app does not do means the arriving user does not find what they came for, and that means low-rated reviews.

So the audit marks empty space as an opportunity rather than a waste: "this many characters are free; these phrases from your pool would fit".

The largest unused space, though, is per country. If a country's keyword field is entirely empty, all 100 characters are being spent there and there is no visible sign of it at all. The audit reports country coverage on its own line.

• Empty characters are an opportunity, not a waste - but they must not be filled with irrelevant words.
• An empty country field means all 100 characters spent there.
• Filling the field with phrases for work you do not do costs you ratings.
• Country coverage is a separate line, and usually the item that finds the most.

How to read the output, and how the method is versioned

The audit produces a list, not a score. Not giving a score is deliberate: one number does not tell you which job to do.

Every row carries three facts: what was found, where it was found, how many characters it returns. With all three present the row turns directly into work.

Rows are sorted by recovery, so the top row is the correction that opens the most characters - usually app-name repeats. There are also unsortable rows: warnings like "this subtitle looks like a word list" or "this country's field is empty". They carry no character figure but their decision value is high.

The right way to use it: apply the top three rows, ship one release, wait a week, and compare ranks. Applying all of it at once makes it impossible to measure which correction did what.

As for the method changing over time: that is normal. Changing is not the problem; not saying it changed is. When the counts described here change, the change is written down and dated - because two audits from different dates can only be compared if the method is the same.

The place that changes most often is stem-finding, as language support widens and normalisation rules improve. The second is Apple's own rules: indexed fields and character limits change from time to time, and those changes are verified against Apple's own documentation rather than inferred from observation.