Was kostet Server-seitiges Tracking?
Neben Google-Analytics 4-Implementierungen und -Trainings habe ich derzeit auch viel mit Server-seitigem Tracking zu tun. Entweder geht es darum, das vorhandene Tracking auf Server-seitig umzurüsten. Oder in Workshops werden die Vorteile und Aufwände besprochen und eine Roadmap für das jeweilige Unternehmen entwickelt.
Bei den Workshop-Gesprächen kommt recht schnell folgende Frage auf: Was wird uns das Server-seitige Tracking kosten? Denn anders als beim bisherigen Client-seitigen Tracking muss für das Server-seitige Tracking ein eigener Server bereitgestellt werden, der regelmäßige Kosten verursacht.
Deswegen erläutere ich heute im Newsletter die drei Kostenfaktoren, die ein Server-seitiges Tracking mit sich bringt, am Beispiel eines eingesetzten Google Cloud Servers.
Kurzer Recap: Was macht Server-seitiges Tracking anders?
Server-seitiges Tracking sendet im Vergleich zum Client-Seitigen Tracking die erfassten Daten nicht direkt an die Vendoren wie Google Analytics, Google Ads oder Facebook, sondern an einen eigenen Server. Dies gibt dir bessere Möglichkeiten bzgl. Datenschutz und Datenqualität.
Dieser neue „Endpoint“, an welchen die Daten nun gesendet werden, muss allerdings gehostet werden. Meistens geschieht dies via Cloud-Anbieter wie z.B. Google Cloud, Microsoft Azure oder Amazon Web Services.
Das Bereitstellen dieses Servers bringt allerdings laufende Kosten mit sich.
Kostenfaktor 1: Rechenpower
Je mehr Traffic du auf deiner Website hast, je umfangreicher dein Tracking ist und je mehr Tracking-Tools du nutzt, desto mehr Requests entstehen. Diese Requests nimmt der Server entgegen und beantwortet sie. Dafür braucht der Server Rechenpower.
Diese Rechenpower liefern in einem typischen Google Cloud Setup die sog. App Engines. Google empfiehlt, beim Start des eigenen Server-seitigen Trackings drei App Engines einzusetzen. Damit sollten auch größere Online-Shops ihre Request-Mengen verarbeiten können.
Eine App Engine kostet ca. 35 € pro Monat. Zudem können über die Auto-Scaling-Funktion optional weitere App Engines aktiviert werden, falls es zu Traffic-Spitzen und somit unüblich mehr Requests kommt. Die über das Auto Scaling aktivierten App Engines sitzen bildlich gesprochen auf der Reserve-Bank und warten auf ihren Einsatz. Das Bereitstellen und Aktivieren braucht jedoch etwas Zeit, weswegen der übliche Traffic nicht über das Auto Scaling gehandlet werden sollte.
Zur Kosten-Optimierung kann man nach ein paar Wochen des aktiven Server-seitigen Trackings den Traffic in den Google Cloud Berichten kontrollieren, wie hoch das eigene Request-Volumen ist und wie viele App Engines in der Regel zum Einsatz kommen. Werden nicht alle drei App Engines benötigt, kann man diese dann reduzieren.
Der Nachteil, wenn die App Engines überlastet sind: Die überzähligen Requests können nicht entgegengenommen und beantwortet werden. Das Tracking wird löcherig.
Kostenfaktor 2: Network-Egress
Die Antwort der Requests wird vom Server an die Nutzer-Browser gesendet. Dieser Vorgang wird als „Network Egress“ (zu Deutsch: Netzwerk-Ausgang) bezeichnet und nach Datenmenge (sprich Giga- oder Terabyte) in Rechnung gestellt.
Das Volumen des Network Egress geht mit der Request-Menge einher. Je mehr Tracking verbaut ist, desto mehr Network Egress. Außerdem ist noch wichtig, in welchem Land der Server steht und aus welchen Ländern besonders viele Nutzer auf deine Website zugreifen. Idealerweise steht der Server von diesen Nutzern nicht allzu weit weg.
Das Volumen des Network Egress geht mit der Request-Menge einher. Je mehr Tracking verbaut ist, desto mehr Network Egress. Außerdem ist noch wichtig, in welchem Land der Server steht und aus welchen Ländern besonders viele Nutzer auf deine Website zugreifen. Idealerweise steht der Server von diesen Nutzern nicht allzu weit weg.
Eine weitere Möglichkeit, den Egress zu optimieren, ist die sog. Datastream Consolidation. Wenn du z.B. sowohl Universal Analytics als auch Google Analytics 4 implementiert hast, würden normalweise beide Tools größtenteils die selben Daten an den Server funken. Warum diese „doppelten“ Daten nicht einsparen?
Der Google Analytics 4 Data Stream bietet die Möglichkeit, ebenfalls Universal Analytics mit Daten zu versorgen. Und auch die von der Facebook Conversion API benötigten Daten kann GA4 „huckepack“ mitnehmen. So spart man eine Menge doppelter Requests.
Kostenfaktor 3: Logging
https://ecommerce-analytics.de/server-seitiges-tracking-workshop/Alle eingehenden Requests werden geloggt, also gespeichert. Diese gespeicherten Logs eignen sich z.B. für Fehleranalysen des Servers.
Google stellt ca. 53 Gigabyte Speicher pro Monat für diese Logs kostenfrei bereit. Braucht man mehr Speicherplatz, muss dieser bezahlt werden. Man kann dann allerdings schauen, ob man wirklich alle Requests loggen muss/möchte oder ob man bestimmte Filter einrichtet. Hier kommen wieder die doppelten Data Streams ins Spiel.
Wofür braucht man das Logging der Requests? Hauptsächlich zum Debugging. Anhand der Logs können Fehler im Tracking erkannt werden, z.B. ob du „Personal Identifiable Information“ wie E-Mail-Adressen speicherst. Oder wenn du merkst, dass dein Server-seitiges Tracking wesentlich weniger Daten erfasst als das Client-seitige.
Nach dem Setup deines Server-seitigen Trackings mit einem Google Cloud Project ist es also ratsam, einen Blick zu haben auf…
- die verbrauchte Rechenpower / Belastung der App Engines und ob du hier evtl. mit weniger App Engines auskommst.
- das Volumen der zu beantwortenden Requests, also dem Network Egress und ob du dein Tracking nicht „verschlanken“ bzw. Data Streams konsolidieren kannst
- den Speicherverbauch deines Request-Loggings und ob du ggf. Filter einrichten solltest, die das Logging-Volumen gering halten
Die meisten Request-Volumen sind über die Zeit gleichmäßig. Dadurch sind die regelmäßigen Kosten auch gut vorhersehbar.
Wenn du gerade am Beginn des Themas stehst und dich fragst, ob Server-seitiges Tracking für dich Sinn macht und welche Schritte du angehen musst, ist mein Workshop zu dem Thema evtl. interessant für dich.