Broad Match Testing: A Protocol That Won't Bleed Budget

Match Types17 October 202610 min readSearch Term Pro

Broad match is the one match type that can genuinely make you money you were not making and quietly lose you money you did not notice, often in the same week. Its job is to find converting queries your keyword list never thought to cover. Its failure mode is to spend a steady trickle on irrelevant searches while you mean to get around to checking the report. The difference between the two outcomes is almost never the match type itself — it is whether you ran it as a controlled test or just flipped it on.

This post is a protocol for the controlled version: a time box, a spend cap, a negative scaffold, a review cadence, and kill-or-scale criteria you set before you start. The aim is that your broad-match experiment ends on a date with a decision, not as a setting that drifts for months. If you are still deciding whether broad match belongs in the account at all, start with the broad, phrase and exact match decision — this post assumes you have decided to test it and want to do so without bleeding budget.

Box the test: a cap and a deadline, set first

A test without a cap and a deadline is not a test. Before you enable a single broad keyword, write down two numbers: the most you are willing to spend on the experiment, and the date you will judge it. The cap bounds your downside regardless of how the matching behaves, which matters because broad match's whole point is that you cannot fully predict the queries it will serve on. The deadline forces a decision, which is the thing most broad-match “tests” never actually reach — they just become permanent because nobody set a day to end them.

For most accounts the window is around two weeks. That is long enough for broad match to surface the new query space it exists to find — judge it on day two and you are reading noise — and short enough that the cap keeps the worst case small. If your account has low search volume, extend the window rather than raising the daily budget: a test is starved of data by too few days, not by too few dollars per day, and padding the budget just buys more of the same thin signal faster. Pick the numbers, write them down, and treat them as the terms of the experiment.

Isolate it in its own ad group or campaign

Put the broad keywords somewhere separate — their own ad group, or better, their own campaign — rather than dropping them into a structure full of proven exact and phrase keywords. Isolation buys a clean read: you can see the broad traffic's cost, conversions and search terms on their own instead of smeared across keywords that were already working. It also makes the spend cap self-enforcing, because a dedicated campaign budget is a ceiling the test cannot spill past into your core campaigns.

Isolation is also what makes the rollback clean. If the test fails, killing it is pausing one ad group, not surgically separating broad keywords from the phrase and exact ones you want to keep. Build the broad versions from keywords already proven in exact or phrase match, as practitioner guides recommend — TripleDart's broad match guide advises building broad versions of proven keywords in a separate structure rather than launching new keywords in broad match — so the experiment explores the neighbourhood of queries you already know convert instead of a cold guess into empty space.

Build the negative scaffold before the first impression

Broad match should not have to re-learn, on your budget, the waste your account already catalogued. Before you turn it on, build a negative scaffold: start from your existing account-level list, add the category errors that are obviously wrong for your business — free, DIY, jobs, salary, informational patterns that never convert — and fold in any competitor or off-product terms you already exclude elsewhere. This is the same proactive posture as building negative lists before the waste happens, applied to the one match type most likely to go looking for it.

Scope the scaffold carefully, because broad-match negatives ignore word order and can over-block. A broad negative like “free tool” blocks any query containing both words in any arrangement, which can catch a query you actually wanted — so keep the risky, generic negatives tight and reserve the wide ones for terms that are unambiguously waste. And understand what the scaffold is: a floor, not a wall. Broad match will still surface new waste no list could have predicted, which is the entire reason the next step is a daily review. Running broad match with no scaffold at all is the specific mistake behind broad match paired with no negative list; the scaffold is how you avoid funding the predictable waste while you hunt the unpredictable kind.

Watch the search terms daily, then weekly

During the test the search terms report is your instrument panel, and early on you read it daily. The first week is when the new query space broad match opened is widest and the waste risk highest, so a daily pass lets you negate clear junk the day it starts spending rather than discovering it after the cap is half gone. Read top-down by cost, negate the obvious category errors on sight, and leave the borderline queries alone — a query on three clicks and no conversion is not a verdict yet, and the significance question is the same one in how many clicks before you negate a term.

Once the obvious waste is negated and the term list stops changing shape, drop to a weekly review for the rest of the window. The daily cadence was a containment measure for the volatile opening; a stabilised test does not need it. As you negate, prefer patterns over single strings — grouping recurring waste the way pattern grouping beats listing one term at a time — so one negative closes a family of bad queries and your scaffold compounds instead of sprawling. The review is not optimisation yet; it is keeping the test honest so the final numbers reflect broad match's real performance, not a fortnight of un-negated noise.

Decide on the deadline: scale or kill

On the date you set, you make the call you defined in advance, and defining it in advance is what keeps it honest. Scale when broad match has surfaced genuinely new converting queries your exact and phrase keywords were not capturing: that is the upside you tested for, and the move is to promote those winners into tighter match types while keeping the broad keyword running as a discovery layer. The test has done its job — it found demand you were missing and handed you the queries to go capture deliberately.

Kill it when the end-of-window search terms are still dominated by irrelevant queries your negatives keep failing to pre-empt, when cost per acquisition on the broad traffic is clearly worse than your other match types with no sign of improving, or when the only conversions broad match produced are ones your exact and phrase keywords would have captured anyway. That last case is the subtle one: a test that merely re-buys traffic you already had is a failed test even though it technically converted, because it added cost and matching risk for no incremental demand. Pausing one isolated ad group ends it cleanly. Either way you finish with a decision and a bounded bill — which is the whole difference between testing broad match and leaking to it.

For the prior question of whether broad match belongs in the account at all, see the broad, phrase and exact match decision. For the failure mode this protocol is built to avoid, see broad match with an unpaired negative list. And for building the scaffold that goes in before the test starts, see proactive negative keyword lists.

Frequently asked questions

How do I test broad match without wasting money?

Run it as a bounded experiment rather than a setting you switch on and forget. Before you enable broad match, decide three things: a spend cap for the test, a fixed window to run it (commonly about two weeks), and the kill and scale criteria you will judge it against. Build the broad keywords in their own ad group or campaign so the test is isolated and reversible, pair them with a negative scaffold of waste patterns you already know, and review the search terms daily for the first stretch. The discipline is that the test ends on a date with a decision — scale the winners to tighter match types, or shut it off — instead of running indefinitely while you mean to check it. A broad-match experiment that has no end date and no cap is not a test; it is an open tab on your budget.

How long should a broad match test run?

Long enough to gather readable search-term data and no longer, which for most accounts means roughly two weeks before you make the scale-or-kill call. The reason is that broad match's whole job is to surface queries you did not bid on, and that surfacing takes a little volume — judge it on day two and you are reacting to noise. But the window also has to be short enough that a cap-plus-deadline keeps the downside bounded. Set the review cadence inside it: daily for the first week or so, when the new query space is widest and the waste risk highest, then weekly once the obvious junk is negated and the term list stabilises. If your account has very low volume, extend the window rather than the budget — you want more days of data, not more spend per day.

What negative keywords should I set up before testing broad match?

Build a negative scaffold from the waste you already know about before the first impression serves, so the test does not spend day one re-learning lessons your account learned months ago. Start from your existing account-level negative list, then add the obvious category errors for your business — free, DIY, jobs, salary, informational patterns that never convert — and any competitor or off-product terms you already exclude elsewhere. Be careful with broad-match negatives, because they ignore word order: a broad negative like "free tool" can block a valid query you wanted, so scope the risky ones tightly. The scaffold is a floor, not a wall; broad match will still surface new waste you could not have predicted, which is exactly what the daily review is for. The scaffold just stops you paying twice for waste you already catalogued.

When should I kill a broad match test versus scale it?

Decide both thresholds before you start, so the call is arithmetic and not a gut feeling at the end. Scale when broad match has surfaced genuinely new converting queries that your existing exact and phrase keywords were not capturing — that is the upside broad match exists to deliver, and the move is to promote those winners into tighter match types and keep the broad keyword running as a discovery layer. Kill it when, at the end of the window, the search terms are dominated by irrelevant queries that your negatives keep failing to pre-empt, when cost per acquisition on the broad traffic is clearly worse than your other match types with no sign of improving, or when the only conversions are ones your exact and phrase keywords would have captured anyway. A test that merely re-buys traffic you already had is a failed test, even if it technically converted.

Should I test broad match in a separate campaign?

Yes — isolate the broad keywords in their own ad group or campaign rather than dropping them into an existing structure. Isolation gives you three things a test needs. First, a clean read: you can see the broad traffic's cost, conversions and search terms without them blurring into your proven keywords. Second, containment: a dedicated budget cap on the test campaign enforces the spend ceiling automatically, so the downside cannot spill into your core campaigns. Third, a clean rollback: killing the test is deleting one ad group, not untangling broad keywords from phrase and exact ones you want to keep. Practitioners also recommend building the broad versions from keywords already proven in exact or phrase match, so the test explores the neighbourhood of queries you know convert rather than a cold guess.