Markus Baersch

Der Tag Manager von Piwik PRO kennt (derzeit) weder Element-Visibility Trigger noch Trigger-Gruppen. Dieser Beitrag zeigt, wie man sowohl die Sichtbarkeit von Elementen als Trigger in Piwik PRO nutzen, als auch (mit Einschränkungen) weitere Bedingungen hinzufügen kann, um das Verhalten von Trigger-Gruppen zu simulieren.

Mit dem Start der Beta-Phase für Piwik PRO Core habe ich mir gesondert auch den Tag Manager angesehen (Video dazu) und setze ihn seither auf meiner Website einschließlich des integrierten Consent-Managements selbst ein. Für viele - aber freilich nicht alle - Aufgaben, ist er ebenso geeignet, wie der Google Tag Manager, wenn damit Seitenaufrufe und ein paar typische Events vermessen werden sollen. Auch E-Commerce etc. sind kein Thema. Da der kostenlose Core-Plan zum offiziellen Start sogar auf 500.000 Hits ausgebaut wurde, ist also eine Vermessung von mehr als nur Seitenaufrufen auch bei Piwik PRO für viele Websites realistisch durchführbar.

Content-Vermessung im Piwik PRO Tag Manager

Wenn es um die Vermessung von Content und Interaktion damit geht, können die üblichen Klick-Trigger eingesetzt werden. Oder meinethalben auch Timer oder die automatisch ausgelösten Scroll-Events. Oder vielleicht lieber nicht, weil z. B. Scrolltracking wenig bis keine Aussagekraft hat und vor allem Hits verschwendet.

Wenngleich Piwik PRO aber "von Haus aus" mit Element-Sichtbarkeit im Rahmen des Content-Trackings unter Verwendung von data-Attributen arbeiten kann, gibt es keine entsprechenden Trigger im Tag Manager. Das ist übrigens einer der Punkte, an denen der Matomo Tag Manager seinem Piwik-Pendant überlegen ist. Wer dennoch die Einblendung bestimmter Elemente in Piwik PRO vermessen will, muss sich mit IntersectionObservern in HTML-Tags behelfen, um darüber Events in die Datenschicht zu schreiben.

Sichtbarkeit als Trigger nutzen (und optional mit Zeit verknüpfen)

Um auch in Piwik ansatzweise die Funktion einer Trigger-Gruppe aus einem Timer, der erst nach Erreichen einer berechneten Lesezeit feuert und der Sichtbarkeit eines bestimmten Elements nachzubauen, habe ich ein entsprechendes Tag erstellt. Dieses kann entweder die erste oder alle Einblendungen beliebiger anhand von CSS-Selektoren bestimmbarer Elemente als Trigger-Events in die Datenschicht schreiben. Optional kann dabei angegeben werden, welche Mindestzeit seit dem Laden der Seite vergangen sein muss, damit das Messevent / die Events erfolgen.

Das Google Tag Manager Beispiel, auf dem dieses Szenario basiert, ist die Lesedauer eines Blogbeitrags in Kombination mit der Sichtbarkeit eines Elements am Ende jedes Blogposts. Es wird hier als Anwendungsbeispiel für Trigger-Gruppen beschrieben.

Mit dem HTML-Tag, dessen Code hier auf GitHub zu finden ist, kann dieses Beispiel nachgebaut werden - fast. Eine Kröte, die man fressen muss: Bei echten Trigger-Gruppen ist es egal, in welcher Reihenfolge die beteiligten Trigger feuern müssen. Erst wenn der letzte der in der Gruppe enthaltenen Trigger ausgelöst hat, feuert auch die Gruppe. Das bedeutet für das Beispiel, dass man das Ende eines Beitrags zuerst erreichen und erst dann die Zeit ablaufen kann. Im HTML-Workaround für den Piwik PRO Tag Manager wird hingegen das Event nur ausgelöst, wenn das erste über den CSS-Selektor auffindbare Element sichtbar wird, nachdem die definierte Zeit vergangen ist. Ist das Ende des Blogposts also schon sichtbar, bevor die Zeitschwelle erreicht ist, feuert das Event nicht; bzw. nur dann, wenn das Ende nochmal aus dem Sichtbereich gescrollt und danach erneut sichtbar wird. Daher wird im Code des Tags in der dort optional berechneten Lesezeit auch von einem "sehr schnellen" Leser ausgegangen. Hinweis: Wenn diese Funktion genutzt werden soll, unbedingt den Selektor für den Hauptinhalt bzw. Container des Blogposts o. Ä. anpassen (je nachdem, welcher Inhalt vermessen werden soll).

Dabei ist aber die Verknüpfung von Sichtbarkeit und Zeit kein Zwang. Mit dem Tag kann ebenso gut auch jedes oder nur das erste Sichtbarkeits-Event eines Elements vermessen werden.

Verwendung des Tags

1. Ein neues benutzerdefiniertes (synchrones) Tag anlegen und den Code von GitHub aus der Rohansicht ("Raw") kopieren und im neuen Tag einfügen. Zunächst können die Kommentare am Anfang des Codes entfernt werden, da dies im Gegensatz zum Google Tag Manager nicht automatisch durch Optimierung / Minimierung des Codes beim Ausliefern von Piwik PRO Tag Containern geschieht. Puristen können Tag Codes auch komplett minimieren, wenngleich das freilich der Les- und Pflegbarkeit nicht unbedingt förderlich ist.
2. Am Ende des Codes findet sich zunächst die Funktion zur Berechnung der Lesezeit. Hier zumindest den Selektor für den Blog-Content anpassen - über eine ID, eine Klasse oder alles andere, was von document.querySelector gefressen wird. Ist die Berechnung für den geplanten Einsatz nicht erforderlich, weil nur generelle Sichtbarkeit vermessen oder mit einer konstanten Zeitschwelle auf allen Seiten gearbeitet werden soll (z. B. Sichtbarkeit des Footers nach wenigstens 5 Sekunden), kann die komplette Funktion minimalReadingTime() ebenso wie die Kommentare entfernt werden.
3. Darunter werden dann die Funktionsaufrufe von minimalReadingTime()hinzugefügt - eine für jedes zu vermessende Element, für das Ereignisse in die Datenschicht geschrieben werden sollen. Die beiden auskommentierten Beispiele aus dem Code zeigen die einmalige Vermessung der Sichtbarkeit des "Blog-Footers" (ein Absatz der Klasse "nlink") nach der Lesezeit (analog zum oben verlinkten GTM-Anwendungsbeispiel) oder des Seitenfooters (selektiert über die der Id "footer") nach konstanten 2 Sekunden. Der Paramater timing für die Mindestzeit wird in Millisekunden definiert - oder mit "0" weggelassen, wenn der dritte Parameter unique z. B. abweichend von der Vorgabe mit true belegt werden soll, um nur das erste Erscheinen des Elements zu vermessen (sonst löst jede Einblendung ein Event aus).

Weitere Beispiele finden sich auch im Kommentar zum Code bei GitHub. Damit das Tag genutzt werden kann, ist noch ein passender Trigger erforderlich. Dieser muss ggf. noch angelegt werden:

Trigger anlegen

1. Das Tag selbst braucht einen Trigger, der erst dann auslöst, wenn alle Elemente, die beobachtet werden sollen, bereits existieren. Daher ist es empfehlenswert, einen Seitenaufruf-Trigger anzulegen bzw. zu nutzen, welcher erst nach dem Laden der Seite auslöst. In Piwik PRO ist das das DOM-Lifecycle Event "Page Load" bzw. "Seitenladen" in der deutschen Übersetzung.
2. Ebenso wird noch ein Trigger für die Messung der Sichtbarkeits-Events benötigt, der auf dem vom HTML Tag ausgelösten Data Layer Event basiert. Als Event Name wird "tvo.visibility" angegeben. Wenn mehrere Elemente über das Tag vermessen werden, kann als Bedingung das auslösende Element abgefragt werden. Dazu kann über eine Datenschicht-Variable für den Schlüssel "visibilityElement", der zusammen mit dem Event im Tag im dataLayer abgelegt wird, eine Bedingung angelegt werden. Das Element wird nach dem Muster tagtyp#id.klasse1.klasse2.klasse3 identifiziert. Dadurch ist es möglich, CSS-Selektoren wie "#idname" oder ".klasse" in Vergleichen zu nutzen ("regexp" oder "enthält"). Ein Absatz (p) ohne Id und mit der Klasse "nlink" aus dem Anwendungsbeispiel würde also so als Bedingung verwendet:
   

Trigger nutzen

Mit dem zweiten erzeugten Trigger für die Sichtbarkeit des gewünschten Elements kann nun z. B. ein Tag vom Typ "Piwik PRO benutzerdefiniertes Event" angelegt und ausgelöst werden. Wahlweise kann auch bei allen Sichtbarkeitsereignissen gefeuert und der Name des eingeblendeten Elements wie oben beschrieben aus dem dataLayer gelesen und im Event verwendet werden.

Alternativen und Ergänzungen

Prinzipiell kann mit einem IntersectionObserver jede beliebige Kombination von Elementen vermessen werden. Auch die dortigen Optionen sind einsetzbar, um die Funktion erst dann auszuführen, wenn ein bestimmter Umfang des Elements sichtbar ist und nicht beim ersten erscheinenden Pixel im Viewport bereits eine Auslösung erfolgt, wie es derzeit der Fall ist. Auch ist es denkbar, bei Einblenden des Elements vor Ablauf der Zeitspanne für die Restzeit ein per Timeout passend ausgelöstes Events zu implementieren, so dass das Verhalten einer Trigger-Gruppe besser nachgebildet wird.

Generell soll der Beispielcode nur genau das sein: Ein Beispiel. Wenn es dazu angeregt hat, den Piwik PRO Tag Manager über die eingebauten Trigger hinaus zu verwenden, dann hat es seinen Zweck erfüllt 😉