GA4 data-driven attribution at low volume: trust the split or reconcile with the CRM?

GA4 defaults to data-driven attribution now, and teams still argue about it. Take a dental clinic with around 30 bookings a month. The model needs volume to learn, so the credit split can swing a lot from week to week, and paid search numbers look different every time someone opens the report. The CRM, meanwhile, shows exactly which lead came from which form fill. At that size I think last click is easier to defend and easier to reconcile with actual bookings. DDA works better as a second lens for spotting which channels start journeys than as the number you optimize budgets against. Does anyone have a volume threshold where they felt comfortable switching?

Agreed that DDA is the wrong tool at 30 bookings a month. But last click reconciling cleanly doesn't make it right. It ties out with your CRM only because it hands most of the credit to brand search and direct, since people search the clinic name right before they fill in the form. So paid search gets blamed for journeys it actually started.

What I'd do is import the CRM bookings as offline conversions so the totals tie out, then look at channel share over a rolling 90 days so the weekly swings flatten. How many of those bookings come in by phone rather than through a form?

Phone is where this usually breaks, so check it first. Offline conversion imports match on a gclid or on enhanced conversion data, and a booking made by phone after a Google search often has neither. It lands in the CRM but never makes it into the import, so your totals look fine while paid search gets quietly undercounted. If you can't match most bookings back to a click, set up call tracking with a separate number per campaign before you trust any channel split.

Sasha's right that a gclid-only import will miss most phone bookings, but enhanced conversions for leads can close part of that gap without new numbers. The import can match on a hashed phone number or email, so if the front desk logs the caller's number in the CRM and that field goes into the upload, many phone bookings can still tie back to the campaign. It's usually a quicker first test than swapping website numbers, since per-campaign numbers only catch people who browse the site and then dial the number shown there. Someone who clicks an ad and calls straight from the results page, through a Google call extension or forwarding number, is a separate case.

Say the clinic takes 12 phone bookings a month and the desk always takes a number. Send those hashed and you'll see how many actually match. The ones that still don't are the ones worth tracking separately.

Worth running first, but formatting is what usually sinks it. The phone number has to be in E.164 (country code, no spaces, no brackets, no leading zero) before you hash it. If you send the desk's numbers raw, you get a low match rate that looks like a tracking problem when it's really just a formatting one.

Agreed on E.164, and I'd add one rule: track the match rate itself. Before any channel split influences budget, write down the matched share of CRM bookings, by source if you can. Then only move budget once that share has held steady for a few weeks. Otherwise you can't tell whether a change in paid search credit came from the ads or from the match rate moving.

Unmatched bookings aren't random. They pile up in phone calls and in people who searched the clinic name first, so a low match rate quietly pushes credit toward whatever the matched bookings happen to be. A formatting fix can also jump the match rate on its own, and that will look like paid search improving if you don't log it. Note the date you normalize the numbers and compare the periods before and after on the same basis.

Agreed, and the denominator is where this tends to go wrong. If you divide matched bookings by all CRM bookings, blank phone fields from the desk count as misses, so a low rate can just mean nobody typed a number, not that the match failed.

Split the bookings into three buckets: no contact data, contact data that didn't match, and matched. Only the middle bucket tells you anything about tracking. The first is a desk habit to fix, not an upload problem.

Numbers entered without a country code are a common cause of the second bucket. Normalize them with the clinic's default country code instead of dropping them, otherwise they vanish from the denominator too. Then log all three counts alongside the matched share, so the before and after comparison runs on the same basis.