Analytics e Dados
15 de out. de 2026
Go back
Google Tag Manager Settings: entenda a nova arquitetura do GTM, Destination Tags e o que muda na mensuração
Autor: Rafael Lins
Leitura estimada: 1 min
O Google Tag Manager ganhou Settings e Destination Tags. Entenda como atualizar containers, revisar permissões, otimizar performance e validar GA4 e Google Ads.

O Google Tag Manager (GTM) está passando por uma transformação importante em sua arquitetura de mensuração.
Depois das mudanças anunciadas pelo Google em agosto de 2026, uma nova experiência de gerenciamento começou a chegar aos containers, introduzindo a seção Settings, a utilização de Destination Tags e um processo de otimização que promete simplificar a comunicação entre o GTM e os produtos Google.
Em outubro de 2026, Benjamin Mangold, da Loves Data, publicou um guia prático sobre essa atualização, mostrando como funciona a migração de containers existentes e quais cuidados devem ser tomados.
A mudança é relevante para empresas, agências e profissionais que trabalham com Google Analytics 4 (GA4), Google Ads, Google Tag Manager e arquiteturas de mensuração.
Mas existe um detalhe importante:
A otimização é opcional, precisa ser validada antes da publicação e pode modificar permissões de acesso imediatamente.
Isso significa que não estamos falando apenas de uma atualização visual da interface.
Estamos diante de uma evolução na maneira como os dados são configurados e encaminhados aos destinos Google.
O que mudou no Google Tag Manager em 2026?
O Google começou a aproximar duas tecnologias que historicamente possuíam funções relacionadas, mas distintas.
O Google Tag funciona como uma camada de configuração e envio de informações aos produtos Google.
O Google Tag Manager permite gerenciar tags, eventos, acionadores, variáveis e integrações por meio de uma interface centralizada.
Com a nova arquitetura, parte dessas funcionalidades passa a funcionar de maneira mais integrada.
As principais mudanças incluem:
Nova seção Settings.
Destination Tags.
Envio mais direto de dados aos destinos Google.
Possibilidade de reduzir carregamentos intermediários de JavaScript.
Configurações mais centralizadas.
Novas relações de permissões entre contas.
Assistente para otimização de containers existentes.
Antes e depois da atualização
Característica | Modelo anterior | Nova experiência |
|---|---|---|
Configuração de destinos | Associada às Google Tags | Centralização por Destination Tags |
Configurações compartilhadas | Distribuídas entre tags e produtos | Gerenciamento em Settings |
Carregamento de JavaScript | Pode exigir biblioteca adicional | Possibilidade de envio direto pelo GTM |
Eventos | Tags e acionadores existentes | Eventos preservados durante a otimização |
Permissões | Acessos administrados por produto | Novos vínculos entre container e destinos |
Publicação | Versionamento tradicional | Versionamento continua disponível |
Atualização | Configuração existente | Otimização opcional |
A mudança não elimina os fundamentos do GTM.
Tags, triggers, variables, templates e folders continuam existindo.
O que muda é a organização da interface e a maneira como determinadas configurações e destinos são administrados.
O que é a nova seção Settings?
A seção Settings é uma área do Google Tag Manager destinada ao gerenciamento centralizado de configurações relacionadas aos destinos conectados ao container.
Um destino representa um produto ou recurso que recebe os dados enviados pela implementação.
Por exemplo:
Google Analytics 4.
Google Ads.
Outros destinos Google compatíveis.
Na nova experiência, determinadas configurações deixam de depender exclusivamente de Google Tags individuais e passam a ser administradas no próprio container.
Isso pode simplificar a operação, especialmente quando diferentes produtos compartilham informações de uma mesma implementação.
Settings não substitui Admin
Existe uma diferença importante entre essas áreas.
Admin continua concentrando funcionalidades administrativas, como gerenciamento de usuários e configurações da conta e do container.
Settings reúne configurações relacionadas à mensuração e aos destinos.
Também não significa que todas as opções do Google Analytics ou Google Ads foram transferidas para o GTM.
Cada produto continua mantendo suas próprias funcionalidades e configurações específicas.
O que são Destination Tags?
As Destination Tags representam uma das mudanças mais relevantes da nova arquitetura.
Elas conectam o container diretamente aos destinos Google responsáveis por receber os dados.
Na implementação anterior, determinadas configurações utilizavam o Google Tag como uma etapa intermediária.
Na arquitetura otimizada, o GTM pode encaminhar dados diretamente aos destinos compatíveis.
Arquitetura anterior simplificada
Site → Google Tag Manager → Google Tag → GA4 / Google Ads
Nova arquitetura otimizada
Site → Google Tag Manager → Destination Tags → GA4 / Google Ads
Essa representação é conceitual.
O comportamento real depende das tags existentes, dos destinos configurados e das funcionalidades utilizadas.
A principal mudança é a possibilidade de reduzir etapas adicionais de carregamento e processamento de JavaScript.
Destination Tags não substituem as tags de eventos
Esse ponto é fundamental.
Uma Destination Tag estabelece a conexão e as configurações necessárias para enviar dados ao produto Google.
As tags de eventos continuam responsáveis por registrar interações específicas.
Por exemplo:
Destination Tag: conexão com o Google Analytics.
Evento GA4: envio do evento generate_lead.
O processo de otimização foi desenvolvido para preservar os eventos e acionadores existentes.
Portanto, não é necessário presumir que todos os eventos precisarão ser reconstruídos.
Entretanto, preservar a configuração não elimina a necessidade de testar seu funcionamento.
A atualização é obrigatória?
Não.
Segundo a documentação do Google e o guia publicado pela Loves Data, a otimização de containers existentes é opcional.
Isso permite que empresas avaliem a mudança antes de implementá-la em produção.
A cautela é especialmente importante em containers que possuem:
Ecommerce.
Eventos personalizados.
Conversões do Google Ads.
Enhanced Conversions.
Consent Mode.
Múltiplas propriedades GA4.
Integrações com CRM.
Server-side tagging.
Cross-domain measurement.
Tags de terceiros.
Scripts personalizados.
Nesses ambientes, a atualização deve ser tratada como uma alteração controlada da infraestrutura de mensuração.
Como atualizar o Google Tag Manager?
O processo apresentado pela Loves Data utiliza o assistente de otimização disponibilizado pelo Google.
A interface pode variar conforme a disponibilidade da funcionalidade e as características do container.
Etapa 1: acessar o assistente
Dentro do Google Tag Manager:
Abra o container web.
Acesse Overview.
Localize Container quality.
Identifique a opção de otimização, quando disponível.
Selecione Optimize for faster, easier tagging.
Clique em Get started.
O assistente apresenta a experiência Optimize your Tag Manager container.
Nela, o usuário pode revisar as mudanças propostas para melhorar a configuração e a performance.
Etapa 2: revisar as tags selecionadas
O assistente identifica Google Tags elegíveis para otimização.
Antes de avançar, confira:
Identificadores dos destinos.
Contas associadas.
Propriedades de produção.
Propriedades de teste.
Configurações existentes.
Permissões solicitadas.
Essa revisão é especialmente importante em operações que administram múltiplos clientes.
O nome de uma propriedade não deve ser a única referência para identificação.
Sempre que possível, valide também seus identificadores.
Etapa 3: escolher as configurações do container
Durante a migração, o GTM pode encontrar configurações diferentes entre Google Tags existentes.
Nesse caso, o assistente apresenta a etapa Choose container settings.
O usuário pode comparar os valores disponíveis e selecionar a configuração que servirá como referência.
Isso merece atenção em implementações que possuem:
Domínios diferentes.
Configurações de cookies.
Parâmetros personalizados.
Regras de mensuração.
Configurações de eventos automáticos.
O assistente não deve ser tratado como um mecanismo que necessariamente combina todas as configurações existentes de maneira ideal.
É necessário revisar as diferenças.
Também pode existir a opção Do not import Google tag settings.
Nesse cenário, as configurações necessárias deverão ser revisadas e definidas manualmente.
Etapa 4: revisar as alterações propostas
Antes de adicionar as mudanças ao workspace, utilize a opção de visualização dos detalhes.
O fluxo apresentado pela Loves Data inclui:
Show details → Preview changes
Essa etapa permite analisar:
Destination Tags adicionadas.
Configurações importadas.
Tags modificadas.
Destinos associados.
Workspace selecionado.
Alterações de permissões.
Somente depois dessa revisão as mudanças devem ser adicionadas ao workspace.
Atenção: permissões podem mudar imediatamente
Este é provavelmente o ponto mais sensível de toda a atualização.
O processo de otimização pode criar vínculos externos entre contas e destinos Google.
Segundo o guia da Loves Data, determinadas alterações de permissões entram em vigor imediatamente quando são adicionadas ao workspace.
Isso pode acontecer antes da publicação da nova versão do container.
Diferença entre configuração e permissão
Tipo de alteração | Momento de aplicação |
|---|---|
Configurações de tags | Após publicação do container |
Destination Tags no workspace | Após publicação |
Vínculos externos e permissões | Podem entrar em vigor imediatamente |
Histórico de versões | Registra alterações versionadas do container |
Alterações administrativas de acesso | Não devem ser presumidas como reversíveis por rollback |
Isso possui implicações importantes para agências e empresas.
Uma operação pode administrar o GTM de um cliente sem possuir acesso administrativo completo ao Google Analytics ou Google Ads.
Durante a otimização, novas relações de acesso podem ser estabelecidas.
Por isso, é fundamental revisar os vínculos e permissões envolvidos.
Onde verificar os vínculos?
O guia da Loves Data indica a área:
Admin → External Account Links
Nela, é possível revisar os vínculos externos associados ao container.
A recomendação é conferir quais contas estão conectadas e se os acessos correspondem às responsabilidades de cada equipe.
Um rollback do container não deve ser considerado suficiente para desfazer alterações externas de permissões.
A atualização pode melhorar a performance?
Um dos benefícios anunciados pelo Google é a possibilidade de reduzir o JavaScript carregado na página.
Em determinadas implementações, o GTM precisava carregar componentes adicionais do Google Tag para encaminhar dados aos destinos.
Com a arquitetura otimizada, parte desse processamento pode ser simplificada.
Isso pode resultar em:
Menos carregamentos intermediários.
Redução de determinadas requisições.
Menor trabalho de inicialização.
Comunicação mais direta com destinos Google.
Entretanto, é importante separar benefício arquitetural de ganho mensurável.
A atualização não garante automaticamente:
Melhoria de Core Web Vitals.
Redução significativa do LCP.
Melhoria do INP.
Aumento de conversões.
Redução de todos os scripts de terceiros.
O resultado depende da implementação existente.
Um site com dezenas de scripts externos continuará sujeito ao custo de execução desses recursos.
Como avaliar o impacto?
Indicador | Objetivo |
|---|---|
Requisições de rede | Identificar redução de carregamentos |
JavaScript transferido | Comparar bytes antes e depois |
Execução de JavaScript | Avaliar processamento |
Main thread | Identificar tarefas de longa duração |
LCP | Avaliar carregamento do conteúdo principal |
INP | Avaliar responsividade |
CLS | Verificar estabilidade visual |
Eventos enviados | Confirmar integridade da mensuração |
Chrome DevTools, Lighthouse e PageSpeed Insights podem ajudar nessa análise.
Os testes devem ser realizados em condições comparáveis.
O que muda para o Google Analytics 4?
Para implementações de GA4, a nova arquitetura simplifica a conexão entre o container e o destino Google Analytics.
Mas isso não significa que todos os eventos devam ser reconstruídos.
O processo de otimização busca preservar as tags existentes.
Ainda assim, é necessário validar a coleta.
Eventos automáticos
Verifique se a detecção automática de eventos continua configurada corretamente.
Page views
Confirme se as visualizações de página continuam sendo registradas.
Em sites com implementação manual de page_view, é importante verificar possíveis duplicidades.
Enhanced Measurement
Revise a relação entre os eventos automáticos do GA4 e aqueles configurados diretamente no GTM.
Cross-domain
Confirme se os domínios utilizados na mensuração entre sites permanecem configurados corretamente.
Eventos personalizados
Valide os eventos relevantes para o negócio.
Por exemplo:
generate_leadsign_uploginpurchasebegin_checkoutform_submit
Ecommerce
Para implementações comerciais, confira especialmente:
transaction_idvaluecurrencyitemsitem_iditem_namequantity
Um evento purchase pode continuar sendo enviado e, ainda assim, apresentar problemas nos parâmetros de receita.
Por isso, validar apenas a presença do evento não é suficiente.
O que muda para o Google Ads?
No Google Ads, a atenção deve estar nas tags de conversão e nos destinos conectados.
A nova arquitetura pode simplificar o encaminhamento dos dados, mas não elimina a necessidade de revisar:
IDs de conversão.
Rótulos de conversão.
Eventos utilizados.
Valores de conversão.
Moedas.
Enhanced Conversions.
Consentimento.
Deduplicação.
Configurações de atribuição.
Também é importante distinguir a atualização do GTM de outras mudanças realizadas pelo Google em seus produtos de mensuração.
A evolução da interface não significa que todas as configurações de conversão do Google Ads foram transferidas para Settings.
O Conversion Linker ainda é necessário?
Essa é uma das dúvidas mais relevantes.
Segundo a Loves Data, o Google confirmou que, para destinos conectados diretamente por Destination Tags em containers web otimizados, determinadas funcionalidades anteriormente cobertas pelo Conversion Linker passam a ser atendidas pela nova arquitetura.
Isso pode reduzir a necessidade de manter uma tag Conversion Linker separada em determinadas implementações.
Mas existe uma ressalva importante.
Não remova automaticamente o Conversion Linker de todos os containers.
Antes de qualquer alteração, verifique:
Quais destinos foram efetivamente otimizados.
Quais continuam utilizando a configuração anterior.
Como estão implementadas as conversões do Google Ads.
Se existem configurações específicas de cookies.
Se a operação utiliza server-side tagging.
Se existem dependências adicionais.
A remoção de uma tag deve acontecer somente depois da validação de que sua funcionalidade está coberta pela nova configuração.
E o server-side GTM?
A otimização apresentada pela Loves Data está relacionada ao container web.
Ela não substitui automaticamente um container server-side.
Em uma arquitetura de server-side tagging, o fluxo pode envolver:
Site → GTM Web → Server Container → Destinos
Se a implementação utiliza um servidor de tagging próprio, é necessário confirmar que o encaminhamento continua correto após a atualização.
Verifique:
URL do servidor de tagging.
Requisições recebidas.
Parâmetros enviados.
Identificação dos eventos.
Destinos processados.
Configurações de consentimento.
A nova arquitetura não elimina automaticamente a necessidade de manter a infraestrutura server-side existente.
Consent Mode continua necessário
A atualização também não substitui o Consent Mode.
O Consent Mode continua responsável por comunicar os estados de consentimento aos produtos Google, conforme a implementação adotada.
Durante os testes, é importante verificar cenários como:
Consentimento negado
e
Consentimento concedido
O comportamento deve permanecer compatível com a configuração de privacidade e com as políticas aplicáveis.
No Brasil, também é necessário considerar os requisitos da LGPD.
A simplificação técnica do envio de dados não representa autorização para ignorar regras de consentimento ou tratamento de dados pessoais.
Ter Settings no menu significa que o container já foi atualizado?
Não.
Esse ponto é destacado no guia da Loves Data.
A presença da seção Settings não significa necessariamente que o container já foi migrado para Destination Tags.
É possível visualizar a nova interface e continuar utilizando uma configuração anterior.
Portanto, não basta verificar se o menu existe.
É necessário analisar:
Os destinos conectados.
As tags utilizadas.
A configuração de envio de dados.
O status da otimização.
As alterações publicadas.
A mesma cautela vale para a ausência de um aviso de atualização.
Nem todos os containers precisam apresentar exatamente a mesma experiência de migração.
A nova arquitetura substitui todas as funcionalidades do GTM?
Não.
O Google continua diferenciando os tipos de containers e identificadores.
Containers tradicionais com identificadores iniciados por GTM- continuam oferecendo recursos como:
Tags.
Triggers.
Variables.
Custom HTML.
Templates.
Integrações de terceiros.
Já estruturas associadas a identificadores como G- e AW- possuem capacidades específicas.
A aproximação entre Google Tag e Google Tag Manager não significa que qualquer identificador possa executar arbitrariamente scripts de terceiros.
Essa distinção é importante para evitar interpretações equivocadas sobre a unificação anunciada pelo Google.
Checklist de validação antes de publicar
A atualização deve ser tratada como uma alteração de produção.
O checklist abaixo reúne os principais pontos de atenção.
Verificação | O que confirmar |
|---|---|
Backup lógico | Versão anterior identificada e exportação do container, quando apropriado |
Destinos | IDs e contas corretos |
Settings | Configurações importadas corretamente |
Permissões | Vínculos externos revisados |
Destination Tags | Acionamento esperado |
GA4 | Eventos enviados corretamente |
Google Ads | Conversões enviadas corretamente |
Ecommerce | Valores e parâmetros preservados |
Duplicidade | Ausência de eventos duplicados não intencionais |
Consent Mode | Comportamento conforme consentimento |
Cross-domain | Continuidade da mensuração |
Server-side | Encaminhamento correto, quando aplicável |
Performance | Comparação antes e depois |
Preview | Testes realizados no Tag Assistant |
Publicação | Versão documentada |
Produção | Validação após publicação |
O ideal é documentar o estado anterior da implementação e registrar as alterações realizadas.
Isso facilita a identificação de problemas e a comparação dos resultados.
Como essa mudança afeta a governança de mensuração?
A evolução do GTM também reforça a importância de tratar mensuração como infraestrutura.
Em operações maiores, a implementação envolve diferentes responsabilidades:
Marketing: define objetivos e conversões.
Analytics: estrutura eventos, parâmetros e indicadores.
Desenvolvimento: implementa dataLayer e integrações.
Mídia: utiliza sinais de conversão para otimização.
Privacidade: define requisitos de consentimento e tratamento de dados.
TI e segurança: administram acessos, infraestrutura e permissões.
A nova arquitetura aproxima algumas dessas responsabilidades.
Por isso, a atualização não deve ser executada sem que os responsáveis compreendam suas implicações.
Em ambientes com múltiplos clientes, a revisão de acessos é especialmente importante.
O que muda para agências que administram vários containers?
Agências que operam Google Tag Manager para diferentes clientes precisam adotar uma abordagem controlada.
Cada container pode possuir características próprias.
Por exemplo:
Um cliente utiliza apenas GA4.
Outro utiliza GA4 e Google Ads.
Outro possui ecommerce.
Outro utiliza server-side tagging.
Outro possui múltiplos domínios.
Outro depende de integrações de terceiros.
Isso significa que não existe necessariamente um procedimento único que possa ser aplicado sem validação em todos os containers.
A atualização deve considerar a arquitetura real de cada projeto.
Também é importante evitar alterações simultâneas em muitos clientes sem um processo de homologação.
A nova configuração pode ser adequada, mas precisa ser validada no contexto específico da operação.
A mudança representa o fim do Google Tag Manager tradicional?
Não.
O Google está evoluindo o produto, não eliminando sua função de gerenciamento de tags.
A nova arquitetura aproxima configurações, destinos e ferramentas de mensuração.
Mas os recursos tradicionais continuam necessários.
O GTM ainda desempenha um papel central na implementação de:
Eventos personalizados.
DataLayer.
Tags de terceiros.
Conversões.
Integrações.
Consentimento.
Mensuração de ecommerce.
Configurações avançadas.
A diferença é que parte do gerenciamento dos produtos Google está se tornando mais integrada.
O que fazer agora?
Para quem já utiliza Google Tag Manager, o primeiro passo não deveria ser atualizar imediatamente todos os containers.
O mais adequado é realizar uma revisão técnica.
Sequência recomendada
Identificar se o container possui a nova experiência.
Revisar os destinos Google existentes.
Documentar a configuração atual.
Conferir as permissões.
Avaliar a elegibilidade para otimização.
Revisar as mudanças propostas pelo assistente.
Testar em Preview.
Validar GA4, Google Ads e demais integrações.
Publicar uma versão documentada.
Confirmar o funcionamento em produção.
Essa abordagem reduz o risco de alterar uma implementação que já funciona corretamente.
Conclusão
A introdução de Settings e Destination Tags representa mais uma etapa na evolução do Google Tag Manager.
A proposta do Google é simplificar o gerenciamento das configurações e tornar o envio de dados aos destinos mais eficiente.
Entre os benefícios potenciais estão:
Centralização de configurações.
Menor complexidade de implementação.
Redução de carregamentos intermediários.
Integração mais direta com produtos Google.
Maior visibilidade dos destinos conectados.
Entretanto, a atualização também introduz responsabilidades importantes.
A revisão de permissões, a validação dos eventos e a documentação das alterações continuam fundamentais.
A principal recomendação é tratar a otimização como uma mudança de infraestrutura de mensuração, não como uma atualização cosmética da interface.
Um container atualizado não é necessariamente um container melhor implementado.
A qualidade depende da integridade dos dados, da configuração correta dos eventos, da governança dos acessos e da capacidade de validar os resultados.
Na Ad Rock Digital Mkt, projetos de mensuração são estruturados considerando Google Tag Manager, GA4, Google Ads, Consent Mode, dataLayer e integrações de dados.
A evolução dessas ferramentas reforça a importância de uma arquitetura de analytics organizada, documentada e compatível com ambientes de produção.
Fontes e referências
Loves Data, Google Tag Manager Settings: How to Update Your Container, outubro de 2026
https://www.lovesdata.com/blog/google-tag-manager-settings/
Google, About the updated Google Tag Manager experience
https://support.google.com/tagmanager/answer/17079602
Google, About Google Tag Manager container optimization
https://support.google.com/analytics/answer/16659369
Google, Google Tag Manager settings
https://support.google.com/tagmanager/answer/17070049
Google, Add Google Analytics as a destination in Google Tag Manager
https://support.google.com/tagmanager/answer/17096871
Google Developers, Server-side tagging
https://developers.google.com/tag-platform/tag-manager/server-side/overview
Google Developers, Consent Mode
https://developers.google.com/tag-platform/security/concepts/consent-mode
Nota técnica
A disponibilidade de recursos, os nomes dos controles e o comportamento do assistente de otimização podem variar conforme o tipo de container, os destinos conectados e o estágio de implantação da atualização. Antes de realizar alterações em produção, recomenda-se verificar a documentação oficial e validar o comportamento da implementação existente.
Go back





