Markus Baersch

Dieser Beitrag ist Teil einer Artikelserie zum Measurement Protocol. Nach einigen Anwendungsmöglichkeiten und Denkanstößen folgt ein technischer Praxisteil mit Hinweisen zum Einsatz.

Alle Teile dieser Serie

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

Reale Anwendungen für Websitebetreiber

Im ersten Teil hat gezeigt, dass man mit dem Measurement Protocol die Grenzen von Websites und Apps sprengen und neue Bereiche mit Google Analytics erobern kann. Es gibt aber auch im Zusammenhang mit dem Web - und speziell den Herausforderungen im Marketing - reichlich Anwendungsszenarien, die mit "klassischem" Tracking oft viel aufwändiger oder z. T. unmöglich sind. Einige Beispiele:

Selektives und sekundäres Tracking

Um mehr als eine Property mit Daten versorgen, bieten Standardtracking und Tag Manager entsprechende Lösungen an. Diese sind entweder schwierig zu implementieren, unübersichtlich, fehleranfällig... oder alles zusammen. Um einer zweiten Id nur in ausgesuchten Fällen Daten zu senden, steht schnell viel Konfigurationsaufwand an, der den Bestand an Triggern und Tags im Google Tag Manager deutlich steigert. Folgeaufwand für die Pflege ist ebenso nicht ausgeschlossen. Auch Lösungen über hitCallback liefern u. U. unerwartete Ergebnisse; speziell bei nachträglicher Impelentierung in einem komplexeren Trackingsystem.

So ist es in der Praxis i. d. R. viel einfacher, die sekundäre Sammlung von Daten durch Anpassung des (ohnehin meistens lieblos in ein Template geschmissenen) Trackingcodes mit Hilfe des Measurement Protocols zu erledigen. Sollte es zwei oder drei weitere wesentliche Stellen mit zusätzlichen Events oder manuellen Hits geben, verfährt man damit ebenso und ist in wenigen Minuten fertig. Ja: Quick & Dirty, dafür (kosten-) effizient und damit i. d. R. im Sinne des Kunden. Überzeugt man so vom Mehrwert eines zusätzlichen Profils, folgen Budgets für tiefere Implementierungen viel einfacher 😉

Damit kann man nicht nur bei separat existierenden Properties für mehrere Sites schnell ein gemeinsames Tracking implementieren, sondern ausgewählte Daten mehrerer Domains in einen Topf werfen. Ein umgesetztes Beispiel aus der Online-Marketingpraxis: Ein Verbund mehrerer Shops sammelt via Measurement Protocol in einem gemeinsamen Profil Daten zu Besuchern und Checkouts, die zur übergreifenden Auswertung dienen. Ohne aufwändige Implementierung von Cross-Domain-Tracking oder mehreren Instanzen des Standardtrackings.

Daten anreichern

Zusätzliche Daten wie Zeitpunkte von Tagespreisanpassungen, Wetterdaten, Änderungen im Produktportfolio u. Ä. immer direkt in der Webanalyse? Das geht unter Einsatz des Measurement Protocols. So kann ein Dashboard z. B. den Verlauf des Transaktionsvolumens unmittelbar mit anderen Messdaten kombiniert darstellen.

Online meets Offline

Wenn noch ein paar der Ideen aus dem ersten Beitrag hinzugefügt werden, finden sich weitere Kombinationen: Per Measurement Protocol und Lichtschranke erfasstes Kommen und Gehen, Bewegungsmuster in Ladengeschäften, Websitenutzung und ebenso eingeschossene Wetterdaten in einer GA-Datenansicht erlauben Auswertungen, die sonst ohne Datenaufbereitung in Drittanwendungen nicht möglich sind. Direkt in Google Analytics.

Stornos und Retouren

Mit dem Datenimport wird Google Analytics nicht nur mit zusätzlichen Informationen versehen oder bestehendes Datenmaterial durch weitere Dimensionen und Metriken angereichert, sondern auch um Stornos und Retouren bereinigt. Für die meisten in der Hilfe von Google aufgeführten Anwendungsszenarien ist ein echter Import tatsächlich der beste Weg. Bei der "Korrektur" von bereits erfassten Transaktionen können aber weder Import noch webgestützte Lösungen mit dem Measurement Protocol mithalten... weshalb dem Thema Stornos ein eigener Beitrag dieser Serie gehört.

Serverseitiges Tracking

Um mit dem Measurement Protocol ein serverseitig implementiertes Tracking umzusetzen, braucht man überraschend wenig, wenn man sich selbst um die Verwaltung des Users - z. B. am Client in einem eigenen Cookie - kümmert und auf Pageviews beschränkt. Oder sich in aufwändigeren Implementierungen selbst Tracking-Aufrufe vom Browser an den eigenen Server senden lässt, um Events oder alles andere ebenfalls abzudecken... auf der Serverseite. Die Website ist frei von Trackingcode, der geblockt werden könnte (huch, habe ich das jetzt laut gesagt?). Klar, das leisten auch andere Webanalyse-Anbieter - aber hier kann man auf der Auswertungsseite beim gewohnten Google Analytics bleiben. Zugegebenermaßen ist die Abdeckung aller Optionen des regulären GA-Trackings auf diesem Weg mühselig. Solcher Bedarf besteht selten. Außerdem kann man dazu auf bereits bestehende Implementierungen zurückgreifen, wenn man sich den Spaß des Eigenbaus unbedingt verwehren will 😉

Zwar werden Proxies, CDNs & Co. plötzlich zum Problem und Details wie die saubere Zuordnung einer Einstiegsseite eines Erstbesuchers sind in diesem Kontext problematisch (aber lösbar). Soll das Ganze die Performance der eigenen Website nicht zu sehr belasten, bringt die Implementierung einer asynchronen Lösung weitere Herausforderungen. Und wenn viele der eingehenden Hits auf dem eigenen Server zusätzlich einen ausgehenden Hit mitbringen, ist das je nach Serverauslastung ein weiterer Faktor, der zu berücksichtigen ist. Dafür bietet diese Variante ein paar nette Vorteile. So kommen z. B. nicht nur Besucher, sondern auch der Googlebot und seine Freunde in die Webanalyse. Hier können deren Bewegungen in eigenen Profilen oder als Segment komfortabel analysiert werden. Zumindest solange es nicht zu viel Traffic gibt, so dass das einsetzende Sampling in der Webanalyse den Plan verdirbt. Der Einsatz eigener Properties für jeden Bot - oder GA Premium - relativieren dieses Problem jedoch. Weil das Thema so spannend ist, enthält diese Serie einen eigenen Beitrag zum serverseitigen Tracking mit Analytics voller Details und Beispielen 😉

Measurement Protocol im Einsatz

Um von einer Idee zur lebenden Implementierung zu kommen, muss der Sprung in die Praxis her. Für alle, die sich auf technischer Ebene damit zu befassen haben, schließt dieser Beitrag daher mit Tipps ab, die den Einstieg erleichtern und typische Stolperfallen aufzeigen. Wer Technisches meidet, darf an dieser Stelle aussteigen und findet zum Trost im nächsten Beitrag der Serie eine Anleitung, wie man auch als "Nicht-Techie" etwas aus dem Measurement Protocol herausholen kann.

Tipp 1: Vermeide (not set), wo immer es geht

In der Referenz zum Measurement Protocol gibt es für alle Hit-Typen ausführliche Beispiele. Wer stets nur diejenigen Parameter nutzt, die mehr oder weniger zwingend zu einem Hit-Typ gehören, reißt an anderen Stellen ggf. Lücken, die die Auswertung später erschweren.

Oberstes Gebot ist es, zumindest die "optionalen" Angaben, die direkt zu einem Hit wie einem Event gehören, nicht zu vernachlässigen. Denn es können durchaus wichtige Parameter ungenutzt bleiben und dennoch Spuren des Aufrufs in Analytics bleiben. Als Beispiel: Ein Aufruf von v=1&tid=UA-xxx-1&cid=555&t=event&ec=Uncomplete+Event funktioniert zwar, doch in Analytics bleibt die Ereignisaktion dann (not set). Wer nur auf Kategorien und Werte blickt und sich um Aktionen nicht kümmert, mag damit zurecht kommen, aber solche Aufrufe reißen Lücken.

Leider kann u. U. nicht einmal das Weglassen von Pflichtangaben verhindern, dass dennoch "irgendwas" ankommt: v=1&tid=UA-xxx-1&cid=555&t=event&dt=Ich+darf+nirgends+ankommen überträgt ein Event ohne erforderliche Parameter; hat aber den Titel einer Seite im Gepäck. So erzeugt man zwar kein Ereignis, doch es bleibt eine (z. B. im Echtzeitbericht sichtbare) Interaktion im Bereich "Content". Diese wird, da der Pfad fehlt, der Standardseite zugeschlagen. Folgerichtig gibt es bei Übergabe eines Pfades statt eines Titels ebenso einen Eintrag. Das ist kein Drama, solange man nichts mit Echtzeitdaten anfängt, aber es ist unsauber. Debugging von Grenzfällen ist daher angesagt, bevor entsprechende Systeme auf Echtdatenprofile losgelassen werden.

Alle Informationen über den Client wie Browser etc. fehlen, wenn man sie nicht explizit mit überträgt. Ich sage nicht, dass man diese alle mit irgendwelchen Standardwerten belegen soll, aber wer Reports zu diesen Informationen nutzt, muss sich darüber im Klaren sein, woher die ganzen "Ausreißer" stammen. Zumindest einen Hostnamen sollte man daher möglichst bei jedem Aufruf befüllen; genau wie alles andere, was ggf. in Segmenten oder Filtern aktiv in Google Analytics genutzt werden soll. Die Verwendung des "Cache Busters" z mit einer Zufallszahl ist ebenso eine gute Erweiterung und darf in Echtanwendungen nicht fehlen, um Proxies und Caching aller Art auszuhebeln.

Merke: Aufgesattelte Seiteninfos bedeuten keinen Pageview!

Wie gerade gezeigt, können Angaben zu einer Seite, die typischerweise zu einem Pageview gehören, bei einem Event oder einer Transaktion "im Bundle" übertragen werden. Das ist sinnvoll, um diese Attribute in Berichten wie "Seiten" unter "Ereignisse" wiederzufinden oder als sekundäre Dimension zu nutzen. Allerdings findet sich die so übertragene "auslösende" Seite auch wirklich nur dort wieder, jedoch nicht in Berichten zum Website-Content. Um dort Spuren zu erzeugen, ist ein zusätzlicher Hit erforderlich, der einen separaten Pageview überträgt.

Tipp 2: Status 200 bedeutet nicht, dass alles OK ist

So einfach es erscheint, unvollständige Daten zu übertragen: einige Dinge sind wirklich unverzichtbar. Logisch ist, dass ohne Property-Id nichts zugestellt werden kann. Weniger offensichtlich ist vielleicht, dass auch eine Client Id cid zwingend erforderlich ist.

Wer z. B. v=1&tid=UA-xxx-1&t=event&ec=TestEventOhneCid&ea=Nirvana testet, bekommt den Statuscode 200 als Antwort, es entstehen aber keine Daten in der Webanalyse. Das gilt für unvollständige Requests aller Art: Selbst bei einem Aufruf ohne tid liefert Google brav ein Pixelchen zurück.

Tipp 3: So bekommt man eine cid

Die gute Nachricht: Eine einfache Id wie "1234" funktioniert einwandfrei. Wer nur ein wenig testet, muss sich daher nicht weiter mit diesem Parameter herumplagen - alle Aufrufe kommen einfach vom selben Nutzer. Soll eine echte Id erzeugt und z. B. in einem eigenen System oder Cookie verwaltet werden, findet man dazu entsprechende Bauanleitungen und Code; z. B. in PHP. Alternativ setzt man auf den Cookie von Google Analytics des aktiven Users auf, wenn denn ein Browser im Spiel ist oder z. B. serverseitiges Tracking stattfindet.

Tipp 4: Sammeln und per Batch übertragen

Statt Aufrufe einzeln abzusetzen, können mehrere Hits in einem Rutsch per POST statt GET übertragen werden. Nicht zu früh freuen: Auch "batchen" hat seine Grenzen. Ein Paket darf nicht mehr als 20 Hits enthalten und muss mit max. 16K auskommen, wobei keiner der einzelnen Hits größer als 8K sein darf. Die Größenbeschränkung klingt unkritisch, kann aber - genau wie die übliche Grenze von 2K für einzelne Werte - im Einzelfall zum Problem werden. Jedenfalls wenn man etwas anderes als Webtraffic misst.

Um zuerst in einem Log zwischengelagerte Daten zu bestimmten Zeitpunkten zu verarbeiten und an Analytics zu übertragen, bringt der Batchbetrieb einen deutlichen Zeitgewinn und ist deshalb fast Pflicht.

Beim Batch werden die Daten statt an /collect an /batch gesendet - und zwar spätestens jetzt per POST statt einfach mittels GET. Dabei können die einzelnen Hits im POST-Payload durch Zeilenumbrüche ("\n") getrennt werden. Man mag auf die Idee kommen, dass die Reihenfolge ggf. eine Rolle spielt und ein Event-Hit nach einem Pageview-Hit so vielleicht zu einer zugeordneten auslösenden Seite führt. Das stimmt leider nicht. Soll ein Event Infos zur auslösenden Seite beinhalten, müssen die zusätzlichen Parameter direkt im Hit enthalten sein - genau wie bei der einzelnen Übertragung an /collect.

Dennoch ist eine zeitliche Dimension im Batch vorhanden: Hängt man einem Hit z. B. den "Queue Time" Parameter qt=20000 an, wird eine 20 Sekunden "Verweildauer" zwischen diesem und dem vorherigen Hit definiert. So kann der Zeitpunkt des Hits in Millisekunden in die Vergangenheit verlegt werden; relativ zum Verarbeitungszeitpunkt. Das hilft allerdings weder bei Echtzeitberichten (dort landet stets nur der letzte Eintrag eines Batchs), noch kann es zum nachträglichen Korrigieren von Webanalysedaten verwendet werden. Der Grund ist die Grenze der Hit-Zeitmaschine, die nicht weiter als 4 Stunden in die Vergangenheit fliegt. Alles was lt. QueueTime älter ist als 4 Stunden, kommt definitiv nicht in Analytics an.

Tipp 5: SSL verwenden

OK, eigentlich muss es wohl TLS heißen. Egal. Gesicherte Übertragung der Daten ist im Fall eines installierten Clients oder serverseitiger Aufrufe von einem Server mit Zertifikat auf keinen Fall eine schlechte Idee. Dazu in allen Aufrufen http://www.google-analytics.com/collect gegen https://ssl.google-analytics.com/collect (oder batch/) austauschen.

Inspiriert zu eigenen Anwendungen? Dann freue ich mich über Kommentare aller Art. Die nächsten Teile dieser Serie beleuchten ein paar der aufgeführten Szenarien im Detail. Sie zeigen, was alles im Measurement Protocol steckt - also gleich weiterlesen im Artikel zum LifeLogging mit IFTTT 😉