Google Ads Offline Conversion Imports After June 15, 2026

Google now names the Data Manager API as the primary API for sending offline conversions to Google Ads, and since June 15, 2026 the Google Ads API has refused offline conversion imports from developers that had not used them between December 2025 and May 2026 (Google Ads Developer Blog). The Data Manager API requires SHA-256 hashing of emails, phone numbers and names (Google's formatting guide). Hashing alone does not remove HIPAA risk, because an event name that reveals a treatment type can still be PHI. Curve Compliance receives CRM and booking outcomes by webhook, credits each one to the original ad click, and sends Google Ads only a fixed list of fields under a neutral name such as Lead.

On June 15, 2026, the Google Ads API stopped accepting new adopters of offline conversion imports, including enhanced conversions for leads. Developers that had not imported offline conversions between December 2025 and May 2026 now get the error CUSTOMER_NOT_ALLOWLISTED_FOR_THIS_FEATURE. Developers already importing can keep using the Google Ads API while they move to the Data Manager API. If your CRM's imports return that error, those conversions are not reaching Google Ads.

That alone would make for a rough week. But it landed alongside two other developments that tell a bigger story about where healthcare marketing compliance is heading: a pixel settlement in Indiana that puts every mid-market hospital system on notice, and an FTC ban on location data sales that should make any healthcare app developer nervous.

Book a call. Seeing failed offline conversion imports in Google Ads and not sure what your CRM sends about each patient? Book a call with Curve.

What Google Actually Changed on June 15

Google announced the change on May 15, 2026, on its Google Ads Developer Blog. Access is set by developer token. Tokens that had not imported offline conversions between December 2025 and May 2026 lost access to offline conversion imports in the Google Ads API on June 15. Tokens already importing can keep doing so while they integrate with the Data Manager API, and Google's post gives no end date for them.

The replacement is Google's Data Manager API. It does the same fundamental job, accepting offline conversion events so Google Ads can optimize bidding toward leads that actually became patients. But the implementation requirements are meaningfully different.

Data Manager requires SHA256 hashing of all personally identifiable information before it hits Google's servers. It enforces stricter field-level controls on what metadata accompanies each conversion event. And it expects a different authentication and payload format than the old endpoint.

For most industries, this is a migration headache. For healthcare, it's a compliance minefield.

Why Healthcare CRMs Have a Specific Problem

The typical flow looks like this: a prospective patient clicks a Google ad, visits your site, fills out a form or calls your office. Your CRM (Athenahealth, NextGen, Kareo, or whatever you're running) eventually records whether that lead became a patient, booked an appointment, or completed a procedure. That outcome data gets sent back to Google so Smart Bidding knows which clicks are actually valuable.

The old API was loose enough that many healthcare organizations were sending conversion data with minimal preprocessing. Names, email addresses, phone numbers, appointment types, even diagnosis-adjacent metadata in custom fields. Technically functional. Legally indefensible under HIPAA if any of that data qualifies as PHI paired with a health condition indicator.

Data Manager's hashing requirement helps, but hashing alone doesn't solve the HIPAA problem. If you're sending a SHA256-hashed email address alongside a conversion event that reveals the type of appointment or treatment, the hash is irrelevant. The conversion event name itself can become PHI. Google now knows that a specific individual sought care in a sensitive category.

The migration to Data Manager is mandatory. But the migration done carelessly creates new HIPAA exposure that the old sloppy implementation also had, just with a different API format.

What a Compliant Migration Looks Like

The conversion data needs to be scrubbed before it leaves your infrastructure. That means:

Stripping appointment metadata. The conversion event that reaches Google should be generic, such as a qualified lead or new patient event, with no clinical context.

Hashing identifiers properly. SHA256 hashing of email, phone, and name fields, normalized and lowercased before hashing, which Data Manager requires anyway.

Removing location precision. Zip code is acceptable for Enhanced Conversions matching. Full address is not.

Filtering at the server level. This processing needs to happen in a controlled environment between your CRM and Google, not in a browser, not in a Google Tag Manager variable, not in a spreadsheet someone uploads manually.

Curve's server-side pipeline handles this by sitting between CRM webhooks and the Data Manager API endpoint. Patient identifiers get hashed, appointment metadata gets stripped to generic conversion labels, and the compliant event forwards to Google. Smart Bidding keeps optimizing. No PHI touches Google's servers.

We built this integration using Claude Code with MCP tool chaining, the same architecture we use for connecting CallRail, form platforms, and scheduling tools to ad platform APIs without leaking sensitive data. Small team, but the compliance infrastructure is enterprise-grade.

Hospital CIOs Are Done Buying Tools That Don't Prove Value

The API migration is hitting at a moment when hospital systems are already rethinking their entire tech stack.

A Becker's Hospital Review survey published in June 2026 found that health systems are taking a "more disciplined approach" to technology investments. Not because previous purchases failed outright, but because the accumulated complexity of a decade of point solutions is crushing operational teams.

The quotes from CIOs are telling. Tower Health, Sky Lakes Medical Center, and Reid Health all described the same pattern: years of acquiring AI-adjacent add-ons, security layers, analytics dashboards, and EHR plugins that each solved a narrow problem while adding integration burden and vendor management overhead.

The new posture is extracting value from existing platforms before adding new ones. CIOs want measurable, system-level outcomes, not feature-level promises from another vendor.

What This Means for Compliance Vendors

If you're selling a compliance tool to a hospital system in 2026, "we keep you HIPAA-compliant" isn't enough. The CIO's question is: what does this replace, what does it integrate with, and how do I measure whether it's working?

This is the environment Curve Compliance was built for. It replaces separate point solutions with a single server-side tracking layer that covers Meta CAPI, Google Enhanced Conversions, TikTok Events API, and now Data Manager migration. One vendor, one BAA, one integration. Pricing is usage-based; book a call for a quote.

The market matured from "buy everything that sounds compliant" to "buy what actually works and prove it." That shift benefits platforms with real integration depth over those selling surface-level pixel swaps.

Columbus Regional: $25.50 Per Patient, 20,763 Affected

On April 22, 2026, a federal court granted preliminary approval to a class-action settlement against Columbus Regional Health over Meta Pixel tracking on their patient portal. Final approval hearing is set for July 22, 2026.

The numbers are small in isolation. 20,763 class members covering patients who logged into the portal between 2017 and 2022. Each claimant gets $25.50 in cash. The total payout is modest by healthcare litigation standards.

The precedent is not modest.

Columbus Regional is a single-metro-area system in Indiana. Not a national chain, not a telehealth giant, not a Fortune 500 health company. A regional hospital. And plaintiff firms found it worth suing.

The Math That Should Worry Every Mid-Market System

The class was defined by a five-year window of portal logins. That's it. If you logged into MyChart (or whatever portal Columbus Regional was running) between 2017 and 2022, and Meta Pixel was present on those pages, you're in the class. No proof of harm required. No evidence that Facebook actually used the data. The pixel's presence on authenticated health pages was sufficient to allege unauthorized disclosure of PHI.

There are over 200 class-action lawsuits filed against healthcare organizations for tracking pixel violations. Kaiser Permanente settled for $47.5 million covering 13.4 million patients. Advocate Aurora Health paid $12.25 million. Mass General Brigham paid $18.4 million.

Columbus Regional proves the model scales down. Plaintiff attorneys don't need a massive health system to justify filing. Any organization running standard tracking pixels on authenticated patient pages is a viable target.

The defense is straightforward: no PHI in the pixel payload means no HIPAA claim and no viable class certification. Server-side tracking that strips identifiers before data leaves your servers removes the factual basis for these lawsuits entirely.

FTC Banned Kochava from Selling Location Data. Healthcare Apps Should Pay Attention.

On May 4, 2026, the FTC permanently banned Kochava and its subsidiary from selling sensitive location data linked to millions of mobile devices. It's the first permanent ban on geolocation data sales under Section 5 of the FTC Act.

Kochava was collecting precise GPS coordinates from mobile devices and selling datasets that could identify visits to reproductive health clinics, addiction treatment centers, mental health facilities, and places of worship. The FTC determined this constituted an unfair trade practice.

Why This Matters for Healthcare Mobile Apps

Most healthcare apps aren't selling location data intentionally. But many are collecting and transmitting it unintentionally through third-party SDKs.

Firebase Analytics, Braze, Segment, Adjust, and similar tools often auto-capture device location as part of their default event payloads. If your telehealth app uses Firebase for analytics and a patient opens it while sitting in a behavioral health clinic, that GPS coordinate is now associated with a health-related app session in Google's systems.

You didn't "sell" the data in the way Kochava did. But the FTC's enforcement theory doesn't require a sale. Unauthorized disclosure to a third party is sufficient for enforcement action. And if that third party is an ad platform, the HIPAA implications layer on top.

The fix is the same principle that applies to web pixels: process events server-side, strip location and device identifiers before forwarding to any third party, and maintain control over what data leaves your infrastructure.

Curve's server-side model applies to mobile SDK data the same way it applies to web tracking. Events flow through a controlled pipeline where location coordinates, device IDs, and session metadata get filtered before any conversion data reaches ad platforms.

The Common Thread

These four developments, the API change, the CIO spending shift, the Columbus Regional settlement, and the Kochava ban, all point in the same direction. The era of moving health-related data carelessly between systems is ending. Not gradually. Abruptly.

Google is requiring cleaner data inputs. Hospital CIOs are demanding fewer, more integrated tools. Courts are certifying classes based on pixel presence alone. And the FTC is issuing permanent bans on data practices that were industry-standard two years ago.

Healthcare marketers who built their measurement infrastructure on client-side pixels and manual CSV uploads are running out of runway. The migration to server-side, compliance-first tracking isn't optional anymore. It's the baseline requirement for running paid media in healthcare.

If your CRM's offline conversion imports have started failing, or if you're still running Meta Pixel on authenticated patient pages, the timeline for fixing this just got shorter.

Book a call with Curve to see how server-side tracking handles Data Manager migration, CAPI integration, and PHI stripping in a single pipeline.

Frequently Asked Questions

What replaced Google's offline conversion import API?

Google now names the Data Manager API as the primary API for importing offline conversions. It does the same core job, accepting offline conversion events so Google Ads can optimize bidding toward leads that became patients. It requires SHA256 hashing of personal identifiers before data reaches Google, enforces stricter field-level controls on the metadata sent with each conversion, and expects a different authentication and payload format than the old endpoint.

What changed for Google offline conversion imports on June 15, 2026?

From June 15, 2026, the Google Ads API no longer accepts new adopters of offline conversion imports, including enhanced conversions for leads. Developers that had not imported offline conversions between December 2025 and May 2026 get an error. Those already importing can continue while they integrate with the Data Manager API, which Google now calls the primary API for offline conversions (Google Ads Developer Blog). A CRM whose imports now fail leaves Smart Bidding without that outcome data.

Is hashing patient emails enough to make offline conversion uploads HIPAA safe?

No. Data Manager's hashing requirement helps, but a SHA256-hashed email sent with a conversion event that reveals an appointment or treatment type still tells Google that a specific person sought care in a sensitive category. The event name itself can become PHI. Conversion data should drop appointment metadata, use generic labels such as qualified lead or new patient, and leave out full addresses.

How can a healthcare practice send CRM outcomes to Google Ads without sharing patient data?

Process conversion data on a server between your CRM and Google, not in a browser, a Tag Manager variable or a manually uploaded spreadsheet. Curve Compliance receives outcomes through webhooks from booking systems, CRMs and call tracking, credits each one to the original ad click, and sends Google Ads only a fixed list of fields. Contact identifiers are off by default and SHA-256 hashed when enabled.