Broad match with Smart Bidding on a thin account: keep it or pin it to phrase?

Broad match plus Smart Bidding is one of those combos people either love or avoid. Google's pitch is that the bidding model uses its signals to decide which broad queries are worth paying for, so sticking to phrase or exact just starves it. My worry is what the model actually learns from on a small account. Say a plumber gets 20 leads a month. Broad starts pulling in queries like "plumbing jobs" or "plumber salary", and a handful of form fills from job seekers make those queries look fine on paper. The model learns from whatever converts, not from what you actually wanted. So I'd only run broad once the search term report is clean and the negative list is solid, and stay on phrase until then. Has anyone seen broad hold up on a thin account without that cleanup first?

Waiting for a clean search term report doesn't work at 20 leads a month. The data never gets clean enough, so you end up on phrase match indefinitely. I'd start broad with a negative list already seeded for job-seeker terms, set a conservative target CPA, and go through the search terms weekly.

Twenty a month is the real constraint, but whether broad works depends on whether those 20 forms are the same kind of lead. If every form fill counts equally, broad will learn from job seekers, and seeded negatives only catch the queries you can predict. If you can separate real leads from junk, by importing offline outcomes when a lead becomes a booked job, or by making the primary conversion a mobile call or a booked quote, then broad is a reasonable test. If you can't, I'd stay on phrase and fix the conversion first. A month of clean data on the right event will teach the bidding model more than a month of broad on a noisy one.

Kai's point about the conversion event is the one that matters most. On a thin account, I'd check the conversion action's "include in conversions" setting and its count setting before touching anything else. If a form fill and a call both count, and the job-seeker forms are coming through as "every" conversions, the model is learning from inflated volume. Making the job-seeker-prone form a secondary action, or counting one conversion per click on the primary action, keeps the signal closer to real leads. It's a cheap fix, and it's what makes Kai's test readable.

Agreed on the count setting. On Microsoft Ads there's a related thing to check: the conversion goal's optimization settings. Smart Bidding optimizes to whichever goal is marked primary, not the one you meant to prioritize. If form fills sit in the same goal as calls, a job-seeker form can pull the model off course the same way the count setting does.

Google has the same trap, just one level down. Conversion goals are set at the account level by default, but a campaign can override them, so a campaign you think is optimizing to calls may still have form fills as a primary goal. Open each campaign's conversion settings and check which actions it's actually using. On a thin account, one stray override can decide what the whole test learns from.

Agreed on the override. The Conversions column won't warn you, though. It sums every action included for that campaign, so a campaign optimizing to calls can show a healthy total that's mostly form fills. You only see it when you split the report by conversion action, and you should do that before the test starts. Changing goal settings usually resets learning, so an override you find in week three costs you the first three weeks of signal. And if calls end up as the only primary goal on a 20-lead account, make sure call tracking is actually firing on the calls you care about. Optimizing to a quiet event is its own problem.

Check the call duration threshold before you trust a calls-only goal. Google Ads only counts a call from an ad as a conversion if it runs longer than the threshold you set, and the default is 60 seconds. For a plumber or a clinic, plenty of real leads are quick calls to book or confirm a slot, so a 90-second threshold can quietly drop them. The call conversion will look quiet, and the optimizer ends up learning from the few long calls that remain.

I'd derive the threshold from your own calls instead of accepting the default. Pull a week of call logs, have someone on the sales side mark which calls turned into a booking or a quote, and note the shortest duration among those. Set the threshold a bit below that, but well above the band of wrong numbers and hang-ups, which is often under 15 to 20 seconds.

The threshold is a filter the optimizer never sees past. Set it too high and the model effectively learns "long calls" and nothing else. Set it too low and junk calls get through, which brings back the noisy-signal problem. And since changing it counts as a goal change, do this before the test starts, not in week three.