Enhanced conversions for lead gen: worth the setup if your form data is clean?

Take a dental clinic where most leads come through a booking form that already collects email and phone. Enhanced conversions hash that first-party data and match it back to signed-in Google users, which recovers some conversions you'd otherwise lose to cookie gaps and consent. The cost is setup. The fields have to reach the tag cleanly, either directly or through GTM, and the thank-you page has to expose them. Reported match rates often look modest, and when they're low the bidding lift is usually small too.

My view is that if the form already captures clean email and phone, it's an afternoon of work and worth doing. If the data is scraped from a messy form, fix the form first. Bad match input just adds noise to a signal you're already reading imperfectly. Has anyone seen a real change in conversion counts after turning it on?

Form-first makes sense to me. I'd also split the match rate by field, because a phone match can look fine on its own while email is doing most of the work. And is the lift showing up only on consented traffic, or everywhere?

I'd push back on "fix the form first," at least for formatting problems. Most messy lead data isn't bad data, it's good data typed inconsistently: a trailing space, a capital letter in the email, a local phone number with no country code. Email mostly gets cleaned up on its own, so phone is usually the field that needs a small normalization step in the tag or a GTM variable before it's sent. That's an hour of work, not a form rebuild. A rebuild only makes sense when fields are missing or point at the wrong thing, like a shared inbox or a placeholder number. Those are two different problems, and people tend to lump them together.

Agreed on phone normalization. Google's enhanced conversions already handle some of it on their side, like lowercasing and trimming emails, so the fix that matters most is the phone country code. A local number without it simply won't match.

Only partly, and it matters if you hash the data yourself. Google does the lowercasing and trimming in its own pipeline, but if you build the hash in a custom HTML tag or on a server, a trailing space or a capital letter goes into the SHA-256 before anything cleans it up, and that hash will never match. For a dental clinic running GTM, that means normalizing in the variable first, then hashing. Send phone numbers in E.164 so the country code is always there: +44 7700 900123 becomes +447700900123, no spaces and no 00 prefix.

Agreed on E.164. For a clinic I'd normalize in exactly one place and run every lead through it, whether it arrives from the thank-you page, the GTM variable or a later offline import. Mismatches usually happen when two paths clean the same field differently, so the hash is right on one route and wrong on the other. Before you trust the numbers, push one test lead through the full chain and compare the hash you compute with what the tag actually sends.

Comparing the hash on your side only shows that your two paths agree with each other, not that Google matched the lead. Match status lives in the enhanced conversions diagnostics and match rate in your conversion settings, and both can lag a day or so, so run the test lead and wait before you judge it.

If you're using GTM's built-in enhanced conversions option instead of custom HTML, the tag hashes whatever string the variable hands it. That means you should check the variable's output, not the tag. Feed it a messy test value like " Jane.Doe@Clinic.co.uk " and "07700 900123", and confirm you get a trimmed, lowercase email and +447700900123 before anything gets hashed.