Tracking von AMP Seiten mit dem GTM / Teil 2 Events

Nachdem wir uns im ersten Teil dieser Miniserie damit beschäftigt haben, wie man die Seitenaufrufe von AMP Seiten in Google Analytics erfasst, geht es heute mit dem Event Tracking weiter. Wir sehen uns beliebte Klassiker unter den Events an und untersuchen ob und wie man sie für AMP Seiten umsetzen kann.

Click Tracking

GTM Container für AMP unterscheiden nicht mehr zwischen Linkclicks und allgemeinen Clicks. Es muss nun ein CSS Selektor benannt sein, der die Elemente beschreibt, auf deren Clicks der Trigger reagiert. Was hier auf den ersten Blick schmerzlich abgeht, sind Variablen wie die Click-URL. CSS Feinspitze haben dafür aber eine Lösung: den CSS Attributselektor.

Das beliebte Tracking von PDF-Downloads lässt sich damit mit folgendem Selektor umsetzen:

Für Laien übersetzt heißt das: erfasse Clicks auf alle <a>-Elemente (Links) deren Linkziel .pdf enthält.

Damit lassen sich für viele Situationen, in denen die Standardvariablen wie Click URL oder Click Ziel fehlen, Workarounds bilden.

Formular Tracking

Für das Abschicken von Formularen steht leider kein Triggertyp zur Verfügung. Allerdings funktioniert dieser auch bei HTML-Seiten nicht immer, weil nicht jedes Formular tatsächlich auch ein HTTP-Submit Event auslöst, auf das dieser Trigger reagiert. Als Workaround für Formulare ohne HTTP-Submit oder AMP-Formulare bieten sich die folgenden Alternativen an:

  • Seitenaufruf einer Danke- oder Bestätigungsseite
  • Visibility-Trigger für ein Danke- oder Bestätigungspopup
  • und zur Not den Click auf den Submit-Button – auch wenn das nicht unbedingt bedeutet, dass das Formular auch tatsächlich abgeschickt wurde, z.B. weil ein Pflichtfeld nicht ausgefüllt wurde.

Scrolltracking

Die gute Nachricht: es gibt Trigger und Variablen für Scrolltracking. Die schlechte Nachricht: die Variablen geben nur den absoluten Scrollfortschritt in Pixel an, keine Prozentwerte. Und mangels JavaScript kann man sich die auch nicht selber ausrechnen.

Wir setzen zwei verschiedene Arten von Scrolltracking ein: eine maximale Scrolltiefe, die als Event beim Verlassen einer Seite abgeschickt wird und ein Setup mit vordefinierten Prozentwerten (meist 25, 50, 75 und 100%), bei denen jeweils ein Event gefeuert wird.

Ersteres lässt sich für AMP-Seiten nicht umsetzen, zweiteres schon. Allerdings, will man den Scrollfortschrittt z.B. in das Ereignislabel schreiben, muss man für jede Schwelle einen eigenen Tag und einen eigenen Trigger anlegen. Bei der HTML Version ginge das mit einem Tag und einem Trigger.

Als Alternative zum Scrolltracking – nicht nur für AMP-Seiten – bietet sich ein Visibility-Tracking an. Was sagt es zum Beispiel aus, wenn ein Blogartikel eine Scrolltiefe von 50% hat? Bei einem langen Artikel, der noch keine Kommentare erhalten hat, dass der Besucher den Artikel zur Hälfte gelesen hat. Bei einem sehr kurzen Artikel mit vielen Kommentaren hat der Leser den Beitrag komplett gesehen – plus einen großen Teil der Kommentare.

Will ich aber wissen, wie viele Besucher meinen Artikel bis zum Ende gescrollt haben, macht es mehr Sinn, das Element nach dem Artikel mit einem Visibility-Event zu versehen. Social Media Icons, die Kommentarsektion oder eine Infobox zum Verfasser sind Elemente, die man oft unter Artikeln findet und die sich hier anbieten.

Visibility

Dieser Trigger löst immer dann aus, wenn ein bestimmtes Element am Bildschirm sichtbar wird. Leider lässt der Trigger in der AMP-Version nur HTML-IDs als Selektor zu und keine allgemeinen CSS-Selektoren. Dafür bietet der Trigger im Gegensatz zur HTML-Version neben einer Mindestsichtbarkeit in Prozent auch eine Maximale Sichtbarkeit zum Einstellen und die Mindestsichtbarkeitsdauer kann sowohl als Gesamtzeit auf der Seite, als auch als durchgehende Zeit definiert werden. Beides ist aber kein wirklich adäquater Ersatz für die Einschränkung auf IDs als Selektor.

Neben den bereits erwähnten Einsatzmöglichkeiten als workaround für Scroll- und Formulartracking bietet sich der Triggertyp vor allem für Impression-Tracking, z.B. von Werbebannern, internen Promotions oder Bilderkarussellen an:

Durch die Einschränkung des Selektors auf IDs eignet sich das Visibility-Tracking aber nur für Anwendungen mit wenigen Elementen. So ist der Aufwand für das Tracken der 5 Sujets im Heroshot noch akzeptabel, bei 200 Bildern einer Galerie vom letzten Firmenevent hingegen weniger.

Timings

Gerne setzen wir bei unseren Kunden ein Floodlight ein, das nach einer bestimmten Anzahl an Sekunden auf allen Seiten feuert. Wer länger auf einer Seite verweilt, dem darf auch ein gewisses Interesse an dem Produkt oder dem Inhalt unterstellt werden, und diese Information kann man für das Targeting nutzen. Oder Websitebetreiber wollen einen Besucher nicht mehr als Bouncer zählen, wenn er zum Beispiel mindestens eine Minute lang auf einer Artikelseite verweilt. In GTM AMP-Containern steht so ein Timer zur Verfügung. Neben dem Intervall kann auch eingestellt werden, wie lange der Trigger aktiv sein soll, zum Beispiel soll das Event alle 30 Sekunden ausgelöst werden, aber maximal 2 Minuten lang.

Ein Trigger, der nach einer bestimmten Zeit auf der gesamten Website auslöst, ist leider nicht möglich. Zwar gibt es eine entsprechende Variable, jedoch kann diese lediglich als Wert oder Dimension übergeben, aber nicht als Bedingung für einen Trigger genutzt werden.

Was fehlt?

Damit haben wir auch schon alle Trigger-Möglichkeiten für AMP-Seiten durch. Was sind nun die Optionen der Web-Container, die am meisten abgehen?

Video-Tracking

Da die Videoproduktion für Websites deutlich aufwendiger ist, als jene von Bildern oder Grafiken, wüsste man gerne ob sich der Aufwand lohnt. Leider gibt es trotz eigenem AMP-Element für die Einbettung von Youtube-Videos, aktuell in AMP-Containern keine Trigger und Variablen für Videotracking.

Benutzerdefinierte Ereignisse

Mangels voller JavaScript-Unterstützung kann man ohnehin kaum eigene Events an den GTM schicken, aber die Möglichkeit mittels RegEx all GTM-Events, egal ob Sichtbarkeit, Click oder Seitenaufruf zusammenzufassen, z.B. um einen Generalblocker für alle Tracking und Marketingtags zu erschaffen, wird schmerzlich vermisst.

Clicktext und URL

Zum Befüllen der Events fehlen leider beliebte Standardvariablen wie Clicktext oder Click-URL. Trotz ihres Namens können diese Variablen in Web Containern nicht nur bei Click-Events genutzt werden. Sie enthalten immer die Werte des zuletzt erfassten Elements, zum Beispiel des Werbebanners, dessen Erscheinen einen Visibility-Trigger ausgelöst hat.

Zwar kann man die meisten Anforderungen damit trotzdem erfüllen, aber in vielen Fällen heißt das, dass für jedes Element ein eigener Tag und Trigger angelegt werden müssen, wo in Web-Containern alle Elemente eines Typs(zum Beispiel alle Buttons auf einer Website) mit einem Tag und Trigger abgehandelt werden können.

Virtuelle Seitenaufrufe

Die fehlende Möglichkeit, die Seiten-URL, die an Google Analytics verschickt wird, macht virtuelle Pageviews leider unmöglich. Ebenso ein Umschreiben von einzelnen URLs weil diese zu lang oder zu unleserlich sind, oder weil man einfach die Parameter abschneiden will, um in Analytics nicht dutzende Zeilen für ein und die selbe Seite zu haben.

Als Workaround für die virtuellen Seitenaufrufe, um die einzelnen Sektionen einer Single Page Application oder die Teilschritte eines Formulars zu erfassen, bieten sich aber Events mit einem Visibility-Trigger an.

Marketing Pixel

Für Google Ads und Floodlights stehen – wie gewohnt – Remarketing- und Conversion-Tags zur Verfügung. Die Frage ist, ob man die benötigten Trigger und Variablen mit den Bordmitteln des AMP-Containers umsetzen kann.

Problematisch wird es aber bei Facebook Tags: da es hier wie bei HTML-Containern keine vordefinierten Tags gibt, und JavaScript nicht zur Verfügung steht, muss man bei den AMP-Seiten leider auf Facebook Remarketing verzichten. Das Gleiche gilt übrigens auch für andere Social Media Plattformen wie Twitter oder linked.In.

Fazit

Die Möglichkeiten, Nutzerinteraktionen auf AMP-Seiten zu erfassen, sind aktuell noch sehr eingeschränkt. Das liegt zum Großteil an AMP selber. Man darf sich nicht erwarten, das Tracking der HTML-Seiten 1:1 für die AMP-Seiten nachbauen zu können, aber mit ein wenige Aufwand und eventuell Kreativität sollte es möglich sein, die wichtigsten Interaktionen abzubilden. Die geplante Öffnung von AMP für eigenen JavaScript-Code könnte in naher Zukunft die Möglichkeiten stark erweitern.

Ein guter Anhaltspunkt, wie viel Sie in das Event-Tracking Ihrer AMP-Seiten investieren sollten, ist wie groß der Anteil der AMP-Sitzungen an Ihrem Gesamttraffic ist. Wie Sie diesen Anteil in Analytics sichtbar machen, lesen Sie im ersten Teil dieser Miniserie.

Noch Fragen? Die e-dialog Webanalyse ExpertInnen helfen Ihnen gerne weiter: Kontakt

Hinterlassen Sie einen Kommentar: