Google Consent Mode v2: erteilten Consent synchron ausgeben - #500
Merged
Conversation
Das Fragment gibt bisher nur den denied-Default synchron aus. Der granted- Status eines wiederkehrenden Besuchers kommt erst aus consent_manager_frontend.js, und das wird mit defer geladen — laeuft also nach dem HTML-Parsing. Ein Tag-Manager-Snippet im Template laedt gtm.js dagegen async. Damit entscheidet ein Wettlauf, welchen Consent-Zustand GTM beim Start sieht. Gewinnt gtm.js, wertet GTM Tags mit "Additional consent required" (Facebook-Pixel, LinkedIn Insight, TikTok Pixel …) mit denied aus und feuert sie nicht nach — sie bleiben aus, obwohl die Einwilligung vorliegt. Gemessen an zwei Live-Installationen mit identischer Konfiguration: bei der einen war das consent-Script nach 240 ms fertig und gtm.js nach 254 ms, dort feuert der Pixel; bei der anderen 414 zu 419 ms, dort nicht — in einem einzigen Seitenaufruf traten alle drei gcd-Zustaende auf (p/r/v). Im GTM-Vorschaumodus faellt es nicht auf, weil der Debug-Modus gtm.js zusaetzlich verzoegert. Jetzt wird der bereits bekannte Consent direkt hinter dem Consent-Mode-Script ausgegeben — serverseitig aus dem Consent-Cookie und mit demselben Mapping wie im Frontend (getCookieConsentMappings). Ruecksichtnahme auf bestehende Installationen: - Nur im Auto-Mapping-Modus. Im manuellen Modus bestimmt der Betreiber selbst, welche Flags wann gesetzt werden. - Kein Zugriff auf ein globales gtag(): eine lokale Push-Funktion in einer IIFE haelt die Ausgabe unabhaengig davon, ob und wie andere Scripte gtag definieren, und ueberschreibt nichts. Angefasst wird nur der dataLayer. - Ohne erteilte Einwilligung bleibt die Ausgabe leer, der denied-Default ist unangetastet. Fuer Erstbesucher aendert sich nichts. - Es wird ausschliesslich granted gesetzt, nie denied — eine bestehende Einwilligung kann dadurch nicht zurueckgenommen werden.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Mein Fix für meine Situation von neulich (#492) hat nur einen Teil gelöst.
Der defer-Fix hat den Default-cosnent synchron gemacht.
Jetzt muss noch das consent-Update für wiederkehrende Besucher synchron gemacht werden.
Da gab es bisher immer noch eine race condition, weshalb ich es erst jetzt gemerkt habe,
Jetzt wird der bereits bekannte Consent direkt hinter dem Consent-Mode-Script ausgegeben — serverseitig aus dem Consent-Cookie.
Liegt keine Einwilligung vor, bleibt die Ausgabe leer und der denied-Default unangetastet.