Send closed revenue back to the ad platforms, carefully
Offline conversion imports let Google and Meta optimise toward money instead of form fills. They also hand a platform your customer list and let it mark its own homework. Here is how to do it without either mistake.
There is a specific and very common way for a well-run advertising account to waste money: it is optimising beautifully toward the wrong thing. Cost per lead is falling, volume is up, the dashboard is green, and the sales team is quietly complaining that the leads are rubbish. Both observations are correct at the same time.
An ad platform will get you more of whatever you tell it to want. If you tell it you want form fills, it will find the people most likely to fill in forms, which is not the same population as the people most likely to buy.
Offline conversion imports are the fix, and they are genuinely one of the highest-return changes available to most mid-market advertisers. They also come with two costs that are rarely discussed at the same time as the benefit. This article covers both.
What the platform is actually optimising
Automated bidding optimises toward the conversion events you report. It has no independent knowledge of your revenue, so the definition of success you send is the definition it uses, and every downstream bidding decision inherits it.
This is not a subtle effect. Modern bidding is a machine learning system with a large amount of data about the person behind each impression, and it is extremely effective at finding more of whatever pattern you rewarded. Reward the wrong pattern and it will be extremely effective at that.
The failure is invisible inside the platform, because the platform is succeeding at the task it was given. It is only visible where the leads land, which is a different system, usually owned by a different team, often reported on in a different meeting.
That organisational split is why this problem persists for years in businesses that are otherwise well run. Nobody is doing anything wrong. The information required to notice simply never appears in one place.
The two ways to send revenue back
There are two mechanisms: click-based imports, which use an identifier the platform attached to the original click, and identity-based imports, which match on hashed customer details. Click-based is more accurate and far less invasive, and should be preferred wherever possible.
| Click-based | Identity-based | |
|---|---|---|
| What you send | A click identifier, a time, a value | Hashed email or phone, a time, a value |
| Personal data shared | None | Yes, hashed but matchable |
| Accuracy | Exact — it is the platform's own identifier | Probabilistic, depends on which address the customer used |
| Works when | The identifier survived from click to CRM | You have contact details but no click identifier |
| Main risk | The identifier gets lost in a form or a redirect | You are handing over a customer list |
The practical implication is that the most important engineering work happens long before any upload: capturing the click identifier on the landing page and carrying it through the form into the CRM as a hidden field. If that plumbing exists, you can use the good mechanism. If it does not, you are pushed toward the invasive one.
Capturing the identifier is the whole job
The click identifier arrives as a URL parameter, must be read on the landing page, stored, carried through every form the visitor touches, and written to a field on the CRM record. Each of those steps is a place it commonly gets dropped.
The identifier survives a surprisingly hostile journey. Redirects strip parameters. Single-page applications rewrite URLs. Multi-step forms lose hidden fields between steps. A visitor who returns three days later on a different device arrives with nothing at all, which is correct behaviour and still means no identifier.
The test for whether this is working is simple and worth running monthly: count what share of new CRM records created from paid traffic have a populated identifier field. If it is under about sixty percent, fix the plumbing before doing anything else, because everything downstream is operating on the remainder.
Where a phone call is the conversion, the identifier has to survive into the call record instead, which usually means a call tracking platform that can associate a session with a call. That is a real integration with a real cost, and it is the point at which many businesses decide identity-based matching is the pragmatic route.
Why this is the highest-return change most advertisers can make
Optimising to revenue rather than to leads changes which people the platform pursues, and in businesses with variable deal sizes that shift is worth more than any creative or keyword work available at the same cost.
The effect is largest exactly where lead quality varies most: businesses with a wide range of deal values, long consideration, or a meaningful share of enquiries that were never going to buy. In those accounts the cheapest leads and the most valuable customers are often almost disjoint populations.
It is smallest in businesses where every sale is worth roughly the same and almost every enquiry converts. If that describes you, the lead count already is the revenue signal, and this work will produce a modest improvement at best. Knowing which situation you are in before starting saves a quarter.
The first cost: you are giving away the scoreboard
Once a platform knows which of its clicks became revenue, its own reporting will confidently attribute that revenue to itself. The upload improves its bidding and simultaneously destroys any pretence that its reported results are independent.
This is not a reason to avoid uploading. It is a reason to keep your measurement and your optimisation in separate systems and to stop quoting platform-reported revenue in any document that goes to a board. The platform is now a participant in the measurement, and participants do not audit themselves.
The clean arrangement is straightforward once stated: the platform optimises using data you send it, and a system with no stake in the answer reports what actually happened. Those are two jobs, and giving both to the same vendor has an obvious flaw that is somehow invisible when the vendor is large enough.
This is the specific reason CloseRev exists as a separate system from the ad platforms. It reconciles your closed sales against your own source records, so the number you report is produced by something that does not sell media.
The second cost: it is a data sharing decision
Identity-based imports send customer identifiers to a third party for matching. Hashing limits exposure but does not anonymise, because the hash is designed to be matchable, and the decision needs a lawful basis and a record like any other transfer.
The engineering framing — it is only a hash — is technically true and legally insufficient. A one-way hash of an email address is still personal data in every jurisdiction that has considered the question, precisely because it functions as an identifier. If it did not, the upload would not work.
What this means operationally is modest but non-optional: know your lawful basis, record the transfer in your processing inventory, make sure your privacy notice describes it in terms a person could recognise, and be able to exclude customers who have objected. None of that is difficult; all of it is embarrassing to be missing when asked.
There is also a commercial dimension that gets less attention than the legal one. Your customer list is a genuine asset, and uploading it to a platform that also sells access to audiences is a decision worth making deliberately rather than as a side effect of a performance experiment.
A sequence that works
Fix identifier capture, verify it, upload a backfill, hold bidding steady while the platform learns, then switch the optimisation target. Changing the target before the data is flowing is the most common way this goes wrong.
- Capture the click identifier on landing and carry it to the CRM. Verify the fill rate before proceeding.
- Decide gross or net revenue, and whether to send the full value or a margin-adjusted one. Write it down.
- Backfill several months of history so the algorithm has enough events to learn from on day one.
- Upload on a schedule — daily is normal — and monitor for rejected rows rather than assuming success.
- Leave bidding alone for two to four weeks. Then change the optimisation target, and only then.
- Keep your independent report running throughout, because it is how you will know whether any of this worked.
Send margin, not revenue, if you can
If product or service margins vary substantially, sending a margin-adjusted value rather than gross revenue produces better bidding, because it stops the platform chasing high-revenue, low-profit customers.
This is an advanced move and a genuinely valuable one in businesses with mixed product economics. A platform told that a fifty thousand pound sale is worth fifty thousand pounds will pursue more of them, even if that line carries an eight percent margin while a smaller line carries forty.
The objection is that margin data is sensitive and nobody wants it in an ad platform. A reasonable compromise is to send a scaled proxy — a consistent transformation that preserves the ordering without disclosing the actual figures. The algorithm needs relative value, not your P and L.
The long sales cycle problem
Bidding algorithms learn from recent conversions. When sales close months after the click, the feedback arrives too late to guide bidding on current traffic, and the whole mechanism weakens considerably.
There is no complete solution, but there is a workable partial one: send a mid-funnel milestone as a separate conversion with an estimated value, alongside the eventual closed revenue. A qualified opportunity at ninety days is a much better signal than a form fill at day zero, even though it is not money.
The risk to manage is that the milestone becomes the target and the same problem recurs one stage further down the funnel. Guard against it by keeping the closed-revenue upload running and periodically checking that milestone volume and closed revenue still move together.
When not to do this at all
Skip offline conversion imports if your conversion volume is too low for the algorithm to learn from, if your identifier capture is badly broken, or if you have no independent measurement to check the result against. In each case the upload adds risk without adding signal.
Volume is the hard constraint. Bidding algorithms need a meaningful number of conversions in a learning window to change behaviour, and a business closing fifteen deals a month is not going to supply it. That is not a failing; it means the effort belongs somewhere with a better return, such as improving what happens to the leads you already get.
The second case is more common than teams admit. If a third of paid records carry an identifier, uploading produces a partial and biased picture — the sales that happened to keep their identifier are not a random sample of your sales — and the algorithm learns from the bias.
The third is a judgement call and worth taking seriously. Uploading revenue while relying entirely on the platform's own reports to evaluate the change leaves you with no way to distinguish real improvement from a platform becoming more confident about claiming credit. Those look identical from inside the dashboard.
The conversation to have with your finance team first
Agree what revenue figure is being sent, on what basis, and how it reconciles to the ledger, before the first upload. An advertising platform holding a revenue definition nobody in finance recognises causes an entirely avoidable argument later.
The specific questions are gross or net, whether refunds are clawed back, how multi-year or instalment contracts are valued, and which date is used. None are difficult; all are contested if left unstated until somebody notices that the ad platform reports a different revenue total from the management accounts.
It also protects you politically. The first time a colleague sees a large revenue number inside an advertising interface, the reasonable reaction is to ask where it came from and who decided that. Having the answer written down beforehand turns a governance concern into a two-minute explanation.
What to check every month
Monitor the identifier fill rate, the upload rejection rate, the lag between close and upload, and whether platform-reported revenue is drifting away from your own. Each has a characteristic failure that is silent until checked.
- Identifier fill rate on new paid records. A drop usually means a site change broke the capture.
- Rejected rows. Uploads fail partially and quietly; a rejection rate creeping up is a schema or timing problem.
- Upload lag. Conversions outside the platform's acceptance window are discarded, and long cycles hit that limit.
- Divergence between platform-reported and independently measured revenue. Some gap is expected; a widening one is a story.
Upload your revenue so the platform bids better. Keep your own measurement so you can still tell whether it did.
Questions people actually ask
- What is an offline conversion import?
- It is the practice of sending sales that happened outside the website — a phone order, a signed contract, a showroom purchase — back into an advertising platform, linked to the click that originally generated the lead. The platform can then optimise bidding toward closed revenue rather than toward form submissions.
- Why does uploading revenue improve ad performance?
- Because the platform's bidding algorithm optimises toward whatever you tell it success is. If success is a form fill, it will find you cheap form fills, including from people who never buy. If success is a closed sale with an amount attached, it will bid toward the people who look like buyers.
- What data do I have to send to the ad platform?
- For click-based imports, the click identifier the platform gave you, plus the conversion time and value — no personal data at all. For identity-based matching, hashed emails or phone numbers. The click-based route is strictly better for privacy and should be the default wherever the identifier survives.
- Is uploading customer data to Google or Meta a privacy risk?
- It is a data sharing decision with real consequences, and it needs a lawful basis, a record in your processing register, and usually a mention in your privacy notice. Hashing reduces exposure but does not make the data anonymous, because the whole point of the hash is that the platform can match it.
- Should I trust the platform's reported results after uploading?
- Use them for optimisation, not for reporting. Once a platform knows which sales closed, its own reports will attribute those sales to itself under its own model. That is useful for bidding and it is not an independent measurement of your marketing.
- How long does an offline conversion take to affect performance?
- Bidding algorithms generally need a few weeks and a meaningful volume of conversions before behaviour changes noticeably. If your sales cycle is long, the feedback loop is long too, and setting expectations about that in advance prevents the change being abandoned before it can work.