Google Ads Offline Conversion Import: Clinic Guide

Offline conversion import is how a clinic tells Google Ads that an ad click eventually became a booked or attended appointment, and it is done by uploading the click ID Google issued at the moment of the click, paired with a conversion time and a neutral conversion action name. Curve is the HIPAA-compliant tracking platform that captures those click IDs server-side, matches them to CRM and EHR outcomes, and uploads only the fields Google needs, with a signed Business Associate Agreement included on every plan. The risky part is never the upload itself. It is the spreadsheet that gets built to feed it.

Why clinics need this more than most advertisers

An ecommerce advertiser sees the conversion in the browser. Cart, checkout, thank-you page, done. The value is known within seconds and Google learns from it immediately.

A clinic sees a form submission or a phone call, and then nothing useful for days. The form fill is a stranger who may or may not be a real patient. Somewhere between a third and most of them will not convert, depending on the specialty and how well the front desk follows up. The event that actually matters, the one with revenue attached, happens in a scheduling system that Google will never see.

If you optimize toward form fills, Google gets very good at producing form fills. That is not the same as producing patients, and in high-value specialties the gap between the two is where most of the wasted spend lives. Offline conversion import closes that gap by sending the outcome back to the platform that generated the click.

The three ways Google accepts an offline conversion

They are not interchangeable, and picking the wrong one is a common reason uploads silently fail to record.

Click ID uploads

Google appends a click identifier to the landing page URL when someone arrives from an ad. On the search network this is the gclid. For iOS app and privacy-restricted traffic you may see wbraid or gbraid instead. Upload that identifier with a conversion time and Google matches it back to the exact click, campaign, ad group, and keyword.

This is the cleanest option for healthcare, because the click ID is an opaque string with no meaning outside Google's systems. It is not an identifier of a person in any way you would recognize, and it carries nothing about the patient. No account enrollment is required for it to record.

Enhanced conversions for leads

When you do not have a click ID, Google can match on hashed customer data instead, typically a SHA-256 hash of a normalized email address or phone number. This only records if the destination account is enrolled in enhanced conversions for leads, which is an account setting rather than something the upload can turn on.

This path works, and it involves sending a hashed identifier that came from a patient record, so the surrounding controls matter more. The hash is not the problem. What the hash arrives alongside is.

The Data Manager API

Google's newer ingestion rail accepts both click IDs and hashed user data through a single endpoint, with the destination account named explicitly in the request. It is the direction Google is moving. We cover what it means for clinics in a separate guide on server-side Enhanced Conversions.

The part that actually breaks: capturing the click ID

Every offline conversion import project fails in the same place. Not the upload. The capture.

For the click ID to appear in your CRM months later, something has to grab it from the landing page URL, hold it through however many pages the patient browses, and write it into the record created when they finally submit a form or call. That chain breaks constantly.

• The patient lands on a page, browses to three others, and the parameter is gone from the URL by the time they reach the form.
• The form is an embedded widget from a booking tool on a different domain, and the parameter does not cross the boundary.
• The patient clicks out to IntakeQ, Calendly, or Jane App to book, and the entire session context is left behind on your site.
• The click ID is captured into a hidden field that the CRM silently drops because the field was never mapped.
• The patient calls instead of submitting, and nothing connects the phone call to the browsing session at all.

Diagnose this before building anything else. Pull fifty recent leads from your CRM and count how many carry a click ID. If the answer is under half, the upload is not your problem and building it will not help. Fix the capture first.

This is the specific gap bridge tokens exist to close. When a patient clicks from your site into a separate booking tool, a bridge token carries the attribution across the handoff so the conversion that happens on the other side still traces back to the original click.

What never goes in the upload file

Google's offline conversion import accepts a fixed set of columns. It does not accept, and has no use for, anything clinical. But the file is usually built by exporting from a CRM or EHR and deleting columns, and deletion is easy to do incompletely.

These must never reach the file:

• Diagnosis, procedure, or service line. Not in a column, not in the conversion action name, not in a campaign name that gets exported alongside it.
• Medical record numbers or patient IDs. Even an internal ID becomes a persistent identifier once it leaves your systems.
• Appointment notes or reason for visit. These ride along in exports far more often than teams expect.
• Dates of birth or full dates of service. Both are HIPAA identifiers in their own right.
• Unhashed email or phone. If you are using enhanced conversions for leads, the hashing happens before upload, not after.
• Provider names where the provider is a single-specialty practitioner, because the provider name is the diagnosis by implication.

The uncomfortable version of this: a CSV exported from an EHR and sitting in a marketing team's downloads folder is a bigger practical risk than the upload it was made for. It is unencrypted, it is on a laptop, it gets emailed, and it usually contains far more than anyone trimmed. If your offline conversion process involves a human exporting patient records to a spreadsheet, the process is the problem, not the destination.

Timing, values, and the rules that cause rejections

A few operational constraints decide whether your uploads record or quietly disappear.

1. Conversion time must be after click time. Obvious, and yet timezone mismatches between a CRM export and the ad account cause a steady trickle of rejections. Confirm both are in the same timezone before you trust a batch.
2. Uploads must fall inside the click lookback window. Google will not match a conversion to a click older than the account's window. Long consideration cycles in surgical or fertility specialties can exceed it.
3. Upload frequently. Daily beats weekly, weekly beats monthly. Smart Bidding responds to recent signal, and a monthly batch teaches the algorithm about a month that has already ended.
4. Send a value if you have one. A booked consultation and a booked surgery are not the same conversion. Value-based bidding needs the difference. Use a realistic average by service category rather than a single flat number, and keep the category out of the conversion action name.
5. Match the counting setting to reality. A conversion action counting every conversion will count repeat uploads on the same click. One that counts one per click will reject them. Know which you configured before you debug a discrepancy.
6. Use adjustments for corrections. If a booked appointment cancels, Google accepts a retraction rather than requiring you to live with the inflated number. Clinics with high no-show rates should be using this.

Naming conversion actions so the account stays clean

Conversion action names are permanent, visible to everyone with account access, and exportable. In a clinic account they are also the most common place a service line ends up written down inside an ad platform.

Bad: "Bariatric Consult Booked." "IVF Appointment Attended." "Suboxone Intake Completed."

Better: "Appointment Booked." "Appointment Attended." "Consult Completed." Or a neutral alias like "Conversion 3."

You lose no reporting, because the campaign structure already tells you which service produced the conversion, and that reporting belongs in your own analytics rather than in the ad account. If separating outcomes by service matters for bidding, use separate campaigns with neutral names and keep the mapping in a document only your team holds.

How Curve runs offline conversion import for clinics

Curve is HIPAA-compliant ad tracking, attribution, and analytics for healthcare, and offline conversion upload is one of its core paths rather than an add-on.

The Curve tracking script installs in place of the Google tag and the Meta Pixel. It captures the click ID at the landing page and holds it server-side against the visitor's session, which is what makes the later match possible. Events go to Curve's US-hosted infrastructure, not directly to any ad platform.

From there:

• Bulk upload with automatic click ID matching. Upload a CRM or EHR outcome export, up to 10,000 rows and 5MB per file, and Curve matches each row to the originating click rather than requiring you to assemble Google's format by hand.
• Incoming webhooks. Rather than exporting spreadsheets at all, your CRM can post outcomes to Curve as they happen, matched by email, click ID, or bridge token. Incoming data cannot override protected core attribution and contact fields, so a webhook cannot corrupt the attribution it is trying to complete.
• Per-destination field mapping. Only fields you explicitly map forward to Google. The default is that nothing goes. Columns that came along in the export and were never mapped simply do not leave.
• Identifier hashing. Email and phone are SHA-256 hashed to Google's requirements before forwarding, so no plaintext identifier crosses the boundary.
• Neutral event aliases. The conversion Google receives carries a neutral name, so the service line never enters the ad account.
• Bridge tokens. Attribution survives the jump to IntakeQ, Calendly, Jane App, or any separate booking tool, which is where most click IDs are lost.
• Reconciliation reporting. Curve reports what it sent to Google against what Google recorded, so a batch that did not land is visible rather than assumed.
• PHI-pattern detection. Uploads 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 also supports the Google Ads Enhanced Conversions path and the Data Manager API rail, so the same outcome data can reach Google whichever way your account is configured. A signed BAA is included on every plan.

Frequently asked questions

Do I need a BAA with Google to do this?

Google does not sign BAAs for its advertising products, so the answer is that you need an architecture where no BAA is required. Click IDs are opaque strings that identify a click, not a person. Hashed identifiers sent without health context are the standard mechanism the platforms are built around. What you must never do is send the condition.

Is a gclid protected health information?

No. It is a random string Google issued to identify one click on one ad. It carries no patient identity and means nothing outside Google's systems. That is precisely why it is the right key for healthcare offline conversion import.

What if most of my leads have no click ID?

Fix capture before building upload. Common causes are parameters lost across pages, forms on a different domain, and click-outs to booking tools. Bridge tokens address the last one. Enhanced conversions for leads with a hashed email can serve as a partial fallback, but a high click ID capture rate is worth more than any fallback.

How often should I upload?

Daily if you can automate it. Smart Bidding learns from recent conversions, and a batch uploaded weeks after the fact teaches the algorithm about traffic conditions that no longer exist. Automated webhooks beat scheduled exports for exactly this reason.

Can I upload appointment value?

Yes, and you should. Use a realistic average per conversion category so value-based bidding has something to work with. Keep the category out of the conversion action name and out of any column that travels to Google.

What happens if a booked appointment cancels?

Upload a conversion adjustment to retract or restate it. Clinics with meaningful no-show rates that never adjust are training Smart Bidding on conversions that did not happen, which quietly degrades performance over time.

Does this replace my website conversion tracking?

It complements it. Keep a lightweight, PHI-free lead event so Google has fast signal, then send the booked or attended outcome later as its own neutral conversion with its own value. Two conversion actions, two different jobs. See our overview of HIPAA-compliant conversion tracking setup for how the two fit together.

Where to start

Run the fifty-lead test. Export your last fifty leads and count how many carry a click ID. That single number tells you whether you have an upload project or a capture project, and almost every clinic that thinks it has the former actually has the latter.

Then check what your site is currently sending. The free compliance scanner shows which tracking scripts are running on your pages and what they are reporting. If you want click ID capture, bridge-token attribution across booking tools, webhook-driven outcome import, and neutral server-side uploads to Google Ads with a signed BAA on every plan, visit curvecompliance.com and we will look at your current setup with you. Related reading: routing ad clicks to your CRM without PHI.

Reviewed August 2026. Google Ads offline conversion import formats, lookback windows, and enhanced conversions requirements change periodically. Verify against current Google Ads documentation before implementation.