Server-side tagging: setup decisions and cost
The server-side tagging decision: which setup form, which cost items, and when not building it is the better call. No price figures.
By Roozbeh Nazari · CEO
Over the last two years server-side tagging has moved, for teams in Türkiye, from "should we build it" to "why have we still not built it". That shift has not made the decision any easier. Building it is not a software preference but an operational commitment: a permanently running server, someone to watch it, and a dependency that stops your measurement when it breaks. This piece sets out the items to look at when making the call.
We describe the measurement framework on our analytics and data strategy service page. How reporting is set up on multilingual sites we covered in our piece on locale-based funnel analysis in GA4; server-side tagging is that reporting’s counterpart at the data collection layer.
A warning first: this piece gives no price figures. Cloud provider pricing varies by region, by usage pattern and over time; a figure written today is wrong in six months. Instead it sets out the items that make up the cost, and how to work them out against your own traffic. You produce the figure yourself, from your provider’s current pricing page multiplied by your own traffic volume.
What server-side tagging actually changes
The classic arrangement sends requests from the browser straight to the measurement platforms. In a server-side arrangement the browser sends a request to a single address; the server at that address receives it, processes it, and distributes it to the relevant platforms itself. What changes is not where the data goes but who sends it.
That shift has three consequences. First, the number of scripts running in the browser drops and page weight goes down. Second, which data goes to which platform becomes controllable in one place. Third, and in practice the most decisive, cookie lifetime and data quality become less dependent on browser restrictions.
None of those three is an automatic gain. Built wrongly, page weight does not drop, control is not consolidated, and data quality falls. Server-side tagging is a measurement architecture choice; it works because it is built correctly, not because it is built.
Setup form: three routes, three different dependencies
There is more than one way to stand up a tagging server, and the choice should be made according to the team’s operational capacity.
- Automatic provisioning through a managed cloud service. The fastest route; scaling and patch management largely fall to the provider. In return you take on provider dependency and a usage-based cost line.
- Manual setup on your own infrastructure. Installed from a Docker image, giving full control. Scaling, monitoring and updates pass to you.
- Not building it at all. This is a real option and is often the right one on low-traffic, single-market sites. A server you do not run has zero operating cost.
One technical constraint to watch in the manual setup: the provisioned servers are recommended to have at most one virtual CPU. Additional vCPUs are not utilised and affect autoscaling negatively. So the "one more powerful machine" approach does not help here; you scale sideways, not upwards. Clustering is recommended for availability and performance.
The items that make up the cost
Reducing the total cost to a single server charge is the most common mistake in this decision. In reality there are at least five items, and three of them do not appear on the invoice:
- The cost of continuously running instances. The tagging server has to stay up even when there is no traffic; an arrangement that cold-starts on the first request loses data.
- Additional instances that scale with traffic. During campaign periods this item can be a multiple of the baseline; work it out against your busiest month, not the annual average.
- Network egress. Traffic leaving the server for the platforms is charged, and in multi-platform setups a single event turns into more than one egress.
- Domain and certificate management. The tagging server needs to run under the same domain as your site, which creates an ongoing maintenance item on the DNS and certificate side.
- Engineering time. The largest and most overlooked item. Setup is one-off; monitoring and incident response are continuous.
The practical method for filling these in is to take one month’s real event count and multiply each item by it. You can read the event count from your existing GA4 reports; there is no need to estimate. Any cost calculation made without knowing the monthly event count amounts to fitting the provider’s example scenario onto your own site, and it usually lands below the real figure.
The last item is what decides the call. If there is no alerting arrangement to notice when measurement stops and no person to respond, server-side tagging does not improve measurement; it adds a new single point at which measurement can quietly stop.
When not building it is right
The cases where not building it is right are concrete. On a single-language, single-market, low-volume site the gain is not worth the operational load. If the measurement arrangement is already inconsistent, changing the data collection layer does nothing but carry the inconsistency across; fix the event schema first. If there is nobody to take on the technical maintenance, the setup goes unmaintained after a while, and an unmaintained tagging server is riskier than none at all.
The case where building it is clearly right is a multi-market, high-volume setup with meaningful advertising investment. There the improvement in data quality feeds directly into budget decisions, and the operating cost is small next to the ad budget spent on faulty attribution.
The order of the decision is: fix the measurement schema first, then write down your volume and market count, then fill in the five cost items with your own numbers, and finally name who will take on maintenance. A "let us build it" decision taken before those four are written down is not a technical decision but a wish.
After setup: stopping measurement from failing silently
The most dangerous failure mode of a server-side arrangement is not the server going down entirely; a server that crashes is noticed immediately. The real risk is partial failure: the server is up, it answers requests, but distribution to one platform is erroring. What shows up in the reports is not an error message, just less data. Teams usually notice weeks later, when a campaign result comes in lower than expected.
So there are three checks that should count as part of the setup. First, monitoring the server’s health check endpoint from outside and alerting when it does not respond. Second, tracking daily event counts per platform; if one platform’s count falls while the others hold steady, the problem is in distribution, not on the site. Third, updating the server image regularly — a running version falls behind over time, and periodic restarts are recommended.
Putting those three checks in place takes less time than the setup itself, and it turns the server-side tagging decision into a reversible one. An unmonitored arrangement, by contrast, can spend the trust placed in measurement on a single silent failure; the time spent winning that trust back far exceeds the time saved on setup.