Projektkalkulation
Aus einer frühen Schätzung muss ein belastbares Angebot werden
Ein Kunde möchte sein bestehendes Tracking auf Server-Side Tagging umstellen – und erwartet früh eine belastbare Aufwandsschätzung. Doch nicht die Zahl der Tags entscheidet über den Projektumfang, sondern die unbekannten Abhängigkeiten zwischen Datenmodell, Consent, Plattformen, Tests und beteiligten Teams.
Genau hier liegt das Kalkulationsrisiko für Agenturen und Freelancer: Ein scheinbar überschaubares Setup kann erst während Audit, Migration oder Abnahme seine tatsächliche Komplexität zeigen. Dieser Artikel zeigt, wie Du den vollständigen Lebenszyklus der Umstellung in kalkulierbare Arbeitspakete zerlegst, Unsicherheit im Angebot sichtbar machst und Implementierung, Projektmanagement sowie laufenden Betrieb sauber voneinander abgrenzt.
Projektumfang
Kein SST-Projekt gleicht dem anderen
Eine der größten Herausforderungen bei der Kalkulation ist die Heterogenität bestehender Tracking-Setups.
Überschaubare Installation
Auf der einen Seite gibt es vergleichsweise überschaubare Installationen: einen Web-Container, Google Analytics 4, einige Google-Ads-Conversions und eine saubere Data Layer.
Gewachsenes Setup
Auf der anderen Seite stehen über Jahre gewachsene Container mit zahlreichen Tags, individuellen JavaScript-Lösungen, verschiedenen Marketingplattformen, unterschiedlichen Consent-Abhängigkeiten und mehreren beteiligten Dienstleistern oder Fachabteilungen.
Beide Projekte heißen am Ende möglicherweise einfach „Umstellung auf Server-Side Tagging“. Der tatsächliche Aufwand kann sich jedoch erheblich unterscheiden. Die Anzahl der vorhandenen Tags ist dabei nur ein Indikator. Häufig entscheidender ist, wie unterschiedlich die Tags aufgebaut sind und ob sie von bestimmten Daten, Triggern, Consent-Einstellungen oder anderen Tags abhängig sind.
Ein Container mit 30 sehr ähnlichen Google-Ads-Tags kann einfacher zu migrieren sein als ein Container mit zehn unterschiedlichen Tags mit jeweils eigenen technischen und organisatorischen Abhängigkeiten. Deshalb beginnt eine belastbare Kalkulation nicht mit der Umsetzung, sondern mit der Bestandsaufnahme.
Audit
Die Bestandsaufnahme ist ein eigenes Arbeitspaket
Vor der Migration sollte zunächst geklärt werden, was überhaupt vorhanden ist. Dazu gehören unter anderem:
- Welche Web-Container und Properties sind betroffen?
- Welche Tracking- und Marketinganbieter werden verwendet?
- Welche Daten werden aktuell an welche Drittanbieter übertragen?
- Welche Tags basieren auf Templates, welche auf Custom HTML oder individuellen Skripten?
- Welche Daten kommen von der Data Layer?
- Welche Consent-Abhängigkeiten bestehen?
- Welche Tags sollen tatsächlich auf Server-Side Tagging umgestellt werden?
- Welche Tags bleiben bewusst clientseitig?
Gerade bei älteren oder über Jahre gewachsenen Containern ist die Dokumentation häufig nicht vollständig oder nicht mehr aktuell. Dann besteht ein Teil des Projekts zunächst darin, den tatsächlichen Ist-Zustand zu erfassen. Dieser Aufwand sollte nicht als kostenloses Vorprojekt behandelt werden: Eine saubere Bestandsaufnahme ist bereits ein fachliches Arbeitspaket und bildet die Grundlage für alle weiteren Entscheidungen.
Für größere oder unbekannte Setups kann es deshalb sinnvoll sein, Audit und Umsetzung als getrennte Projektphasen zu planen. Erst nach dem Audit lässt sich der eigentliche Migrationsaufwand deutlich belastbarer einschätzen.
Konzeption & Umsetzung
Die technische Migration ist nur ein Teil des Projekts
Ist der bestehende Aufbau bekannt, beginnt die eigentliche Konzeption. Dabei muss entschieden werden, welche Daten künftig über den Server-Container laufen sollen, welche Anpassungen im Web-Container notwendig sind und wie der neue Datenfluss aussehen soll. Typische Aufgaben können beispielsweise sein:
- Server-Container einrichten
- Tagging-Domain konfigurieren
- DNS-Einträge einrichten oder koordinieren
- Web-Container anpassen
- GA4 über den Server-Container routen
- Google-Ads-Tracking umstellen
- weitere Drittanbieter integrieren
- Clients, Tags, Trigger und Variablen im Server-Container konfigurieren
- Consent-Signale korrekt weitergeben
- zusätzliche Funktionen oder Plugins integrieren
Je nach Setup kommen weitere Sonderfälle hinzu. Das Problem bei der Kalkulation: Die technische Umsetzung ist häufig der sichtbarste Teil des Projekts, aber nicht zwingend der aufwendigste. Insbesondere bei größeren Organisationen können Testing und Abstimmung ähnlich viel oder sogar mehr Zeit beanspruchen als die eigentliche Implementierung.
Qualitätssicherung
Testing sollte von Anfang an eingeplant werden
Ein SST-Projekt ist nicht abgeschlossen, sobald Requests im Server-Container ankommen. Entscheidend ist, ob der gesamte Datenfluss weiterhin korrekt funktioniert. Das Testing sollte deshalb mehrere Ebenen umfassen. Zunächst muss technisch geprüft werden, ob Requests korrekt vom Browser an die Tagging-Domain und anschließend an die jeweiligen Zielsysteme übertragen werden.
1
Browser
Die vorgesehenen Events und Consent-Signale werden ausgelöst.
2
Tagging-Domain
Requests erreichen den vorgesehenen Endpunkt.
3
Server-Container
Der richtige Client verarbeitet die Requests und löst die vorgesehenen Tags aus.
4
Zielsystem
Die Plattform nimmt Requests, Events und Parameter wie erwartet an.
Darüber hinaus sollte geprüft werden:
- Werden Events korrekt ausgelöst?
- Stimmen Event-Namen und -Parameter?
- Ist die Consent-Implementierung korrekt?
- Werden Daten doppelt gesendet?
- Fehlen Events oder Parameter?
- Werden Conversion-IDs und andere wichtige Parameter korrekt übergeben?
- Werden Requests von den jeweiligen Plattformen akzeptiert?
Bei kritischen Integrationen reicht es häufig nicht aus, ausschließlich im Google Tag Manager Preview Mode zu prüfen, ob Tags ausgelöst werden und Requests den Server-Container erreichen. Zusätzlich sollte kontrolliert werden, ob die Requests die erwarteten Parameter und Consent-Signale enthalten, im Server-Container vom richtigen Client verarbeitet werden und anschließend korrekt an die jeweiligen Zielplattformen weitergeleitet werden. Auch die Daten in den Zielplattformen selbst müssen überprüft werden. Dieser Schritt wird in Projektkalkulationen leicht unterschätzt.
Abstimmung & Freigabe
Je mehr Stakeholder beteiligt sind, desto länger wird die Abnahme
Eine Tracking-Infrastruktur wird selten nur von einer einzigen Person betreut. Google Analytics wird möglicherweise vom Analytics-Team betreut, Google Ads liegt beim SEA-Team oder einer externen Agentur, Affiliate-Tracking verantwortet ein weiterer Dienstleister und Paid Social wiederum ein anderes Team. Eine technische Migration kann deshalb bereits abgeschlossen sein, während die fachliche Abnahme noch läuft. Idealerweise bestätigen die jeweiligen Stakeholder, dass ihre Integrationen auch nach der Umstellung weiterhin wie erwartet funktionieren. Dadurch entsteht ein organisatorischer Aufwand, der sich nur begrenzt technisch beschleunigen lässt.
Für die Kalkulation bedeutet das: Projektmanagement und Abstimmung sollten als eigenständige Bestandteile des Projekts eingeplant werden. Bei mehreren beteiligten Parteien sollte dafür ein eigenes Budget vorgesehen werden.
Ebenso wichtig ist eine klare Definition der Verantwortlichkeiten. Wer testet welche Plattform? Wer gibt sie frei? Und was passiert, wenn ein externer Stakeholder mehrere Tage nicht reagiert? Solche Fragen haben direkten Einfluss auf Projektlaufzeit und Aufwand.
Migrationsstrategie
Umstellung im laufenden Betrieb oder Parallelbetrieb?
Eine weitere wichtige Entscheidung betrifft die Art der Umstellung.
Direkte Umstellung
Grundsätzlich kann ein bestehendes Setup direkt auf Server-Side Tagging umgestellt werden. Das ist technisch häufig sogar der einfachere Weg. Allerdings verändert sich dadurch die bestehende Datenbasis unmittelbar. Wenn nach der Umstellung Veränderungen auftreten, ist nicht immer sofort klar, ob diese tatsächlich durch die Einführung von Server-Side Tagging verursacht wurden oder ob es sich um normale Schwankungen handelt.
Parallelbetrieb
Eine Alternative ist ein Parallelbetrieb. Dabei laufen altes und neues Setup für einen definierten Zeitraum nebeneinander. Der Vorteil liegt auf der Hand: Die Ergebnisse lassen sich besser vergleichen. Der Nachteil ist aber: Eine saubere Parallelinstallation kann technisch deutlich komplexer werden.
Doppelte Events müssen vermieden werden, Cookies oder Identifier können miteinander interagieren, Consent-Abhängigkeiten müssen berücksichtigt werden und auch andere Seiteneffekte, zum Beispiel durch eine geteilte Data Layer sind möglich.
Ein Parallelbetrieb sollte deshalb nicht automatisch eingeplant werden. Er ist vielmehr eine bewusste Projektentscheidung, die zusätzliche Konzeption, Implementierung und Testing erfordern kann.
Nachbeobachtung
Der Erfolg einer SST-Umstellung lässt sich nicht immer sofort beurteilen
Nach dem Go-live beginnt die nächste schwierige Phase: die Bewertung. Technisch lässt sich meist relativ schnell feststellen, ob Requests korrekt verarbeitet werden. Schwieriger ist die Frage, ob sich auch die Datenqualität verbessert hat. Bestimmte Effekte von Server-Side Tagging können sich unmittelbar zeigen, andere brauchen Zeit. Das gilt beispielsweise dann, wenn längere Cookie-Speicherzeiten oder stabilere Identifier langfristig dazu beitragen sollen, Nutzer oder Conversions besser zuzuordnen.
Hinzu kommen normale Schwankungen durch:
- Saisonalität
- Kampagnen
- veränderte Media-Budgets
- Consent-Raten
- Website-Traffic
- Conversion Rates
- Änderungen an der Website
- Änderungen der Plattformen selbst
Wer nach wenigen Tagen lediglich zwei Zahlen miteinander vergleicht, kann deshalb schnell falsche Schlüsse ziehen. Gerade wenn kein echter Parallelbetrieb existiert, ist es schwierig, Veränderungen eindeutig der SST-Migration zuzuschreiben. Eine sinnvolle Projektplanung sollte daher auch eine Nachbeobachtungsphase vorsehen.
Laufender Betrieb
Auch ein SST-Stack ist nicht wartungsfrei
Mit Server-Side Tagging kommt eine zusätzliche technische Ebene in das bestehende Tracking-System. Das bringt Vorteile, erhöht aber auch die Gesamtkomplexität. Nach dem Projekt sollte deshalb geklärt sein, wer das neue System dauerhaft betreut, beispielsweise:
- Wer überwacht, ob der Tagging-Server erreichbar ist?
- Wer erkennt Fehler bei der Datenübertragung?
- Wer reagiert auf Änderungen der eingesetzten Plattformen?
- Wer pflegt Web- und Server-Container?
- Wer überprüft nach Änderungen am Web-Container, ob der serverseitige Datenfluss weiterhin funktioniert?
- Gibt es regelmäßige technische Überprüfungen?
Hieraus kann ein eigenes Leistungsmodell entstehen. Eine Agentur kann beispielsweise nach Projektabschluss regelmäßige Checks anbieten oder einen laufenden Tracking-Retainer vereinbaren. Wichtig ist lediglich, diese Phase nicht stillschweigend als Teil des ursprünglichen Projekts zu betrachten.
Infrastruktur
Auch das Hosting gehört zur Projektentscheidung
Neben Implementierung und Betrieb stellt sich die Frage, wer die technische Infrastruktur für den Server-Container bereitstellt und betreibt.
Eigene Infrastruktur
Agenturen können diese Infrastruktur selbst aufbauen und verwalten. Dann müssen allerdings auch Themen wie Betrieb, Skalierung, Wartung und laufende Infrastrukturkosten in das eigene Angebot einfließen.
Infrastrukturbetrieb auslagern
Eine Alternative besteht darin, diesen Teil bewusst aus dem Projekt herauszulösen. ProxyRiders richtet sich genau an Fachleute und Organisationen, die Google Tag Manager Server-Side Tagging einsetzen möchten, ohne dafür eine eigene Server-Infrastruktur betreiben zu müssen.
Für Agenturen und Freelancer kann das die Kalkulation vereinfachen: Sie konzentrieren sich auf Konzeption, Tracking-Implementierung und Datenqualität, während Hosting und technischer Serverbetrieb als standardisierter Bestandteil behandelt werden.
Kalkulationsmodell
Ein Modell für die Projektkalkulation
Gesamtaufwand =
Analyse + Konzeption + Implementierung + Testing + Abstimmung + Release + Nachbeobachtung + Betrieb
Wie groß die einzelnen Blöcke werden, hängt vom jeweiligen Projekt ab. Typische Kostentreiber sind unter anderem:
- Anzahl und Qualität bestehender Container
- Anzahl der integrierten Tracking-Anbieter
- Anteil individueller Implementierungen
- Qualität der bestehenden Data Layer
- Komplexität des Consent-Setups
- Anzahl beteiligter Stakeholder
- gewünschter Testing-Umfang
- Parallelbetrieb oder direkte Migration
- benötigte Dokumentation
- Schulung des Kunden
- gewünschte Betreuung nach Umstellung
- Hosting- und Infrastrukturmodell
Eine solche Struktur macht Angebote belastbarer.
Angebotsstrategie
Lieber Unsicherheit sichtbar machen als zu knapp kalkulieren
Die schwierigsten SST-Projekte sind nicht zwingend diejenigen mit den meisten Tags. Problematisch sind vor allem Projekte, bei denen vor dem Start viele Abhängigkeiten unbekannt sind. Genau diese Unsicherheit sollte sich auch im Angebotsprozess widerspiegeln.
Festpreis: Bei überschaubaren Setups kann ein Festpreis sinnvoll sein.
Zweistufiges Vorgehen: Bei komplexen oder historisch gewachsenen Tracking-Landschaften kann dagegen ein zweistufiges Vorgehen sinnvoller sein: Zunächst wird ein Audit durchgeführt und der Migrationsumfang definiert. Anschließend wird auf Basis dieser Erkenntnisse die eigentliche Umsetzung kalkuliert.
Damit wird aus einer groben Schätzung eine belastbare Projektplanung. Und damit sinkt das Risiko, dass wesentliche Arbeiten erst während der Umsetzung sichtbar werden.
Fazit
Kalkuliere die Umstellung, nicht nur den Server-Container
Server-Side Tagging ist technisch gut beherrschbar. Die eigentliche Herausforderung für Freelancer und Agenturen liegt häufig darin, die gesamte Umstellung als Projekt korrekt zu erfassen. Nicht nur der Server-Container verursacht Aufwand: Bestandsaufnahme, Konzeption, Testing, Stakeholder-Abnahmen, Release, Nachbeobachtung und laufender Betrieb gehören ebenso dazu.
Wer diese Bestandteile berücksichtigt, kann realistischere Angebote erstellen und vermeidet Diskussionen über Leistungen, die während des Projekts plötzlich als „zusätzlicher Aufwand“ auftauchen. Gerade bei Server-Side Tagging lohnt es sich deshalb, nicht nur die technische Implementierung zu verkaufen, sondern einen klar definierten Prozess.
Nächster Schritt
Trenne Projektarbeit und Infrastrukturbetrieb sauber voneinander
ProxyRiders übernimmt Hosting, Skalierung, Updates und den technischen Betrieb des GTM Tagging-Servers. Du hältst Konzeption, Implementierung, Testing und Kundenabnahme kalkulierbar in Deinem Leistungsumfang.