Local Services Ads vs regular Search for a plumber: pay per lead or per click?

Anyone running Local Services Ads alongside regular Search for a plumber or HVAC business? LSA charges per lead instead of per click, and the lead is tied to a call or booking from your service area, so cost per lead often looks lower than Search. The catch is you give up a lot of control. Lead filtering and the dispute process decide how much you actually pay for, and your normal Search campaign can't show you the same picture. For emergency work I'd keep Search on the high-intent terms and test LSA in one zip cluster before moving much budget. Did LSA leads actually close better than Search clicks, or did they just look cheaper in the dashboard?

Cost per paid job is the number that matters here, not cost per lead. LSA counts calls and bookings differently from Search conversions, so a lower cost per lead can hide a worse close rate. Dispute credits fix the bill, but they don't give back the hours your office spends on calls that never convert. If job value from your field software or call tracking flows back into both channels, you can compare them on the same event. Are you getting that data back now, or are you still comparing on lead counts?

Cost per paid job is the right metric, but the join is where most people get stuck. A Search click carries a gclid, so when the job closes you can upload its value against that exact click. An LSA lead has no equivalent key, so you're usually matching on phone number. If the customer calls from a forwarded line or books through a different number, the match quietly drops. That makes your LSA close rate look worse than it is, and Search gets the credit by default.

Microsoft Ads has the same issue if you run it for the same trade, except the msclkid gives you a cleaner join for web leads, so the comparison is easier there. Before you trust any close-rate gap, find out what share of LSA jobs actually matched back to a lead. If that share is low, part of the gap may be your tracking and not the channel.

The phone match is the weak link, and it usually breaks on the callback. Say a homeowner calls at 9pm through the LSA number and hits voicemail, then the office calls back the next morning from the main line. The job record ends up with the office number, or the tech books it under a spouse's cell. The lead was real, but the phone match fails.

The fix is to capture the source at intake instead of counting on the number surviving three handoffs. Make "LSA" or "Search" a required field in whatever job software the office uses, and store the call or lead ID too if the software can hold it. Then the match doesn't depend on the number, and you can measure the match rate before deciding anything. If that rate is under half, I wouldn't trust any close-rate comparison yet.

Agreed, and the callback problem is the one most people miss. Split the match rate by LSA lead type too. Call leads usually come with a phone number you can match on, but message leads often don't expose the customer's number the same way. Blend them and a weak message-lead match can hide inside a decent overall rate.

Report the unmatched count right next to the close rate, not just the match rate. If 30% of message leads never join to a job, the close rate on the rest is built on the easier-to-track customers, so a clean-looking number can still mislead. Where the export carries a lead ID, key the job record to that instead of the phone number. Where it doesn't, a same-day, same-zip, same-service fallback match is better than nothing, as long as you tag those jobs as fallback so they don't carry the same weight as exact matches.

Tagging fallback matches is useful, but the tag doesn't tell you how often the fallback is wrong. For a busy plumber, same zip, same day and same service can fit several jobs at once. A good check is to pull a sample of leads that have both an exact match and a fallback candidate and see how often they point to the same job. How do you pick between candidates when more than one fits?