Serverseitiges Tracking: wann der Aufwand sich rechnet

Serverseitiges Tracking verkauft nichts, es macht Käufe sichtbar

Ein Server-Container bringt keine einzige zusätzliche Bestellung. Er sorgt dafür, dass Käufe, die ohnehin stattgefunden haben, häufiger im Konto ankommen. Der Mehrumsatz im Bericht nach der Umstellung ist deshalb kein Ertrag. Ertrag entsteht erst, wenn die Gebotssteuerung mit den besseren Signalen besser einkauft, und dieser Effekt ist deutlich kleiner als die Zahl im Bericht.

Vorsicht bei Angeboten, die einen Prozentwert für zusätzliche Conversions ohne Methode nennen und ihn mit Rendite gleichsetzen. Ich würde das Projekt anders bewerten: zuerst ausrechnen, wie viel Signal überhaupt infrage kommt, dann gegen die vollen Kosten stellen.

Die Formel für das zusätzliche Signal

Zusätzliche Signale = Bestellungen über Google × Einwilligungsquote × Anteil, der trotz Einwilligung heute verloren geht.

Die Einwilligungsquote steht in dieser Formel, weil sie die Obergrenze setzt. Wer nicht eingewilligt hat, wird durch den Umzug auf den Server nicht messbar. Der letzte Faktor meint Adblocker, Skriptfehler, Abbrüche vor der Danke-Seite und gelöschte Cookies. Skriptfehler behebt schon ein Tag-Fix. Eine belastbare Zahl für DACH-Shops habe ich nicht gefunden, du musst ihn selbst bestimmen.

Angenommen, ein Shop macht 2.000 Bestellungen im Monat über Google, 60 Prozent der Käufer willigen ein, und von diesen gehen 5 Prozent trotz Einwilligung verloren. Dann kommen 60 Signale hinzu. Alle drei Werte sind frei gewählt. Bei 80 Euro Warenkorb sind das 4.800 Euro mehr sichtbarer Umsatz im Monat, von denen kein Euro neu ist.

So bestimmst du ihn: Speichere zu jeder Bestellung Consent-Status und gclid und gleiche über ein paar Wochen ab, welche Bestellnummern das GA4-Kaufevent oder ein eigenes Log tatsächlich zeigt. Das Abgleichen mit dem Shopsystem ist ohnehin fällig. Wer diese Lücke vor dem Projekt nicht beziffern kann, kann die Investition nicht bewerten.

Was Betrieb und Wartung kosten

Das Hosting ist der kleinste Posten. Google veranschlagt für den Tagging-Server auf Cloud Run rund 45 US-Dollar pro Instanz im Monat und empfiehlt mindestens zwei Instanzen. Dazu kommen ab etwa einer Million Anfragen im Monat mögliche Logging-Kosten, wenn das Standard-Logging nicht abgeschaltet wird. Managed Hosting ist die Alternative: Stape listet nach eigener Angabe 20 US-Dollar monatlich für bis zu 500.000 Anfragen und 100 US-Dollar für bis zu 5 Millionen, ohne Jahresrabatt. Preise Stand November 2026, sie schwanken nach Region und Konfiguration.

Teuer ist die Zeit. Der Server braucht Updates, Google rät wegen der Sicherheitsfixes zu mindestens einem Update je Hauptversion. Dazu kommt das, was in keiner Preisliste steht: Fehlersuche nach Shop-Updates, jede neue Tag-Änderung doppelt testen, jemand, der das Setup versteht, wenn es ausfällt. Die Tabelle nimmt dafür 2 bis 6 Wartungsstunden monatlich zu 100 Euro an und einen Aufbau von 2.000 bis 5.000 Euro, verteilt auf 24 Monate.

Ab welcher Größe es sich rechnet

Die Kosten musst du gegen echte Mehrbestellungen stellen, nicht gegen sichtbare. Die Formel: monatliche Kosten geteilt durch den Deckungsbeitrag je Bestellung vor Werbekosten. Das folgende Rechenbeispiel nutzt erfundene, runde Zahlen: 25 Euro Deckungsbeitrag, 60 Prozent Einwilligung, 5 Prozent Verlust.

Die erste Zeile erledigt die Frage für kleine Shops. Sechs zusätzliche Signale müssten zwölf echte Bestellungen erzeugen, das geht nicht auf. In der mittleren Zeile muss die Gebotssteuerung den Umsatz bei gleichem Budget um gut ein Prozent verbessern. Das halte ich für möglich, aber kaum für nachweisbar: vertretbar, doch eine Entscheidung unter Unsicherheit. Erst in der letzten Zeile wird das Risiko einer Fehlinvestition klein.

Meine Faustregel, eine Einschätzung ohne Studie: Unter 2 Prozent Kostenanteil an den Werbekosten und mit belegter Lücke würde ich es machen. Darüber nur, wenn ein zweiter Grund dazukommt. Bei 80 Euro Warenkorb und angenommenen 20 Prozent Werbekostenanteil hat die mittlere Zeile 32.000 Euro Werbekosten, 600 Euro sind knapp 2 Prozent davon. Die erste Zeile liegt bei über 9 Prozent.

Ohne neuen Ziel-ROAS wird die Umstellung teuer

Sichtbar mehr Conversions heben den ausgewiesenen ROAS, im Beispiel um rund 5 Prozent (60 zusätzliche auf 1.140 bisher gemessene Bestellungen, ohne Modellierung gerechnet). In der Kasse ändert das nichts. Bleibt der Ziel-ROAS stehen, wirkt das Konto rentabler als vorher, und das System gibt mehr Budget für dieselben Verkäufe aus. Ich würde das Ziel deshalb nach der Umstellung neu aus der Marge herleiten und gegen den Umsatz im Shop-Backend prüfen, nicht gegen die Zahl im Konto.

Die Einwilligung bleibt auch auf dem Server nötig

Die Annahme, auf dem Server entfalle der Banner, ist falsch. § 25 TDDDG knüpft das Speichern von Informationen im Endgerät und den Zugriff darauf an eine Einwilligung, es sei denn, das ist für einen vom Nutzer ausdrücklich gewünschten Dienst unbedingt erforderlich. Die Datenschutzkonferenz liest die Vorschrift als technikneutral, und für die Verarbeitung nach dem Auslesen gilt zusätzlich die DSGVO. Meine Einschätzung zur deutschen Rechtslage, keine Rechtsberatung: Solange der Browser weiter Cookies oder Kennungen liefert, ändert der Umweg über den eigenen Server an dieser Pflicht nichts.

Auch Google behandelt das Server-Setup nicht als Ausnahme. Consent Mode wird weiter im Web-Container eingerichtet, und Enhanced Conversions arbeiten nur bei erteilter Einwilligung. Im EWR ist ad_user_data für Enhanced Conversions und tagbasierte Conversion-Messung erforderlich.

Im Beispiel bringen 5 Prozentpunkte mehr Einwilligung, im rechtlich zulässigen Rahmen, rund 95 zusätzliche gemessene Bestellungen, also mehr als das ganze Server-Projekt. Ich halte den Cookie-Banner oft für den größeren und billigeren Hebel.

Erst die günstigeren Stufen testen

Ich würde die Reihenfolge so legen, wenn die Lücke noch unbekannt ist:

1. Grundlagen und Enhanced Conversions: Kauf-Tag, Werte und Doppelzählungen zuerst sauber, siehe das Fundament im Conversion-Tracking.
2. Google Tag Gateway: Es liefert Google-Tags über die eigene Infrastruktur aus, etwa CDN, Load Balancer oder Webserver. Google nennt dafür 11 Prozent mehr Signale. Gemessen wurden laut Fußnote aber Ladevorgänge des Tag-Skripts, nicht Käufe oder Umsatz, global und im April 2025. Das ist eine Herstelleraussage, keine Prognose für deinen Shop.
3. Voller Server-Container: erst, wenn danach noch eine belegte Lücke offen ist.

Wann die Rechnung anders ausfällt

Ein Container, der mehrere Kanäle bedient, verteilt seine Kosten. Läuft auch die Conversions API von Meta darüber, rechne gegen die Summe der Werbekosten statt nur gegen Google. Das senkt die Hürde, auch wenn jeder Kanal etwas Wartung mitbringt.

Längere Kaufentscheidungen können den Verlustanteil erhöhen. Safari löscht per JavaScript gesetzte Cookies nach 7 Tagen ohne Interaktion. Serverseitig gesetzte Cookies aus der HTTP-Antwort entgehen dieser Grenze nur, wenn das Setup wirklich zur eigenen Domain gehört. Erkennt Safari ein Third-Party-CNAME- oder IP-Cloaking, begrenzt es sie ebenfalls auf 7 Tage. Ein Setup ohne eigene Domain und IP-Zuordnung kann den erhofften Vorteil also verfehlen, das solltest du vor der Beauftragung prüfen lassen.

Umgekehrt fällt die Rechnung schlechter aus, wenn niemand im Haus das Setup versteht. Dann hängst du bei jeder Tag-Änderung an einem Dienstleister, und die Wartungsannahme aus der Tabelle ist zu niedrig.