4 Komponenten
4 Komponenten kommen bei Google Analytics zum Einsatz:
- Collection: Hiermit werden Daten zu Nutzer-Interaktionen gesammelt.
- Processing: Hier werden die gesammelten Daten – unter Berücksichtigung der Konfiguration – verarbeitet.
- Configuration: Die verarbeiteten Daten können damit beeinflusst werden.
- Reporting: Hier findet dann die Präsentation und Visualisierung der Daten statt.
Collection
Zunächst müssen die Daten gesammelt werden. Hierzu existieren verschiedene Technologien und Bibliotheken, die zu diesem Zweck eingesetzt werden können. Welche Technologie zum Einsatz kommen kann, hängt von der eingesetzten Plattform ab. Folgende Techniken gibt es:
- Für Website und Web-Applikationen existieren JavaScript-Bibliotheken wie gtag.js, analytics.js und die App + Web Property.
- Für Android gibt es eine Firebase SDK.
- Für iOS gibt es auch eine eigene Firebase SDK.
- Für AMP-Websites gibt es die amp-analytics-Bibliothek.
- Man kann aber auch Plattform-unabhängig mit dem Measurement Protocol Daten erfassen.
Für das Web kommen gtag.js, analytics.js und die App + Web Property zum Einsatz. Zur App + Web Property komme ich gleich nochmal. Historisch muss noch der Vollständigkeit halber gesagt werden, dass neben den JS-Bibliotheken gtag.js und analytics.js auch noch ga.js existierte.
ga.js war das erste Tracking-Skript von Google Analytics und wurde 2014 zuletzt aktualisiert. Es ist auch unter dem Namen “Klassisches Analytics” (Classic Analytics) bekannt. In 2013 kam dann analytics.js, auch bekannt unter “Universal Analytics”. Das neue Skript kam mit mehr Funktionen, wie z.B. E-Commerce-Tracking. Dann kam das Global Site Tag (gtag.js) dazu. Damit möchte Google die eigene Produktwelt (Google Analytics, Google Ads, Google Tag Manager, etc.) vereinen und vereinheitlichen. Bisher hat jedes Tool etwas anders gearbeitet und seine eigene Schreibweise gehabt.
Das Tracking für mobile Apps über Android und iOS ging lange Zeit über die “Google Analytics Services SDKs”. Mit Februar 2020 wurden diese SDKs endgültig gelöscht. Die alten Dokumentationen zur Einrichtung kann man jedoch weiterhin für Android und iOS bei Google Developers finden. Seit da an empfiehlt Google Analytics die Umstellung auf die “Firebase SDKs” von Android und iOS.
Firebase wurde 2014 von Google akquiriert. Die umfassende App-Entwicklungsplattform hat seit 2016 auch Firebase Analytics integriert. Firebase Analytics ist das Google Analytics für Apps. Statt Sitzungen und Seitenaufrufen liegt der Fokus bei Firebase auf User und Events. Zudem existieren in Firebase User Properties und Event-Parameter statt Hit-, Session- und User-Scopes. Leider konnte man – mit Ausnahme von Workarounds – App- und Web-Daten nicht mehr zusammen analysieren. Auch gab es einen Tool-Bruch, da man nun Google Analytics und Firebase Analytics im Einsatz hatte – 2 Tools.
Um dieses Problem aus der Welt zu schaffen, wurde im Juli 2019 die neue App + Web Property vorgestellt (zunächst als Beta). Man spricht dabei auch von “Firebase für das Web”, da das vorhin erwähnte Firebase-Daten-Modell nun auch für Websites zum Einsatz kommt (statt Sitzungen und Seitenaufrufen liegt der Fokus bei User und Events). Technisch basiert die neue Property auf gtag.js, was also auch der aktuelle Standard für den Google Tag Manager und Google Analytics ist.
Zurück zur eigentlichen Daten-Sammlung:
Die aktuellen Techniken gtm.js, analytics.js, SDKs, etc. basieren alle auf dem Measurement Protocol. Mit dem Measurement Protocol können Daten von beliebigen Geräten, die mit dem Internet verbunden sind, an Google Analytics gesendet werden. Daten lassen sich demnach auch ohne den Einsatz von bspw. analytics.js versenden. So kann man selbstständig Requests per POST oder GET, die der Struktur des Measurement Protocols entsprechen müssen, an den GA-Server schicken. Werden aber die JavaScript-Bibliotheken oder SDKs eingesetzt, dann übernehmen diese Techniken automatisch den “Zusammenbau” der Hits. Was das genau heißt, schauen wir uns nachfolgend an.
Wird der JavaScript-Code von Universal Analytics im Head-Bereich der Website integriert, dann ist der Tracking-Prozess grob wie folgt:
- Nutzer ruft eine Website auf
- Der Browser fordert die Seite beim Server an
- Der Server antwortet und sendet die Seite an den Browser
- Der Browser stellt fest, dass im Head-Bereich das Google Analytics-Skript eingebunden ist
- Der Browser fordert das Skript vom Google-Server an
- Der Google-Server antwortet und schickt das Skript an den Server
In der Regel passiert dieser Prozess schnell, sodass man als Nutzer nicht viel mitbekommt. Das Skript holt sich nun diverse Daten und schickt es an den Google Analytics-Server. Von wo kommen aber die Daten? Das Skript holt sich die Informationen aus verschiedenen Quellen:
- HTTP-Request des Browsers
- Browser-Informationen
- Cookies
Fordert der Nutzer eine Website oder Ressource an, dann wird ein HTTP-Request geschickt. Dieser Request enthält diverse Informationen wie z.B. den Referrer und User Agent. Über das window- und document-Objekt kann das Skript ebenfalls auf diverse Informationen zugreifen (z.B. Seitentitel, URL, etc.). Zudem werden auch Informationen aus Cookies ausgelesen, um Session- oder Kampagnen-Daten abzugreifen.
Diese Daten werden dann zu einer URL “zusammengebastelt” und an den GA-Server geschickt. Dieses Zusammenbasteln übernimmt das eingesetzte Skript (z.B. analytics.js). Erfolgt das Tracking mittels Measurement Protocol muss diese URL JavaScript-seitig selbst zusammengebastelt werden. Beides hat Vor- und Nachteile. Beim Einsatz des Tracking-Codes muss man selbst nicht mehr viel machen. Nachteil ist, dass weitere Daten – die man ggf. nicht benötigt – mitgeschickt werden, sofern man es selbst nicht unterbindet. Beim direkten Einsatz des Measurement Protocols bestimmt man selbst was an Daten versendet wird. Nachteil ist der technische Setup-Aufwand dahinter.
An welche URL werden nun die Daten geschickt?
Ein Hit muss min. folgende Parameter mitsenden:
https://www.google-analytics.com/collect?v=1&t=pageview&tid=UA-12345678-9&cid=meine_id
Dabei kann der Request unterteilt werden in die Transport-URL und den Payload. Mit der Transport-URL wird der Endpoint bestimmt, wo die Daten hingeschickt werden sollen. Dies folgender Teil der Request-URL:
https://www.google-analytics.com/collect
Daten können mittels GET oder POST an diesen Endpoint geschickt werden. Die endgültig gesammelten Daten werden als Payload verschickt:
v=1&t=pageview&tid=UA-12345678-9&cid=meine_id
Es handelt sich somit um die Parameter innerhalb der Request-URL. Die Daten werden als Schlüssel-/Wert-Paare (key-value pairs) übermittelt. Die Zuweisung erfolgt über das =, die Trennung über &. In meinem Beispiel werden alle Pflicht-Werte mitgegeben:
| Parameter | Beispiel | Bedeutung |
|---|---|---|
| v | v=1 | Hier wird die Protokoll-Version mitgegeben. |
| tid | tid=UA-12345678-9 | Dies ist die Property-ID an die Daten geschickt werden sollen. |
| cid | cid=meine_id | Darüber wird eine eindeutige Client ID mitgegeben. |
| t | t=pageview | Dieser Parameter definiert den Hit-Typ (in diesem Fall ist es ein Seitenaufruf). |
Hinweis zur alten Bibliothek ga.js:
Der alte Tracking-Code ga.js basierte nicht auf dem Measurement Protocol. Das Skript baute alle Informationen ebenfalls zu einer URL zusammen, jedoch wurde der Request als .gif abgeschickt. Der Request fing dabei an mit:
http://www.google-analytics.com/__utm.gif?
Als Parameter wurden die Informationen dann mitgegeben. Die GIF-Parameter unterscheiden sich jedoch von den Parametern des Measurement Protocols. Zu erkennen sind sie an “utm” gefolgt von weiteren 1-2 Buchstaben für die verschiedenen Verwendungszwecke. “utmwv” definierte z.B. die Tracking-Code-Version, “utmul” sendete die Browser-Sprache und mit “utmr” wurde die Referrer-URL übermittelt.
Processing
In diesem Schritt werden die gesammelten Daten zunächst entgegengenommen, bevor sie im weiteren Verlauf verarbeitet werden. Die Verarbeitung findet unter Berücksichtigung der Konfiguration statt.
Die Daten landen in einem Log-File auf dem Google Analytics-Server. Aus dem Log-File geht es in den Verarbeitungsprozess. Dabei werden die Daten sinnvoll zusammengeführt und strukturiert. 4 wichtige Schritte passieren dabei:
- Daten-Organisation: Die Daten werden zunächst in Nutzer und Sitzungen organisiert.
- Daten-Import: Weitere Daten aus verschiedenen Quellen werden in diesem Schritt mit den Google Analytics-Daten verknüpft.
- Daten-Anpassungen: Hier werden dann die Daten nach den individuellen Einstellungen angepasst.
- Daten-Aggregation: Für Reporting-Zwecke werden die Daten nun sinnvoll strukturiert und in Datenbank-Tabellen organisiert. Durch die Daten-Organisation kann man schneller auf diese Daten zugreifen.
Configuration
Während des Verarbeitungsprozesses finden auch individuelle Konfigurationen Beachtung. Alle 4 Schritte im Processing können dabei beeinflusst werden:
- Daten-Organisation: Wie Nutzer und Sitzungen verarbeitet werden, kann auch selbst beeinflusst werden. Statt der Client ID, kann z.B. eine User ID konfiguriert werden. Oder das Zeitlimit für Sitzungen kann angepasst werden. Dies findet hier Berücksichtigung.
- Daten-Import: Hier kann einstellt werden, dass Daten aus der Google Search Console oder Google Ads importiert werden.
- Daten-Anpassungen: Die individuellen Einstellungen können in der Verwaltung von Google Analytics definiert werden. Dazu gehören unter anderem Filter-Einstellungen.
- Daten-Aggregation: Sobald die Daten an diesen Schritt angekommen sind, gibt es keine Möglichkeit mehr diese anzupassen.
Für Daten-Konfigurationszwecke gibt es zudem noch APIs, mit denen man Daten automatisiert anpassen kann:
- Management API: Damit können Konten, Properties und Datenansichten angepasst werden.
- Provisioning API: Hier können automatisiert Google Analytics-Konten erstellt werden (für große Projekte).
- User Deletion API: Hiermit können personenbezogene Daten gelöscht werden.
Reporting
Nach dem Verarbeitungsprozess können die Daten betrachtet werden. Dazu gibt es 2 Möglichkeiten:
- Über die Google Analytics Benutzeroberfläche. Hier werden die Daten schon visualisiert. Zudem können Daten segmentiert und gefiltert werden.
- Oder man nutzt die Reporting API, um die Daten selbst zu visualisieren oder auch in andere Tools zu übertragen.
Sonderfall: Serverseitiges Tracking
Die oben dargestellte Funktionsweise ist stark client-orientiert. Im August 2020 hat das Google-Team den Server-Container innerhalb des Google Tag Managers vorgestellt. Hier wird zwischen Browser und Google Analytics-Server eine weitere Schicht (der Google Tag Manager-Server) dazu integriert. Wie das konkret funktioniert kannst du hier nachlesen:
