Server-side e Measurement Protocol: medir pagamentos fora do site

Em maio de 2026, a Verde Vivo comparou os pedidos pagos da loja com as compras registradas no Analytics, só entre clientes que tinham aceitado a medição, e a conta não fechava. A tag do navegador registrava a compra no clique de finalizar o pedido, pago ou não. Pix expirado e boleto vencido entravam como venda, e o Pix pago vinte minutos depois, pelo aplicativo do banco, ficava com a data e o valor do clique, sem nenhuma confirmação de que o dinheiro entrou.

O prejuízo vai além do relatório incompleto. As campanhas que trazem quem paga com Pix parecem piores do que são, o lance automático do Google Ads aprende com uma parte dos pedidos e a venda da loja física e as etapas do lead no CRM ficam fora de qualquer análise. Esses fatos acontecem no servidor da empresa, e só ele pode contá-los ao Analytics.

Cada evento tem um único remetente

Há três arranjos possíveis. No navegador, a tag do site envia tudo, como a Verde Vivo fazia. No servidor, o sistema da empresa envia os eventos direto ao Analytics. No arranjo misto, o navegador continua enviando o comportamento (páginas, cliques, checkout) e o servidor envia o que só ele sabe (pagamento confirmado, venda offline, mudança de etapa do lead). O misto é o caminho da maioria das lojas, com uma regra: cada evento sai de um lugar só.

Dois nomes costumam confundir a conversa. O Tag Manager de servidor é um contêiner de tags que roda num servidor da empresa e recebe o que o navegador manda antes de repassar ao Google; ele trata e filtra dados. O envio direto do sistema da loja ao Analytics é outra coisa, e não depende do primeiro. Para o Pix confirmado, o que importa é o envio direto, feito pelo Measurement Protocol ou pela Data Manager API.

O Measurement Protocol continua, e a recomendação para o futuro mudou

O Measurement Protocol é a forma antiga e estável de um servidor enviar eventos ao Analytics por uma requisição na internet. A página oficial, atualizada em 22 de outubro de 2026, diz que ele chegou a um estado maduro e finalizado, continua operando e não tem plano de descontinuação. Na mesma faixa, o Google recomenda construir integrações novas de servidor para servidor com a Data Manager API, que chama de infraestrutura central para as próximas novidades de ingestão de dados.

O guia de migração do Google, atualizado em 21 de outubro de 2026, compara as duas rotas em cinco linhas. A Data Manager API usa um modelo de dados comum a todos os produtos de anúncios do Google, aceita criptografia, envia para vários destinos na mesma requisição, dispensa o segredo de API e recusa a requisição na hora quando há erro. O Measurement Protocol é específico do Analytics, envia para um fluxo por vez, exige o segredo e só aponta erros quando a requisição vai ao servidor de validação.

Para a Verde Vivo, a decisão foi ficar no Measurement Protocol, que já funcionava e não tem data de fim, e registrar a migração como tarefa do plano de melhoria, a ser avaliada quando a loja quiser mandar o mesmo pedido ao Analytics e ao Google Ads numa só chamada. Quem começa hoje uma integração do zero tem razão para olhar primeiro a Data Manager API, que aceita até 2.000 eventos por requisição e 10 destinos, segundo a página de limites atualizada em 22 de outubro.

O pedido do servidor precisa carregar o identificador do navegador

O evento enviado pelo servidor só se liga à visita certa se levar o identificador do navegador da pessoa, o client_id, lido do cookie do Analytics no momento do checkout e guardado junto do pedido. A documentação recomenda enviar também o número da sessão (session_id) para que o evento entre na sessão que trouxe a compra. Com identificador inventado, cada pagamento vira uma pessoa nova, sem origem. Mesmo com os dois, a ligação depende de prazo: a página oficial pede que eventos que serão unidos aos coletados pela tag do site (gtag.js) ou pelo SDK do Firebase cheguem em até 48 horas do evento original.

O exemplo abaixo é a requisição que o sistema da Verde Vivo monta quando o banco confirma um Pix. Para quem não programa: ela diz ao Analytics que o navegador identificado por client_id fez uma compra de R$ 215, com dois itens, no horário em que o pagamento foi confirmado. O valor do pedido é a soma dos itens, e o segredo de API fica fora do código, numa variável do servidor.

O carimbo de tempo (timestamp_micros) corresponde a 22 de setembro de 2026, 14h20 em Brasília, hora da confirmação do Pix. O protocolo aceita eventos com até 72 horas de atraso; no comportamento padrão, um evento mais antigo é aceito com a data trocada para 72 horas atrás, e com a validação configurada como ENFORCE_RECOMMENDATIONS é recusado. Uma fila parada por quatro dias perde a data certa dos pedidos.

A prova de recebimento vem do relatório, e a validação só confere o formato

O protocolo não devolve erro quando o evento está malformado: a requisição de produção responde como se tudo estivesse certo. Para conferir o formato, existe um endereço de validação que aponta campos inválidos sem gravar nada. Esse validador não confere o segredo de API nem o identificador do fluxo, e o que ele recebe não aparece nos relatórios. Nos testes, a prova de que o pedido chegou fica no DebugView (a tela de depuração do Analytics), com o parâmetro debug_mode no evento, e no relatório em tempo real. Em produção, a prova de que ele entrou na sessão certa vem do dado processado no dia seguinte e da conciliação.

Fila e reserva evitam o pedido enviado duas vezes

O sistema não envia o evento no instante em que o banco avisa o pagamento; ele grava o pedido numa fila. Um processo lê a fila, envia, guarda a resposta e marca o pedido como enviado. Se a rede falha, tenta de novo com intervalos crescentes. Três prazos convivem aqui: até 48 horas o evento ainda se une à visita; até 72 horas é aceito com a data original; depois disso, o pedido entra só na conciliação. A parte delicada é a concorrência: dois processos lendo a mesma fila podem achar o mesmo pedido pendente e enviar os dois. A proteção é reservar o pedido numa operação única do banco de dados antes de enviar.

O trecho a seguir mostra essa lógica. Para quem não programa: o primeiro processo que consegue gravar a reserva com o número do pedido é o único autorizado a enviar; os outros recebem “já reservado” e seguem adiante. Dois casos ficam sem resposta automática: o processo que cai no meio do envio, cuja reserva abandonada volta para a fila depois de alguns minutos, e o envio que pode ter chegado sem resposta do servidor, marcado como incerto. A conciliação mensal resolve os incertos comparando com os dados processados.

Consentimento vale também no servidor. O sistema confere a escolha que a pessoa fez no banner do site antes de enviar qualquer evento em nome dela, porque o servidor não vê o banner; o registro dessa escolha precisa estar guardado junto do pedido. Nenhum e-mail, telefone ou documento entra como parâmetro. Os fundamentos estão em Consentimento e Consent Mode: respeitar a escolha e ler as lacunas.

Na Verde Vivo, a compra passou inteira para o servidor

O erro mais comum na migração é manter a compra no navegador, na página de confirmação, e acrescentar a compra do servidor. Quem paga com cartão dispara as duas, e a receita de cartão dobra. Caio, o desenvolvedor da Verde Vivo, evitou isso movendo a compra inteira para o servidor em junho de 2026, para todas as formas de pagamento, no mesmo dia em que a tag do navegador parou de enviá-la.

A diferença que sobrou em agosto, 260 pedidos pagos sem compra no Analytics, vem sobretudo de quem recusou a medição no banner, escolha que o servidor respeita, e também de pedidos lançados por telefone ou no balcão da loja e de falhas pontuais; cada parcela fica declarada no relatório em vez de ser preenchida. Numa queda de rede de quatro dias em julho, alguns pedidos ficaram presos na fila além das 72 horas e entraram na conciliação com a marca “enviado fora da janela”. Com o Pix contado, a mídia que traz pagadores de Pix subiu na comparação entre campanhas, e o evento principal importado no Google Ads passou a incluir esses pedidos.

Para encomendar o mesmo na sua empresa, escreva para cada evento que acontece fora do navegador três respostas: quem envia, qual número impede o envio repetido e de onde vêm o client_id e o session_id. Peça também onde fica registrado o consentimento e qual relatório prova o recebimento. Sem essas cinco respostas, nenhum envio deve ser ligado em produção.