In lead generation there is a hierarchy of interventions almost nobody respects. At the top is not campaign structure, not bidding strategy, not even creative: it is whether Google knows which leads became customers. Everything else optimises toward a metric that is, at best, a proxy and, at worst, actively misleading.
In 2026 this has a technical deadline attached, which makes it a good moment to deal with it.
The deadline: 15 June 2026
From 15 June 2026, offline conversion import and enhanced conversions for leads uploads were migrated to the Data Manager API and blocked in the Google Ads API. Anyone uploading offline conversions through an integration built on the Google Ads API has to move to the new interface.
The detail that caught people out. Developer tokens that sent no requests between January and June 2026 were not allowlisted for legacy access. If your integration was dormant — a paused project, a client on hold, a script that only uploaded at quarter end — you may only discover the problem at the first upload that matters.
There is a second simplification worth knowing: since April 2026, Google Ads accepts user-provided data from website tags, from Data Manager and from API connections without forcing a single method. Existing accounts were automatically migrated to the new unified setting.
- January - June 2026 The activity window that determined whether developer tokens were allowlisted for legacy access.
- April 2026 Unified user-provided data setting: tags, Data Manager and API coexist.
- 15 June 2026 Uploads move to the Data Manager API and are blocked in the Google Ads API.
Enhanced conversions for leads, or offline conversion import?
If you have nothing in place yet, Google’s recommendation — which we share — is to start with enhanced conversions for leads rather than the older offline conversion import. The reasons are concrete:
| Offline conversion import (classic) | Enhanced conversions for leads | |
|---|---|---|
| What you must retain | Every lead’s GCLID, across the whole sales cycle | User-provided data, e.g. a hashed email address |
| Typical breaking point | The GCLID is lost between form, CRM and manual steps | A missing or dirty email field |
| Cross-device | Limited | Supported |
| Engaged-view conversions | No | Yes |
| Setup complexity | High: needs site, CRM and upload coordination | Lower |
The substantive difference is where the chain breaks. With GCLID, the fragile point is preserving a technical identifier across systems never designed to preserve it: one salesperson creating a contact by hand after a phone call makes that lead invisible forever. With user-provided data, the fragile point is contact data quality — a more familiar problem, and an easier one to police.
The value loop, in practice
The point is not technical, it is procedural. The loop you have to close has four steps:
- The lead arrives and is recorded with contact details and source.
- Sales qualifies it. This is where the first piece of information Google does not have is created: this lead is relevant, or it is not.
- The lead progresses or stalls. Meeting booked, quote sent, contract signed: each stage carries a different value.
- The value goes back to Google Ads as an event with an amount that reflects that stage.
The most common mistake is not technical. It is sending one flat value for every lead. If every submitted form is worth 100, you have taught the system that all leads are equal — which is precisely what you were trying to fix. You need differentiated values: qualified lead, meeting, quote, customer.
How much value to assign each stage
A simple, honest method: start from the average value of an acquired customer and work backwards, multiplying by the historical conversion rate between stages. If a customer is worth £3,000 and 20% of quotes close, a sent quote is worth £600. If 40% of meetings produce a quote, a meeting is worth £240. These are approximations, but their hierarchy is right — and the hierarchy is what the algorithm uses to decide.
The privacy constraint, which is not a footnote
Uploading user-provided data means processing personal data belonging to customers and prospects. In the EU and UK that requires a lawful basis, a notice that describes what happens, and consistency with the consent actually collected. This is not a formality: it is the precondition for using the feature at all.
It interlocks with the site-side consent question we covered in the article on Consent Mode v2 and the Digital Markets Act. The two belong together: one governs what you collect on the site, the other what you send back from the CRM.
Implementation checklist
- Check the state of the integration. If you uploaded via the Google Ads API, confirm the move to the Data Manager API happened and that your developer token meets the access conditions.
- Map the funnel stages with the people who sell, not alone. The stages that matter are the ones sales actually recognises.
- Assign a value to each stage using average value discounted by stage conversion rate.
- Fix contact data quality. Email required and validated in the form, normalised in the CRM.
- Automate the upload. A manual monthly export beats nothing, but the latency penalises bid learning.
- Watch the diagnostics in the interface: match rate, rejected conversions, average upload delay.
- Only then enable more aggressive tolerances and automations such as Smart Bidding Exploration.
Why this matters more than it looks
Every feature shipped in 2026 — AI Max, Smart Bidding Exploration, promotion mode, the generative formats — moves work from the operator to the system. And the system optimises toward whatever you tell it counts. An account that sends Google "form submitted" will buy, with increasing efficiency, submitted forms: the better the automation gets, the better it gets at buying the wrong thing.
Closing the value loop is the one thing that makes all the incoming automation safe. It is also, not coincidentally, the piece most often missing when we audit an account. You can see how we handle it and the process we use.