How measurement works

The queue, the nightly window, the shared rate limit — and which actions cost a Play request.

Everything goes through one queue

No scheduled work calls Play directly. Rank checks, listing reads, autocomplete probes, review scans and category charts are all tasks in a queue, and a worker consumes them.

The only direct call left is adding an app, because you are waiting for the answer on screen — and even that goes through the same rate limit.

One rate limit for everyone

Every request to Play passes through a single ceiling shared by the whole platform, with jittered spacing. It is not per workspace and not per worker: adding worker threads does not make requests faster.

The slowness is deliberate. Crawling a store quickly is the shortest path to being blocked, and being blocked costs everyone a day of data.

If Play does answer with a rate limit, the spacing doubles and keeps doubling while it persists, rather than retrying into the wall. This was learned the hard way: a night of retrying once cost 143 keywords their measurement.

The nightly cycle

• 03:00-08:00 UTC — the plan runs in six passes, spreading the load instead of firing everything at once.
• Tracked keywords first, except dead weight, which is measured once a week; keywords nobody tracks are refreshed from what budget is left, oldest first, so nothing is permanently skipped.
• Listings and category charts are read in the same window at a lower priority.
• Scoring runs afterwards, from signals already stored.
• The notification pass runs at 09:00 UTC, after all of it.

A keyword is measured at most once a day. If two of your apps track the same term, it is fetched once and both get the result.

What costs a request and what does not

Costs one: measuring a rank, reading a listing, an autocomplete probe or harvest query, a review scan, a category chart, adding an app, asking Google Play for a developer's apps. Asking for similar apps costs two, and the wizard asks once when it suggests competitors. Either answer is kept for a day, so asking again the same day costs nothing.

Costs one indirectly: bringing terms in from any Discover source. Paste and AI ideas make no Play request to collect, but every term that lands in the pool is then measured like any other — a rank check, and a probe if there is no suggestion evidence for it yet.

Costs nothing: every score, the gap analysis, the coverage matrix, the ASO score and its trend, Try your copy, near-duplicates, share of voice, the visibility breakdown, the listing-change comparison on Activity, the printable report, the keyword page with its rank volatility, the competitor comparison, the measured-not-tracked suggestions with their Rising view, the Localizations card, the ratings and installs card, and exporting. They are all derived from measurements already taken, which is why they are instant.

When a Play request fails

Three different failures used to read as one message. They are told apart now, because what you should do about each is different.

• Not found — the request reached Play and there is no such app in that store. Check the package name and the store you picked.
• Rate limited — Play, or our own brake in front of it, is asking us to slow down. There is nothing wrong with what you typed; wait a little and try again.
• Not responding — the service that talks to Play is down. That one is ours, not yours.

The difference matters most in the add-app wizard and the free tools, where you are waiting for an answer on screen. A rate limit there used to tell visitors to check their package name, which sent them hunting for a mistake they had not made.

Nightly work never shows you any of this. An app that has been taken off Play ends its task as skipped rather than failed and is not retried three times a day — a delisted competitor should spend neither your measurements nor an operator's attention.

A request that times out is reported as not responding, never as not found. And when Play asks us to slow down during the add-app wizard, the competitor search stops there instead of firing its remaining searches — every other user's measurements share that ceiling.

Hourly limits per workspace

Actions that start a lot of work have an hourly ceiling shared by everyone in the workspace. They sit far above what a person does by hand; they exist so a script looping over different keywords cannot drain the shared queue.

• Measurement budget — 300 keywords an hour across discovery and re-measure: each keyword sent to measurement counts once, a harvest counts 30 and a review scan 26. Keywords skipped because they were measured in the last ten minutes give their share back.
• Discovery — Paste, Harvest, Reviews and sending terms to measurement: 60 an hour.
• Re-measure — the ↻ on a row and bulk re-measure: 120 an hour.
• AI — ideas, metadata drafts, Why this ranking?, and saving or testing a key: 30 an hour.
• Direct Play lookups — the add-app preview, the competitor search, adding a competitor and adding an app (one for the app, one for each new competitor): 60 an hour.
• Invitations: 20 an hour.

Hitting one returns a message that says which limit it was and to try again later; nothing you already have is affected. Read now has no hourly ceiling of its own; it has its cooldown. Re-adding an app you already have, or a competitor already linked, costs nothing: it does not go to Play again.

Separately, a workspace can create at most 1,000 new keywords a day through discovery. Terms beyond that are not recorded, and the panel says how many were left out.

→ Accounts, team and AI keys