Tiefergelegt: Die technischen Gründe für unser erweitertes GA Opt-Out bei Studio Enns
Einleitung
Weitere Informationen zu unserem Impressum und unseren Datenschutzbestimmungen finden Sie hier.
„Warum so kompliziert?“ – Diese Frage mag aufkommen, wenn man von unserem mehrstufigen Prozess zur Sicherstellung des Google Analytics Opt-Outs hört, der sogar ein passwortgeschütztes Server-Skript beinhaltet. Warum reicht nicht ein einfacher Klick? Die Antwort liegt in den technischen Details von Webseiten-Auslieferung, Caching und der Vermeidung von Risiken bei Server-Konfigurationen. Lassen Sie uns einen Blick unter die Haube werfen.
Hauptteil
Der Kern des Problems ist, dass ein im Browser gespeicherter Opt-Out-Wunsch (typischerweise in einem Cookie oder im localStorage) auf jeder Seite rechtzeitig ausgelesen werden muss, nämlich bevor das Google Analytics Skript ausgeführt wird. Nur dann kann GA angewiesen werden, keine Daten zu senden.
Die Herausforderung Caching
Moderne Webseiten, auch unsere bei Studio Enns, nutzen aggressives Caching, um schnell zu laden. Litespeed Cache und andere Technologien speichern oft fertige HTML-Versionen von Seiten zwischen. Wenn eine solche gecachte Seite ausgeliefert wird, werden serverseitige Skripte (wie PHP) oft gar nicht mehr ausgeführt. Ein PHP-Skript, das den Opt-Out-Status prüfen sollte, käme also nicht zum Zug. Auch clientseitiges JavaScript muss korrekt im HTML-Code stehen, um wirken zu können.
Statische HTML-Seiten
Ein signifikanter Teil unserer Webseite besteht aus statischen .html-Dateien. Diese werden vom Server normalerweise direkt ausgeliefert, ohne dynamische Verarbeitung. Auch hier gilt: Die Logik zur Opt-Out-Prüfung muss direkt im HTML-Code der Seite verankert sein.
Die Notwendigkeit von JavaScript im
Damit das Opt-Out zuverlässig funktioniert, muss ein kleines JavaScript (unser optinoptout.js) im -Bereich jeder HTML-Seite geladen werden – und zwar vor dem Google Analytics gtag.js-Skript. Dieses JavaScript prüft sofort beim Laden, ob im localStorage ein Opt-Out-Flag gesetzt ist. Wenn ja, setzt es eine globale Variable (window['ga-disable-GA_MEASUREMENT_ID'] = true;), die gtag.js erkennt und respektiert. Fehlt dieses Skript oder wird es zu spät geladen, funktioniert der Opt-Out auf dieser Seite nicht.
Risiko .htaccess
Eine Möglichkeit, Code dynamisch in alle Seiten einzufügen, wäre über die zentrale .htaccess-Datei (mittels mod_rewrite und einem PHP-Injector-Skript). Aber: Unsere Haupt-.htaccess enthält bereits wichtige und sensible Regeln (z.B. für Litespeed Cache, Weiterleitungen). Eine fehlerhafte Änderung hier kann die gesamte Webseite lahmlegen oder die Performance massiv beeinträchtigen. Dieses Risiko wollten wir nicht eingehen.
Problem Zentrale Verwaltung
Wie bereits erwähnt, nutzen wir Tools wie datareporter.eu zur Verwaltung von Datenschutztexten. Diese Tools erlauben meist nur Textänderungen, aber nicht das Einfügen von Skripten in den -Bereich aller verwalteten Seiten.
Die Lösung: Gezielte Code-Injektion per Skript
Unser passwortgeschütztes PHP-Skript löst dieses Dilemma:
- Es umgeht die Notwendigkeit, die
.htaccesszu ändern. - Es umgeht die Einschränkungen der zentralen Verwaltungstools.
- Es modifiziert die HTML-Dateien direkt auf dem Server, indem es den notwendigen
