Medição › Medição

O dataLayer da loja

Este guia é para a agência e para quem configura o Google Tag Manager de uma loja na Denaryx. Toda página da vitrine tem um dataLayer com os eventos de comércio eletrônico no formato do Google Analytics 4, desde a abertura da página e antes do aviso de cookies. Aqui estão onde ele existe, os eventos e os campos de cada um, a ordem do consentimento, o que roda no checkout e como testar.

Os nomes e os campos abaixo são os que a plataforma envia hoje. Um campo que não aparece aqui não existe no dataLayer.

Onde o dataLayer existe

• Em toda página da vitrine: a página inicial, o produto, as listas (categoria, marca e todos os produtos), a busca, o carrinho e as páginas institucionais, em qualquer tema, também no tema próprio da agência. O window.dataLayer existe mesmo na loja sem nenhuma ferramenta ligada e sem aviso de cookies.
• Fora dele: a prévia do editor de temas e a página de envio da receita (ótica) não medem e ficam sem dataLayer.
• O checkout não tem dataLayer. Ele fica em outro endereço (checkout.denaryx.com), sem script de terceiros, e a área do cliente também. A compra chega ao Tag Manager por um contêiner isolado, o Tag Manager no checkout.

O dataLayer é um array na página. Nada sai dela por ele: o que manda dados para fora (o Tag Manager, o Google Analytics, os pixels) espera o aceite do comprador no aviso de cookies.

O formato

Os eventos seguem o formato de comércio eletrônico do GA4. Antes de cada evento entra um { ecommerce: null }, que limpa o anterior, e depois o evento:

{ ecommerce: null }
{
  event: 'view_item',
  event_id: '8d0f7b8e-3a51-4c1e-9b0e-2f6f1d4c7a10',
  ecommerce: {
    currency: 'BRL',
    value: 349.9,
    items: [
      {
        item_id: '5b7c2a90-1f3e-4d8a-a6c4-9e0d3b2f1a77',
        item_name: 'Armação Aurora',
        item_brand: 'OrBlack',
        item_variant: 'Preto / 52',
        item_category: 'Óculos',
        item_category2: 'Armações de grau',
        price: 349.9,
        quantity: 1,
      },
    ],
  },
}

• event_id é aleatório em cada evento. Na compra (purchase), é o id do pedido. As ferramentas usam o event_id para descartar o mesmo evento quando ele chega duas vezes (pelo navegador e pelo servidor).
• currency é sempre BRL, e os valores vão em reais, como número (349.9).
• O item é a variante. O item_id é o id da variante, o mesmo do feed do Google Shopping: o remarketing casa com o catálogo pelo mesmo id.
• item_brand e item_variant só vão quando existem. A variante é a combinação das opções ("Preto / 52"); o produto sem opções vai sem ela.
• A categoria é o caminho da categoria principal do produto, em até cinco níveis: item_category, item_category2 até item_category5.
• O page_view e o search não têm itens e vão sem o objeto ecommerce: os campos ficam no próprio evento.

Além dos eventos, o array tem os comandos do Consent Mode (gtag('consent', ...)). No console, eles aparecem como Arguments, e não como objetos (ver Como testar).

Os eventos da vitrine

Os detalhes de cada um:

• As listas. O item_list_id da categoria é o id dela; o da marca, marca: e o endereço da marca (marca:orblack); o de todos os produtos, todos. O item_list_name é o nome que o comprador vê. Cada produto da lista vai pela primeira variante disponível, a que o cartão mostra.
• O select_item sai no clique (e no clique com o botão do meio) num link para um produto das listas que a página conhece: a categoria, a marca, todos os produtos, o resultado da busca (item_list_id busca, "Resultado da busca") e as sugestões da busca enquanto o comprador digita (busca-preditiva, "Sugestões da busca"). O tema não precisa de JavaScript nem de marcação nos cartões: vale o link /produtos/<endereço>. O index é a posição na página da lista, a partir de 0, e recomeça em cada página. As seções de produtos da página inicial, as sugestões do carrinho e os relacionados do produto ainda não geram o select_item; o "Ver esta armação" do provador virtual gera (ver "Os eventos do provador virtual").
• O carrinho. A plataforma compara o carrinho de antes com o de depois e manda um evento por variante que mudou, com a diferença na quantity. Vale para o carrinho mudado pelas rotas em JSON do tema (/cart/add.js e as outras) e pelos formulários sem JavaScript. Num item composto (a armação com a lente e os tratamentos), cada parte vai como um item, com a quantidade da armação.
• O begin_checkout da vitrine só sai quando o comprador já aceitou no aviso de cookies e há uma ferramenta ou um pixel liberado ouvindo: nesse caso, o clique espera um instante para os envios saírem. Sem isso, o clique segue direto para o checkout, sem o evento. O checkout tem o seu próprio begin_checkout, ao abrir, no contêiner do checkout (próxima seção).

Um exemplo do select_item:

{ ecommerce: null }
{
  event: 'select_item',
  event_id: 'c3a1d9f2-6b4e-4f0a-8d2c-71e5b0a9f364',
  ecommerce: {
    item_list_id: 'todos',
    item_list_name: 'Todos os produtos',
    items: [
      {
        item_id: '5b7c2a90-1f3e-4d8a-a6c4-9e0d3b2f1a77',
        item_name: 'Armação Aurora',
        item_brand: 'OrBlack',
        item_variant: 'Preto / 52',
        item_category: 'Óculos',
        item_category2: 'Armações de grau',
        price: 349.9,
        quantity: 1,
        index: 3,
      },
    ],
  },
}

E o page_view, sem ecommerce:

{ ecommerce: null }
{
  event: 'page_view',
  event_id: '0e9b6c47-2d8f-4a1b-b3e5-5c4f7a2d1e08',
  page_location: 'https://orblank.denaryx.store/produtos/armacao-aurora',
  page_title: 'Armação Aurora | OrBlack',
  page_referrer: 'https://www.google.com/',
}

Os eventos que o tema publica para os pixels personalizados (Denaryx.analytics.publish) não entram no dataLayer.

Os eventos do provador virtual

Na página da armação com o provador virtual de óculos (a loja ligou o provador, e a armação tem o arquivo dele), a janela "Experimente no rosto" gera três eventos:

• O item é a variante que está no provador: a escolhida na página quando a janela abre, ou a cor trocada dentro da janela. Com outra armação no rosto (a troca de modelo), os três continuam levando a variante da armação da página. Os campos do item são os mesmos dos outros eventos, sem index.
• A troca de modelo: experimentar outra armação dentro da janela não gera evento. O clique em "Ver esta armação" gera o select_item da lista "Provador virtual" (item_list_id provador), com a variante experimentada e o index dela entre as outras armações da janela, a partir de 0. A página da outra armação abre com a janela e gera o try_on_opened dela.
• O try_on_mode fica no próprio evento, fora do ecommerce: no Tag Manager, a variável da camada de dados try_on_mode o lê. Cada troca entre a câmera e uma foto (e cada foto nova) gera um evento.
• Nada do rosto vai ao dataLayer: nem a imagem, nem as medidas, nem a DP que o comprador digita, nem o resultado de "serve no seu rosto". A imagem e as medidas não saem do aparelho.
• Sem currency e sem value: experimentar não é uma etapa da compra com valor. Para o GA4, os três são eventos personalizados com itens; para contá-los como conversão secundária, marque o evento no GA4 ou crie a tag no Tag Manager com um gatilho de evento personalizado com o nome dele.
• Num tema próprio, os eventos saem quando a janela é a do snippet kit-provador e o script kit-provador.js do kit, sem mudança. O script avisa a plataforma com o evento denaryx:provador no document; quem escreve o próprio provador pode disparar o mesmo aviso, com detail: { evento: 'try_on_opened', variante: '<id da variante>' } (e modo: 'camera' ou 'photo' no try_on_mode), ou detail: { evento: 'product_clicked', variante: '<id da variante>' } no clique numa das armações de product.try_on.similar. Outros nomes e campos são ignorados.

Um exemplo do try_on_mode:

{ ecommerce: null }
{
  event: 'try_on_mode',
  event_id: '6f1e2d3c-4b5a-4987-a6b5-c4d3e2f1a0b9',
  try_on_mode: 'camera',
  ecommerce: {
    items: [
      {
        item_id: '5b7c2a90-1f3e-4d8a-a6c4-9e0d3b2f1a77',
        item_name: 'Armação Aurora',
        item_brand: 'OrBlack',
        item_variant: 'Preto / 52',
        item_category: 'Óculos',
        item_category2: 'Armações de grau',
        price: 349.9,
        quantity: 1,
      },
    ],
  },
}

Os eventos do checkout

No checkout, os eventos entram no dataLayer do contêiner isolado do Tag Manager no checkout, e só nele:

• value é o valor dos produtos com os descontos (o cupom e o desconto do Pix), sem o frete: a mesma conta da compra pelo servidor. O frete vai à parte, no shipping do purchase. Não há tax: o preço no Brasil já inclui os impostos.
• coupon só vai quando o comprador usou um cupom.
• shipping_tier é o nome que o comprador viu: a transportadora e o serviço ("Correios PAC"), o ponto de retirada ("Retirada: Loja Centro") ou "A combinar".
• O purchase sai quando o comprador chega à página do pedido vindo do checkout, na mesma aba. A página aberta de novo (pelo e-mail, ou recarregada) não repete a compra. O event_id dele é o id do pedido, o mesmo que a compra pelo servidor manda à Meta e ao TikTok, e o transaction_id é o mesmo do Measurement Protocol do GA4.
• Sem dados pessoais. O dataLayer do checkout nunca leva o e-mail, o telefone, o nome, o CPF nem o endereço do comprador, mesmo com o aceite do Marketing: tudo o que entra nele vai a qualquer tag do contêiner. O contato vai às ferramentas pelo servidor, cifrado em SHA-256.

Um exemplo do purchase, com um produto de R$ 49,90 e R$ 10,00 de frete:

{ ecommerce: null }
{
  event: 'purchase',
  event_id: 'a4f2c0d1-7e3b-4b9a-9c5d-1e8f6a2b3c47',
  ecommerce: {
    transaction_id: '1027',
    currency: 'BRL',
    value: 49.9,
    shipping: 10,
    items: [
      {
        item_id: '9e2d4c1b-0a7f-4e3d-8b6c-5f1a2e9d0c38',
        item_name: 'Camiseta',
        item_variant: 'M',
        price: 49.9,
        quantity: 1,
      },
    ],
  },
}

Consentimento

A loja pede o consentimento do comprador quando tem alguma ferramenta ou pixel ligado. O aviso de cookies tem duas categorias:

• Análise libera o Google Analytics: no Consent Mode, analytics_storage.
• Marketing libera os pixels de anúncio e os sinais de anúncio do Google: ad_storage, ad_user_data e ad_personalization.

A ordem no dataLayer

O dataLayer começa com o Consent Mode negado, sempre:

gtag('consent', 'default', {
  analytics_storage: 'denied',
  ad_storage: 'denied',
  ad_user_data: 'denied',
  ad_personalization: 'denied',
});

Depois vem a escolha do comprador, quando existe (gtag('consent', 'update', ...) e o evento denaryx_consent), e depois os eventos da página. Na página em que o comprador escolhe no aviso, a escolha entra logo depois do consent default, à frente dos eventos que já estavam no array: assim, o Tag Manager processa a página vista daquela página (com a origem da visita) já com o consentimento dado.

Na página em que o comprador aceita no aviso, o Tag Manager encontra:

['consent', 'default', { analytics_storage: 'denied', ... }]
['consent', 'update', { analytics_storage: 'granted', ad_storage: 'granted', ... }]
{ event: 'page_view', ... }
{ event: 'view_item_list', ... }
{ event: 'denaryx_consent', consent_analytics: 'granted', consent_marketing: 'granted', consent_source: 'banner' }
{ event: 'gtm.js', 'gtm.start': 1760140800000 }

Nas páginas seguintes, com a escolha guardada:

['consent', 'default', { ... }]
['consent', 'update', { ... }]
{ event: 'denaryx_consent', consent_analytics: 'granted', consent_marketing: 'granted', consent_source: 'stored' }
{ event: 'gtm.js', 'gtm.start': 1760140805000 }
{ event: 'page_view', ... }
{ event: 'view_item_list', ... }

(Cada evento vem depois do seu { ecommerce: null }, omitido aqui.)

O evento denaryx_consent

Sem escolha, ele não sai. Para montar gatilhos com ele no Tag Manager:

1. Crie as variáveis da camada de dados consent_analytics, consent_marketing e consent_source.
2. Crie um gatilho de evento personalizado denaryx_consent, com a condição consent_marketing igual a granted (ou consent_analytics, para uma tag de análise).
3. Para contar só a escolha nova, e não a mesma escolha a cada página, acrescente consent_source igual a banner.

As tags do Google respeitam o Consent Mode sozinhas. As tags de outras ferramentas precisam da verificação de consentimento do Tag Manager (nas configurações avançadas da tag) ou de um gatilho como o acima.

Quando o Tag Manager carrega

• Na loja, o contêiner salvo em Painel › Medição › Ferramentas carrega só depois do aceite, de qualquer uma das duas categorias. Quando carrega, processa o array inteiro: recebe os eventos da página de antes do aceite.
• Quem retira uma permissão no link "Preferências de cookies" fica sem os cookies das ferramentas (_ga, _gcl_*, _fbp, _ttp e os outros), e a página recarrega sem os scripts delas.
• No checkout, o contêiner carrega com o aceite da categoria do pixel dele (o Marketing, por padrão). A escolha é a que o comprador fez na loja e vem com o carrinho: quem não escolheu nada na loja não carrega o contêiner no checkout.

Quem salva os IDs e os pixels é o dono ou o gerente da loja, em Painel › Medição.

Nativo, pixel personalizado e Tag Manager no checkout

A loja tem quatro caminhos de medição, e cada um roda num lugar:

O Tag Manager no checkout

É um pixel pronto, em Painel › Medição › Pixels personalizados › "Tag Manager no checkout": o lojista informa só o contêiner (GTM-...), e a plataforma escreve o código. O contêiner roda numa página isolada (um iframe com sandbox, de origem opaca), com o mesmo dataLayer da vitrine: o Consent Mode negado, a escolha do comprador (denaryx_consent com consent_source: stored), o gtm.js e os eventos do checkout. Na loja, quem roda é o contêiner de Ferramentas.

Os limites do isolamento:

• Sem cookies e sem armazenamento da página. Uma tag que depende de cookie (o _ga, o clique do anúncio) não acha nada lá dentro e cria um visitante novo.
• Sem acesso à página do checkout: o contêiner não lê o DOM, o que o comprador digita nem o endereço do checkout. As variáveis de página do Tag Manager (Page URL, Page Hostname, Page Path) mostram o endereço da página isolada, https://checkout.denaryx.com/<loja>/pixels/<id>.
• Pode carregar scripts e mandar dados para outros endereços, que é o trabalho das tags.

O painel recomenda o mesmo contêiner na loja e no checkout. Nesse caso, separe as tags pelo endereço: a variável Page Hostname é checkout.denaryx.com dentro do checkout e o endereço da loja fora dele. As tags que não servem no checkout (as do GA4 e a de conversão do Google Ads) levam a condição "Page Hostname diferente de checkout.denaryx.com", e as que só servem nele, "igual". O mesmo vale para o begin_checkout, que sai nos dois: escolha qual dos dois cada tag usa.

Qual compra usar em cada ferramenta

A mesma compra pode chegar por mais de um caminho. Para não contar duas vezes:

• Os ids que ligam as duas compras: o transaction_id é o número do pedido, o mesmo do Measurement Protocol; o event_id é o id do pedido, o mesmo event_id da API de Conversões da Meta e da Events API do TikTok.
• Quando conta: o purchase do contêiner sai com o pedido feito. A do servidor sai, por padrão, com o pagamento aprovado (o ajuste "Quando a compra conta", em Painel › Medição › Compra pelo servidor). O Pix e o boleto não pagos contam no contêiner e não no servidor.
• Um caminho por ferramenta na loja também. O GA4 ligado em Ferramentas e uma tag do GA4 no contêiner da loja contam cada evento duas vezes; o mesmo vale para a Meta e o TikTok. Use as Ferramentas ou o contêiner, não os dois.
• Na tag do Google no contêiner da loja, desligue o envio automático da página vista e use o evento page_view do dataLayer, que sai uma vez por página. Com os dois, a página vista conta em dobro.

Ainda não existem: o reembolso (refund), o user_data para as conversões otimizadas do Google Ads e o gclid na compra pelo servidor.

Como testar

No console

Abra uma página da loja, as ferramentas do desenvolvedor (F12) e o console:

window.dataLayer;

O array aparece mesmo sem nenhuma ferramenta ligada e antes de qualquer escolha no aviso. Os comandos do Consent Mode aparecem como Arguments; para ler tudo como listas:

window.dataLayer.map((e) =>
  Object.prototype.toString.call(e) === '[object Arguments]'
    ? Array.from(e)
    : e,
);

Para ver o select_item, abra um produto de uma lista em outra aba, com o botão do meio (ele também conta), e rode de novo na página da lista: o último evento é o select_item. No clique comum, a página troca e leva o array junto.

No modo de visualização do Tag Manager

O modo de visualização (Tag Assistant) funciona na loja como em qualquer site: informe o endereço da loja. Lembre que o contêiner só carrega depois do aceite no aviso de cookies: aceite na janela que o Tag Assistant abre. Os eventos de antes do aceite aparecem na sequência, porque o contêiner processa o array inteiro ao carregar.

O modo de visualização não alcança o contêiner do checkout: ele roda numa página isolada, sem cookies, e o Tag Assistant não se conecta a ela. Para conferir o checkout:

• no console do checkout, troque o contexto (o seletor "top" do Chrome) para o frame da página do pixel (/<loja>/pixels/<id>) e leia o window.dataLayer dele;
• na aba Rede, filtre pelos endereços das suas tags e confira as requisições que saem a cada etapa;
• na loja, o mesmo contêiner, com os mesmos eventos de comércio eletrônico, pode ser conferido no modo de visualização.

No DebugView do GA4

Com o modo de visualização do Tag Manager aberto (ou com o debug_mode na tag), os eventos da loja aparecem no DebugView (Administrador › Exibição de dados › DebugView). A compra pelo servidor não passa pelo navegador e não aparece no DebugView: confira-a nos relatórios do GA4, em que ela entra com o número do pedido como transaction_id.

O código de teste de eventos da Meta e do TikTok para a compra pelo servidor ainda não existe no painel.

A prévia nas redes (og:image)

Toda página da loja tem og:image: as fotos do produto, o logo da marca na página dela, a imagem de compartilhamento da loja (Painel › Buscadores › Prévia nas redes sociais), o logo do tema e, sem nenhum deles, uma imagem gerada com o nome e o endereço da loja. Para ver a prévia como o Facebook e o WhatsApp veem, cole o endereço no Depurador de compartilhamento do Facebook. Depois de trocar a imagem, use "Extrair novamente": o Facebook guarda a prévia anterior até lá.