← Blog

Build a Search-Terms Trend Database to Negate Smarter

Search Terms10 min readSearch Term Pro

Most search terms report reviews have no memory. You export the report, compare the terms against your keywords and this month's spend, negate what looks wasteful, and close the tab — and next month you start from scratch against a fresh export that has forgotten everything the last one told you. That snapshot habit is fine for catching obvious junk, but it is blind to the single most useful signal in the report: how a term is changing over time. A query that converted well last quarter and is quietly decaying now looks, in a single window, almost identical to one that has always been marginal. Treated as snapshots they get the same decision. Treated as time series they get different ones.

The fix is to stop throwing the export away. Snapshot the search terms report into a persistent table each month, keyed by the term, so every query accumulates a history you can read as a trajectory. This is a different artifact and a different decision rule from the point-in-time work the rest of a hygiene routine does — the n-gram analysis that finds wasteful patterns in a single export, or the clicks-before-negating threshold that fires on a term's current numbers. Those ask "is this term wasteful right now?" The trend database asks "which way is this term heading?" — and that question catches waste a threshold only registers after the money is gone.

The snapshot review versus the time series

A snapshot review is a comparison between one export and your current account state. It is good at two things: catching queries that are plainly off-intent for your offer, and firing a threshold — spend without conversions, cost per conversion above a ceiling — on a term's present numbers. Both are real and necessary, and a wasted-spend scorecard built on current-window thresholds catches most of the gross waste in an account. But a threshold is a line a term either has or has not crossed today. It cannot tell you that a term is three months into a steady decline and will cross the line next cycle, nor that a term below the line this month has been reliably above it for a year and is merely having a seasonal dip.

A time series answers exactly those questions, because it holds each term's own history. The practitioner value is not more data for its own sake — it is that trajectory converts two ambiguous snapshot cases into clear decisions. A decaying converter becomes a negate-or-investigate call you can make one cycle early, before you pay for the bad window that a threshold would need to see first. A volatile-but-seasonal term becomes a hold, protecting a query a single-window rule would wrongly cut. Industry write-ups on search terms review keep arriving at the same instruction — track terms over time rather than in isolation, and export consistently to build the history (Search Engine Land). The trend database is what makes that instruction operational instead of aspirational.

Building the database: export, key, append

The mechanics are deliberately boring, because anything elaborate does not survive contact with a monthly cadence. Export the search terms report on a fixed schedule with a stable column set — search term, match type, campaign, cost, clicks, conversions, conversion value — plus a snapshot date stamped on every row. Then append that export to one growing table rather than overwriting last month's. The single decision that matters is the key: normalise the term text (lowercase, trim, collapse whitespace) so the same query lands on the same logical row across months, and keep the snapshot date as a second dimension so you can pivot cost and conversions by term over time.

Automate the append or you will stop doing it. A manual export-and-paste habit reliably dies around the second or third cycle, which is why the durable versions of this are a Google Ads script writing straight to a Sheet on a schedule — the same approach vendors package when they bucket terms into "new," "rising," and "declining" groups (Three Chapter Media). You do not need their exact buckets; you need the append to happen without you. Key on the term, stamp the date, let it accumulate. After three or four cycles the table is worth reading; after a year it is the most valuable diagnostic asset in the account, because it is the only record of what your queries did that Google does not keep for you at term-level granularity.

Reading trajectory: rising, decaying, seasonal

Once the history exists, every term falls into one of a few trajectory shapes, and each shape maps to a decision. A rising converter — conversions and value climbing month over month while cost per conversion holds — is a candidate to promote: pull it into its own exact-match keyword or ad group so you can bid it deliberately instead of catching it as a broad-match accident. A decaying converter — conversion rate or value falling steadily while cost holds or rises — is the case the database exists to catch. It is not yet a threshold breach, but the direction is unambiguous, and that is enough to act on before the money is spent.

The shape that demands restraint is the seasonal or volatile term: weak this window, strong on a longer cycle. A snapshot rule would negate it on the bad month and lose the good one; the history tells you to hold. This is the same discipline as over-negating in a different frame — the danger is cutting a query that pays off outside the window you happened to look at. Reading trajectory is how you separate a term that is genuinely dying from one that is merely between seasons, a distinction the single-export review cannot make because it has only ever seen one season.

The negation rule for a decaying term

The decision rule for the trend database is narrower than a threshold and that is the point: negate confirmed decay, investigate volatility, leave seasonality alone. Confirmed decay means a term whose conversion rate or conversion value has fallen across at least two or three consecutive snapshots while its cost has not — the persistence is what separates decay from noise. When you see that pattern, you do not have to wait for the term to cross your spend-without-conversions threshold; the trajectory has already told you where it is going, and negating now saves the window a snapshot rule would make you pay for.

The one guardrail: confirm the decay is in the term and not in the account. A landing page change, a tracking break, or a bid-strategy shift can drag a term's conversions down without the query itself getting worse — negating the term then hides a problem you should be fixing upstream. Check that the decay is specific to the term rather than shared across the campaign before you cut. When it is genuinely the term, add it to the right negative list scope the same way you would any other negative, and note the trajectory in the database so a future review knows the term was retired on decline, not on a single bad read.

Watching patterns move, not just terms

Individual terms are the ground floor; the higher-value view is watching patterns move over time. Because the database is keyed at the term level, you can aggregate it into n-grams or intent clusters and track the trajectory of a whole pattern rather than a single query. A cluster of "free," "cheap," and "discount" variants creeping up in share month over month is a broad-match boundary loosening in slow motion — the kind of drift a pattern-grouped negative handles in one move, and the trend view tells you when the pattern has grown enough to be worth the grouped block rather than reacting to each instance.

This is where longitudinal tracking pays back most, because pattern drift is nearly invisible in a single export. Any one month, a handful of new junk variants looks like ordinary noise you negate and forget. Across six months, the same variants forming a rising cluster is a structural signal that a match type is expanding into territory you do not want, and the fix is a boundary, not a list of one-off negatives. The database turns a series of forgettable snapshots into the trend line that makes the structural problem legible — and structural fixes, applied once, stop far more waste than the running cleanup they replace.

Cadence, upkeep, and keeping it honest

The database is only as good as the discipline feeding it, so keep the cadence fixed and the schema stable. Monthly is the practical floor for most accounts; high-spend accounts justify weekly snapshots, but do not mix cadences in one table or your trajectory reads get distorted by uneven intervals. Resist the urge to add columns mid-stream — a schema that changes every quarter makes the history non-comparable, which defeats the entire purpose. Pick the column set once, stamp every row with its snapshot date, and let the table grow uniform. Boring and consistent beats rich and intermittent every time here.

Fold the trend database into the routine you already run rather than treating it as a separate project. Your monthly hygiene pass still does its snapshot work — the search terms report review, the current-window threshold checks, the obvious-junk negation — and the trend database sits alongside it, answering the one question the snapshot cannot: which way is each term heading. Over a year the two together change the character of the work. You stop rediscovering the same wasteful terms every month and start acting on trajectories, negating decay before it costs you a full window and protecting the seasonal converters a memoryless review would have cut.

For the point-in-time counterparts to this longitudinal workflow, see the n-gram search-term analysis for finding negatives in a single export, the clicks-before-negating threshold for deciding when a term has earned a cut, and the pattern-grouping guide for turning recurring junk into a single grouped negative.

Frequently asked questions

What is a search-terms trend database?

It is a persistent table that stores each month's search terms report export keyed by the query (or the n-gram), so every term accumulates a history of its cost, clicks, conversions, and conversion value across months. Instead of re-reading a fresh export in isolation each cycle, you compare each term against its own past. That lets you see a term's trajectory — rising, flat, or decaying — and negate on the direction of travel rather than on a single window's numbers. The database is usually just a Google Sheet or a small warehouse table fed by a monthly export or a Google Ads script.

Why isn't a monthly search terms review enough?

A monthly review compares this month's terms against your keywords and current spend, then negates whatever looks wasteful right now. It has no memory, so it cannot distinguish a term that has always been marginal from one that converted well last quarter and is now decaying. Those are different decisions: the first is a clean negative, the second is a term worth investigating before you cut it. Without a history you either negate too early and lose a recovering query, or too late and pay for a full bad window first. The trend database supplies the memory the snapshot review lacks.

How do I export the search terms report for trend tracking?

Export the search terms report on a fixed cadence — monthly is the common floor — with a consistent column set (search term, match type, campaign, cost, clicks, conversions, conversion value) and a snapshot date. Append each export to one growing table rather than overwriting, keyed on the normalised term text so the same query lands on the same row across months. A Google Ads script writing to a Sheet automates the append and avoids the manual-export drift that kills most tracking habits after two cycles.

When should I negate a term based on its trend rather than its current numbers?

Negate on trend when a term's conversion rate or value is falling month over month while its cost holds or climbs — that decay is the signal a snapshot threshold misses until the term has already breached it. Conversely, hold a term whose current window looks weak but whose history shows it converting seasonally or recovering, because a single-window negation would cut a query that pays off on a longer cycle. The rule is: negate confirmed decay, investigate volatility, and leave seasonality alone.

Does Google's built-in search terms insights replace a trend database?

No. Google's search terms insights surface rising and declining themes at the category level to help you find new demand, not term-level cost-and-conversion trajectories for negation decisions. They are an intent-discovery tool, not a wasted-spend ledger. A trend database keyed to your own exports keeps the raw term-level history — including the low-volume and decaying terms Google's aggregated view smooths over — which is exactly the granularity a negation decision needs.