How Server-Side Tracking Works

The Data Flow

Understanding server-side tracking starts with understanding the data flow — the journey from a user clicking an ad to the conversion being reported back to the ad platform. Here is the step-by-step process:

1. User clicks an ad. The ad platform appends tracking parameters to the destination URL. Google Ads adds a gclid, Meta adds an fbclid, TikTok adds a ttclid. These click IDs are essential for attribution.
2. User lands on your website. Your tracking snippet captures the click ID from the URL and stores it in a first-party cookie on your domain. This cookie persists across sessions so the click ID is available when the user converts — even if it happens days later.
3. User performs an action. The user browses your site and eventually takes a valuable action: adds an item to their cart, submits a lead form, or completes a purchase. The tracking snippet captures this event along with relevant data (event type, value, currency, product details).
4. Event is sent to your server. The event data, including the stored click ID, is sent from the browser to your tracking server (or to your platform's endpoint, in the case of managed solutions like AllTrack).
5. Server forwards data to ad platforms. Your server (or the managed platform) sends the conversion data to each connected ad platform via their respective Conversion API. The click ID enables the platform to attribute the conversion back to the specific ad click that initiated the journey.
6. Ad platform records the conversion. The platform receives the server-side event, matches it to the original ad click using the click ID, and records the conversion. This data feeds into campaign reporting and algorithmic optimization.

First-Party Cookies and CNAME Setup

First-party cookies are central to server-side tracking because they enable you to persist click IDs and user identifiers across sessions. However, browsers are increasingly aggressive about limiting cookie lifespans.

Safari's Intelligent Tracking Prevention (ITP) caps JavaScript-set cookies at 7 days (and 24 hours for cookies set via URL decoration from known trackers). This means if a user clicks your ad on Monday and converts the following Tuesday, the click ID stored in a JavaScript cookie may have already expired.

How CNAME Configuration Extends Cookie Life

A CNAME (Canonical Name) DNS record allows you to point a subdomain of your website (such as track.yourdomain.com) to your tracking server. Because the tracking endpoint is on your own domain, cookies set by this endpoint are treated as true first-party cookies by the browser — exempt from many ITP restrictions.

When the tracking server sets a cookie via an HTTP response header (a "server-set" cookie) on your CNAME subdomain, that cookie can have a much longer expiration — typically 90 days to 1 year. This dramatically improves attribution accuracy for businesses with longer sales cycles.

Conversion APIs Explained

Each major ad platform provides its own server-side API for receiving conversion data. While the implementation details vary, the core concept is the same: your server sends an HTTP request containing event data to the platform's API endpoint.

Meta Conversions API (CAPI)

Meta's Conversions API accepts events such as Purchase, AddToCart, Lead, and others. Events are sent via POST requests to graph.facebook.com with your pixel ID and access token. Meta uses the fbclid or hashed user data (email, phone) for attribution. Meta strongly recommends using CAPI alongside their browser pixel for maximum match rates.

Google Enhanced Conversions

Google offers Enhanced Conversions as their server-side solution. It works by sending hashed first-party customer data (email address, phone number, name, address) alongside your conversion tag. This data supplements the gclid for better attribution, especially when cookies are unavailable. Google also supports the Measurement Protocol for GA4 events sent server-to-server.

TikTok Events API

TikTok's Events API functions similarly to Meta's CAPI. You send events to TikTok's servers with the ttclid or hashed user identifiers. TikTok supports standard e-commerce events and custom events, and provides a test event tool for debugging your integration before going live.

Event Deduplication

When you run both client-side pixels and server-side tracking simultaneously (which is recommended during a transition period), there is a risk of counting conversions twice. Event deduplication prevents this.

The mechanism is straightforward: you assign a unique event ID to each conversion. For a purchase, this could be the order ID. For a lead form submission, it could be a UUID generated at the time of submission. You include this event ID in both the client-side pixel event and the server-side API event.

When the ad platform receives two events with the same event ID, it recognizes them as duplicates and counts the conversion only once. If the client-side event is blocked by an ad blocker, only the server-side event arrives — and the conversion is still counted. This gives you the reliability of server-side tracking with a safety net for any edge cases.

Consent and Privacy

Server-side tracking does not bypass privacy regulations. GDPR, CCPA, ePrivacy, and other frameworks still require user consent before processing personal data for advertising purposes.

However, server-side tracking makes consent management more robust. Because all data flows through your server, you can implement consent checks at the server level:

• No consent: Do not forward any conversion data to ad platforms. The event is captured but not sent.
• Analytics consent only: Send anonymized, aggregated data without user identifiers.
• Full marketing consent: Send complete conversion data including click IDs and hashed user data.

This granularity is harder to achieve with client-side pixels, which often fire before a consent decision is made or continue to operate even after consent is withdrawn. Server-side tracking puts you in full programmatic control of what data leaves your infrastructure.

Implementation Options

There are three main approaches to implementing server-side tracking, each with different trade-offs.

1. Server-Side Google Tag Manager (sGTM)

The DIY approach. You deploy a server-side GTM container on Google Cloud (App Engine or Cloud Run), configure tags and triggers to forward events to each ad platform's API, and manage the infrastructure yourself. Maximum flexibility, but requires GTM expertise, cloud engineering skills, and ongoing maintenance.

2. Managed Platforms (AllTrack)

The plug-and-play approach. Platforms like AllTrack handle all infrastructure, API integrations, event mapping, deduplication, and CNAME configuration. You add a tracking snippet and connect your ad accounts. Ideal for teams without dedicated tracking engineers or those who want to move quickly. AllTrack specifically supports 9 ad platforms natively with a 5-minute setup.

3. Custom Code

The developer-first approach. You build server-side tracking directly into your backend application, making API calls to each ad platform from your own codebase. This gives you absolute control but requires significant development effort for each platform integration, and you are responsible for handling API authentication, rate limits, error handling, retries, and staying up to date with API changes.