Tracking keyword ranks over time, and the one number that tells you if you are up or down

A single rank check is a photograph. It tells you where you sit for one term, in one storefront, at one moment, and it cannot tell you whether that is better or worse than last week.

The fix is obvious — snapshot it daily — and it creates a new problem the moment you track more than about five terms. You end up with twenty sparklines, some up, some down, and no answer to the only question you actually have: overall, am I up or down?

The sign error, first

Before any of the maths: rank numbers are inverted. Lower is better. Position 3 beats position 30.

That sounds too obvious to state until you write the comparison code, and then it becomes the single easiest bug to introduce in this whole area. A delta computed as new - old is negative when you improved. Sort ascending and your best keywords land at the bottom. Colour a positive delta green and you have coloured every decline green.

The convention worth adopting, and the one Appstro uses: delta is signed so that positive means improved. It is stated in the function that computes it and in the one that sorts by it, because a rule held in only one of those two places will eventually disagree with itself.

The visibility index

To collapse a set of keywords into one number you need a weighting, because positions are not linear. Moving from #40 to #30 is not the same event as moving from #4 to #3.

The weighting used here is 1 / sqrt(rank):

So #1 counts twice what #4 counts, and ten times what #100 counts. Sum it across your tracked keywords and you have a single figure that moves when your set improves.

It is an index, and the word is doing real work. It is not a percentage of traffic. It is not impressions. It is not a share of anything. Nothing public exposes App Store search volume, so no weighting of positions can be converted into people. What the index is good for is comparing one keyword set against itself over time — up is up, down is down, and the magnitude is only meaningful relative to your own history.

Anyone presenting a number like this as "visibility share" or "estimated traffic" has added a unit that does not exist.

The rule that stops it inventing a rise

This is the part that gets skipped, and it produces a very specific lie.

An aggregate trend compares the start of a window against the end. A keyword you added yesterday has no value at the start of a 30-day window. If you score that absence as zero, the keyword appears to have gone from 0 to something — a rise that never happened — and every keyword you add makes your trend look better.

So aggregateTrend only compares keywords with two or more snapshots. Keywords without a window-start value are excluded from the comparison and counted separately, rather than being scored as a gain.

The same discipline appears in every tool here: not enough data and zero are different answers. A trend built on the other choice rewards you for adding keywords, which is exactly backwards.

How the snapshot actually works

Nothing clever, and the simplicity is deliberate:

1. You flag an (app, keyword, country) combination on the rank checker.
2. A daily job resolves each distinct combination's position in Apple's search results and writes one row.
3. The tracked page renders 7, 30 and 90-day history per keyword, plus the aggregate.

Distinct combinations, not per user — two people tracking the same term for the same app cost one lookup, not two.

One consequence of daily snapshots worth expecting: a rank that moves every single day is normal, and reading meaning into a one-day change is reading noise. The windows exist because the trend is the signal.

Which keywords are worth tracking

Tracking is cheap but attention is not, and a board of eighty keywords is a board nobody reads. Three filters worth applying before you add one:

Would you change something if it moved? A term you have no plan for produces a line that goes up and down and generates no decision. That is a dashboard, not a measurement.

Is it a term you can plausibly compete on? Tracking a head term you sit at #180 for tells you nothing for months. The movement worth watching happens in ranges where a listing change can actually shift you.

Is it one term or three? Plurals, word order and near-synonyms often resolve to nearly the same result set. Tracking all of them triples your rows and adds no information.

A useful default is the terms already in your name, subtitle and keyword field, plus a handful you are considering adding. That gives you a before-and-after when you next edit the listing — which is the only clean experiment available here, since nothing public will tell you what a term is worth in advance.

On cadence: daily snapshots, weekly reading. Positions move constantly for reasons that have nothing to do with you, and checking daily converts that noise into anxiety. The 7, 30 and 90-day windows exist because the window is the signal.

What this cannot tell you

• Not traffic. No public source has App Store search volume, so no index built from positions can be converted into installs or impressions. The index compares you to your past self and nothing else.
• Not why a rank moved. A competitor shipped, an editorial placement landed, Apple reindexed, or your edit worked. The series shows movement; attribution is not in it.
• Not a rank you did not track. Coverage is exactly the combinations you flagged, and an unflagged term is not evidence of anything.
• Not a competitor's tracked set. You can check where any app ranks for a term you choose; you cannot see which terms they care about.
• Not tomorrow. A trend describes a window that has already happened.

The work

Track the ten to twenty terms you would actually change something over — not every term you rank for. Read the aggregate weekly rather than the sparklines daily, and when it moves, look at which keywords moved rather than at the index itself. The index tells you that something changed; only the rows tell you what.