Hector Herrera Résumé

Writing · essay

Server-side conversions in plain English

What server-side conversion tracking is, why browser pixels lost signal, how deduplication and hashing work, and when it's worth building versus when it's overkill.

By Hector Herrera · · 5 min read

"Server-side tracking" gets pitched as a cure for bad attribution. It isn't a cure. It's a sturdier way to send conversion data that you already know about. Used for the right reasons, it closes real gaps. Used as a way to get around a visitor's choices, it's a liability.

Here's how I explain it to business owners, without the vendor gloss.

Pixels vs server-side events

A pixel is a snippet of JavaScript that runs in the visitor's browser. When something happens, like a page view or a form submission, the browser sends an event to the ad platform. Meta's pixel and Google's tags work this way by default.

A server-side event is sent from a server you control instead of the visitor's browser. When your system records that a lead came in, your server sends that event directly to the platform's API. Meta's version is the Conversions API. Google Ads accepts conversions from your systems through offline conversion imports and its API.

There's also server-side tagging, which is a slightly different idea. Instead of the browser sending data to many third parties, it sends data to a tagging server you run (for example, a server-side Google Tag Manager container on your own subdomain). That server then decides what to forward and where. It gives you more control over what leaves your hands, at the cost of running and paying for another piece of infrastructure.

Why browser signals got weaker

Pixels used to be good enough. Several things changed:

  • Ad blockers and privacy extensions block many tracking scripts entirely.
  • Browser tracking protections, like Safari's Intelligent Tracking Prevention and Firefox's Enhanced Tracking Protection, limit third-party cookies, shorten the life of some script-set cookies, and in some modes strip known click-ID parameters from URLs.
  • Consent requirements mean that in many places, some visitors will decline and tags should respect that.
  • Scripts fail. Slow pages, visitors leaving before a tag fires, or a broken tag after a site update.

The result is that the browser misses a share of conversions, and the ad platform optimizes on an incomplete picture. How big that share is varies by audience and site, which is why I'd measure it for your own setup rather than trust a generic number.

Deduplication: sending twice without counting twice

The usual setup runs both: the pixel in the browser and the server event from your backend. That gives you redundancy, but the platform needs to know they're the same conversion.

For Meta, that's done with an event ID. When the form submits, you generate a unique ID, send it with the pixel event, and send the same ID with the Conversions API event, using the same event name. Meta then counts it once.

Browser pixel:   event_name=Lead, event_id=lead_8f3a2c
Server (CAPI):   event_name=Lead, event_id=lead_8f3a2c
Result:          one Lead, not two

If the IDs don't match, or one side uses a different event name, you'll double-count. That's one of the most common problems I check for. It inflates reported conversions and teaches the platform the wrong lesson.

For Google Ads, the model is a bit different. If you import offline conversions for a later stage like "qualified lead," that's usually a separate conversion action from the on-site form conversion, so you decide which one bidding should optimize toward rather than deduplicating them against each other. I covered that flow in attribution when the sale happens off the website.

What data to send, and how

Server events are matched to people using identifiers. The platforms document which ones they accept. Typical ones:

  • Email and phone, normalized (trimmed, lowercased, phone in a consistent international format) and then hashed with SHA-256 before sending.
  • Click identifiers and browser IDs, such as gclid for Google or Meta's fbc and fbp values, captured at the time of the visit. These are not hashed.
  • IP address and user agent, which some platforms accept to improve matching.
  • Event details: name, time, source URL, and value if you use one.

Hashing is not the same as anonymization. A hashed email can still be matched by a platform that has the same email. Treat it as personal data.

Send the minimum you need. There's no reason to forward the free-text message from a form, or anything sensitive the person told you. On legal and health-adjacent sites especially, keep case details out of any payload that leaves your systems.

Consent and privacy obligations

Moving an event from the browser to the server doesn't change what you're allowed to do with it. If a visitor declines advertising tracking, sending the same data from your server instead is still sending it.

So:

  • Check consent state before sending server events, and pass it where the platform supports it.
  • Make sure your privacy policy describes this data sharing accurately.
  • Get legal advice on your obligations where your visitors are. That's a real question, not a formality.

Done properly, server-side sending can actually improve privacy, because you control exactly which fields go out, instead of a third-party script collecting whatever it can.

When it's worth it, and when it's overkill

It's usually worth it when:

  • You spend meaningfully on Meta or Google and rely on automated bidding.
  • Conversions happen in a backend or CRM that the browser never sees.
  • You can see a real gap between conversions recorded in your system and those reported by the platform.
  • You have someone who can maintain it.

It's probably overkill when:

  • Ad spend is small, or you're not running paid media at all.
  • The basics aren't working yet. If UTMs are inconsistent and forms don't capture click IDs, fix that first, as in GA4 and Tag Manager setups that answer business questions.
  • Nobody will monitor it. A server integration that fails silently is worse than a pixel you know is imperfect.

My own personal site runs no trackers at all, because it doesn't need them. Lead-generation sites with serious ad spend are a different story. Choose the simplest architecture that will still scale. For many businesses, that's a pixel plus a well-built offline import. For some, it's a server-side setup with deduplication, consent checks, and alerts when events stop flowing. Measure the gap first, then decide.