Your CRM has no Google Ads connector. That may work in your favour.
For in-house and niche CRMs, no connector is coming. We capture click details at the enquiry, send the records that matter straight to Google’s Data Manager API and warn you when anything fails.
- Custom CRM
- Data Manager API
- Google Ads
A custom CRM can send offline conversions to Google Ads through the Data Manager API, which is Google’s stated replacement for the old upload routes. You need a stored click identifier or hashed contact details for each enquiry, a record of the event you want to count, and code that sends it, checks the result and retries.
If you run an in-house system, or a niche CRM built for your trade, you’ve probably noticed that connector lists stop a long way before they reach you. Less choice can mean a better result, since nobody’s product roadmap stands between you and the field you need.
Why the destination matters now
Google Ads Help says: “Starting June 15, 2026, offline conversions import and enhanced conversions for leads uploads will be migrated to the Data Manager API and blocked in the Google Ads API.” New or dormant integrations lost the old route, whereas integrations that kept uploading through the first half of 2026 kept legacy access for now. We could find no published end date, which makes any older in-house uploader a job for sooner instead of later.
A new build should go straight to the Data Manager API. It authenticates with OAuth and its own scope instead of the Ads API developer-token arrangement, and on 4 November 2026 Google announced support for Google Ads call conversions and row-level diagnostics, which should make it far easier to see why an individual record was refused. If you already have an uploader, our Data Manager API migration page covers moving it across.
The six jobs the integration has to do
- Remember the click. Your website saves the GCLID, gbraid or wbraid on landing, submits it with the enquiry and keeps it on the CRM record. If your forms post to an old endpoint, this is often the fiddliest part.
- Collect contact details properly. Email and phone need normalising before SHA-256 hashing, or two identical customers become two strangers. Consent state goes with them, because a visitor who denied
ad_user_datashouldn’t have hashed details collected at all. - Decide what counts. Someone has to agree which status change means “qualified” and which means “sold”, and we write those rules down in plain English first.
- Send each event once. A stable key from your database, stored alongside the time we sent it, stops a retry or a re-saved record being counted as a fresh sale.
- Deal with refusal. Records get rejected for reasons ranging from a malformed hash to a click that’s too old, so the code logs the reason, retries what’s retryable and parks the rest where someone can see it.
- Shout when it stops. A scheduled job that dies on a Friday can go unnoticed for weeks, so Tracking Monitoring, from £150 a month ex VAT, can sit on top and raise the alarm.
Can’t our own developers build this?
They can, and for some companies they should. We’re happy to write the specification or review what your team has built, and the six jobs above make a decent acceptance checklist either way. The reasons teams bring in outside help tend to be narrower than skill: Google’s conversion rules are fiddly, they change often, and the first bad upload only shows up later as strange bidding behaviour.
How will the CRM talk to it?
A missing modern API doesn’t rule anything out. The connection follows whatever your system can offer:
| What your CRM offers | How we’d connect it |
|---|---|
| REST API or webhooks | Direct and event-driven |
| Database access | A read-only query on a schedule, with care for load |
| Scheduled CSV or report export | Picked up and validated before sending |
| Nothing at all | A small addition to the application, if you own the code |
The limits of matching
An offline sale can only be tied to an ad when the enquiry carried a click identifier or contact details that match someone who clicked. Phone enquiries need call tracking, or a website enquiry from the same person, to create that link. Anything with no ad click behind it, such as a referral or a repeat customer ringing their usual number, stays out of the data, and rightly so.
What it costs, and who keeps it
A custom CRM sync starts from £2,500 ex VAT, with a fixed quote after scoping because every in-house system is a little strange in its own way. The code lives in your repository and connects with your own Google account, so there’s nothing to hand back if we part ways. For a wider comparison, read how to send CRM data to Google Ads.
Common questions
Straight answers to what people ask before they get in touch.
Can a niche CRM with no API still send conversions to Google Ads?
Usually, yes. If there’s a database we can read, a scheduled report we can pick up or application code we can extend, there’s a way in. A report emailed daily is inelegant, but it works, and we validate each row before anything reaches Google Ads so a bad export doesn’t become bad data.
We already upload conversions through the Google Ads API. Do we have to change?
If your integration kept uploading through the first half of 2026 it kept legacy access for now, and we could find no published end date. New or dormant integrations are blocked. We’d plan the move to the Data Manager API on your terms, before someone else picks the date for you.
What does the Data Manager API need that the old route didn’t?
OAuth with its own scope replaces the Google Ads API developer-token set-up, and records are structured differently too. Click identifiers, hashed contact fields and consent all still matter. Google also announced row-level diagnostics in November 2026, which should make individual rejected records easier to understand.
Will you need access to our source code?
Only if that’s the best way in. Many CRMs can be read through an API, a database replica or an export without touching the application. If we do need a small code change, such as storing a click ID on an enquiry, we can supply it for your developers to review.
Can you hash the data inside our own network?
Yes, and we’d generally prefer that. Emails and phone numbers can be normalised and hashed on your own infrastructure, so the plain versions stay with you. Only the hashes, click identifiers, event details and values are then sent on to Google, which keeps the data protection conversation shorter.