Enhanced Conversions for Leads in Healthcare: What to Hash, What to Never Send

This is for health tech founders, growth leads and analytics engineers who advertise on Google in India and the Gulf and want better conversion matching without leaking health information into an advertising platform. Enhanced conversions for leads lets you send hashed contact details from a lead form, or from your CRM later, so Google can match a lead to the ad interaction that produced it. The question for a healthcare business is not only how to implement it, but what must never be in the payload.

The article covers the mechanism as Google documents it, the normalisation and hashing steps, a permitted-fields list you can adopt as policy, and the review points for India and the Gulf. It does not claim any lift from the feature. It assumes you already have conversion tracking in place.

Legal note: whether hashed identifiers are personal data under your jurisdiction's law, and what consent you need, is a question for your counsel and data protection officer. In India that includes the Digital Personal Data Protection Act, 2023 and its rules. In the UAE and Saudi Arabia, health data has its own regimes, and our pages on healthcare marketing in the UAE and Saudi Arabia outline the marketing side.

What the feature does

Google's developer documentation on enhanced conversions for leads describes uploading click conversions that contain hashed user identifiers, so a conversion can be matched to an ad interaction even where a click ID is missing. In Google's words the click ID (GCLID) is optional but recommended where possible, and conversions that contain only user-provided data are still accepted.

The prerequisites listed there: conversion tracking enabled, customer data terms accepted, and the Google tag configured to track form submissions and enable enhanced conversions for leads. The API checks two account settings, accepted customer data terms and enhanced conversions for leads enabled; both must be true.

There are two ways to run it. One captures hashed form fields with the Google tag at submission. The other uploads hashed identifiers from your CRM after the lead qualifies. The second is better for healthcare, because you control exactly which fields leave your systems.

What is allowed to be hashed

The identifiers Google's documentation covers are: email, phone number, first name, last name, street address, country, state, city and postal code. Google hashes with SHA-256 for email, phone, first name, last name and street address, and country, state, city and postal code are not hashed. Up to five user identifiers can be sent per conversion. Each identifier object carries one of: a hashed email, a hashed phone number, mobile ID, third-party user ID or address information.

For a health business, the minimum set is a hashed email, a hashed phone number, or both. Name and address add little for matching and add data you must justify. A sensible default is: email and phone only.

Normalise first, then hash

Google specifies the preparation before hashing. Getting it wrong produces hashes that never match, with no error to tell you.

1. Trim leading and trailing whitespace.
2. Lowercase the value.
3. Email: for gmail.com and googlemail.com addresses only, remove periods and any plus-suffix from the part before the at sign. Other domains keep periods and suffixes.
4. Phone: convert to E.164 format with the country code and a plus sign, for example the plus sign, country code and subscriber number with no spaces or dashes. For Indian numbers, add the +91 prefix and strip the leading zero. For UAE numbers, add +971 and strip the leading zero.
5. Hash the UTF-8 bytes with SHA-256 and output a 64-character lowercase hexadecimal string.

Test the function with known inputs. Normalising " Name@Example.COM " and "name@example.com" should give the same hash. A phone entered as "098765 43210" and as "+919876543210" should too.

The permitted-fields list

This is the policy that protects you. Write it down, get it approved, and enforce it in code with an allowlist rather than relying on people to remember.

The right-hand column applies to every place data can leak, not only the hashed fields. Event names, conversion action names, URL parameters, tag variables and custom variables are all places where diagnosis text can slip in.

One field deserves a separate warning. Google's documentation says not to include custom variables when importing enhanced conversions for leads; such conversions are dropped. Do not attempt to attach treatment categories there.

Where health data leaks in practice

1. URLs. A thank-you page URL such as one containing the condition or treatment name is sent to the tag. Use a neutral confirmation URL.
2. Form field capture. If the tag captures fields automatically, it may pick up a free-text message. Configure it to collect only the email and phone fields, or use the CRM upload route.
3. Event parameters. Developers add parameters such as service or specialty to a generic lead event. Review the data layer.
4. Conversion names. "IVF consultation booked" reveals sensitive information to anyone with ad account access. Prefer "Consultation booked", and track service line in your own analytics.
5. Audience building. Google's personalised advertising policy restricts remarketing and customer lists for Health ads. Read the policy before using any uploaded data for audiences. Enhanced conversions for measurement is a different purpose, but the account's configuration should not mix them.

Consent and the consent field

Google's documentation says to populate the consent field for ad user data, and warns that conversions may not be attributable without it. Capture consent on the form with clear wording, record it on the lead, and pass the status with each upload. In the UAE and Saudi Arabia, check regulator rules on advertising and health data before collecting. In India, a consent log that records what the person agreed to, when, and how to withdraw is the sensible baseline under the data protection law, subject to your counsel's advice.

If a lead withdraws consent, remove them from future uploads. You cannot recall what has been uploaded, so gate the export before sending.

A payload example

Here is a hypothetical event shown in words. A health tech company's CRM marks a lead as qualified. The upload row contains: the conversion action name "Qualified lead", the time of qualification with a time zone offset, a value defined in advance, the currency, a random event ID, a consent status, and two user identifiers: the SHA-256 hash of the normalised email, and the SHA-256 hash of the E.164 phone number. If a click ID exists, it is included. Nothing else is included.

If the row contained the speciality, the product plan the user asked about or the message they typed, the row would fail the permitted-fields test.

Choosing the upload route

Google's documentation says that from 15 June 2026 the Google Ads API's upload click conversions method rejects requests from developer tokens with no prior offline or enhanced conversion uploads, and recommends the Data Manager API. Google's Data Manager API upgrade guide confirms that API supports enhanced conversions for leads and offline conversions, and does not require a developer token. If you are starting now, build on the Data Manager route unless your agency already has an established Google Ads API integration.

Testing

1. Send a handful of test leads with known emails and phone numbers.
2. Compare your hash against an independent calculation.
3. Check Google Ads diagnostics for the status of the uploads and any errors.
4. Confirm that the account shows conversions for the test leads after the expected delay.
5. Inspect the raw payload in the network tab or server logs to confirm that only permitted fields are present.

Repeat the inspection whenever the form, tag or CRM changes.

Governance

• Assign an owner for the permitted-fields list.
• Put the allowlist in code, with a failing test if a new field appears.
• Review the account's conversion action names each quarter.
• Keep a data map for your data protection owner.
• Retain logs without payload content.

Our conversion tracking service and analytics tracking setup work include this review, and the Google Ads guide for healthcare places the feature in the wider account.

Where to start

1. Decide whether you will use tag-based capture or CRM upload; for healthcare, prefer CRM upload.
2. Write and approve the permitted-fields list.
3. Implement normalisation and SHA-256 hashing with tests.
4. Add the consent field and gate the export by consent.
5. Use neutral conversion action names and thank-you URLs.
6. Test, inspect the payload, and review quarterly.