Blog
Todos os eventos do GA4 que o seu contentor de servidor vê, e de onde vem cada um
Publicado · 5 min de leitura
Encaminhar o GA4 através de um contentor de servidor não muda que eventos existem. O que muda é que finalmente vê quais chegam: a página do contentor conta cada nome de evento que reencaminha. Essa lista surpreende nos dois sentidos: aparecem eventos que ninguém configurou e faltam eventos que se esperavam. Ambas as coisas têm explicações simples assim que se sabe de onde vem cada evento.
Quatro eventos que a etiqueta do Google envia em qualquer propriedade
No momento em que a etiqueta do Google carrega com o seu ID de medição, quatro eventos fluem sem qualquer definição por trás. Nada no Analytics os desliga, e nada no seu contentor precisa de os pedir.
- page_view — um por carregamento de página, ou por mudança de rota numa aplicação de página única quando a opção «alterações de página» do fluxo está ativa.
- session_start — o primeiro hit de uma nova sessão. Uma sessão termina após trinta minutos de inatividade, por isso um visitante que regressa duas horas depois inicia outra.
- first_visit — uma vez por navegador, na primeira sessão que o GA4 alguma vez viu dele. Limpar os cookies produz outro.
- user_engagement — enviado quando a página esteve em primeiro plano durante dez segundos, ou quando o visitante sai depois de interagir. É daqui que vem o tempo de interação do GA4.
Se vê page_view e mais nada, a etiqueta está a funcionar. Não é uma falha; é um site em que ainda ninguém chegou ao fundo da página.
Nove eventos da medição avançada — e o interruptor que decide se recebe algum
A medição avançada do GA4 recolhe mais nove eventos no navegador, sem etiqueta para nenhum deles. Configuram-se no fluxo de dados, não no Tag Manager, e é por isso que um contentor de servidor os reencaminha sem saber que existem.
Cada um tem uma condição mais estrita do que o nome sugere.
- scroll — uma vez por página, e só quando 90 % da altura da página esteve visível. Não em qualquer deslocamento: ao chegar ao fundo. Uma página mais curta do que a janela nunca o dispara.
- click — um clique de saída, para um domínio diferente do atual. Os links internos não contam. O evento chama-se click, com um parâmetro outbound; não existe outbound_click.
- view_search_results — um carregamento de página cujo URL tem um parâmetro de pesquisa (q, s, search, query ou keyword por predefinição).
- file_download — um clique num link que termina numa extensão de documento, arquivo, áudio, vídeo ou folha de cálculo.
- form_start e form_submit — a primeira interação com um formulário na página, e a sua submissão.
- video_start, video_progress e video_complete — apenas para players do YouTube incorporados, e apenas quando a incorporação tem a API JS ativada.
E aqui está a parte que custa semanas. Cada um desses nove depende do interruptor principal da medição avançada do fluxo, e um fluxo criado através da API de administração do Analytics — em vez de na interface do Analytics — tem esse interruptor DESLIGADO. Leia as definições pela API e cada opção individual devolve true; o interruptor principal simplesmente não aparece na resposta, porque é false e a API omite booleanos falsos. A configuração parece totalmente ativada e entrega apenas page_view.
Encontrámos isto na nossa própria propriedade. A SignalHost liga o interruptor principal quando cria uma propriedade por si; se a sua foi criada de outra forma e o scroll nunca chega, abra o fluxo de dados no Analytics e verifique a «Medição avançada» em si, não as opções por baixo.
Sete eventos de comércio eletrónico, só se o seu site os enviar
Os eventos de comércio — view_item_list, view_item, add_to_cart, remove_from_cart, begin_checkout, add_payment_info e purchase — são os que realmente interessam a uma loja, e os únicos nesta página que nada envia automaticamente. O GA4 define os nomes e a forma; o seu site tem de enviar cada um para o dataLayer, exatamente com esse nome, com um objeto ecommerce anexado.
Um tema padrão do Shopify não o faz. O núcleo do WooCommerce não o faz. Uma aplicação ou plugin de dataLayer fá-lo, e no Shopify os eventos do checkout precisam de um Custom Pixel, porque o contentor do tema nunca carrega nas páginas de pagamento. Quando escolhe uma plataforma de loja no assistente da SignalHost, instalamos um acionador e uma etiqueta de evento do GA4 para cada um dos sete, de modo que, no momento em que o seu site envia purchase, o evento é reencaminhado — mas o envio tem de ser organizado por si. O artigo seguinte explica exatamente o que instalar.
O que a página do contentor conta
Cada pedido de medição que passa pelo seu contentor é contado por nome de evento, por dia, durante 400 dias. Só o nome é guardado — nem o URL, nem o ID de cliente, nem um único parâmetro — e é isso que torna seguro guardá-lo tanto tempo. A lista é o que chegou ao seu nome de anfitrião, por isso responde a uma pergunta a que o próprio Analytics não consegue responder: o navegador enviou-o sequer?
Espere contagens desiguais. Cada carregamento de página é um page_view; só os carregamentos que chegam ao fundo são um scroll; só as sessões que passam dos dez segundos são um user_engagement. Um site com dez visualizações de página e dois scrolls é um site normal.
Quando falta um evento
Dois casos, e a página do contentor distingue-os.
Se o evento não está na lista do contentor, o seu site nunca o enviou. O contentor não pode reencaminhar o que não chegou. Para um evento padrão, verifique o interruptor da medição avançada do fluxo; para um evento de comércio, verifique que o envio para o dataLayer acontece, com o nome certo, na página onde deve.
Se o evento está na lista do contentor mas não no Analytics, chegou e foi reencaminhado, e o problema está do lado do Google: o ID de medição errado, um filtro de dados, uma propriedade numa conta diferente daquela para que está a olhar, ou simplesmente o atraso dos relatórios — o tempo real mostra-o em segundos, os relatórios padrão podem demorar um dia.
