> Site index: https://usehardal.com/llms.txt
> Every content route also serves markdown at <url>.md

# What Is Server-Side Tracking? How It Works, Pros and Cons

Server-side tracking sends events through a server you control before they reach GA4, Meta or TikTok. How it works, what it fixes, what it does not, and how to set it up.

Source: https://usehardal.com/server-side-tracking
Published: 2026-09-26
Updated: 2026-09-26
Author: Berkay Demirbas
Category: Server-Side Tracking

---

> **Quick answer:** Server-side tracking sends website and app events to a server you control first, then forwards them to analytics and ad platforms such as GA4, Meta, and TikTok. The browser talks to one first-party endpoint instead of loading a script for every vendor, and you decide what each destination receives. Consent still applies.

## How server-side tracking works

With client-side tracking, every vendor ships its own script. Each script runs in the visitor's browser and sends data straight to the vendor's domain:

```text
Browser -> Google Analytics
Browser -> Meta Pixel
Browser -> TikTok Pixel
```

With server-side tracking, events go to an endpoint on your own domain, such as `metrics.example.com`. A server behind that endpoint processes each event and forwards it to every destination through that platform's server API:

```text
Browser or app -> metrics.example.com -> your server -> GA4, Meta CAPI, TikTok Events API, warehouse
```

On the way, the server can validate an event, drop fields a vendor should not see, hash email addresses and phone numbers, check the visitor's consent state, and decide which destinations receive a copy.

Events reach the server in two ways:

- **Browser-originated events** are created on the page, then routed through the server instead of going straight to vendors. Server-side tagging with a Google Tag Manager server container works this way.
- **Server-originated events** start in your backend, such as a completed order, a refund, or a CRM stage change. The backend calls the vendor's API directly. This is [server-to-server tracking](https://usehardal.com/glossary/server-to-server).

Most production setups use both.

## Client-side vs server-side tracking

| | Client-side tracking | Server-side tracking |
|---|---|---|
| Where events go first | Each vendor's domain | Your first-party endpoint |
| Scripts on the page | One per vendor | Usually one collection script, none for backend events |
| Ad blockers and privacy lists | Often block vendor domains such as `google-analytics.com` | A first-party endpoint is blocked less often |
| Cookie lifetime in Safari | Cookies set with `document.cookie` are capped at seven days | Server-set first-party cookies follow standard HTTP cookie rules |
| What each vendor receives | Whatever its script collects | Only the fields you forward |
| Setup | Paste a tag | Run a server, map a domain, configure destinations |
| Running cost | None beyond the tools | Hosting, or a managed service |

## What server-side tracking fixes

### Fewer events lost to blockers

Ad blockers and browser privacy features work from lists such as EasyList and EasyPrivacy. Those lists match known vendor domains and script paths. A request to your own subdomain usually does not match, so more consented events arrive. Lists can still catch well-known paths, such as a default `gtm.js` filename, so the endpoint and script paths matter too. For the current state of blockers in Chrome, see [uBlock Origin and Manifest V3](https://usehardal.com/adblockers-versus-chrome).

### Longer-lived first-party identifiers

Safari's Intelligent Tracking Prevention caps cookies created with `document.cookie` at seven days. A cookie your server sets in an HTTP response on your own domain follows standard cookie rules instead, so a returning visitor keeps the same anonymous ID for longer.

Safari still caps server-set cookies at seven days when the endpoint is third-party infrastructure behind a CNAME or a mismatched IP address. The details are in the [Safari ITP guide](https://usehardal.com/safari-itp-guide).

### Better match quality for conversion APIs

Meta Conversions API, TikTok Events API, and Google Ads enhanced conversions all accept hashed customer data and click identifiers alongside each conversion. A server can attach hashed email, phone, and the `fbc`, `ttclid`, or `gclid` values to every event it forwards, which helps ad platforms attribute the conversion to the right click.

Backend events also cover conversions the browser never reported, such as a purchase where the visitor closed the tab before the confirmation page loaded. Setup guides: [Meta Conversions API Gateway](https://usehardal.com/meta-conversions-api-gateway-setup) and [a first-party domain for TikTok Events API](https://usehardal.com/how-to-set-up-first-party-domain-for-tiktok-eapi).

### Control over what leaves your infrastructure

Client-side scripts send whatever they are built to collect, including IP addresses and full page URLs that can carry personal data in query parameters. A server lets you strip, hash, or truncate those fields before any vendor sees them. It also lets you choose where the data is processed, which matters for data residency rules under GDPR, KVKK, and similar regimes.

### Lighter pages

Every vendor script adds download, parse, and execution time. Replacing several of them with one collection script reduces the work the browser does on each page load. See [how server-side tracking affects page speed](https://usehardal.com/benefits-of-server-side-improved-website-page-speed-to-more-conversions).

## What server-side tracking does not fix

- **Consent.** Moving collection to a server does not change the legal basis for processing. If a visitor declines, the server should not forward identifiable events. A server does make enforcement consistent, because one server applies the same consent rule to every destination.
- **Poor event design.** Missing parameters, wrong event names, and double-firing triggers travel through a server unchanged.
- **Every discrepancy.** Server-side tracking narrows the gap between ad platforms, analytics, and your backend. It does not close it. See [data discrepancy](https://usehardal.com/glossary/data-discrepancy).
- **Duplicates.** If the browser and the server both send the same purchase, platforms count it twice unless both copies share an event ID. See [event deduplication](https://usehardal.com/glossary/event-deduplication).

## Types of server-side tracking setups

| Setup | How it works | Good fit | Trade-off |
|---|---|---|---|
| Server-side tagging (sGTM) | Browser tags send to a Google Tag Manager server container on your domain, which forwards to vendors | Teams already running GTM | You host, pay for, and maintain the container and every vendor tag in it |
| Conversion API gateways | A single-vendor server, such as Meta's Conversions API Gateway | One ad platform | One gateway per destination |
| Server-to-server from the backend | Your backend calls APIs such as the GA4 Measurement Protocol or Meta Conversions API | Orders, refunds, offline conversions | Engineering time, and events need identifiers from the browser session |
| Managed first-party platform | One hosted collection endpoint for web and apps that routes to many destinations | Teams that want the outcome without running infrastructure | Subscription cost |

For a side-by-side of vendors, see [the best server-side tracking tools](https://usehardal.com/best-server-side-tracking-tools).

## How much does server-side tracking cost?

A self-hosted server-side GTM container runs on a cloud service such as Google Cloud Run. The bill grows with request volume, and someone has to monitor, scale, and update the container. Read [how to keep server-side tagging costs down](https://usehardal.com/optimizing-server-side-tagging-costs).

Managed sGTM hosting replaces the cloud bill with a monthly fee but still leaves you maintaining the tags. A full platform also covers the destinations, the reporting, and the upkeep. Hardal plans start at $249 per month for 5M events. See [pricing](https://usehardal.com/pricing).

## How to set up server-side tracking

1. **List the events that matter.** Purchases, leads, and sign-ups first. Note which destination needs each one and which parameters it requires.
2. **Choose the collection endpoint.** Use a subdomain of your site, such as `metrics.example.com`, served from infrastructure you control so browsers treat it as first-party.
3. **Choose where the server runs.** Pick a region close to your visitors for latency, or inside a specific country if residency rules require it.
4. **Connect destinations.** Route events to GA4 ([GA4 server-side tracking guide](https://usehardal.com/ga4-server-side-tracking)), Meta Conversions API, TikTok Events API, Google Ads, and your warehouse.
5. **Pass consent to the server.** Send the choice your consent management platform records with every event, and have the server enforce it for each destination.
6. **Run both setups in parallel.** Keep your current tags, send the server-side copy to separate properties, and compare. The [GA4 dual-tagging guide](https://usehardal.com/server-side-parallel-measurement) walks through the comparison.
7. **Cut over.** Remove the direct browser path once every required event arrives and the remaining differences are explained.

## Run server-side tracking with Hardal

Send web and mobile events to one first-party endpoint. Hardal applies your governance rules, forwards approved data to unlimited destinations, and gives you analytics on every plan. You manage the data rules, not the routing infrastructure.

Choose managed hosting in the US, UK, EU, EMEA, or Asia on Azure, AWS, or Huawei Cloud. If your policies require it, self-host Hardal instead.

You do not need to remove Google Tag Manager or GA4 to start. Run Hardal beside your current setup, compare the numbers, and switch when the data checks out. [Explore managed server-side hosting](https://usehardal.com/server-side-hosting) or [book a demo with the team](https://usehardal.com/contact/demo).