Google Ads Data Manager: What Clinics Should Send

Through Google Ads Data Manager a clinic should send four things and nothing else: the click ID Google issued at the ad click, the conversion timestamp, a neutral conversion action name, and optionally a value. Hashed email or phone can be added when no click ID exists. Curve is the HIPAA-compliant tracking platform that assembles exactly that payload server-side and forwards it to Google, with per-destination field mapping that makes sending anything else a deliberate act rather than a default. A signed Business Associate Agreement is included on every plan. Data Manager's convenience is real, and for healthcare it is also the risk.

What Data Manager actually is

Google Ads Data Manager is two things sharing a name, and clinics need to keep them separate.

The first is a section of the Google Ads interface, a hub for connecting data sources so first-party data can flow into the account without anyone writing code. It offers connectors to warehouses and business systems, along with scheduled file uploads, and it is where customer lists, conversion imports, and audience data are managed.

The second is the Data Manager API, a programmatic ingestion endpoint that accepts conversion events. It takes click IDs or hashed user data, names the destination account explicitly in the request, and is the direction Google is consolidating its various upload paths toward. It replaces the older habit of having a separate mechanism for every kind of upload.

Both matter. The interface is where a marketing coordinator connects a CRM in four clicks. The API is where a properly designed integration sends a controlled payload. The gap between those two experiences is the entire subject of this article.

Why Google built it, and why that creates a problem for clinics

Signal loss is Google's problem. Third-party cookies degraded, browser tracking prevention tightened, and the browser tag stopped being a reliable source of conversion data. Google's answer was to make it easier for advertisers to send first-party data directly from their own systems.

The design goal was to remove friction. Fewer steps, fewer engineers, fewer reasons not to connect your CRM. For an ecommerce brand that is straightforwardly good.

For a clinic it inverts the safety model. The old model made sending data hard, and hard meant deliberate. A connector that syncs a CRM object in four clicks makes sending data the default, and the person clicking is often the one least equipped to judge which fields carry protected health information.

The uncomfortable part: the field selection screen in a connector setup is doing compliance work, and it does not look like compliance work. It looks like configuration.

What a clinic should send

Here is the complete list. If a field is not on it, the default answer is no.

• The click ID. The gclid, or wbraid and gbraid for privacy-restricted traffic. An opaque string identifying one click on one ad. It carries no patient identity and means nothing outside Google's systems. This is the ideal healthcare key.
• The conversion timestamp. When the outcome happened, in a timezone that matches the ad account.
• A neutral conversion action name. "Appointment Booked," not "Bariatric Consult Booked."
• A conversion value. Optional but valuable. A number with no label attached is not a disclosure. A number in a column called procedure_revenue alongside a procedure name is.
• A hashed email or phone, when there is no click ID. SHA-256, normalized to Google's specification, hashed before it leaves your infrastructure. Use this as a fallback, not as the primary path.

That is it. Four fields plus one conditional fallback is enough to close the loop between an ad click and a booked patient, feed Smart Bidding an accurate signal, and report on campaign performance honestly.

What a clinic must never send

These appear in real connector configurations, usually because they were already columns in the object being synced.

• Diagnosis, condition, procedure, or service line in any field, including the conversion action name, a custom variable, a campaign name, or a list name.
• Reason for visit or appointment notes. Free-text fields are the worst offenders because nobody reviews their contents before syncing.
• Medical record numbers, patient IDs, or chart numbers. An internal identifier stops being internal the moment it leaves.
• Dates of birth and full dates of service. Both are HIPAA identifiers on their own.
• Unhashed email, phone, name, or address. Hashing is not optional and it is not something to let the platform do for you at the far end.
• Page URLs and referrers. On a clinic site the URL frequently names the condition, which makes it the disclosure regardless of what else is in the payload.
• Provider or department names where a single specialty is implied. "Dr. Chen, Reproductive Endocrinology" is a diagnosis with a person's name attached.
• Insurance or payer fields. Payment for care is explicitly part of the definition of protected health information.
• Custom variables, unless you wrote each one yourself and can defend it. Custom variables are where teams put the thing they wanted for reporting, and reporting wants exactly the granularity compliance forbids.

The direct CRM connection trap

The single most consequential decision in a Data Manager setup is whether to connect the CRM directly.

Connecting directly means the connector reads objects from your CRM. Objects in a healthcare CRM contain what healthcare CRMs contain. Even when the initial field selection is careful, three things go wrong over time.

First, field selection drifts. Someone adds a field for an operational reason and it is included in a sync nobody re-reviewed. Second, free-text fields are unauditable by nature. A notes field passes review because it was empty when reviewed. Third, nobody owns the connector. It was configured once during onboarding by a person who has since left, and it keeps running.

There is a further wrinkle worth stating plainly. Google does not sign a BAA for its advertising products. Your CRM vendor may well sign one with you, but that BAA governs the relationship between you and the CRM. It does not extend to the ad platform on the other end of a connector, and connecting the two does not create a chain of coverage. The disclosure is yours.

The alternative is to put a controlled layer between the CRM and the platform, one that reads outcomes and emits a fixed, minimal payload. Then no CRM field can reach Google unless someone deliberately maps it, and field drift in the CRM has no effect on what leaves.

Customer lists deserve their own decision

Data Manager also handles customer lists for audience targeting, and the compliance question there is different from conversions.

A conversion upload says an ad click became an outcome. A customer list says these specific people belong together in a group. If the group is defined by a condition, membership in the list is the disclosure, and hashing the email does not change that. The hash is a pseudonym, not an anonymization, and the list's meaning is carried by the list, not by its contents.

A list called "Patients" is a business fact. A list called "Diabetes Program Patients" is protected health information organized for upload. If you need audience segmentation by service line, keep the segmentation on your side and send only what the platform genuinely needs to match.

How Curve sends to Google Data Manager

Curve is HIPAA-compliant ad tracking, attribution, and analytics for healthcare, and it is built to sit exactly where the controlled layer should be.

The Curve tracking script installs in place of the Google tag. Events go to Curve's US-hosted infrastructure rather than directly to Google. Curve captures the click ID at landing, holds it against the session, matches later outcomes to it, and forwards to Google Ads through Enhanced Conversions and the Data Manager API rail.

What governs the payload:

• Per-destination field mapping. Only explicitly mapped fields forward to a given destination. The default is that nothing goes. This is the structural answer to connector drift, because a field that appears in your CRM next quarter does not automatically appear in a Google payload.
• Identifier hashing. Email and phone are SHA-256 hashed to Google's requirements before leaving Curve's infrastructure.
• Neutral event aliases. Google receives a neutral event name rather than the service line, so the condition never enters the ad account interface or an export.
• Incoming webhooks. Your CRM posts outcomes to Curve as they happen, matched by email, click ID, or bridge token, with protected core attribution and contact fields that incoming data cannot override.
• Offline conversion uploads. Bulk CRM or EHR outcome files, up to 10,000 rows and 5MB, with automatic click ID matching.
• Bridge tokens. Attribution survives the click-out to IntakeQ, Calendly, or Jane App, which is where click IDs are most often lost.
• Reconciliation reporting. Curve reports what it sent against what Google recorded, so a batch that failed to land is visible rather than assumed.
• PHI-pattern detection. Payloads are inspected for PHI-shaped values such as SSNs, MRN-style identifiers, dates, and long numeric sequences, and flagged for review. This is a monitoring layer. The protection is the field mapping and the hashing.

Curve forwards to Meta CAPI, TikTok Events API, Microsoft UET, LinkedIn, GA4, Amazon Ads, and others through the same controls, so the rule you set for Google is not one you have to reinvent per platform. For the architectural picture, see our technical overview of conversion API architecture for HIPAA compliance.

Frequently asked questions

Is Google Ads Data Manager HIPAA compliant?

The question does not quite apply. Data Manager is an ingestion mechanism, not a covered service, and Google does not sign a BAA for its advertising products. Compliance is determined by what you put through it. A payload of click IDs and neutral conversion names creates no disclosure. A CRM sync carrying appointment reasons creates a serious one.

Can I connect my EHR to Data Manager?

No. Treat that as a hard line. An EHR is a clinical system and its objects are protected health information by default. If you need EHR outcomes in Google Ads, extract the minimal outcome record through a layer you control and send only click ID, timestamp, neutral name, and value.

Does hashing make it safe to send anything?

No. Hashing protects the identifier, not the meaning of the payload. A hashed email in a list named after a condition still discloses the condition. Hashing is one control among several, and it is the least important one compared with deciding what leaves at all.

What about consent mode?

Consent signaling is worth configuring and it is not a substitute for the decision above. Consent governs whether data may be used for advertising purposes. It does not turn a disclosure of protected health information to a vendor without a BAA into a permitted one. Configure both, and do not treat one as covering the other.

Should I use the API or file uploads?

The API when you can, because it is automated, timely, and does not involve a human exporting patient data to a spreadsheet that lives in a downloads folder. Scheduled file uploads are acceptable when the file is generated by a system rather than a person and contains only the approved fields.

Will sending less data hurt performance?

Sending fewer fields does not hurt. Sending fewer conversions does. Clinics conflate the two and end up sending too much of the wrong thing. Google's bidding needs volume, recency, and accuracy of conversions. It does not need to know the procedure. Feeding it real booked appointments with neutral names outperforms feeding it form fills with rich labels.

How do I audit what is currently going out?

Start in the Google Ads interface: review every data source connection, every conversion action name, every customer list name, and every custom variable. Then review what your website is loading, since page-level tags are a separate and usually larger exposure. Our guide to why client-side pixels create HIPAA violations covers that second half.

Where to start

Open Data Manager in your Google Ads account and read the list of connected sources out loud. If any of them is a CRM or a scheduling system connected directly, that is the first thing to unwind. Then read your conversion action names and customer list names. Service lines hide there more often than anywhere else, and renaming costs nothing.

The free compliance scanner shows what your website is currently sending to ad platforms, which is the other half of the picture. If you want a controlled layer between your systems and Google, with per-destination field mapping, hashed identifiers, neutral event names, click ID matching, reconciliation reporting, and a signed BAA on every plan, visit curvecompliance.com and we will review your setup with you. Related reading: HIPAA-compliant conversion tracking setup across Google, Meta, and Microsoft.

Reviewed August 2026. Google Ads Data Manager connectors, API surfaces, and enhanced conversions requirements change frequently. Verify against current Google Ads documentation before implementation.