App Store keyword rank tracking: keep a useful position record

Define what your keyword rank tracker measures

Start with the app identifier and exact query. Record the intended storefront, device category, language context, observation time and source. Keep paid placement handling and the checked result range explicit. Use one row for one comparison, and retain the original export or observation separately so another person can reconstruct the claim. If the source cannot establish a condition, write unknown. A complete-looking sheet with guessed context is harder to interpret than an honest partial record.

A source can expose its own useful dimensions. Appfigures documents keyword rank queries with an app, country, iOS device and time range, plus daily or hourly granularity; hourly access depends on the plan. Those documented filters are reasons to preserve context in your export. They do not establish that every provider measures positions identically. Check the source definition and coverage before mixing observations, and restart the baseline when the measurement method changes.

Choose evidence for the question you are asking

A rank observation answers where the source saw an app for a query. It does not answer how many people searched for that phrase, how many downloaded the app or whether they completed a useful task. Keep those questions in separate columns or reports. A low-demand phrase can show an attractive position while contributing little acquisition. A relevant phrase with a difficult position can still belong in a research backlog; use product fit and documented demand evidence to prioritize it.

Apple's acquisition documentation reports discovery and downloads by sources such as App Store search, with territory and device filters. Its App Store search definition includes views and downloads from search ads. Source-level totals in that report do not establish an individual query's organic position. Read the rank record beside acquisition evidence using matching periods, while preserving each report's scope. Do not rename the search-source total organic keyword installs merely because both reports concern search.

Use a free App Store keyword tracking spreadsheet

Download the blank CSV and open it in your preferred spreadsheet application. Each row has places for the app, phrase, market, device, language, two observation times, source, metric definition, checked range, paid-placement handling and both positions. The final columns hold the interpretation and relevant listing changes. No account or email address is required. The file contains no live observations, formulas, macros or connection to your store account; enter evidence you are entitled to use.

Choose a small set of phrases that describe supported tasks in the released app. Use a repeatable review schedule appropriate to your source and release cycle. Preserve the original observation time when a report arrives late; the download time is a different fact. Before changing the listing, record its version, the relevant field and the hypothesis. Keep dates and sources beside the positions so a later editor can distinguish a new release from a new measurement method.

Compare positions without inventing missing ranks

For two numerical positions with matching scope, earlier position minus later position gives an observed improvement: 12 minus 8 equals 4. A negative result describes a decline: 7 minus 19 equals minus 12. Call this a change in observed positions rather than a percentage growth in traffic. Check that both values are positive positions under the same definition. Keep a stable phrase set when summarizing a round; adding easy phrases halfway through can change the summary without improving an existing observation.

If the app is absent from the checked range, leave the position blank and explain the range in the interpretation. Do not replace missing with zero, a guessed last position or an invented loss. The later appearance of the app can be useful evidence even when a numerical movement cannot be calculated. Treat US-to-GB, phone-to-tablet and provider-to-provider comparisons as separate records unless you have an explicit method for reconciling them. The fictional table shows the arithmetic and the exclusions; it is not a product case study.

Keep public samples and listing decisions in their place

A public catalog search is useful for inspecting names, publishers and related products. Apple's Search API documentation supports a country and a limited result count. It does not establish that array order matches a live on-device App Store position. RateMyApp's free keyword explorer labels its output as a public sample. Use it to develop relevant research questions; use an appropriately documented observation source for a position record. An absent sample result should not become a claim that the app never ranks.

Review several comparable observations before writing a conclusion. Keep other changes visible: pricing, paid campaigns, release timing and listing assets may move alongside metadata. A position change after a release does not identify which edit caused it. If discovery improves but useful downloads do not, investigate the listing promise and the first product task. Use the free conversion calculator with compatible counts, or prepare a focused private testing brief. Community testing can investigate understanding; it cannot verify search demand or purchase a public store rating.

Your next steps

• Preserve the app, exact phrase, storefront, device, times and source definition.
• Confirm matching scope before calculating earlier minus later position.
• Keep missing observations blank and record the checked range and interpretation.
• Review listing changes and acquisition separately; do not infer downloads or causality from positions.