How to Send Conversions Back to an Ad Platform
How to send conversions back to an ad platform: report one chosen outcome from your server, deduplicate it against the browser and verify with a real test lead.
To send conversions back to an ad platform, report the one outcome you chose from your own server as well as from the browser, carry the click identifier the platform added to the ad link, and make the two reports match so each conversion is counted once. Then submit a real test lead and confirm the platform received it a single time.
This is the most important technical detail in modern paid advertising, and it is where many small setups quietly fail. The platform learns from the signal you return. If the signal is partial, doubled or about the wrong event, it learns from noise, and it does so very efficiently.
How to send conversions back to an ad platform: why the browser alone is not enough
A browser pixel is a small piece of code on your page that reports what a visitor did. It is the usual starting point, and it has a weakness: it loses a meaningful share of conversions to ad blockers, privacy settings and declined consent.
When that happens, the platform sees fewer results than actually occurred. It then optimises from a partial picture. A campaign that is working can look as though it is not, and the platform's search for people like your customers is trained on an incomplete group.
The fix is to send the conversion from your own server as well, through the platform's conversions interface. Your server knows when a form was really submitted, whatever the visitor's browser chose to share. It sends the result along with the click identifier that the platform appended to the ad link, which is how the platform ties the conversion back to the ad that produced it.
Three disciplines that decide whether it works
Switching on server reporting is the easy part. Whether it helps depends on three habits, and each one prevents a different quiet failure.
| Discipline | What to do | What goes wrong without it |
|---|---|---|
| Send one event | Report the conversion you chose, and nothing else | Page views and button clicks teach the platform to find browsers |
| Deduplicate | Send the same event from browser and server with the same unique identifier | Each conversion is counted twice and the platform trains on inflated results |
| Match the event name | Use the same name on both sides | The two reports are never matched, whatever the identifier says |
Send one event, not everything
It is tempting to report every action a visitor takes, on the theory that more information must help. It does not. The platform optimises towards what you report, so reporting everything tells it to find people who do everything, including people who only browse.
Choose the single conversion that best stands for success, and keep it as close to revenue as your volume allows. A completed lead form is the usual starting point for a business that sells through conversations. A qualified lead or a purchase is better if you have enough of them for the platform to learn from. If you are using a proxy, be explicit that it is one. The thinking behind choosing the event is in how to set an ad cost ceiling.
Deduplicate, or every result looks twice as good
If the browser reports a conversion and the server reports the same conversion, the platform needs a way to know they are one event. That way is a shared unique identifier. When both reports carry the same identifier, the platform treats them as one. When they do not, it counts two.
Double counting is flattering, which is why it survives. Every result looks twice as good, the cost per result halves and the dashboard looks healthy. The platform's learning is trained on the inflated number, and your own decisions are made against a figure that was never real.
Use the same event name on both sides
This one is easy to miss because it looks like a detail. If the browser calls a form submission a subscription and the server calls it a lead, the platform will not treat them as the same thing, however carefully the identifier is shared.
Pick a name, write it down and use it in both places. When anyone changes one side later, change the other the same day. A written note of the event name and the identifier rule is worth keeping, because the two sides are often set up by different people at different times.
Get the click identifier through
The click identifier is what lets the platform say which ad this conversion belongs to. It travels in the ad link, so it has to survive the journey from the ad to the form and on to your records, where the server can read it when the conversion is sent.
Check that journey by hand. Click your own ad, confirm the link arrives with its identifiers intact, and submit the form from that click. Then look for the new contact and confirm that its source is attached. If the identifier is missing at the end, the server has nothing to send, however well the rest is built. A lead whose link carries no identifier cannot be credited to its campaign, which is also why the platform's campaign and ad identifiers belong on every ad, as covered in how to run a small ad test.
Test with a real lead before the money runs
Do not trust a setup you have not watched. Before launch, run through this list with a real submission.
- The browser pixel is installed on every page an ad can land on.
- The server-side conversion is switched on and sends only the outcome you chose.
- Browser and server send the same event name and the same unique identifier.
- You submitted a real test lead and confirmed the platform received it once, not twice.
The last line is the one that catches the quiet failures. If the platform shows the test lead twice, deduplication is broken. If it shows it zero times, something is missing on the path. Fix it before spending, because the platform starts learning from the first conversion it sees.
Reading the symptoms
When the platform's picture looks wrong, the pattern of the error usually points at the cause. This table lists what you might see and where to look first.
| What you see | Likely cause | Where to look |
|---|---|---|
| Your test lead shows up twice | Browser and server are not deduplicated | The unique identifier on each report |
| Your test lead shows up, but not matched to the ad | The event names differ between the two sides | The name used in the browser and the server |
| Far fewer conversions than your own contacts | The browser is losing some, and the server report is off or incomplete | Whether the server-side conversion is switched on |
| Plenty of results, few real customers | The event is too far from revenue, or too many events are reported | Which conversion you chose to send |
| Contacts with no source attached | The ad link lost its identifiers on the way | The journey from the ad to the stored contact |
Notice that none of the fixes is inside the creative. The signal is a plumbing problem, and plumbing problems hide behind healthy looking dashboards.
Who owns the setup
Two sides have to agree for this to work, and in a small company they are often set up by different people at different times. The page may be built by one person and the conversion interface connected by another. That is how event names drift apart.
Give the setup one owner and one written note. The note should say which event you send, what it is called, how the unique identifier is made and where the click identifier is stored. Whenever anyone changes the form, the page or the connection, they check the note first and repeat the real test lead afterwards. It takes minutes, and it protects every campaign that follows.
Know what the platform still cannot see
Even with a clean server report, the platform sees only its own side of the story. It knows who clicked and what you told it afterwards. It does not know whether the lead became a conversation, a deal or revenue unless you tell it, and it counts conversions its own way, so its figure and your count of real people will differ.
Treat the platform's number as a reference and keep a second ledger of your own. The reasoning is in how to judge ads by deals not clicks. Where the numbers disagree, neither is wrong. They answer different questions, and yours is the one that decides the budget.
What consent does to the picture
Where consent applies, some visitors will decline. Their browser activity may not be reported at all, which is part of why the server report matters. Know what share of visitors decline, and what that hides, because a consent banner can conceal everything that happens after it. Where the gap sits, and what to do about it, is covered in how to read the path from ad click to lead.
Frequently asked questions
Why not rely on the browser pixel alone?
Because ad blockers, privacy settings and declined consent mean it loses a meaningful share of conversions. The platform then sees fewer results than happened.
What is deduplication?
It is making sure a conversion reported by both browser and server is counted once. Both reports must carry the same event and the same unique identifier.
Should I report every action to the platform?
No. Report the one conversion you chose. Page views and button clicks teach the platform to find browsers.
How do I know it is working?
Submit a real test lead from an ad click and confirm the platform received it exactly once.
The full method, with the checklists, is in The Paid Ads Playbook, a free 31-page playbook.