Cookies sættes stadig efter Reject

Hvorfor det betyder noget

En Reject-knap, der ikke faktisk blokerer valgfri behandling, er et af de tydeligste tegn på, at samtykkemekanismen ikke håndhæves korrekt.

Sådan verificerer du manuelt

1. Afvis valgfri behandling i en ren session, og genindlæs derefter siden.
2. Undersøg cookies og netværksrequests efter Reject.
3. Sammenlign adfærden før og efter Reject for at bekræfte, at valgfri storage reelt stopper.

Typiske årsager

• Reject opdaterer kun bannerets visuelle tilstand, men sender ikke denied-status videre.
• Valgfrie tags starter igen efter reload på trods af brugerens afvisning.
• Gemte samtykkeværdier læses forkert eller ignoreres efter navigation.

Rettelse i GTM

1. Sørg for, at denied-status læses ind, før tags kan starte igen efter reload.
2. Knyt samtykkekontroller til alle valgfrie tags, ikke kun til hændelser ved første indlæsning.
3. Bekræft i GTM Preview, at Reject persisterer korrekt mellem genindlæsninger.

Rettelse i WordPress eller CMP-plugins

1. Gennemgå pluginintegrationer, som fortsætter med at indlæse valgfrie tags efter Reject.
2. Bekræft, at CMP-pluginet gemmer og anvender denied-status ved hver sideindlæsning.
3. Fjern overlappende tracking-plugins, som ignorerer CMP-status.

Generel udviklerrettelse

1. Behandl Reject som en håndhævet runtime-tilstand, ikke blot som en UI-handling.
2. Blokér valgfrie loaders på hver side, når gemt samtykkestatus er denied.
3. Test reload-, genbesøgs- og navigationsscenarier mellem sider, ikke kun første indlæsning.

Sådan bekræfter du, at rettelsen virker

• Reject og reload: bekræft, at valgfrie cookies fortsat mangler.
• Reject og reload: bekræft, at valgfrie requests forbliver blokeret.
• Kør en ny scanning, og kontrollér at Reject-relaterede findings forsvinder.