Markus Baersch

Google Analytics 4 ist auf dem Vormarsch; aber noch nicht da, wo es sein müsste. Das gilt für viele Bereiche. Aktuell noch als Alpha bezeichnet ist die neue Version des neuen Measurement Protocols. Neben vielen Dingen, die derzeit noch fehlen, gibt es auch klare Vorteile wie z. B. den Schutz vor Spam über einen Schlüssel, der bei allen Hits mit gesendet werden muss. Dieser Beitrag zeigt das Google Analytics 4 Measurement Protocol im Einsatz... und auch dessen (aktuelle) Grenzen.

Measurement Protocol: Mehr als Websites vermessen

Generell ist das Google Analytics Measurement Protocol (GAMP) nichts Neues, sondern wurde bereits mit Universal Analytics eingeführt. Durch einfaches Absetzen von Anfragen an den Analytics-Server sind darüber Messpunkte zu generieren. Ich habe hier im Blog schon vor über fünf Jahren darüber geschrieben und es seither für viele Dinge eingesetzt. Auch heute laufen Daten in meiner Welt über das GAMP - und nicht alles davon hat wirkliche Business Relevanz 😉

Allerdings hat die Einfachheit des alten GAMP - die simple Verwendung und hürdenfreie direkte Bestückung beliebiger Web-Properties mit (falschen) Daten - auch seine Schattenseiten entwickelt. Schon früh haben Spammer das GAMP für sich entdeckt und nicht nur während des Wahlkampfs von Donald Trump (dem ersten freilich), sondern auch in den letzten Wochen mit einem schrägen Revival auf sich aufmerksam gemacht. Wenngleich die ärgerlichen Spuren von Bots in der Webanalyse heute weniger via GAMP erzeugt, sondern von Headless Browsern hinterlassen werden, ist das Thema nicht durch.

Measurement Protocol "V2" / GA4MP

Daher bietet die neue Version (hier findet sich die Entwickler-Dokumentation) neben einigen anderen Anpassungen auch einen gewissen Schutz gegen diese Form von Spam. Wer Hits an eine GA4-Property senden will, muss die Verwendung des Measurement Protocols aktiv in den Einstellungen des Datenstreams aktivieren und ein dort generiertes "API-Secret" verwenden, wenn Hits gesendet werden. Solange ausgehende Hits nicht (wie in einem Browser) für einen Besucher / Anwender "sichtbar" sind, bleibt dieses Kennwort geschützt. So stellt man sicher, dass nur autorisierte Quellen per GAMP Daten über einen Datenstream senden können (welche dann in der verbundenen Property landen).

Auch ist der Versand nur noch per POST statt früher optional auch per GET-Anfrage an den Analytics Server möglich. Was bei der denkbaren Komplexität der zu sendenden Events durchaus sinnvoll ist, weil so mehr Daten in einem Aufruf übertragen werden können. Mehrere Events in einem Aufruf zu senden, ist beim neuen Format so auch etwas einfacher geworden. BTW: nennen wir das neue Format ab hier abgekürzt einfach GA4MP, auch wenn es streng genommen eine Version 2 ist, also auch GAMPV2 wohl nicht falsch wäre.

Die Einrichtung geschieht unter "Verwaltung" - "Datenstreams" (bei der Property). Klickt man hier auf den Eintrag eines bestehenden Datenstreams oder legt einen neuen für diesen Zweck an (beides ist gleichwertig im Ergebnis), kann dort im Bereich "Weitere Einstellungen" unter "Measurement Protocol – API-Secrets" nach Bestätigung eines Hinweises ein "API-Secret" kopiert werden.

Dieser Wert wird beim Versand von Events an die Property zur Authentifizierung gültiger Daten verwendet. Für mehrere Anwendungen, die Daten an GA senden sollen, können bei Bedarf mehrere unterschiedliche Schlüssel existieren. Zudem wird später noch die Measurement Id ("Mess-Id" im deutschen Interface) benötigt. Diese findet sich oben links in den Einstellungen des Datenstreams. Beide Angaben können per Klick in die Zwischenablage kopiert werden.

Erste Schritte

Genau wie beim Vorgänger bietet Google auch für Analytics 4 einen "Event Builder" an, der dazu dient, eigene Events zusammenzustellen und unter Angabe des API-Secrets und der Measurement Id an Analytics zu senden. Im einfachsten Fall wählt man dazu "Custom"-Event aus, gibt eine beliebige "client_id" und einen Eventnamen an (hier "hello_world") und verzichtet auf weitere Parameter. Danach kann das Event nach einem vorherigen Klick auf "Validate Event" an Analytics gesendet werden, wenn alles in Ordnung war.

Diese sind dann in der Echtzeit von Google Analytics 4 in der entsprechenden Property schnell wiederzufinden, wenn man dazu eine (ausdrücklich empfohlen!) eigens angelegte Property nutzt und nicht seine von der Website stammenden Daten verwässert.

GA4MP im Einsatz

So schön das Erproben mit dem Event Builder auch ist: Eine echte Anwendung erfordert i. d. R. einen serverseitigen Versand der Hits über das GA4MP. Mit ein wenig Code ist das in allen gängigen Sprachen machbar, denn am Ende des Tages muss nur eine Request per POST abgesetzt werden. Das geht faktisch überall. Schon in der Alpha Phase existieren bereits ein paar hilfreiche Bibliotheken von Charles Farina für TypeScript und Python. Auch ohne dies genügen i. d. R. ein paar Zeilen Code, um das GA4MP zu nutzen. Die Möglichkeit, diese durch Anpassung der URL zunächst an einen Validierungs-Server senden zu können, ist eine hilfreiche Angelegenheit in der Entwicklung eigener Lösungen. In diesem Video zeige ich den Einsatz mit ein paar Zeilen PHP Code:

Selbst die Beispiele, die man bisher mit dem alten GAMP betrieben hat (wie z. B. mein altes LifeLogging-Beispiel zum GAMP), sind bei Verwendung eines Endpunktes auf dem eigenen Server, der die alten eingehenden Trigger von IFTTT, Zapier oder was auch immer entgegennimmt, "übersetzt" und über das GA4MP weiterleitet, alle nach wie vor umsetzbar.

Dennoch gibt es Einschränkungen und Lücken, die (hoffentlich) zum großen Teil noch auf das Alpha-Stadium zurückzuführen sind. So kann man z. B. ein serverseitiges Tracking von Transaktionen im Rahmen einer ansonsten "normal" per client-seitigem Trackingcode erzeugten Sitzung durchaus umsetzen und der Kauf landet auch in der Sitzung des aktiven Benutzers, wenn man seine Id (aus dem _ga-Cookie) verwendet. Und auch das Stornieren von Transaktionen per nachträglichem Hit (wie hier beschrieben; der Beitrag enthält auch ein Update zu GA4) ist mit dem GA4MP ebenso möglich. Aber eine wesentliche Lücke bleibt (noch):

Measurement Protocol: Auch Websites vermessen?

Mit Universal Analytics war die Vermessung von Seitenaufrufen, Events, Transaktionen etc. gleichwertig zu "echten" Daten, die über den Trackingcode auf einer Website gesammelt wurden. Was bedeutet, dass man mehr oder weniger vollwertiges Tracking einer Website aufbauen konnte, ohne dabei den normalen client-seitigen Trackingcode zu nutzen.

Das Gleiche sollte theoretisch auch für Google Analytics 4 machbar sein. Ich bin mir auch sicher, dass es möglich ist... wenn nicht heute, dann sicher in Zukunft. Aber die derzeitigen Einschränkungen - vor allem in Form von nicht per GAMP zu versendenden Events und Parametern die nebenbei noch schlecht dokumentierten sind - verhindern derzeit offenbar das Erzeugen einer echten Sitzung mit Quelle, Nutzer und allem, was dazugehört.

Meint: Alle Events werden sauber in Analytics 4 empfangen und sind dort auch sichtbar. Will man aber eine Website vermessen, ist das nicht genug, denn es müssen vor allem eben Nutzer existieren und deren Nutzung muss sich in einer Quelle zuzuordnenden Sitzung widerspiegeln, wenn das Ganze einen Wert haben soll aus Sicht der Webanalyse. Zumindest mir ist dies bisher nicht gelungen und so sammelt meine Test-Property für GA4 dieser Website derzeit bei Zustimmung zum Tracking zwar fleißig über das GA4MP Seitenaufrufe, aber alles andere fehlt noch.

Das liegt vor allem (vermutlich) an den fehlenden automatisch generierten Events zur Nutzerbindung, dem Start einer Sitzung und normalerweise vorhandenen Parametern zur aktuellen Sitzung, deren Anzahl, Quelle, Medium und einigen anderen Dingen, die sich via GA4MP derzeit nicht nachbilden lassen. Was für echte Besucher zu wenig ist. Wer aber z. B. nur wissen will, welche Bots welche Seiten wann und wie oft aufrufen, kann auch mit GA4MP das auf GAMP ausgelegte Bot-Tracking nachbauen.

Allgemein zeigt sich das noch frühe Stadium an mehreren Stellen. So sendet der Event Builder (der übrigens auch Links zur Dokumentation der alten Universal-Version enthält, statt auf die passenden Dokumente für GA4 zu verlinken) zum Beispiel die client_id, die auch in einem Feld mit der Bezeichnung "client_id" eingegeben werden muss, als Parameter "clientId" in der JSON Nutzlast des ausgehenden Hits. Was verwirrend ist, zumal offenbar beide Schreibweisen sowohl erfolgreich validiert als auch an GA4 gesendet und dort verarbeitet werden können. Wichtige Events wie "page_view" sind nicht in ihren Parametern dokumentiert und können nur zum Teil im DebugView echter Hits (oder der BigQuery Datenstruktur) nachvollzogen werden. andere darf man schlichtweg nicht senden. E-Commerce ist noch relativ jung in GA4 und auch da muss man sich behelfen, wenn man die genaue Struktur kennen will. Oder man schaut bei Marcus Stade im Blog, wie er seine ersten Erfahrungen mit E-Commerce und dem GA4MP gemacht hat. Allgemein ist derzeit noch nicht sehr viel zum neuen Measurement Protocol zu lesen.

Es ist noch früh, aber schon jetzt nützlich

Die oben genannten Einschränkungen betreffen zum Glück viele bereits bestehende Anwendungsideen des GAMP auf Basis der alten Version nicht. Spätestens durch Zwischenschalten eines weiteren Schritts (und ein wenig Code) ist fast alles auch mit dem neuen Measurement Protocol auf Basis von Google Analytics 4 aufzubauen. Wenngleich es dort etwas mühselig ist, an die Eventparameter zu kommen, wenn man sich entsprechende Events selbst bauen möchte, die z. B. Daten von Google Fit in einer Analytics Property auswertbar machen sollen. Wer aber solche Dinge wirklich nachbaut, wird auch mit den Daten aus GA zurecht kommen oder sich in BigQuery behelfen 😉

Vor allem die Ergänzung bestehender Sitzungen durch serverseitig versendete Hits ist ein interessanter Ansatz, der schon jetzt möglich zu sein scheint und auch über Transaktionen hinaus seine Anwendungen finden wird. Ich bin jedenfalls gespannt, wie es weiter geht mit dem Google Analytics 4 Measurement Protocol... Folgebeiträge und Updates zu diesem Beitrag sind also nicht auszuschließen 😉