---
title: 'Server-side tagging: browser vs server tracking | Plainrouter'
description: 'Compare browser and server-side tracking, follow a purchase event, and choose between server-side GTM, a direct API, and a managed integration.'
last_updated: 2026-09-12
---

# Server-side tagging

Server-side tagging processes measurement events on a server before forwarding them to a destination. Browser-side tagging runs measurement code in the visitor's browser. The two can work together: a browser can collect an interaction and send it to a server for processing.

Server-side tracking is the broader collection and delivery approach. Server-side tagging usually refers to running configurable tags in a server container. A backend sending a purchase directly to an advertising API is server-side tracking without necessarily using a tag manager.

## Browser vs server-side tracking

| Browser-side | Server-side |
| --- | --- |
| Code runs in the visitor's browser. | Processing runs on your backend or a hosted service. |
| Observes page views, clicks, and other browser interactions. | Receives browser events or events from backend systems. |
| Sends data from the browser to the configured endpoint. | Validates, transforms, and forwards the data it receives. |
| Depends on the page loading and measurement code running. | Backend events can originate independently; browser-sourced events still depend on browser collection. |

In server-side Google Tag Manager, incoming requests become events that the container's tags process. Moving that processing does not automatically remove browser collection. [Google's server-side tagging introduction](https://developers.google.com/tag-platform/tag-manager/server-side/intro).

## Follow one purchase through both paths

Consider a checkout that records a confirmed purchase with the event ID `purchase_123`:

1. **Browser path:** the confirmation page sends a permitted purchase event through the browser integration.
2. **Server path:** the backend sends the confirmed purchase through a direct API, server container, or managed integration.
3. **Destination:** when both paths describe the same purchase, the integration follows the destination's deduplication rules to avoid counting it twice.

For Meta, the browser `eventID` and server `event_id` must identify the same event, and the event names must match. Reuse that identity when retrying the same purchase; a new ID would describe a different event. See the [Meta deduplication guide](/library/meta-event-id-deduplication) for examples and verification.

A backend confirmation can exist even if the visitor closes the confirmation page. A server that only forwards browser requests cannot recreate an event it never received.

## Choose an implementation

- **Server-side GTM:** consider a container when you need configurable tags and routing across several destinations. Your team or hosting provider operates the container; you still maintain its configuration.
- **Direct API:** consider sending events from your backend when you need control over the integration and can maintain event mapping, credentials, retries, and delivery monitoring.
- **Managed integration:** consider a service when its supported destinations and event model fit your requirements. Check what it operates and what your application must supply. Plainrouter's [Signals](/product/signals) is a Meta-focused option.

Use the [implementation comparison](/compare) to compare ownership and maintenance. For a Meta setup without a server container, start with [CAPI without GTM](/library/meta-capi-without-gtm).

## Is it the same as a conversions API?

No. Server-side tagging is a processing architecture. A conversions API is an interface a destination exposes for receiving events. A server-side system may use that interface.

## Does it automatically prevent duplicate purchases?

No. When browser and server paths describe the same event, the integration needs consistent event identity and the destination's deduplication rules.

## Does it make every event usable for advertising?

No. Moving processing to a server does not establish permission to send the event or make its source data accurate. Consent choices must reach the relevant processing and destination steps. See [Google's server-side consent implementation](https://developers.google.com/tag-platform/tag-manager/server-side/consent-mode) and our [server-side consent guide](/library/server-side-consent).

For Google Ads website conversions, follow the [server-side GTM setup and verification guide](/library/google-ads-server-side-tracking).

## Related reading

- [TikTok Pixel Helper: browser event troubleshooting](/library/tiktok-pixel-helper)

- [Compare server-side tracking providers](/library/server-side-tracking-tools)
- [Meta Conversions API: how it works](/library/meta-conversions-api)
- [Troubleshoot missing or duplicate events](/library/meta-capi-missing-duplicate-events)
- [All definitions](/definitions)