Cookies continuam a ser definidos após Reject

Porque isto importa

Um botão Reject que não bloqueia realmente o processamento opcional é um dos sinais mais claros de que o mecanismo de consentimento não está a ser aplicado corretamente.

Como verificar manualmente

1. Rejeite o processamento opcional numa sessão limpa e recarregue a página.
2. Inspecione cookies e pedidos de rede após Reject.
3. Compare o comportamento antes e depois de Reject para confirmar se o storage opcional realmente para.

Causas típicas

• Reject atualiza apenas o estado visual do banner, mas não propaga um estado denied.
• Tags opcionais voltam a disparar após reload apesar da escolha rejeitada.
• Valores de consentimento guardados são mal lidos ou ignorados após navegação.

Correção no GTM

1. Garanta que o estado denied é lido antes de as tags poderem voltar a correr após reload.
2. Aplique checks de consentimento a todas as tags opcionais, não apenas a eventos de first-load.
3. Verifique no GTM Preview que Reject persiste corretamente através de reloads.

Correção em WordPress ou plugins CMP

1. Reveja integrações de plugins que continuam a carregar tags opcionais após Reject.
2. Verifique que o plugin CMP guarda e aplica o estado denied em todos os page loads.
3. Remova plugins de tracking redundantes que ignoram o estado CMP.

Correção genérica para developers

1. Trate Reject como um estado runtime executável e não apenas como uma ação de UI.
2. Bloqueie loaders opcionais em cada página quando o estado de consentimento guardado for denied.
3. Teste reload, revisit e navegação cross-page, e não apenas first-load.

Como confirmar que a correção funciona

• Reject e reload: confirme que os cookies opcionais continuam ausentes.
• Reject e reload: confirme que os pedidos opcionais continuam bloqueados.
• Execute um novo scan e verifique que findings ligados ao Reject desaparecem.