Enviar do servidor o evento que o navegador não vê, sem duplicar

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.

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.

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.

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 mesmo caminho com o prefixo _debug_ (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.

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.

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.