Google Ads Conversion API: Server-Side Import

What the Google Ads Conversion API Actually Does

Two weeks ago a B2B client forwarded me a Slack thread from their dev team. The message was short: "Google says our offline conversion imports will stop working after June 15." Nobody knew what that meant for their pipeline. They had a working integration that pushed CRM-closed deals back to Google Ads via the API every night. Now Google was telling them the pipe was being replaced.

That pipe is what most people mean when they say "Google Ads Conversion API" -- the set of endpoints in the Google Ads API that let you send conversion data server-side rather than relying purely on browser-based tags. The core method, ConversionUploadService.UploadClickConversions, accepts a batch of conversion objects tied to click identifiers (GCLID, GBRAID, or WBRAID) and writes them into your Google Ads account so Smart Bidding can use them.

If you have ever imported CRM deals, phone-call outcomes, or in-store purchases into Google Ads, you have used this system -- whether through the API directly, a CSV upload, or a connector like Zapier. The concept is the same: tell Google what happened after the click so it can optimise toward the outcomes that matter, not just form fills.

For a deeper walkthrough of how offline data flows into Google Ads, see my guide on Google Ads Offline Conversion Tracking: Import CRM Deals.

Why Google Is Replacing the Legacy Import

Google has been steadily tightening what the Google Ads API accepts for conversion uploads. Two dates matter:

Date	What changes
February 2, 2026	New developer tokens can no longer send session attributes or IP addresses in Google Ads API conversion imports (source)
June 15, 2026	New developer tokens are blocked from all offline conversion imports via the Google Ads API. Tokens that haven't uploaded conversions between December 2025 and May 2026 are also blocked (source)

The replacement is the Data Manager API, which went generally available on December 9, 2025 (announcement). Google is consolidating three previously separate pipelines -- Customer Match audiences, conversion uploads, and mobile-identifier ingestion -- into a single API. Think of it as Google's answer to what Meta did years ago with its Conversions API: one server-side endpoint for all first-party data.

The shift is not cosmetic. The Data Manager API introduces confidential matching, supports richer consent signals, and works across Google Ads, Campaign Manager 360, Search Ads 360, and Display & Video 360 from a single call.

What Is Not Changing

Offline conversion tracking as a practice is not going away. Google is changing the pipe, not turning off the faucet. If you are uploading CRM deals to Google Ads today, you will keep doing that -- just through a different endpoint.

How the Google Ads Conversion API Works (Current State)

Before you plan a migration, it helps to understand what you are migrating from. Here is the basic flow of the Google Ads offline conversion API:

1. Create a Conversion Action

A Google Ads API conversion action is the container that defines what you are measuring -- "Qualified Lead," "Closed Won," and so on. You create it in the Google Ads UI or via the API. Each action gets a resource name like customers/9876543210/conversionActions/257733534.

If you are unsure where to find these identifiers in your own account, I wrote a step-by-step in Your Google Ads Conversion ID: Find It and Fix It.

2. Capture the Click Identifier

When someone clicks your ad, Google appends a GCLID (or GBRAID/WBRAID for iOS) to the landing page URL. Your site needs to capture that value and store it alongside the lead record in your CRM. This is the join key that links a downstream conversion back to the original click.

3. Upload the Conversion

When the lead converts -- signs a contract, makes a purchase, books a demo -- your backend sends a ClickConversion object to the API. The object includes the GCLID, the conversion action resource name, the timestamp, and optionally a value and currency code. Google matches it to the original click and credits the campaign.

4. Add User-Provided Data (Enhanced Conversions for Leads)

The more durable version of this flow is Enhanced Conversions for Leads, where you also hash and send first-party data (email, phone) alongside the GCLID. This improves match rates -- Google reports a median 10% increase in measured conversions for advertisers using first-party data with their offline imports versus standard GCLID-only uploads.

For a full implementation walkthrough, see my post on Enhanced Conversions for Leads: CRM Deals to Google Ads.

The Data Manager API: What Changes

If you are building a new Google Ads API conversion upload integration today, you should go straight to the Data Manager API. Here is what is different.

Unified Endpoint

The legacy setup required separate integrations for Customer Match, offline conversions, and store sales. The Data Manager API handles all three through a single set of endpoints. You authenticate once, configure your data sources, and send events.

Consent and Privacy Controls

The Data Manager API has built-in support for consent signals and confidential matching. Given the expanding scope of consent frameworks -- something I cover in my Google Consent Mode v2 guide -- this is not a nice-to-have. It is the direction all ad platforms are heading.

Rate Limits

Each Google Cloud project gets 100,000 requests per day and 300 requests per minute, with individual requests supporting up to 10,000 records. For most advertisers this is more than enough. If you are a large agency uploading for hundreds of accounts, plan your batching carefully.

Cross-Platform Support

As of May 2026, the Data Manager API supports sending conversion events to Campaign Manager 360, Search Ads 360, and DV360 -- not just Google Ads (source). If you run campaigns across the Google Marketing Platform, one integration now covers all of them.

Server-Side Tracking vs. API Conversion Upload

I see these two concepts confused constantly. They solve related but different problems.

Server-side tracking (via server-side Google Tag Manager) moves event collection from the browser to your own server. The browser sends a single request to your first-party domain; your server forwards events to Google Ads, GA4, Meta, and wherever else they need to go. This fixes ad-blocker losses, avoids Safari's 7-day client-side cookie cap, and gives you control over what data leaves your infrastructure.

API conversion upload (the Google Ads conversion tracking API) sends data that was never in the browser -- CRM outcomes, phone calls, in-store transactions. No tag involved. Your backend talks directly to Google's API.

Many accounts need both. Server-side tracking recovers the online conversions your browser tags miss. The conversion API imports the offline conversions your tags could never see. For a deeper dive, see Server-Side Tracking: A Complete Guide for 2026.

Migration Checklist: Moving to the Data Manager API

If you are currently using the Google Ads API for conversion uploads, here is what to do before June 15, 2026.

Audit Your Current Setup

Document every integration that calls ConversionUploadService. Check whether you are using a direct API integration, a third-party connector (Zapier, Fivetran, a custom script), or a manual CSV upload. Each path has a different migration effort.

Confirm Your Developer Token Status

Google is enforcing the June 15 cutoff at the developer-token level. If your token has uploaded conversions between December 2025 and May 2026, you are on the allowlist and the legacy API keeps working for now. But "for now" has an expiration date.

Set Up the Data Manager API

Register your data sources in the Data Manager UI (under Tools in Google Ads) or via the API. Configure your conversion actions, map your fields, and test with a small batch before switching production traffic.

Hash User-Provided Data Correctly

If you are upgrading to Enhanced Conversions for Leads -- and you should -- hash email addresses and phone numbers with SHA-256 before sending. Normalise emails to lowercase and strip whitespace. Google will not match incorrectly hashed data, and you will see zero conversions with no error message telling you why.

Test and Validate

Use the validate_only flag in the API to check for errors without actually uploading conversions (documentation). Run validation in staging before you flip production. I have seen teams lose weeks of conversion data because they pushed a broken integration live without testing.

If any of this feels like more than your team can handle -- or you are not sure whether your current setup is even working correctly -- I can audit your tracking and tell you exactly what needs fixing.

Common Mistakes With the Google Ads Conversion API

After auditing dozens of conversion API setups, here are the errors I see most often.

Wrong Conversion Action Resource Name

The API accepts any syntactically valid resource name without complaining. If you point to the wrong conversion action, your data uploads successfully into the wrong bucket. Bidding optimises toward the wrong goal. I have seen this go undetected for months.

Missing or Stale GCLIDs

GCLIDs expire after 90 days. If your sales cycle is longer than that, conversions uploaded with expired GCLIDs are silently dropped. For B2B companies with long sales cycles, this is a structural problem -- see my post on Marketing Measurement for Long B2B Sales Cycles for workarounds.

No Deduplication

If your CRM fires multiple events for the same deal (stage changes, re-imports, retries after errors), you can end up double-counting conversions. Use the order_id field to deduplicate. Google will reject duplicate order_id values for the same conversion action, which is the behaviour you want.

Ignoring Partial Failures

Always set partial_failure = true in your upload requests. Without it, a single bad record kills the entire batch. With it, valid conversions still process and you get error details for the failures (documentation).

How This Compares to Meta, LinkedIn, and Snapchat

The conversion API for Google Ads is conceptually similar to what Meta, LinkedIn, and Snapchat offer -- but the implementations differ.

Meta's Conversions API is more tightly integrated with its pixel and requires deduplication between browser and server events. LinkedIn's Conversions API is newer and more limited in scope. Google's approach has historically been more fragmented (separate endpoints for different data types), but the Data Manager API is closing that gap.

The broader trend is clear: every major ad platform is building a server-side data ingestion layer. Browser-only tracking is no longer sufficient. If you want to understand the pattern across platforms, start with What Is the Conversions API? A Plain-English Guide.

FAQ

Not sure your Google Ads conversion data is actually reaching the right place? Let me audit your setup -- I will tell you exactly what is broken and what to do about it.