Server-side tracking: when the effort pays off

Server-side tracking sells nothing, it makes purchases visible

A server container does not bring in a single additional order. It ensures that purchases which happened anyway reach the ad account more often. The extra revenue in the report after the switch is therefore not a return. A return only arises if bidding buys better with the better signals, and that effect is considerably smaller than the figure in the report.

Be wary of offers that quote a percentage of additional conversions without a method and equate it with return on investment. I would assess the project differently: first calculate how much signal is even possible, then set that against the full costs.

The formula for additional signal

Additional signals = orders via Google × consent rate × share that is lost today despite consent.

The consent rate is in this formula because it sets the ceiling. Moving to the server does not make anyone measurable who has not given consent. The last factor covers ad blockers, script errors, drop-offs before the thank-you page and deleted cookies. Script errors can be fixed with a tag fix alone. I have not found a reliable figure for shops in the DACH region (Germany, Austria and Switzerland), so you have to determine it yourself.

Suppose a shop gets 2,000 orders a month via Google, 60% of buyers give consent, and 5% of those are lost despite consent. That adds 60 signals. All three values are chosen freely. At an order value of €80, that is €4,800 more visible revenue a month, not a single euro of which is new.

How to determine it: store the consent status and gclid with every order, and over a few weeks match which order numbers the GA4 purchase event or your own log actually shows. Reconciling with the shop system is due anyway.

What running and maintaining it costs

Hosting is the smallest item. For the tagging server on Cloud Run, Google estimates around 45 US dollars per instance per month and recommends at least two instances. On top of that, from around one million requests a month, logging costs may arise if default logging is not switched off. Managed hosting is the alternative: according to its own price list, Stape charges 20 US dollars a month for up to 500,000 requests and 100 US dollars for up to 5 million, without an annual discount. Prices as of November 2026; they vary by region and configuration.

The expensive part is time. The server needs updates, and because of security fixes Google advises at least one update per major version. Then there is what no price list shows: troubleshooting after shop updates, testing every new tag change twice, someone who understands the setup when it fails. The table assumes 2 to 6 maintenance hours a month at €100 and a setup of €2,000 to €5,000, spread over 24 months.

At what size it pays off

You have to set the costs against real additional orders, not visible ones. The formula: monthly costs divided by contribution margin per order before ad spend. The following worked example uses invented, round numbers: €25 contribution margin, 60% consent, 5% loss.

The first row settles the question for small shops. Six additional signals would have to generate twelve real orders, which does not add up. In the middle row, bidding has to improve revenue by a good one per cent on the same budget. I consider that possible but hardly provable: defensible, but a decision under uncertainty. Only in the last row does the risk of a bad investment become small.

My rule of thumb, a judgement without a study behind it: below 2% of ad spend, and with a proven gap, I would do it. Above that, only if there is a second reason. At an order value of €80 and an assumed ad spend share of 20%, the middle row has €32,000 of ad spend, and €600 is just under 2% of that. The first row is above 9%.

Without a new target ROAS the switch gets expensive

More visible conversions raise the reported ROAS, in the example by around 5% (60 additional orders on 1,140 previously measured, calculated without modelling). Nothing changes in the till. If the target ROAS stays where it is, the account looks more profitable than before, and the system spends more budget on the same sales. After the switch I would therefore derive the target again from margin and check it against revenue in the shop back end, not against the figure in the ad account.

Consent is still required on the server

The assumption that the banner is no longer needed on the server is wrong. Section 25 TDDDG makes storing information on a user's device and accessing it subject to consent, unless this is strictly necessary for a service the user has explicitly requested. The German Data Protection Conference reads the provision as technology-neutral, and the GDPR applies in addition to processing after the information has been read. My assessment of the legal situation in Germany, not legal advice: as long as the browser continues to supply cookies or identifiers, the detour via your own server changes nothing about this obligation.

Google does not treat the server setup as an exception either. Consent mode is still set up in the web container, and enhanced conversions only work when consent has been given. After the switch, also check a visit where the banner was declined: with ad_storage denied, the Google Ads tag neither writes nor reads cookies, and the browser sends the conversion pixel to a domain without third-party cookies. In basic mode, no Google tag loads at all. In the EEA, ad_user_data is required for enhanced conversions and tag-based conversion tracking.

In the example, 5 percentage points more consent, within what the law allows, bring around 95 additional measured orders, so more than the entire server project. I often consider the cookie banner the bigger and cheaper lever.

Test the cheaper stages first

If the gap is still unknown, I would set the order like this:

1. Basics and enhanced conversions: get the purchase tag, values and double counting right first, see the foundations of conversion tracking.
2. Google tag gateway: it serves Google tags through your own infrastructure, such as a CDN, load balancer or web server. Google cites an 11% uplift in signals for it. According to the footnote, however, what was measured was loads of the tag script, not purchases or revenue, globally and in April 2025. That is a vendor claim, not a forecast for your shop.
3. Full server container: only if a proven gap is still open after that.

Several channels share the costs

A container that serves several channels spreads its costs. If Meta's Conversions API also runs through it, calculate against total ad spend rather than Google alone. That lowers the hurdle, even if each channel brings some maintenance with it.

Longer purchase decisions can increase the share that is lost. Safari deletes cookies set via JavaScript after 7 days without interaction. Cookies set server-side in the HTTP response only escape this limit if the setup really belongs to your own domain. If Safari detects third-party CNAME or IP cloaking, it caps them at 7 days as well. A setup without your own domain and IP mapping can therefore miss the hoped-for advantage, and you should have that checked before you commission it.

Conversely, the calculation looks worse if nobody in-house understands the setup. Then you depend on a service provider for every tag change, and the maintenance assumption in the table is too low.