Google unifica Google Tag e Google Tag Manager: o que muda na implementação, performance e gestão de tags

O Google anunciou em 20 de agosto de 2026 uma das mudanças mais importantes dos últimos anos na sua infraestrutura de mensuração.

A empresa começou a unificar o Google tag e o Google Tag Manager em uma experiência mais integrada.

A atualização não elimina o GTM.

Também não transforma automaticamente todas as implementações existentes.

O que o Google está fazendo é aproximar duas arquiteturas que historicamente funcionavam de forma relacionada, mas com interfaces, capacidades e fluxos de configuração diferentes.

Segundo a documentação oficial, as mudanças têm três objetivos principais:

• simplificar a configuração de mensuração;

• melhorar performance e gerenciamento;

• oferecer uma experiência mais unificada entre os produtos de tagging do Google.

Na prática, isso afeta desde sites simples que utilizam apenas uma Google tag até implementações mais avançadas com Google Tag Manager, Google Analytics 4, Google Ads, eventos personalizados, conversões e múltiplos destinos.

O que foi anunciado em 20 de agosto de 2026

O anúncio oficial apresenta três grandes frentes:

1. nova interface simplificada do Google Tag Manager;

2. unificação entre Google tag e Google Tag Manager;

3. visual tagging para criação de eventos e conversões com menos configuração manual.

Essas mudanças não devem ser tratadas apenas como uma alteração visual.

Elas indicam uma evolução da arquitetura de tagging do Google.

Google tag e Google Tag Manager não eram a mesma coisa

Antes de entender a mudança, é importante separar os conceitos.

Google tag

A Google tag é a infraestrutura utilizada pelos produtos Google para coleta e envio de dados.

Ela pode ser identificada por IDs como:

• G- para Google Analytics;

• AW- para Google Ads.

Uma implementação simples podia utilizar diretamente uma Google tag no site sem depender de um container completo do Google Tag Manager.

Google Tag Manager

O Google Tag Manager é um sistema mais amplo de gerenciamento de tags.

Ele permite trabalhar com:

• tags;

• triggers;

• variáveis;

• templates;

• Custom HTML;

• scripts de terceiros;

• workspaces;

• versionamento;

• debugging;

• permissões.

Tradicionalmente, uma implementação podia carregar uma Google tag através do próprio GTM.

Com a atualização de 2026, essa separação começa a ficar menos visível para o usuário.

O Google tag passa a ganhar capacidades completas de container

A mudança mais importante é esta:

Google tags serão atualizadas para containers com capacidades completas de Google Tag Manager.

Segundo o Google, sites que utilizam apenas Google tag passarão a poder utilizar recursos associados ao GTM, incluindo:

• interface de configuração;

• tagging baseado em interface;

• debugging;

• versionamento.

Isso reduz a distância entre uma implementação direta de Google tag e uma implementação tradicional com GTM.

Isso significa que todo Google tag virou GTM?

Conceitualmente, a infraestrutura está sendo unificada.

Mas existem diferenças importantes conforme o ID utilizado.

O Google publicou uma documentação específica explicando que o prefixo do container determina quais capacidades podem ser executadas.

Container com prefixo GTM-

Exemplo:

GTM-ABCDEFG

Esse tipo de container permite:

• tags Google;

• scripts de terceiros;

• Custom HTML;

• JavaScript personalizado;

• outros recursos do Tag Manager.

É o modelo mais flexível.

Container com prefixo G- ou AW-

Exemplos:

G-ABCDEFG

AW-123456789

Esses containers ficam restritos a tags Google.

Segundo o Google, eles podem enviar dados exclusivamente para serviços Google e não executam scripts arbitrários de terceiros.

Isso cria uma distinção interessante.

A interface e infraestrutura podem ser unificadas, mas o nível de capacidade continua controlado pelo identificador utilizado.

Por que essa distinção é importante para segurança

Um container GTM- pode executar códigos de terceiros.

Isso é extremamente poderoso.

Também exige mais governança.

Um container restrito a G- ou AW- possui uma superfície de execução menor.

Para empresas que precisam apenas de:

• GA4;

• Google Ads;

• conversões;

• remarketing Google;

essa arquitetura pode oferecer um ambiente mais controlado.

Já implementações que dependem de:

• Meta Pixel;

• LinkedIn Insight Tag;

• ferramentas de heatmap;

• chat;

• scripts próprios;

• vendors de marketing;

continuarão precisando das capacidades completas de um container GTM-.

Nova interface do Google Tag Manager

A página Overview do GTM está sendo redesenhada.

O objetivo declarado pelo Google é simplificar a navegação tanto para usuários iniciantes quanto para profissionais experientes.

Uma das mudanças mais visíveis é a criação de uma nova seção:

Settings

Ela centraliza configurações relacionadas ao container e aos destinos Google.

O que entra em Settings

A nova área concentra informações como:

• configurações compartilhadas;

• destinos Google;

• fluxo de dados;

• relacionamento entre o container e os produtos Google conectados.

Essa centralização reduz parte da fragmentação que existia anteriormente.

Em implementações com múltiplas tags Google, algumas configurações podiam existir repetidas ou com diferenças entre tags.

A nova arquitetura busca consolidar esses comportamentos.

O menu Advanced

Recursos tradicionais do Tag Manager passam a aparecer dentro de uma seção expansível chamada:

Advanced

Entre eles:

• Triggers;

• Variables;

• Templates;

• Folders.

Esses recursos não estão sendo removidos.

O Google afirma explicitamente que a atualização da interface não elimina funcionalidades existentes.

A mudança é principalmente organizacional.

A parte mais técnica: GTM poderá deixar de carregar gtag.js adicionalmente

Essa é provavelmente a mudança mais interessante para quem trabalha com performance.

Segundo o Google, após a otimização do container, o Tag Manager poderá enviar dados diretamente para destinos Google.

Historicamente, determinadas implementações do GTM carregavam JavaScript adicional do gtag.js para enviar informações aos produtos Google.

A nova arquitetura elimina essa camada adicional em determinados cenários.

O Google afirma que isso pode melhorar a performance do site ao reduzir latência na transmissão da mensuração.

Antes da otimização

Uma arquitetura simplificada podia envolver:

Site → GTM → carregamento adicional de gtag.js → Google destination

Cada recurso JavaScript adicional possui algum custo.

Pode envolver:

• requisição;

• download;

• parsing;

• execução;

• inicialização.

Em sites com implementações pesadas, esses custos se acumulam.

Depois da otimização

O fluxo passa a poder funcionar de forma mais direta:

Site → Google Tag Manager → Google destination

Segundo o Google, isso permite enviar dados diretamente aos destinos sem carregar o gtag.js adicional.

É importante não transformar isso em uma promessa de aumento significativo de Core Web Vitals em qualquer site.

O impacto real dependerá da implementação.

Mas arquiteturalmente, eliminar uma dependência JavaScript intermediária é uma melhoria positiva.

Isso vai deixar o GTM mais rápido automaticamente?

Não necessariamente.

O Google está melhorando a forma como suas próprias tags podem operar dentro da nova arquitetura.

Isso não corrige problemas como:

• dezenas de scripts de terceiros;

• Custom HTML excessivo;

• triggers mal configurados;

• tags duplicadas;

• pixels desnecessários;

• listeners pesados;

• JavaScript personalizado ineficiente.

Um container mal estruturado continuará podendo impactar a página.

A atualização melhora a infraestrutura Google.

Ela não substitui uma auditoria de GTM.

O novo processo de otimização do container

Usuários atuais do Google Tag Manager poderão receber um banner oferecendo a otimização.

Segundo a documentação oficial, o processo não acontece automaticamente.

O usuário precisa iniciar a migração.

Isso é importante.

O Google recomenda a otimização, mas a decisão de publicar continua sob controle da equipe responsável pelo container.

Quando todas as Google tags possuem a mesma configuração

Se as configurações já forem consistentes, o processo tende a ser simples.

O fluxo oficial inclui:

1. acessar a página Overview do container;

2. localizar o banner de otimização;

3. selecionar Review details;

4. revisar as configurações;

5. opcionalmente visualizar as alterações;

6. adicionar as mudanças ao workspace;

7. testar;

8. publicar.

Quando existem configurações diferentes

O cenário fica mais delicado quando existem múltiplas Google tags com configurações conflitantes.

Nesse caso, o Google apresenta um processo de migração para que a equipe escolha quais configurações serão consolidadas.

Esse é um ponto em que não recomendamos clicar em avançar sem uma auditoria.

Pode existir diferença entre tags relacionada a:

• parâmetros;

• cross-domain;

• configuração de cookies;

• user_id;

• consentimento;

• destinos;

• eventos;

• configurações específicas de Ads ou Analytics.

A consolidação precisa respeitar a arquitetura real da mensuração.

Eventos e triggers existentes são mantidos

O Google informa que o processo de otimização mantém:

• event tags;

• triggers existentes.

Isso reduz o risco de uma migração destrutiva.

Ainda assim, o processo deve ser validado em Preview antes da publicação.

Especialmente em containers antigos, podem existir dependências não documentadas.

Preview continua obrigatório em projetos profissionais

A existência de uma migração guiada não elimina a necessidade de testes.

Antes da publicação, valide:

• page_view;

• eventos personalizados;

• conversões;

• ecommerce;

• Google Ads;

• parâmetros;

• consent mode;

• cross-domain;

• referrals;

• dataLayer;

• triggers;

• duplicidade.

Também recomendamos manter uma referência da versão anterior do container para facilitar rollback.

Rollback continua disponível

Uma das vantagens do GTM é o versionamento.

A documentação oficial informa que, caso necessário, a equipe pode desfazer alterações no workspace ou retornar a uma versão anterior depois da publicação.

Isso reforça a importância de manter uma política de versionamento organizada.

Uma publicação importante deveria sempre possuir uma descrição clara.

Exemplo:

Otimização do container para arquitetura unificada Google tag/GTM

Mudança nos snippets de implementação

Outro ponto relevante é que os novos snippets de implantação serão padronizados.

Segundo o Google, todos os novos snippets passarão a utilizar a mesma estrutura.

Além disso, eles não terão mais o comando:

gtag config

na forma anterior.

Essa mudança merece atenção de desenvolvedores e equipes de analytics que mantêm implementações customizadas.

O novo papel do gtm init

O Google recomenda configurar comportamentos de inicialização através do trigger:

gtm init

Essa é uma mudança conceitual importante.

Em vez de depender do antigo comando de configuração inserido no snippet, comportamentos iniciais passam a ser organizados dentro do fluxo do próprio Tag Manager.

Para implementações legadas, o Google também informa que o init pode ser configurado para aguardar o comando config, caso seja necessário preservar compatibilidade.

Não remova código antigo sem entender a arquitetura

Esse é um ponto que merece cautela.

Ao encontrar uma documentação dizendo que novos snippets não terão mais determinado comando, algumas equipes podem tentar remover configurações manualmente.

Isso pode quebrar implementações existentes.

Antes de alterar código diretamente no site, identifique:

• qual snippet está instalado;

• quais IDs estão sendo utilizados;

• se existe Google tag direta;

• se existe GTM;

• se existem tags duplicadas;

• quais destinos recebem os dados;

• como consent mode está configurado;

• como cross-domain funciona.

Migração de tagging deve começar por inventário.

A nova camada de vínculos entre produtos

Durante a otimização, o container pode ser vinculado diretamente a contas de destino Google.

Isso permite que o Tag Manager apareça e seja gerenciado de forma mais integrada em outros produtos.

O Google informa que esses vínculos são criados automaticamente durante a otimização e recebem acesso de leitura por padrão.

As permissões podem ser alteradas posteriormente.

Isso muda governança e acesso

Esse recurso pode facilitar colaboração entre equipes.

Por exemplo:

Google Ads ↔ Google Tag Manager

Google Analytics ↔ Google Tag Manager

Antes, usuários podiam precisar navegar entre plataformas para entender como a mensuração estava configurada.

A integração facilita visibilidade.

Por outro lado, ela exige governança de permissões.

Permissões não são versionadas

A documentação oficial faz uma observação importante:

permissões não são versionadas junto com o container.

Isso significa que rollback de uma versão não necessariamente desfaz alterações de acesso.

Administradores precisam revisar separadamente:

• usuários;

• permissões;

• External Account Links.

Esse detalhe é especialmente importante em ambientes corporativos.

Visual Tagging: uma das maiores mudanças para usuários menos técnicos

Além da unificação, o Google está expandindo o conceito de Visual Tagging através do Tag Assistant.

A proposta é permitir que o usuário configure eventos e conversões selecionando elementos diretamente no site.

Em vez de configurar manualmente:

• seletor;

• variável;

• trigger;

• tag;

o usuário navega pelo site e aponta visualmente quais informações devem ser utilizadas.

O sistema constrói a configuração técnica em segundo plano.

Visual Tagging ainda está em beta

No momento do anúncio, o recurso está disponível em beta principalmente para conversões de compra no Google Ads.

O Google informa que outros casos de uso serão adicionados progressivamente ao longo do ano.

Portanto, não devemos tratar o Visual Tagging como substituto completo da configuração tradicional do GTM.

Ainda não.

Como funciona o Visual Tagging para compras

A documentação atual apresenta um fluxo guiado para configurar conversões de compra.

O processo envolve:

1. iniciar a solução de problemas de conversão no Google Ads;

2. abrir o fluxo guiado;

3. navegar até o site;

4. realizar uma compra de teste;

5. acessar a página de confirmação;

6. selecionar visualmente os elementos que representam os valores;

7. confirmar;

8. publicar a configuração no GTM.

Quais dados podem ser selecionados

No fluxo atual, o Visual Tagging pode identificar valores como:

• Transaction ID;

• subtotal do pedido;

• moeda;

• nome do cliente;

• e-mail;

• telefone.

Isso demonstra como o Google pretende reduzir a necessidade de configuração manual para cenários comuns de conversão.

O sistema cria tags, triggers e variáveis

Depois da seleção dos elementos, o próprio sistema gera a estrutura necessária no Tag Manager.

Segundo a documentação:

• tags;

• triggers;

• variables;

podem ser configurados automaticamente.

Para empresas sem equipe técnica, isso reduz bastante a barreira de implementação.

Mas Visual Tagging não substitui Data Layer

Esse ponto é importante.

Selecionar elementos visuais pode funcionar bem em implementações simples.

Porém, depender do DOM para mensuração pode ser mais frágil.

Imagine que o desenvolvedor altere:

• classe CSS;

• estrutura HTML;

• template;

• checkout;

• framework;

• elemento visual.

A configuração pode deixar de funcionar.

Em projetos mais robustos, o dataLayer continua sendo uma arquitetura superior para eventos e ecommerce.

DOM scraping versus dataLayer

DOM scraping

O GTM tenta encontrar informações diretamente no HTML.

Vantagens:

• implementação rápida;

• menor dependência inicial de desenvolvimento.

Riscos:

• fragilidade;

• dependência da interface;

• mudanças de layout;

• seletores quebrados.

Data Layer

O sistema envia explicitamente dados estruturados para a camada de mensuração.

Exemplo conceitual:

Evento de compra → transaction_id + value + currency + items

Vantagens:

• maior estabilidade;

• separação entre interface e mensuração;

• dados estruturados;

• melhor governança.

Para projetos profissionais, continuamos recomendando dataLayer sempre que possível.

Visual Tagging pode democratizar o GTM

Mesmo com essas limitações, o recurso é importante.

Ele permite que equipes menores implementem mensuração básica sem escrever JavaScript ou compreender seletores complexos.

Isso pode reduzir problemas comuns como:

• conversões não implementadas;

• ausência de valor;

• transaction_id faltando;

• campanhas sem mensuração adequada.

A ferramenta pode ser excelente para configurações iniciais.

Projetos complexos continuarão exigindo conhecimento técnico.

O risco de duplicidade continua existindo

A própria documentação do Visual Tagging alerta quando encontra uma conversão de compra já existente.

Isso é fundamental.

Uma migração mal feita pode acabar criando:

• purchase antigo;

• purchase novo;

• conversão importada;

• Google Ads tag;

• GA4 importado;

ao mesmo tempo.

O resultado pode ser contagem duplicada.

Antes de publicar uma nova conversão, confirme exatamente quais eventos já estão sendo enviados.

O que muda para quem usa apenas Google tag

Esse grupo talvez seja o mais beneficiado pela unificação.

Sites que utilizam apenas IDs G- ou AW- poderão ganhar acesso a recursos anteriormente associados ao GTM, como:

• debugging;

• versionamento;

• interface;

• configurações orientadas pela UI.

Isso reduz a necessidade de migrar imediatamente para um container GTM- apenas para obter ferramentas básicas de gerenciamento.

O que muda para usuários atuais do GTM

Para quem já possui um container GTM- maduro, a mudança é menos radical.

Os principais benefícios são:

• nova área Settings;

• consolidação das configurações Google;

• data flow map;

• integração entre destinos;

• possível melhoria de performance;

• administração mais centralizada.

Triggers, variáveis, templates e estrutura de eventos continuam existindo.

O que muda para agências e consultorias

A atualização pode simplificar onboarding e diagnóstico.

Em um projeto novo, será mais fácil visualizar:

• destinos;

• configurações;

• relacionamento entre produtos;

• fluxo dos dados.

Isso reduz parte da investigação inicial.

Ao mesmo tempo, migrações de containers existentes podem exigir auditoria antes da consolidação.

O que muda para desenvolvedores

Desenvolvedores precisam ficar atentos principalmente a:

• novo snippet;

• ausência do gtag config nos novos deployments;

• uso do gtm init;

• containers G- e AW-;

• containers GTM-;

• Visual Tagging;

• dataLayer.

Projetos com implementação hardcoded também devem revisar se ainda faz sentido manter a arquitetura atual.

Isso substitui server-side tagging?

Não.

A unificação anunciada é uma mudança na arquitetura de tagging e gerenciamento.

Server-side tagging continua sendo uma camada diferente.

No server-side GTM, dados são enviados primeiro para um servidor de tagging controlado pela empresa antes de seguir para destinos como Google Analytics ou Google Ads.

Isso permite:

• maior controle;

• transformação dos dados;

• redução de exposição no navegador;

• contexto first-party;

• integração com consent mode;

• maior governança.

O Google continua investindo fortemente nessa arquitetura.

Isso substitui Consent Mode?

Também não.

Consent Mode continua sendo a solução para comunicar o estado de consentimento do usuário aos produtos Google.

A nova arquitetura de Tag Manager precisa continuar respeitando:

• analytics_storage;

• ad_storage;

• ad_user_data;

• ad_personalization;

• outros consent types aplicáveis.

A unificação não elimina responsabilidades legais nem a necessidade de CMP quando aplicável.

Google Tag Manager continua exigindo governança

Ferramentas mais fáceis podem criar a impressão de que qualquer usuário pode publicar qualquer mudança.

Isso é perigoso.

Um container GTM pode influenciar:

• Analytics;

• Google Ads;

• Meta;

• CRM;

• conversões;

• consentimento;

• scripts;

• performance;

• segurança.

É recomendável manter papéis separados:

• Read;

• Edit;

• Approve;

• Publish.

Ambientes maiores também devem documentar cada mudança antes da publicação.

Checklist antes de aceitar a otimização

Antes de iniciar o fluxo de migração, recomendamos revisar:

• quais Google tags existem;

• quais IDs estão ativos;

• quais destinos recebem dados;

• se existem tags duplicadas;

• diferenças de configurações;

• consent mode;

• cross-domain;

• user_id;

• ecommerce;

• eventos personalizados;

• conversões;

• parâmetros compartilhados;

• permissões;

• vínculos externos;

• versões recentes do container.

Checklist depois da otimização

Após adicionar as mudanças ao workspace:

• executar Preview;

• testar page_view;

• testar eventos principais;

• validar ecommerce;

• validar purchase;

• validar transaction_id;

• confirmar valores;

• validar Google Ads;

• verificar consentimento;

• verificar cross-domain;

• analisar Network;

• confirmar ausência de duplicidade;

• revisar Tag Assistant.

Somente depois dessa validação a versão deve ser publicada.

Uma oportunidade para limpar containers antigos

A atualização é também uma boa oportunidade para revisar dívida técnica.

Muitos containers acumulam ao longo dos anos:

• tags pausadas;

• pixels antigos;

• variáveis sem uso;

• triggers duplicados;

• Custom HTML obsoleto;

• versões antigas de ferramentas;

• scripts de projetos encerrados.

Antes ou depois da otimização, vale executar uma auditoria completa.

Um container menor e documentado é mais fácil de:

• testar;

• manter;

• auditar;

• proteger.

Performance continua dependendo da arquitetura completa

A melhoria anunciada pelo Google é positiva.

Mas performance precisa ser analisada no contexto completo da página.

Itens relevantes incluem:

• quantidade de tags;

• scripts síncronos;

• scripts de terceiros;

• listeners;

• DOM;

• execução JavaScript;

• consent banner;

• chat;

• ferramentas de heatmap;

• pixels publicitários.

A otimização do Google Tag Manager não substitui análise de performance web.

O que essa mudança sinaliza sobre o futuro do GTM

A direção parece bastante clara.

O Google está tentando reduzir a fragmentação entre:

• Google tag;

• Tag Manager;

• Analytics;

• Google Ads;

• Tag Assistant;

• configuração de conversões.

A tendência é que tarefas comuns sejam cada vez mais:

• visuais;

• guiadas;

• centralizadas;

• integradas entre produtos.

Ao mesmo tempo, recursos avançados continuam disponíveis para implementações mais complexas.

A evolução do GTM é parecida com o que acontece em outras ferramentas

Estamos vendo o mesmo movimento em diversas áreas de tecnologia.

Ferramentas sofisticadas passam a oferecer uma camada visual simples para tarefas comuns, mantendo opções técnicas para casos avançados.

Isso pode ser resumido assim:

Interface visual para casos simples;

Configuração técnica para casos complexos;

No GTM, Visual Tagging representa exatamente essa direção.

O impacto para Web Analytics

Para profissionais de analytics, a mudança reduz parte da complexidade operacional, mas não altera o trabalho estratégico.

Ainda será necessário decidir:

• quais eventos medir;

• quais conversões realmente importam;

• quais parâmetros enviar;

• como nomear eventos;

• como evitar duplicidade;

• como relacionar métricas aos objetivos do negócio.

Configurar ficou potencialmente mais fácil.

Definir o que precisa ser medido continua exigindo conhecimento.

Uma ferramenta mais simples não significa uma estratégia mais simples

Imagine uma empresa configurando visualmente dez cliques diferentes como conversão.

Tecnicamente, a implementação pode estar correta.

Estratégicamente, pode estar completamente errada.

Google Ads começará a otimizar para os eventos configurados.

Se os sinais forem fracos, a automação pode perseguir ações sem valor comercial.

O problema nunca foi apenas disparar uma tag.

O problema é decidir qual comportamento representa sucesso.

Como a Ad Rock enxerga essa atualização

Na Ad Rock, consideramos essa mudança positiva porque reduz fragmentação entre os produtos de tagging do Google.

Os principais ganhos são:

• administração mais centralizada;

• maior clareza sobre destinos;

• possível redução de JavaScript adicional;

• melhor integração entre produtos;

• facilidade para implementações simples;

• melhor debugging para usuários da Google tag.

Ao mesmo tempo, recomendamos cautela em containers existentes.

Não é aconselhável iniciar uma consolidação sem compreender:

• tags atuais;

• eventos;

• triggers;

• consentimento;

• conversões;

• dependências.

Como a Ad Rock pode ajudar

A Ad Rock trabalha com projetos envolvendo:

• Google Tag Manager;

• Google Analytics 4;

• Google Ads;

• Consent Mode;

• ecommerce tracking;

• server-side tagging;

• eventos personalizados;

• conversões;

• dataLayer;

• auditoria de containers;

• debugging;

• arquitetura de mensuração.

Podemos apoiar empresas tanto na avaliação da nova arquitetura quanto na migração e otimização de containers existentes.

O objetivo não é apenas adotar uma novidade do Google.

É garantir que a implementação continue:

• correta;

• estável;

• documentada;

• performática;

• alinhada às decisões de negócio.

Conclusão

A atualização anunciada pelo Google em agosto de 2026 representa uma evolução importante da sua infraestrutura de tagging.

Google tag e Google Tag Manager passam a compartilhar uma arquitetura mais integrada.

Sites que utilizam apenas Google tag ganham acesso a recursos tradicionalmente associados ao GTM.

Usuários do Tag Manager recebem uma interface mais centralizada, melhor integração entre destinos e a possibilidade de enviar dados diretamente aos produtos Google sem carregar uma camada adicional do gtag.js em determinados cenários.

O Visual Tagging reduz ainda mais a barreira de entrada ao permitir configurar conversões diretamente sobre a interface do site.

Mas os fundamentos continuam os mesmos.

Mensuração de qualidade depende de:

• arquitetura;

• eventos bem definidos;

• dados consistentes;

• consentimento;

• validação;

• governança.

A tecnologia está ficando mais simples de operar.

Isso não torna menos importante compreender o que está sendo medido.

Referências oficiais

Google Tag Manager Help: Updates to Google tag and Google Tag Manager

https://support.google.com/tagmanager/answer/17079602

Google Analytics Help: Optimize your Google Tag Manager container

https://support.google.com/analytics/answer/16659369

Google Tag Manager Help: Manage tagging behavior using the container ID

https://support.google.com/tagmanager/answer/17070049

Google Tag Manager Help: Visual tagging in Tag Assistant

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 overview

https://developers.google.com/tag-platform/security/concepts/consent-mode

Google Developers: Implement consent mode with server-side Tag Manager

https://developers.google.com/tag-platform/tag-manager/server-side/consent-mode