Meta Offline Conversions: Sending Closed Deals Back

Meta knows a form was submitted. It does not know that the lead was junk, that sales disqualified it in four minutes, or that a different lead from the same campaign became a forty thousand dollar customer in August.

So it optimises for the last thing it can see, which is the form fill, and it gets very good at finding people who fill in forms. That is a different population from people who buy.

Sending the closed sale back to Meta fixes both halves of the problem: the reporting stops flattering you, and the algorithm starts learning from outcomes instead of intentions. Here is how it actually works on Meta, which is not how it works on Google, and the difference is the whole reason people get this wrong.

Does Meta match on the click or the person?

The person. This is the single most important thing to understand before you build anything.

Google's offline conversion import is built around GCLID. You capture a click identifier, store it, send it back, and Google joins the conversion to that exact click. It is a database join and it either matches or it does not.

Meta works on identity. You send a conversion with hashed customer information, email, phone, name, city, and Meta matches that against its own users. fbclid exists and helps, but it is short-lived, frequently missing, and stripped by browsers and privacy tooling more aggressively every year. A Meta setup that depends on the click identifier the way a Google setup does will match a fraction of what it should.

The practical consequence: on Google you protect the click ID above all else. On Meta you collect and normalise customer data above all else, and you treat the click ID as a bonus when it survives.

What goes in the payload?

As many match keys as you legitimately hold, hashed before they leave your systems.

Email is the strongest single key. Phone number is next, and it needs normalising to E.164 before hashing or it will not match. First name, last name, city, state, postcode and country are weaker on their own and meaningfully improve the match rate in combination. If you have the click identifier and the browser cookies from the original visit, send those too.

Everything except the click identifier and cookies is hashed to SHA-256, lowercased and trimmed first. The normalisation is not optional decoration: Jane@Example.com and jane@example.com hash to entirely different values, and one of them matches nobody.

Alongside the match keys, the event needs its name, the time it actually happened, the value, the currency, and an action source describing where it occurred, which for a phone sale or a CRM close is not the website.

How do I send them?

Through the Conversions API, from your server or your CRM, the same endpoint that reports your on-site conversions.

Meta used to run a separate offline conversions product with its own event sets and its own upload flow. That is not where new work should go. Offline events are now part of the same Conversions API, distinguished by the action source on the event rather than by being a different system, which also means a single integration covers both your website purchases and the deal your sales team closed by phone.

Three routes exist in practice. A direct API integration from your backend, which is the most control and the most work. A CRM integration, where HubSpot or Salesforce sends the event when a deal reaches a stage you choose. Or a manual file upload for a business that closes a few dozen deals a month and does not need this automated on day one.

Start with the manual upload if the alternative is not starting. A month of uploaded closes teaches you more about your campaigns than a perfect integration you have not built.

What about deduplication?

If the same conversion can arrive twice, once from the browser pixel and once from your server, both need the same event id and the same event name so Meta counts one.

This matters less for genuinely offline events, since a deal closed in a CRM never fired a pixel. It matters a great deal for purchases, where the browser and the server both see the same order, and a missing event id turns your revenue reporting into fiction. The same discipline applies whether the second sender is your own server or a platform like Shopify, which is the trap our piece on Shopify's Meta CAPI goes into.

Which conversion should you send?

Not just the closed deal. Send the stage that happens often enough for the algorithm to learn from, and the one that carries the money.

A campaign generating thirty closed deals a month gives Meta's optimisation very little to work with, because conversion-optimised delivery needs volume before it can find a pattern. A qualified lead, which might be ten times more frequent and still meaningfully better than a raw form fill, is usually the better optimisation target. Then send the closed deal with its real value, and judge the campaign on that.

That is the same two-event structure we argue for on Google Ads in conversion tracking for leads that close. The platforms differ, the principle does not: optimise on the frequent signal, report on the valuable one.

What to confirm before you build

Two numbers, against Meta's current documentation rather than against this article, because both have moved and both decide what your setup can report.

How far back an event can be dated and still attribute. There is a limit on how stale an offline event can be when it arrives. If your sales cycle is longer than that limit, some closed deals cannot be credited to the campaign that produced them however good your integration is. Find that number before you design around it.

What the attribution windows are set to on your account. Meta's defaults have changed more than once, and the window determines which conversions get credited at all. A deal that closes outside it is not a tracking failure to debug, it is the window working as configured.

What good looks like afterwards

Reported conversions go down. That is the correct outcome and it catches people off guard.

You were counting form fills and you are now counting customers, so the number falls and the cost per conversion rises. Neither is a regression. The campaigns whose apparent performance collapses were the ones producing volume without revenue, and you were paying for that gap the whole time without being able to see it.

Give the algorithm several weeks at meaningful volume before judging the change. Then look at what it started spending on, which is usually the more interesting report than the conversion count.

FAQ

Can Meta track conversions that happen offline?

Yes. Offline conversions are sent through the Conversions API, from your server, your CRM, or a file upload, with an action source that says the event did not happen on your website. Meta matches them to people using hashed customer data such as email and phone, then credits them to the ad those people saw or clicked.

Do I need fbclid to send offline conversions to Meta?

No, and depending on it is the common mistake. Meta matches on identity rather than on the click, so hashed email and phone do most of the work. fbclid improves matching when it survives, but it is short-lived and often missing, so a setup built around it the way a Google Ads setup is built around GCLID will match far less than it should.

Why did my conversion count drop after connecting the CRM?

Because you changed what you were counting. Form fills are plentiful and closed deals are not, so a number that measures customers is smaller than one that measured intentions. The cost per conversion rises for the same reason. What matters is whether the revenue attributed to the channel went up.

How do I hash the customer data correctly?

Lowercase and trim the value, normalise phone numbers to E.164 with the country code, then hash to SHA-256. Do it before anything leaves your infrastructure. Incorrect normalisation is the quiet failure here: the event is accepted, the hash matches nobody, and the match rate stays low with nothing in the interface to explain it.

Is it worth doing at low volume?

For reporting, yes, immediately. For optimisation, not until you have enough closed deals a month for the algorithm to find a pattern, which is why most accounts should optimise on a qualified lead and report on the closed deal rather than asking Meta to bid toward thirty events a month.