Markus Baersch

Analytics · Beratung · Lösungen

Start » Blog » GA4 / Measurement Protocol

28.06.2022

Mehr als ein Jahr nach meinem ersten Blick auf das Measurement Protocol für GA4 hat sich eine der größten damaligen Hürden bei der Verwendung für Websites inzwischen aufgelöst: Mit dem Schritt aus der Testphase sind nun Sitzungen (und User) zu erzeugen, wenn eine Session ID übergeben wird. Dazu gedacht, bestehende Sitzungen mit weiteren Hits zu ergänzen, ergibt sich damit endlich mehr als "nur Events" in GA4 bei ausschließlicher Nutzung des GA4 Measurement Protocols. Aber wie viel? Was fehlt im Vergleich zu einer vollständigen Implementierung mittels gtag.js im Browser? Auch wenn man es eigentlich nicht tun sollte - probieren schadet ja nichts...

Nicht für die alleinige Nutzung für Websites und Apps gedacht

Das Measurement Protocol für GA4 ("GA4 MP") ein komplett alternativer Weg zur Anlieferung von Daten. Bei Universal Analytics war das Measurement Protocol technisch deckungsgleich mit dem Weg, auf dem Daten aus dem Browser zu Analytics gelangt sind. Bei GA4 ist das aber anders. Wie Google an mehreren Stellen deutlich macht, soll damit keine vollständige "Server-to-Server" Vermessung von Websites mit GA4 stattfinden.

Ergänzung, nicht Ersatz für gtag

Das steht nicht nur direkt in der Einleitung der GA4 MP Hilfe, sondern man findet es schnell selbst heraus, wenn z. B. mit dem Event Builder probiert wird, Ereignisse wie einen Start einer Web-Sitzung (eines neuen Users) zu simulieren. Die dazu erforderlichen Events session_start und first_visit stehen (als automatisch vermessene Ereignisse in GA4) mit vielen anderen Events auf einer Liste reservierter Namen für Events, Parameter und User-Eigenschaften.  Auf der anderen Seite enthält die Auflistung von Ereignissen und deren Parameter, die für das Measurement Protocol verwendet werden können, nichts vom Seitenaufruf page_view.

Zusammen mit den explizit genannten Einschränkungen - kein Remarketing ohne User ID (IMHO leicht zu verkraften) und keine geografischen Informationen (schon blöder) ist wohl klar: Trotz der neu hinzugekommenen Option zur Übermittlung einer Session ID ist das Measurement Protocol bestenfalls eine sehr eingeschränkte Option, die nicht einfach wie der Vorgänger für Universal Analytics für eine 100% serverseitige Anbindung geeignet ist.

Und wenn man es trotzdem probiert?

Ich habe dennoch in einer zweiten GA4-Property mit dem Sammeln von Daten begonnen, um sowohl einen Vergleich der entstehenden Metriken beider Methoden zu haben, als auch die Lücken in den Dimensionen (nebst den daraus resultierenden Konsequenzen für die Nützlichkeit) finden zu können. Es ist nur ein Experiment, wie die Überschrift verrät. Gleichwohl ist es nicht vollkommen nutzlos, denn es gibt zahlreiche Setups, in denen zur Sammlung von Daten im Browser etwas anderes im Einsatz ist, aber trotzdem Daten zu Google Analytics fließen. Wie oben beschrieben ist das mit Universal unproblematisch, aber bei GA4 bleibt nur das GA4 MP, wenn man nichts "nachbauen" möchte, das wie gtag.js im Browser aussieht. Und wer will das schon? 😉

Setup

Über einen eigenen Endpunkt wurden auf einer Test-Website alle Events, die auch über den normalen Weg an GA4 gesendet werden und die gtag.js nicht "selbst" in Form von Enhanced Measurement und automatischen Events erhebt, parallel via Measurement Protocol an eine zusätzliche GA4 Test-Property übergeben. Die "normalen" gtag.js Hits werden nur über den eigenen Endpunkt (der vollständigen IP Adresse beraubt) weitergegeben.

Natürlich mag die Reihenfolge eine Rolle spielen, wenn der Tracking Endpunkt viel zu tun hat, aber davon abgesehen ist zumindest die Menge der an die Properties gesendeten vergleichbaren Events wie Seitenaufrufe, Element-Sichtbarkeit etc. theoretisch gleich. Es ist kein Consent Mode im Spiel, beide Trackings basieren auf dem gleichen eingehenden Datenstrom des serverseitigen Endpunkts und geben Daten nur bei Zustimmung weiter. Bots, die sich in die eine Messung schleichen, sollten daher auch die andere Methode betreffen. Zur Kontrolle existiert zudem eine Universal Analytics Property, die über den gleichen Endpunkt wie das GA4 MP versorgt wird.

Ein vergleichbares Setup wurde auf meiner eigenen Site (mit weniger Traffic) implementiert, um Unterschiede aufgrund der Last zu vermeiden, allerdings ist hier kein gtag.js im Browser im Spiel. Hier nutze ich eine BigQuery - Anbindung, um gesammelte Events und manuell gesendete Test-Events im Detail zu untersuchen.

Eine dritte Site mit deutlich mehr Traffic versorgt über einen server-side Google Tag Manager eine GA4 Property via Measurement Protocol mit Daten. Diese Anbindung wird parallel zu Universal Analytics und GA4 über den gleichen Tracking-Server betrieben, vom gleichen Datenstrom versorgt und umfasst nur Seitenaufrufe mit minimalen Event-Eigenschaften und einer konstanten Engagement Zeit (was in diesem Kontext irrelevant sein wird).

Measurement Protocol via ssGTM

Um einzelne Aspekte zu testen, wurde (m)eine GA4 Property zudem teilweise manuell mit Test-Events "beschossen", die aber zur Differenzierung in URL und Seitentiteln markiert werden, um sie aus Vergleichen auszuschließen.

Seitenaufrufe senden

Vereinfacht gesehen werden Seitenaufrufe genau so gesendet, wie es für alle anderen Events in der Hilfe dokumentiert ist und direkt im Event Builder erprobt werden kann. Nur sind die Parameter, welche hierüber für Seitenaufrufe (und andere Ereignisse) wirklich sinnvoll sind, leider nicht dokumentiert und müssen mühselig erprobt werden. Ein Minimal-Seitenaufruf mit einer zufälligen Client ID und neuen Session ID, um den Eintritt eines neuen Users zu simulieren, sieht in etwa so aus, wenn ein Referrer und eine URL der Seite nebst Titel übergeben werden:

Seitenaufruf via Measurement Protocol

Ein auf diese Weise gesendeter Hit ist sowohl in der Echtzeit sichtbar, als auch später (wie in der Hilfe beschrieben) in Reports. Durch die Angabe einer Session ID wird zudem der Akquisitionsbereich (anders als früher) mit Daten bestückt. Es ist zudem im Rahmen der gesetzten Limits für die Größe eines Requests möglich, mehrere Ereignisse zu bündeln und in einem Aufruf zu senden. Soweit, so gut.

Das ist alles anders

Wenn eine 100% Anbindung auf diese Weise vorgenommen wird, entstehen zwar wie in der Hilfe versprochen "echte" Sitzungen selbst ohne session_start Event, aber das bedeutet weder, dass dieses Event ersatzweise serverseitig erzeugt wird, noch entstehen andere wichtige Marker wie das o. a. first_visit Ereignis. Wie man vermuten kann, hat das zahlreiche Implikationen auf die Attribution und die schöne mehrstufige Zuordnung zu Kanälen, Quellen und Medien, die GA4 so vielseitig macht und das datengetriebene Standard-Attributionsmodell mit Daten füttert. Hier eine (nicht vollständige) Aufzählung aller Einschränkungen, die sich aus der Verwendung des GA4 MP ergeben.

Weniger Platz für Dimensionen (rly?)

Offenbar gibt es anders als bei gtag.js für das Senden von URLs wie der aktuellen Seite oder dem Referrer oder dem Seitentitel keine Ausnahme von der Regel, dass maximal 100 Zeichen verwendet werden müssen. Während also bei normaler Nutzung des Trackingcodes oder Tag Managers problemlos bis zu 300 Zeichen in diesen Feldern stehen dürfen, heißt es beim Measurement Protocol offiziell: Zu lang = doof. Zumindest in meinen Tests habe ich davon aber nichts gesehen.

Sowohl in Reports als auch in BigQuery finden sich auch längere URLs, wenn man es versucht. Hier einige Beispiele aus meinen Tests mit verschiedenen URL Parametern:

Lage URLs offenbar kein Problem

Andere Felder wie der Titel, in dem sich oft längere Angaben finden, scheinen nicht betroffen zu sein.

... und lange Titel auch nicht

Darauf sollte man sich aber vermutlich nicht einfach verlassen. Einem potenziellen Problem kann man wahlweise trotzdem durch generelles Kürzen des Hostnamens und / oder Verkürzung des Pfades begegnen.

Fehlende Quellinformationen "by design"

Es kommt leider nichts an Quellangaben in den dafür vorgesehenen Dimensionen an, wenn es um die Herkunft von Sitzungen geht.

  • Auch wenn Referrer und Parameter an URLs übertragen werden, findet keine Zuordnung von Quelle und Medium statt. Obschon die dazu erforderlichen Informationen "angeliefert" werden
  • Ebenso sieht es mit UTM-Parametern aus: Diese gehen spurlos an der Kanalzuordnung vorbei. Sie finden sich aber unverändert in den URLs wieder, die als page_location übergeben wurden
  • Andere Click-Identifier wie gclid, wbraid und gbraid verbleiben gleichsam in übergebenen URLs und finden sich in den Berichten wieder... auch wenn diese i. d. R. sehr lang sind und daher (siehe oben) nicht unbedingt zuverlässig dort landen, wo man sie haben will. Ist eine Verarbeitung geplant, bietet sich dazu eher eine Event-Eigenschaft an
  • Versuche, eine Anlieferung von Quelle und Medium anhand von Dimensionen campaign, source, medium etc. in verschiedenen Varianten herbeizuführen, scheitern ebenfalls - egal ob man neue User und Sessions via erstem Hit mit Verweisquellen oder anderen (im Channelgrouping bekannten und unbekannten) Angaben versehen möchte. Die Hits werden nicht ignoriert, aber die Angaben führen nicht zu Zuordnungen in GA4. Ich habe zumindest in meinen Tests erfolglos mehrere Varianten erprobt.

Daher sind (bisher) alle Session- und First User- Angaben mit „Direct“ bzw. in der Kanalgruppierung als „Unassigned“ gekennzeichnet, auch wenn vielleicht google.com oder andere als Referrer zu finden sind, die eine Einordung im organischen Traffic oder einer Verweisquelle erlauben würden. Als Ergebnis steht man - zumindest aus Sicht der Standardreports - ohne Quelleninformationen, Kanalgruppierung oder Nutzerquellen da.
Keine Attribution

Prinzipiell muss man in Reports in GA4 mit den Sitzungen, den anhand der Client IDs gezählten User und zugeordneten Events nebst der Verweildauer zufrieden sein. Und den Ereignis-Parametern und User-Properties, die es durchaus in die Daten schaffen, solange sie nicht mit den Listen der reservierten Namen kollidieren. Dazu gehört der im obigen Beispiel gesendeten Referrer - diese werden nur nicht zu Quellen ausgewertet, aber korrekt gespeichert. Zum Grund "spekuliere" ich am Ende dieses Beitrags.

Attribution "light"

Da aber viele Angaben nicht verloren gehen, sondern nur nicht zu anderen Dimensionen verarbeitet werden, kann man sich theoretisch auf den Referrer und die Landingpage verlassen, welche alle Parameter weiterhin beinhaltet, solange diese nicht doch (vielleicht auch erst in Zukunft) den genannten Längenbeschränkungen für Feldinhalte zum Opfer fallen Andere hilfreiche Infos wie selbst gesendete Quell und Medium-Informationen kann und sollte man zumindest im Hit selbst hinterlassen. Dazu können sowohl selbst definierten (z. B. "custom_source_medium") als auch Standard-Event-Eigenschaften ("medium" / "session" auf Eventlevel) dienen, wenn man diese in GA4-Reports (selbst definiert) oder BigQuery (dann geht auch Standard) sehen will.

In den Rohdaten, individuellen Reports zu Parametern der jeweiligen Ereignisse und in BigQuery finden sich die Angaben jeweils wieder und können mit entsprechendem Aufwand für eine Attribution im Selbstbau genutzt werden. Ein Beispiel:
Daten in BQ

Erfreulicherweise ist auch der "entrance" hier in den Daten verzeichnet, was bei entsprechenden Abfragen von Sitzungs-Starts ohne session_start Event sehr hilfreich ist. Die eigentlichen Felder für User oder Sitzungs-Quellen sind davon aber nicht betroffen und weisen auch in BQ stets "Direct" und "none" aus.
Keine Daten zur Traffic-Quelle in BQ

Daher kann man bei entsprechenden Abfragen eigentlich nur auf die Eintritts-Events zurückgreifen oder muss die Daten nachträglich in BQ direkt anreichern, um vergleichbare Auswertungen auf dieser Basis anstellen zu können, wie sie mit "vollwertigen" Daten möglich sind.

0% Engagement trotz Engagement-Time

Ohne die Fähigkeit, user_engagement an GA4 zu senden, ist ungeachtet der Option zur Übertragung der Interaktionsdauer auf Event-Ebene in der Eigenschaft engagement_time_msec keine Möglichkeit vorhanden, aus einer Sitzung eine "Engaged Session" zu machen. Das gelingt nur, wenn das GA4 MP wie vorgesehen nur im Kontext einer konventionell vermessenen Sitzung genutzt wird. Es reicht aber für Realtime und die gemessene Dauer im Kontext der Events.

Woher? Womit? Unbekannt!

Wie schon in der Hilfe steht, ist keine Option vorgesehen, geografische Angaben zu übertragen. Da keine IP gesendet werden kann (so sollte es auch sein) und angesichts der Natur des Measurement Protocols die IP des sendenden Servers irrelevant ist, fehlt es an allen damit verbundenen Dimensionen zum User-Standort. Ohne einen User Agent ist zudem nichts zur Technologie bekannt - weder Browser, noch Betriebssystem. Diese Dimensionen sind und bleiben bei dieser Methode (not set).

Selbst „eigentlich nicht“ reservierte Parameter wie language und screen_resolution funktionieren offenbar nicht, obschon bei den Ausnahmen nicht genannt und im Event Builder bei Erprobung kein Problem. Wenn sie hinzugefügt werden, erscheint in der Echtzeit aber nichts davon… und später findet sich nichts in den entsprechenden Dimensionen (wohl aber in BQ - es ist ein Parameter wie jeder andere auch). Wer diese Daten in GA4 Reports direkt einsehen will, sollte sich statt der Standardbenennung lieber mit abweichend benannten Event-Parametern behelfen.

Conversions? Generierte Events? Audiences?

Es gibt ohne gtag.js im Browser potenziell reichlich „Lücken“ im Tracking. Überall da, wo GA4 sich auf die Hilfe des Browsers bzw. gtag.js Tracking-Codes verlässt, fehlt es an Pendants im Measurement Protocol. Wenn also Dinge wie Conversions (jenseits des Kaufabschlusses, der per Default eine Conversion ist), Generierung von Events auf Basis anderer Events und Erzeugung von Zielgruppen etc. eigentlich im Browser stattfinden, muss Google die eingehenden Ereignisse via GA4 MP gesondert behandeln, wenn Daten entstehen sollen.

Die Messung von Conversions funktioniert, wenn die Definition nur auf Event Namen oder existierenden Parametern basiert. Das ist nur auf den ersten Blick eine Überraschung, denn dazu muss Google die Markierung der eingehenden Events als Conversion selbst übernehmen. Auf der anderen Seite sollte man dieses Verhalten aber erwarten dürfen, denn wenn das GA4 MP im gedachten Sinn und Zusammenspiel mit einer regulären Session eingesetzt wird, muss es möglich sein, hierüber Conversion-Ereignisse auszulösen.

Auch ohne Definition von Conversions ist zudem E-Commerce - wie zu erwarten war - komplett abgedeckt. Werden Purchase Events gesendet, werden diese ebenso wie alle anderen E-Commerce Ereignisse erwartungskonform verarbeitet und bevölkern neben Conversions auch E-Commerce-Reports.

E-Commerce funktioniert

Sowohl in GA4, als auch BigQuery gibt es hier außer den bereits genannten Einschränkungen nichts, was GA4 MP purchase Events von anderen unterscheidet. Die Angaben unter ecommerce, items und den event_properties sind vollständig vorhanden.

Während Zielgruppen i. d. R. auf Dimensionen basieren, die nicht verfügbar sind (wie die Quelle etc.), habe ich es mit einer Zielgruppe basierend auf einem Ereignis versucht. Hauptsächlich um zu sehen, ob hier überhaupt etwas passiert, denn ohne Cookies ist der Wert (wenngleich nicht Null) doch begrenzt für Marketingzwecke. In der Übersicht finden sich in GA4 auch tatsächlich Daten zu dieser Zielgruppe mit Users und Conversions (aber eben ohne Engagement).

Nach diesen Ergebnissen wäre zu erwarten, dass auch Events, die in GA4 auf Basis anderer Ereignisse definiert werden, auf gleiche Weise bei Einsatz des Measurement Protocols entstehen. Das ist aber offenbar (zumindest derzeit) nicht der Fall. Ob sich hier noch etwas ändert oder darauf gebaut wird, dass ersatzweise alle erforderlichen Events direkt serverseitig gesendet werden, darf jeder selbst entscheiden.

Wie sieht es bei Apps-Streams aus? Das kann ich (noch) nicht sagen, aber wer sich ein Bild machen mag, findet ein Code Lab für die Anbindung einer App via Measurement Protocol, das sicher einen guten Einstieg erlaubt. Da die App-Vermessung mit Firebase und die Nutzung der Daten für Marketing-Zwecke ebenso wie bei Web-Datenstreams stark von automatischen Ereignissen abhängig ist, wird es auch hier eine Menge Kröten zu schlucken geben - aber auch da sind nicht alle Events "verboten" und so mag ein ähnlich unvollständiges Bild entstehen, das dennoch seinen Nutzen hat.

New Users = Null. Eigentlich unnötig(?)

Es kann via GA4 MP nicht nur kein session_start gesendet werden, sondern auch kein first_visit. Während jedoch inzwischen Sitzungen entstehen, bedeutet "kein First Visit = keine New Users". Selbst wenn man konsistente Client IDs einsetzt. Daher bleibt der User Acquisition Report leer und summiert alle Events und andere Kennzahlen in einer Zeile, die "Direct" zugeordnet ist und 0 New Users, Sessions oder Engagement aufweist. Wie überall sieht man aber die Engagement Time und Anzahl der Events.

Keine New Users - warum eigentlich?

Muss das so sein? Ich würde meinen "Nein". Denn wenn sich Google entschließt, die Verarbeitung der GA4 MP Ereignisse serverseitig anzupassen, könnte das ganz anders aussehen und es sollte (vielleicht anders als im Fall von Identifiern in URLs und Quelleninformationen) keinerlei echte Auswirkungen auf den Datenschutz haben. Segmentiert man Daten bei wenig Traffic und dem Wissen, dass es nur einen neuen User an einem Tag gab, findet man kaum etwas, was nicht auch URLs verraten könnten, würde ich meinen. Zudem stehen die Daten (genau wie beim Referrer etc.) dennoch in den Rohdaten zur Verfügung und man kann die jeweilige Information (wiederkehrend oder neu, Verweisquelle etc.) wieder selbst daraus extrahieren.

Noch eigenartiger wird es, wenn man neben einer session_id versuchsweise auch eine session_number einsendet, so wie es beim Web Tracking auch der Fall ist. Erstaunlicherweise werden beide Parameter offenbar "sonderbehandelt". Das ist sogar in GA4 Reports bei der (nur bedingt hilfreichen) Ansicht aktuell gesendeter Parameter zu sehen.

Auch Session Number funktioniert

Da spätestens hiermit auch ohne Nachschlagen in bestehenden Daten klar sein sollte, ob es sich um einen schon bekannte Client ID handelt oder nicht, wäre eine Differenzierung zwischen neu und wiederkehrend jedenfalls kein Hexenwerk mehr. Die Parameter finden ich auch in BigQuery unter den bekannten Keys mit vorangestelltem _ga wieder - für alle dortigen Auswertungen eine gute Nachricht.

Sitzungseigenschaften an bekannter Stelle in BQ

Parameter nutzlos oder fehlen (noch)

Selbst Parameter, die im Measurement Protocol explizit vorgesehen sind, haben bei einer 100% Vermessung ohne gtag.js keinen Zweck. So ist die Angabe von non_personalized_ads: true in Ereignissen bei dieser Einsazform unnötig, wenn es ohnehin keine Form der Anbindung des Browsers gibt und keine Cookies (und keine User ID, sonst fällt das Urteil anders aus) etc. im Spiel sind.

Die Angabe eines Zeitpunkts eines Events über timestamp_micros ist ebenfalls nur da einzusetzen, wo Ereignisse tatsächlich in eine vorher bereits vermessene Sitzung im Rahmen des gegebenen Limits (immerhin ganze drei Tage!) nachträglich eingefügt werden sollen. Wer beim "Web-Tracking light" via 100& GA4 MP aktuelle Zeitstempel angibt, erzielt keinen Vorteil, sondern entzieht sich nur der Möglichkeit, die Ereignisse in Echtzeit zu betrachten. Schlussendlich ist es mir ebenso nicht gelungen, mit dem debug_mode Parameter dafür zu sorgen, dass Ergebnisse von Tests direkt im DebugView von GA4 kontrollierbar werden. Das mag damit erklärbar sein, dass kein Gerät identifiziert werden kann und DebugView daher nicht handlungsfähig ist... der Wunsch nach einer Kontrollmöglichkeit auf Empfängerseite bleibt damit unerfüllt.

Lichtblick User Properties

Nach allen Einschränkungen mag man es nicht glauben, aber: Eigenschaften auf Nutzer-Ebene werden genau so verarbeitet, wie es im Normalfall passiert. Ist eine Property belegt, gilt sie von da an (nicht rückwirkend) für alle anderen Events, die von dieser Client ID angeliefert werden. Auch sitzungsübergreifend. Da diese Verarbeitung ohnehin für alle Hits erforderlich ist, macht Google beim Measurement Protocol keine Ausnahme. Die folgende Abbildung zeigt die selbst definierte User-Eigenschaft "User Bot Score" mit drei unterschiedlichen Werten aus 3 Tests:

  • "OK" wurde im ersten Hit einer Sitzung mit 3 Aufrufen gesendet und findet sich bei allen drei Aufrufen (P1-P3 im Titel) wieder
  • Der "OK2" - Test ist auch eine Sitzung mit 3 Hits, die Eigenschaft wurde beim zweiten gesetzt und besteht von da an
  • "OK3" stammt aus dem ersten Hit einer ersten Sitzung mit zwei Seiten und einer zweiten Sitzung mit 3 Seiten

User Properties im Report

Das würde mit gtag.js aus dem Browser (m. E.) nicht anders aussehen. Auch die user_properties in den GA4-BigQuery-Daten sind erwartungsgemäß befüllt. Damit lässt sich je nach Einsatzzweck einiges anfangen. Sobald es in GA4 auch Session- und Produktlevel für Dimensionen gibt, ist ein vergleichbares Verhalten zu erwarten.

Warum sind die Daten so, wie sie sind?

Mir fallen drei mögliche Gründe ein, warum durchaus verfügbare Daten nicht in die Reports einfließen, wie man es vielleicht erwarten mag. Welcher der drei Gründe mit welchem Gewicht zur aktuellen Situation der Verarbeitung und Nützlichkeit der Daten beiträgt, kann ich nicht beurteilen. Trotzdem bin ich aus allen drei Gründen skeptisch, dass sich noch viel tun wird. Vielleicht können wir in Zukunft noch weitere Eigenschaften anliefern, die eine Auswirkung auf den Umfang der GA4 Reports haben, aber einen umfangreicheren Ersatz für echtes Tracking im Browser erwarte ich persönlich nicht. Und zwar deshalb:

  • Datenschutz: Wenngleich es nur ein sehr geringer (eigentlich nur optischer) Unterschied für den Datenschutz ist, ob Informationen wie z. B. der Status eines Users (neu oder wiederkehrend) im GA4 User Interface dargestellt werden oder "nur" in den Rohdaten schlummern, die gesendet und bei Google gespeichert wurden, weist z. B. die aktive Entfernung von Identifiern aus URLs m. E. deutlich darauf hin, dass man sich aus der Schusslinie halten will. Wer also "reine Measurement Protocol" Daten in GA4 betrachtet, sieht dort wie beschrieben nichts von Quellen, Medien, Besuchergewinnung oder -status etc. Das ändert aber nichts daran, dass die Information existiert. Weil ich bei diesen Themen nicht wirklich sattelfest bin, habe ich mich zu den Implikationen mit Dr. DSGVO Klaus Meffert ausgetauscht. Das Ergebnis bestätigt die obige Einschätzung, dass die Verwendung wiederkehrender Client IDs beim Anliefern von Daten ungeachtet des Transportwegs den gleichen Regeln unterworfen ist, wie es auch bei Einsatz normalen GA4 Trackings im Browser der Fall ist. Da ebenso der Empfänger der Daten gleich bleibt, würde ein "anonymes" Tracking via GA4 MP (von der IP Adresse und ein paar anderen Kritikpunkten abgesehen) je nach Perspektive immer noch (gleich) problematisch sein. Es ist immer noch Google, es ist immer noch unsicheres Drittland und so weiter. Während Datenschutz also immer noch ein großes Thema bleibt, wird es kaum der Treiber dafür sein, dass die Reports sind, wie sie sind. Was nicht bedeutet, dass man alle Dimensionen, die per GA4 MP angeliefert werden, nicht trotzdem genauso unter Datenschutz-Gesichtspunkten betrachten muss, wie es bei allen anderen Transportmechanismen der Fall ist. GA4 MP = serverside = entkoppelt. Zumindest in der Regel. Das löst aber nicht alle Probleme.
  • Strategie: Schon wahrscheinlicher ist die Tatsache, dass ein Verschwinden von gtag.js aus dem Browser nicht zu dem passt, was Google damit geplant hat. Die Beförderung zum "Google Tag" steht unmittelbar bevor und gtag.js soll mehr Fähigkeiten und Flexibilität bekommen. Einen bis zu einem gewissen Punkt gleichwertigen alternativen Weg zu Anlieferung von Daten anzubieten, wäre daher kontraproduktiv. Wie eingangs erwähnt war das GA4 MP nie als Ersatz geplant - weder für alle Einsatzzwecke seines Vorgängers für Universal Analytics, noch für gtag.js.
  • Ressourcen: Hier mag der Hauptgrund liegen, warum alles, was nicht direkt mit den Hits angeliefert werden kann, sondern ein Processing der Daten erfordert, nicht Teil der Reports ist, sondern nur in den Rohdaten schlummert. Wer normales Tracking mit gtag.js betreibt, überlässt dem Browser sehr viel Kontrolle. Ist es ein neuer User, wann hat die Sitzung begonnen, die wievielte ist es, was ist eine Conversion... das alles steuert im Normalfall der Browser und GA4 muss sich nicht darum kümmern. Solange das so bleibt (wer weiß), wird auch beim Measurement Protocol keine weitere serverseitige Verarbeitung stattfinden...  jedenfalls über das hinaus, was oben bereits beschrieben ist. Vermutlich schon gar nicht, um nur für GA4 MP Sitzungen bessere Reports zu generieren. Alle derzeit existierenden Sonderverarbeitungen dienen der Konsistenz von durch GA4 MP ergänzte und regulär vermessene Sessions. Nicht vergessen: Solange die MP Events im Rahmen einer bestehenden Sitzung stattfinden, sind sie voll in diese integriert und mehr oder minder gleichwertig zu den sonstigen Events, die aus dem Browser stammen.

Daher gehe ich davon aus, dass wesentliche Änderungen nur dann zu erwarten sind, wenn diese evtl. generell für GA4 Datenverarbeitung auf Google-Seite erforderlich werden.

Vergleichbarkeit der Methoden

Trotz aller Bemühungen um ein Setup, in dem möglichst alle Ursachen für Unterschiede in der Versorgung der jeweiligen Properties (GA4 Web, Universal serverside, GA4 MP) mit Daten habe ich keine finale Antwort auf die Frage, ob die Daten quantitativ vergleichbar sind zwischen den verschiedenen Wegen.

Während in UA, GA4 Web und GA4 MP zwingend Unterschiede in den Zuordnungen zu Dimensionen - speziell Sitzungen und User - zu erwarten sind, sollten einige Metriken übereinstimmen. Da sind z. B.

  • die Seitenaufrufe in Summe oder für einzelne Seiten
  • Anzahl der Events, die vergleichbar an GA4 auf zwei verschiedenen Wegen gesendet werden (abgesehen vom page_view)
  • Bei übereinstimmenden Sitzungs-IDs auch die Anzahl der Sitzungen zwischen beiden GA4 Varianten; nicht aber im Vergleich zu Universal

Bei den beiden Kandidaten, die serverseitig mit "Custom Code" angebunden wurden, sind die Zahlen für das Measurement Protocol stets zu niedrig gewesen im Vergleich zu GA4 Web oder Universal server-side. Auch in der Echtzeit konnte man im Vergleich von GA4 zu GA4 für unterschiedliche Methoden fast immer beobachten, dass die Anzahl der Nutzer und Seitenaufrufe bei der GA4 MP Variante niedriger war. Die Ergebnisse zeigen ähnliches Verhalten in beiden Test Setups und diese haben sich auch nicht dadurch geändert, dass die Reihenfolge der ausgehenden Requests verändert wurde. Logging zeigte stets einen parallelen ausgehenden Versand der Ereignisse. Ob nun aber das Problem wirklich auf Empfängerseite liegt oder nicht, kann damit nicht sicher bestimmt werden.

Denkbar ist es, dass ein Teil der Ereignisse verworfen wurde, weil diese aus Sicht des Measurement Protocols nicht valide waren. Da aber auch auf Ebene gleicher URLs z. T. deutliche und im Trend überall zu beobachtende Differenzen zum Nachteil der GA4 MP Anbindung gibt, erscheint diese Erklärung unwahrscheinlich.

Die per ssGTM angebundene Test-Property hingegen hat über mehrere Tage im Test besser vergleichbare Ergebnisse erzielt. Hier ein Vergleich zwischen beiden GA4 Versionen für zwei aufeinanderfolgende Tage mit (hoffentlich) ausreichend Abstand zur Betrachtung von mehr als 72 Stunden:

Vergleich der Kennzahlen aus beiden Methoden

  • Die Seitenaufrufe passen gut mit marginalen Ausnahmen, solange man auf Seitenebene vergleicht. In der Top-Liste der Seiten sind nur die beiden vorletzten Einträge (gelb im unkenntlich gemachten Titel markiert) aufgrund der niedrigen Fallzahlen vertauscht, aber sonst stimmt das Bild
    • Etwas anders ist es bei den Aufrufen in Summe. Warum die Gesamtzahl der Seitenaufrufe Differenzen aufweist, ist nicht direkt erklärbar und es ist auch nicht an allen Tagen des Tests gleich stark zu beobachten. Liegt das Problem wie in den beiden anderen Tests vermutlich eher auf der Sender-Seite, bin ich mir hier nicht so sicher, ob nicht doch der Empfänger den Unterschied generiert. Vielleicht bei der Verarbeitung? Da es hier wie in den anderen Tests Seiten betrifft, bei denen Unterschiede in der Zusammenstellung der Eigenschaften eher unwahrscheinlich sind, gibt es keinen offensichtlichen Grund. Der Tracking-Server selbst scheint mit der Last des zusätzlichen Tags lt. Logs nicht überstrapaziert, solange der Test aktiv war
  • Daten zu Engagement fehlen und die Dauer ist aufgrund des Setups nicht vergleichbar (siehe oben)
  • Wie beschrieben gibt es nichts zu Neu vs. Wiederkehrend, aber auch das war zu erwarten
  • Weniger Sitzungen und Nutzer? Da nicht alle Events vermessen wurden, dürfen auch Differenzen bei "Total users" oder "Sessions" entstehen. Aber in diesem Umfang? Dazu müsste der Test vermutlich wiederholt werden... ich kann mir aber bei der Natur der Site kaum denken, dass es so viele Sitzungen geben soll, die keine Seitenaufrufe beinhalten und die Session-ID, welche die eine Property bekommen hat, stimmte mit der anderen überein; dito die Client-IDs

Ich muss dennoch davon ausgehen, dass die o. g. Differenzen der beiden anderen Tests hausgemacht sind und vermutlich nicht für ein generelles Problem stehen. Ich erwähne es dennoch in diesem Beitrag, weil es eine Vielzahl von verschiedenen Wegen zur Anbindung gibt und wenn bei meinen Tests zweieinhalb von drei auf verschiedene Weise unzuverlässig erscheinen, ist das ein gewisser Indikator dafür, dass man gut bedient ist, die eigene Implementierung genau zu prüfen und zu vergleichen, auch wenn alles prinzipiell zu funktionieren scheint. Da die Test Setups nicht technisch gleich, sondern durchaus unterschiedlich auf- und umgesetzt sind, glaube ich auch nicht mehr an einen systematischen Fehler, der alle auf die gleiche Weise betrifft.

So oder so ist aber zu bedenken, dass ein selbst betriebener Endpunkt, der bisher nur das recht anspruchslose Universal Analytics Measurement Protocol bedient hat, bei einer Umstellung ggf. mehr zu tun bekommt und evtl. schlichtweg die Last das Problem in meinen Tests war, denn beide Tracking-Server der anderen beiden Tests waren im Gegensatz zur ssGTM Variante nicht skalierbar.

Fazit: Ist das Ganze also nutzlos?

Nein, natürlich nicht. Wer wirklich nur sehen will, welche Ereignisse von wie vielen Usern in wie vielen Sitzungen erzeugt wurden, kann mit den so erhobenen Daten durchaus arbeiten. In Standard Reports finden sich rudimentäre Daten und im Erkunden-Bereich kann auf eine Menge an Eigenschaften zugegriffen werden. Die Verfügbarkeit in BigQuery erlaubt weitere Analysen und bringt in gewisser Weise die Möglichkeit der Attribution zurück - wobei man sich fragen muss, warum man dann nicht gleich alle Events von der Quelle aus über eine leichtgewichtige Cloud Function direkt in BigQuery versenkt und sich den Umweg über GA4 und das Measurement Protocol spart.

Aus einer anderen Perspektive betrachtet bleibt allerdings sehr viel von dem auf der Strecke, was GA4 auszeichnet. Es sollte also entweder einen guten Grund geben oder nur sehr begrenzte Anforderungen an die Daten bestehen, um diesen Weg zu gehen, statt sich der üblichen Tagging-Optionen zu bedienen oder zur Not das Request-Format von GA4 nachzubauen.

Als Ausweg aus der Consent-Falle eignet sich das Measurement Protocol ebenfalls nur bedingt, denn man sendet Daten immer noch an Google und muss sich daher selbst bei einem begrenzten Satz an Dingen, die an GA gesendet werden können, immer noch an die Regeln halten. Für "Basteleien" und alles jenseits von Websites (und Apps) hingegen ist das Measurement Protocol eine gute Wahl.

Die Funktionalität hat sich allerdings in den fast anderthalb Jahren seit dem ersten Blick kaum gewandelt und es bleibt "per Design" ein Weg, bestehende auf normalem Weg vermessene Web Sessions zu ergänzen und nicht die Vermessungsmethode im Browser komplett zu ersetzen.

Hat Dir der Beitrag geholfen?

Dann freue ich mich, wenn Du ihn mit anderen teilst! Wenn Du magst, gib einen aus ;)

© 2001 - 2024 Markus Baersch