Zurück zu allen Wissensbeiträgen

Analytics-Manipulation durch Google Tag Manager Container Kidnapping

Vor kurzem wurde ich mit der Frage konfrontiert, was passieren würde, wenn jemand anderer meinen Google Tag Manager Container einfach auf seiner Website installiert. Also quasi “GTM-Container-Kidnapping”. Lies weiter, dann erfährst du es …

Tja, ehrlicherweise war ich mir da auch nicht ganz sicher im Vorfeld. Aber da das durchaus eine sicherheitsrelevante Frage ist, wollte ich dem auf den Grund gehen.

Das erfährst du hier

  1. Was könnte passieren?
  2. Was passiert bei Container-Code-Kidnapping? Testszenario.
  3. Das kannst du gegen Container-Kidnapping tun.
  4. Fazit

Was könnte bei Container-Code-Kidnapping passieren?

Zunächst einmal hatte ich unmittelbar die Befürchtung, dass alle Tags, die auf meiner “eigentlichen” Seite feuern, nun auch auf der anderen Seite zu finden sein werden. Inklusive Analytics-Tracking, Drittanbieter-Pixel usw. Aber ganz sicher war ich mir da nicht.

Ich fragte bei meinem Podcast-Gast Cem Alkan nach, der sich ebenfalls sehr gut mit dem Google Tag Manager auskennt. Seine Antwort:

Die schnelle Antwort von Cem

Allerdings war da noch das Wort “theoretisch” und dahinter verstecken sich doch diverse Unwägbarkeiten. Ich wollte es also “praktisch” erfahren.

Das passiert wirklich, wenn der Container-Code gekidnappt wird

Ich habe also auf einer meiner Websites den ursprünglichen Google Tag Manager Container Code herausgenommen und einen anderen (von einer anderen Domain) eingebaut, mit allem, was dazu gehörte: GA Tracking, diverse Pixel und Co.

Und was soll ich sagen: Zumindest beim Analytics-Tracking passierte zunächst nichts. Zwar feuerte das Pageview Tag ordnungsgemäß (s. Screenshot im Debug-Modus des Tag Managers) …

Das Pageview-Tag für Google Analytics (untere Reihe) feuerte ordnungsgemäß, Screenshot aus dem Tag Manager Debug Mode

… jedoch wurde in Google Analytics in der Echtzeit-Ansicht kein Traffic aufgezeichnet. Bei näherem Hinsehen wurde jedoch klar warum.

Wenn man im Debug-Modus des Tag Managers die einzelnen Tags klickt (s. oben), erfährt man schnell, mit welchen Werten das Tag ausgelöst hat. Beim Klick auf das Pageview-Tag gab es die Erkenntnis: Es wurde keine Tracking-ID/Google Analytics Property zum Absenden genutzt. Dementsprechend wusste das Tag nicht, in welche Analytics-Property es den Pageview schicken sollte.

Aha. Das war ja erstmal gut. Offenbar funktioniert das Kidnapping des Containers nur bedingt.

AAABER!

Meine Konfiguration sieht beinahe immer Suchtabellen vor, die zum Beispiel bei verschiedenen Hosts oder bei Nutzung des Debug-Modes unterschiedliche Property-IDs zurückgeben. Das mache ich, um zu verhindern, dass bei Tests auf der Website die “echten” Analytics-Daten leiden, also durch Falsch-Daten zu ihrem Nachteil verändert werden.

Wenn jetzt die “fremde” Domain nicht in der Suchtabelle zu finden ist, weiß das Tag natürlich nicht, an welche Property die Daten rausgehen. Zumindest dann nicht, wenn kein Haken bei “Standardwert hinzufügen” gesetzt wurde (s. Screenshot).

Wenn kein Haken gesetzt ist, kann hier schonmal weniger passieren.

Sollte der Haken gesetzt sein, wird immer, wenn ein Eingabe-Wert in der Suchtabelle nicht gefunden wurde, ein Standardwert genommen, den man selber definieren kann.

Statt das zu tun, habe ich in der Tag-Konfiguration nun “hart” die Live-Analytics-Property eingebunden, um zu provozieren, dass das Tracking verfälscht wird …

Die Property ID wurde nun “hart” eingefügt (hier eine Beispiel-ID)

… und dann passierte leider im Analytics-Konto das hier:

In der Echtzeit-Ansicht in GA wurde der Traffic nun aufgezeichnet.

Es wurde also mithilfe des gekidnappten Container-Code Analytics-Traffic aufgezeichnet. Das war natürlich “unschön”. Denn das öffnet denen Türen, die manipulieren wollen.

Was kannst du gegen Container-Kidnapping tun?

Tja, ich bin ein lösungsorientierter Mensch, also gibt’s natürlich auch Vorschläge, wie du dein Analytics-Konto gegen so etwas wappnen kannst.

1. Lösung: Mit Filtern in Google Analytics arbeiten

Wenn ein GTM-Container oder ein Google-Analytics-Tracking-Code auf einer anderen Website außer deiner eingebunden wird, entsteht der Traffic nicht auf deiner Domain, sondern auf der fremden. Logisch soweit.

In Google Analytics wird aufgezeichnet, auf welcher Domain, respektive welchem Host der Traffic aufgezeichnet wird. Den dazugehörigen Bericht findest du unter “Zielgruppe” > “Technologie” > “Netzwerk” und dort musst du oberhalb der Tabelle “Hostname” klicken (s. Screenshot):

Im Bericht “Netzwerk” findet sich auch der Host, auf dem Traffic stattfand.

Die gute Nachricht: Du kannst verhindern, dass Traffic außerhalb deiner eigenen Domain in Analytics aufgezeichnet wird.

Dafür kannst du in der Verwaltung deines GA-Kontos auf Datenansichtsebene einen speziellen Filter setzen, der nur dann Traffic zulässt, wenn er von einem Host kommt, den du gutheißt, meistens der eigenen Domain (manchmal aber auch den Domain, auf denen du freiwillig trackst, etwa Google Übersetzerseiten, Mailchimp usw.).

Die Filterkonfiguration, wenn du ausschließlich auf deiner kompletten eigenen Domain tracken möchtest, könnte also zum Beispiel so aussehen: “Einschließen” > “Filterfeld = Hostname” > “Filtermuster = meinedomain\.de”. Wenn du nur www. und keine andere Subdomain zulassen möchtest: “Filtermuster = www\.meinedomain\.de”. Falls du Google-Übersetzer-Seiten zulassen möchtest UND deine komplette eigene Domain, schreibst du in das Filterfeld einfach “translate\.googleusercontent\.com|meinedomain\.com”. Da gibt es natürlich noch wesentlich mehr Beispiele. Aber du erkennst das Prinzip.

In der Datenansicht einen neuen Filter setzen

Filter anlegen, der nur Traffic auf dem eigenen Host zulässt

Ganz nebenbei kann man mit dieser Methode auch einem Großteil sonstiger Google-Analytics-Spammern das Handwerk legen (s. auch dieser Beitrag zum Spam verhindern).

2. Lösung: Suchtabelle mit Hostname im Google Tag Manager nutzen

Wer im Google Tag Manager ein Google Analytics Pageview Tag (oder auch jedes andere, wie zum Beispiel Eventtracking und Co.) anlegt, muss an bestimmter Stelle, die Property ID mitteilen.

Wie schon erwähnt, nutze ich an der Stelle meist Suchtabellen, um abhängig vom Host der Seite oder sonstigen Gegebenheiten dem Tag unterschiedliche Property-IDs mitzugeben. So kann ich etwa steuern, dass der Traffic auf www.metrika.de an eine andere Analytics-Property gesendet wird als der Traffic auf hierunddort.metrika.de. Und das mit nur einem einzigen Tag in nur einem Tag Manager Container.

Der Verweis auf die Suchtabelle im GA-Pageview-Tag

Die Suchtabelle selbst ist eine Variable vom Typ “Suchtabelle”. Wie sie aussieht, hier nochmal als Beispiel.

Ihr einziger Job ist, zu überprüfen: “Auf welchem Host wird das Tag gefeuert?” und dementsprechend wird die entsprechende Analytics-Property-ID zurückgegeben.

Bitte hier im Sinne der Fake-Abwehr aber daran denken: KEINEN HAKEN SETZEN BEI “Standardwert festlegen”! Oder dann zumindest keine Live-Property-ID nutzen.

Bitte keinen Haken setzen oder eine unverfängliche Property-ID nutzen!

Denn ansonsten wird Traffic auf jedem Host, den die Tabelle nicht “kennt”, dorthin gemeldet.

3. Lösung: Blocking Trigger im Google Tag Manager

Die gerade genannten Lösungen funktionieren für Google Analytics super. Aber wenn ich jetzt zum Beispiel überhaupt kein Tag auf einem anderen Host feuern möchte?

Standardmäßig wird das Google Analytics Pageview Tag etwa mithilfe des Triggers “All Pages” auf allen Seiten ausgespielt, auf denen der Tag Manager stattfindet.

Du musst jetzt also einen oder mehrere Custom Trigger bauen oder deine bestehenden Trigger ergänzen, die nur auf den gewünschten Hosts auslösen, also auf deiner Website, die bei deinen Tags als Auslöser dient. Hier im Beispiel mal der “All Pages”-Trigger. So geht’s:

Einfach einen neuen Trigger anlegen, der den Systemstandard-Trigger “All Pages” ablösen kann:

  • Triggertyp “Seitenaufruf”
  • Diesen Trigger auslösen bei “Einige Seitenaufrufe” (klingt erstmal widersinnig, denn es soll ja auf allen Seiten sein, aber wir schränken gleich nur den Host ein)
  • Diesen Trigger auslösen, wenn ein Ereignis eintritt und alle diese Bedingungen erfüllt sind: “Page Hostname” > “stimmt mit regulärem Ausdruck überein” > “meinedomain\.de” (Bitte nicht den umgekehrten Schrägstrich/Backslash vergessen) (Wenn die Variable “Page Hostname” bei dir noch nicht verfügbar ist, sie ggf. zuvor aktivieren im Menübereich “Variablen”)

Ein Trigger, der nur feuert, wenn der passende Hostname zugrunde liegt.

Im Anschluss dann ggf. die Trigger in deinen Tags auf den neuen Trigger umstellen. Oder wie gesagt: Die bestehenden Trigger erweitern.

Und das Ende vom Lied

Was kann da alles passieren, werden jetzt alle Leser gedacht haben. Kann man den Google Tag Manager überhaupt noch sinnvoll einsetzen bei diesen Möglichkeiten?

Aber klar doch. Spammern stehen ungeschützten Tag Manager- und Analytics-Konten von jeher einige Türen offen. Deshalb auf Tracking zu verzichten, halte ich gelinde gesagt für gewagt. Zumal es ja mindestens mal die drei oben genannten Möglichkeiten gibt, das zu verhindern. Insofern bin ich da recht entspannt, wenn ich darauf angesprochen werden.

Aber ich halte es für absolut wichtig zu wissen, was passieren kann, DAMIT du dich eben schützen kannst.

Fazit

Jep, ein Google Tag Manager Container lässt sich kidnappen und damit zum Beispiel Traffic auf ein fremdes Analytics-Konto schicken. Schwer ist das nicht.

Doch es gibt mindestens die drei obigen Lösungen, wie du dagegen etwas tun kannst – und insofern ist Panik unangebracht.

Welche ist deine Lösung? Lass’ uns darüber sprechen. Gerne in den Kommentaren.

Maik Bruns
Letzte Artikel von Maik Bruns (Alle anzeigen)

Passend zum Thema:

Google Analytics: AnonymizeIP entspannt einbinden in Universal Analytics (mit und ohne Google Tag Manager) Effizient tracken mit der “Google-Analytics-Einstellungen”-Variable Mit Content Grouping die Erfolge von Website-Teilen messbar machen Datenqualität: Facebook Click ID (fbclid) aus Google Analytics heraushalten

Noch mehr Insights

Was ist Unassigned Traffic in GA4, wo finde ich ihn und wie lässt er sich beheben?

Keine klare Zuordnung des Traffics zu Kanälen, kein direkter Zusammenhang zu euren Marketing-Maßnahmen – und dementsprechend keine Aussagekraft, ob eure Kampagnen wirken oder nur Geld verbrennen und euren ROI runterdrücken. Nervig, oder? Genau das passiert in vielen Setups, die wir sehen, durch den sogenannten “Unassigned”-Traffic. 

Dadurch verliert ihr wertvolle Einblicke, weil GA4 euren Traffic nicht eindeutig zuordnen kann.

Mehr erfahren >
Top