Markus Baersch

Software · Beratung · Lösungen

Start » Blog » Analytics / Measurement Protocol

23.11.2015

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

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 („Channels“ 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!

Das Telefon als Datenquelle, Analytics als Empfänger

Soweit der Plan. Zur Umsetzung führt folgender Weg:

  1. IFTTT Konto einrichten und App installieren
  2. Unter My Recipes via Create a Receipe ein neues Rezept anlegen. Über einen Klick auf „this“ einen Trigger erzeugen. Bei der Auswahl des Kanals steht Android Phone Call weit oben, so dass eine Suche nicht erforderlich ist. Anklicken – das soll unser erster Beispiel-Trigger sein.

    IFTTT: this - Android Phone Call

    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 Channels und Aktionen gibt es ggf. noch Optionen zu definieren, hier reicht ein Klick auf Create Trigger.
  4. Ein Klick auf „that“ bestimmt nun, was passieren soll. Da wir Daten an den Analytics-Server senden wollen, benötigen wir einen Channel, der uns den Aufruf einer beliebigen URL erlaubt. Ich habe „Maker“ dazu verwendet (es mag andere geben). Als „Action“ steht nur Make a web request zur Wahl – genau, was gebraucht wird.

    IFTTT: that - Maker

  5. Um Daten an eine Analytics-Property (welche extra hierfür eingerichtet wurde – warum wurde im zweiten Teil ausführlich erläutert) zu senden, muss nun ein Tracking-Hit gesendet werden. Ich habe mich für Events entschieden. Mittels https://www.google-analytics.com/collect?v=1&tid=UA-xxx-1&cid=666&t=event&ec=Logging+Calls&ea=Outgoing Call&el={{OccurredAt}}&aip=1 geht der Aufruf raus. Die Anatomie des Trackingaufrufs sollte vertraut wirken, wenn man die Beispiele aus dem zweiten Teil kennt. Einzige Ausnahme ist die eingesetzte „Variable“: Werte, die ein Trigger liefert und die in der Aktion genutzt werden können, sind über den Schalter oben links in Eingabefeldern wie hier der URL wählbar („Ingredients“). So ist auch der Zeitstempel {{OccurredAt}} in die URL gekommen.

    Konfiguration des Triggers

  6. Als Methode reicht GET, der Content Type kann noch auf text/plain gesetzt werden und schon ist das Rezept fertig.

Idealerweise wiederholt man diesen Vorgang nun für eingehende und verpasste Anrufe in zwei weiteren Rezepten, bei denen in der URL die Ereignisaktionen über den Parameter ea entsprechend angepasst werden. 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 IF-App installiert (und angemeldet!) ist, ein paarmal klingeln lassen und wieder auflegen. Auf der IFTTT Website sollte es beim Blick in das Receipe Log recht schnell eine Bestätigung der Ausführung geben. Viel spannender ist es, im beschickten Profil nun die Übersicht des Echtzeitberichts in Analytics zu öffnen und zu sehen, ob es einen aktiven User gibt. Dieser sollte im Unterpunkt Ereignisse einen Eintrag hinterlassen haben.

Event in Echtzeit

Wer stattdessen nichts sieht, kann an der Unzuverlässigkeit der Echtzeitberichte gescheitert sein. Zum Glück findet man bei Anpassung der Periode auf das aktuelle Datum Events alternativ nach kurzer Wartezeit in den normalen Berichten unter „Verhalten – Ereignisse“.

Ausbauen mit weiteren Events

Wenn diese Hürde genommen ist, kann man sehr einfach weitere Events mit Hilfe der anderen Android-Channels 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.

Außerdem gibt es eine ganze Welt weiterer Channels 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.

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 Benutzerdefinierte Dimension, Eventlabel oder Ähnliches zu verwenden. Widerstand ist hier unbedingt erforderlich. Solche persönlichen Informationen („PII“ in Neudeutsch) haben allein schon wegen der Nutzungsbedingungen von 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.
  • URL Shortener abschalten: Je nachdem, was man genau anstellt, kann IFTTT URLs kürzen. Wer keine URLs mit seiner Tracking-Id bei solchen Diensten haben will, kann zur Sicherheit in den Einstellungen die Verwendung von Shortenern abschalten.
  • Who the f.. is „Maker“? Keine Ahnung. Was gemeint ist: Ein fremder Server setzt die Requests ab, die unsere Daten an Analytics senden. Das muss kein Problem sein und für ein reines Spielprofil ist das Risiko überschaubar. Wer ernsthaftes Tracking im Sinn hat, schaltet besser ein wenig PHP auf dem eigenen Server dazwischen. Einer „Brückenseite“ muss man dann nur noch die erforderlichen Angaben für Events oder Pageviews senden, der Rest der URL und vor allem Parameter wie die tid hält man so unter Verschluss. So, Aluhut aus. Letzter Tipp:
  • Cache Buster nutzen. Der z-Parameter ist eine gute Sache, wenn man ansonsten nichts in seiner URL hat, das sich bei zwei Aufrufen unterscheiden würde. Denn in solchen Fällen besteht sonst die realistische Gefahr, dass zwei kurz aufeinander folgende Events wie verpasste Anrufe nicht beide in der Webanalyse ankommen. Wenn man keine veränderlichen Daten wie einen Zeitstempel mitsendet, kann zur Not sogar so etwas wie eine Telefonnummer o. Ä. als z=… genutzt werden, denn der Wert dient ausschließlich zur Schaffung eindeutiger URLs mit Zufallsdaten, die definitiv nicht in der Webanalyse landen und daher nicht unter den obigen „PII-Hinweis“ fallen.

So sehen Ergebnisse in Analytics aus

Google Analytics zeigt je nach Anzahl der Trigger und Häufigkeit der Aktionen schnell erste Daten, über die man sich hermachen kann. Wer sich auf Events beschränkt, kann sich von den Eventkategorien über die Aktionen bis hin zu den Labels (wo man z. B. konsistent Zeitstempel unterbringen kann) durch die Ereignisse des Tages klicken.

Events in der Übersicht

Mit dem Verlauf mehrerer Tage kann man Trends zur Telefonnutzung darstellen, zur Häufigkeit der Logins zuhause und im Büro, Autofahrten, Checkins… 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.

© 2001 - 2017