Client- vs. serverseitiges Tracking

Wer ein Webanalyse-Tool zur Messung von Website-Traffic nutzt und sich für die gängige, clientseitige Implementierung entscheidet, sieht sich spätestens beim Auswerten von Transaktionsdaten mit folgender Frage konfrontiert:

Wieso ist die Anzahl an Transaktionen im Webanalyse-Tool niedriger als meine tatsächlichen Transaktionen im Backend?

Diese Frage ist durchaus berechtigt, da eine Abweichung von 5-15% trotz korrekter Tracking-Implementierung erfahrungsgemäß nicht unüblich ist. Eine entscheidende Rolle hierbei spielen der User und seine Einstellungen im Browser. Das Bewusstsein über die Verfolgung im Netz sowie die Möglichkeiten, sich dort anonym zu bewegen, sind in den vergangenen Jahren stark angestiegen und werden sich voraussichtlich immer weiter verbreiten.

Verschiedene Tools wie z.B. AdBlock oder Ghostery helfen den Nutzern dabei, bekannte Webanalyse-Tools wie Google Analytics zu erkennen und zu blockieren. Auch die Browsereinstellungen werden immer leichter zugänglich, wodurch die Nutzer z.B. ihre Cookies, die für das Tracking erforderlich sind, ohne große Umstände löschen können. Diese und viele weitere Browsereinstellungen führen letztendlich dazu, dass das Verhalten dieser Nutzer nicht messbar ist und ein großer Teil an Daten verloren geht.

Wie lässt sich jedoch dieses Problem beheben, wo man doch keinen Einfluss auf den Browser des Users nehmen kann?

Technisches Setup

Spielen die Vollständigkeit und Genauigkeit der Daten eine große Rolle, besteht die Möglichkeit, vom clientseitigen aufs serverseitige Tracking umzusteigen. Die Trackingdaten werden also nicht mehr im Browser des Users (Client) gesammelt und versendet, sondern stattdessen von dem dahinterstehenden Website-Server. Der Unterschied lässt sich anhand der folgenden Grafik verdeutlichen:

"Client- vs serverseitiges tracking"

A: Sobald ein User eine Website aufruft, erfolgen verschiedene Requests an den Webserver, der die notwendigen Dateien (HTML, JS, css) liefert, um die Seite darstellen zu können. Dieser Austausch erfolgt sowohl beim client- als auch serverseitigen Tracking, weil er für die Website-Darstellung grundsätzlich notwendig ist.

B: Diese Verbindung stellt das clientseitige Tracking dar, das Senden von Daten vom Browser zu den Servern des Analyse-Tools. Die Implementierung ist mittlerweile auch für wenig technikaffine Personen möglich und durch den Browser-Kontext können viele User-spezifische Informationen wie Cookies, die IP Adresse oder der User Agent leicht ermittelt werden. Außerdem kann in der Netzwerkanalyse des Browsers nachvollzogen werden, welche Requests mit welchen Daten rausgeschickt werden, was ein schnelles und unkompliziertes Debugging ermöglicht. Gleichzeitig kann der User jedoch leicht Einfluss auf das Tracking nehmen, indem er dieses blockiert. Es fehlt somit die Kontrolle über das Tracking.

C: Hier wird das serverseitige Tracking dargestellt, bei dem der Server der Website direkt mit den Servern des Analyse-Tools kommuniziert. Die Kommunikation erfolgt wie bei der Browser-Server-Kommunikation via HTTP(S)-Requests. In diesem Fall hat der User keine Möglichkeit, das Tracking zu blockieren oder zu beeinflussen. Treten keine technischen Probleme auf, ist daher eine 100%-ige Genauigkeit von z.B. Transaktionsdaten erreichbar. Der Nachteil bei dieser Variante ist jedoch, dass für die Implementierung umfassende technische Kenntnisse notwendig sind und die Ermittlung von User- bzw. Browser-spezifischen Daten zusätzliche Implementierungen erfordert. Außerdem lassen sich Tracking-Requests nicht einfach im Browser überprüfen, wodurch das Debugging erschwert wird.

Use Cases

Stellt man beide Varianten gegenüber, lässt sich sagen, dass sowohl die client- als auch serverseitige Implementierung Vor- und Nachteile mit sich bringt. Je nach Kontext macht es also Sinn, sich für die eine oder andere Variante zu entscheiden. Denkbar ist dabei auch eine Kombination beider Varianten, um optimale Tracking-Ergebnisse zu erzielen.

Weniger kritische Bestandteile wie z.B. das Page- oder Event-Tracking, in denen ein Richtwert in der Regel ausreichend ist, können auf Clientseite getrackt werden. Im Gegenzug dazu können Aktionen wie Registrierungen oder Transaktionen, die 100%-ige Genauigkeit fordern, über serverseitiges Tracking laufen. Bei dieser Form der Implementierung ist besonderes Augenmerk auf die Übergabe der Client-ID aus dem Tracking-Cookie zu achten, um eine korrekte Session-Verknüpfung später im Analysetool zu gewährleisten.

Während die Entscheidung für client- oder serverseitiges Tracking bei den zuvor genannten Beispielen auf der erforderlichen Datengenauigkeit basiert, gibt es auch Interaktionen, die nur über serverseitiges Tracking gemessen werden können und dieses daher voraussetzen. Dazu zählen Aktivitäten, die nicht auf der Website stattfinden und bei denen somit kein Tracking-Request im Browser rausgeschickt werden kann. Ein Beispiel dafür sind Offline-Käufe.

Angenommen ein User erhält auf der Website einen Gutschein-Code, der 10% Rabatt im Ladengeschäft verspricht, und löst diesen daraufhin ein. Sendet das Warenwirtschaftssystem diesen Offline-Kauf mit dem Gutschein-Code mithilfe von serverseitigem Tracking an das Webanalyse-Tool, kann später ermittelt werden, wie häufig die dazugehörige Werbeaktion gesehen und geklickt wurde und wie häufig sie zu einem Kauf geführt hat. Es kann somit der Erfolg der Kampagne gemessen und diese optimiert werden. Ein weiteres Beispiel sind Stornierungen oder Statusänderungen einer Bestellung. Angenommen die Bezahlung für eine bestimmte Bestellung ist eingegangen oder die Bestellung wurde aus verschiedenen Gründen vom Kundenservice storniert, kann dies für verschiedene Auswertungen im Webanalyse-Tool relevant sein und sollte somit erfasst werden. Auch hier lassen sich bestimmte Aktionen im Warenwirtschaftssystem mit einem serverseitigem Tracking verbinden, um die Information ans Webanalyse-Tool zu übermitteln.

Das serverseitige Tracking ermöglicht somit zum einen eine bessere Datenqualität. Zum anderen können Websitedaten mit weiteren geschäftsrelevanten KPIs angereichert werden, um ein umfassendes Bild des Users zu erhalten. Unabhängig davon, aus welchem Grund serverseitiges Tracking zum Einsatz kommt, sollte man jedoch stets im Hinterkopf behalten, dass es nicht davon befreit, datenschutzkonform zu arbeiten. Die erfassten Daten müssen genau wie die von Clientseite stammenden Daten sorgsam behandelt und auf die Einhaltung von Datenschutzrichtlinien überprüft werden. Darüber hinaus ist es auch hier notwendig, den Nutzer über die Sammlung und Verarbeitung der Daten aufzuklären und ihm eine Opt-Out-Möglichkeit zu bieten.

Fazit

Zusammengefasst lässt sich sagen, dass das serverseitige Tracking eine gute Alternative oder Erweiterung zum clientseitigen Tracking darstellen kann. Der Implementierungsaufwand ist jedoch in der Regel höher und es ist mehr technisches Know-How erforderlich. Aus diesem Grund sollten Aufwand und Nutzen sowie die Sinnhaftigkeit je nach Einzelfall abgewogen werden, bevor sich für die eine oder die andere Variante entschieden wird. Ein Beispiel für die Nutzung von serverseitigem Tracking mit Google Analytics folgt in einem späteren Artikel.