Keyword strategy: universe, launch set, push ladder

A keyword is a commitment, not an aspiration. Every term you index and every term you fund is a statement about what the product is for, and false statements are not neutral.

Most keyword work in this industry stops at a list. Somebody exports a few thousand phrases from a third-party tool, sorts by estimated volume, pastes the top forty into a title and a backend field, and calls the job done. That process produces a document, not a strategy, and it fails for a reason that has nothing to do with effort: it never asks which of those queries the product can actually win, whether the product can honestly serve the intent behind them, or what the system learns about your ASIN when it starts appearing for terms it converts badly on.

Keyword strategy in this framework is a sequence of narrowing decisions. You assemble a query universe from first-party sources. You group it into families so that thin data becomes readable. You classify every query on six dimensions, one of which is a hard truthfulness gate that removes terms from every field and every campaign permanently. From what survives you select a small launch set whose job is to teach the system what need you satisfy, and then you build a push ladder that spends against ranking only where conversion has already been proven. Everything else, the branch expansion, the event windows, the seasonality tagging, is maintenance on that spine.

The through-line is that a keyword is a commitment, not an aspiration. Every term you place in an indexed field and every term you fund is a statement to the retrieval layer and the behavioural layer about what this product is for. Statements that turn out to be false are not neutral. They generate clicks that do not convert, purchases that come back, and a conversion history the ranking system reads as evidence you lose that query. Model

This page sits downstream of the six-layer stack and upstream of the launch sequence and PPC and organic rank. It assumes you can already read the four-index diagnosis, because half the classification work here runs on those indices.

Building the query universe from eight first-party inputs

The tracked query set is assembled once at onboarding and refreshed quarterly, from eight sources, merged into one deduplicated universe where every row carries a tag recording which source contributed it. The tag matters later: it determines whether a row is allowed to carry a volume number, and it tells you whether a candidate arrived with proven demand behind it or merely as a string somebody's crawler found.

Two of these are consistently under-used. The advertising search-term report is treated by most accounts as a negative-keyword harvesting exercise when it is the only source in the list that shows you a query converting before you decided to target it. And return reason codes never enter keyword work at all in most operations, which is strange, because a return coded "not as described" against a query family is the cheapest available evidence that a term failed the truthfulness test months earlier.

The prompts report in the advertising console is a ninth input in some accounts, showing which assistant prompts a campaign triggered against, with impressions, clicks and attributed sales. Treat it as directional only. Observed The data is sparse, the lookback is short, and it should contribute candidate additions and trend reads rather than anything you would size a decision on.

Why third-party volume estimates never enter the volume maths

This is a policy, not a preference, and it has three legs.

Indexation comes before every other question

Three states get conflated constantly and they fail separately. Indexed means the term is associated with the ASIN and can retrieve it. Ranked means it retrieves it at a position a shopper would plausibly reach. Visible means it does that against real competition on a real results page. Diagnosing a ranking problem on a term that was never indexed is the single most common way to waste a month.

Full walkthrough of the failure modes is in indexation troubleshooting.

Query family construction

"Roll it up to family" is the standing answer to thin data throughout the measurement system, and it is worthless unless the clustering rule is fixed, because different rules produce different verdicts on the same export. One rule, applied consistently, recorded once per account.

Why single queries below the floor can only be read as families

The indices are ratios of your rate to the market's rate, and ratios computed on small denominators are noise wearing the clothes of a finding. The framework's floors: Model

At launch and across the entire tail, almost every query sits below these floors. Family-level reading is therefore the default state of the system, not the exception, and individual query reads are reserved for head terms with genuine volume. A below-floor number becomes usable evidence only when an independent signal points the same way: a price-median gap, a consistent family pattern, a delivery differential. Two signals in one direction is a diagnosis. One below-floor number is an anecdote.

Classifying every query on six dimensions

Each surviving query in the universe carries six labels. Together they decide whether it enters copy, whether it enters spend, and which rung of the ladder it belongs on.

1. Type

2. Funnel role, from the four indices

For every query or family, compute impression share, CTR index, cart-add index and purchase index. Each localises failure to a different surface: findability, the tile, the page, the offer. The classification here is simply where this query wins and where it loses, and it determines what kind of work the query needs. A family losing at the tile does not need more spend, it needs a main image. A family losing at the offer does not need copy, it needs a price or delivery decision. The full method is in the four-index diagnosis, and the SQP index calculator will do the arithmetic.

3. Price fit

Divide your selling price by the query family's purchase price median from the SQP export. Not the click price median: the purchase median, because it tells you what the market actually paid on that query rather than what it browsed.

4. Winnability

This is where the third-party competitor data earns its keep. For each family, look at who holds page one: how many holders there are, how deep their review moats run, and how good their listings actually are. Run the extractability and coverage lens over the top three. A family held by three listings with 4,000 reviews each and complete attribute coverage is a different proposition from a family held by three listings with 200 reviews and empty structured fields, even when the volume looks identical. Winnability is the inverse of the competitive moat, and it is the term in the ladder score that stops you funding a war you cannot win.

5. Coverage status

Does this term, or the concept behind it, have a home on the page already? Record which one: item name, item highlights, a bullet, the description, backend, a structured attribute, or absent. Absent is the interesting value. A high-value family with coverage status "absent" is a copy job. A high-value family with coverage in the description only is a promotion job. A family with coverage everywhere and a collapsing impression share is neither, and you should be looking at the four indices instead.

6. The promotion test

The sixth dimension is a gate rather than a label, and it deserves its own section.

The promotion test

One question, asked of every candidate before it enters any field or any campaign: can this product honestly serve the intent behind this query?

Not "could it plausibly be retrieved for this". Not "does it share a word with this". Can a person who typed this phrase, meaning what they obviously meant by it, buy this product and be satisfied? If the answer is no, the term is excluded from every indexed field and every campaign, and the exclusion is recorded as a dated yes or no against the term so that it does not quietly reappear next quarter when somebody rebuilds the list.

There is a second reason the test has hardened, and it is newer. The assistant layer reads your claims against your reviews, your Q&A and your structured data, and it will surface the mismatch inside its own answer about your product. Contradiction became more expensive than absence. Observed Under the old regime, a stuffed term you could not serve was a small drag on conversion. Under the current one, a claim the corpus contradicts can be quoted back at a shopper at the moment of decision, in an answer you did not write and cannot edit. Saying nothing about a use case you do not serve costs you the branches you were never going to win. Saying something false about it costs you the ones you were.

The practical consequences are unpopular with people who like big keyword lists. Terms that describe an adjacent product fail. Terms carrying a constraint you do not meet, a size you do not offer, a certification you do not hold, fail. Terms whose implied use case your return codes already show you failing at, fail, and those are worth hunting for specifically. Everything that fails leaves the register entirely rather than sitting at the bottom of it, because a list with a "maybe" column at the bottom is a list that will be mined by whoever writes the next backend field.

The Search Protection Register

The register is the artefact all of this produces, and it exists so that changes can be judged. The procedure that builds it, P-04 in the operator's kit, is triggered before any title, copy or coverage change ships, refreshed quarterly, and there is no exception to that ordering. It runs on the eight first-party sources above with third-party volumes excluded by policy, and it produces three dated, read-only artefacts: the register itself, the frozen family definitions, and the baseline SQP export.

One row per protected query or cluster, carrying: the query, its commercial value, organic visibility, the raw funnel counts (impressions, clicks, cart adds, purchases), paid coverage, conversion, and the on-page content element that supports it. Commercial value is volume times price times margin, and the register is ranked by it, which is why margin data has to come from the client rather than from any export.

The register's quality gate before any change ships: paid coverage populated on every row, family definitions frozen and dated, every intake candidate carrying a recorded promotion-test verdict, and the register itself read-only and dated. The prompt library that drives the analysis is part of the operator's kit rather than something we publish, but nothing about the artefact requires it: the columns and the rules above are the whole specification.

The mission map

Keyword work is now one branch of a tree the shopper never sees. A single stated mission fans out into multiple retrieval branches, and the pool a product is chosen from is assembled from all of them. Retrieved by many branches is the obvious fit. Retrieved by one is incidental. Retrieved by none is never evaluated at all, regardless of how good the offer is. Model

The question the mission map asks is: of all the queries a mission will generate, how many can this ASIN be found by, and how many can it truthfully win? Eight fields, scored per ASIN.

Score each field covered (explicitly stated on an indexed surface), implied (inferable but not stated anywhere) or silent (absent, so the assistant hears nothing when that branch fires). The objective is to move every legitimate field from silent to covered without fabricating a single claim. Most listings we audit cover two or three of the eight.

The keyword placement hierarchy

With roughly 200 characters of title real estate collapsing into 75 plus 125 structured characters, every term needs a new home. Assign each to the highest-leverage surface it truthfully belongs to, in this order.

The launch set

For a new ASIN, or an existing one being repositioned, the keyword decision that matters most is the smallest one: which five to fifteen exact terms you point the first spend at.

Selection criteria. A term joins the launch set only if it meets all of these:

• Type. Generic-constraint, or a generic head precise enough that the intent behind it is unambiguous. Not broad category heads.
• Promotion test. Passed, recorded, dated. No exceptions, and this is the criterion under most pressure at launch because launch is when somebody always wants to "just try" a bigger term.
• Price band: normal. Below 1.3×. Never launch into a mismatched battlefield. A new ASIN has no review moat and no conversion history to overcome a price gap with, and the resulting weak conversion is precisely the association you are trying not to write.
• Winnability. At least one page-one holder you can beat on evidence quality or on the offer. If you cannot name which incumbent you are taking the position from and why, you do not have a plan, you have a hope.
• Identity match. Direct match to the identity root in the 75-character name and to the defining spec. A launch term that does not match your stated identity is asking the system to learn two things at once.
• Coverage first. The term, or the concepts behind it, already live in the name, the highlights and the bullets before any spend starts. Spending on a term with no on-page home buys clicks against a page that does not answer the query.

Execution rules

The spend gate below still applies at launch exactly as it does in steady state. A query you cannot yet convert does not receive rank spend, it receives page work. The full day-by-day sequence sits in the launch sequence.

The push ladder

For an established ASIN, ranking spend is allocated through a ladder rather than a budget spread. The ladder has a gate at the bottom of it.

Below the gate, spend does not buy position. It buys data, and it should be labelled a data-buy and capped as one. The reason is mechanical: rank follows conversion, not spend. Advertising a query you convert below market on rents a position that gets reclaimed the moment the budget tapers, and the below-market conversion signal you generate along the way makes the organic problem worse than it was before you started. Model

Two supporting checks belong with the gate. Confirm the reading sits above the significance floor, roughly 100 of your own clicks, or read the family instead. And confirm the purchase index is not depressed by same-day attribution: purchases attach only within roughly a 24-hour window of the search, so high-consideration and premium SKUs systematically under-report purchase index. Benchmark within the price tier before declaring a conversion problem. That single caveat has reversed several of our own diagnoses.

Scoring: V × R × W

Every eligible family gets one number, the product of three terms.

Rank the families by the product. Take the top three to five as the active push list. One family equals one rung. The temptation to push six families simultaneously is the same temptation as changing six things in one measurement window, and it has the same consequence: results you cannot attribute.

Operating the rung

• Top-of-search placement emphasis. Across large brand samples top-of-search is the best-converting placement in roughly 70% of brands and the best on ACOS in 40 to 50%. Observed Reproduce the placement table on the account before acting on it: the shape recurs, the values do not.
• Budget shifts of no more than 20 points per week. Larger moves make the following week unreadable.
• One variable per measurement window. The rung is the variable.
• Paid coverage recorded in the register for every funded family, week by week, so that the eventual post-mortem is possible.

Graduation and demotion

Branch expansion after the roots hold

Once the head and root families hold page one, expansion runs along the classification axes rather than by adding volume. New constraint modifiers first: audience, occasion, context. Then complement adjacency. Then honest substitute-comparison content, handled on the page as a comparison you make, never by naming the substitute category as your own identity.

Every branch enters the same way. Coverage first, spend second. The branch gets a home in copy or an attribute, indexation is verified, and only then does it become eligible for the ladder. And it enters only with a promotion-test pass and a price-band check, because a branch is a new claim about what the product is for and every argument on this page applies to it exactly as it applied to the launch set.

Event positioning inside deal windows

Deal events matter to ranking because they concentrate conversion volume into a window the system reads as velocity. They only pay if the ASIN enters the window already ranked, which is why the prep runway is 60 days and not 60 hours.

One structural rule that survives every event calendar: never migrate a title inside a deal window.

Seasonality and temporal relevance

Query demand is not stationary, and a measurement system this precise will misread seasonal movement as performance movement unless seasonality is modelled explicitly at intake.

• Tag every tracked family with a seasonality profile at intake: flat, seasonal peak, event-driven, or occasion-driven. This tag is the reference that stops a normal Q1 decline being escalated as a ranking failure.
• Occasion branches activate ahead of demand, not with it. Gift, holiday and seasonal phrasing must be indexed and already converting before the surge, on exactly the same logic as event pre-ranking. Coverage built during a peak arrives too late to rank inside it.
• Compare year-over-year for seasonal families and period-over-period for flat ones. Mixing the two is the most common false signal in monthly reporting.
• Rule seasonality out before assessing anything else in a decline. Otherwise every autumn looks structural. The order is set out in rank drop diagnosis.

Weekly keyword operations

The whole system reduces to five recurring tasks. None of them takes long once the register exists, and skipping them is how accounts drift back into list-management.

What this means in practice

Five things you can do this week, in order of how much they will change.

Sources