Google Ads Call Reporting for Clinics: PHI-Safe Setup

Yes, a clinic can run Google Ads call reporting without exposing protected health information, but not with the setup Google hands you by default, because the snippet that swaps in a forwarding number is the Google tag and it reports the page it loaded on. Curve is the HIPAA-compliant tracking layer that replaces that tag, keeps condition-bearing page data on its own servers, and forwards a hashed, neutrally named call conversion to Google Ads instead. A signed Business Associate Agreement is included on every plan.

What Google Ads call reporting actually does

Call reporting is three separate things wearing one name, and clinics get into trouble because they enable all three without separating them.

The first is the call asset, formerly the call extension. It attaches a phone number to your ad. When someone taps it on mobile, the call is placed from the search results page and Google can count it as a conversion without touching your website at all.

The second is the Google forwarding number. Instead of showing your real clinic line, Google shows a number it owns, routes the call through, and records duration, start time, end time, area code, and call status. This is how it knows a call happened and how long it lasted.

The third is website call reporting, and this is the one that matters for compliance. To count calls placed from your own site, Google needs to replace the number printed on your pages with a forwarding number. It does that with JavaScript. That JavaScript is the Google tag, loaded on the page where the number appears.

Most clinics print their phone number in the header. The header is on every page. Which means enabling website call reporting typically means loading the Google tag on every page of the site, including the ones that name a condition, a procedure, or a treatment program.

Where the PHI risk actually sits

The instinct is to worry about the call. The call is usually the least of it. Here is the risk in the order it actually bites.

The page the number sat on

When the Google tag loads to swap the number, it sends a request carrying the page URL and the referrer. A URL like /treatments/suboxone-induction or /services/ivf-consultation tells Google what the visitor was looking at. Pair that with the persistent identifier the tag sets and you have an individual associated with a specific health interest, disclosed to a vendor that does not sign a BAA for its advertising products.

This is the same mechanism behind the healthcare pixel litigation that has now produced more than $100 million in cumulative settlements. Advocate Aurora settled at roughly $12.225 million. None of those cases needed a phone call to happen. The page load was enough.

The recording and the transcript

Google Ads call recording is an account-level setting available in some accounts and regions. If it is on, Google holds audio of a conversation in which a patient describes symptoms, names a medication, or asks about a diagnosis. That is protected health information sitting with a vendor with whom you have no Business Associate Agreement. There is no field mapping that fixes a recording. The only correct answer is to keep the recording inside a system that will sign a BAA, which usually means your own phone platform rather than the ad account.

The caller number

A phone number by itself is an identifier, not PHI. A phone number tied to a call that originated from a page about a specific treatment is PHI, because the combination reveals something about the individual's health. Google's call reporting reports area code and call metadata rather than the full caller number in the interface, but the exposure question is about what your systems send onward, not only about what Google displays back to you.

The conversion action name

This one is free to fix and almost always overlooked. If your conversion action is named "Call from Bariatric Surgery Page," the condition is now a permanent label inside the ad account, visible in reporting, exportable, and shared with anyone who has access. Name conversion actions neutrally. There is no reporting benefit that justifies putting a service line in the label.

Google does not sign a BAA for Google Ads

Google Workspace can be covered by a BAA. Google Cloud can be covered by a BAA. Google Ads cannot. Neither can Meta's advertising products. This is the fact that decides the whole architecture, and it does not change based on how carefully you configure the account.

The consequence is simple. Anything that reaches Google Ads must be either not PHI at all, or a hashed identifier sent for matching purposes under a design where the health context never travels with it. There is no version of this where you disclose the condition and stay compliant because you were careful about it.

A PHI-safe call reporting setup

Here is the configuration that works. It preserves the reporting clinics actually need, which is knowing which campaigns produce real calls, without putting the condition in front of the ad platform.

1. Turn off Google Ads call recording. If you need recordings for quality or training, keep them in a phone system that signs a BAA. Do not let audio of a clinical conversation live in an ad account.
2. Keep call assets, they are the safe part. A call placed directly from the search results page never touches your website. There is no page URL to leak. Calls-from-ads conversions are the lowest-risk conversion in the whole account.
3. Do not install Google's number-swap snippet sitewide. This is the single most consequential decision. The default install path puts the Google tag on every page carrying your phone number, which on most clinic sites is every page.
4. Move number tracking to a call platform that signs a BAA. Use dynamic number insertion from your call tracking provider, not from Google, and confirm the BAA covers call metadata and recordings.
5. Send the call conversion to Google server-side. When a call qualifies, upload it as an offline conversion matched on the click ID, with a neutral conversion action name. Google gets the fact that a campaign produced a qualified call. It does not get the page, the recording, or the reason.
6. Rename every conversion action neutrally. Use labels like "Qualified Call" or "Call Over 60s," not the service line.
7. Decide what counts as a conversion before you build it. Duration thresholds are the usual proxy. A call over 60 seconds is a reasonable signal in most clinics. Uploading qualification from your CRM later is better, because it optimizes toward booked patients rather than long conversations.

Notice what stays intact. You still know which campaign, ad group, and keyword produced the call. You still get automated bidding fed with real conversion signal. What you give up is Google's convenience layer, and the convenience layer is the part that was creating the exposure.

Duration thresholds, and why they under-report

Counting calls over a set duration is the default because it is easy, and it is a blunt instrument. A patient who calls, gets the answer they needed in forty seconds, and books online later is a conversion your threshold discards. A wrong number that stayed on the line is a conversion your threshold invents.

The better pattern is to treat the call as an event and let the outcome arrive separately. Log the call when it happens. When the front desk marks it as booked in the CRM or EHR, upload that outcome as a distinct conversion with its own neutral name and its own value. Google then optimizes toward bookings rather than toward talkativeness.

This requires the click ID to survive from the ad click through to the call record. That is the piece that usually breaks, and it is worth solving properly rather than falling back to duration because the plumbing was hard.

Multi-location clinics have an extra problem

A group with fifteen locations usually has fifteen numbers, and often fifteen sets of location pages. Two failure modes appear.

First, the location page frequently doubles as a service page, so the URL carries both the site and the specialty. Second, teams build a conversion action per location for reporting granularity, and the location names accumulate in the ad account alongside whatever service the location is known for.

The fix is to carry the location as a parameter on a single neutral conversion rather than as a separate named conversion action, and to keep location-level reporting in your own analytics where it belongs. Our guide to attribution across multiple practices covers the rollup pattern in more detail.

How Curve handles call tracking without the leak

Curve is HIPAA-compliant ad tracking, attribution, and analytics built for healthcare, and it is designed around the assumption that the ad platform should never see the health context.

The Curve tracking script installs in place of the Google tag and the Meta Pixel. Events go to Curve's US-hosted infrastructure rather than directly to any ad platform. From there, what reaches Google Ads is decided explicitly rather than by default.

• Per-destination field mapping. Only fields you explicitly map forward to a given destination. The default is that nothing goes. Page URL, referrer, and form content stay behind unless you deliberately send them, which for a clinic means never.
• Identifier hashing. Email and phone are SHA-256 hashed to Google's Enhanced Conversions requirements before they leave.
• Neutral event aliases. The event Google receives carries a neutral name rather than the service line, so the condition never appears in the ad account interface or in an export.
• CallRail as an inbound connector. Curve connects to CallRail as an incoming webhook, so call outcomes flow into Curve and are matched to the originating ad click. CallRail is a source of truth about the call, not a destination Curve pushes patient data to.
• Bridge tokens. When a patient clicks from your site into a separate booking or intake tool, the attribution survives the jump, so a call or booking that happens on the other side still traces back to the campaign.
• Offline conversion uploads. Qualified calls and booked appointments can be uploaded in bulk from a CRM or EHR export with automatic click ID matching, up to 10,000 rows per file.
• 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 itself is the field mapping plus the hashing.

The practical result is that Google Ads receives a hashed identifier and a neutral conversion tied to a click ID. It does not receive the page the patient was reading, the recording, or anything that names the condition. For the wider server-side picture, see our guide to Enhanced Conversions server-side setup without PHI leakage.

Frequently asked questions

Can I use Google forwarding numbers at all?

For call assets in the ad itself, yes. That path never touches your website, so there is no page URL to disclose. For website call reporting, the forwarding number requires Google's snippet on your pages, and that is the part to avoid on a clinic site.

Is a phone number PHI?

On its own, no. It is an identifier. It becomes PHI when it is connected to information about someone's health, treatment, or payment for care, which is exactly what happens when a call originates from a treatment-specific page and both facts travel together.

Does turning off call recording make the setup compliant?

It removes the most obvious exposure and does not address the main one. The page URL disclosure from the number-swap tag happens on page load, whether or not anyone calls. Recording is worth turning off, but it is not the fix.

Will server-side call conversions hurt Smart Bidding?

No, provided the conversions arrive reliably and with the click ID attached. Google's bidding cares about volume, consistency, and timeliness of the signal, not about whether it came from a browser tag. Uploading qualified calls typically improves bidding, because the signal is closer to a real booking.

What about call tracking numbers on printed materials?

Offline numbers are outside the ad platform question entirely, but they still need a home that signs a BAA if calls are recorded or if call notes reference a reason for calling. Treat the call platform as a system handling PHI regardless of where the number was printed.

How long do I have to upload a call conversion?

Google Ads accepts offline conversion uploads within its click-ID lookback window, which is generous but not unlimited, and the click ID has to have been captured in the first place. Upload daily rather than monthly so a slow CRM process never becomes the reason a conversion is rejected.

Can I keep using CallRail?

Yes. CallRail signs BAAs and is a common choice in healthcare. In a Curve setup it acts as an inbound webhook connector, sending call outcomes into Curve where they are matched to the ad click and then forwarded to Google as a neutral conversion.

Where to start

Open your Google Ads account and check three things today. Is call recording on. Is the number-swap snippet installed sitewide. Do any conversion action names contain a service line. Those three answers usually describe the entire exposure, and two of them can be fixed this afternoon.

Then look at what your site is loading. The free compliance scanner shows which tracking scripts are running on your pages, including the Google tag that arrived with call reporting. If you want the call path rebuilt properly, with server-side collection, neutral event names, hashed identifiers, CallRail matching, and a signed BAA on every plan, visit curvecompliance.com and we will walk through your current setup with you. Related reading: routing ad clicks to your CRM without PHI.

Reviewed August 2026. Google Ads call reporting features and offline conversion import requirements change periodically. Verify against current Google Ads documentation before implementation.