What server-side tagging does not fix
Moving tags to a server solves three real problems and quietly creates two new ones. A short inventory before you migrate.
Sample article. The text is placeholder content written to show how the page renders.
Server-side tagging is usually sold as a fix for data loss. It is a fix for some data loss, and an entirely new surface for a different kind.
What it genuinely improves
- Page weight. Vendor scripts stop competing with your content for the main thread.
- First-party context. Cookies set from your own domain survive browser restrictions that third-party cookies do not.
- Control of the payload. You decide what leaves your infrastructure.
What it does not touch
Consent is still consent. If a visitor declines, moving the tag to a server does not create permission — it only moves where the decision is enforced. Teams discover this during an audit, not before.
Attribution does not improve either. The server sees what the browser told it. A missing click identifier stays missing.
The two new problems
A silent failure surface. A client-side tag that breaks shows up in the browser console. A server container that drops requests shows up nowhere until someone reconciles totals.
// The shape of the problem: nothing here throws.
const response = await fetch(endpoint, { method: 'POST', body });
// no status check, no retry accounting, no logCost that scales with traffic. Client-side tagging is paid for by the visitor’s device. Server-side tagging is paid for by you, per request.
Before you migrate
Write down the number you expect to change and by how much. If you cannot state it in advance, you will not be able to tell success from a broken container afterwards.