Die Evolution des Web-Trackings: Von Logfiles zur serverseitigen Zukunft

Web-Analyse hat mehrere Datenquellen: Anfragen im Serverprotokoll, Ereignisse aus dem Browser und Geschäftsvorgänge im Backend, etwa Bestellungen im Serversystem eines Shops. Im Laufe der Zeit kamen neue Verfahren hinzu. Die älteren verschwanden dadurch nicht. Serverseitiges Tracking ergänzt heute häufig die Browsermessung; eine vollständige Rückkehr zu Logdateien ist damit nicht gemeint.

Logdateien: Anfragen zählen, Nutzung einordnen

Serverprotokolle waren eine wichtige Grundlage früher Web-Statistiken und bleiben für Betrieb und Fehleranalyse nützlich. Ein Access-Log kann beispielsweise Zeitpunkt, angeforderte Adresse, Antwortstatus und IP-Adresse enthalten. Welche Anfragen und Felder gespeichert werden, bestimmt die Konfiguration.

Eine Anfrage ist jedoch kein Besucher und nicht automatisch ein Seitenaufruf. Eine einzelne Seite lädt oft mehrere Dateien; Bots erzeugen ebenfalls Anfragen. Inhalte aus Browser- oder vorgeschalteten Caches können den Ursprungsserver umgehen. Ein Scrollvorgang ohne zusätzliche Anfrage erscheint dort überhaupt nicht. Log-Analyse braucht deshalb passende Filter und klar definierte Kennzahlen.

Urchin bereitete Web-Daten für Berichte auf. Google übernahm das Unternehmen 2005 und stellte Google Analytics am 14. November 2005 kostenlos bereit. Damit wurde eine gehostete Analyse für viele Websites leichter zugänglich.

Browsermessung: Ereignisse zusätzlich erfassen

JavaScript kann Interaktionen wie Videostarts oder Klicks erkennen und als Ereignis senden. Ein Tracking-Pixel bezeichnet je nach Zusammenhang eine Bildanfrage oder allgemeiner einen Messaufruf. Cookies sind gespeicherte Werte, kein ausführbarer Programmcode.

Google Analytics verwendet hauptsächlich First-Party-Cookies, die unter der eigenen Domain der Website gespeichert werden. Eine Verbindung zu einem fremden Analyseserver ist daher nicht gleichbedeutend mit einem Drittanbieter-Cookie. Universal Analytics wertete Seitenaufrufe, Ereignisse, Nutzer und Sitzungen aus. Die inzwischen eingestellte Produktgeneration dient hier der historischen Einordnung.

Mehrere Anbieter und Betriebsmodelle

Die Entwicklung verlief nicht nur entlang der Google-Produkte. Adobe übernahm Omniture 2009. Webtrekk ging 2019 an Mapp. Matomo hieß bis 2018 Piwik und bietet unter anderem einen Betrieb auf eigener Infrastruktur. Auch etracker gehört zum Spektrum der Web-Analyse.

Für die Auswahl zählen konkrete Funktionen, Datenflüsse, Verträge, Speicherorte und Betriebskosten. Ein europäischer Anbieter, Open Source oder eigenes Hosting allein belegt keine datenschutzkonforme Einrichtung. Maßgeblich sind die aktuelle Einrichtung und die tatsächliche Verarbeitung.

Browser-Schutz und das Ereignismodell von GA4

Safari mit Intelligent Tracking Prevention und Firefox mit Enhanced Tracking Protection begrenzen bestimmte Trackingverfahren. Je nach Browser, Kontext und Einstellung werden beispielsweise Zugriffe blockiert oder Speicherbereiche voneinander getrennt. Daraus folgt kein allgemeines Verbot sämtlicher Cookies.

GA4 organisiert die Erhebung um Ereignisse mit zusätzlichen Parametern. Nutzer- und Sitzungskennzahlen bleiben Teil der Auswertung. Modellierung kann unter bestimmten Voraussetzungen fehlende Informationen statistisch ergänzen: Beobachtete Muster dienen dazu, Werte zu schätzen, für die keine direkte Messung vorliegt. Eine Rekonstruktion aller verlorenen Ereignisse ist damit nicht zugesagt; auch ausreichende Datenmengen garantieren die Eignung einer Property nicht.

Serverseitiges Tagging: ein zusätzlicher Verarbeitungsschritt

Bei serverseitigem Tagging empfängt ein Server Messdaten über eine kontrollierte Empfangsadresse, den sogenannten Endpunkt. Der Server verarbeitet die Ereignisse oder leitet Ereignisdaten weiter. Quellen können Browser, Apps und Backend-Systeme sein. Bei Google Tag Manager wird für den Produktivbetrieb eine eigene First-Party-Domain empfohlen. Eine gemeinsame Hauptdomain ist jedoch keine allgemeine Definition von Server-to-Server-Kommunikation.

Der Nutzen liegt in einem prüfbaren Datenweg: Welche Felder gehen an welches Ziel? Welche Ereignisse werden verworfen? Welche Einwilligung gilt? Eine richtige Konfiguration kann Browserarbeit reduzieren. Zusätzliche Infrastruktur verursacht allerdings Kosten und benötigt Überwachung, Zugriffsschutz und Wartung.

Ein Server erkennt einen reinen Scrollvorgang nicht ohne ein Signal aus dem Browser. Eine bestätigte Bestellung kann dagegen direkt aus dem Bestellsystem kommen. Bei paralleler Browser- und Backend-Übermittlung ist eine passende Deduplizierung nötig. Wird dieselbe Bestellung über beide Wege gemeldet, darf daraus beispielsweise nur ein Kauf statt zwei Käufen entstehen. Blockierte, nicht erhobene oder unzulässige Daten werden durch den Serverweg nicht automatisch verfügbar.

Der Anteil fehlender Ereignisse muss für die konkrete Website untersucht werden. Unterschiedliche Quellen erfassen verschiedene Teile eines Besuchs; eine Abweichung ist deshalb nicht automatisch ein Messfehler. Sinnvoll ist die passende Kombination der Datenquellen mit dokumentierten Grenzen.