DEV Community: VolkanGunay

App Store and Google Play keyword search volume

VolkanGunay — Wed, 04 Nov 2026 13:42:34 +0000

A keyword’s Apple Ads popularity, its search demand signal and your listing’s search traffic describe different things. Read each with its country and period; none of them is an exact number of searches.

Does the App Store publish keyword search volume?

No. App Store Connect shows your own app's impressions, product page views and downloads, broken down by source such as App Store search, but it does not show how often a term is searched across the store. Google Play Console likewise reports your own listing's traffic, not the market's demand for a term.

Signal	Store	What it is	What it is not
Apple Ads popularity	App Store	A relative score for a term in a country and period	An exact count of searches
Search demand signal	The store and country observed	Suggestions returned for the typed term at the recorded time	Proof that an omitted term has no demand
Your listing analytics	Your own app and report scope	Visitors, impressions or acquisitions as defined by the selected report	All searches for a term across the store

Read a popularity value

Apple Ads popularity is relative: a 60 is more popular than a 30, but neither is a number of searches. Keep the country and period with every value.

Period. Compare terms within the same period.
Scope. Check the country the score belongs to.
Missing data. A missing score and a low score are different states; neither is an exact search count.

The Apple popularity guide explains the score in more detail.

Google Play keyword search volume

Google Play Console’s store analysis describes traffic and acquisitions for your listing. Read the report’s definition, filters and period before using a figure in a keyword decision. Your listing’s search traffic is a different population from all searches across the store.

Read an estimate with its stated basis

When a tool labels a figure as monthly search volume, check the stated data source, estimation basis, country and period. Providers can use different inputs and definitions. A precise-looking number is not evidence that it is a store-reported count.

NOTE: Compare figures only when their metric and scope match. Keep an estimate, a relative popularity value and a missing observation visibly distinct.

Use separate observations in a keyword decision

Use suggestions to discover candidate terms in the target storefront, then check whether each term describes your app.
Read any recorded popularity value with its named field, country and reporting period.
Review competing apps and keyword difficulty separately. A difficulty estimate is a comparison aid, not a ranking probability.
After a listing change, compare your own dated ranks and listing analytics in the same scope. Movement alone does not establish the cause.

A dated study of 1,000 selected popular terms in five storefronts recorded Spearman ρ = 0.30 between suggestion count and popularity. Popularity came from the week dated 2026-08-09 and suggestions from 2026-09-14. The study does not turn either measure into search counts or describe every term in the store.

FAQ

Q: How can I see App Store keyword search volume for free?
A: Start with the suggestions visible in the target store and your own listing analytics. If you have access to a popularity report, retain its field name, scale, country and period. These observations describe different scopes; they do not provide an exact keyword search count.

Q: What is the search volume on the Play Store?
A: Read your listing’s visitors and acquisitions in Play Console with the selected report filters and period. These figures concern your listing, not all searches in the store.

Q: Is Apple's search popularity the same as search volume?
A: No. It is a relative score: a higher score means more searches than a lower one, but neither is a number of searches. Read it with its country and period.

Q: Why does each ASO tool show a different search volume?
A: Check each provider’s definition, source, period and estimation basis. Compare only matching scopes. A difference between two figures is not enough to establish which one is more accurate.

Sources

Apple Ads — Countries and regions —
Google Play Console Help — Understand and grow your app’s user base — 2026-10-13 · Listing visitors, acquisitions and search-term report scope; checked 2026-10-13.

Originally published on Storelift.

App Store keyword research, step by step

VolkanGunay — Wed, 28 Oct 2026 12:25:14 +0000

App Store keyword research is choosing the search terms your app should rank for by checking three things per term: do people type it (autocomplete), can you win it (the ten apps already ranking), and does it describe your app. The whole method works with the App Store itself; free tools only speed up the reading.

Step 1 · Write a seed list from the job your app does

Start with the words a stranger would type to find what your app does, not with your brand. Three places give you candidates without guessing:

Your own reviews. The words users choose to describe the app are often not the ones in your description.
Competitors' titles and subtitles. Those two fields are public and indexed, so they show which terms other apps are targeting on purpose. Read them for concepts; Apple's guidelines forbid using other apps' names as keywords.
Your category's vocabulary. Tasks, objects and outcomes ("split bill", "receipt", "expense"), not adjectives.

Keep single words and short phrases in the list. The keyword combiner turns a word list into two- and three-word candidates, and Step 2 shows which of them people actually type.

Step 2 · Check demand with App Store autocomplete

Type a candidate into the App Store search box to collect suggestion ideas for the selected storefront. A suggestion can help build a research list, but its presence does not establish an exact search count and its absence does not establish zero demand.

Keep suggestion evidence separate from Apple Ads search popularity. Record the storefront and date with either observation. The existing comparison of 1,000 popular terms across five storefronts found a rank correlation of ρ = 0.30; it does not turn suggestions into search counts. The sample and limits are recorded in autocomplete demand vs search popularity.

NOTE: Read autocomplete in the storefront you are researching. Suggestions in the US store say nothing about Germany or Turkey — each storefront is its own search engine.

Step 3 · Read the top-10 wall to judge difficulty

Review the apps currently competing for the term. Rating counts and title matches provide context for that result set; read them alongside relevance and the observed ranks.

The number beside a term is its ratings wall: it shows how established the apps you would compete with on that term are. Use it to compare terms; it does not tell you how many ratings you need or guarantee a rank.
Title matches — whether the competing apps carry the term in their app names. That shows competitors targeting it deliberately.

Read keyword difficulty as a comparison aid, alongside the competing apps and observation date. It is not a probability that your app will rank. Use the free keyword difficulty tool to inspect one term in one storefront before adding it to your research list.

NOTE: Hypothetical example: two relevant terms have different competing apps and rating counts. Record those differences and test a candidate against your own baseline; the competitor’s rating count alone does not establish whether you can rank.

Step 4 · Keep terms that are relevant, searched and winnable

Sort candidates into test now, research further and exclude. Test relevant terms with enough evidence to define a baseline. Research terms whose demand or competitive context is uncertain. Exclude terms that misdescribe your app; an absent suggestion alone is not enough to discard a term.

Relevance is not optional. Apple lists terms that are not relevant to the app, trademarked terms and competing app names among the keyword uses that lead to rejection, and a user who finds you through an unrelated term is unlikely to install.

Step 5 · Place the words: title, subtitle, then 100 characters

On the App Store, text relevance comes from the app name, subtitle, keyword field and primary category. Put the strongest target in the name (30 characters) or subtitle (30 characters), where people also read it, and use the hidden keyword field for the rest:

100 characters, commas between terms, no spaces after commas.
Don't repeat words already in your name, subtitle or category, and skip plurals of words you already have — Apple treats them as duplicates.
No filler such as "the", "app" or "game".

The keyword field tool packs a list into 100 characters and flags duplicates with your title; the rules are explained in the 100-character keyword field, and every field's limit is in App Store and Google Play character limits.

Google Play has no keyword field. Play reads the title (30), short description (80) and full description (4,000), and Google's own help asks for SEO best practices in the description within its spam policy.

Step 6 · Repeat per storefront, then measure

Each localization you add in App Store Connect has its own name, subtitle and keyword field, and some storefronts index a second locale next to their default — see ASO localization. Translating an English keyword list is not research: demand and the wall have to be read again in each country.

After the release, the only proof is rank. Check a single term with the free rank check; Storelift tracks rank daily to the top 200 on iOS and about 30 on Google Play across 175 storefronts, and its keyword discovery surfaces terms you already rank for but never tracked.

FAQ

Q: How do I do App Store keyword research for free?
A: Use the App Store itself: type candidate terms into search to see whether autocomplete suggests them, then open the top results and look at how established the competing apps are and whether they carry the term in their names. Free tools such as the keyword difficulty and keyword field tools only automate those readings.

Q: Is there a free App Store keyword research tool?
A: Yes, several parts of the job have free tools: keyword difficulty for the top-10 wall, keyword field for packing 100 characters, keyword combiner for candidates and rank check for your position.

Q: Can I see a competitor's App Store keywords?
A: Not the keyword field — Apple does not publish it, so no tool can read it from the store. You can see a competitor's name and subtitle, and you can see which terms they rank for by searching them.

Q: How many keywords can an App Store app target?
A: Apple publishes no recommended count. The space is fixed: 30 characters of name, 30 of subtitle and 100 of keyword field per localization, and words from those fields are combined when matching searches.

Q: Is Google Play keyword research different?
A: Yes. Play has no keyword field, so terms have to sit in the title, short description or full description, where users read them. Play search results list apps without their rating counts, so on Play you judge a term's difficulty from the titles and short descriptions of the apps already in the top results.

Originally published on Storelift.

"Dream interpretation" ranks 184 apps deep on iOS. Ours doesn't show up anywhere in that window.

VolkanGunay — Thu, 10 Sep 2026 13:00:37 +0000

We use our own product to track our own portfolio, which means we also get to watch it fail publicly. "Dream interpretation" is one of the terms where it does.

The number

For the keyword "dream interpretation," our reading of the iOS App Store goes 184 apps deep before the public search surface stops returning results. Our own app is not in that window — not at position 184, not anywhere inside it. The honest state for that keyword is "unranked within what we can read," not a low number we're rounding away from zero.

Why we're publishing our own miss

A tool that only ever shows you screenshots of its wins is showing you a curated product, not a working one. If Storelift can measure "184 deep, not present" for its own listing and say so plainly, that's a small piece of evidence that it'll say the same thing about your listing when the same thing is true — instead of quietly showing "not ranked in top 50" style softened language that avoids the harder truth.

What "184 deep, absent" actually tells you

It's not a death sentence for the keyword, it's a starting measurement. It tells you the term has enough competing supply to fill 184 slots of real search results (itself informative about competitiveness) and that whatever's currently working for the incumbents — listing text, review count, category fit — isn't yet working for this specific app on this specific term.

The fix from here is the same as it would be for any tracked keyword: check who's actually occupying the top of that 184-deep list, compare listing text and review counts against them, and treat "not present" as the baseline you're measuring improvement against, not as a wall.

We publish this kind of real, sometimes unflattering example on the landing page itself rather than only in curated screenshots. We build Storelift.

Spotify's Play Store page says "1,000,000,000+" installs. The real number is 3,091,946,484.

VolkanGunay — Wed, 09 Sep 2026 13:00:39 +0000

Google Play shows a rounded install bucket on every listing — "1,000,000,000+", "500,000,000+" — but the exact integer is sitting right next to it on the same page. Nobody reads it because the bucket is what's styled to be seen.

What we found reading past the bucket

Spotify's listing shows the familiar 1,000,000,000+ badge. The precise figure on the same page, same day, same storefront: 3,091,946,484. That's not a rounding difference — it's more than three billion over the bucket's stated floor, sitting inside a label that only promises "at least one billion."

We checked this wasn't a storefront artifact: Spotify returned the identical exact figure on both the Turkish and US listings. The install count is a global figure, not localized per country — which is itself worth knowing if you were assuming otherwise.

Why the bucket exists and why it's not enough

The rounded badge is a reasonable UI choice at the platform level — nobody needs "3,091,946,484" at a glance on a store listing. But if you're using install count as a competitive signal — sizing up a rival, benchmarking category scale, deciding if a market is saturated — the bucket alone actively misleads: two apps both showing "1B+" could be one billion apart from each other and you'd never know from the badge.

The general lesson

Any public store page with a rounded headline number is worth checking for the precise figure sitting next to it before you build an argument on the rounded version. It's usually right there in the page — Play does this consistently, not just for Spotify.

The full method and more examples, including how much the bucket compresses for a small app (10,000+ badge, 19,317 actual), are here: Play Store real download numbers. We build Storelift.

Same App Store, same keywords, 3.5x apart: a US vs Turkey review-wall comparison

VolkanGunay — Tue, 08 Sep 2026 13:00:37 +0000

We ran the identical method — same keyword set, same window, same "median rating count of whoever's in first place" metric — on two storefronts, and the answer came back 3.5x apart.

The two numbers

United States: median rating count of the #1 app, across 360 measured records, is 259.
Turkey: the same metric, across 530 measured records, is 73.

Same method, same day, same category mix. One storefront's entry wall is more than three times thicker than the other's, for what is nominally the same store and the same app category.

Why this isn't just "the US market is bigger"

Market size explains why the US has more competing apps, but it doesn't automatically explain why the review count you need to sit at #1 specifically is proportionally higher — that's a claim about the shape of user behavior (how readily people in each market leave ratings) intersecting with how concentrated attention is at the top, not just a headcount difference.

Whatever the underlying cause, the practical consequence is the same either way: a launch strategy calibrated against a US review-wall number and then applied unchanged to a Turkish storefront is calibrated against the wrong wall by a factor of more than three.

The actionable version

If you're deciding where to spend your first review-generation push, storefront choice changes the size of the wall you're pushing against by more than 3x on this data. Launching broad across lower-wall storefronts first, and treating the highest-wall storefronts as a later, better-funded phase, is the ordering the numbers support — even though "win your home market first" is the more common advice.

Full per-storefront table: how many reviews it actually takes to rank. We build Storelift, tracking rank and the competitive wall per storefront, not as one blended global number.

58% of the apps sitting in first place have fewer than 100 reviews

VolkanGunay — Mon, 07 Sep 2026 13:00:37 +0000

"You need hundreds of reviews to rank" is common enough advice that we assumed it would hold up once we actually counted. Across our measured sample, it doesn't hold for the majority of first-place apps.

The count

Looking at every keyword in our tracked set where an app currently sits in first place, 58% of those first-place apps have fewer than 100 ratings on the listing.

That's not "some outliers slip through with low review counts." It's the majority case. If your mental model is "triple-digit reviews minimum to contend for the top spot," it's wrong more often than it's right in this sample.

Why the advice persists anyway

The advice isn't fabricated — it's a real pattern in a specific slice: competitive, high-volume English-language terms in a handful of large storefronts, where review count genuinely does correlate with survival at the top because everyone else there also has hundreds or thousands. The mistake is generalizing that slice's rule to the whole keyword space, most of which doesn't look like that slice at all.

Once you widen the sample past the loudest, most-discussed keywords, the review-count wall turns out to be a local property of a specific competitive tier, not a universal gate Apple or Google enforces.

What to actually check before assuming a wall exists

Look at who's actually sitting in first place for your keywords, not for the keyword-difficulty conversation's favorite examples. If the incumbents on your specific terms have low review counts, spending your first months on review generation instead of on the listing itself, screenshots, or the keyword field is optimizing for a wall that doesn't exist on your terms.

The full sample and per-storefront breakdown behind this number is here: how many reviews it actually takes to rank. We build Storelift, which shows you the actual incumbents for each of your keywords instead of a single blended "difficulty" guess.

Our nightly measurement run reads 800 keyword country pairs before it stops

VolkanGunay — Sun, 06 Sep 2026 13:00:37 +0000

Every ranked position in Storelift comes from a scheduled run, not an on-demand scrape. The run starts at 02:10 UTC and reads up to 800 keyword×country pairs before its own gate stops it.

Why a hard ceiling on the collector itself

800 isn't a marketing number, it's an engineering constraint we set on purpose: the collector has its own internal time budget per run, and past a certain unit count within that budget, results start arriving from a slower, less fresh part of the window than the ones at the front. Rather than letting the run silently degrade past that point, it stops at 800 and the remainder rotates in on the following run.

The alternative — no ceiling, let it run as long as it takes — sounds more thorough and is actually worse: a run with no bound eventually produces "fresh" data that's hours stale by the time it's written, with no visible signal that it happened.

What "rotation" means in practice

Above the 800-unit line, keyword×country pairs aren't dropped, they're queued for the next scheduled pass instead of squeezed into a run that's already at capacity. If your portfolio's total pairs exceed 800, you see this directly as a rotation cadence rather than a promise of "everything, every night" that quietly isn't true past a certain portfolio size.

Why 02:10 UTC specifically

Fixed, published, boring on purpose — a scheduled time you can point at is falsifiable in a way "continuously updated" isn't. If a number looks stale, there's an exact timestamp to check it against, not a vague claim about real-time tracking that never quite gets audited.

We think a tool that states its own collection limits plainly is more trustworthy than one that implies unlimited capacity and hopes nobody stress-tests it. The schedule lives in our own infrastructure code, not just in copy — it's the actual cron. We build Storelift.

Apple's public search hands you 200 results. Google Play hands you 30.

VolkanGunay — Sat, 05 Sep 2026 13:00:37 +0000

If you're building anything that reads app store search results without an approved partner API, the two platforms don't hand you the same depth — and the gap changes what "we track your rank" can honestly mean on each one.

The actual ceiling

Apple's public search surface returns up to 200 results per query before it stops. Google Play's equivalent public surface tops out at 30. That's not a rate limit you can work around with more requests — it's the depth of the result set itself.

Why this isn't a rounding difference

200 versus 30 isn't "iOS is a bit deeper." It changes what a rank number even means. An app sitting at position 150 on iOS is a real, trackable position — you can read it, watch it move, alert on it. An app sitting at position 150 on Android is a position that public search literally cannot see; past 30, there's no honest answer to "where do you rank," only "you don't rank inside what's visible."

The design consequence

A tool that quietly treats both platforms the same — same depth claim, same "we track your rank" copy on both — is either silently capping iOS at 30 to match, throwing away real data, or silently reporting a false "not ranked" on Android past 30 when the honest answer is "outside the window we can read."

We chose to surface the asymmetry instead of hiding it: iOS tracking goes to 200, Android tracking goes to 30, and both numbers are stated, not implied. An app outside the Android window shows as untracked-at-this-depth, not as a fabricated rank or a silent zero.

What this means if you're evaluating any ASO tool

Ask what depth it reads on each platform, specifically. "We track your keyword rank" said about both platforms in the same sentence, without a number attached, usually means one of the two platforms is quietly worse than advertised. The number is the whole claim; without it, it's marketing copy.

We publish both depths on how we measure. We build Storelift — same read-depth honesty applied to every storefront we track.

We only alert on a 10-spot rank drop. Here's why 1 spot would be worse.

VolkanGunay — Fri, 04 Sep 2026 13:00:37 +0000

Rank tracking tools love to notify you the instant a number changes. We deliberately don't — our drop alert only fires once an app falls 10 spots or more between two measurements.

The tempting, wrong version

A 1-spot threshold sounds like the more attentive product. In practice it turns every notification channel into noise: App Store search rank has real day-to-day jitter that has nothing to do with anything you did — a competitor's own rank shifting, a re-index, sampling timing. Alert on every 1-spot move and within a week the alert is something people mute, which defeats the entire point of having one.

Why 10, specifically

10 spots is large enough to almost never be pure noise and small enough to still catch a real problem while it's still cheap to fix — a keyword field edit, a screenshot swap, a review-response push. Wait for a 30-spot collapse before alerting and you've waited past the point where the fix is simple.

The threshold is symmetric: the same 10-spot rule fires on a jump upward, so a keyword field change you made on purpose gets confirmed by the same mechanism that would have warned you if it went the other way.

The trade-off we're making explicit

This means small real movements — 3 spots, 5 spots — genuinely don't page anyone. That's intentional, not a limitation we're hiding: an alert system tuned to catch everything catches nothing anyone still trusts by week three. A threshold set high enough that every alert is worth opening is worth more than a lower one that trains you to ignore your own notifications.

If you're building anything similar — uptime, price, rank, any noisy time series — the question worth asking isn't "how sensitive can I make this," it's "what's the smallest move that's still cheaper to catch early than to catch late." That number is rarely 1.

We build Storelift, where this threshold governs both the in-app alert and the rank-drop email.

Our free plan caps out at 1 app, 15 keywords, 2 countries — on purpose

VolkanGunay — Thu, 03 Sep 2026 13:00:37 +0000

Most free ASO tiers are marketed as "free forever" and then quietly rate-limited somewhere you only discover after you've built a workflow around them. We went the other way: the free plan's ceiling is small and stated as a number, not a vibe.

The actual numbers

Storelift's free plan tracks 1 app, 15 keywords, across 2 countries. That's the whole ceiling — no "up to X, fair use applies" fine print underneath it.

We could have written "unlimited (fair use)" instead. It reads better on a pricing page. We didn't, for a specific reason: an unlimited-sounding free tier that's secretly capped by infrastructure cost is a promise you can't keep without either quietly throttling people or quietly eating the cost forever. Both of those end with a user finding out the hard way.

Why 15 and not 50

The number isn't arbitrary marketing math — it maps to what a single small app realistically needs to sanity-check before paying for anything. One app rarely has more than a dozen or so keywords worth tracking daily; 15 covers that with room, without covering "run your whole portfolio for free," which is the actual boundary a free tier exists to hold.

Two countries is the same logic applied to storefronts: enough to compare your home market against one expansion target, not enough to do full international rollout planning without paying for it.

What this buys you as a user

A stated ceiling you can check against before you invest a workflow in a tool. If 15 keywords and 2 countries genuinely cover your one-app case, the free plan is not a trial with a countdown — it's a permanent tier that does exactly what it says, and you can verify that by reading the plan page instead of trusting a testimonial.

The full plan breakdown, including where the paid tiers pick up, is on the pricing page. We build Storelift — a keyless ASO tracker, no API keys, no OAuth grant to your developer console required to start.

Apple lists ~130 App Store countries. Two of them don't actually work.

VolkanGunay — Tue, 01 Sep 2026 13:00:08 +0000

Apple publishes a list of App Store storefront country codes. We tested every single one against the live store instead of trusting the list, and two of them quietly don't return anything.

The problem with trusting a list

A storefront ID being present in Apple's published catalog is not the same claim as "searching in that storefront actually returns results." Endpoints get deprecated, storefronts get merged, regions get folded into others — and none of that necessarily shows up as a documentation update.

If you build a rank tracker (or any tool) that just iterates the published list, you inherit whatever is silently broken in it. The failure mode is worse than an error: it's an empty result set that looks exactly like "this app doesn't rank here," when the real answer is "this storefront doesn't work at all."

How we actually verified it

130 candidate storefronts, each checked three independent ways:

Autocomplete hints — does the storefront's search-suggestion endpoint return anything for a common term?
Language-code acceptance — does the lookup endpoint accept the storefront's expected language code?
Country-code acceptance — does the lookup endpoint accept the storefront's country code specifically (not /search, which has its own separate rate-limiting behavior that can falsely zero out working countries under load)?

A storefront has to pass on this independent evidence, not on being present in Apple's list. 128 passed. 2 did not — no error message, just empty where content should have been.

Why this is the boring, necessary part

This is not a glamorous finding. It's a data-plumbing check that most tools in this category skip, because checking it costs three separate API calls per country and the payoff is invisible until something breaks. But a silent gap in a catalog you didn't build yourself is a worse failure than a smaller, honestly-scoped catalog — because you can't see the edges of a gap you don't know exists.

The full breakdown of which storefronts are covered, and the exact three-endpoint method, is here: App Store storefront country codes, verified.

If your own tooling loops over a country list without checking whether the endpoint actually answers, it's worth spending an afternoon running the same three checks. Storelift publishes exactly which 128 storefronts it measures, and why the other 2 aren't in that list — not "everywhere," a list you can see the edges of.

In 13 of 19 App Store countries we track, the #1 app has zero ratings

VolkanGunay — Mon, 31 Aug 2026 13:00:08 +0000

Everyone optimizing for the US App Store is fighting a wall built out of hundreds of ratings. Most of the map is not walled at all.

The number

Across the 19 storefronts in our measurement set, we looked at the median rating count of whichever app currently sits in first place for a tracked keyword. In 13 of the 19, that median is exactly zero.

Not "low." Zero. The app in first place, for a real search term, in that storefront, on the day we measured, had no ratings at all.

Norway, Taiwan, Russia, Mexico, Malaysia, Japan, Vietnam, Israel, Ukraine, Australia, South Korea, Indonesia, Thailand — thirteen storefronts where showing up with zero social proof is not a disadvantage, it's the norm at the top.

Why this matters more than it sounds

The standard playbook for a new app is: win your home market first, then localize outward. That plan implicitly assumes review count is a cost you pay once and reuse — build the wall at home, then go compete somewhere the wall is lower.

This data flips the ordering. If your home storefront is one of the six with a real wall (US, UK, and a handful of others), you're spending your most expensive months first and reaching your cheapest wins last — or never, if you run out of runway before you get there.

The inverse plan — launch broad across the zero-median storefronts before investing anywhere near the size of the US wall — is not intuitive, but it's what the actual distribution of competition supports.

What a single "difficulty" score hides

A tool that gives you one global difficulty number for a keyword is compressing 19 different competitive realities into one. In 6 of them that number is meaningfully high. In 13, it should functionally be close to zero, and isn't.

That compression is not a rounding error, it's a category-wide simplification that this specific dataset makes visible. The full per-storefront table, and the method behind it, is here: how many reviews it actually takes to rank, by country.

We publish this kind of country-level breakdown because it's the thing a single blended score can never show you. If you're deciding where to launch next, check the storefront before you check the keyword — Storelift tracks rank per storefront, not as a global average.