Modo Cosmético (cookieConsentCosmeticOnly)

Esta página descreve o que o flag featuresConfig.cookieConsentCosmeticOnly faz hoje no código. A semântica dele mudou: ele já não controla o estado default dos sinais de Google Consent Mode v2.

:::danger Precisa de validação do responsável por LGPD antes de valer como política O default do flag no base é true, e o estado de boot do GCM v2 é granted para toda brand, cosmética ou não (ver Consent LGPD). Este texto é descrição factual do código, não declaração de conformidade — o responsável por LGPD / DPO precisa confirmar que o comportamento é o pretendido, e em quais brands, antes de qualquer parte disto ser tratada como política publicada. :::

O que o flag faz hoje

Uma frase, direto do JSDoc em app/types/feature-flags.ts: o boot é sempre granted (paridade com o legado), e o flag controla apenas se a RECUSA do usuário tem efeito.

Desdobrando nos dois pontos onde ele é lido:

Ponto de leitura	cookieConsentCosmeticOnly: true	cookieConsentCosmeticOnly: false
Salvar preferência no banner (CookieConsentBanner.handleSave)	Qualquer escolha é convertida em createAcceptAllPreferences() antes de gravar o cookie e de chamar updateConsentSignals	A escolha do usuário é gravada e propagada como está
Boot dos inicializadores (primeGTMQueue, initFloodlight, AnaLayerInitializer)	Nunca passa applyDenied — a recusa registrada numa visita anterior não é reaplicada	Se a visita anterior registrou recusa total, passa applyDenied: true → update all-denied logo após o default all-granted

O que não muda entre os dois modos:

• O consent default injetado antes do container carregar é all-granted nos dois casos.
• Não existe wait_for_update em nenhum dos dois casos.
• O banner renderiza igual nos dois casos (quem controla a renderização é brand.features.cookieConsentPopup).

Comportamento por interação

O banner tem dois botões no nível superior: Personalizar e Aceitar todos. Não existe "Recusar todos" — ver Consent LGPD.

Interação	Modo default (false)	Modo cosmético (true)
Clica Aceitar todos	todas as categorias true	todas as categorias true (igual)
Personalizar → liga alguma categoria → Salvar	preferências granulares gravadas	todas as categorias true
Personalizar → não liga nada → Salvar	coerce pra aceitar tudo (paridade legado, ver abaixo)	todas as categorias true
Não interage	banner permanece; nenhum cookie gravado	banner permanece; nenhum cookie gravado
Volta em visita futura tendo recusado antes	recusa é reaplicada no boot (update all-denied)	recusa não é reaplicada

O coerce de "salvar só com necessários"

Vale nos dois modos: se o usuário abre Personalizar, não liga nenhuma categoria opcional e clica salvar, o handler chama handleAcceptAll(). É paridade com o legado — "só necessários" era tratado como equivalente a recusar, e voltar pra mesma decisão depois de o usuário ter ido até Personalizar foi considerado UX confusa.

Consequência a registrar: combinando isso com a ausência de botão de recusa no banner, em brand cosmética não há caminho de UI que resulte em recusa efetiva.

Valores por brand

Default do base (app/config/features/features.ts): true.

cookieConsentCosmeticOnly	Brands
true	7k-bet-br, betpontobet-bet-br, cl-bet7k-com, fi-7k-bet, ng-7k-bet
false	casateste-com, donald-bet-br, pb-bet, ph-state77-com, pt-state77-com, rj-bet, state77-com, x2b-bet

Todas as 13 brands declaram o flag explicitamente hoje. Lista viva:

grep -rn "cookieConsentCosmeticOnly" \
  app/config/features/features.ts overrides/*/app/config/features/features.ts

:::note Intenção declarada no código, atribuição por brand a confirmar O JSDoc do flag diz que o false é o caminho para "brands em jurisdições que exigem honrar a recusa do usuário" — logo, divergir do default é por desenho, não resíduo. O que o código não diz é o critério que colocou cada brand num lado ou no outro: hoje há brands BR nos dois grupos (7k-bet-br e betpontobet-bet-br com true; donald-bet-br, casateste-com, pb-bet, rj-bet com false). Essa distribuição precisa de confirmação do responsável por LGPD. :::

Por que o banner continua renderizando

Independente do modo, brands com cookieConsentPopup: true renderizam o banner. As razões registradas no projeto:

• Registrar para auditoria que o usuário recebeu aviso de cookies
• Manter UX consistente entre brands
• Requisitos contratuais com plataformas de pagamento e parceiros

Migração de cookie legado

O parser de cookies_consent migra tanto o nome legado (cactusCookiesConsent, lido e deletado numa única passada) quanto o formato legado (array → objeto). Ver Consent LGPD.

Em modo cosmético, um usuário que tinha ["necessary"] (recusou no modelo antigo) tem a preferência sobrescrita para "aceitar tudo" na próxima vez que salvar no banner. Se ele não interagir, o cookie migrado permanece com a escolha antiga — mas ela não é reaplicada aos sinais de GCM v2, porque em modo cosmético o applyDenied nunca é passado.

Cuidados operacionais

1. Mudar o flag em produção é decisão conjunta de marketing + responsável por LGPD, com aprovação registrada antes.
2. true → false muda comportamento de atribuição. Passa a existir o caminho update all-denied no boot para quem já recusou — parte do tráfego passa a operar com sinais negados. Avise marketing antes.
3. Não espere dashboard de "usuários que recusaram cookies" em modo cosmético. Toda escolha é gravada como aceitar tudo; a métrica é 0% de recusa por construção.
4. Não confunda com "esconder o banner". Quem controla a renderização é brand.features.cookieConsentPopup, no backoffice — não este flag.
5. Ao adicionar campo em features.ts, propague pra todos os overrides. Override é substituição de arquivo inteiro; brand sem o campo recebe undefined.