Once a team has decided to use server-side tagging, the next problem is design. A tagging server adds a new place where data is received, changed and sent on. If nobody decides what each part is responsible for, the setup simply moves the old browser problems to a server that fewer people can inspect.
This article maps the data flow of a server-side Google Tag Manager setup, walks through one hypothetical purchase event, and ends with a checklist of design decisions and the conditions behind each one. Whether server-side tagging is worth it at all is a separate question and is not covered here.
Who is responsible for what
Each component should have one clear job. The table summarises the parts described in Google's server-side tagging overview and related pages.
| Component | Responsibility |
|---|---|
| Browser and web container | Collects the interaction, applies consent state, sends a request to the tagging server |
| Consent platform | Shows the banner and stores the choice. Consent mode does not provide a banner. |
