Por que as tags com functionality_storage nunca disparam
A tag só dispara se todos os sinais exigidos estiverem concedidos quando o acionador for executado. Uma configuração de consentimento pode negar functionality_storage e personalization_storage por padrão e depois atualizar apenas os quatro sinais lidos pelas tags de publicidade e análise do Google. Os dois continuam negados mesmo depois de alguém aceitar. Mapeie-os no banner ou exija um sinal que seja atualizado.
Comece com uma análise.
A análise gratuita lê o HTML da sua página inicial e o seu contêiner público do Tag Manager e lista as tags de rastreamento que encontra.
Grátis · Sem cadastro · Verificação de HTML e GTM público
Para que servem functionality_storage e personalization_storage?
A visão geral do Consent Mode do Google lista sete tipos de consentimento. Ela descreve como as tags respondem a quatro deles: ad_storage, analytics_storage, ad_user_data e ad_personalization. Os outros três são definidos pela finalidade. functionality_storage cobre coisas como configurações de idioma, personalization_storage coisas como recomendações de vídeo e security_storage autenticação e prevenção de fraudes.
Então esses dois costumam importar por um motivo: alguém os indicou em uma tag. No Tag Manager, um widget de chat ou um script de recomendações pode ter uma verificação de consentimento adicional em Consent Settings. A regra do Google para essa verificação é rígida. A tag só dispara se todos os tipos da lista estiverem concedidos quando ela for acionada.
Por que a tag continua bloqueada depois que alguém aceita?
Porque aceitar o banner e atualizar o sinal são dois eventos separados. Em uma correção de consentimento que auditamos em agosto de 2026, a página definia seis sinais como negados por padrão e deixava security_storage concedido, o que é normal. A configuração da plataforma de consentimento atualizava depois os sinais de publicidade e análise do Google e nada mais. Um listener de chat condicionado a functionality_storage nunca foi executado, nem para os visitantes que clicaram em aceitar. Nada indicou uma falha, porque uma tag bloqueada é exatamente o que uma configuração de consentimento deve produzir.
A verificação lê o estado naquele momento.
Quais configurações causam isso?
- A atualização só cita os sinais do Google. É o caso acima e o primeiro a descartar.
- O nome está escrito errado na atualização. Em uma atualização escrita à mão, um erro de digitação cria outro tipo de consentimento, e o verdadeiro continua no valor padrão.
- O banner não tem uma categoria correspondente. Sem uma opção funcional ou de personalização para oferecer, a plataforma não tem o que enviar para esse sinal, a menos que associe outra categoria a ele.
- O visitante não escolheu essa categoria. Quem aceitou só análise deve deixar a tag bloqueada. É a configuração funcionando.
- O acionador só foi executado antes da escolha. Lemos o código de execução do Tag Manager em novembro de 2026: uma verificação que falha encerra aquela tentativa, e nada a repete quando o consentimento muda. A tag precisa de um acionador executado depois da atualização, como mostra o artigo sobre o evento de atualização do consentimento. Se ela também dispara uma vez por página, leia antes a nota sobre tentativas bloqueadas.
Vale verificar também a falha oposta. A documentação da API de modelos do Google trata como concedido um tipo de consentimento que nunca foi definido, e o código aplica a mesma lógica às verificações de consentimento adicionais. Se o seu comando padrão deixar de fora esses dois sinais, uma tag condicionada a um deles pode disparar antes de o visitante escolher qualquer coisa.
Como descobrir qual é o seu caso?
Aceite tudo no Tag Assistant
Abra seu site no Tag Assistant com um perfil de navegador limpo e clique em Aceitar tudo. Aceitar tudo elimina a escolha do visitante como causa possível.
Leia o sinal depois da escolha
Em Summary, selecione o último evento Consent e abra a guia Consent. Compare as colunas de padrão e de atualização para o sinal exigido pela sua tag. Se a guia não mostrar esse sinal, execute
google_tag_data.ics.entriesno console. É um objeto interno e pode mudar, mas mostra o padrão e a atualização que o Google armazenou para cada tipo.Identifique a causa
Negado por padrão e sem atualização depois de Aceitar tudo significa que sua plataforma não está enviando esse sinal. Uma atualização para concedido significa que o sinal está certo, então passe para a tag. Nenhum estado significa que a tag está passando na verificação em vez de esperar por ela.
Verifique a tag e o acionador
Abra Consent Settings na tag e compare cada tipo exigido com a grafia do Google, caractere por caractere. Um tipo escrito errado não tem estado, então essa verificação passa quando deveria segurar a tag. Depois veja quando ela foi bloqueada. Uma tag bloqueada apenas em um acionador de carregamento de página antes da escolha precisa de um acionador executado depois da atualização do consentimento.
Corrija onde está a falha
Se o sinal nunca for atualizado, mapeie a categoria do banner para ele na sua plataforma de consentimento ou na atualização enviada pelo seu código. Se a plataforma não puder enviá-lo, exija um sinal que ela envie e que corresponda ao que o visitante aceitou.
Teste aceitar, recusar e o retorno do visitante
Repita a verificação de três formas. A tag deve disparar depois de Aceitar tudo, continuar bloqueada depois de uma recusa ou quando só outras categorias forem escolhidas, e disparar de novo quando o mesmo visitante voltar.
O guia do Tag Assistant do Google explica a guia Consent em mais detalhes. Se você ainda está decidindo o que um script deve aguardar, veja em qual categoria de consentimento um script se encaixa.
Uma única categoria do banner deve controlar os dois sinais?
Pode. Algumas plataformas enviam os dois a partir de uma única categoria funcional e outras os mantêm separados. Qualquer opção funciona se o texto do banner descrever o que as tags fazem. O importante é que cada sinal exigido pelo seu contêiner tenha uma categoria por trás.
O Velo mantém os dois separados. Com o Consent Mode ativado, cada escolha envia os sete tipos: a categoria Funcional define functionality_storage, Personalização define personalization_storage e security_storage continua concedido. Um ajuste para observar: onde o Velo pergunta antes de armazenar qualquer coisa, uma categoria oculta no banner não pode ser concedida, então o sinal dela continua negado mesmo depois de Aceitar tudo. Verifique seu contêiner antes de remover uma. O guia de Consent Mode mostra a configuração.
Perguntas frequentes
O que as pessoas perguntam sobre este assunto.
Por que minha tag que aguarda functionality_storage nunca dispara?
Uma causa comum é um sinal que começa negado e nunca recebe atualização da sua plataforma de consentimento. A tag só dispara se todos os tipos exigidos estiverem concedidos quando o acionador for executado, então ela continua bloqueada mesmo depois de alguém aceitar. Aceite tudo no Tag Assistant, abra o último evento Consent e veja se o sinal mudou.
As tags do Google usam functionality_storage ou personalization_storage?
A visão geral do Consent Mode do Google define os dois, mas só descreve como as tags respondem a ad_storage, analytics_storage, ad_user_data e ad_personalization. Os dois sinais importam quando uma tag do seu contêiner os indica como tipo de consentimento exigido.
O que acontece se functionality_storage não tiver estado padrão?
Ela passa. A documentação de modelos do Google trata como concedido um tipo de consentimento que nunca foi definido, e o código do Tag Manager que lemos em novembro de 2026 faz o mesmo nas verificações de consentimento adicionais. Uma tag condicionada a um sinal sem estado pode disparar antes de o visitante escolher.
Uma tag bloqueada dispara sozinha quando o visitante aceita?
Não. A verificação é lida quando o acionador é executado e, no código do Tag Manager que lemos em novembro de 2026, uma tag bloqueada não é repetida quando o consentimento muda. Ela precisa de um acionador executado depois da atualização do consentimento, como o evento de consentimento da sua plataforma.
functionality_storage deve ser concedido por padrão?
Somente quando o armazenamento for estritamente necessário para algo que o visitante pediu. Pelas regras ePrivacy da UE, o restante do armazenamento aguarda o consentimento, então lá o seguro é um padrão negado seguido de uma atualização real. O Reino Unido agora tem exceções próprias, incluindo uma para adaptar um site às preferências do visitante, então consulte as orientações da ICO para o tráfego britânico.
© 2026 por
