Das Measurement Protocol: LifeLogging mit Analytics und IFTTT

Dieser Beitrag ist Teil einer Artikelserie zum Measurement Protocol. Jetzt geht es ans Eingemachte: Endlich empfängt Google Analytics mehr als nur Testdaten. Wir werden WLAN-Logins, Ladevorgänge, Anrufe und jede Menge anderen Kram in der Webanalyse versenken 😉

Alle Teile dieser Serie

• Überblick und Anwendung
• Praxistipps und Einsatzmöglichkeiten
• LifeLogging mit IFTTT
• Transaktionen stornieren per Refund-Event
• Serverseitiges Tracking: Dem Googlebot zuschauen

Warum IFTTT?

Ich bin Diplom-Ingenieur der Elektrotechnik. Ein Lötkolbenmann. Trotzdem bin ich eigenartigerweise kein Bastler. Ungeachtet dessen waren meine ersten Ideen zu "messbaren Ereignissen aus dem echten Leben" als Kandidaten für Analytics Sensoren. Türsensoren, um genau zu sein. Dazu gibt es reichlich verschiedene Möglichkeiten. Und bei Nico Miceli habe ich sogar eine Anleitung für eine Lösung mit Türsensoren, Minicomputer und trackbaren Messungen gefunden, die das Ganze wie gewünscht an Analytics sendet.

Weil ich kein Bastler bin, habe ich nach fertigeren Ansätzen gesucht, Wireless Sensor Tags gefunden und bestellt 😉 Weil auch hierbei der Weg zu Google Analytics erst einmal erarbeitet sein will, bin ich schlussendlich bei IFTTT ("If This Then That") gelandet, denn die Wireless Tags bieten dazu eine Schnittstelle.

Wer IFTTT kennt weiß, dass es hier jede Menge Adapter ("Services" genannt) als Brücke zu Anwendungen, Geräten, Websites und Cloud-Diensten gibt, die als konfigurierbare Trigger ("This") für verschiedenste Aktionen ("That") dienen. MashUps zwischen Diensten bzw. Datenquellen und Empfängern sind damit mit wenigen Klicks eingerichtet und für eine Unzahl an Aufgaben existieren fertige "Rezepte". Klingt ideal, um Daten mit dem Measurement Protocol an die Webanalyse zu senden? Ist es auch!

Hinweis: Da der "Webhook" Adapter in IFTT inzwischen nur noch in der Pro Version zu haben ist, braucht es einen kostenpflichtigen Account zum 1:1 Nachbau. Wenn Du es auch ohne einen solchen Account nachbauen willst, verwende Zapier, Make, n8n oder was auch immer für Dich funktioniert. Überall existierende ähnliche oder andere Trigger als Eingangssignal für eine solche Vermessung und dort kann man i. d. R. auch einen HTTP-Request an eine beliebige API raus senden - also auch an GA4 per Measurement Protocol.

Das Telefon als Datenquelle, GA4 als Empfänger

Soweit der Plan. Da wir mit dem GA4 Measurement Protocol arbeiten, brauchen wir zwei Dinge vorab: Die Measurement ID der GA4-Property (das G-XXXXXX aus dem Datenstrom) und ein API Secret, das man in GA4 unter Verwaltung > Datenströme > den jeweiligen Stream auswählen > Measurement Protocol API Secrets erstellen kann. Beides zusammen bildet die Grundlage für jeden Aufruf.

Der Weg zur Umsetzung:

1. IFTTT Konto einrichten und App installieren
2. Unter My Applets via New Applet ein neues Rezept anlegen. Über einen Klick auf "this" im nächsten Schritt einen Trigger erzeugen. Bei der Auswahl des Service steht Android Phone Call gut sichtbar oben, wenn man eine Suche nach "android" durchführt. Anklicken - dieser Dienst soll unseren ersten Beispiel-Trigger liefern.
   
   Wer ein iPhone sein eigen nennt, findet mit "iOS" als Suchbegriff ebenfalls ein paar Trigger, allerdings sind Anrufe leider nicht dabei. Trotzdem dranbleiben: Nach dem gleichen Prinzip finden sich für iOS sinnvolle andere Dinge wie den Upload eines neuen Fotos u. a., die man in ähnlicher Form als Event nutzen kann.
3. Android weiter vorausgesetzt: Aus einer Liste wird jetzt die Aktion ausgewählt, für die man eine Reaktion definieren will. Any phone call placed als Trigger für ausgehende Anrufe ist der erste Eintrag - prima für ein Beispiel. Bei anderen Services und Triggern gibt es ggf. noch Optionen zu definieren, hier reicht ein Klick zur Auswahl des Triggers.
4. Ein Klick auf "that" bestimmt nun, was passieren soll. Da wir Daten an den GA4-Server senden wollen, benötigen wir einen Channel, der uns einen HTTP-POST-Request erlaubt. Ich habe "Webhooks" dazu verwendet. Als "Action" steht nur Make a web request zur Wahl - genau, was gebraucht wird.
5. Jetzt wird es spannend - und hier unterscheidet sich das GA4 Measurement Protocol grundlegend vom alten Universal Analytics. Statt einer langen GET-URL mit Parameterkette senden wir einen POST-Request mit JSON-Body. Das klingt komplizierter, ist aber eigentlich eleganter. In der Webhook-Konfiguration:URL:

   https://www.google-analytics.com/mp/collect?measurement_id=G-XXXXXX&api_secret=YOUR_SECRET

   Method: POST

   Content Type: application/json

   Body:

   {
   "client_id": "ifttt_lifelogging",
   "events": [{
   "name": "phone_call_outgoing",
   "params": {
   "engagement_time_msec": 1,
   "occurred_at": "{{OccurredAt}}"
   }
   }]
   }

   Ein paar Anmerkungen dazu: Die client_id ist ein frei wählbarer String. Da alle Events vom gleichen "Gerät" kommen - nämlich von IFTTT - reicht ein fixer Wert wie ifttt_lifelogging völlig aus. Der engagement_time_msec-Parameter ist wichtig: Ohne ihn tauchen Events in vielen GA4-Berichten schlicht nicht auf. Der Wert 1 (eine Millisekunde) reicht, um GA4 zufriedenzustellen. Und die Variable {{OccurredAt}} kommt wie gehabt aus den IFTTT-Ingredients - Werte, die ein Trigger liefert und die über den Schalter oben links in Eingabefeldern wählbar sind.

   

   Hinweis: Der Screenshot zeigt noch die alte Konfiguration mit GET-URL. Bei der GA4-Variante sieht das Formular etwas anders aus, weil Method, Content Type und Body zusätzlich befüllt werden. Ich hätte ihn gern aktualisiert, aber inzwischen ist der Webhook kostenpflichtig (siehe Hinweis oben).  

6. Im letzten Schritt wird noch ein Name vergeben und die Einrichtung mit "Finish" abgeschlossen.

Was beim alten Universal Analytics über Event-Kategorie, -Aktion und -Label abgebildet wurde, lebt jetzt im Eventnamen und in den Parametern. Statt ec=Logging+Calls&ea=Outgoing+Call&el={{OccurredAt}} heißt es jetzt phone_call_outgoing mit occurred_at als Parameter. Sauberer, wenn man mich fragt.

Idealerweise wiederholt man diesen Vorgang nun für eingehende und verpasste Anrufe in zwei weiteren Applets, bei denen der Eventname entsprechend angepasst wird:

• phone_call_incoming - für eingehende Anrufe
• phone_call_missed - für verpasste Anrufe

Vor allem mit den verpassten Anrufen hat man ein ideales Ereignis, das man beliebig selbst auslösen kann - also kann schon getestet werden.

In Echtzeit testen

Mit etwas Glück sollte es möglich sein, nach der Definition und automatisch erfolgenden Aktivierung des Rezepts verpasste Anrufe direkt nachzuverfolgen. Dazu mit einem zweiten Telefon die eigene Nummer des Geräts anrufen, auf dem die IFTTT-App installiert (und angemeldet!) ist, ein paarmal klingeln lassen und wieder auflegen. Auf der IFTTT Website sollte es beim Blick in das Activity Log recht schnell eine Bestätigung der Ausführung geben. Viel spannender ist es, in GA4 den Echtzeitbericht zu öffnen und zu sehen, ob das Event dort auftaucht.

Wer stattdessen nichts sieht: Das GA4 Measurement Protocol liefert bei Erfolg einen HTTP 204 zurück - ohne Body. Fehler werden leider ebenso stillschweigend geschluckt. Zum Debuggen kann man die URL vorübergehend auf den Validation Server umstellen:

https://www.google-analytics.com/debug/mp/collect?measurement_id=G-XXXXXX&api_secret=YOUR_SECRET

Dieser gibt eine JSON-Antwort mit Hinweisen auf fehlerhafte Parameter zurück. In IFTTT selbst kann man das schlecht nutzen, aber zum Testen des JSON-Bodys mit einem Tool wie cURL oder Postman ist das Gold wert.

Ausbauen mit weiteren Events

Wenn diese Hürde genommen ist, kann man sehr einfach weitere Events mit Hilfe der anderen Android-Services wie Location, SMS, Batterie und vor allem dem "Android Device"-Adapter erstellen, der An- und Abmeldungen bei Bluetooth-Geräten (im Auto) und WLAN-Netzwerken erlaubt. Mit der Netzwerkkennung kann dabei z. B. zwischen Home und Office unterschieden werden - reichlich Ansatzpunkte für Messungen.

Eventname-Vorschläge als Orientierung:

• wifi_connected / wifi_disconnected - mit Parameter network_name
• bluetooth_connected - mit Parameter device_name
• battery_low / battery_full
• sms_received

Wichtig: Eventnamen in GA4 müssen in snake_case sein - also Kleinbuchstaben mit Unterstrichen. Leerzeichen, Großbuchstaben und Sonderzeichen sind tabu.

Außerdem gibt es eine ganze Welt weiterer IFTTT-Services zu entdecken. Es empfiehlt sich, die Liste später in Ruhe durchzugehen und sich inspirieren zu lassen - je nachdem, welche Dienste und Apps man selbst verwendet, finden sich hier noch jede Menge andere Ansätze für neue Messideen.

Benutzerdefinierte Dimensionen in GA4 registrieren

Ein Detail, das man beim GA4 Measurement Protocol nicht vergessen darf: Eigene Parameter wie occurred_at oder network_name tauchen in den GA4-Standardberichten erst auf, wenn man sie als benutzerdefinierte Dimensionen registriert hat. Das geht unter Verwaltung > Benutzerdefinierte Definitionen > Benutzerdefinierte Dimensionen erstellen. Dort den Eventnamen und den Parameternamen eintragen - fertig. Ohne diesen Schritt werden die Parameter zwar erfasst, sind aber in den Berichten unsichtbar. Wer das vergisst, wundert sich tagelang (frag nicht).

Hinweise und Tipps

Für ungetrübten Spaß sollten ein paar Dinge beim Einsatz beachtet werden:

• Keine PII senden! Es mag verlockend sein, bei Triggern wie Telefonanrufen die Nummer oder den Namen als Zutat zu verwenden und als Parameter mitzuschicken. Widerstand ist hier unbedingt erforderlich. Solche persönlichen Informationen ("PII" in Neudeutsch) haben allein schon wegen der Nutzungsbedingungen von Google Analytics explizit nichts in der Webanalyse zu suchen. Vom Datenschutz im Allgemeinen mal abgesehen. Wer seine eigenen Standorte per Foursquare, iOS Location oder Android Location senden will, mag das ethisch mit sich vereinbaren können, aber "fremde" Infos sind stets sensibel zu behandeln.
• API Secret schützen: Das API Secret für das GA4 Measurement Protocol ist kein hochsensibles Geheimnis - es erlaubt lediglich das Senden von Events an eine Property, nicht das Lesen von Daten. Trotzdem sollte man es nicht öffentlich teilen. In IFTTT ist es sicher in der Webhook-URL aufgehoben.
• Eigene Property verwenden: Wie schon im zweiten Teil der Serie empfohlen - LifeLogging-Events gehören in eine separate GA4-Property. Man will seine Website-Daten nicht mit Batterie-Events und WLAN-Logins verunreinigen.
• Deduplizierung: Das GA4 Measurement Protocol hat kein eingebautes Equivalent zum alten Cache-Buster-Parameter z. Dafür sorgt die Kombination aus client_id, Eventname und Zeitstempel normalerweise für ausreichend Eindeutigkeit. Wer trotzdem Probleme mit doppelten Events hat, kann einen zufälligen Wert als zusätzlichen Parameter mitsenden.

So sehen Ergebnisse in GA4 aus

GA4 zeigt je nach Anzahl der Trigger und Häufigkeit der Aktionen schnell erste Daten. Die Echtzeit-Ansicht zeigt eingehende Events live, und in der Ereignis-Übersicht unter Berichte > Engagement > Ereignisse findet man alle Eventnamen mit Anzahl.

Hinweis: Der Screenshot zeigt die alte Universal Analytics Ansicht. In GA4 findet man die Events unter Berichte > Engagement > Ereignisse - sortiert nach Eventname statt nach Kategorie/Aktion/Label.

Wer die benutzerdefinierten Parameter als Dimensionen registriert hat, kann sie in Explorations (dem freien Berichtseditor in GA4) als Zeilen oder Filter verwenden. So lassen sich z. B. WLAN-Logins nach Netzwerkname aufschlüsseln oder Anruf-Events nach Tageszeit filtern. Mit dem Verlauf mehrerer Tage kann man Trends zur Telefonnutzung darstellen, zur Häufigkeit der Logins zuhause und im Büro, Autofahrten und was sonst noch an Daten gesammelt werden soll.

Damit: Ran an die eigenen Ideen und "Happy Tracking"! Der nächste Artikel wird nach diesem eher exotischen Beispiel wieder bodenständiger: Sauberes und effizientes Stornieren von bereits erfassten Transaktionen per Refund-Event.

Wer hier einen Kühlschrank gesucht hat, findet diesen in einer älteren Fassung (mit "Maker" statt "Webhooks" und einer älteren Ausgabe der IFTTT-Oberfläche) als Präsentation: