Video Hub / Server-Side Tagging in Google Tag Manager: Full Tutorial

Server-Side Tagging in Google Tag Manager: Full Tutorial

Please accept marketing cookies to view this video

Accept cookies

Frequently asked questions

Not with a managed provider. The setup is container creation, a DNS record and a configuration change on your existing web container, all done through interfaces rather than code. Self-hosting is where the technical requirement appears, since you then own scaling, monitoring and maintenance of the server itself.

Cost scales with request volume rather than being a flat fee, because the server processes every event. Self-hosting means paying cloud infrastructure directly and absorbing the maintenance time. Managed providers fold the infrastructure into a subscription, and free tiers exist for testing a setup before committing to either path.

Look for a gap between the conversions your ad platform reports and the sales your backend confirms. Add a check on your Safari and iOS traffic share, since those visitors are most affected by cookie restrictions. If the gap is measurable and your ad spend is meaningful, the case holds. If the gap is theoretical, fix other things first.

No, it sits behind it. Your client-side container still runs in the browser and still captures events. What changes is where it sends them: to your own server first, rather than directly to each platform. You are extending the stack rather than swapping one thing for another, which is a common misreading.

Because the whole benefit comes from data travelling to a domain you own. A CNAME record points something like insights.yourdomain.com at your tagging server, so requests look like your site communicating with itself rather than with a third-party analytics domain. Without that step there is no first-party route to use.

No. Consent has to be captured in the browser and the resulting signal has to travel with the event through to the server, where each tag respects it individually. A server-side setup that receives data before consent was given is no more compliant than a client-side one. The infrastructure changes, the obligation does not.

Reported conversions usually rise, since events that were being blocked start arriving. Treat that as recovery of data you were already earning rather than new performance, and set the first few weeks as a fresh baseline. Comparing directly across the switch date will overstate the improvement to anyone reading the report.

Forgetting to add the server container URL to the client-side Google tag. Everything else can be configured correctly and data will still travel straight to Google as before, with no error to indicate why. Publishing both containers is the other common omission, since an unpublished container silently breaks the chain.