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.

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.

Die Vorteile des Server-seitigen Trackings

Zwei große Umwälzungen zurzeit in der Analytics-Welt:

Google hat angekündigt, die Vorgängerversion von GA4 im nächsten Jahr abzuschalten. Alle Universal Analytics-Nutzer müssen demnächst also auf GA4 (oder ein anderes Tool) wechseln
Bisherige Tracking-Implementierungen (sog. client-seitiges Tracking) werden immer löchriger und ihr Einsatz zudem datenschutzrechtlich immer fragwürdiger.. Deswegen beschäftigen sich viele aktuell damit, ihr Tracking auf eine server-seitige Lösung umzustellen.

Was es damit auf sich hat und was die größten Vorteile dabei sind, erkläre ich heute.

Kurz erklärt: Was ist Server-seitiges Tracking?

Aktuell funktionieren die meisten Tracking-Implementierungen client-seitig. Das bedeutet, dass die eingebauten Tracking-Tags direkt im Browser des Nutzers geladen werden und die gesammelten Daten von dort aus direkt an die Tracking-Anbieter wie Google oder Facebook senden.

Beim server-seitigen Tracking werden die Tracking Tags grob gesagt nicht mehr vollständig im Browser des Nutzers geladen, sondern größtenteils auf dem von dir bereitgestellten Server. Auch die getrackten Daten gehen erst einmal zu diesem Server und von dort dann an die jeweiligen Tracking-Anbieter.

Das bringt uns gleich zu…

Vorteil 1: Mehr Datenschutz

Weil die Daten erst an den eigenen Server geschickt werden, kannst du dort in diesem „Zwichenstopp“ auch wesentlich besser bestimmen, welche Daten in welcher Art an die Anbieter weitergegeben werden. So kannst du bspw. die IP-Adresse auf dem eigenen Server bereits anonymisieren oder komplett rausnehmen. Auch andere sensible Daten kannst du selbst verschlüsseln oder von der Weitergabe ausschließen. Server-seitiges Tracking bringt dir wesentlich mehr Kontrolle über deine eigenen Daten.

Vorteil 2: Bessere Datenqualität

Adblocker und Browser Tracking Preventions blockieren mittlerweile einiges an client-seitigem Tracking. Zudem werden Cookie-Laufzeiten stark eingeschränkt, was die Analytics-Tools daran hindert, Nutzer über längere Zeit hinweg wiederzuerkennen.

Die Laufzeit der Cookies von Google Analytics ist normalerweise auf 2 Jahre eingestellt. Apples ITP (Intelligent Tracking Prevention) im Safari-Browser dampft diese 2 Jahre auf 7 Tage ein. Heißt: Nach 7 Tagen wird der GA-Cookie gelöscht. Kommt der Nutzer danach wieder auf deine Website, wird er von Google Analytics wie ein neuer Nutzer behandelt.

Erkennt der Browser einen Parameter von Google Ads oder Facebook Ads in der URL, wird der Cookie sogar bereits nach 24 Stunden gelöscht.

Das ist sehr schlecht für die Wiedererkennung der Nutzer und somit für die Attribution von Conversions auf die Marketing-Kanäle, über die der Nutzer auf die Website kam.

Server-seitiges Tracking schafft hier Abhilfe. Für Cookies gelten wieder die üblichen Laufzeiten, was eine bessere Attribution ermöglicht.

Bei dem Ganzen gilt natürlich weiterhin: Möchte ein Nutzer nicht getrackt werden (und lehnt im Cookie-Banner die Cookies ab) wird er auch nicht getrackt. Ein server-seitiges Tracking ignoriert nicht die Entscheidung des Nutzers.

Vorteil 3: Eine bessere Seitenladezeit

Tracking-Tags bestehen hauptsächlich aus Javascript, welches bei client-seitigem Tracking vom Browser des Nutzers geladen und ausgeführt werden muss. Je mehr Tags eingebunden werden, desto größer die Arbeitslast für den Browser. Das drückt auf die Seitenladezeit des Browsers.

Für das Ranking in den Google-Suchergebnissen ist die Seitenladezeit ein nicht unerheblicher Faktor geworden (Stichwort: Googles Core Web Vital Report). Je länger die Seitenladezeit, desto mehr Nutzer verlassen die Website sofort wieder. Ein Grund, weswegen Google solche längeren Seitenladezeiten quasi abstraft und in den Suchergebnissen weiter nach hinten „verbannt“.

Das bedeutet unterm Strich: Durch viel Tracking wird die Seitenladezeit länger, das Google-Ranking dadurch schlechter und Conversions gehen verloren.

Beim server-seitigen Tracking werden die Tracking-Skripte nicht mehr im Browser des Nutzers, sondern auf dem eigenen Server ausgeführt. Weniger zu tun also für den Browser des Nutzers und somit auch geringere Seitenladezeiten.

Meine Prognose: Dieses Jahr werden viele ihr Tracking auf eine server-seitige Lösung umstellen

Das Datenschutz-Thema ist für sehr viele Firmen eine heikle Angelegenheit, die jetzt genau schauen lässt, ob das bisherige Tracking so weiter eingesetzt werden darf. Und gerade, wenn Google den Wechsel vom bisherigen Universal Analytics erzwingt und somit sowieso das Tracking überarbeitet werden muss, werden viele gleich auf server-seitig wechseln.

Was es genau mit dem „Tod von Universal Analytics“ auf sich hat, werde ich in 2 Wochen im nächsten Newsletter erläutern.