Offline conversions: closing the loop between click and sale

The platform knows everything up to the click and nothing after. How to send the real outcome back, the three ways to do it, what you are actually uploading, and the four mistakes that kill it.

The ad platform knows everything that happened up to the click and nothing about what happened after. It knows someone arrived and filled in a form. It does not know whether that person bought, whether they bought big, or whether they were never going to buy at all.

That would not matter much if a person optimised the campaigns. They are optimised by an automated system that learns from what you send back — and if all you send back is forms, it will learn to fetch forms.

What the platform never finds out

In a business where the sale closes off the website — a call, a meeting, a visit to the shop — an entire stretch stays dark:

• Which forms were real people and which were noise.
• Which of the real ones ended up buying.
• How much each one billed.
• Which asked for the expensive service and which for the cheap one.

All of that information exists. It is in your CRM, your business system or a spreadsheet. It simply never returns to the place where spending decisions are made.

How the loop actually closes

The mechanics have three steps, and the first is the one almost nobody gets right:

1. Store the click identifier when the lead arrives. Google appends a parameter to the destination URL (the gclid) and Meta another (the fbclid). That identifier has to travel with the form and be stored next to the contact. If it is not captured then, there is no recovering it later.
2. Record the outcome. When the lead buys, note when and for how much on the same record.
3. Send the outcome back to the platform. With its identifier, its date and its value.

Step 1 is a five-minute implementation decision that has to be taken before you have the problem. Step 3 can be built later; step 1 cannot be built backwards.

Three ways to send it back

Practical advice: start with the first even if you know you will end at the third. Three weeks of manual uploads prove that identifiers are being stored properly, that dates line up and that the platform accepts the file. Building the integration before knowing that is automating a circuit that does not work yet.

And where there is no click identifier — a lead that arrived by phone, say — platforms accept contact data for matching. It works less well and carries implications worth reading before switching it on.

What you are actually uploading

Worth pausing here. Uploading a customer list to an advertising platform is a disclosure of personal data to a third party, even when it is called “conversion upload” and even when the emails in the file are hashed.

What that implies:

• It needs a lawful basis. Holding the data is not enough; this specific purpose has to be justifiable.
• It has to be disclosed. Your privacy policy should mention that data is shared with advertising platforms for measurement.
• The platform is one more vendor. It goes into your register, with its processing agreement and a check on whether it processes outside your country.
• Hashing helps but does not settle it. It reduces exposure in transit. It does not turn processing without a legal basis into processing with one.

If you upload only the click identifier, the date and the value — no contact data — the risk profile is considerably lower. It is usually enough, and it is where to start. The full framing is in how we handle data.

The four mistakes that kill it

1. Not storing the identifier. The foundational error. Discovered three months later, when there is nothing left to send.
2. Uploading out of window. Platforms accept conversions within a window from the click. If your sales cycle is long, check the current limit before designing the process: it can constrain everything.
3. Uploading everything at the same value. If all sales carry the same value, the system learns to bring volume, not revenue. Real value is half the benefit.
4. Uploading twice. Without your own transaction identifier, a repeated upload duplicates conversions and inflates ROAS — exactly the problem described in why platform ROAS does not match your revenue.

Checklist before you start

• Does the form store the click identifier next to the contact?
• Is there somewhere that records whether the lead bought and for how much?
• Is there your own transaction identifier, to avoid duplicates?
• What is the platform’s maximum upload window, and does your sales cycle fit inside it?
• Does the privacy policy cover this disclosure?
• Who finds out if the upload stops running?

The last is the usual one: a conversion upload that stops does not produce an error, it produces fewer conversions — and that looks exactly like a bad month.

FAQ

• Does this only work for e-commerce? It is the opposite: e-commerce needs it least, because the sale happens on the site. It matters most where the sale closes by phone, in a meeting or in a shop — which is where the platform is otherwise blind.
• Do I need a CRM? You need somewhere that records which lead became a customer and for how much. A spreadsheet works to start. What you cannot skip is storing the click identifier alongside the lead at the moment it arrives.
• Is uploading customer data to an ad platform legal? It is a disclosure of personal data to a third party, so it needs a lawful basis, it has to be covered by your privacy policy, and the platform has to appear in your vendor register. Platforms also require contact data to be hashed before upload — that reduces exposure but does not replace the legal basis.
• How long until it improves results? Longer than a week. Automated bidding needs a meaningful volume of the new signal before it changes behaviour, and until then you are feeding it without seeing much. Judging it after ten days is how good implementations get switched off.