The Google Ads Offline Conversion API Deprecation Is a Smart Bidding Event, Not a Dev Ticket

The Google Ads offline conversion import API deprecation is a lead gen migration problem, not an engineering ticket

Google is moving offline conversion imports out of the Google Ads API and into the Data Manager API and enhanced conversions for leads. Search Engine Land covered the announcement here, and most of the coverage has framed this as a developer task. Update the endpoint, ship the PR, move on.

That framing misses the real risk.

If you are running Smart Bidding on call or form-fill conversions, this is a bid-model continuity problem. Per Google’s offline conversion imports upgrade guide, Google Ads will accept conversions from website tags, Data Manager, and API connections in parallel during the transition. That overlap window exists for a reason.

tCPA and Max Conversions campaigns depend on a steady stream of conversion signal. Break the stream for 48 to 72 hours during a cutover and the model either pauses spend while it relearns or overbids on the recovery. Either way, you pay.

If you spend $25k to $500k a month and your call tracking platform pushes conversions back to Google, you have weeks, not months, to sequence this. The accounts that get burned will not be the ones that missed the deadline. They will be the ones that flipped the switch cleanly on a single date with no overlap window.

The Data Manager API does not inherit conversion history the way most operators assume

Here is the part most policy summaries bury. When you migrate from the legacy offline conversion imports endpoint to the Data Manager API or to enhanced conversions for leads, the new endpoint is treated as a separate ingestion pipe.

Historical conversion lineage does not carry over. Conversions you uploaded last quarter through the old endpoint live in the conversion action’s history. New conversions through the new endpoint route through a new connection. Smart Bidding works off the rolling conversion volume on the campaign, not a unified ledger of every conversion ever recorded.

What happens when that rolling stream goes quiet for two days during a cutover? On a tCPA campaign pulling 80 to 150 conversions a week, a 48-hour gap is roughly 20 to 40 missing signals. The model reads that as a demand drop. It tightens bids and starves the campaign, or it loosens bids on the recovery and you overpay for two weeks.

CallRail, Invoca, Ringba, and HighLevel ship single-destination pipes. None of them dual-write out of the box

Most call tracking and CRM platforms built their Google Ads integration as one vendor-managed pipe. CallRail’s Google Ads integration documentation walks through connecting a CallRail account to a Google Ads account and mapping calls to one or more conversion actions. Invoca, Ringba, and HighLevel each ship their own vendor-managed Google Ads integrations as the default path. The architectures differ under the hood, but the operational consequence is the same: the destination is controlled by the vendor, and dual-write is not exposed as a setting.

When the vendor updates that integration to point at the Data Manager API, it flips. The legacy stream stops, the new stream starts, and Smart Bidding sees the cliff.

Waiting for your call tracking platform to solve this for you is a losing bet. They will ship a Data Manager API integration on their timeline. You will turn it on. Your legacy stream will stop the same day. That is the exact cliff we are trying to avoid.

The operational fix is a webhook relay. You sit a small piece of middleware between your call tracking platform’s webhook output and Google’s endpoints. The relay receives one conversion payload, hashes the PII (personally identifiable information, meaning email and phone), and posts the same payload to both endpoints.

Three implementations work in the field:

• A multi-step Zapier zap. Trigger on the call tracking webhook. Step one: format the payload. Step two: POST to the legacy Google Ads API endpoint. Step three: POST to the Data Manager API. Cheapest to build, easiest to debug, slowest at high volume.
• A Make scenario with two HTTP modules. Same logic, faster execution, better error logging. Reasonable for accounts pushing 500 to 5,000 conversions a month.
• A short Cloud Function. Node or Python on Google Cloud or AWS Lambda. Best for high-volume accounts and the only option if you need sub-second latency.

Pay-per-call migrations are harder than form-fill migrations because phone calls rarely capture email

Form-fill lead gen captures email and phone at the moment of conversion. Pay-per-call captures phone, sometimes a name, rarely an email. That asymmetry matters more than it used to.

Google’s transition reduces the weight of weaker match signals like IP and session attributes over time. That leaves hashed first-party identifiers, mainly email and phone, as the durable match keys. Form-fill accounts hold up because they have email. Call-only accounts see match rates drop unless two things happen.

First, the GCLID (Google Click Identifier, the tracking parameter Google appends to ad clicks) has to flow all the way through your call tracking platform to the conversion upload. Per CallRail’s documentation on PPC tracking templates, CallRail captures GCLID from the landing page session and binds it to the call record. Confirm your platform does the same and that your webhook payload includes it.

Second, the phone number has to be normalized to E.164 format (the international standard, like +14155551234) and hashed with SHA-256 before upload. If you upload +1 (415) 555-1234 to one endpoint and 14155551234 to another, you may generate two different hashes and get zero matches between them. Normalize before you hash, every time.

The diagnostic to run during dual-write: compare match rate on the new endpoint against the legacy endpoint side by side. If Data Manager match rate is more than 10 points below legacy after two weeks, your hashing or normalization is broken. Smart Bidding will under-count conversions even after you cut over, and your tCPA targets will drift upward as the model thinks volume dropped.

The right sequence is six weeks long, not one day

Here is the playbook to run.

Week 1: Provision in parallel. Enable the Data Manager API connection in your Google Ads account. Do not disable anything. The legacy upload keeps running. The new connection sits idle until you start writing to it.

Week 2: Stand up the webhook relay. Build the Zapier, Make, or Cloud Function relay. Point it at your call tracking platform’s webhook output. Have it write to both endpoints. Test with five to ten real conversions before letting full volume flow.

Weeks 2 through 5: Monitor daily. Pull the conversion counts and match rates from both sources every morning. You are looking for parity. The new endpoint should match the legacy endpoint within 5 percent on conversion count and within 10 points on match rate.

Week 4 checkpoint. Go or no-go decision. If the numbers line up, plan the cutover. If Data Manager match rate is lagging, stop and debug. The usual culprits are GCLID dropout, phone normalization, and hashed email format. Do not skip this. Cutting over on a broken match rate is exactly the failure mode we are sequencing around.

Week 6: Disable the legacy upload. Only after match rate parity. Smart Bidding has been receiving signal from the Data Manager connection for four weeks at this point. The cutover is a non-event.

What to do this week if you spend $25k+ a month through CallRail, Invoca, Ringba, or HighLevel

Three concrete tasks for the next seven days.

1. Audit your conversion upload path. Find out whether your call tracking platform posts directly to Google Ads, or whether a Zap or Make scenario you control sits in the middle. If you already control a relay, retrofit it. If your platform posts directly, you have more work ahead.
2. Provision the Data Manager API connection in Google Ads now. Do it before the rush when every agency tries to provision the same week. The connection can sit idle. You are claiming inventory, not committing to a date.
3. Build the relay this month. Not the week before cutover. This month. Even a stub relay that just logs payloads gives you a working harness to test against.

If you run multiple campaigns or buy multiple verticals, sequence the dual-write rollout campaign by campaign. Do not flip every campaign onto the new pipe on the same day. A hashing bug or a normalization error will blind every bid model at once, and you will spend the next month trying to figure out which campaign tripped first.

Talk to our pay-per-call team before you flip the switch

For accounts spending $25k to $500k a month, a botched Data Manager API migration can mean a 20 to 40 percent effective CPL penalty for the first 30 days post-cutover. On a $100k monthly budget, that is real money, and it lands during the exact window when your bid model is most sensitive.

The work here is operational, not technical. The accounts that come out clean are the ones that built the overlap window and verified match rate before disabling anything.

If you want to walk through your specific stack, your current call tracking platform, and what the dual-write window looks like for your campaigns, book a free strategy call with Elevarus and ask for the pay-per-call team. Bring your CallRail, Invoca, Ringba, or HighLevel setup and we will map the migration sequence to your volume and verticals.