O gerador de container do Google Tag Manager (GTM) monta automaticamente um container pronto para importar no GTM do seu site, com as tags que enviam os eventos do site para a Context Cloud. Ele faz a ponte entre o que o site já envia e o que a plataforma espera receber:
- lê o site e o container GTM que já está publicado nele;
- identifica os eventos e campos que o site empurra para o
dataLayer; - cruza esses dados com a Estrutura de dados do app (aba Eventos);
- gera as tags, gatilhos e variáveis do GTM que enviam esses eventos para a Context Cloud.
O recurso fica em Configurações > Estrutura de dados > Google Tag Manager.
Resultado: em vez de criar tag por tag no GTM, você importa um arquivo e publica. O que o gerador não conseguir resolver sozinho aparece na aba Revisão para você completar.
Pré-requisitos
| Pré-requisito | Por que é necessário |
|---|---|
| URL do site cadastrada em Configurações > Plataformas > Web Push | O gerador usa essa URL para acessar o site e ler o container GTM publicado |
| Eventos configurados em Estrutura de dados > Eventos | São os eventos de destino do mapeamento. Evento que não está na estrutura não é gerado |
GTM instalado no site, enviando eventos para o dataLayer | É o que o gerador lê. Se o site não carrega nenhum container, a geração termina com erro |
Quanto mais próximo do padrão de e-commerce do GA4 (view_item, add_to_cart, purchase etc.) o dataLayer do site estiver, mais campos o gerador resolve sozinho.
O que o gerador produz
Cada execução cria uma versão do container, com:
| Elemento | Conteúdo |
|---|---|
| Métricas | Eventos mapeados, Campos mapeados e Campos para revisão |
| Mapeamento | De-para entre os eventos do dataLayer e os eventos da Context Cloud, com a origem de cada campo |
| Revisão | Campos e eventos que o gerador não resolveu sozinho, com o motivo |
| Sugestões | Novos campos de evento sugeridos a partir do que o site já envia |
| JSON do GTM | Arquivo de exportação do GTM, pronto para importar |
O container gerado fica na pasta Inngage do GTM e tem três tipos de item:
- Tag de carregamento do SDK (
Inngage - 0 · Carregar SDK): dispara em todas as páginas, uma vez por carregamento. - Uma tag por evento (ex.:
Inngage - add_to_cart): envia o evento e seus campos para a Context Cloud. - Gatilhos e variáveis: leem o
dataLayer, a URL da página e, em lojas VTEX, oorderFormdo checkout.
Como o mapeamento decide de onde vem cada dado
Para cada evento da Estrutura de dados, o gerador define:
| Regra | Exemplo |
|---|---|
| Gatilho no dataLayer: o evento do site que dispara o evento Inngage | add_to_cart do site → add_to_cart Inngage; orderPlaced do site → purchase Inngage |
| Gatilho por rota: mudança de URL do checkout, quando o site não empurra o evento | #/shipping → add_shipping_info; #/payment → add_payment_info |
| Fontes de cada campo, em ordem de prioridade | currency vem de ecommerce.currency; se ausente, do orderForm da VTEX; se ausente, BRL |
| Transformações | Lista de produtos reduzida a nomes únicos, até 20 itens |
| Frequência: evita disparo duplicado | Uma vez por página; purchase uma vez por sessão por transactionId |
| Condições: restringe onde a tag dispara | view_cart só na URL do carrinho, não no minicart |
O gerador reconhece apelidos comuns de eventos e campos (ex.: orderPlaced para purchase, sign_in para login, subcategoria para item_category_2), ignorando diferenças de caixa, pontuação e underscore. Quando não encontra correspondência, o evento vai para Revisão.
Dois cuidados que o gerador aplica para não enviar evento falso:
- Um campo que sempre resolve (como a URL da página) não prova que o evento aconteceu. Um
view_itemcom odataLayervazio não é enviado só com a URL. category_viewsó é enviado quando o nome da lista de produtos corresponde à categoria dos itens; vitrines genéricas (home) não geram o evento.
Ciclo de vida de uma versão
| Status | Significado |
|---|---|
| Gerada | Versão criada pelo gerador, ainda não entregue |
| Entregue | JSON baixado para importação no GTM |
| Ativa | Versão em uso no site |
| Descartado | Versão abandonada |
O status é um controle de acompanhamento: mudá-lo na plataforma não altera nada no site. O topo da aba indica a versão em uso (ex.: "Nenhuma versão em uso no site."), e cada nova geração cria uma versão no Histórico de versões. Gerar novamente refaz a geração mantendo os Overrides (decisões manuais de mapeamento).
Se o site não carregar nenhum container do Tag Manager, a versão termina com erro e a mensagem indica a causa.
