Tracking von AMP Seiten mit dem Google Tag Manager / Teil 1 Seitenaufrufe

Was sind AMP-Seiten?

AMP – ursprünglich stand das für Accelerated Mobile Pages – ist eine Scriptsprache für (mobile) Webseiten, die dem HTML sehr ähnlich ist. Die Idee dahinter ist, dass durch Caching, stark eingeschränktes JavaScript und die weitgehende Vermeidung externer Ressourcen (wie z.B. externe CSS Dateien) das Laden und das Rendern von Websites deutlich schneller wird. Hauptanwendungsgebiet von AMP sind die mobilen Versionen von statischen Inhaltsseiten. Es eignet sich mehr für Newsbeiträge, als für den Neuwagenkonfigurator und ist dementsprechend vor allem – aber bei weitem nicht ausschließlich – bei Publishern und Blogs im Einsatz.

Mehr zu AMP in einem älteren Blogartikel von uns

Was bringt das?

Aus SEO Sicht sind AMP-Versionen von Webseiten besonders interessant, weil dies einen doppelten Bonus in Googles Suchmaschinenranking bedeutet: einerseits durch die schnellere Ladezeit, andererseits ist die Existenz einer AMP-Version einer Seite selbst schon ein Bonus bei Google: bei der Suche von einem mobilen Endgerät aus, wird dies wohlwollend berücksichtigt und in den Ergebnislisten mit einem kleinen Blitzsymbol (siehe Screenshot) angezeigt.

Was bedeutet das für mich?

Wichtigste Eigenschaft für den Frontendentwickler ebenso wie für den Webanalysten ist die Tatsache, dass man keine eigenen JavaScripts verwenden kann. AMP erlaubt nur eigene, vorgefertigte Anwendungen aus der AMP JS Bibliothek. Zumindest aktuell, eine Öffnung für eigenes JavaScript steht im Raum. Bis dahin müssen wir aber auch beim Tracking einige Einschränkungen hinnehmen. Wir sehen uns an, was aktuell geht und was nicht.

Google Tag Manager für AMP-Seiten

Wie auch für herkömmliche HTML-Seiten verwenden wir den Google Tag Manager. Erster Schritt ist das Einrichten eines eigenen GTM-Containers.

Der GTM listet uns zwei Code Snippets, die wir auf unseren AMP-Seiten einbauen müssen. Oder falls das AMP-Modul des Content Management Tools eine Option hat, GTM Container einzubauen, muss man nur noch die Container-ID in das passende Formularfeld eintragen.

AMP Seitenaufrufe tracken

Das Tracking von AMP-Seitenaufrufen bzw. Sitzungen ist ein stark vernachlässigtes Thema. Dabei ist es genauso einfach und schnell einzubauen wie auf HTML-Seiten. Wenn Sie AMP-Versionen ihrer Webseiten anbieten, empfehlen wir auf jeden Fall, die Aufrufe dieser AMP-Seiten separat zu erfassen. Sobald Sie einschätzen können, wie relevant AMP-traffic für Ihre Website ist, können Sie entscheiden, wie viel Aufwand Sie in das Event-Tracking stecken wollen.

Eigenes oder bestehendes Property?

Zunächst stellt sich die Frage, ob für die AMP-Seiten ein eigenes Property in Google Analytics erstellt werden soll. Da es sich aber meist um die gleichen Inhalte handelt, wie bei der HTML-Version, empfehlen wir, die Daten in das bestehende GA Property zu schreiben.

Einrichten des Analytics Pageview Tags

Leider gibt es für AMP-Container keine Settings-Variable wie in Web-Containern. Somit müssen Einstellungen für Seitenaufrufe und Events für alle Tags händisch vergeben werden. Es empfiehlt sich daher, die Property ID in einer Variable vom Typ Konstante im Tag Manager anzulegen:

In den einzelnen Analytics Tag wird dann mit Hilfe des Legosteins die entsprechende Variable ausgewählt, anstatt die ID direkt einzutragen. Damit muss man zumindest nicht bei jedem neuen Tag die Property ID nachschlagen und ein allfälliger Wechsel des Properties ist schnell umzusetzen.

Die Einstellungen für den Analytics Request fallen weg. Die Requests werden automatisch mit anonymisierten IP-Adressen verschickt, aber die URL kann z.B. nicht händisch gesetzt werden, womit etwa keine virtuellen oder bereinigten Seitenaufrufe umgesetzt werden können.

Modifizieren kann man den Seitenaufruf nur durch das Hinzufügen von benutzerdefinierten Dimensionen und Metriken. Die Quellen für benutzerdefinierte Dimensionen sind sehr eingeschränkt. JavaScripts stehen nicht zur Verfügung und damit auch all die wertvollen Informationen, die wir für das HTML-Tracking bereits in den dataLayer schicken. Auch Cookies können nicht ausgelesen werden.

Statt dem dataLayer kennt das Tracking von AMP-Seiten AMP-Variablen. Diese müssen beim Aufruf des GTMs mitübergeben werden:

Im GTM gibt es dann einen Variablentyp AMP-Variable, mit dem diese Informationen ähnlich den dataLayer Variablen im Web-Container ausgelesen werden können:

Vermutlich wird man einen All Pages-Trigger für den Seitenaufruf wählen, und falls nicht, dann einen Trigger vom Typ URL, in dem man die gewünschten Seiten definiert. Dabei fällt auf, dass AMP Container nicht mehr zwischen den GTM events pageview, DOM ready und window loaded unterscheidet.

AMP und HTML traffic unterscheiden

Wenn wir AMP- und HTML-Aufrufe getrennt voneinander auswerten wollen, gibt es mehrere Möglichkeiten:

1. URL

Werden Ihre AMP-Seiten von einem Modul ihres CMS erstellt, dann erhalten sie meist eine URL, in der amp irgendwo vorkommt. Die AMP-Version der URL

www.beispiel.blog/10-gruende-fuer-amp-tracking/

könnte dann etwa so aussehen:

www.beispiel.blog/10-gruende-fuer-amp-tracking/amp/

oder

amp.beispiel.blog/10-gruende-fuer-amp-tracking/

Die erste Variante mit einer zusätzlichen Seitenpfadebene ist leicht in der Seitenansicht erkennbar. Für die Variante mit der Subdomain muss man noch eine sekundäre Dimension Hostname hinzufügen.

2. Benutzerdefinierte Dimensionen

Eine andere Möglichkeit, zwischen HTML- und AMP-Aufrufen zu unterscheiden ist eine Benutzerdefinierte Dimension mit dem Scope hit. Über den GTM geben wir an diese Dimension für jeden Seitenaufruf und jedes Event die Information mit, ob diese Interaktion auf einer AMP- oder HTML-Seite ausgeführt wurde.

3. Eigene Datenansichten

Egal ob URL oder benutzerdefinierte Dimension: beide können als Filter für eigene Datenansichten genutzt werden. Zum Beispiel könnte man eine Datenansicht für die AMP-Seiten, eine für die HTML-Seiten und eine gemeinsame Datenansicht erstellen. Für die AMP-Datenansicht kann dann dieser URL-basierte Filter verwendet werden:

Eine andere Möglichkeit ist, anstatt auf die URL auf die benutzerdefinierte Dimension aus Variante 2 zu filtern.

Für die HTML-only Datenansicht wählt man dann einfach Ausschließen anstatt Einschließen.

Wenn wir eine AMP-Kennung im Seitenpfad haben, dann bietet es sich an, diese zumindest in der gemeinsamen Datenansicht zu entfernen. Dazu nutzen wir einen Suchen und Ersetzen-Filter in der Datenansicht:

Damit scheinen dann sowohl die HTML- als auch die AMP-Aufrufe der Seite unter dem gleichen Seitenpfad auf und können sehr einfach gemeinsam ausgewertet werden. Für die getrennte Auswertung haben wir ja die eigenen Datenansichten, die benutzerdefinierten Dimensionen und evtl. den Hostname.

Und was ist mit App+Web properties?

Aktuell gerade in einer public Beta befinden sich die Web+App properties, Analytics properties, in denen Daten von Websites und Apps miteinander kombiniert werden können. Leider gibt es momentan noch keine vordefinierten Tags in AMP-GTM-Containern und mangels JavaScript-Tag kann auch nicht einfach der gtag-Code benutzt werden. Somit müssen wir aktuell leider darauf verzichten, AMP-Seiten in Web+App properties zu erfassen. Sobald es hier Neuigkeiten gibt, erfahren Sie es hier am e-dialog Blog.

Freuen Sie sich außerdem auf Teil 2 der Serie: Event-Tracking für AMP-Seiten.