Tracking a keyword is tracking a country, a language, a location and a device, not just the words. In Market4 a tracked keyword's identity is the normalized query string together with those four dimensions. Track "seo reporting tool" for the United States on desktop, then track the same words for Germany on mobile, and you hold two separate records with two separate rank histories. That is deliberate. They are two different result pages, and one average across both would describe neither of them.
A tracked keyword record carries a fingerprint, and the fingerprint is what uniqueness is enforced on. It is built from the normalized query plus the country code, the language code, the free-text location and the device, with the result page fixed at page one. Nothing else goes into it. Tracking the same question twice while it is live is refused, because the second record would be the same series measured twice — but tracking it for a second country is not the same question, so it is allowed and gets its own history.
| Part of the identity | Example value | Change it and you get |
|---|---|---|
| The normalized query | seo reporting tool | A different keyword entirely |
| Country, Google's gl | us | A separate record with its own rank history |
| Language, Google's hl | en | A separate record with its own rank history |
| Location, free text | Austin, Texas, United States | A separate record with its own rank history |
| Device | desktop, tablet or mobile | A separate record with its own rank history |
Every one of those dimensions is optional when you create the record. Omitting the country means tracking wherever Google decides to put the site, which is a legitimate choice and a different measurement from pinning it to one market. What is not available is treating them as settings you can edit later without consequence: they are part of what the record is, so changing one would silently turn the series into a measurement of something else.
The same words asked of two countries return different result pages, so storing them as one record would produce a rank history that jumps between two rankings and belongs to neither. "best crm" asked of Germany on a phone is a genuinely different search from "best crm" asked of the United States on a desktop: different competitors, different local results, sometimes a different intent behind the same string. Stored SERP snapshots already made this decision, and tracked keywords reuse it rather than re-arguing it.
A cap on tracked keywords is a read-cost decision, not a licence tier. Here is why 500, what archiving actually frees, and why there is no delete.
Publishing writes to a database and tells search engines about an address. Preflighting is the step that asks the server answering that address whether it serves a page. What to check, which findings block an announcement, and why the check must never fail a publish.
Market4 turns one release note into a changelog page, a blog post, a mail-out and a week of social posts — and then tells you which of them brought anyone back.
That cap exists because reading performance fans out over every live keyword in a single pass: one Search Console report, every keyword joined against it, then the target pages looked up. A cap rather than a warning keeps that read to two bounded queries and one API call. It also means a keyword list multiplied across four countries and three devices spends its budget twelve times faster than the same list tracked once.
A tracked keyword carries two identities, and confusing them is the failure this design is guarding against. The normalized query is the join key: it is the string a Search Console query row matches on, and the string a blog post's target keyword matches on. Neither of those carries a locale, because Search Console reports a query, not a query-plus-device. The fingerprint is the series key, and it is what a stored SERP snapshot matches on.
Normalization for the join key trims the string, lower-cases it, and collapses runs of inner whitespace to single spaces. The collapse is a deliberate divergence from the snapshot fingerprint, which only trims and lower-cases. Google collapses whitespace itself, so "best crm" with two spaces and "best crm" are the same question to it; without the collapse, an invisible extra space in a pasted keyword would quietly break every join the record exists for.
A tracked keyword has no expiry date, and that is the last piece of the design worth knowing. Measurements expire in this product — usage logs and stored searches both age out — but a tracked keyword is a statement of intent rather than an observation. Deleting one after ninety days would delete the only record of what the site was trying to win, which is the question the whole feature exists to answer.
Because uniqueness is enforced on the fingerprint, and a second record with the same query, country, language, location and device would be the same series stored twice. Two records would then produce two rank histories for one ranking, and nothing would say which was authoritative. Change any one of the four dimensions and the record is a different series, so it is accepted.
Country, language, location and device are part of the record's identity rather than settings on it, so changing one would turn an existing series into a measurement of a different ranking. The supported move is to archive the keyword you no longer want and track the new combination as its own record, which keeps both histories readable and honest.
Only when the page meant to win it is not a blog post — a pricing page or a home page, for example. A blog post declares its own target keyword when it is created, so adding a second copy of that link on the keyword record would create two places to update and one of them would go stale as soon as an author retargeted the post.
Fewer than the cap, and fewer than you think. The cap is 500 live keywords per app, which is far past any list a person reads weekly. Every extra country or device multiplies the list without adding a new question, so the useful discipline is one record per query per market you actually sell into.
Search Console's regex filters are RE2 expressions, which is a deliberately smaller syntax than the one most regex tutorials teach. What RE2 leaves out, what to write in place of each missing construct, and the two things a filter does not change.
