Google Analytics 2027 · Capítulo 31 de 35 · 11 min
Enviar do servidor o evento que o navegador não vê, sem duplicar
O Pix confirmado, a venda da loja física e a etapa do lead chegam ao GA4 pelo servidor, uma vez cada, com identificador e data certos.
Este capítulo faz parte do curso gratuito Google Analytics 2027.
Com a conciliação feita, 41 dos 60 pedidos sem par tinham a mesma história: a pessoa gerou o Pix, fechou a aba e pagou pelo aplicativo do banco vinte minutos depois. O navegador nunca voltou à página de confirmação. Para o GA4, aquela sessão terminou num begin_checkout.
O custo é maior do que 22 por cento da receita fora do relatório. As campanhas que trazem quem paga com Pix parecem piores do que são, o lance do Google Ads aprende com a metade errada dos pedidos, e a loja física e as etapas do lead no HubSpot ficam fora de qualquer análise. Tudo isso acontece fora do navegador, e só o servidor sabe.
O capítulo monta a medição pelo servidor da Verde Vivo: escolhe a arquitetura, compara Measurement Protocol e Data Manager API, e envia o purchase do Pix confirmado uma vez, com o identificador que liga o evento à sessão de origem.
Existem três arquiteturas. No navegador, a tag do site envia tudo, e é o que a Verde Vivo tinha. No servidor, o backend envia os eventos diretamente ao GA4, sem tag na página. Na híbrida, o navegador continua enviando o comportamento (página, clique, checkout) e o servidor envia o que só ele conhece (pagamento confirmado, venda offline, etapa de lead). A híbrida é a escolha de quase toda loja, e a regra dela é uma: cada evento tem um único remetente.
GTM server-side (o contêiner do Tag Manager que roda num servidor seu e recebe os hits do navegador antes de repassá-los ao Google) e Google tag gateway (o roteamento das tags do Google pelo seu próprio domínio, via CDN ou balanceador de carga) resolvem problemas diferentes. O primeiro transforma e enriquece o dado antes de enviar. O segundo só muda o caminho: a tag passa a ser servida pelo seu domínio, sem lógica no meio.
Os quatro caminhos do servidor até o GA4
| Caminho | O que faz | Quando usar | O que não faz |
|---|---|---|---|
| GTM server-side | Recebe hits do navegador num servidor seu, transforma e repassa | Enriquecer, filtrar ou esconder parâmetros antes do Google | Não conhece o pagamento confirmado sozinho; precisa do backend |
| Google tag gateway | Serve a tag do Google pelo seu domínio via Cloudflare, Akamai, Fastly, Google Cloud ou CloudFront | Reduzir perda de sinal no navegador | Nenhuma lógica; não envia evento de servidor |
| Measurement Protocol | Requisição HTTP do backend com client_id, eventos e parâmetros | Evento que o navegador não vê; maduro, sem plano de descontinuação | Não valida api_secret; resposta 2xx não prova evento certo |
| Data Manager API | Ingestão server-to-server com modelo unificado entre produtos do Google | Integrações novas; rota recomendada pelo Google desde 07/05/2026 | Eventos do Analytics ainda por allowlist; erro numa linha reprova a requisição |
Fonte: Google for Developers, tag gateway, Measurement Protocol e Data Manager API (setembro de 2026)
O gateway ganhou parceiros ao longo de 2025 e 2026: Cloudflare em 8 de maio de 2025, Akamai em 29 de janeiro de 2026, Fastly em 8 de abril de 2026, Google Cloud com disponibilidade geral em 1 de junho de 2026 e Amazon CloudFront em 3 de junho de 2026. Cloudflare divulgou 11 por cento de aumento em sinais observados e Fastly, 14 por cento. São números de aumento de sinal publicados pelos próprios parceiros, não conversões incrementais auditadas.
Medição pelo servidor: as datas que mudaram o desenho em 2025 e 2026
- 8 de maio de 2025Concluído
Google tag gateway com Cloudflare
Parceiro divulga 11 por cento de aumento em sinais observados, sem auditoria independente
- 29 de janeiro e 8 de abril de 2026Concluído
Akamai e Fastly entram no gateway
Fastly divulga 14 por cento de aumento de sinal, com a mesma ressalva
- 7 de maio de 2026Concluído
Data Manager API v1.6
Qualquer evento com transaction ID para fluxos web e app do Analytics; rota recomendada no lugar do Measurement Protocol
- 1 e 3 de junho de 2026Concluído
Gateway em Google Cloud (GA) e CloudFront
Balanceador de carga do Google Cloud sai do beta de 5 de janeiro; CloudFront via Tag Assistant
- 15 de junho de 2026Concluído
Google Ads API fecha a novos adotantes de conversões offline
Quem começa agora usa a Data Manager API
- 20 de agosto de 2026Concluído
Google tag e GTM se fundem
Upgrade opcional, por convite; envio direto a destinos do Google sem JavaScript extra
Measurement Protocol é a rota que existe há anos e que o Google descreve, em setembro de 2026, como madura e finalizada: continua operacional, sem planos de descontinuação, mas a recomendação para integrações novas é a Data Manager API. Uma requisição leva o measurement_id do fluxo, o api_secret criado em Admin, um client_id, opcionalmente o user_id, e até 25 eventos, cada um com até 25 parâmetros.
O client_id é o que separa uma medição boa de uma inútil. Ele precisa ser o mesmo que o navegador da pessoa usou, lido do cookie da Google tag na hora do pedido e guardado junto do número do pedido. Com o mesmo client_id, o purchase do servidor entra na conta do mesmo usuário e a atribuição encontra a sessão que trouxe a compra. Com um client_id inventado, cada evento vira uma pessoa nova sem origem.
POST https://www.google-analytics.com/mp/collect
?measurement_id=G-XXXXXXX&api_secret=SEGREDO_DO_FLUXO
{
"client_id": "1712345678.1694012345",
"user_id": "cliente_88213",
"timestamp_micros": 1758627600000000,
"events": [{
"name": "purchase",
"params": {
"transaction_id": "VV-48213",
"value": 215.00,
"currency": "BRL",
"payment_type": "pix",
"items": [{ "item_id": "VASO-CER-22", "item_name": "Vaso cerâmica 22 cm",
"price": 89.00, "quantity": 1 }]
}
}]
}O timestamp_micros permite datar o evento no momento real do pagamento, com até 72 horas de atraso. No modo RELAXED o Google ajusta o que passa disso; no ENFORCE_RECOMMENDATIONS, rejeita. Nomes de propriedade de usuário vão até 24 caracteres e valores até 36, com 25 propriedades por requisição. Quem guarda a fila por mais de três dias perde o evento ou o recebe com a data errada.
Validação tem endereço próprio: o endereço /debug/mp/collect no lugar de /mp/collect (região europeia em region1.google-analytics.com) devolve os erros sem gravar nada. Os códigos dizem o que falhou: VALUE_INVALID, VALUE_REQUIRED, NAME_INVALID, NAME_RESERVED, VALUE_OUT_OF_BOUNDS, EXCEEDED_MAX_ENTITIES e NAME_DUPLICATED. O servidor de validação não confere api_secret nem firebase_app_id, e a rota de produção responde 2xx para quase tudo. Uma resposta sem erro prova que a requisição chegou, não que o evento certo foi gravado; a prova fica no DebugView e no tempo real.
Data Manager API é a rota que o Google recomenda para integrações novas desde 7 de maio de 2026, quando a versão 1.6 passou a aceitar qualquer evento com transaction ID para fluxos web e app do Analytics, roteado por Measurement ID ou Firebase App ID. Diferenças em relação ao Measurement Protocol: modelo de dados unificado entre os produtos de anúncios, criptografia, vários destinos por requisição, sem api_secret, e erros em fast-fail, em que uma linha errada reprova a requisição inteira. Eventos reservados voltam com INVALID_EVENT_NAME.
Os limites são maiores: até 2.000 eventos por requisição, 10 identificadores por evento, 10 destinos, 100.000 requisições por dia e 300 por minuto por projeto no serviço de ingestão. O acesso ao recurso de eventos do Analytics é por allowlist, segundo a cobertura de imprensa do lançamento, e é isso que mantém a Verde Vivo no Measurement Protocol por enquanto: a API está em disponibilidade geral, o recurso específico ainda depende de aprovação.
A rota de migração publicada pelo Google tem cinco passos: habilitar a API e as credenciais, instalar a biblioteca, mapear os campos, enviar os eventos e verificar em tempo real, no DebugView ou nos diagnósticos. Quem começa hoje uma integração de conversão offline com o Google Ads já não tem escolha: desde 15 de junho de 2026 a Google Ads API não aceita novos adotantes de importação de conversões offline, e a Data Manager API é o caminho.
Confiabilidade é o que separa o script de teste do sistema de produção. O backend não envia o evento na hora em que o webhook do pagamento chega; ele grava numa fila. Um processo lê a fila, envia, guarda a resposta e marca como enviado. Se a rede falhar, tenta de novo com espera crescente, até o limite das 72 horas. A chave de idempotência (o valor que garante que o mesmo pedido nunca é enviado duas vezes) é o transaction_id.
// Fila de envio: um pedido pago vira no máximo um purchase no GA4
async function processarFila() {
const pendentes = await fila.lerPendentes({ maxIdadeHoras: 72 });
for (const pedido of pendentes) {
if (await enviados.existe(pedido.transactionId)) continue; // idempotência
const resposta = await enviarMeasurementProtocol({
clientId: pedido.clientIdDoCookie, // lido no checkout, nunca inventado
userId: pedido.clienteId,
timestampMicros: pedido.pagoEm * 1_000_000,
evento: montarPurchase(pedido),
});
await registro.gravar(pedido.transactionId, resposta.status);
if (resposta.ok) await enviados.marcar(pedido.transactionId);
else await fila.reagendar(pedido, { esperaCrescente: true });
}
}Privacidade vale também no servidor. Nenhum e-mail, telefone ou documento entra como parâmetro. Dado fornecido pelo usuário para os casos de uso de anúncio segue o fluxo próprio, com hash SHA-256 e consentimento registrado. O backend confere o estado de consentimento que a pessoa deu no site antes de enviar qualquer evento em nome dela, porque o servidor não vê o banner.
Manutenção fecha o desenho. Cada envio fica registrado com número do pedido, hora, resposta e tentativas. Um alerta dispara quando a fila acumula mais de um número combinado de pedidos ou quando a proporção de erros sobe. Uma vez por mês, a conciliação do capítulo anterior confirma que os purchase do servidor batem com os pedidos pagos.
Armadilha comum: manter o purchase do navegador na página de confirmação e acrescentar o purchase do servidor no webhook de pagamento. Quem paga com cartão dispara os dois, e a receita de cartão dobra no relatório. A regra de um remetente por evento vale no dia da migração: no momento em que o servidor passa a enviar purchase, a tag do navegador para de enviá-lo, para todos os meios de pagamento.
Na Verde Vivo, o Caio moveu o purchase inteiro para o servidor. O navegador continua enviando begin_checkout, add_shipping_info e add_payment_info, com o client_id gravado no pedido da Shopify. O webhook de pedido pago cai numa fila, e um processo envia o purchase pelo Measurement Protocol com timestamp_micros da confirmação e transaction_id igual ao número do pedido. Antes de ligar em produção, cada modelo de requisição passou pelo servidor de validação e o resultado foi conferido no DebugView.
O purchase da Verde Vivo antes e depois do servidor
Antes: só o navegador
Antes
- purchase disparado na página de confirmação, na criação do pedido
- Pix e boleto pagos depois da sessão nunca chegavam: 41 pedidos sem par em agosto
- Pedidos criados e não pagos contavam como venda até expirar
- Cobertura de 96 por cento na conciliação, com receita de cartão certa e de Pix errada
- Nenhum registro de envio; erro silencioso
Depois: navegador até o pagamento, servidor no pagamento
Depois
- purchase enviado pelo webhook de pedido pago, uma vez, para todo meio de pagamento
- client_id do cookie guardado no pedido; a sessão de origem continua atribuída
- timestamp_micros da confirmação, dentro das 72 horas
- Cobertura de 99,8 por cento em setembro: 1.647 purchase para 1.650 pedidos pagos
- Fila com idempotência por transaction_id, registro de resposta e alerta de acúmulo
Em setembro, a conciliação encontrou 1.647 purchase para 1.650 pedidos pagos. Os três que faltaram ficaram na fila durante uma queda de rede de quatro dias e passaram das 72 horas; entraram na tabela conciliada por SQL, com a marca de "enviado fora da janela". A leitura de campanha mudou: a mídia que trazia pagador de Pix subiu de posição, e o evento-chave importado no Google Ads passou a incluir esses pedidos.
Escolha o evento que hoje só acontece fora do navegador no seu negócio (pagamento confirmado, venda no balcão, lead qualificado) e escreva, para ele, quem envia, qual é a chave de idempotência e de onde vem o client_id; sem as três respostas, não ligue nenhum envio. O próximo capítulo automatiza a leitura do que chegou, pelas APIs do Analytics.
Antes do purchase do Pix sair do backend, o Caio precisou de duas peças que o capítulo pressupõe: um segredo de API criado no fluxo certo e um contêiner de servidor respondendo no domínio da Verde Vivo. O guia abaixo cobre as duas, na ordem em que ele fez.
Guia prático: criar o api_secret e validar o primeiro evento
Faça primeiro numa propriedade de teste ou com debug_mode ligado. Leva uns 15 minutos.
Passo 1: Crie o segredo no fluxo web
Em Administrador > Coleta e modificação de dados > Fluxos de dados, abra o fluxo web, clique em Chaves secretas da API Measurement Protocol (Measurement Protocol API secrets) e em Criar. Dê um apelido que diga o uso, como backend-pagamentos.
Deu certo quando: O segredo aparece na lista com o apelido e o valor para copiar.
Erro comum: Colar o segredo no JavaScript do site. Ele é privado; exposto, permite que qualquer pessoa envie dados falsos à propriedade.
Passo 2: Guarde o segredo fora do código
Grave o valor no cofre de segredos ou na variável de ambiente do backend, nunca no repositório.
Deu certo quando: O código lê o segredo por variável de ambiente e o repositório não contém o valor.
Passo 3: Capture client_id e session_id no checkout
Leia o client_id do cookie _ga (os dois últimos blocos numéricos) e o session_id do cookie da propriedade, e grave os dois junto do pedido.
Erro comum: Enviar só o client_id: o evento chega, mas a origem aparece como (not set). O session_id do evento do navegador é o que liga o purchase à sessão de origem.
Passo 4: Valide no endpoint de debug
Envie a mesma requisição para https://www.google-analytics.com/debug/mp/collect, o endereço de validação, que não grava nada. Com validation_behavior em ENFORCE_RECOMMENDATIONS durante o desenvolvimento, o servidor aponta também o que foge das recomendações.
Deu certo quando: A resposta volta com validationMessages vazio.
Erro comum: Confiar só nisso: o validador não confere api_secret nem measurement_id, e nada do que ele recebe aparece nos relatórios.
Passo 5: Confirme no DebugView e no Tempo real
Envie para o endpoint de produção com debug_mode true e engagement_time_msec positivo no evento. Abra Administrador > Exibição de dados > DebugView e depois o relatório Tempo real.
Deu certo quando: O purchase aparece no DebugView com transaction_id, value e currency certos, em poucos segundos.
No fim você tem: Um segredo guardado com nome de uso, um modelo de requisição validado e a prova visual de que o evento chegou à sessão certa.
Guia prático: subir o contêiner de servidor com domínio próprio
Serve para quem vai tratar os hits do navegador no servidor. O purchase pelo backend não depende disso.
Passo 1: Crie o contêiner de servidor no GTM
Em Tag Manager, crie um contêiner do tipo Servidor. Escolha provisionar automaticamente no Google Cloud (Cloud Run) ou configurar manualmente, o caminho usado para hospedagens como Stape.
Deu certo quando: O GTM mostra a string de configuração do contêiner, que o servidor usa para se identificar.
Passo 2: Dimensione o servidor de inclusão de tag
O Google recomenda no mínimo 2 instâncias em produção para reduzir o risco de perda de dados em queda, e estima cerca de US$ 45 por mês por instância. O servidor de visualização é separado do servidor que recebe o tráfego real.
Erro comum: Deixar o registro de cada requisição ligado em alto volume: o custo de logs pode passar o custo do próprio servidor.
Passo 3: Aponte um domínio da empresa
Use um subdomínio, como medir.verdevivo.com.br, com o registro de DNS indicado pela hospedagem, ou o mesmo domínio do site com um caminho, como verdevivo.com.br/medir, roteado por CDN ou balanceador de carga.
Deu certo quando: O endereço https do subdomínio responde e o certificado é válido.
Passo 4: Registre a URL no contêiner
No contêiner de servidor, vá em Administrador > Configurações do contêiner e preencha URLs do contêiner do servidor (Server container URLs) com o domínio próprio.
Passo 5: Mande a tag do site para o servidor
No contêiner web, abra a Google tag e defina o parâmetro de configuração server_container_url com o mesmo endereço. Publique só depois de testar no modo de visualização dos dois contêineres.
Deu certo quando: No modo de visualização do contêiner de servidor, as requisições do site aparecem chegando pelo cliente do GA4.
No fim você tem: Um servidor de inclusão de tag com duas instâncias, domínio da empresa e a tag do site entregando os hits a ele.
O que os praticantes repetem sobre servidor e MP
O evento de servidor só vale o que vale o identificador que ele carrega.
- Guarde o client_id no pedido; sem ele, o GA4 cria outra pessoa (Analytics Mania).
- Nunca mande o client_id como dimensão: a cardinalidade estraga relatórios (Analytics Mania).
- Cookie FPID gerenciado pelo servidor é HttpOnly; o backend lê ele, não o _ga (Simo Ahava).
- Mesma origem, como site.com/medir, mantém cookies do servidor com vida longa (Stape).
- Sem session_id, o purchase do servidor aparece como (not set) na origem (ajuda do GA4).
O teste: Pegue um pedido pago de ontem e confira se a origem dele no GA4 não está como (not set).
alexandrecaramaschi.com/educacao/frontends-com-vibecoding
Ao migrar o cliente do GA4 no servidor para o modo Gerenciado pelo servidor (Server Managed), o identificador passa a morar no cookie FPID, que o JavaScript não lê. Se o checkout continuar copiando o client_id do _ga para o pedido, o purchase do backend pode chegar com outro identificador. Mude a leitura do identificador no mesmo dia da migração e teste com um pedido real.
Seu caderno neste capítulo
Abrir o caderno completoSelecione um trecho do capítulo para destacar ou anotar. Nos vídeos e áudios, use Anotar este momento. No teclado, selecione com Shift e as setas e use Alt+Shift+D para destacar ou Alt+Shift+N para anotar.
Salvo neste navegador. Entre na sua conta para levar o caderno a outros aparelhos.
Entre na sua conta para compartilhar o que aprendeu e convidar alguém para estudar com você.
Conexões deste capítulo
Veja o que estudar antes e para onde seguir depois, explore os conceitos e compare abordagens em outros cursos. Sugestões marcadas como “sugerido pelo grafo” vêm dos assuntos em comum, não do índice do curso.
Estude antes
- Cobre no relatório os números certos e ignore o restosugerido pelo grafoApresenta os conceitos “Tagueamento server-side” e “Google Tag Manager”, usados em “Enviar do servidor o evento que o navegador não vê, sem duplicar”.
- CursoPython: Programação do Zerosugerido pelo grafo18 capítulos de “Google Analytics 2027” usam conceitos apresentados em “Python: Programação do Zero”.
- CursoGoogle Ads 2027sugerido pelo grafo4 capítulos de “Google Analytics 2027” usam conceitos apresentados em “Google Ads 2027”.
- CursoLinkedIn Ads 2027sugerido pelo grafo5 capítulos de “Google Analytics 2027” usam conceitos apresentados em “LinkedIn Ads 2027”.
Conceitos deste capítulo
O mesmo assunto em outros cursos
- Google Ads 2027Levar a venda do CRM de volta ao Google Ads pelo Data ManagerExaminar conexões de Levar a venda do CRM de volta ao Google Ads pelo Data Manager
- Analytics de busca para decisão executivaReconhecer quando o dado não merece confiançaExaminar conexões de Reconhecer quando o dado não merece confiança
- Meta Ads 2027Desenhar o plano de mensuração e instalar o Meta Pixel com eventos úteisExaminar conexões de Desenhar o plano de mensuração e instalar o Meta Pixel com eventos úteis
- TikTok Ads e Live Commerce 2027Enviar eventos pelo servidor com a Events API sem contar venda em dobroExaminar conexões de Enviar eventos pelo servidor com a Events API sem contar venda em dobro
Leve uma ideia para a prática
Escolha uma atividade no painel e volte a este curso quando quiser.
Atividades e evolução ficam reunidas no painel da sua conta.