Server-side tracking records the conversion on a server and sends it to the other side, server to server. A pixel asks the visitor’s browser to do it. For lead and call buyers, the server is the better witness. Here is why.
Key takeaways
- A pixel runs in the visitor’s browser. A server-side postback runs between servers.
- Phone calls are not page events. A pixel cannot see them.
- Safari limits how long scripts can keep cookies, and blockers can stop pixels from firing.
- A server record with a click ID can carry late outcomes, such as “qualified” or “signed.”
- Pay on the server record. Keep a pixel, if you need one, as a second opinion.
What is a pixel, and what is server-side tracking?
A pixel is a small piece of code on a page. When the page loads or a form is submitted, the visitor’s browser fires it and reports a conversion.
Server-side tracking skips the browser. When a lead is submitted or a call ends, your system records it and sends a message, called a postback, to the buyer, the publisher or the ad platform. The message carries the click ID, so everyone can match the outcome to the click.
Pixel vs server-side tracking at a glance
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Five reasons pixels fall short for lead and call buyers
1. Calls do not happen on the page. A phone call is not a page event. A pixel cannot see a call, how long it lasted, or whether it qualified. Your call platform can. In pay-per-call, the outcome that sets the payout lives on a server.
2. Browsers limit what scripts can store. Safari’s tracking prevention deletes cookies and other script-written storage after seven days without the visitor interacting with the site. WebKit cuts that to 24 hours for cookies created on a landing page reached through a link carrying a click ID. (Source: WebKit, Tracking Prevention) Ad blockers and privacy browsers can also stop a pixel from firing. Each of these is a lost conversion on a pixel report and a normal one in a server log.
3. The best outcome comes late. A lead becomes “qualified” or “signed” days after the click. A pixel fires at the click or the form. A server can send the later outcome when it happens.
4. Pixels fire when they should not. A page can reload, a visitor can hit back, or a script can run twice. That makes duplicate conversions. A server record with a unique ID makes deduplication straightforward.
5. Pixels are easy to fake. Anyone who can load a pixel URL can fire it. A postback can be limited to known senders and checked against the original click ID. For a buyer paying on outcomes, that matters.
How server-side tracking works, step by step
- Every click gets a unique click ID, passed in the URL to your landing page or call number.
- Your page or platform stores that ID on your server, not only in a cookie.
- When the lead is submitted or the call ends, your server records the outcome against that ID.
- Your server sends a postback with the click ID and the outcome: lead, call connected, call over the minimum duration, qualified, or signed.
- The receiver matches the click ID and records the conversion. If the same ID arrives twice, it counts once.
What this looked like when the numbers did not match
In late September we ran a paid-channel test on one of our legal landing pages. We tagged every click with the platform’s ad ID and passed it through to our own lead system. We also logged each landing on our side.
The platform’s reports showed one number of clicks. Our log showed fewer landings. For four days, that was 184 paid clicks against 157 landings.
That gap does not prove a bad click. A click and a page load measure different steps. But because we kept our own record, we could do what the platform asked next: give them our time zone, our definition of a landing, and logs for the same dates. Both sides looked at the same data instead of arguing from screenshots.
Why this matters for fraud and disputes
Timing and quality checks need clean data. When every outcome is tied to a click ID and a timestamp on a server, you can measure time-to-convert, find the bad sub ID, and answer a dispute with records.
It also makes reconciliation shorter. When buyer and publisher both work from server records, the monthly argument is about the edge cases, not the whole count.
What server-side tracking will not do
It does not fix bad traffic. A bot can still submit a form. It also does not remove consent or privacy duties. You still have to follow the rules for the data you collect and share.
It takes setup. You need click IDs end to end, a reliable store, and someone who owns postback testing. The first week usually finds a gap.
When to keep a pixel
Keep one where a platform needs it, such as ad optimization signals. Treat it as a second opinion. The server record is the one you pay on.
Where this fits at RPM
We have run performance marketing since 2015, and RPM has made the Inc. 5000 seven years in a row. We pay on outcomes, so we want the record of the outcome to come from a system that a browser setting cannot block. The only metric that matters at the end of the month is your cost per case, and you can only trust that number if the count behind it is right.
Frequently asked questions
What is the difference between a pixel and a postback?
A pixel fires from the visitor’s browser. A postback is sent from one server to another, usually carrying the click ID and the outcome.
Do I still need cookies for tracking?
Often as a convenience, but a click ID stored on your own server does not depend on a cookie surviving.
Does server-side tracking work for phone calls?
Yes. Call platforms record the call on the server and can send the outcome, such as connected, duration and qualified, back by postback.
Will server-side tracking end attribution disputes?
It shortens them, because both sides can point to the same click ID and timestamps. It does not settle disagreements about lead quality.
Is server-side tracking only for large buyers?
No. If you pay on outcomes, you want the record of the outcome on a server.
Part of the RPM Insights library.