Server Side Tracking as a glowing railway switch in the dark that directs incoming data streams onto its own tracks.

When Server-Side Tracking Is Really Worth It

For years, server-side tracking was considered the answer to the end of third-party cookies. That end has not materialized. What speaks in favor of the transition today, what it costs, and when it starts paying off.

Listen to the audio version

Server Side Tracking as a glowing railway switch in the dark that directs incoming data streams onto its own tracks.
Table of contents

Server Side Tracking shifts the measurement of user actions from the browser to a server that you operate yourselves. The transition pays off as soon as your measurement data supports real budget decisions. For websites with a handful of requests a month, the effort outweighs the benefits. In 2025, however, the rationale for the procedure has shifted, because Google is keeping third-party cookies in Chrome. What remains are measurement gaps that can be quantified.

What happens technically during server-side tracking

In the classic setup, the browser loads scripts from Google, Meta, or other providers and sends the measurement data directly to them. In the server-side setup, the data takes a detour via an intermediary station: the browser sends it to a server container under your own subdomain. This container then decides which information is forwarded to which provider. Google describes this process in its documentation as a way to instrument tags so that user activity is measured where it takes place.

Technically, much remains familiar. Server containers work with the same model of tags, triggers, and variables as the browser variant in Google Tag Manager. For the switch, Google mentions three effects: better page performance, finer privacy controls, and higher data quality. Performance improves because fewer third-party scripts are loaded and executed in the browser. The crucial difference lies in where the processing takes place and who controls the access. Your Conversion Tracking then runs through an instance that belongs to you.

Server-side tracking in comparison – on the left, measurement data directly to the providers; on the right, bundled via your own server.

The diagram shows both approaches side by side. On the left, the measurement data leave the website in many directions simultaneously, and some of the connections drop along the way. On the right, the same data first flow into a dedicated instance and proceed from there in an orderly manner.

Why the cookie argument no longer holds water

For years, the reason given for the redesign was: third-party cookies are disappearing from Chrome. On April 22, 2025, Google dashed that expectation and announced, to maintain the current approach to third-party cookies. Users still decide for themselves in the Chrome settings. On October 17, 2025, the second step followed: Google is discontinuing turn on a large portion of the Privacy Sandbox technologies, including Topics, Protected Audience, and the Attribution Reporting API. The company cites low adoption and feedback from the ecosystem as the reason.

The measurement gaps still exist, just somewhere else. Safari blocks after WebKit Tracking Prevention Policy all third-party cookies without exception and deletes cookies set via JavaScript after seven days without user interaction. Cookies from link decoration only last there for 24 hours, and storage such as LocalStorage or IndexedDB Safari clears after this deadline. Firefox works on a similar principle. Anyone who attracts many visitors via iPhones will lose part of the attribution between click and order, regardless of how Chrome behaves. Returning buyers with a longer decision-making process are the first to drop out of the statistics. This is precisely where server-side measurement comes in, because your own server can set cookies with a longer lifespan.

What the remodeling costs

The infrastructure is the predictable part of the bill. Google estimates for a server container on Cloud Run around 45 US dollars per month and server and recommends for production use at least two instances, to avoid data loss in the event of a failure. Each instance runs with one vCPU and 0.5 GB of memory; according to Google, two to ten servers process 35 to 350 requests per second. For the launch, this means about 90 US dollars a month. Google expressly recommends setting up a budget alert because costs increase with the number of instances.

In addition to hosting, there are other costs that are often missing from the initial quote:

  • A dedicated subdomain along with a DNS entry and a valid certificate
  • Setting up server containers, clients, and tags, as well as testing them
  • The integration with your consent tool
  • Continuous monitoring, because a silent failure distorts your figures unnoticed
  • Follow-up inspection after vendor updates when interfaces change

How you recognize the benefit

The math is simple: the redesign pays for itself if the recovered data is worth more than 90 US dollars in hosting plus setup and maintenance. For a shop generating five-figure monthly amounts via Google Ads or Meta, this threshold is reached quickly. You can see how much budget is being misallocated by looking at the gap between the orders in your backend and the reported conversions in your ad account. The same logic applies to the analysis in Google Analytics 4 (GA4). The legal aspect remains unaffected by this: Section 25 TDDDG is technologically neutral and requires consent as soon as information is stored on or retrieved from the user's device. Where the server is located makes no difference in this regard. For users in the European Economic Area, Google additionally sets the Consent Mode ahead, of the signals like ad_storage and analytics_storage evaluates.

These five points speak in favor of a switch:

  • You manage advertising budgets based on conversion data, such as in Meta Advantage+ or in Google Ads
  • A noticeable portion of your traffic comes via Safari, iPhone, or iPad
  • The gap between orders in the backend and conversions in the ad account has become measurable
  • You want to control which data leaves your house at all
  • There is someone on the team or in your agency who permanently maintains the system

If several of these points are missing, your money is better invested in clean data management and good content. How the Decline in organic clicks can be balanced, we have described elsewhere. If you want to overhaul the measurement of your campaigns anyway, we will support you in the Performance Marketing from conception to ongoing operation.

FAQs about Server Side Tracking

Does server-side tracking replace cookie consent?

No. Section 25 TDDDG is worded in a technology-neutral manner and applies regardless of whether the processing takes place in the browser or on a server. As soon as information is stored on or retrieved from the user's terminal equipment, you need consent. The exception only applies if the access is strictly necessary for the explicitly requested service.

How much does server-side tracking cost per month?

For the pure infrastructure, Google estimates about 45 US dollars per server per month on Cloud Run and recommends at least two instances, so about 90 US dollars. Added to this are one-time setup, connection to the consent tool, and ongoing monitoring. The total cost depends on how many requests your website generates.

Do I necessarily need Google Cloud for server-side tracking?

No. In its documentation, Google lists three ways: Cloud Run, App Engine, and a manual setup on your own infrastructure. Cloud Run is the documented standard way with the lowest setup effort. Anyone running their own servers can also run the container there.

Does server-side tracking help against ad blockers?

Partially. Because the measurement data goes to a subdomain of your own domain instead of known provider addresses, simple list-based blockers are less effective. Blockers that react to behavioral patterns still detect the path, however. You will not achieve complete data collection with this method.

Will my existing tags be kept when switching?

Mostly yes. Server containers use the same model of tags, triggers, and variables as the browser variant, so the logic remains transferable. However, each tag must be individually checked and re-wired because the data now flows through the server container. Plan for the test with the same care as for the setup.