Feeding leads back to Meta and Google: Conversions API and offline import

Meta and Google are very good at finding more of whatever you report to them as success. The problem: most of the time, you only report the form. Whether the lead was reachable, was a fit or bought, they never find out. Feeding back closes this gap, and it is one of the biggest levers in lead marketing. This article explains how it works, which statuses to feed back and what to watch out for with data protection. At ad.boutique, this is the core of our lead CRM with live dashboard.

The problem: platforms optimise for forms

A campaign with the objective "leads" learns from every submitted form which people submit forms. It does not learn which people become customers, because it does not know.

This leads to a familiar pattern:

1. The cost per lead falls, and the campaign looks good in the ad account.
2. Sales complains about bad leads: unreachable, no interest, wrong target group.
3. Marketing and sales argue about whose fault it is.

The cause is not bad targeting, but a wrong signal. The algorithm does exactly what you tell it. If you tell it that a lead is good when it was qualified or bought, it looks for more such people.

There is also a second gap: what the platform counts and what arrives with you are not always the same numbers. Without capturing every enquiry yourself, nobody notices this difference.

How feeding back works

Feeding back means that your CRM sends an event to the ad platform at every relevant status change of a lead. The platform attributes the event to the ad through which the lead came and uses it for optimisation and reporting.

For this to work, you need three things:

• An identifier stored with the lead: the lead ID from a Meta Instant Form, the Google click ID (GCLID) from the URL or hashed contact details.
• A status per lead in the CRM, maintained by sales.
• A connection from the CRM to the platform that sends events automatically.

Meta Conversions API

The Meta Conversions API (CAPI) is an interface through which you send events directly from the server or CRM to Meta, instead of only through the pixel in the browser. For feeding back leads, it is the standard route.

At its core, an event contains:

With leads from Instant Forms, matching is particularly reliable, because the lead ID comes from Meta itself. With leads via the website, hashed contact details and, where available, Meta's click ID help.

Google offline conversions and enhanced conversions

Google offers two ways to attribute events from the CRM:

• Offline conversion import: you store the Google click ID (GCLID) from the landing page URL with the lead and later upload events with this ID, event name, time and value, manually, on a schedule or via an API.
• Enhanced conversions for leads: instead of the click ID, hashed contact details captured when the form was submitted are used. Status changes sent later are matched through them.

In both cases, you create conversion actions in Google Ads for each status and decide which of them counts for the bidding strategy. For users in the European Economic Area, Google also requires that users' consent is passed along through Consent Mode.

Which statuses to feed back

Not every status is suitable as an optimisation goal. A good status occurs often enough for the platform to learn, and is close enough to revenue for it to learn the right thing.

What has proven itself is optimising for the middle status and additionally sending the late status with its value. That way the algorithm gets enough signals, and you still see in the ad account which campaign brings revenue. For SaaS, the article lead scoring for SaaS describes how to define the middle status. For real estate, the article handing real estate leads to estate agents shows what routing and status look like in practice.

How valuable the whole chain is can be seen in the real estate investment case: a lead dashboard with a daily data feed tracked every enquiry all the way to subscription, around 450 high-ticket leads, measured across the whole chain. Only this made it possible to say which channel brings subscriptions and which does not.

Data protection and consent

Feeding back processes personal data and therefore needs a sound basis under the GDPR. The most important points (as of October 2026, not legal advice):

• Consent: tracking and transfer to ad platforms only run with the person's consent, obtained through the cookie banner or in the form. Without consent, nothing is transferred.
• Information: the privacy information describes that data is transferred to Meta and Google to measure and optimise advertising.
• Data minimisation: only what is needed for matching is transferred: event, time, value, identifier. No names, no conversation notes, no content of the enquiry.
• Hashing: email addresses and phone numbers are normalised and hashed (SHA-256) before sending. The platform matches hash values, and plain text never leaves your system.
• Contracts: the platforms' terms for data transfer must be accepted, and the roles (controller, processor) should be clarified.
• Retention: click IDs and hash values are not stored for longer than necessary.

Hashing is not anonymisation. A hash of an email address remains personal data. It only ensures that the address is not transferred in plain text.

Counted versus arrived

Before you optimise, you should know whether the numbers are right. That is why we compare two numbers every week: what the platform counts as a lead and what actually arrives in the CRM.

Typical causes of discrepancies:

The difference between the platform count and real enquiries is not a cosmetic flaw. It is one of the most important numbers in the report, and we resolve it before optimising any further.

When feeding back does not help

Feeding back needs volume. If you only have a handful of closed deals a month, the platform can learn little from them. Then an earlier status as the optimisation goal helps. And feeding back needs a maintained status: if sales gives no feedback, there is nothing to feed back.

How we solve it with boutique.OS

At ad.boutique in Vienna and Zurich, feeding back runs through our boutique.OS platform. The lead CRM collects every enquiry from Instant Forms, landing pages and other sources in one place, stores the source and identifiers, routes the lead immediately to the responsible person and maintains the status. Every relevant status change is sent to Meta and Google after consent. In the live dashboard, you see both numbers side by side: what the platform counts and what arrives.

This is how the set-up works:

1. Define the statuses: together we define which stages exist and which counts as the optimisation goal.
2. Connect the sources: Instant Forms, landing pages, calendar, existing CRM.
3. Set up routing: who gets which leads, how quickly, with which notification.
4. Activate feeding back: Conversions API and Google import, with consent checks and hashing.
5. Check weekly: counted versus arrived, before we optimise.

The lead CRM can sit in front of your existing CRM or take over lead management completely. How we work overall is described on the page how we work. If you want to see what this looks like with demo data, the page live dashboard with lead CRM is the best place to start.