Skip to content

Digital Analytics Blog

von Marcus Stade

Menu
Menu
ga4_recipes_mpschema_web

Google Analytics 4 Recipes: Measurement Protocol

Posted on 23. Dezember 202028. Dezember 2020 by mstade

Bei einem Umstieg (oder paralleler Implementierung) auf Google Analytics 4 wird bei einigen Implementierungen auch ein Umstieg (oder Ergänzung) auf das Measurement Protocols von Google Analytics 4 anstehen. Dabei ist das GA4 Measurement Protocol noch im Alpha Status und beinhaltet eine deutliche Änderungen gegenüber Universal Analytics. (Stand 22.12.2020)

Was ist das Measurement Protocol und wofür brauche ich es?

Das Measurement Protocol definiert, wie ein Request an den Google Analytics Server zusammengesetzt ist und welche Informationen vorhanden sein sollten und können, so dass diese Informationen von Google Analytics korrekt interpretiert werden können. Also jeder Request, der an den Google Analytics Server rausgeht, egal ob durch ein Tag im Google Tag Manager oder hardcoded im HTML, formt die zu sendenden Informationen entsprechend dem Measurement Protocol um. Hier ein Beispiel eines Pageview-Tags für Universal Analytics:

https://www.google-analytics.com/collect?v=1&_v=j87&aip=1&a=223002784&t=pageview&_s=1&dl=https%3A%2F%test.de%2F&ul=de-de&de=UTF-8&dt=Test&sd=24-bit&sr=1920x1080&vp=977x937&je=0&_u=QACAAEAB~&jid=&gjid=&cid=1098310274.1597920143&tid=1234567&_gid=279826990.1607867870&gtm=2wgbu0NQP78LZ&z=581560256

(Zum Ausprobieren, einfach den Wert “tid=1234567” durch die eigene Universal Analytics ID ersetzen und im Browser aufrufen. Im Google Analytics Realtime View wird dann der Hit sichtbar)

Ergebnis des Requests im Browser:

ga4_recipes-measurementprotocal_testhit

Ergebnis des Requests in Unversal Analytics:

ga4_recipes-measurementprotocal_testhit_ga

Dieser Request beinhaltet unter anderem folgende Informationen:

ParameterBeschreibung
https://www.google-analytics.com/collect?Server von Google Analytics
v=1Universal Analytics Format
aip=1IP Anonymisierung ist true
t=pageviewEvent Type ist pageview
dl=https%3A%2F%test.de%2FLocation (URL)
ul=de-deSprache des Users
dt=TestTitel des Dokuments
sd=24-bitFarbtiefe des Monitors
sr=1920×1080Auflösung des Monitors
vp=977×937Größe des Viewports
cid=1098310274.1597920143ClientId des Users über die die verschiedenen Hits zu einem User zugeordnet werden
tid=1234567Universal Analytics Property
z=581560256Cache Buster

Vollständige Referenz für Universal Analytics:

https://developers.google.com/analytics/devguides/collection/protocol/v1/parameters

Im Browser und in einer App reicht meist die Integration des Tags oder SDKs für das Tracking. Allerdings gibt es auch Fälle, in denen das entweder nicht möglich ist, oder das zu trackende Geräte zwar internetfähig ist, aber dort weder Web-Tags noch App-SDKs eingesetzt werden können, beispielsweise Spielekonsolen oder Kassensysteme. Ein weiterer Anwendungsbereich ist auch eine serverseitige Integration von Google Analytics. 

Hierfür kann dann direkt der Request an Google Analytics entsprechend dem Measurement Protocol zusammengebaut und versendet werden.

GA4 und Measurement Protocol

Google Analytics 4 kommt mit einem völlig überarbeiteten Measurement Protocol Format und einigen neuen Features. Zum aktuellen Zeitpunkt ist das Measurement Protocol für Google Analytics 4 noch im Alpha-Stadium und kann sich noch stark ändern. Dennoch lohnt es sich bereits ein Blick darauf. Die Google Analytics 4 Variante des Measurement Protocol identifiziert sich im Request durch die Angabe v=2 (Universal Analytics: v=1)

Zu den wichtigsten Änderungen zählen:

  • Für Request an den Google Analytics Server dürfen nur noch POST Requests verwendet werden. In der Version von Universal Analytics waren auch GET-Request erlaubt, wie im oben gezeigten Beispiel.
  • Da Google Analytics 4 für App und Web gedacht ist, existiert sowohl für Apps (Firebase) als auch für Web eine Version des Measurement Protocols.
  • Wird in Universe Analytics Requests akzeptiert, ohne das eine weitere Prüfung auf Spam Traffic etc. stattfindet, wird in Google Analytics 4 ein API Key Secret verwendet, so dass alle Request mit fehlendem oder falschen API Key Secrets nicht verarbeitet werden.
  • Zur Validierung der Request an den Google Analytics Server steht nun erstmals ein Validierungsserver zu Verfügung, mit dem sich einige Fehler im beim Aufbau des Requests besser finden lassen. Den aus Universal Analytics bekannten Hit Builder gibt es auch für GA4, den Event Builder.
  • Die Unterscheidung zwischen Pageviews, Events, etc. als Hit Type verschwindet und es gibt nur noch Events
  • Es können mehrere Events pro Request übermittelt werden

Erstellen des Measurement Protocol API Key Secrets

Die Google Analytics 4 Measurement Protocol API Key Secrets werden auf Data Stream Ebene erstellt. Das heißt, für jede eingehende Datenquelle ist ein gesonderter API Key Secret erforderlich und nicht alle Datenquellen müssen immer für das Measurement Protocol freigeschaltet werden. Um das API Key Secret zu erstellen, gehen wir in den Data Stream  hinein und klicken auf  API Key Secret und erstellen einen Key für diesen Data Stream. Das Vorgehen ist für App und Web gleich.

ga4_recipes_mp_api_secret
ga4_recipes_mp_api_secret_value

GA 4 Measurement Protocol für Web

Für das Measurement Protocol für Web sieht folgende Struktur vor:

ga4_recipes_mpschema_web

Wie oben beschrieben, gibt es nun für das Measurement Protocol zwei mögliche Serveradresse:

https://www.google-analytics.com/mp/collectEndpoint für produktives Tracking
(im folgenden Measurement Protocol Server genannt)
https://www.google-analytics.com/debug/mp/collectEndpoint für Validierungsserver

Da sich die Komplexität des Measurement Protocol Requests in GA4 erhöht, ist die Verfügbarkeit eines Validierungsserver, mit dem ein Requests getestet werden kann, sehr hilfreich, auch wenn nur sieben verschiedene Validation Error Codes zur Verfügung stehen.

Die Measurement ID und den API Secret Key werden als Query Parameter mitgesendet, alle andere anderen Informationen befinden sich als JSON im BODY des Request.

Bauen wir nun verschiedene Hits für GA4 zusammen und schicken diese zum Validation-Server:

Request für ein einzelnes Event

Wir senden ein Event mit dem Namen “sessionstart” an den Validation Server. Hierfür nutze ich die Console im Browser, sende den Request mit Javascript und gebe die Antwort des Servers aus:

fetch(`https://www.google-analytics.com/debug/mp/collect?measurement_id=G-0WPD6V5EKJ&api_secret=bq-et0s9SVWiwScjvJckAw`, {
  method: "POST",
  body: JSON.stringify({
    client_id: '123.123',
    events: [{
      name: 'sessionstart',
      params: {},
    }]
  })
}).then(response => response.json())
  .then(data => console.log(data));
ga4_recipes_singleevent_validation

Die Ziel-URL ist: https://www.google-analytics.com/debug/mp/collect?measurement_id=G-0WPD6V5EKJ&api_secret=bq-et0s9SVWiwScjvJckAw

Das JSON im Detail:

Wie bei Universal Analytics erfolgt die Identifikation des Clients über die ClientId (client_id). Optional kann für das Cross-Device Tracking eine UserId (user_id) übergeben werden. Diese ersetzt allerdings nicht die ClientId. Die ClientId kann über die üblichen Methoden (gtag(‚get‘) oder CustomTask) ausgelesen werden.

Zudem kann ein Timestamp mitgesendet werden, der das Event einen Zeitpunkt bis zu 48 Stunden in der Vergangenheit zuordnen kann. Zudem kann ein boolean Wert mit einem Event mit gesendet werden, der in Google Analytics 4 als Indikator genutzt wird, ob für einen User personalisierte Anzeigen verwendet werden dürfen oder nicht.

Events werden in einem Array übergeben. Das bedeutet, dass im Measurement Protocol für Google Analytics 4 mehrere Events in einem Hit übergeben werden können. Jedes Array-Element enthält ein JSON, das den Event Namen und die Event-Parameter enthält. Event Parameter werden in einem späteren Beispiel übergeben, daher sind diese hier leer.

Das sollte bei Events und im JSON Body beachten werden:

  • Event Namen dürfen höchsten 40 Zeichen umfassen. Erlaubt sind alphanumerische Werte (Buchstaben und Ziffern) sowie Unterstriche “_”
  • Events dürfen jedoch nicht mit einem “_”, “google_”, “ga_” oder “firebase_” beginnen
  • Reservierte Eventnamen (=Namen von automatisch erfassten Events) dürfen nicht verwendet werden (Liste: https://developers.google.com/analytics/devguides/collection/protocol/ga4/reference?client_type=gtag#reserved_names)
  • Jeder Request darf höchstens 25 Events erhalten
  • Der Body des Post-Requests muss kleiner sein als 130 kb

Sehen wir uns das Event im Network-Tab an:

Alle Daten sind korrekt im Request enthalten. Die Validierung liefert ein leeres Array “validationMessages” zurück. Das heißt, der Request wurde akzeptiert. Ändern wir nun das Ziel des Requests auf den Measurement Protocol Server:

fetch(`https://www.google-analytics.com/mp/collect?measurement_id=G-0WPD6V5EKJ&api_secret=bq-et0s9SVWiwScjvJckAw`, {
  method: "POST",
  body: JSON.stringify({
    client_id: '123.123', user_id:'1',
    events: [{
      name: 'sessionstart'
    }]
  })
}).then(response => response.json())
  .then(data => console.log(data));
ga4_recipes_singleevent_server

erscheint das Event im GA4 Interface:

ga4_recipes_singleevent_interface

Das validationMessages Array des Requests

Um zu verstehen, wie das validationMessages Array, das ein Request an den Validierungsserver zurückliefert, zu verstehen, senden wir nun ein fehlerhaftes Event an den Validierungsserver. Der nachfolgende Request enthält den reservierten Eventnamen “session_start”:

fetch(`https://www.google-analytics.com/debug/mp/collect?measurement_id=G-0WPD6V5EKJ&api_secret=bq-et0s9SVWiwScjvJckAw`, {
  method: "POST",
  body: JSON.stringify({
    client_id: '123.123', 
    events: [{
      name: 'session_start'
    }]
  })
}).then(response => response.json())
  .then(data => console.log(data));
ga4_recipes_singleevent_validation_array

Der Validierungsserver liefert nun im validationMessages Array ein Element im JSON Format zurück, das den Fehlercode (validationCode), das Feld auf das sich der Fehler bezieht (fieldPath) und eine Beschreibung des Fehlers (description) enthält. Der Validierungsserver prüft lediglich den Aufbau, reservierte Namen, erwartete Felder, etc., allerdings nicht alle Fehler. Dennoch ist eine Validierung sinnvoll.

ga4_recipes_singleevent_validation_array_reserved

Derezeit gibt es lediglich sieben mögliche Validierungscodes, sofern der Validierungsserver einen Fehler zurückgibt:

Error MessageBeschreibung
VALUE_INVALIDEin Wert entspricht nicht der Definition
VALUE_REQUIREDEin erwarteter Wert fehlt
NAME_INVALIDEin verwendeter Key ist nicht korrekt
NAME_RESERVEDEin verwendeter Key darf nicht verwendet werdet, da bereits von GA4 reserviert
VALUE_OUT_OF_BOUNDSDier Wert des Key ist zu groß
EXCEEDED_MAX_ENTITIESZuviele Parameter im Request
NAME_DUPLICATEDDuplikate vorhanden

Hinweis: Zum Stand des Beitrags konnten nicht alle Fehlermeldungen hergestellt werden.

Mehrere Events in einem Request

Im Gegensatz zum Measurement Protocol von Universal Analytics besteht beim GA4 Measurement Protocol die Möglichkeit, mehrere Events (maximal 25) mit einem Request zu senden. Das Konstruieren des Requests ist einfach. Den vorherigen Request wird ein zweites Element im Array hinzugefügt:

fetch(`https://www.google-analytics.com/debug/mp/collect?measurement_id=G-0WPD6V5EKJ&api_secret=bq-et0s9SVWiwScjvJckAw`, {
  method: "POST",
  body: JSON.stringify({
    client_id: '123.123', 
    events: [{
      name: 'session_start'
    },{
      name: 'sessionstart_2'
    }]
  })
}).then(response => response.json())
  .then(data => console.log(data));
ga4_recipes_multipleevent_validation

Senden wir dies an den Validationserver, wird ein leeres Array als Antwort zurückgegeben, insofern ist der Hit valide.

ga4_recipes_multipleevent_validation_array

Sehen wir uns den Hit im Network-Tab an, sehen wir das zwei Events mit einem Request versendet wurden:

ga4_recipes_multipleevent_server

Senden wir nun den Request an den Measurement Protocol Server, werden beide Events  auch im GA4 Interface angezeigt:

ga4_recipes_multipleevent_interface

Das validationMessages Array bei Request mit mehr als einem Event

Ersetzen wir nun den ersten Eventnamen durch den reservierten Namen “session_start” und senden die Daten an den Validierungsserver, erhalten wir wieder die erwartete Antwort:

fetch(`https://www.google-analytics.com/debug/mp/collect?measurement_id=G-0WPD6V5EKJ&api_secret=bq-et0s9SVWiwScjvJckAw`, {
  method: "POST",
  body: JSON.stringify({
    client_id: '123.123', 
    events: [{
      name: 'session_start'
    },{
      name: 'screen_view'
    }]
  })
}).then(response => response.json())
  .then(data => console.log(data));
ga4_recipes_multipleevent_validation_array_reserved

Ein Array-Element, das uns darauf hinweist, dass “session_start” nicht verwendet werden kann. Ändern wir nun auch das zweite Element in einen reservierten Eventnamen, zum Beispiel “screen_view”. Wieder erhalten wir als Antwort ein Array-Element, das uns auf den reservierten Namen “session_start” hinweist:

ga4_recipes_singleevent_validation_array_reserved_2

Ändern wir nun  “session_start” in einen Eventnamen, der nicht reserviert ist, zum Beispiel “sessionstart”:

fetch(`https://www.google-analytics.com/debug/mp/collect?measurement_id=G-0WPD6V5EKJ&api_secret=bq-et0s9SVWiwScjvJckAw`, {
  method: "POST",
  body: JSON.stringify({
    client_id: '123.123', 
    events: [{
      name: 'sessionstart'
    },{
      name: 'screen_view'
    }]
  })
}).then(response => response.json())
  .then(data => console.log(data));
ga4_recipes_singleevent_validation_array_reserved_3

Nun erhalten wir ebenfalls ein Array-Element als Antwort, mit der Nachricht, das “screen_view” ein reservierter Eventname ist. Der Validierungsserver liefert also pro Request lediglich den ersten Fehler im Measurement Protocol zurück, nicht alle auftretenden Fehler.

Was passiert mit Request, die ein fehlerhaftes Event enthalten, wenn diese an den Measurement Protocol Server gesendet werden? Senden wir den eben genutzten Request nun an den Measurement Protocol Server und ändern den Eventnamen in screenview:

fetch(`https://www.google-analytics.com/mp/collect?measurement_id=G-0WPD6V5EKJ&api_secret=bq-et0s9SVWiwScjvJckAw`, {
  method: "POST",
  body: JSON.stringify({
    client_id: '123.123', 
    events: [{
      name: 'screenview'
    },{
      name: 'screen_view'
    }]
  })
}).then(response => response.json())
  .then(data => console.log(data));
ga4_recipes_multipleevent_server_1

Keines der Events erscheint im GA 4 Interface:

ga4_recipes_multipleevent_validation_interface

Auch in BigQuery gehen diese nicht ein, wie in der Übersicht aller bisher gesendeten Events zeigt:

ga4_recipes_multipleevent_validation_bq

Events mit Event Parametern

Um Event-Parameter einem Event hinzuzufügen, werden diese im Object “params” ergänzt. Dabei ist folgendes zu beachten:

  • Pro Event können lediglich 25 Event-Parameter mitgesendet werden
  • Der Event-Parameter-Name darf lediglich 40 Alphanumerische Zeichen oder Unterstiche “_”  umfassen
  • Der Event-Parameter-Name darf nicht einem “_”,”google_”, “ga_”, “firebase_”   beginnen
  • Zudem darf der Event-Parameter nicht “firebase_conversion” heißen
  • Der Wert des Events darf maximal 100 Zeichen umfassen

Füllen wir nun das params Object mit den zwei Event-Parametern “language” und “country”:

fetch(`https://www.google-analytics.com/mp/collect?measurement_id=G-0WPD6V5EKJ&api_secret=bq-et0s9SVWiwScjvJckAw`, {
  method: "POST",
  body: JSON.stringify({
    client_id: '123.123',
    events: [{
      name: 'sessionstart',
      params: {language:'DE', country:'DE'},
    }]
  })
}).then(response => response.json())
  .then(data => console.log(data));
ga4_recipes_eventparams_validation

Das Senden des Requests an den Validierungsserver liefert ein leeres Array zurück, somit ist der Request valide und wir senden diesen an den Measurement Protocol Server:

ga4_recipes_eventparams_server

Im Google Analytics Interface sind die Event-Parameter zu sehen:

ga4_recipes_multipleevent_interface

Validieren wir nun einen Hit mit mehr als 25 Event-Parameter (ep1 bis ep26):

fetch(`https://www.google-analytics.com/mp/collect?measurement_id=G-0WPD6V5EKJ&api_secret=bq-et0s9SVWiwScjvJckAw`, {
  method: "POST",
  body: JSON.stringify({
    client_id: '123.123',
    events: [{
      name: 'sessionstart',
      params: {ep1:'1', ep2:'2',ep3:'3', ep4:'4',ep5:'5', ep6:'6',ep7:'7', ep8:'8',ep9:'9', ep10:'10',ep11:'11', ep12:'12',ep13:'13', ep14:'14',ep15:'15', ep16:'16',ep17:'17', ep18:'18',ep19:'19', ep20:'20',ep21:'21', ep22:'22',ep23:'23', ep24:'24',ep25:'25', ep26:'26'},
    }]
  })
}).then(response => response.json())
  .then(data => console.log(data));
ga4_recipes_eventparams_validation_more25

Der Validierungsserver liefert trotz der Überschreitung ein leeres Array zurück. Sehen wir uns den Hit im GA4 Interface an:

ga4_recipes_eventparams_interface_more25

Das Event erscheint im Interface. Ebenso die Event-Parameter:

ga4_recipes_eventparams_interface_epmore25

Im Bild stammen die die beiden Event-Parameter „language“ und „country“ noch aus dem vorhergehend gesendeten Event. Somit sind mit diesem Event 25. Event-Parameter verarbeitet, nicht die gesendeten 26. Ebenfalls finden sich im BigQuery Export lediglich 25 Event-Parameter:

ga4_recipes_eventparams_bq_more25

Nicht verarbeitet wurde der Event Parameter ep19. Offenbar ist also die Reihenfolge der Event-Parameter nicht entscheidend.

Events mit Event Parametern für eCommerce

In Google Analytics 4 wird ein eCommerce Aktion durch einen vordefinierten Event-Namen definiert (Siehe: https://www.marcusstade.de/appweb-ecommerce-daten-mit-enhanced-e-commerce-eec-implementierung/) . Für jede dieser eCommerce Aktionen werden vordefinierte Event-Parameter erwartet, beispielsweise bei “purchase”, untern anderem der Umsatz “value”, die Transaktions-Id “transaction_id”, sowie optionale Event-Parameter wie der Gutscheincode “coupon”. (Vollständige Referenz der Events mit benötigten und empfohlenen Parametern: https://developers.google.com/analytics/devguides/collection/protocol/ga4/reference/events) Diese werden einfach dem “params”-Object hinzugefügt  Ein Measurement Protocol Request an den Validierungsserver für einen Kauf mit der Transaktions-Id “Test” und einen Umsatz von 99.99 EUR sieht dann folgendermaßen aus:

fetch(`https://www.google-analytics.com/debug/mp/collect?measurement_id=G-0WPD6V5EKJ&api_secret=bq-et0s9SVWiwScjvJckAw`, {
  method: "POST",
  body: JSON.stringify({
    client_id: '123.123',
    events: [{name: 'purchase',
      params: {
        transaction_id: 'Test',
        value: '99.99',
        currency: 'EUR'
      }}]
  })
}).then(response => response.json())
  .then(data => console.log(data));
ga4_recipes_eventparams_ecommerce_validation

Der Request liefert ein leeres Array. Senden wir also den Request an den Measurement Protocol Server und sehen uns die Transaktion im Interface an:

ga4_recipes_eventparams_ecommerce_interface

Ebenso die Event-Parameter:

ga4_recipes_eventparams_interface_ep

und die Werte der Event-Parameter:

ga4_recipes_eventparams_ecommerce_interface_value

Auch in BigQuery werden die Werte der Event-Parameter einer eCommerce-Transaktion zugeordnet, allerdings fehlen noch Produktinformationen zur Transaktion:

ga4_recipes_eventparams_ecommerce_bq

Um Produktinformationen in einem Measurement Protocol Request zu integrieren, werden die Produktinformationen in einem Array namens “items” im Object „params“ integriert. Jedes Array Element kann dabei die vordefinierten Event-Parameter für item enthalten, wie 

item_nameName des Produktes
item_idID des Produktes
item_pricePreis des Produktes
item_brandMarke des Produktes
item_categoryKateogrie des Produktes
item_variantVariante des Produkte
quantityAnzahl der gekauften Einheitens des Produkts
item_couponGenutzter produktspezifischer Coupon

Senden wir nun einen zweiten Request mit der Transaktions-ID “Test_Items” mit Produktinformationen:

fetch(`https://www.google-analytics.com/debug/mp/collect?measurement_id=G-0WPD6V5EKJ&api_secret=bq-et0s9SVWiwScjvJckAw`, {
  method: "POST",
  body: JSON.stringify({
    "client_id": "client_id",
    "events": [{
      "name": "purchase",
      "params": {
        "transaction_id": "Test_Items",
        "value": 99.99,
        "currency": "EUR",
        "items": [{
          "item_id": "SKU_1",
          "item_name": "Connector",
          "item_brand": "NoBrand",
          "item_category": "Connector",
          "item_variant": "Red",
          "price": 99.99,
          "quantity": 1
        }]
      }
    }]
  })
});
ga4_recipes_eventparams_ecommerceproduct_validation

Der Validierungsserver liefert ein leeres Array, daher senden wir den Request an den Measurement Protocol Server:

fetch(`https://www.google-analytics.com/mp/collect?measurement_id=G-0WPD6V5EKJ&api_secret=bq-et0s9SVWiwScjvJckAw`, {
  method: "POST",
  body: JSON.stringify({
    "client_id": "client_id",
    "events": [{
      "name": "purchase",
      "params": {
        "transaction_id": Test_Items",
        "value": 99.99,
        "currency": "EUR",
        "items": [{
          "item_id": "SKU_1",
          "item_name": "Connector",
          "item_brand": "NoBrand",
          "item_category": "Connector",
          "item_variant": "Red",
          "price": 99.99,
          "quantity": 1
        }]
      }
    }]
  })
}).then(response => response.json())
  .then(data => console.log(data));

Im Google Analytics 4 Interface wird der Kauf erfasst:

ga4_recipes_eventparams_ecommerceproduct_interface

Ebenso sind im BigQuery Export nun die Produktdaten vorhanden:

ga4_recipes_eventparams_ecommerceproduct_bq

Events mit User-Properties

Mit User-Properties können Informationen an den User gebunden werden. Der Vorteil einer User-Property ist, dass die Information nach Verarbeitung der User-Property in jedem Event verfügbar ist, ohne das diese explizit mitgesendet werden muss. Hierfür müssen User-Properties allerdings im Frontend registriert werden:

ga4_recipes_userproperties_create_interface

Für User-Properties gelten folgende Einschränkungen:

  • Es dürfen maximal 25 User-Properties pro Event mitgesendet werden
  • User-Property Namen dürfen maximal 24 Zeichen lang sein
  • Für Werte für von User-Property gilt eine Zeichenbeschränkung von 36 Zeichen
  • User-Property dürfen nicht mit “google_”, “ga_”, “firebase_” beginnen
  • Folgenden Namen sind reserviert “first_open_time”, “first_visit_time”, “last_deep_link_referrer”, “user_id”, “first_open_after_install”
  • User-Properties werden nicht sofort nach Erstellung im Frontend funktional, sondern benötigen einige Stunden, bis Daten entsprechend verarbeitet werden

Die User-Properties werden im JSON Object “userProperties” übergeben, das sich auf der gleichen Ebene wie Event befindet. Konstruieren wir einen Request für einen Kauf und senden die Information “LastPurchase” mit dem Wert “2020-12-22” als User-Property:

fetch(`https://www.google-analytics.com/debug/mp/collect?measurement_id=G-0WPD6V5EKJ&api_secret=bq-et0s9SVWiwScjvJckAw`, {
  method: "POST",
  body: JSON.stringify({
    "client_id": "client_id",
    "events": [{
      "name": "last",
      "params": {}
    }],
       "userProperties": {"LastPurchase": {"value": "2020-12-22"}}
  })
}).then(response => response.json())
  .then(data => console.log(data));

Der Validierungsserver liefert ein leeres Array zurück, daher senden wir den Request an den Measurement Server:

ga4_recipes_userproperties_validation

Die User-Property erscheint nicht im GA4 Realtime Interface.

ga4_recipes_userproperties_interface

Allerdings im Big Query Interface, d.h. diese wurde korrekt verarbeitet:

ga4_recipes_userproperties_bq

Senden wir nun ein Event “TestUserProperty” an den Server mit der gleichen ClientId. Im Google Analytics 4 Interface findet sich nun das Event:

fetch(`https://www.google-analytics.com/mp/collect?measurement_id=G-0WPD6V5EKJ&api_secret=bq-et0s9SVWiwScjvJckAw`, {
  method: "POST",
  body: JSON.stringify({
    "client_id": "client_id",
    "events": [{
      "name": "TestUserProperty",
      "params": {}
    }]
  })
})

Ebenso ist die User-Property im BigQuery Export für das Event vorhanden, obwohl es nicht im Request vorhanden war:

ga4_recipes_userproperties_bq_test

Measurement Protocol für Firebase

Google Analytics 4 bietet neben dem Measurement Protocol für Web auch ein Measurement Protocol für App an. Dies wird in den meisten Fällen wohl nicht implementiert, um Daten aus einer App an Google Analytics 4 zu senden, sondern eher aus Drittsystemen ein Event einer App zuzuordnen.

ga4_recipes_mpschema_app_firebase

Beide Measurement Protocol Varianten sind nahezu identisch und unterscheiden sich lediglich durch zwei Abweichungen:

WoWebApp
Query ParameterMeasurement IDfirebase_app_id
JSON Bodyclient_idapp_instance_id

Um einen Request in einer App zusammenzubauen, erfolgt dies genauso wie in Web und ersetzt die beiden Parameter. Hier der Beispiel-Request, für einen Firebase Request:

fetch(`https://www.google-analytics.com/mp/collect?firebase_app_id=1:1031235478220:android:fcfbff6faf1279f39b9869&api_secret=Dte3QM9FSa2cD7KVP5Sy1w`, {
  method: "POST",
  body: JSON.stringify({
    "app_instance_id": "998b26562339f2d7ff600f3afe3cf9fb",
    "events": [{
      "name": "Request_mpfirebase",
      "params": {}
    }]
  })
})

Die “firebase_app_id” befindet sich in Google Analytics 4 unter den App Stream Details der jeweiligen App :

ga4_recipes_firebase_app_id

Auf die app_instance_id, also das Äquivalent zur ClientId, kann direkt in der App zugegriffen werden. Auf Android erfolgt dies mit “getAppInstanceId()”.:Sehen wir uns ein Beispiel einer App an, die die app_instance_id per Log ausgibt:

Für iOS wird mit Swift appInstanceID() und mit Objective-C appInstanceID verwendet.

Vergleichen wir die „app_instance_id“ mit der „user_pseudo_id“ eines aus dem Firebase SDK generierten Request, stimmen diese überein:

ga4_recipes_firebase_instanceid_bq

Auch für die Firebase Variante des GA4 Measurement Protocols kann der Validierungsserver genutzt werden. Senden wir nun den Request mit dem Measurement Protocol für Firebase. Der Request erscheint im GA4 Interface:

ga4_recipes_firebase_mp_request

Ebenso ist der Hit in BigQuery mit den erwarteten Werten vorhanden:

ga4_recipes_firebase_mp_request_bq

Fazit

Das Measurement Protocol für Google Analytics 4 bietet trotz des aktuellen Alpha Status viele sinnvolle Neuerungen gegenüber dem Measurement Protocol für Universal Analytics. Für den Produktiven Einsatz ist es aber wohl noch zu früh, da sich vom derzeitigen Alpha Status ausgehend noch viele Änderungen ergeben können.

1 thought on “Google Analytics 4 Recipes: Measurement Protocol”

  1. Pingback: BP 4.06: Januar-News - mit Gast Podcast

Schreibe einen Kommentar Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Keep in Touch

Supporter: InPignus GmbH

ImPignus

mohrstade

mohrstade.de

Analytics Pioneers

Schlagwörter

App+Web App-Tracking Basic Big Query Customer Data Platform DataQuality DataStudio Events Google Analytics für Firebase ITP Machine Learning Property PWA Quick-Tipp User-Journey Wordpress Überblick

Podcast Empfehlung:

beyond pageview

Neueste Beiträge

  • Tag Management Platform: Commanders Act Platform X – DataCollection (Teil 2)
  • Tag Management Platform: Übersicht (Teil 1)
  • IP und User Agent Identifier: Nachteile
  • GA4 Recipes: Machine Learning Features für Predictive Audiences in anderen Tools nutzen, am Beispiel von Tealium AudienceStream
  • Quick Tipp: GA4 Configuration Tag vs. Universal Analytics Setting Variable – Sequence matters

Kategorien

  • Allgemein
  • Cloud
  • Dashboard
  • Firebase Analytics
  • Google Analytics
  • Google Analytics 4 (App+Web)
  • Google Optimize
  • Google Tag Manager
  • Machine Learning
  • Matomo
  • Tag Management

Links

  • Datenschutzerklärung
  • Hear Me Speak
  • Impressum
  • Meet & Eat
  • Über den Blog
©2023 Digital Analytics Blog | Built using WordPress and Responsive Blogily theme by Superb