Cookies sätts fortfarande efter Reject

Varför det här är viktigt

En Reject-knapp som inte faktiskt blockerar valfri behandling är ett av de tydligaste tecknen på att samtyckesmekanismen inte verkställs korrekt.

Så verifierar du manuellt

1. Avvisa valfri behandling i en ren session och ladda sedan om sidan.
2. Inspektera cookies och nätverksförfrågningar efter Reject.
3. Jämför beteendet före och efter Reject för att bekräfta att valfri storage verkligen stoppas.

Typiska orsaker

• Reject uppdaterar bara bannerns visuella status men skickar inte vidare denied-status.
• Valfria taggar startar igen efter reload trots att användaren avvisat.
• Sparade samtyckesvärden läses fel eller ignoreras efter navigering.

Åtgärd i GTM

1. Säkerställ att denied-status läses in innan taggar kan starta igen efter reload.
2. Koppla samtyckeskontroller till alla valfria taggar, inte bara till förstasidehändelser.
3. Bekräfta i GTM Preview att Reject kvarstår korrekt mellan omladdningar.

Åtgärd i WordPress eller CMP-pluginer

1. Granska pluginintegrationer som fortsätter att ladda valfria taggar efter Reject.
2. Bekräfta att CMP-pluginet sparar och tillämpar denied-status vid varje sidladdning.
3. Ta bort överlappande tracking-pluginer som ignorerar CMP-status.

Generell utvecklaråtgärd

1. Behandla Reject som ett verkställbart runtime-läge, inte bara som en UI-åtgärd.
2. Blockera valfria loaders på varje sida när sparad samtyckesstatus är denied.
3. Testa reload-, återbesöks- och navigeringsscenarier mellan sidor, inte bara första laddningen.

Så bekräftar du att åtgärden fungerar

• Reject och reload: bekräfta att valfria cookies fortfarande saknas.
• Reject och reload: bekräfta att valfria förfrågningar förblir blockerade.
• Kör en ny skanning och kontrollera att Reject-relaterade findingar försvinner.