What is server-side tracking?
Server-side tracking means your website's server reports an event, such as a completed order, directly to tools like Google Analytics or Meta. Browser tracking relies on a script running in the visitor's browser to do the same job.
Most sites use both. The browser tracks the journey: page views, product views and add-to-carts. The server confirms the events that matter most, such as purchases and qualified leads, because the server knows for certain that they happened.
Why does browser tracking miss conversions?
Browser scripts can be blocked, cut short or confused before they fire. Every missed event makes your reports less accurate and gives ad platforms less to learn from.
- Ad blockers and privacy tools stop common tracking scripts from loading.
- Browser privacy features limit how long cookies last and strip some tracking parameters from links.
- Third-party checkouts and payment redirects send shoppers to another domain, and the thank-you page may never load or may lose the original source.
- Slow pages and closed tabs mean the script never finishes.
We have fixed exactly this problem for a direct-to-consumer store where a third-party checkout broke purchase attribution. Server-side purchase events closed most of the gap.
How does the GA4 Measurement Protocol work?
The GA4 Measurement Protocol is Google's way of accepting events sent from a server. Your server sends a small message to Google with the event name, its details and an identifier that links it to the visitor.
The key pieces are:
- Measurement ID and API secret from your GA4 data stream, which authorize the request
- client_id, read from the visitor's GA cookie and stored with the order, so the server event joins the same visitor's session
- Event name and parameters, such as purchase with transaction_id, value, currency and items
- Consent fields, which pass along the visitor's choices for ad data use
Google designed the Measurement Protocol to add to browser tracking. The common pattern is to pick one source for each event. For example, send page views from the browser and send purchase only from the server, always with a transaction_id so any duplicates are easy to spot. Our marketing analytics team sets this up alongside Google Tag Manager.
How does the Meta Conversions API work?
The Meta Conversions API lets your server send events to Meta, alongside or instead of the Meta Pixel in the browser. Meta uses the events for reporting and to find people likely to convert.
Each server event includes the event name, the time it happened, where it happened (such as website) and customer information that helps Meta match it to a person. Contact details like email and phone are normalized and hashed with SHA-256 before they are sent. Browser details such as the Meta click ID and browser ID cookies, IP address and user agent also improve matching.
Hashing is a technical safeguard. Hashed emails are still personal data under most privacy laws, so treat them that way.
How does deduplication with event IDs work?
When the browser and the server both report the same purchase, the platform needs a way to know it is one order. The answer is a shared event ID.
For Meta, you generate one unique ID for each event, often based on the order number. The Pixel sends it as eventID and the Conversions API sends it as event_id. When Meta receives two events with the same event name and the same ID within its deduplication window, it keeps one. If the IDs don't match, or one side is missing, you count the order twice and your reported results look better than reality.
| Platform | Server method | How to avoid double counting |
|---|---|---|
| Meta | Conversions API | Same event name and event ID from Pixel and server |
| GA4 | Measurement Protocol | Send each event from one source, with a transaction_id on purchases |
After launch, check Meta's Events Manager for deduplication status and compare GA4 purchase counts against real store orders for a week. The numbers should be close.
How should consent be handled?
Server-side tracking must follow the same consent rules as browser tracking. Moving an event to the server does not remove the need for permission where the law or platform requires it.
- Record each visitor's consent choice and store it with the order or lead.
- Only send server events, or only send personal details, when that consent allows it.
- For Google, use Consent Mode in the browser and pass consent fields with Measurement Protocol events.
- Describe the practice clearly in your privacy notice, including which platforms receive data.
- Honor opt-out requests, including browser signals such as Global Privacy Control where state law requires it.
Rules vary by state and country, so have a legal advisor review your setup.
Do you need a server-side container?
Not always. There are two common approaches, and either can work.
A server-side Tag Manager container runs on cloud hosting and forwards events to many platforms from one place. It suits sites with heavy traffic or many tools. A direct integration sends events from your store or CRM straight to each platform's API. It suits smaller sites with a few key events. We choose based on traffic, tools and who will maintain it, and our data engineering team builds either.
Clean purchase data also makes profit reporting possible. See ROAS is not profit for what to do with it, and marketing attribution for the cross-channel view.