Was ist das Google Tag?

Zugegeben, die folgende Überschrift aus dem Blog von Simo Ahava weckte meine Neugier:

Expiration Cap Removed From Javascript Cookies In Webkit Browsers

Tatsächlich dürften die Auswirkungen für alle, die es mit dem Tracking halten, überschaubar bleiben. Aber betrachten wir das Glas erstmal als halbvoll: Unter bestimmten Voraussetzungen wird das Ablaufdatum der JavaScript-seitig gesetzten Cookies zukünftig tatsächlich nicht eingeschränkt.

Besucht der Nutzer die entsprechende Website regelmäßig und interagiert mit dieser, so wird die Laufzeit der Cookies verlängert. Alle skriptgeschriebenen Elemente in Web-Speichern (Cookies, localStorage usw.) Web-Speichertypen werden gelöscht, wenn auf der zugehörigen Website innerhalb von sieben Tagen der Browsernutzung keine nennenswerten Nutzerinteraktionen (z. B. Klicks oder Tastatureingaben) erfolgen.

Was bedeutet dies für die Tracking-Links?

Eingehende Links von Websites, die lt. WebKit Tracking Capabilites haben, sind von dieser Ausnahmeregelung nicht betroffen. Das bedeutet: Über einen Link einer solchen Website mit „Tracking Capabilities“ (wie z. B. Facebook), der zudem URL-Parameter oder Hash-Fragmente enthält, die auf ein Tracking / Werbung hinweisen, und Cookies auf der Zielseite setzt, wird die Laufzeit dieser Cookies weiterhin beschränkt (die Laufzeit sollte i. d. R. maximal 24 Stunden betragen).

Marketer haben bei diesem Rennen zwischen Tracking und Datenschutz zwischenzeitlich einen alternativen Weg gefunden: das Setzen von Cookies im HTTP Request-Header. Doch selbst diese Variante scheint aktuell in das Blickfeld der Browser-Entwickler geraten zu sein.

In Safari Technology Preview 157, there’s a new feature being tested that would limit the expiration of cookies set in HTTP response headers to just 7 days in case the response originates from a server whose IP address subnet does not match that of the site making the request.

Der Krieg um die Cookies geht weiter

Also auch Cookies, die vom Webserver an den Browser gesendet werden, sind nicht zwangsläufig langlebiger, selbst wenn sie von einer Subdomain stammen. Klar ist, dass vor allem für kleine Websitebetreiber dieses Rennen kaum gewonnen werden, kann.

Denn sowohl die Kosten als auch das technische Know-how, die eigene Website-Infrastruktur so zu verändern, um die Mechanismen bzw. Regeln der Browserbetreiber auszuhebeln, werden das erträgliche Maß an einem bestimmten Punkt erreichen.

Kampagnentagging? Brauche ich das überhaupt?

Stellen Sie sich vor, Sie bewerben ein bestimmtes Produkt oder eine Dienstleistung in einem sozialen Netzwerk. Dazu erstellen Sie drei Werbekampagnen und sprechen in jeder Kampagne eine andere Zielgruppe an. Ihr Mediabudget teilen Sie gleichmäßig auf Ihre drei Kampagnen auf. Nach einem Monat möchten Sie wissen, welche Kampagne am besten funktioniert hat, um Ihr Budget in der nächsten Iteration noch effektiver einzusetzen.

Oder: Sie versenden einen monatlichen Newsletter. Klicks aus dem Newsletter auf Ihre Website werden aber in den Mehrzahl der Fälle der Akqusitionsquelle (direct) und dem Medium (none) zugeschrieben. Sie haben also kaum eine Handhabe festzustellen, wie intensiv Ihr Newsletter konsumiert wird.

Jetzt kommen die UTM-Parameter ins Spiel, die dabei helfen, diese Fragen zu beantworten. UTM-Parameter sind kleine Informationsschnipsel, die Sie an die ausgehenden Links anfügen, die in den Werbekampagnen auf Ihre Website führen. An das Ende der URL wird zunächst ein Fragezeichen gehängt, gefolgt von den Kampagnenparametern. So sieht das zum Beispiel aus:

https://www.beispiel-shop.com/tolle-rote-schuhe.html?utm_source=newsletter&utm_medium=email&utm_campaign=wintersale-2020

• utm_source -Gibt Ausschluss über die Kampagnenquelle, hier: „Newsletter“.
• utm_medium – Verrät das Marketingmedium, hier: „email“ (hier wird die englische Schreibweise für „E-Mail“ verwendet).
• utm_campaign – Hiermit können Sie Ihrer Kampagne einen treffenden Namen geben, um diese schnell wiederzuerkennen.

Darüber hinaus gibt es noch weitere Parameter: utm_content und utm_term. Erstgenanntes kann verschiedene Inhaltselemente unterscheiden, und utm_term wird standardmäßig eingesetzt, um Keywords. Letztendlich können Sie beide Parameter aber auch nach eigenem Bedarf verwenden. Das ist Fluch und Segen zugleich. Die freie Verwendung wird dort schwierig, wo die Kampagnenparameter von verschiedenen Personen erstellt und verwendet werden, ohne dass vor dieser Verwendung klare Regeln formuliert wurden:

• https://www.beispiel-shop.com/tolle-rote-schuhe.html?utm_source=newsletter&utm_medium=e-mail&utm_campaign=wintersale-2020
• https://www.beispiel-shop.com/tolle-rote-schuhe.html?utm_source=newsletter&utm_medium=email&utm_campaign=wintersale-2020
• https://www.beispiel-shop.com/tolle-rote-schuhe.html?utm_source=newsletter&utm_medium=Email&utm_campaign=wintersale-2020

In diesen drei URLs wurde das Medium „E-Mail“ in unterschiedlicher Schreibweise verwendet: „e-mail“, „email“ und „Email“. Das ist zwar für einen Leser verständlich, aber für Google Analytics sind das erst einmal drei verschiedene Medientypen und würden auch in den Berichten als unterschiedliche Medien dargestellt.

Kleine Helferlein

Es gibt ein paar Helferlein, die dabei helfen, die UTM-Parameter konsistent zu verwenden.

Der Campaign URL Builder von Google hilft bei der Erstellung von Kampagnen-URLs. Hier muss lediglich die Basis-Ziel-URL (also ohne Parameter) eingegeben werden sowie die UTM-Parameter, die an diese URL angehängt werden sollen.

Eine Excel- oder Google-Tabelle kann Ihnen den Kampagnenparameter-Alltag ungemein erleichtern. In solch einer Tabelle können Sie die verwendeten Parameter und URLs dokumentieren. Ein wichtiger Hinweis: Stellen Sie klaren Regeln auf zur Verwendung von Parametern auf. Eine konsistente Nutzung dieser Parameter ist enorm wichtig, um später Kardinalitätsprobleme zu vermeiden.

Und wenn ich keine Parameter verwende?

Verzichten Sie auf den Einsatz von UTM-Parametern, so könnte Google Analytics immer noch, sofern vorhanden, die Verweisquelle zuordnen. Zugriffe aus Facebook oder von anderen Websites fänden Sie dann zum Beispiel im Akqisitionsbericht „Quelle / Medium“ unter „facebook.com / referrer“. Allerdings fehlte in diesem Fall das Differenzierungsmerkmal a) zwischen Klicks aus organischen und beworbenen Beiträgen und b) zwischen Kampagnen (denn dieses Merkmal würde komplett fehlen).

Ist keine Verweisquelle vorhanden (z. B. im Falle von Newslettern), so würde Google Analytics die Sitzung der Quelle (direct) und dem Medium (none) zuordnen.

Das ist eine oft zu hörende Binsenweisheit, wenn es darum geht, den „Direct Traffic“ zu erklären. Doch tatsächlich steckt mehr dahinter, als auf den ersten Blick erkennbar ist.

So, und was ist jetzt „Direct Traffic“?

Die verkürzte Definition müsste lauten: Unter Direct Traffic fallen zuführende Quellen, die Google Analytics nicht anders zuordnen kann.

Oder wie Google es formuliert:

“Eine Sitzung wird als direkter Traffic verarbeitet, wenn keine Informationen zur Verweisquelle vorliegen oder die Konfiguration so vorgenommen wurde, dass die Verweisquelle oder der Suchbegriff ignoriert werden.”

Google hat auf seinen Supportseiten ein saukompliziertes Ablaufdiagramm publiziert. Das zu verstehen ist nicht ganz einfach, daher fasse ich im folgenden in aller Kürze mögliche unbekannte Quellen zusammen:

• Links aus einer E-Mail (das gilt insbesondere für E-Mail-Clients wie Outlook oder Apple Mail)
• Wechsel von einer https zu einer http-Seite
• Traffic aus Messenger-Diensten
• Links in einem PDF (oder einem anderen Dokument)
• eine Consent Management-Lösung, die nicht ganz sauber aufgesetzt wurde
• kann auch ein Indiz für eine nicht ganz saubere Google Analytics-Implementierung sein (z. B. wenn der Tracking-Code nicht auf allen Seiten installiert wurde)

Doch es geht noch ein wenig komplizierter. Folgendes Szenario:

• An Tag 1 bedienen wir in unserem Browser die Suchmaschine (nennen wir sie „Google“), werden fündig, klicken auf das Suchergebnis und landen auf www.beispieldomain.de
• An Tag 2 (wir kennen die Domain inzwischen) möchten wir die Seite erneut besuchen, geben die bekannte URL daher direkt in die Adresszeile unseres Browsers ein.

Welchem Traffickanal ordnet Google Analytics unserem ersten Besuch zu? Richtig, „google / organic“.

Und welchem Kanal wird unsere zweite Sitzung am Folgetag zugeordnet?
„(direct) / (none)“? Falsch. Richtig ist: „google / organic“

Warum ist das so? Betrachten wir oben kurz erwähntes Ablaufdiagramm, so fragt eines der letzten Entscheidungs-Shapes „Existing campaign data is within timout period?„. Das bedeutet, wenn Google Analytics innerhalb des Kampagnen-Zeitlimits (im Standard 24 Monate) eine Trafficquelle wiedererkennt und dem Besucher zuordnen kann und keine andere bekannte Quelle diese überschreibt, so wird diese der Sitzung als Quelle zugeschrieben.

Also, ist Direct Traffic jetzt schlecht?

Etwas Direct Traffic in den Akquisitionsberichten ist in Ordnung. Ich habe allerdings schon Google Analytics-Datenansichten betrachten, wo der Anteil an direktem Traffic über 50% des Gesamttraffics ausmachte. Und spätestens dann sollten die Alarmglocken schrillen, denn hier scheint etwas mit der Implementierung im Argen zu liegen.

Bis zu 15% Direct Traffic finde ich persönlich in Ordnung (die Definition eines Schwellenwertes hängt aber natürlich auch noch von anderen Faktoren ab). Doch wie lässt sich der Direct Traffic minimieren, sollte er beträchtlich darüber liegen?

Dieser Frage möchte ich im nächsten Blogpost auf den Grund gehen.

Habt Ihr dies bereits erledigt, könnt Ihr direkt in das Event-Setup Tool einsteigen. Dazu geht Ihr in Euren Facebook Business Manager, von dort aus in den Events Manager und dann in die Übersicht Eures Facebook Pixels.
Nun richtet Ihr ein neues Event ein.

Wählt als nächstes die Option “Verwende das Event-Setup-Tool von Facebook” aus und gebt im nächsten Dialogfenster die URL Eurer Website ein, auf der sich das Element befindet, das ein Event auslösen soll.

Entscheidet Euch, ob das Event in Form eines Buttons oder in Form einer URL getrackt werden soll.

Die von Euch ausgewählte Seite wird eingeblendet und die auszuwählenden Elemente werden hervorgehoben dargestellt (ein wenig erinnert dies an den Debug-Mode des Google Tag Managers). Entscheidet Ihr Euch z. B. für die “Add To Cart”-Buttons, so klickt Ihr einen solchen an.

Nun wählt Ihr den Event-Typ aus, der zu der Aktion, die das Element auslöst, am besten passt. Ihr könnt zwischen zahlreichen Typen (von E-Commerce-Events bis zu Standort-Suchen) entscheiden. Wir nehmen den Typ “In den Einkaufswagen”.

Als letzte Aktion schließt die Event-Konfiguration mit “Finish Setup” ab. Alles in allem sieht dieser Prozess denkbar einfach aus.

Ob und wie fehlerfrei das Event-Setup-Tool funktioniert, müssen wir an dieser Stelle noch herausfinden. Hier bietet sich aber ein Test der herkömmlichen Variante (z. B. die Steuerung mittels des Google Tag Managers) an, die dann im Parallelbetrieb läuft. Sind genügend Aktionen getrackt, können die Daten beider Varianten miteinander verglichen werden.

Tags wiederum sind Code-Schnipsel, die unterschiedliche Technologien initialisieren können, z. B.

• Web-Analyse-Software wie Google Analytics
• Marketing Tracking-Tools wie Facebook (Facebook-Pixel) oder Google Ads (Conversion-Tracking)
• A/B-Test bzw. Multivariat-Testing-Tools wie Google Optimize oder Optimizely

Welche Vorteile bringen Tag-Management-Systeme?

Der Einsatz eines Tag-Management-Systems bringt den Vorteil, dass dieses einmalig in den Quellcode der Website eingebunden werden muss und darüber in der Folge alle weiteren Analyse-, Tracking- und Marketingtools gesteuert werden können. Das bedeutet konkret, dass für diese Tools kein separater Trackingcode mehr in das HTML der Website eingebaut werden muss, sondern, dass diese Aufgabe der GTM-Container übernimmt (der Container ist eine Art Platzhalter – oder Code-Injector -, in dem verschiedene Kommandos aufgeführt werden können). Für viele Tools gibt es im Google Tag Manager Vorlagen: Hier ist es oftmals ausreichend, eine ID einzufügen, die das Nutzerkonto identifiziert.

Der Webanalyst oder Marketing-Manager eines Unternehmens macht sich gegenüber der IT bzw, Web-Entwicklung ein Stück weit unabhängiger, da nicht jede Anforderung wie das Einfügen eines Event-Tags in den nächsten Releasezyklus aufgenommen werden muss, sondern recht ad hoc – teilweise ohne große Kenntnisse von HTML, CSS und Javascript – selbst vorgenommen werden kann.

Weitere Vorteile des Google Tag Managers

• Für viele Tags gibt es Vorlagen
• Einsteigerfreundlich, gute Dokumentation
• Schwierig (aber nicht unmöglich!), etwas “kaputt” zu machen
• Integrierte Test-Umgebung (Debug-Mode)
• Sauberer Quellcode – alles wird aus einem zentralen Container-Code gesteuert

YouTube: Überblick über den Google Tag Manager