English
Deutsch
PolskiConsent-Banner prüfen: Welche Tracking-Skripte laden, bevor jemand klickt
Inhalt
Ein Einwilligungsbanner sieht aus wie ein Tor. Es legt sich über die Seite, es stellt eine Frage, und bis ein Knopf gedrückt wird, scheint nichts zu geschehen.
Dieser Anschein ist gezeichnet, nicht erzwungen. Das Banner ist ein Element auf der Seite wie jedes andere, eingefügt von einem Skript, das mit allen übrigen Skripten läuft. Ob die Mess-Tags auf die Antwort warten, ist eine getrennte Vorkehrung – und es ist durchaus möglich, die Frage zu haben und das Warten nicht.
Ein Banner ist keine Schranke
Die Reihenfolge der Ereignisse auf einer Seite liegt fest und ist kurz. Der Browser holt das HTML, arbeitet es von oben nach unten durch und startet jedes Skript, das ihm dabei begegnet. Irgendwo in dieser Abfolge steht das Skript, das das Banner zeichnet.
Alles darüber hat bereits begonnen. Alles darunter beginnt ohnehin, sofern es nicht eigens verhindert wird. Dass das Banner den Bildschirm bedeckt, hält die Seite dahinter nicht an – eine sichtbare Überlagerung hat keine Wirkung auf das, was darunter lädt.
Die Frage lautet deshalb nie, ob ein Banner vorhanden ist. Die Frage lautet, was in den Sekunden vor der ersten Berührung mit den Tags geschieht.
Die drei Wege, ein Skript wirklich zurückzuhalten
Nur drei Vorkehrungen verzögern ein Skript tatsächlich, und jede hinterlässt eine andere Spur im Quelltext.
Der Typ wird geändert. Ein Skript mit type="text/plain" führt der Browser überhaupt nicht aus – es gilt ihm als Text. Das Einwilligungswerkzeug schreibt den Typ nach einer Entscheidung um, und erst dann läuft das Skript. Das ist der häufigste Weg und der am leichtesten erkennbare.
Die Adresse wird verschoben. Die echte Adresse steht in einem Attribut, das der Browser übergeht, etwa data-src, und wandert nach der Entscheidung nach src. Dasselbe Prinzip, ein anderes Attribut.
Das Skript steht gar nicht in der Seite. Vom Tag ist im ausgelieferten HTML nichts zu sehen; das Einwilligungswerkzeug fügt es nach der Antwort ein. Das ist die sauberste Vorkehrung und die von außen am schwersten nachweisbare, denn eine Seite in diesem Zustand sieht genauso aus wie eine ohne jede Messung.
Allen dreien ist eines gemeinsam: es sind Entscheidungen beim Bau der Seite, keine Einstellungen im Banner. Ein Einwilligungswerkzeug, das eingebaut, aber nicht mit den Tags verdrahtet wurde, erzeugt ein tadelloses Banner und hält nichts zurück.
Was Consent Mode vor dem ersten Tag festlegt
Die Tags von Google haben dafür einen eigenen Mechanismus, und der arbeitet andersherum: das Tag lädt sofort und bekommt vorher gesagt, was es darf.
Diese Anweisung ist eine Consent-Vorgabe. Vor dem Laden des Tags gesetzt, sagt sie, ob Speichern erlaubt ist, und das Tag verhält sich vom ersten Moment an entsprechend. Ohne Vorgabe wendet das Tag seine eigene an – und misst danach, bis das Einwilligungswerkzeug den Zustand richtigstellt.
Die Lücke zwischen Seitenaufruf und Richtigstellung ist meist kurz. Immer kurz ist sie nicht, und null ist sie nie.
Eine Vorgabe, die auf granted steht, lohnt einen zweiten Blick. Damit gilt eine Besucherin als einverstanden, bevor gefragt wurde – eine Entscheidung also und kein Versehen, auch wenn es in der Praxis oft ein Versehen ist, abgeschrieben aus einem Beispiel für eine Region mit anderen Regeln.
Die Cookies, die mit der ersten Antwort kommen
Skripte sind nur ein Weg. Der Server kann Cookies schon in der Antwort selbst setzen, bevor eine einzige Zeile der Seite gezeichnet wurde.
Diese Cookies stehen in den Antwort-Headern, und sie werden gesetzt, was das Banner später auch sagt, denn sie wurden verschickt, bevor es das Banner gab. Sitzungscookies für einen Warenkorb gehören in diese Gruppe und sind meist unbedenklich. Analyse-Cookies, die auf demselben Weg gesetzt werden, sind es nicht.
Ob ein Cookie eine Einwilligung braucht, hängt daran, was es tut, nicht daran, wann es gesetzt wird. Aber der Zeitpunkt des Setzens entscheidet, ob ein Einwilligungswerkzeug es überhaupt hätte verhindern können – und bei einem Cookie aus der ersten Antwort lautet die Antwort nein.
Was der Quelltext zeigt, und was nicht
Hier gehört eine ehrliche Grenze hin, denn sie entscheidet darüber, wie ein Ergebnis zu lesen ist.
Das ausgelieferte HTML ist das, was der Server schickt. Es enthält nicht, was ein Skript später nachlädt. Eine Seite, die alle ihre Tags nach der Entscheidung einfügt, zeigt deshalb fast nichts – was das richtige Verhalten ist und genauso aussieht wie eine Seite ganz ohne Tags.
Diese Mehrdeutigkeit lässt sich aus dem Quelltext allein nicht auflösen, und ein Werkzeug, das etwas anderes vorgibt, rät. Was der Quelltext dagegen verlässlich zeigt, ist der umgekehrte Fall: ein Tag, das ungebremst im HTML steht, ist ein Tag, das ohnehin lädt.
Und das ist der Befund, auf den es ankommt. Eine Seite mit Banner und ungebremsten Tags hat den Anschein einer Entscheidung und das Verhalten ohne eine.
Vier Dinge, die ein Blick in den Quelltext klärt
Welche Mess- und Werbedienste eingebaut sind und unter welchen Kennungen. Ob überhaupt ein Einwilligungswerkzeug vorhanden ist. Ob irgendein Skript in der Seite zurückgehalten wird, auf einem der drei Wege. Und welche Cookies schon die allererste Antwort setzt.
Der Tracking- und Consent-Scan beantwortet alle vier für eine beliebige Adresse. Er holt die Seite einmal, liest den ausgelieferten Quelltext und trennt, was eingebaut ist, von dem, was zurückgehalten wird – und er sagt deutlich, wenn ein Ergebnis „hier ist nichts zu sehen” bedeutet und nicht „da ist nichts”.
Das brauchbare Urteil ist keine Note. Es ist der Satz, der aus den vier Antworten folgt: ob das Banner auf dieser Seite eine Frage mit Folgen ist oder eine ohne.
Fragen und Antworten
Wartet ein Skript mit async oder defer auf die Einwilligung?
Nein. Beide Attribute ändern nur, wann ein Skript läuft, nicht, ob es läuft: async führt es aus, sobald es geladen ist, defer nach dem Einlesen des HTML. In beiden Fällen geschieht das in der Regel lange vor dem ersten Klick auf das Banner, und im Quelltext zählt ein solches Skript deshalb als ungebremst.
Ein Google-Tag steht ungebremst im Quelltext, Consent Mode ist aber eingerichtet. Ist das ein Befund?
Zunächst ist es eine Bauweise. Consent Mode hält das Tag nicht zurück: Es lädt sofort und richtet sich nach der Vorgabe, die vorher gesetzt wurde. Ein ungebremstes Tag ist dort also zu erwarten, und es lädt in jedem Fall. Entscheidend ist, was davor im Quelltext steht.
Drei Dinge lassen sich dort ablesen:
- Ob überhaupt eine Consent-Vorgabe gesetzt wird, üblicherweise mit einem Aufruf
gtag('consent', 'default', …). Fehlt sie, gilt die Vorgabe des Tags selbst, bis das Einwilligungswerkzeug den Zustand richtigstellt. - Ob sie vor dem Tag steht. Eine Vorgabe, die erst nach dem Tag ausgeführt wird, kommt für die ersten Anfragen zu spät.
- Welche Werte sie setzt, etwa für analytics_storage und ad_storage. Steht dort granted, gilt eine Besucherin als einverstanden, bevor gefragt wurde.
Offen bleibt auch bei richtiger Vorgabe, ob schon das Laden des Tags und die Anfragen, die es ohne Cookies sendet, ohne Einwilligung zulässig sind. Das ist eine rechtliche Frage, die ein Blick in den Quelltext nicht beantwortet.
Zeigt ein einzelner Abruf, was jede Besucherin und jeder Besucher bekommt?
Nicht unbedingt. Ein Abruf sieht die Seite so, wie sie für genau diese Anfrage ausgeliefert wurde: ohne gespeicherte Entscheidung, von einem bestimmten Ort aus und womöglich aus einem Seitencache. Manche Einwilligungswerkzeuge liefern je nach Herkunft der Anfrage unterschiedliche Fassungen aus, und Consent Mode kennt Vorgaben je Region; eine Vorgabe mit Regionsangabe steht im Quelltext und lässt sich dort lesen, eine Weiche auf dem Server nicht. Ein unauffälliges Ergebnis gilt deshalb streng genommen nur für die Region, aus der geprüft wurde.
Passend dazu
