Guide
Server-side tracking, explained
Server-side tracking sends events from a website or app to a server on the advertiser's own domain first, which checks, cleans and forwards them to the ad platforms and tools the advertiser chooses. Consent still decides what may be sent, exactly as it did before.
The path of an event today
Someone signs up for a trial from an ad, and weeks later the sales team marks them as a customer in the CRM. In the usual setup the page loads a separate script for every vendor. Each script tries to remember the visit inside the browser, and each one reports to its own platform. Some of those reports never leave the browser, some are cut short, and none of them knows about the others. By the time the sale closes, the click is long forgotten and the CRM never heard of it. The platform that showed the ad sees a sign-up at most, and the advertiser sees several partial stories that don't add up. Server-side tracking makes that signal more complete and easier to control.
Where the signal goes missing
Browsers limit how long data written by scripts can last, and cut it shorter still when a visitor arrives from a link that carries tracking parameters. Some strip those parameters from links, keep each site's cookies in a separate jar, or block calls to known trackers, especially in private browsing. Mobile operating systems ask permission before an app can track a person across other companies' apps and sites. People decline consent, use blockers and close a page before a tag fires, and tags break after a site release.
Each of these is legitimate, and each one thins the signal platforms learn from. Third-party cookies have not disappeared everywhere, so the gap doesn't come from one switch being turned off. It comes from many limits adding up, which is why it is worth fixing at the source. See signal loss.
What moves to the server, and what doesn't
What changes is where events are collected and who sends them. The browser or app sends one event to an address on the advertiser's own domain, a first-party collection endpoint. The server validates it, adds what the browser doesn't know, such as the true order value or the stage of a lead in the CRM, and forwards it through the server-to-server conversion APIs the platforms publish.
What stays the same is consent. The event carries the person's consent state, and the server forwards to each destination only what that state allows. Where a browser or device sends an opt-out preference signal, the server applies it downstream. A setup that sends more than the person agreed to is a wrong setup, wherever it runs.
Counting each conversion once
Some platforms recommend sending events from the browser and from the server together, which means the same purchase can arrive twice. A shared event ID, created once and sent by both, lets the platform keep one of them. That is event deduplication.
Matching is a separate question. A platform can use an event only if it can connect it to one of its own users, and the share it manages is the match rate. Identifiers are normalized before they are hashed, because an email with a stray capital letter or a space produces a different code and the match is lost.
A real first-party domain, and a borrowed one
Collection should run on a path of the advertiser's own site, or on a subdomain served from the same infrastructure as the site, so the browser treats it as the advertiser's own. A subdomain that simply forwards to someone else's server looks first-party in the address bar and isn't. Browsers increasingly recognize the pattern and limit what such a subdomain can store, or block the call in private browsing. It also tells anyone reviewing the setup that the data was going somewhere else.
Hashing protects the value. It doesn't hide the person.
Before an email or phone number is shared with a platform, it is turned into a fixed code with a one-way function, so the raw value never travels. The same input always gives the same code, and that is the point, since it is how the platform finds a match. It also means the code still points to one person. Hashed data is personal data and should be handled that way.
Sales that close offline
A signed contract, a store purchase or a lead that becomes a customer weeks later can be sent back from the CRM or the point of sale through the same server, as an offline conversion. The platforms that accept them use them to measure and to optimize toward the customers who actually buy. Timing matters, since each platform accepts events only within its own window, and a late event can be rejected together with the rest of its batch.
One practical rule. Send the conversion when the server confirms the action, such as the order being recorded, and never let the send slow down or break the response the person is waiting for.
A quality checklist
- An event schema with required fields and types
- One event ID per action, shared by the browser and the server
- Identifiers normalized before they are hashed
- Event time correct and inside the window each platform accepts
- Value and currency taken from the order system
- Consent state on every event
- Retries only on temporary errors, and a separate queue for events that fail validation
- Sends that can be repeated safely, so a retry never creates a duplicate
- A log of every delivery and the platform's response, with no personal data in clear text
- Alerts when volume or match rate drops for any destination
- Reconciliation with orders and the CRM
- A test environment, and versioned changes that can be rolled back
- Access by role, encrypted platform keys and no secrets in browser code
How we run it
We run server-side, first-party tracking for the advertisers we work with, on the advertiser's own domain, with consent checked before anything is forwarded and every delivery logged. The full setup is on Technology, and how the data feeds measurement is on Measurement. How the platforms bid on those events is on Digital advertising. What the events are then used for is in our guides Attribution, experiments or mix models? and Paying for media across ad platforms.
Run the checklist on your own setup.
Send us the platforms you report conversions to, and we'll go through the list with you.