Wetterdaten an Google Analytics

Personalisierung

Klassisches A/B Testing gehört fast schon wieder zum “alten Eisen” und hat mittlerweile auch hierzulande die Herzen der meisten Online-Firmen erobert. Und derzeit stürmt schon das nächste große Ding die CRO Hitliste: Die Personalisierung. In den vergangenen 12 Monaten sind einige Firmen mit spannenden all-in-one Lösungen an den Markt gegangen. Jedoch: Es lassen sich wie immer auch dann schon gute Fragen stellen (stell Dir vor: vielleicht sogar beantworten!), wenn bisher noch kein Budget für das nächste Business-Gadget zur Verfügung steht.

Von Regenschauern und Sonnenliegen

Es gibt diverse Möglichkeiten, das Ausspielen von auf den Nutzer zugeschnittenem Content zu ermöglichen. Und glücklicherweise setzen nicht alle Ansätze voraus, dass man im großen Stil private Daten anhäuft. Weitaus wertvoller kann es (je nach Fragestellung) sein, dass ich sinnvoll segmentiere. Angenommen, Du bist ein Anbieter für Rundreisen und findest heraus, dass der Großteil Deiner Nutzer bei Regenschauern allem voran Rundreisen in Warmwasserregionen bucht – bei Sonnenschein jedoch stattdessen schon die nächste Schneewanderung für den Winter plant. Was wäre für Dich ein möglicher logischer Schritt in der strategischen Ausspielung Deines Contents? Tja, darauf weißt nur Du eine Antwort. Was wir jedoch wissen: Der kostenfreie Google Tag Manager kann uns dabei helfen, solche Dinge herauszufinden.

Google Tag Manager & Wetterdaten

Um solche Effekte herauszufinden, muss man nichts anderes machen, als Informationen über das Wetter am jeweiligen Standort des Users an Analytics zu senden. Klingt einleuchtend, ist aber reichlich kompliziert. Ha, hab ich Euch, ist es nämlich nicht – auch wenn dieser Artikel etwas länger ausfällt, ist das Verfahren recht schnell und einfach umgesetzt.

Wetterdaten 1

Wetterdaten 2

Was wird gemacht

Vereinfacht ausgedrückt brauchen wir nur drei Dinge: Die Geolocation des Users, eine Wetter API sowie eine Möglichkeit, diese Daten in den Data Layer zu pushen. In seinem Blog hat Simo Ahava, der Gott des GTM 🙂 ,  ein schönes Setup ausgearbeitet (mehr oder minder ein Prototyp für API Abfragen jeglicher Art), das nichts anderes macht, als genau dies zu tun – und welches ich hier gerne auf Deutsch vorstellen möchte.

Insgesamt sind 6 Schritte für die Umsetzung unseres Wetter-Trackings nötig:

  1. Ein Custom HTML Tag, um sich die Daten per Wetter API zu ziehen und diese im DataLayer zu speichern
  2. Einen Trigger, um ein Event Tag zu feuern, sobald die Daten im DataLayer gelandet sind
  3. DataLayer Variablen, um die Infos aus dem DataLayer in das Event Tag zu ziehen
  4. Eine First Party Cookie Variable, um die Daten zumindest über eine Session hinweg zu erhalten
  5. Zwei Custom Dimensions (Session Scope) in GA um die API Wetterdaten aus dem Tag zu erhalten (Wetter und Temperatur)
  6. Ein UA Event Tag, um die Daten an Analytics zu schicken

1. Der Custom HTML Tag

Als erstes legen wir einen neuen custom HTML Tag an. Ihr könnt ihn nennen wie Ihr wollt, ich bleibe der Einfachheit halber bei Utility – HTML – Weather Query.

GTM Weather - Custom HTML 1

Nicht erschrecken – es folgen eine Menge Zeilen Code. Für die JS Profis unter Euch sollte das alles recht selbsterklärend sein, für die anderen reichen wahrscheinlich die ausgeklammerten Kommentare 🙂 .

Mittlerweile muss man sich einmalig bei OpenWeather registrieren, um auf die API zugreifen zu können. Das ist vollkommen kostenfrei und kann ganz fix hier erledigt werden. Sobald Ihr Euch registriert habt, ersetzt Ihr bitte in Zeile 14 des Codes den Part “XXXXXX DEINE WEATHER API ID XXXXX” durch Eure API ID.

Feuern lasst Ihr den Tag auf den All Pages Trigger. Hier jedoch ein wichtiger Hinweis: Ganz zu Beginn werden zwei Libraries geladen, und zwar jQuery und die Geolocation Library von geoPlugin. Wenn Ihr jQuery schon nativ auf Eurer Seite geladen habt, sollte es hier nicht noch einmal geladen werden – in einem solchen Fall bitte einfach Zeile 2 entfernen. Um zu prüfen, ob jQuery schon geladen ist, könnt Ihr einfach in Eure Console gehen und folgendes eintippen:

Solltet Ihr jQuery asynchron laden, müsst Ihr den Custom HTML Tag statt über den All Pages Trigger über einen Window Loaded Trigger feuern lassen. Hierzu bitte einfach einen weiteren Trigger wie folgt anlegen und den custom HTML Tag darauf feuern lassen:

Pageview Window Loaded Trigger

2. Der Custom Event Trigger

Dieser Trigger feuert, sobald ein Eventkey mit dem Value “weatherDone” in den DataLayer gepusht wird. Auch hier bleiben wir bei Simos Wording und nennen den Trigger Event – weatherDone.

Event Weather Done

3. Die Data Layer Variablen

An dieser Stelle hat man sich für zwei Variablen entschieden, die man einspeisen möchte: Eine kurze Wetterbeschreibung sowie die Wettertemperatur (je nach gewünschter API kann man hier natürlich eine entsprechende andere Anzahl an Variablen anlegen). Wir bauen daher zwei neue Variablen und geben ihnen die Namen DLV – weather und DLV – temperature (DLV steht hier einfach für DataLayer Variable, aber auch hier kann der Name natürlich frei gewählt werden).

DLV Weather

DLV Temperature

4. Die First Cookie Variable

Da wir die Wetterdaten nur einmal pro Session verschicken wollen (alles andere macht wenig Sinn & belastet unnötig den Traffic), bauen wir ein custom cookie mit einer Lebenszeit von 30 Minuten, das bei jedem Pageload zurückgesetzt wird. Hierfür daher bitte einfach eine Variable Session alive mit den folgenden Daten anlegen:

Session Alive

5. Die nötigen Custom Dimensions

Wie vorhin schon angemerkt, interessieren wir uns an dieser Stelle für zwei Variablen: Die Temperatur und die Wetterbeschreibung. Für diese beiden Messwerte legen wir uns nun in Google Analytics zwei neue benutzerdefinierte Dimensionen mit dem Umfang Sitzung (Session Scope) an:

CDs

6. Universal Analytics Event Tag 

Zu guter Letzt legen wir nun noch ein UA Event Tag an, weisen die korrekte Tracking ID zu und vergeben nun die korrekten Variablen:

Weather Tag 1

Dieser Tag, wir nennen ihn hier Weather and Temperature Tag, sollte als non-interaction Event angelegt werden, da man sich ansonsten u.U, sich die Bounce-Rate Messung zunichte macht, obwohl der User ggf. keinerlei Aktionen auf der Seite ausgeführt hat. Daher setzen wir das Event auf “ohne Interaktion = Wahr” und weisen außerdem die zuvor angelegten Custom Dimensions zu:

Weather Tag 2

Und zu guter Letzt kommt unser initial angelegter Trigger zum Einsatz: Das UA Event Tag soll stets bei weatherDone feuern:

Weather Tag 3

Und das war´s! Einmal aufsetzen, die Veränderungen im GTM Container publishen und herausfinden, inwiefern das Wetter möglicherweise einen Einfluss auf das Kauf- und Nutzungsverhalten Eurer User hat.

Zusammenfassung

Das Verfahren ist ein schönes Beispiel dafür, wie mächtig der GTM auch über seinen Haupteinsatzbereich hinaus ist. Im Grunde lassen sich hier alle Informationen in Eure Nutzeranalyse packen, die über eine API abgegriffen werden können – hier findet Ihr eine gute Beispieldatenbank. Spielt gerne ein wenig damit herum und schreibt Eure Erfahrungen in den Kommentarbereich.

Jan
Jan
Autor
Psychologe, Web Analyst, Science Junkie, Star Wars Missionar und Gründer des Blogs

Hinterlasse einen Kommentar

Please enter your comment!
Please enter your name here