Enhanced conversions: sending qualified leads back to ads

Enhanced conversions is Google's name for sending hashed customer data back to the ad platform so it can match an outcome to the click that produced it. Meta calls its version the Conversions API, TikTok calls it the Events API, and Google also offers offline conversion import for outcomes that happen days or weeks after the click. Different names, one job: telling the platform which leads turned into money.

You need this because the platform's record of your account stops at the form. It knows the click, the visit and the submission. It does not know that the phone number was fake, that the lead wanted a quote for next year, or that one particular submission became a contract worth $4,200. Everything it optimises toward is drawn from the half of the story it can see.

A lead generation account we looked at had run for eight months with cost per lead below target and improving every month. The platform ranked it among the best in the portfolio. Then the sales director pulled her own numbers: the cheapest source of leads produced almost no revenue. Both reports were correct. They were counting different things.

Why the platform stops counting at the form

Follow one lead all the way through.

Somebody clicks an ad. The platform logs the click. They read a page, then submit a form. The tag on the thank-you page fires and the platform logs a conversion. As far as it is concerned the job is finished and it went well.

The part that decides whether you made money happens next, outside its view. Someone calls. Maybe nobody answers. If they do answer, maybe they are buying this quarter, maybe they are comparing prices for a purchase eighteen months away, maybe they filled the form in by accident. If they are serious there is a quote, a negotiation, a decision. Weeks later a deal closes, or it does not.

None of that reaches the ad platform. So when the bidding system asks itself who to show the ad to next, the only material it has is "people who behaved like the ones who submitted forms".

Form-fillers and customers are not the same group of people. They overlap, and the overlap is usually smaller than anyone in the room assumes. That gap is the entire subject of this article.

What enhanced conversions actually send

Nothing about the lead's record leaves your system. No notes, no deal history, no name of the company. What crosses is the smallest set of facts that answers one question: was this outcome produced by somebody who saw one of your ads?

In practice that is one or two identifiers plus four fields describing the event.

The identifiers. Either a click identifier that the platform appended to your landing page URL and you stored against the lead, or the lead's email address and phone number, normalised and hashed with SHA-256 before they leave your server. Normalising means lower-casing the email, stripping the spaces around it, and writing the phone number with its country code. Hash a capital letter and you get a completely different string, which will never match anything.

The four fields. Every platform wants the same four, under slightly different names:

• Event name — must be exactly the conversion action you created in the ad account, character for character.
• Timestamp — when the outcome happened, not when your job ran. Get this wrong and you attribute Tuesday's deal to Friday's spend.
• Value and currency — one number and its unit. Never send a bare number; a value with no currency code is a number the platform is free to interpret however it likes.
• Event id — a string you also put on the browser tag for the same outcome, so the platform can throw one of the two away.

That is the whole payload. It is small enough to write by hand, which is worth remembering when a vendor describes it as a major integration.

What changes when the platform learns from closed deals

Three things move, and the first one causes the other two.

The optimisation target changes. The system stops hunting for people who resemble form-fillers and starts hunting for people who resemble buyers. Everything else follows from that.

Bidding gains an economic meaning. If leads from one campaign close four times as often as leads from another, the platform can now bid accordingly. Without that information it treats every lead as identical, which guarantees it overpays for the weak ones and underpays for the strong ones.

The two reports stop contradicting each other. "We delivered 400 leads" versus "they were worthless" turns into one number both departments are looking at. Several teams have told us this mattered more to them than any performance gain.

What it will not do: rescue weak creative, fix bad targeting, or work at all if your sales records are unreliable. Sending back wrong outcomes is worse than sending nothing, because the system will believe you.

Google, Meta and TikTok side by side

Each platform names its version differently, which causes confusion out of all proportion to the actual differences.

Google Ads. Two related mechanisms. Enhanced conversions for leads takes hashed email or phone collected on your form and matches the later outcome to the original click. Offline conversion import takes the click identifier you stored when the visitor arrived, paired with the outcome and its value, and tells Google that this specific click eventually became revenue. The second is the cleaner of the two, because the match is exact rather than probabilistic. Google's import will not accept a click beyond a certain age, so check the current limit before you design around a long sales cycle.

Meta Conversions API. Your server posts conversion events straight to Meta, alongside the browser pixel or instead of it. Matching runs on hashed identifiers in the user data object. Best documented of the three and the most forgiving when your identity data is patchy.

TikTok Events API. Structurally the same as Meta's, with its own event schema and its own click identifier in the landing URL.

Which one first: whichever platform holds the largest share of your spend, because that is where a better signal moves the most money. If two are close, Google's offline import is usually the easier first project when you already have a CRM, since storing one identifier per lead is less work than standing up an event stream.

Identity matching: what crosses over, what gets dropped

Hashing turns an identifier into a fixed-length string that cannot be turned back into the original. The platform hashes its own records the same way and compares strings. Neither side ever transmits a readable email address.

That reduces your exposure. It does not remove your obligations — you are still transferring personal data, and privacy law treats hashed personal data as personal data.

Things that get dropped, in rough order of how often we see them:

• Records where the email was never collected, because the form only asked for a phone number.
• Phone numbers stored as 0901888484 with no country code, hashed as typed.
• Email addresses with a trailing space, or with the capital letter the person typed.
• Leads who arrived from an untracked source and never had a click identifier to store.
• Leads who came through a channel you are not advertising on, which is correct behaviour and not a fault.

The click identifier route deserves separate mention because it avoids personal data almost entirely. When a visitor arrives from an ad, the platform appends a parameter to the URL. Capture it in a hidden form field, store it against the lead, send it back with the outcome. The platform matches on its own identifier rather than on anything about the human being.

That is cleaner on privacy and more accurate on attribution. The catch is that it needs a change to how your forms are handled, and it only covers people who arrived through a tracked click. Where both routes are available, use them together: click identifier where you have it, hashed identifiers as the fallback.

Match rate is the number that tells you it works

Match rate is the share of events you send that the platform can tie to a person who saw an ad. Everything else about your build can be perfect and the match rate can still make it pointless.

Below fifty percent is worth an afternoon of investigation. Below twenty percent, most of the work you did is being discarded at the door and you should stop tuning anything downstream until it improves.

Reading a low number is usually a short exercise. Check whether you send one identifier or two — adding the phone number to a form that only collected email is often the whole fix. Check normalisation by hand: take one real address, hash it in your pipeline, hash it again in a terminal, compare the strings. If they differ, you have found your problem in ten minutes. Check that phone numbers carry a country code at the point of capture rather than being patched later.

Compare your match rate against your own last month rather than against a figure you read somewhere. A B2B account with company email addresses and a B2C account with mobile numbers will land in different places for reasons that have nothing to do with build quality.

Leads that qualify weeks later

Time is the constraint people underestimate most.

A three-day sales cycle makes this straightforward. Outcomes come back while the campaigns that produced them are still running, and the platform can act on them.

A three-month sales cycle is a genuine design problem. Feed back closed deals and the signal lands long after those campaigns changed. The system is learning about a world that no longer exists.

Three ways around it, none of them free:

Send an earlier stage. Qualification instead of closed-won. It happens within days, and it separates good from bad far better than a raw form fill does. This is the right answer for most accounts.

Send a predicted value. When a lead qualifies, send the expected deal value based on your historical close rate for that segment. You trade precision for timeliness. Reasonable when your rates are stable; misleading when they move.

Send both, at different stages. Qualification as the optimisation event, closed-won as a separate reporting event. More to maintain, and it gives you a fast learning signal plus accurate books.

Waiting for perfect data is the option that does not work. A signal that arrives three months late has almost no optimisation value however accurate it is.

Five ways these builds fail

Double counting. The browser tag fires and your server sends the same outcome, and the platform records two. Every platform provides a deduplication key. Using it is not optional. Skip it and your reports look magnificent and are wrong by a factor of two.

Low match rates nobody looks at. Covered above. The failure mode is that the pipeline runs beautifully and quietly achieves nothing, because the events arrive and cannot be tied to anyone.

Test data sent to production. Every platform offers a test mode. Skip it and your first day of debugging is baked permanently into the optimisation data.

Silent failure. A credential expires or a schema changes, the upload stops, and nothing tells anyone. Conversions quietly stop arriving, performance decays over weeks, and somebody works out the cause months later. Alert on the absence of events, not only on errors — an absence produces no error to catch.

Wrong currency or wrong scale. Values sent in the wrong currency, or in cents where the platform expects whole units, aim the optimisation at figures a hundred times off. Any number crossing a system boundary needs its unit attached at the point of sending, not documented somewhere.

What the numbers look like before and after

An illustrative walk-through with the shape we see most often. Substitute your own figures.

Before. Two campaigns. Campaign A produces 200 leads a month at $12 each. Campaign B produces 60 leads at $34 each. Every dashboard prefers Campaign A by a wide margin, and budget has been drifting toward it for months — exactly what a well-behaved system should do given what it was told.

After. The sales data arrives. Of Campaign A's 200 leads, 18 qualify and 3 close, averaging $1,100 each. Of Campaign B's 60 leads, 22 qualify and 9 close, averaging $2,400 each.

Recompute against spend of $2,400 on A and $2,040 on B:

Measure	Campaign A	Campaign B
Spend	$2,400	$2,040
Leads	200	60
Cost per lead	$12	$34
Qualified	18	22
Cost per qualified lead	$133	$93
Deals closed	3	9
Cost per deal	$800	$227
Revenue	$3,300	$21,600
Return on spend	1.4×	10.6×

On cost per lead, A wins by nearly three to one. On return on spend, B wins by more than seven to one. The campaign every dashboard called the winner was the loser, and the bidding system had been steadily moving money toward it for months.

Two things about this example are worth noticing.

Nobody made a mistake. The system optimised correctly toward the goal it was given, and the goal was wrong.

The gap only looks obvious once measured. It stays hidden because the two halves of the data sit in different systems owned by different departments, and nobody routinely joins them. That is also why we suggest starting with measurement rather than with a build — the comparison alone frequently changes decisions before a single event has been sent anywhere.

Consent, and the data you must not send

Identity matching runs on personal data. That carries obligations wherever you operate, and hashing does not dissolve them.

Settle these before you write code, not after:

• Lawful basis. On what grounds are you transferring this person's data to an advertising platform? "The vendor said it was fine" is not an answer that survives a question from a regulator or a customer.
• Notice. Does what you told people at the point of collection actually cover this use?
• Deletion. When someone asks to be removed, you need a way to stop sending them and to pass the request on. Build the ability to exclude records from the upload on day one; retrofitting it is unpleasant.
• Special categories. Health, finance and a few other categories carry extra restrictions, and some platforms prohibit sending events from certain verticals entirely. Read your platform's own policy for your industry.

Two practical rules that keep you out of trouble. Send the minimum that makes the match work — an email hash and a phone hash, not a name, address, job title and company size because the API happens to accept them. And keep a record of which consent state each uploaded record was in, so you can answer the question later without reconstructing it from memory.

A project plan, week by week

Week one — decide the event. Not a technical task. Marketing and sales have to agree which pipeline stage represents a genuinely good outcome, and you have to confirm that stage is recorded consistently by everyone who touches it. If it is not, fixing that is the whole first week, and it is the most valuable week of the project.

Week two — measure the gap by hand. Export last quarter's leads with their sources and outcomes. Join them to platform-reported conversions in a spreadsheet. Build the table from the section above for your own account. This tells you the size of the prize and gives you the baseline you will judge success against.

Week three — build it in test mode. Wire the upload, send test events, confirm they arrive and match. Verify deduplication if you are also running a browser tag. Do not skip this because the payload looks trivial; the payload is trivial and the normalisation is not.

Week four — go live and change nothing else. Resist restructuring campaigns in the same week. You want a clean before and after, and confounding it with other changes makes the result impossible to read.

Weeks five to ten — leave it alone. The hardest part. Cost per lead will rise. Somebody will ask why. Tell them before it happens: you stopped paying for leads that were never worth having, and the number that matters now is cost per qualified lead.

Week ten onward — recalibrate. Establish the new baseline, rewrite thresholds and automated rules against it, then start optimising campaign structure again.

Ten weeks elapsed, roughly two weeks of actual work. The rest is how long the systems take to respond, and shortening it is not within your control.

Signals worth sending beyond the conversion

Once the pipe exists it can carry more than one event, and a few additions repay the effort.

Lead quality grades. If your sales team already grades leads, sending the grade lets the platform distinguish more finely than a binary qualified-or-not. Even three tiers adds usable shape.

Product or service category. When you sell several things at different margins, telling the platform which one a conversion related to lets optimisation work per product rather than in aggregate.

Negative signals. Some platforms accept an indication that a lead was invalid — wrong number, duplicate, obvious spam. This is underused and valuable, because it teaches the system what to avoid rather than only what to chase.

Time to first contact. Not a platform input, but capture it anyway. It is frequently the largest single driver of qualification rate, and it has nothing to do with advertising. Teams regularly discover through this work that their real problem was a two-day response time.

Against over-engineering: every extra field is another thing to maintain and another place a schema mismatch can hide. Start with one event and a value. Add the rest after the basic loop has run untouched for a month.

What this does to your automated rules

If you run automated rules over campaigns, closing the loop changes what those rules can say.

Before, a rule could only test "cost per lead above target". Now it can test "cost per qualified lead above target", which is a different and far more useful statement. The numbers in the rule have to change with it. A qualified lead legitimately costs several times what a raw lead costs, so thresholds written against the old measure will fire constantly against the new one and pause campaigns that are working.

Sequence that avoids the mess: close the loop, wait four to six weeks for enough qualified conversions to pile up, read the new baseline off real data, then rewrite the thresholds. Rewriting on day one produces rules calibrated against a guess.

The wider point is about order of work. Clean conversion data comes before automation, not after. Automation applied to a bad signal does not fail occasionally; it fails consistently and quickly. An hour spent on the signal is worth several spent tuning rules that sit on top of it.

Three numbers to watch every month

After go-live, a monthly check on three numbers will catch almost everything that goes wrong.

Events received versus outcomes recorded. Count the qualified leads in your CRM for the month, count the events the platform says it received. The two will not be identical, but the ratio should be stable. A ratio that moves means something in the pipeline changed — a filter, a credential, a field that stopped being populated.

Match rate. Same number, same place, every month. A slow decline usually traces to data quality upstream: a new form that collects one identifier fewer, or a source that stopped passing the click parameter.

Cost per qualified lead by campaign. The number the whole project exists to produce. Watch the ranking of your campaigns by this measure rather than the absolute figure. When the ranking starts to differ from the ranking by cost per lead, the new signal is doing its job.

Add one habit to the three numbers: two to three months after go-live, look at which campaigns and audiences the platform now favours. If nothing has shifted, the signal is too weak or arriving too late to influence anything, and the fix is upstream rather than in the bidding settings.

Frequently asked questions

Do I still need the browser tag if I send server events?

Generally yes. The tag captures browser context your server does not have; the server captures outcomes the browser never sees. Run both with deduplication, which is the configuration all three platforms expect.

Can we send a daily batch instead of streaming?

Yes. Daily batches are fine for most sales cycles. Real time only matters when your cycle is measured in hours.

What happens if we send the same conversion twice?

With a shared event id, the platform discards the duplicate. Without one, it counts both. This is the single most important implementation detail and the one skipped most often.

What if a deal is cancelled or refunded later?

Platforms support corrections in different ways, generally by sending a negative or adjusted value. If refunds are material in your business, handle them from the start. Retrofitting means reconciling months of overstated values.

How much traffic does this generate?

Very little. You are sending one small payload per meaningful outcome, not per page view. Even a large lead generation business produces a few thousand events a month.

Does this improve attribution accuracy?

It improves what the platform optimises toward, which is a different question. Attribution asks which channel deserves credit for a sale. This asks which outcomes are worth chasing. The two get confused constantly.

How long until I see a difference?

Four to eight weeks in most accounts, depending on volume. The platform needs enough of the new signal to change behaviour, and campaigns need time to relearn afterwards.

Is this only useful for lead generation?

It is most useful there, because the distance between a form and revenue is longest. E-commerce benefits too: sending net revenue after returns rather than gross at checkout changes optimisation noticeably in categories with high return rates.

Which platform should I start with?

Whichever carries most of your spend. If two are close, start with Meta — the Conversions API is the best documented and the most tolerant of imperfect identity data, so you learn the moving parts on the easier problem.

What if my CRM cannot send webhooks?

Most can, sometimes through an automation tool rather than natively. Failing that, a scheduled export processed by a small script works. The loop does not have to be real time to be useful.

Will my cost per conversion look worse afterwards?

Almost certainly, and that is correct. You have replaced a cheap plentiful event with an expensive meaningful one. Moving from $12 per lead to $95 per qualified lead is not a regression, it is the first honest number you have had. The mistake to avoid is reporting the new figure against the old target, which makes a successful change look like a failure and gets it reversed.

Do we have enough volume for this?

Below roughly thirty meaningful conversions a month, the platform cannot find a pattern and feeding the events back changes nothing. Put the effort into targeting and creative until volume supports it. You can still send the events for measurement — the reporting value does not need volume.

Can I run this alongside existing reporting without changing anything?

Yes, and it is a sensible first phase. Send outcomes for measurement only, keep optimisation pointed at the old event, and compare the two pictures for a month. You get the diagnosis without disturbing anything, and the comparison usually settles the internal argument about whether to proceed.

Start with the measurement

Pull last quarter's leads out of your CRM, tag the ones that became revenue, and compare that against what the platform reported for the same period. It takes an afternoon and needs no engineering support.

That comparison answers the only question that matters before you build anything: how far apart are the two pictures? If they are close, your account has bigger problems to solve elsewhere. If they are far apart — and in lead generation they usually are — you now have the table that gets you the engineering time, and a baseline to judge the result against.

Related reading: why clean conversion data comes first, Meta CAPI versus Google versus TikTok Events API, and incrementality versus last-click attribution.

Read next: Form Optimization: How to Stop Losing Leads at the Form