iFrame Tracking: Data Layer Events clever mit postMessage übertragen
Management Summary
Mehr Kontrolle über Ereignisse innerhalb von iFrames: Mit der postMessage Methode landen alle relevanten Data Layer Events zuverlässig im Tracking.
Der Data Layer
Der Data Layer ist eines der wichtigsten Instrumente im Tracking. Er dient nicht nur dazu, Events zu triggern, sondern enthält als sogenannte Datenschicht zwischen der Website und dem Tag Manager auch viele fürs Tracking wichtige Daten.
Wenn man ein normales Tracking über den GTM aufsetzt, ist es keine große Herausforderung, auf den Data Layer zuzugreifen. Mittels der vorgefertigten Data Layer Variablen schafft man es, innerhalb weniger Klicks bestimmte Objekte in der Datenschicht zu erreichen.
Spezialfall: iFrame
Ein iFrame ist ein sogenannter Fremdinhalt – er wird zwar in die Webseite eingebunden, stammt aber meist von einer anderen Origin. Die Origin ist im Prinzip die Adresse einer Website und setzt sich aus dem Protokoll, der Domain und dem Port zusammen. Man kann unterscheiden, ob zwei Websites von der gleichen, oder von unterschiedlichen Origins stammen:
Gängige Beispiele für iFrames sind Youtube-Videos, Formulare aber auch Anwendungen von Drittanbietern, mit denen die Nutzer auf der Website interagieren können.
Wer seine Website analysiert, möchte natürlich auch wissen, was innerhalb dieser iFrames passiert. Das Problem: Methoden wie der Data Layer funktionieren nicht innerhalb des iFrames. Oder besser gesagt: man kann von der Website, in welcher der iFrame eingebunden ist, nicht darauf zugreifen.
Der iFrame selbst kann also einen Data Layer enthalten, die sogenannte Same-Origin-Policy verbietet jedoch, dass der Parent (=die Website) auf die Inhalte aus dem iFrame zugreift und umgekehrt.
Was aber, wenn innerhalb des iFrames ein wichtiges Ereignis passiert, welches ich unbedingt analysieren möchte? Grundsätzlich wäre es auch möglich, den GTM innerhalb des iFrames zu verbauen, dies kann aber, wenn man nicht vorsichtig ist, zu Risiken führen. Beispielsweise kann das zu doppeltem Tracking führen oder einer unsauberen User Journey.
Die einfachere und sicherere Methode: Data Layer Events via postmessage an den Parent senden.
Kommunikation via postMessage
Unter postMessage versteht man eine JavaScript-Methode zur Cross-Origin Kommunikation. In einfachen Worten: der Austausch zwischen zwei getrennten Objekten im Browser, die nicht den gleichen Ursprung haben. Ein Beispiel dafür ist der bereits genannte iFrame innerhalb der Website.
Mit der postMessage Methode haben wir eine Möglichkeit, eine sichere Kommunikation zwischen den beiden stattfinden zu lassen, ohne die Same-Origin-Policy zu verletzen. Diese Kommunikation besteht immer aus zwei Teilen: Dem Sender und dem Empfänger.
Der Sender (in diesem Anwendungsfall: der iFrame) schickt die Message an den Empfänger (die Website) und verwendet dafür die postMessage Methode.
Basis Syntax:
message = Die Nachricht, die an den Empfänger gesendet werden soll als JS Objekt
targetOrigin = Die Origin des Empfängers. Diese sollte immer explizit gesetzt werden! Ein Whitelisting mittels * ist zwar möglich, sollte aber aus Sicherheitsgründen vermieden werden.
Der Empfänger greift die message später mittels eines Event Listeners auf.
Schritt-für-Schritt Anleitung
Jetzt haben wir zwei Komponenten kennengelernt: den Data Layer und die postMessage Methode. Wie man nun die Daten clever mithilfe dessen aus dem iFrame an den Parent GTM übertragen kann, wird im Folgenden erklärt:
1. Data Layer Event definieren
Definiere im iFrame wie gewohnt, was du in dein Data Layer Event senden möchtest. Beispielsweise:
2. In postMessage einfassen
Jetzt kombinierst du die postmessage Syntax mit deinem Data Layer Objekt und baust folgenden Code-Baustein in deinen iFrame ein, wo du normalerweise den Data Layer push machen würdest:
Wir verwenden hier window.top, weil wir die Message aus dem iFrame heraus direkt an das Parent Window senden wollen.
JSON.stringify dient dazu, das Javascript Objekt in ein JSON umzuwandeln, damit es vom Parent später leichter entgegengenommen werden kann. Dies ist nicht zwingend notwendig, aber hilft dabei, Syntax Fehler zu vermeiden.
Mit diesem Schritt hast du nun den Teil des Sendens abgeschlossen. Jetzt kommt der Empfänger ins Spiel.
3. Im GTM entgegennehmen und in den Data Layer pushen
Jetzt geht es weiter innerhalb des Google Tag Manager Containers, welcher im Parent verbaut ist. Du erstellst einen neuen Custom HTML Tag im GTM:
Im ersten Schritt wird ein Event-Listener auf alle “message” Ereignisse gesetzt. Damit reagiert die Website auf die postMessage und führt im Folgenden die Funktion aus. Auch hier ist es wichtig, die Origins explizit zu setzen und zu überprüfen, um sich vor bösartigen messages zu schützen. Im Anschluss wird das Objekt wieder zerlegt und genau so, wie es empfangen wurde, in den Data Layer gepusht.
Gratulation: wenn du alles richtig gemacht hast, siehst du das Event über die GTM Preview kurz darauf bereits im Data Layer:
Race Conditions: Achtung vor Fallstricken!
Ein gängiger Stolperstein in Verbindung mit dieser Tracking-Methode sind die sogenannten Race Conditions. Das bedeutet, dass es bei einem falschen Timing oder einer nicht korrekt ausgeführten Reihenfolge der Events zu Problemen kommen kann. Wenn nämlich der iFrame bereits Events an den GTM senden möchte, während dieser gegebenenfalls noch gar nicht bereit dafür ist, gehen die Ereignisse möglicherweise verloren. Daher achte darauf, dass du den Trigger für deinen GTM Tag so früh wie möglich setzt – am Besten auf die Initialisierung. Und am Besten hilft wie immer: Testen, Testen, Testen. Simuliere wie gewohnt alle deine Tracking-Events im iFrame und stell sicher, dass die gesendeten Daten auch tatsächlich im Data Layer landen.
Fazit
Das Tracking von iFrames muss nicht immer schwierig sein. Mit der postMessage Methode kannst du im Handumdrehen deine Data Layer Events sicher an den Parent senden. Und das Beste: Im GTM musst du den Empfänger nur einmal einrichten.
