Google Tag Manager: die neue Waffe gegen Adblocker

EDIT 25. Mai 2021: Das „Server-Side Tagging“ von Google Tag Manager entwickelt sich weiter und das Umgehen von Adblockern wird immer einfacher. Ich habe dem Artikel den Abschnitt „Den Adblockern einen Schritt voraus“ hinzugefügt.

Google Tag Manager, das Trojanische Pferd für Marketingteams

Google Tag Manager ist ein TMS (Tag-Management-System): Es ermöglicht Marketingteams, Tracker zu einer Website oder Anwendung hinzuzufügen, ohne sich an Entwickler wenden zu müssen. Über eine Weboberfläche können diese Teams entscheiden:

• Auszulösende Tracker (Analysen, A/B-Tests, Attribution usw.).
• Auslösebedingungen (Seitenkategorien, Benutzereigenschaften usw.).
• Daten, die an diese Tools von Drittanbietern übermittelt werden sollen (Benutzereigenschaften, Navigationsdaten, auf der Seite vorhandene Variablen usw.).

Es ist nicht das einzige (wir können zum Beispiel zitieren Segment, Französisch TagCommander oder Matomo Tag Manager), aber Google Tag Manager ist ultradominant:

Google Tag Manager ist auf 31,9 % der Top-10-Millionen-Alexa-Websites vertreten. laut W3Techs, vor allem aber hat Google Tag Manager einen Marktanteil von 99,4 % auf TMS (!)

Wie konnte sich Google erneut durchsetzen? Wie bei Google Analytics ist die Standardversion von Google Tag Manager kostenlos (die marktüblichen Lösungen sind in der Regel kostenpflichtig), sehr gut in die anderen Google-Lösungen integriert und gut gemacht.

Tracker, die nicht mehr von Ihrem Browser aufgerufen werden

Letzten August, Google kündigt eine neue Version von Google Tag Manager an, genannt Server-Side Tagging. Hier ist ein Diagramm von Google um zu erklären, wie Google Tag Manager in der Client-Side-Tagging-Version (der „historischen“ Version) funktioniert:

Google Tag Manager ermöglicht die Auslösung verschiedener Tracker von Drittanbietern (im Diagramm: Google Analytics, Google Ads und ein Analysetool) direkt in Ihrem Browser.

In der neuen serverseitigen Version„Tracker von Drittanbietern werden nicht mehr über Ihren Browser, sondern über einen Server ausgeführt.“Stellvertreter" im Diagramm unten „Servercontainer“ genannt (und unter Google gehostet):

Die Javascript-Bibliothek (im Diagramm „Tag Manager-Webcontainer“ genannt) läuft weiterhin auf Ihrem Browser, um Ihre Interaktionen und Ihre persönlichen Daten zu sammeln, die Ausführung der verschiedenen Drittanbieter-Tracker erfolgt jedoch serverseitig.

Beachten Sie, dass diese neue Version auch für Anwendungen und die Erfassung von „Offline“-Daten gilt (z. B. zur Übermittlung von Einkäufen im Geschäft):

Diagramm von Simo Ahavas Blog : Auf der Serverseite sind die „Clients“ dazu da, die empfangenen HTTP-Anfragen in „Ereignisse“ zu übersetzen, die „Tags“ reagieren auf diese Ereignisse, um „Treffer“ an Marketingunternehmen von Drittanbietern zu senden.

Diese Logik, Drittanbieter-Tracker serverseitig auszulösen, verändert die Lage. Simo Ahava hat die verschiedenen Auswirkungen in einem ausgezeichneten Artikel detailliert beschrieben. Ich werde meinerseits die Vorteile zusammenfassen und mich auf die Probleme für Ihre Privatsphäre konzentrieren (serverseitiges Arbeiten kann es ermöglichen, Ihre Entscheidungen zu umgehen und Ihre personenbezogenen Daten preiszugeben, ohne aufzufallen).

Bessere Benutzererfahrung

Auf den meisten Websites ist die Anzahl der von Dritten geladenen JavaScript-Bibliotheken (für Analysen, Werbung, A/B-Tests usw.) beeindruckend. Das Laden und Ausführen dieser Bibliotheken ist häufig die Hauptursache für eine schlechte Benutzererfahrung: Langsamkeit der Website und mangelnde Interaktivität.

Folgen für Websites mit schlechter Benutzererfahrung: weniger zufriedene Internetnutzer, die die Navigation sofort abbrechen oder nicht mehr zurückkehren.

Hier ist ein Beispiel mit Le Bon Coin, Dies ruft unzählige Javascript-Bibliotheken auf :

Ein kleiner Teil der auf der Le Bon Coin-Homepage aufgerufenen Javascript-Skripte, Dadurch werden Ihre persönlichen Daten an viele Dritte weitergegeben.

Im besten Fall installiert die Website nur eine einzige Javascript-Bibliothek (die Ereignisse können je nach Tool und Ziel sehr unterschiedlich sein, weshalb eine Website manchmal mehr als eine Bibliothek verwendet). Das kann die Bibliothek von Google Tag Manager sein, muss es aber nicht: Man kann eine eigene Bibliothek entwickeln oder andere Bibliotheken am Markt nutzen, etwa Snowplow, Matomo, AT Internet usw.

Anschließend wird diese Bibliothek angewiesen, die „Treffer“ mit den bei Schlüsselinteraktionen erforderlichen Parametern zu senden. Dann muss der „Client“ des Server-Containers diese „Treffer“ in Ereignisse übersetzen, diese werden von den „Tags“ gelesen, die „Treffer“ an dritte Marketingunternehmen senden. Beachten Sie, dass der „Client“ bereits in Google Tag Manager vorkonfiguriert ist, wenn die auf der Site installierte Javascript-Bibliothek von Google bereitgestellt wird. Wenn die Website eine andere Bibliothek verwendet, muss sie in Google Tag Manager einen eigenen „Client“ erstellen (Beispiel mit AT Internet), während wir darauf warten, vorkonfigurierte „Clients“ für die wichtigsten Javascript-Tracking-Bibliotheken zu haben.

Vorteil: Auf der Website ist eine einzige JavaScript-Tracking-Bibliothek installiert und ein einziger „Datenfluss“ kommt vom Browser. Der Benutzer sollte den Unterschied sehen.

Bessere Kontrolle über an Dritte übermittelte Daten

Mit einem serverseitigen „Proxy“ können Sie die an Dritte übertragenen Daten kontrollieren (was deutlich schwieriger ist, wenn die Tracker direkt vom Browser des Benutzers ausgeführt werden):

• Standardmäßig und anders als in der „clientseitigen“ Version werden die IP-Adresse und der User-Agent des Nutzers (Browsername, Version, Betriebssystem, Sprache usw.) nicht weitergegeben (was eine Identifizierung des Nutzers per „Fingerprinting“ verhindert). Der Publisher, der die Server-Side-Tagging-Version von Google Tag Manager nutzt, kann entscheiden, diese Informationen an Dritte zu übertragen, automatisch geschieht das aber nicht.
• Es kommt häufig vor, dass persönliche Informationen über URL-Parameter an Dritte weitergegeben werden (lesen Sie zum Beispiel den Artikel „Google Tag Manager Serverseitig – So verwalten Sie benutzerdefinierte Lieferanten-Tags"), vermeidet der Server-Side Tagging dies.
• Im Allgemeinen hat der Herausgeber die Kontrolle über die personenbezogenen Daten und Cookies, die von seinem „Proxy“ an Dritte gesendet werden (siehe die technische Dokumentation von Google, beachten Sie zum Beispiel die Methoden get_cookies und set_cookies). Er kann daher die Informationen „bereinigen“ und nur das unbedingt Notwendige an Dritte senden.

Beispiel: Wenn ein AT Internet-Treffer vom „Proxy“-Server „gesehen“ wird, kann die Website entscheiden, die IP-Adresse und den User-Agent des Benutzers nicht an AT Internet zu übertragen.

Eine sicherere Website

Richten Sie ein ein Inhaltssicherheitsrichtlinie (CSP) ermöglicht es einem Herausgeber, sich besser vor verschiedenen Arten von Bedrohungen, einschließlich Angriffen, zu schützen XSS (Cross-Site Scripting) und Content-Injections. Durch das Hinzufügen eines Headers zu Webserver-Antworten kann die Site Browsern mitteilen, welche Ressourcen (Skripte, CSS usw.) zulässig sind.

Hier ist ein Beispiel für CSP, dokumentiert von Google :

Inhaltssicherheitsrichtlinie: script-src 'self' https://apis.google.com.

Das heißt: Der Browser hat nur das Recht, Skripte auszuführen, die direkt von der aufgerufenen Seite stammen ('selbst') oder apis.google.com. Und so reagiert Ihr Browser, wenn dann ein bösartiges Skript versucht, von der aufgerufenen Website aus ausgeführt zu werden:

Das Skript evil.js wird weder auf der aufgerufenen Website noch auf apis.google.com gehostet: Seine Ausführung wird vom Browser blockiert.

Durch die starke Reduzierung der zur Ausführung von Javascript-Code berechtigten Drittanbieter-Domänen wird der CSP robuster.

Wenn Server-Side Tagging Vorteile für Benutzer hat, die der Marketingüberwachung zustimmen (Geschwindigkeit, Sicherheit), gefährdet es den Schutz von Benutzern, die nicht zustimmen.

Eine Umgehung des Browserschutzes

Der „Proxy“-Server wird in der Google-Cloud gehostet (instance App Engine), aber Google berät um die App Engine-Domain mit einer Subdomain der Website seiner Kunden zu verknüpfen (ohne Angabe von Gründen):

Die Standardbereitstellung server-side tagging wird auf einer App Engine-Domäne gehostet. Wir empfehlen Ihnen, die Bereitstellung so zu ändern, dass stattdessen eine Subdomain Ihrer Website verwendet wird.

Die Verbindung zwischen der App Engine-Domäne und der Client-Subdomäne, dokumentiert durch Google.

Google empfiehlt keinen Datensatz vom Typ CNAME (Alias) DNS, sondern a DNS Datensatztyp A oder AAAA, direkt verknüpft mit den IP-Adressen der Google App Engine, die als Host fungiert. Der „Proxy“-Server wird daher von Browsern durchaus als Erstanbieter betrachtet, und die Konsequenzen sind daher erheblich.

Insbesondere handelt es sich bei den vom „Proxy“-Server platzierten Cookies nicht um Cookies von Drittanbietern, noch um Cookies, die über Javascript erstellt wurden, noch um Cookies, die von einer CNAME-Domain platziert wurden. Sie sind daher uneingeschränkt berechtigt:

• Safari über Intelligente Tracking-Prävention (ITP) begrenzt die Lebensdauer von in Javascript erstellten Cookies auf 7 Tage (Beispiel: Erstanbieter-Cookies erstellt von Google Analytics). Dank des „Proxy“-Servers setzen Tracker von Drittanbietern diese Einschränkung nun außer Kraft.
• Immer Safari über ITP Beschränkt über eine CNAME-Domäne platzierte Cookies jetzt auf 7 Tage. Dank des „Proxy“-Servers sind Drittanbieter-Tracker von dieser Einschränkung nicht betroffen.
• Brave seinerseits blockiert CNAME-Anfragen an bekannte Tracker. Dank des „Proxy“-Servers vermeiden Tracker von Drittanbietern diese Blockierung.

Eine Umgehung von Adblockern

Ihr Adblocker (uBlock Origin auf Firefox zum Beispiel), Ihr Inhaltsblocker (Firefox Focus oder AdGuard auf iOS zum Beispiel) oder Ihr DNS-Blocker (NextDNS zum Beispiel) funktioniert auf Ihrem Gerät. Dadurch können Tracker von Drittanbietern erkannt und blockiert werden, bevor Ihre persönlichen Daten preisgegeben werden.

Nichts davon gilt bei der Server-Side-Tagging-Version von Google Tag Manager: Die Lecks personenbezogener Daten finden vom Proxyserver des Kunden (gehostet in der Google-Cloud) zu Dritten statt. Sie haben daher keine Möglichkeit mehr, diese Lecks zu verhindern.

Sie könnten sich sagen: Blockieren Sie einfach den ersten Aufruf Ihres Browsers an die Javascript-Bibliothek, die für die Datenerfassung und die Kommunikation mit dem „Proxy“-Server zuständig ist. Außer, dass diese Javascript-Bibliothek durchaus auf der Domain der Website zugänglich sein kann (und nicht beispielsweise auf einer Google-Domain). Auch Google schon weiter empfehlen damit seine Kunden ihre Skripte ändern können gtag.js um in die Domäne des Proxy-Servers einzutreten. Durch diese Manipulation wird die Blockierung über den Domainnamen bereits außer Kraft gesetzt.

Alle Tracking-Bibliotheken Google (gtag.js, Analytics.js aber auch gtm.js, die „erweiterte“ Bibliothek von Google, verantwortlich für Google Tag Manager) kann auf einer eigenen Domäne gehostet werden.

Über den Blog von Simo Ahava.

Wenn gtag.js oder gtm.js sind Javascript-Bibliotheken, deren Namen den wichtigsten Werbeblockern bekannt sind. Sie müssen andere Methoden finden, wenn der Name der Javascript-Bibliothek geändert wurde oder Websites ihre eigenen Bibliotheken erstellt haben.

uBlock Origin, wirksam gegen CNAME-Cloaking auf Firefox, machtlos gegen den Server-Side Tagging?

Den Adblockern einen Schritt voraus

Die Javascript-Bibliothek von Google Tag Manager wird aufgerufen gtm.js, wird es mit der Container-ID aufgerufen: GTM-.... Ein Adblocker kann daher leicht auf diese Namen abzielen und das Laden dieser Bibliothek blockieren. Eine Website könnte beschließen, eine eigene JavaScript-Bibliothek zu erstellen, aber das ist nicht so einfach.

Aber immer Danke an Simo Ahavaist es jetzt einfach, einen anderen Namen für die Javascript-Bibliothek zu wählen gtm.js und verbergen Sie die Container-ID (keine Notwendigkeit, eine eigene Javascript-Bibliothek zu erstellen):

Über Simo Ahavas Blog : Mit der Vorlage „GTM Loader“ von Simo kann die Website die Javascript-Bibliothek umbenennen („Request Path“) und die Container-ID ausblenden („Container-ID überschreiben“ aktiviert, „Container-ID“ leer).

Auch wenn es auf Seiten der Adblocker möglich wäre Ziel-Proxy Google, kann eine Website den Servercontainer nun an anderer Stelle hosten (auf Amazon AWS, Microsoft Azure, OVH... oder auf ihrer eigenen Infrastruktur). Es ist nicht so einfach, aber Google stellt das Docker-Image und die folgenden Schritte bereit.

Simo Ahava gibt daher die Vorgehensweise an Stellen Sie den Servercontainer auf Amazon AWS bereit während Mark Edmondson detailliert beschreibt, wie Stellen Sie den Servercontainer auf Google Cloud Run bereit (ein weiterer Dienst der Google Cloud Platform, der sich von der Google App Engine unterscheidet).

Wie können Adblocker reagieren?

Das Thema ist nicht offensichtlich, hier sind einige Ideen, aber ich bin nicht sicher, ob sie umsetzbar sind:

• Erkennen Sie diese „1st Party“-Anrufe an den „Proxy“-Server automatisch über gesendete URL-Parameter. Allerdings ändern sich diese URL-Parameter je nach verwendeter Bibliothek, angezeigter Seite usw. von einer Website zur anderen.
• Erkennen Sie die Javascript-Bibliothek, die für Aufrufe an den „Proxy“-Server verantwortlich ist, um dessen Ausführung zu blockieren. Wie wir gesehen haben, wird diese Methode nicht funktionieren wenn die Website die Bibliothek in Google Tag Manager umbenennt oder entwickeln Sie Ihre eigene Javascript-Bibliothek.
• Proxys blockieren, auf die Gefahr hin, wesentliche Website-Funktionen zu blockieren? Außerdem funktioniert diese Methode nicht, wenn die Website dies vorsiehtHosten Sie den Servercontainer auf seiner eigenen Infrastruktur.
• Führen Sie niemals Javascript in Ihrem Browser aus, zum Beispiel mit die NoScript-Erweiterung, radikal konfiguriert. Effektive Option, außer dass viele Websites nicht mehr funktionieren.

Geben Sie Ihre persönlichen Daten in völliger Undurchsichtigkeit preis

Obwohl heutzutage viele Websites Ihre personenbezogenen Daten preisgeben, häufig ohne Ihre Zustimmung, ist es dennoch möglich, die Websites zu prüfen, den Verstoß gegen die Einwilligung nachzuweisen und die Datenlecks zu dokumentieren. Der CNIL könnte beispielsweise seinen Job machen und Fehler bestrafen. Nichts davon mit dem Server-Side Tagging, eine Site kann jetzt ganz einfach:

• Erwecken Sie den Anschein einer Einwilligung, indem Sie auf ein Einwilligungsbanner antworten.
• Während Sie Ihre personenbezogenen Daten an mehrere Dritte weitergeben, ohne dass ein externer Prüfer dies bemerken kann (er sieht lediglich den Aufruf des „Erstanbieters“ an den „Proxy“-Server, ohne zu wissen, ob die personenbezogenen Daten dahinter verwendet, weitergegeben oder weiterverkauft werden).

Ihre Daten in der Google-Cloud

Standardmäßig der „Proxy“-Server protokolliert alle eingehenden Anfragen :

Standardmäßig protokolliert App Engine Informationen zu jeder einzelnen Anfrage (z. B. Anfragepfad, Abfrageparameter usw.), die es erhält.

Die in diesen Anfragen enthaltenen personenbezogenen Daten sind jedoch nicht die einzigen Informationen, die an Google weitergegeben werden. Alles Was das CNAME-Cloaking betrifftwerden Cookies, die mit der Domain der aufgerufenen Website verknüpft sind, an die Subdomain des „Proxy“-Servers gesendet. Wenn Ihre Sitzungscookies also mit der Site-Domain (und nicht mit einer separaten Subdomain) verknüpft sind, werden sie an die Google-Cloud gesendet.

Dieses hier erklärt dass die in seiner Cloud gehosteten Daten dem Client gehören und nicht Google. Sie müssen jedoch Google vertrauen.

Der Server-Side Tagging wird wahrscheinlich bald weit verbreitet sein

Wenn serverseitige Lösungen schon seit langem auf dem Markt existieren und es bereits möglich wäre, einen eigenen „Proxy“ zu entwickeln, wird die Einführung der Google-Lösung wahrscheinlich einen großen Einfluss auf die Einführung von Server-Side Tagging haben:

• Google Tag Manager ist auf einer beträchtlichen Anzahl von Websites präsent und äußerst dominant.
• Google präsentiert diese Version als Entwicklung TMS-Tools, die die Leistung und Sicherheit von Websites verbessern.
• Großes Argument für Vermarkter, Ihre persönlichen Daten an Facebook weitergeben.

Ein Google Analytics-Tag kann Verstecken Sie die Weitergabe Ihrer persönlichen Daten an Facebook, Kombi!

Auch wenn ein Google-Tag-Manager-Kunde die Client-Side-Version weiter verwenden kann, auch wenn die Server-Side-Version noch Grenzen hat (wenige Drittanbieter-Bibliotheken, einige Lösungen werden schwer zu unterstützen sein usw.), auch wenn das Erlernen der Lösung komplex ist und auch wenn sie oft kostenpflichtig ist (Google-App-Engine-Rechnung für den „Proxy“-Server), kann man also darauf wetten, dass Google-Tag-Manager-Kunden nach und nach auf diese Version migrieren werden.

Das Umgehen von Adblockern und anderen Browser-Schutzmaßnahmen ist ein Verkaufsargument

Wie wir gesehen haben, Google erklärt nicht Der Grund für die Erstellung einer Subdomain der Website für ihren „Proxy“-Server:

Die Standardbereitstellung server-side tagging wird auf einer App Engine-Domäne gehostet. Wir empfehlen Ihnen, die Bereitstellung so zu ändern, dass stattdessen eine Subdomain Ihrer Website verwendet wird.

Das ist nicht nötig, die Umgehung von Browser-Schutzmaßnahmen und Adblockern wurde bereits in zahlreichen Veröffentlichungen als „Vorteile“ aufgeführt:

• „Server-side Tagging In Google Tag Manager“ von Simo Ahava: Der Artikel nennt als Vorteil, die Einschränkungen von Safari bei der Lebensdauer von Javascript-Cookies umgehen zu können. Zu seiner Ehre will der Autor nicht näher darauf eingehen, dass Server-Side Tagging die Umgehung von Adblockern ermöglicht, und weist darauf hin, dass die Datenerhebung nach Einholung der Einwilligung erfolgen muss.
• "GTM Serverseite – Die natürliche Entwicklung für Ihr Tagging?" von Converteo. Der Artikel listet die Vorteile auf, die sich daraus ergeben, Browsereinschränkungen wie die von Safari und Firefox sowie Adblocker umgehen zu können.
• "Einführung in das serverseitige Tagging von Google Tag Manager", aus dem Analytics-Mania-Blog. Auch hier werden Umgehungen von Browser- und Adblocker-Einschränkungen als Vorteile aufgeführt.
• "Google führt serverseitiges Tagging ein, gute Neuigkeiten?" von Nicolas Jaimes auf dem JDN. Der Aspekt des Artikels ist Werbung und daher wird die Umgehung von Browser-Schutzmaßnahmen als Vorteil aufgeführt (auch wenn die Implementierung von Server-Side Tagging aufgrund des Mangels an Bibliotheken von Drittanbietern derzeit komplex bleibt).

Leider kann man davon ausgehen, dass viele Websites zusätzlich zu den Leistungs-, Sicherheits- und Kontrollgewinnen auch von diesen „Vorteilen“ profitieren werden. Auch für Datenschützer wäre die Unfähigkeit, Websites zu prüfen, ein großer Verlust. Wir hoffen, dass Browser und Adblocker Lösungen finden, damit Internetnutzer, die um ihre Privatsphäre besorgt sind, sich weiterhin verteidigen können.