How to Send CRM Data Back to Meta and Google Ads

Meta's algorithm sees: someone clicked an ad and submitted a form. That's it. It has no idea whether that lead ended up qualifying, booking a call, signing a contract, or paying €50K.

Put a month of real numbers next to that and the gap is obvious. Say a campaign produced 400 form fills at €40 each: €16,000 of spend and, in Ads Manager, a perfectly respectable cost per lead. In the CRM, 310 of those were unusable, 90 were qualified, 22 booked a call and 6 signed, worth €180,000 between them.

Meta was told 400 conversions happened. It will now go and find more people who resemble those 400, which means mostly resembling the 310. So Meta optimises for form submissions, which is why lead quality drops over time: the algorithm has been trained on the wrong outcome, and it is getting better at it every week.

When you send closed-deal data back to Meta via CAPI, Google via Enhanced Conversions, and LinkedIn via the Conversions API, you fundamentally retrain those algorithms. They stop targeting people who fill out forms and start targeting people who actually buy from you.

Three separate things improve, and they are worth distinguishing because they arrive at different times.

• Targeting gets betterThe audience model re-converges on people resembling buyers rather than submitters. This is the slow one: three to six weeks before it is visible, months before it fully settles.
• Bidding gets betterWith a deal value attached, value-based bidding can bid more for the people likely to be worth more. Without values, every conversion is worth the same to the algorithm, which is never true.
• Reporting finally makes senseThis one is immediate. Cost per closed deal by campaign is a number you can put in front of a board, and it is available the day the loop closes rather than months later.

Lead quality climbs, cost per acquisition drops, and the effects compound over a quarter because each round of optimisation trains on cleaner data than the last.

4:35

All four major platforms accept offline conversions and all four give it a different name, which is most of why this looks harder than it is. The mechanism is identical: an event, an identifier that matches it to a click, and optionally a value.

The practical consequence is that the hard part is not any single platform's API. It is having one clean pipeline of CRM events with the right identifiers attached, which every platform can then be fed from.

The full flow works like this, and it is worth reading as a chain: every link has to hold, and each one has a characteristic way of breaking.

1. Someone clicks your ad, and the click ID is captured. Breaks when it is read from a JavaScript cookie that Safari expires in seven days, or blocked by an ad blocker.
2. They fill out a form, and the click ID is passed through and stored on the CRM record. Breaks when a form on one landing page was built without the hidden field, which is almost always at least one form.
3. The sales team qualifies and closes the deal, and the CRM stage updates. Breaks when stages are used inconsistently and closed won means three different things to three reps.
4. A webhook fires on the stage change, carrying the click ID and the deal value. Breaks when the value field is empty, which turns a revenue signal into a count.
5. The stage is matched to the right conversion event per platform. Breaks when every stage is mapped to the same generic event, so the platform learns nothing new.
6. The event is sent to Meta, Google, LinkedIn and Microsoft. Breaks when only one of the four is connected.

Total time from CRM update to Meta receiving the signal in an automated setup: typically under 60 seconds. A weekly CSV upload also works and is a legitimate starting point; it just delays the signal, thins it, and stops entirely the first week somebody is on holiday.

Step 1: Capture and store click IDs

Nothing downstream is possible without this, and it is the step teams most often assume is already done.

• Capture fbclid, gclid (plus gbraid and wbraid), msclkid and li_fat_id at the moment of the click, server-side rather than from a browser cookie that will not survive the sales cycle.
• Pass them through every form submission so they reach the CRM. Every form, including the one on the campaign landing page your agency built in 2024.
• Store them as fields on the lead and contact record, not on the session. A click ID that dies with the session cannot be sent back three weeks later.

Step 2: Decide which stages count

This is a marketing decision disguised as a technical one, and getting it wrong is the most common reason a correctly built loop produces nothing.

• Fire on stages that mean something: qualified, meeting booked, closed won. Not every stage, or you are rewarding volume again with extra steps.
• Map each stage to a distinct platform event: Lead, Schedule, Purchase. Mapping them all to one event tells the algorithm nothing it did not already know.
• Include the original click ID, hashed email and phone, and the deal value in every payload. Normalise before hashing: email lowercased and trimmed, phone in E.164.
• Pick your optimisation event on volume, not purity. If you close ten deals a month, optimise on qualified leads and send closed deals for measurement.

Step 3: Route to each ad platform

• Meta Conversions API: events with the fbclid, hashed user data and conversion value, deduplicated against the browser pixel with a shared event ID.
• Google Enhanced Conversions for Leads: the gclid and the closed-deal value returned to Google Ads, uploaded well inside the current import window.
• LinkedIn Conversions API: critical for B2B, and the platform most often left disconnected because its share of spend looks small next to its share of pipeline.
• Microsoft Ads offline conversions: the msclkid on the same events. Small effort once the other three are running, and free performance.

Step 4: Verify, then leave it alone

• Check the events arrive: Meta Events Manager, the Google Ads conversions table, LinkedIn Campaign Manager. Rows accepted, not rows received.
• Check event match quality in Meta. Below 7 and the events you built this for are being discarded.
• Check your conversion counts did not double. If they did, deduplication is not working and every decision made on the new numbers is wrong.
• Then wait six weeks without changing the optimisation event, the budget or the audience, or you restart the learning phase and reset the clock.

LeadJourney captures every click ID server-side on your own subdomain at the first visit, so step one holds without hidden fields on every form and without depending on a cookie Safari will delete. The value is written onto the CRM record, where it stays for the length of the sales cycle.

Native CRM integrations with HubSpot, Salesforce, Pipedrive, Close and more (plus any other CRM by webhook) read your stages and deal values. You choose which stages count, and each one is routed to the right event on all four platforms at once: the Meta Conversions API, Google Enhanced Conversions and offline imports, the LinkedIn Conversions API and Microsoft offline conversions. Deduplication against the browser pixel is handled rather than configured.

Because the same stages are also attributed back to campaign, ad set and creative in the reporting, you can watch cost per qualified lead during the retraining period instead of cost per lead, which is the only way to tell the fix working from the fix failing. Setup takes about 21 minutes with no developer, and there is a 14-day free trial.

Carry on with the Meta Conversions API guide, Google Ads enhanced conversions for leads and the LinkedIn Conversions API with CRM deals. For the wider case, see why Meta lead quality drops and how to track offline conversions.