Todo site que mede alguma coisa com o Google Tag Manager tem, ou deveria ter, um data layer. É por ele que a página conta às tags o que aconteceu: que um formulário foi enviado, que um plano foi escolhido, que uma compra foi concluída e por qual valor. Quando ele é bem desenhado, o GA4 e o Google Ads recebem dados limpos. Quando não é, as métricas quebram em silêncio — ou, pior, saem do site com o e-mail do cliente dentro.
Os guias que aparecem primeiro na busca explicam bem a sintaxe, mas quase nenhum fala de dado pessoal; alguns chegam a mostrar exemplos que empurram o e-mail do usuário para a camada sem aviso. Este artigo é para quem contrata ou coordena o site, não só para quem programa: o que é o data layer, como ele funciona, os três erros que quebram a coleta e a regra do que pode, do que só vai com hash e do que nunca deve sair da página.
O que é data layer?
Data layer, ou camada de dados, é um objeto JavaScript que fica na página e guarda as informações que as ferramentas de medição vão usar. Segundo a documentação oficial do Google sobre o data layer, ele é o objeto usado pelo Google Tag Manager e pelo gtag.js para passar informações às tags. Os acionadores do Tag Manager podem disparar a partir dos valores que estão nele.
Pense nele como uma caixa de correio entre o site e as ferramentas. O site deposita mensagens ("o formulário de orçamento foi enviado", "o pedido custou R$ 480"); o Tag Manager lê a caixa e decide qual tag dispara e com quais dados. O GA4, o Google Ads e outras plataformas nunca precisam olhar o código da página: olham só o que foi depositado ali.
Essa separação é a razão de existir do data layer. Sem ele, cada tag tenta descobrir sozinha o que aconteceu, lendo o texto de um botão ou a posição de um elemento — e quebra na primeira mudança de layout.
O que é data layer no Tag Manager?
No Google Tag Manager, o data layer é a variável window.dataLayer, uma lista em que o site adiciona objetos com dataLayer.push(). O Tag Manager lê essa lista e oferece duas coisas a partir dela: eventos, que servem de acionador, e variáveis da camada de dados, que levam valores para dentro das tags.
Um evento é empurrado com a chave event. A documentação do Google mostra o formato dataLayer.push({'event': 'nome_do_evento'}), em que o nome descreve a ação, como "login" ou "purchase". No Tag Manager, um acionador do tipo evento personalizado escuta exatamente esse nome. Junto com o evento podem ir outros pares de chave e valor — o tipo de formulário, o plano, o valor —, que viram variáveis.
Há uma regra simples e frequentemente ignorada: só é permitido um objeto dataLayer por página. A documentação avisa que várias instâncias podem impedir as tags de disparar.
Como o data layer funciona, passo a passo?
O caminho do dado tem quatro etapas, e entender onde cada uma acontece é o que permite ao marketing conversar com o desenvolvimento sem traduzir tudo.
- A página declara a camada, antes do código do Tag Manager, com
window.dataLayer = window.dataLayer || []. - O site empurra informações quando algo acontece: uma página carregada, um formulário enviado, um item no carrinho.
- O Tag Manager lê a camada: um evento aciona a tag, e as variáveis entregam os valores.
- A tag envia o dado à plataforma: o GA4 registra o evento, o Google Ads registra a conversão.
Duas consequências práticas. Primeiro, o que não está no data layer não chega a lugar nenhum por esse caminho — o que faz dele o melhor ponto para barrar dado pessoal. Segundo, as variáveis valem enquanto o visitante está naquela página. A documentação lembra que, para uma informação acompanhar várias páginas, ela precisa ser declarada em cada uma, sempre com o mesmo nome.
Qual a diferença entre o data layer e a tag do Google?
A confusão é comum porque os dois andam juntos. A tag do Google (gtag.js) e o contêiner do Tag Manager são os códigos que enviam dados para as plataformas. O data layer é a fonte de onde eles leem. O próprio gtag.js usa uma camada de dados por baixo; o Tag Manager apenas dá mais controle sobre ela.
| Data layer | Contêiner do Tag Manager | Tag do GA4 ou do Ads | |
|---|---|---|---|
| O que é | Lista de dados na página | Código que gerencia as tags | Código que envia a uma plataforma |
| Quem escreve | Desenvolvimento, a partir do plano | Analista de mensuração | Configurada dentro do contêiner |
| O que contém | Eventos e valores do negócio | Acionadores, variáveis e tags | Os parâmetros que vão à plataforma |
| Erro típico | Sobrescrever ou grafar errado | Acionador escutando nome errado | Parâmetro com dado pessoal |
| Quem responde | Dono do plano de mensuração | Analista que publica a versão | Quem configurou a tag |
Elaborado pela Alliance a partir da documentação do Google sobre o data layer.
Se a dúvida é se o site precisa de Tag Manager ou se a tag do Google resolve sozinha, ela é tratada no artigo sobre quando o Google Tag Manager é necessário e quando a tag do Google basta. Aqui, o foco é o que entra na camada.
Como criar e configurar o data layer no Google Tag Manager?
A configuração tem uma parte que é código no site e outra que é configuração no Tag Manager. As duas precisam usar exatamente os mesmos nomes.
1. Declare a camada no lugar certo
A documentação do Google pede que o data layer seja instanciado o mais alto possível no código-fonte, acima do snippet do contêiner, com window.dataLayer = window.dataLayer || []. Essa forma cria a lista se ela não existir e preserva o que já houver, se existir.
2. Empurre eventos com push, nunca com atribuição
Cada informação nova entra com dataLayer.push(). Um envio de formulário, por exemplo, empurra um objeto com event: 'envio_formulario' e, junto, tipo_formulario: 'orcamento'. Nada de e-mail, nome ou telefone nesse objeto.
3. Crie as variáveis e o acionador no Tag Manager
No Tag Manager, crie uma variável do tipo camada de dados para cada chave que importa (por exemplo, tipo_formulario) e um acionador de evento personalizado com o nome exato do evento. Depois, ligue o acionador e as variáveis à tag do GA4.
4. Use os mesmos nomes em todas as páginas
A documentação dá o exemplo: se uma página usa visitorType, outra não pode usar visitor_type. Para o Tag Manager, são duas variáveis diferentes, e metade dos dados some.
Para escolher quais eventos valem a pena — e não lotar a camada de coisas que ninguém vai olhar —, vale ler o guia de quais eventos do GA4 acompanhar do lead ao cliente.
Quais os erros que quebram a coleta em silêncio?
Os três erros abaixo têm algo em comum: nenhum deles gera aviso na tela. O site funciona, o formulário envia, e o relatório simplesmente fica vazio ou incompleto. Todos estão descritos na documentação do Google.
1. Sobrescrever a camada com dataLayer = []
A documentação é explícita: nunca sobrescreva nem reatribua a variável window.dataLayer. Reatribuir descarta tudo o que já estava lá. É um erro comum quando um plugin, um tema ou um desenvolvedor novo "inicializa" a camada no meio da página, depois do contêiner, e apaga os dados que o Tag Manager já esperava.
2. Grafar o nome errado
O nome do objeto diferencia maiúsculas de minúsculas. Segundo o Google, datalayer.push() não funciona; o correto é dataLayer.push(). O mesmo vale para os nomes de evento e de variável: "Envio_Formulario" e "envio_formulario" são coisas diferentes para o acionador.
3. Declarar depois do contêiner
Se a declaração vem abaixo do código do Tag Manager, ou se informações da página são empurradas depois que as tags de carregamento já dispararam, essas tags leem uma camada incompleta. O resultado é página registrada sem a categoria, sem o tipo de visitante ou sem o valor.
Por que o e-mail não pode ir para o GA4?
Aqui está a lacuna dos guias técnicos. A política do Google Analytics sobre informação de identificação pessoal é direta: nenhum dado que o Google possa usar ou reconhecer como informação de identificação pessoal deve ser enviado ao Google Analytics.
O caminho mais comum do vazamento não é intencional. É o exemplo copiado de um tutorial que empurra user_email para o data layer; é o formulário que coloca o e-mail na URL da página de agradecimento; é o campo de busca interna em que o visitante digita o próprio telefone. A política do Google lista justamente esses pontos: URL e título da página, parâmetros de evento e de campanha, termos de busca no site e campos digitados pelo usuário precisam estar livres de dado pessoal.
O GA4 oferece uma proteção parcial: a redação de dados, configurada no Administrador, que remove endereços de e-mail e parâmetros de consulta escolhidos. A própria página avisa que a remoção de e-mail é feita na base do melhor esforço e que o recurso só vale para fluxos de dados da web. É uma rede de segurança, não a regra. A regra é o dado não entrar.
Há também a camada da lei. E-mail e telefone de um lead são dados pessoais para a LGPD, e quem os coleta precisa saber para onde eles vão. O artigo sobre o que a LGPD considera dado pessoal, incluindo o cookie ajuda a enxergar o tamanho dessa definição.
O que pode ir para o data layer, o que só vai com hash e o que nunca sai do site?
A classificação abaixo resolve a maior parte das dúvidas de um plano de mensuração. Ela parte de uma pergunta: o dado descreve a ação ou identifica a pessoa? Se descreve a ação, ele serve à medição. Se identifica a pessoa, ele só pode seguir para a plataforma que tem um mecanismo próprio para isso.
O grupo do meio merece explicação. Plataformas de mídia usam dados do cliente para medir conversões com mais precisão. As conversões otimizadas do Google Ads, por exemplo, recebem e-mail, nome, endereço ou telefone transformados por um algoritmo de hash de mão única chamado SHA-256 antes de saírem do site ou do servidor. O dado chega como uma sequência que serve para comparação, não como o endereço legível.
Mesmo nesse caso, duas regras continuam valendo: o dado com hash vai apenas para a tag da plataforma que o usa, nunca para uma variável que alimente o GA4; e a empresa precisa ter base legal e transparência para usar o dado do cliente dessa forma. Já CPF, mensagem livre, dado de saúde ou financeiro não têm razão de sair do site: ficam no CRM, onde a empresa os controla.
O data layer existe no GTM do lado do servidor?
Não do mesmo jeito. O data layer é um objeto da página, no navegador do visitante. O contêiner de servidor do Tag Manager roda fora do navegador e trabalha com as requisições que recebe — por exemplo, as enviadas pela tag do GA4 —, que transforma em dados de evento para as tags de servidor.
Na prática, a camada da página continua sendo a origem. O que o site empurra para o data layer é o que a tag do navegador envia ao servidor. Por isso o contêiner de servidor não conserta um data layer que já nasce com e-mail dentro: ele pode filtrar o que repassa, mas o dado já saiu da página. A regra de não deixar entrar vale para as duas arquiteturas.
Quais são as boas práticas para gerenciar o data layer?
O data layer não é só código: é um contrato entre quem precisa medir e quem constrói o site. Os sites que mantêm a coleta saudável por anos costumam seguir estas práticas:
- Plano de mensuração escrito: cada evento, com nome, momento em que dispara e variáveis que leva. É o documento que o marketing assina e o desenvolvimento implementa.
- Um dono nomeado, que aprova qualquer evento novo e mantém o plano atualizado.
- Convenção de nomes: minúsculas e sublinhado, sempre, para evitar o erro de grafia.
- Lista de campos proibidos no plano: e-mail, telefone, nome, documento, mensagem livre.
- Teste a cada mudança no site: redesenho, plugin novo e troca de formulário são os momentos em que a camada costuma quebrar.
- Versões documentadas no Tag Manager, com descrição do que mudou em cada publicação.
Como testar a configuração do data layer?
O teste tem três camadas, da mais simples à mais completa:
- Console do navegador: digitar
dataLayermostra o conteúdo da camada; repita depois de cada ação que deveria gerar evento. - Modo de visualização do Tag Manager: mostra, para cada evento, o que havia na camada, quais tags dispararam e quais não dispararam.
- Relatório em tempo real e DebugView do GA4: confirmam que o evento chegou com os parâmetros esperados — e permitem conferir que nenhum parâmetro traz e-mail ou telefone.
- Revisão das URLs: navegue pelo fluxo de formulário e confira se a página de agradecimento não carrega dados do visitante no endereço.
Ao fim do teste, compare o que viu com o plano de mensuração. O que está na camada e não está no plano é ruído ou risco; o que está no plano e não aparece na camada é métrica perdida.
Por onde começar hoje
Abra o console no seu site, envie um formulário de teste e veja o que o data layer guarda. Se aparecer dado pessoal, corrija antes de qualquer outra coisa. Depois, escreva — ou peça — o plano de mensuração com a lista do que pode, do que só vai com hash e do que nunca sai do site, e nomeie quem responde por ele.
Se a empresa precisa montar essa estrutura do zero ou revisar a que existe, o serviço de Web Analytics da Alliance cuida do plano de mensuração, da implementação no Tag Manager e dos testes. E para ver como os dados se encaixam no restante do marketing, o diagnóstico de marketing gratuito da Alliance leva cerca de 30 minutos e aponta a maturidade da empresa em cada frente, incluindo dados e mensuração.