The UI is fine, until it is not
Keyword Planner does its job if you are researching one account now and then: type in some seeds, set a location, skim the ideas, export a CSV. Nothing wrong with it at that scale, and I still open it for quick sense checks.
The problem is recurrence. My keyword research is rarely "one account, once". It is several brands, several markets, refreshed on a schedule, and the output has to feed real deliverables: restructure build sheets, negative keyword lists, asset briefs. Run that through the UI and you are not doing research any more. You are doing data entry with a research step attached. So I moved the whole thing onto the Keyword Planner API and have not gone back.
What the interface actually can't do
- Repeatable queries. There is no way to tell the UI "run these forty seed lists against these five markets, exactly the way you did last quarter". Every session is hand-assembled state: seeds pasted in, location switched, language switched, network toggled. Forget to reset one setting and this quarter's UK numbers get pulled with the last session's US location still applied. I have caught that mistake in my own work, which is part of why this tooling exists.
- Usable exports. Planner's CSV is a snapshot of the screen, with its settings baked into a couple of header rows. Columns you do not need, the grouping you do need absent, and every downstream use starts with twenty minutes of reshaping in a spreadsheet.
- Volume without errors. Copy and paste is a manual transform, and manual transforms fail silently at volume: a truncated paste, a duplicated block, a seed list run against the wrong market. None of these announce themselves. They just sit in the data.
What the tooling does instead
It is a Python tool built on the same official client library as my restructure scripts, and it does three jobs.
1. Query the Planner data directly
The service behind Planner, KeywordPlanIdeaService, exposes the same data the UI shows. GenerateKeywordIdeas takes seed keywords or a URL, plus a language and a set of geo target constants, and returns keyword ideas with their metrics: average monthly searches, competition, and the top-of-page bid range that stands in for CPC. Bids arrive in micros, so divide by a million before anyone else reads the sheet. And when I already have the keyword list and just need current numbers for it, the sibling call for historical metrics does that without the expansion.
Worth saying plainly: the API does not unlock better data. The volumes are the same bucketed averages the UI shows, wearing the same rounding. What it unlocks is running the same query five hundred times, identically, without a human holding the state.
2. Normalise everything into one structure
Every result lands in one table: market, seed set, keyword, volume, competition index, bid range, and the theme my grouping rules assign. Deduplication across seed sets happens once, centrally, instead of per-spreadsheet. The output is deliberately the input format of the next stage: the restructure script reads the same shape, negative keyword candidates fall out of the same table (high-volume terms the expansion surfaced that have no business converting), and asset briefs take the top themes per market.
3. Handle many markets in one pass
Markets are a list of geo and language constant pairs, seed lists are per-market tabs in the same workbook, and the tool loops the lot in one run. No settings to switch, no state to remember between sessions. The planning services carry much tighter rate limits than the reporting side of the API, so the tool queues, paces and retries rather than blasting requests. Slower per call, but it runs unattended, which is the point.
A concrete example
The same multi-market industrial account from the restructure post: five markets, per-market seed lists of a few dozen terms each, agreed with the client up front. One run returned a few thousand candidate keywords per market, with volumes, competition and bid ranges, already grouped into themes, in a single table.
Done manually, that is days per market: a Planner session per seed list, an export each time, the reshaping afterwards, and the settings-switching risk on every single session. Done this way, the machine part took a morning, and the rest of the time went where it should have gone all along: deciding which themes deserve their own campaigns, which markets need different treatment, and which of the surfaced terms go straight onto the negative lists.
The output fed three deliverables directly, with nothing retyped in between: the build sheet the restructure script consumed, the shared negative keyword lists, and the keyword themes for asset briefs.
Where this sits in the wider workflow
Research and build are usually separated by a copy-paste boundary, and that boundary is where accounts go quietly wrong: the keyword that never made it from the research sheet into the build, the negative list assembled from an older export, the theme that got renamed on one side but not the other.
The point of putting research on the API is not the API. It is that the research output and the build input become the same artefact. The pipeline runs: seeds agreed, tooling pulls and normalises the data, the judgement calls happen in one table, and the restructure script builds what the table says. When the account needs revisiting next quarter, the same run repeats against fresh data, and what changed is visible instead of vibes.
What this is not
None of this replaces judgement, and it is not meant to. The tool cannot know that a high-volume theme is strategically wrong for a client, or that two themes should merge because the sales team treats them as one kind of enquiry. Every keyword decision that matters is still a human decision.
What it removes is the repetitive manual layer underneath: the settings, the exports, the reshaping, the retyping. The judgement gets applied faster, to cleaner data, the same way every time. For recurring work across many accounts and markets, that is the whole pitch, and it is enough.