Como o GTM e o gtag usam Service Workers
Giovani Ortolani Barbosa
AutorEm setembro de 2024, o Google introduziu o uso de Service Workers no Google Tag Manager (GTM) para melhorar o desempenho e a confiabilidade das medições:
| “O Google Tag Manager pode usar um service worker para melhorar o desempenho e a confiabilidade das medições. Para garantir que o service worker seja carregado corretamente, consulte as diretrizes da Política de Segurança de Conteúdo.” |
Em Março de 2025, o Google anunciou uma expansão desse recurso:
| “O Google Tag agora usa service workers, quando disponíveis, para enviar dados ao sGTM melhorando o desempenho e a confiabilidade das medições.” |
Este artigo explica como o GTM e o gtag lidam com Service Workers, o que é um Service Worker, como ocorre a comunicação entre eles e por que suas solicitações de análise podem não aparecer na guia Rede das Ferramentas de Desenvolvedor.
O que são Service Workers?
Os Service Workers são scripts em segundo plano que são executados separadamente da thread principal de um site. Eles permitem operações como armazenamento em cache, suporte offline e solicitações de rede em segundo plano, sem bloquear a interface do usuário.
No contexto do GTM e do gtag, os Service Workers são usados para descarregar a tarefa de enviar dados de medição da página da web (por exemplo, GA4 ou hits de anúncios), tornando o rastreamento mais rápido e confiável, mesmo durante eventos de descarregamento da página ou em redes lentas. Observe que, neste contexto, ele não armazena os eventos para serem enviados posteriormente.
Como o GTM e o gtag usam Service Workers
É possível registrar dois tipos de Service Workers, dependendo da sua configuração:
1. Service Worker do seu domínio primário do GTM (sGTM) do lado do servidor
Usado para solicitações GA4 enviadas para contêineres do lado do servidor.
2. Service Worker do domínio googletagmanager.com
Usado principalmente pelos produtos do Google Ads (Google Ads e Floodlight) para solicitações de dados de formulário e dados do usuário.
Ambas as versões seguem um modelo de comunicação semelhante que envolve diversas entidades do navegador.
Fluxo de comunicação
Quando o gtag ou o GTM são executados, eles criam um iframe invisível (src=”about:blank”), que por sua vez carrega outro iframe, sw_iframe.html. Este segundo iframe é responsável por instalar o script do Service Worker (sw.js).
Esses elementos se comunicam por meio da API postMessage() API do navegador (para enviar as informações) e do message listener para recebê-las, formando este fluxo:
gtag/GTM ↔ iframe (about:blank) ↔ iframe (sw_iframe.html) ↔ sw.js (Service Worker)Essa ponte permite que o gtag ou o GTM em execução na página principal passem dados de eventos para o Service Worker, que então decide como e quando enviá-los.
Se você inspecionar a página do site usando a guia Elementos das Ferramentas de Desenvolvedor, poderá ver os iframes.
Demonstração prática das mensagens trocadas entre o iframe e o Service Worker:
- Service Worker do domínio primário do GTM (sGTM) do lado do servidor
- Service Worker do domínio
googletagmanager.com
1. Service Worker carregado do domínio próprio do sGTM
Este Service Worker é usado para requisições GA4 enviadas a um contêiner GTM do lado do servidor.
O script GA4 gtag (G-{Measurement ID} etc.) é responsável por encaminhar os eventos para o Service Worker.
Ele verifica se um evento deve ser enviado pelo Service Worker com base em várias condições:
- O evento não está sendo enviado diretamente para
analytics.google.com/g/collectorwww.google-analytics.com/g/collect(por exemplo, com o parâmetroserver_container_urlconfigurado).
- A página não está sendo descarregada (evento
beforeunload). Durante o descarregamento, requisições como o eventouser_engagementignoram o Service Worker.
- O navegador não é um ambiente restrito (como o WebView, o aplicativo do Google no iOS ou os navegadores integrados aos aplicativos do Facebook e do Messenger).
- Mais especificamente, verifica se o Agente do Usuário do Navegador NÃO contém nenhuma das seguintes strings:
"; wv"OU"FBAN"OU"FBAV"OU (("GSA"OU"GoogleApp") E ("iPhone"OU"iPad"))
- The Service Worker is alive and ready (state
2).- Esta verificação é feita pelo método
.delegate(), que pode ser visto aqui.
Se todas as condições forem cumpridas, o evento é enviado através do Service Worker. Caso contrário, é enviado diretamente utilizando fetch, XHR, sendBeacon, ou Image (por esta ordem) a partir da página principal.
E, se as duas primeiras condições forem cumpridas, o parâmetro richsstsse é adicionado ao URL do evento (saiba mais sobre isso). Este parâmetro permite que o navegador processe a resposta, como enviar pedidos instruídos pelo sGTM para a sincronização de cookies de terceiros.
2. Service Worker carregado do domínio googletagmanager.com
Este Service Worker parece estar relacionado a eventos dos produtos Google Ads e Floodlight.
Algumas solicitações passam por ele, tais como:
- Evento fornecido pelo usuário do Google Ads (solicitações à
https://www.google.com/ccm/form-data/{Conversion ID}/...ehttps://www.google.com/pagead/form-data/{Conversion ID}/...) - Evento de dados do usuário capturado automaticamente (solicitações à apenas
https://www.google.com/ccm/form-data/{Conversion ID}/...).
O script gtag do produto Ads carregado na página (AW-{Conversion ID}, DC-{Floodlight Config ID}, etc.) é responsável por encaminhar os eventos para o Service Worker.
As condições para usar este Service Worker são semelhantes:
- A tag está configurada para enviar dados do usuário e o parâmetro interno
send_user_data_hitinternal parameter is one of the following:user_data_web: usado pelo evento de dados do usuário capturado automaticamenteuser_data_lead: usado pelo evento fornecido pelo usuário do Google Ads
- A página não está carregando (evento
beforeunload).
- O Service Worker está ativo e pronto (estado
2).- Esta verificação é feita pelo método
.delegate(), que pode ser visto aqui.
Caso alguma dessas condições não seja atendida, a solicitação é enviada da página principal normalmente.
O método .delegate
Tanto o gtag quanto o GTM incluem um método chamado .delegate, que realiza a verificação final antes de decidir se o evento será enviado por meio de um Service Worker ou da página principal.
A lógica é simples:
k.delegate = function (a, b, c) {
this.getState() !== 2
? (this.H.C( // Path 1: Not Ready - Sends event from main page.
this.C,
{
state: this.getState(),
hg: this.initTime,
ng: Math.round(Ab()) - this.initTime
},
void 0,
a.commandType
),
c({ // Call the failure callback
failureType: this.C
}))
: this.N.wo(a, b, c); // Path 2: Ready - Sends events from Service Worker.
};
Sempre que o state 2, a solicitação é enviada através do Service Worker. Caso contrário, é enviada pela página principal.
O Service Worker e a página principal trocam mensagens de pulsação a cada X intervalos de tempo (atualmente, 5 segundos) para manter esse state atualizado. A variável de state representa a prontidão do Service Worker:
| State | Significado |
|---|---|
| 0 | estado inicial na inicialização da página |
| 1 | tentando estabelecer comunicação entre a página principal e o Service Worker |
| 2 | O Service Worker está pronto e a conexão com a página principal foi estabelecida com sucesso |
| 3 | tentando novamente após erro |
| 4 | erro fatal / falha / canal de comunicação fechado |
Como verificar se os trabalhadores de serviços estão sendo utilizados
Você pode verificar o uso do Service Worker de diversas maneiras.
1. Aba Rede das Ferramentas de Desenvolvedor
Filtrar solicitações para sw.js ou sw_iframe.html.
Observação:
Service Worker carregado do domínio próprio do sGTM.
Service Worker carregado a partir do domínio googletagmanager.com.
2. Aba Aplicativo das Ferramentas de Desenvolvedor
Abra as Ferramentas de Desenvolvedor → acesse a guia Aplicativo → Service Workers → Clique em “Ver todos os registros” e procure pelo seu domínio.
- Se estiver usando o GA4 para enviar dados para o sGTM: você verá o Service Worker sendo servido a partir do seu domínio próprio do sGTM.
- Se estiver usando algum produto de anúncios do Google: você verá o Service Worker sendo veiculado a partir de googletagmanager.com.
3. Aba Rede das Ferramentas de Desenvolvedor
As solicitações processadas por um Service Worker exibem um ícone de engrenagem ao lado da URL. Isso representa acessos enviados pelo processo em segundo plano, e não pela página principal.
Por que você não vê alguns eventos na aba Rede?
Se os seus eventos do GA4 ou do Google Ads não estiverem aparecendo na guia Rede da página principal, é provável que estejam sendo enviados pelo Service Worker. No entanto, eles ainda serão exibidos na janela do Modo de Visualização do GTM, onde você poderá inspecioná-los.
- Siga os passos descritos aqui.
- Depois de encontrar o Service Worker desejado, clique em “Inspecionar" para abrir sua própria janela do DevTools.
- Acesse a aba Rede, onde suas solicitações de anúncios ou do GA4 que estão faltando aparecerão.
Você poderá ver até dois Service Workers: um para o seu domínio sGTM e outro para o domínio do Google. Cada um deles lida com diferentes tipos de eventos, conforme descrito acima.
Conclusão
A integração gradual do Service Workers no GTM e no gtag pelo Google marca uma mudança para uma forma mais robusta de entrega e gerenciamento de eventos. Ao delegar a entrega de eventos a scripts em segundo plano, o Google melhora o desempenho, a confiabilidade e a precisão da captura de dados, especialmente em casos extremos, como rejeições rápidas ou conexões instáveis, mas isso também significa que algumas solicitações não aparecerão na guia Rede tradicional.
Para especialistas em análise digital, isso significa:
- Não assuma que a ausência de resultados na aba Rede indique problemas de rastreamento.
- Verifique a atividade do Service Worker antes de solucionar problemas.
À medida que esse recurso continua a evoluir, manter-se ciente de como o gtag e o GTM utilizam os Service Workers será crucial para uma depuração precisa e para a confiabilidade dos dados.
Comentários