Send real sales back to Google and Meta

The account in this guide: the same Australian education provider as in my Google Ads audit guide and my Meta lead ads guide. I do this work inside someone else's business. Leads arrive by web form, phone and Meta's instant forms, and the sale is an enrolment that can land days or months later. I can't name it, but the numbers are real. The value-carrying upload wasn't live on this account when I wrote this. What follows is the groundwork.

01 Capture the click ID and contact details with every lead

With auto-tagging on, Google adds a click ID to every ad click, the GCLID. Some iOS traffic carries a GBRAID or WBRAID instead. Capture whichever one is in the landing page address, hold it in a first-party cookie so it survives the visitor clicking around, and write it into a hidden field on every form. Your CRM stores it in its own field, and nothing overwrites it later.

Capture email and phone on every form too. When the click ID is missing, Google can still match the sale on those, hashed, as long as the Google tag captured the same email or phone when the form was submitted. That's most of what enhanced conversions for leads adds.

For Meta instant forms, store Meta's lead ID, a 15 to 17 digit number, in its own CRM field. For Meta visitors who enquire on your own landing page, keep the _fbc cookie, which holds Meta's click ID.

Then open ten recent leads and look at the field. On this account, the field the click IDs landed in also held Google Analytics client IDs, which are two long numbers joined by a full stop. They look like IDs, but Google can't match them to anything, so they had to be filtered out.

Phone sales are the hole in all of this. A call has no click ID unless you use Google's call tracking, which puts a forwarding number on your ads. Then you can import the calls that became sales, matched on caller number and call start time.

02 Decide what counts as a sale, its value and its date

Before anything is uploaded, write down three rules: which CRM statuses count as a sale, which date it takes, and what it's worth.

The sale. On this account the CRM had an "enrolment accepted" tick box that looked like the obvious answer. It missed about one enrolment in three. Counting by status, and accepting a sale if any of its won, payment or acceptance dates fell in the period, caught the ones the tick box missed. For an upload, pick one date per sale and stick to it. I'd use the won date, with the payment date as the fallback.

The value. Send the actual revenue of each sale. If you upload earlier stages too, value each one at the average sale value multiplied by the share of that stage that goes on to buy. A booked call that becomes a sale one time in four is worth a quarter of a sale. That keeps bidding pointed at the sale before it has enough sales to learn from.

The date. Google needs the conversion time with a time zone offset, in the form 2026-10-29 14:05:00+11:00, and it has to fall after the click. Check the offset at the source. On this account the CRM's spreadsheet export and its API gave the same moments in different time zones, an hour apart. That's enough to put a sale before its own click. In a file import, a time zone name such as Australia/Sydney avoids daylight saving mistakes.

For refunds and cancellations, Google lets you retract an uploaded conversion or restate its value, found by the transaction ID you uploaded it with (for GCLID and GBRAID sales, not WBRAID).

Conversion value rules adjust a conversion's value by location, device or audience as Smart Bidding sets a bid. Smart Bidding already uses those signals, so only add a rule when your sales show a difference it can't see, such as leads from one state buying at half the rate. They matter most while you're bidding on a stage before the sale.

03 Upload offline conversions to Google Ads

Create an import conversion action for the sale, and one for each stage you plan to send. Set its click-through window to cover your real time from click to sale, up to the 90-day maximum; Google rejects a sale whose click falls outside it. Wait four to six hours before the first upload.

Start the sale action as secondary. Secondary actions report in the All conversions column but don't steer bidding, so you can watch the numbers settle first. FM-01 covers when to make it primary, which is once campaigns have enough sales to learn from and after at least four weeks in parallel.

Then turn on enhanced conversions for leads. Accept the customer data terms in the conversion settings, because Google won't process data sent before you do, and set the Google tag (or Tag Manager) to capture the email and phone from your lead form when it's submitted. Google matches your upload against that. Each sale goes up with the click ID where you have it, plus up to five hashed identifiers:

1. The click ID, whenever you have it. Google still recommends including it.
2. The email: trimmed and lowercase, with dots and anything after a plus sign removed from Gmail addresses, then hashed with SHA-256.
3. The phone, in international format (+61 and the number without its leading zero), then hashed the same way.

Build new uploads on Google Ads Data Manager, which connects to Google Sheets, file transfer, HubSpot, Salesforce and common databases, or on the Data Manager API. Since 15 June 2026 Google has blocked new integrations from the old Google Ads API upload method.

Give every sale a transaction ID, such as the CRM record ID. Google uses it to drop duplicates, and it's how you retract or restate that sale later.

Upload daily, overlapping each upload by a day as Google's file import guidance suggests. Google rejects a repeat with the same click ID, conversion action and conversion time, which only protects you if the conversion time is the sale time. Stamp it with the upload time and every re-send becomes a new sale.

04 Send CRM stages to Meta's Conversions API

My Meta lead ads guide covers the strategy: whether your account fits (Meta's own forms, at least 200 leads a month, a stage reached by 1% to 40% of leads within 28 days), which stage to optimise for, and the higher intent form. This is the plumbing underneath.

Every event sent to Meta's Conversions API for CRM needs:

• event_name: your CRM stage, named as your CRM names it
• event_time: when the lead reached that stage, in Unix seconds
• action_source: always system_generated
• lead_id: Meta's lead ID, inside the user data
• event_source: crm, and lead_event_source: the name of your CRM, both inside the custom data

Send every stage as it changes, starting with the lead stage. Then mind the clock, because an event can be at most seven days old when it reaches Meta, and one stale event gets the whole batch rejected. A weekly upload lives on that edge. Daily is Meta's minimum, and the safe choice.

Meta checks lead coverage, the share of your Meta leads with matching events, and wants at least 60%. The lead ID is what gets you there. In FM-02's analysis on this account it made 92% of the matches between Meta leads and the CRM, so store it on every lead from day one.

Leads from your own landing page work differently. Send the submission through the Conversions API as well as the Pixel, with the same event name and event ID on both, so Meta counts it once (it merges pairs that arrive within 48 hours). Include hashed email and phone (for Meta, the phone is digits only: 61 and the number with no plus sign and no leading zero, so it hashes differently from Google's) and the unhashed _fbc and _fbp cookies, then watch the Event Match Quality score in Events Manager.

05 Check it's working, then wait out the lag

Check three things, in this order.

The diagnostics. In Google Ads, offline data diagnostics show successful, pending and failed uploads with a status and alerts. Pending uploads should clear within 24 hours. The enhanced conversions diagnostics add coverage and match rate. In Meta's Events Manager, the CRM integration has Overview and Diagnostics tabs and a lead coverage report.

The reconciliation. Compare sales in the CRM, sales uploaded and conversions the platform recorded, for the same dates. Every gap needs a reason. On this account, one month Google counted about a fifth more enrolments than the CRM export showed. The gap was entirely older leads that paid that month, outside the export's window. Google was right and the export was short.

The match rate. Write down the share of sales that reached the platform with a usable click ID or contact match. My working floor is about 70% before bidding relies on it. Below that, fix the feed before the bids.

When match rates are low, work through the causes in order: the click ID never captured (no hidden field, a redirect that strips it, a form on another domain); captured but wrong (analytics IDs, truncated, overwritten); phone sales; clicks older than the window; contact details not formatted before hashing; and leads keyed in by staff with no email.

Then the lag. Google reports an uploaded sale against the date of the original click, not the upload, so last week's numbers keep rising for weeks. On this account half the sales closed within about a week of the enquiry and the rest trailed out over months. The Days to conversion segment shows your own curve. Until a period is older than most of it, it can describe but not decide, so never judge a bid change on a week whose sales haven't landed.

Where AI fits

AI handles this plumbing well, from the hashing scripts to flagging the week coverage drops. On this account AI wrote the scripts that hash the CRM export on my own machine before it goes anywhere, and the reconciliation of the CRM against Google's count. It never saw a raw email or phone number. It can't decide what counts as a sale, though. A tick box that misses one enrolment in three looks perfectly sensible from the outside.