Dados e receita
Como eu decidiria se o rastreamento server-side vale o investimento
Chegou uma proposta de server-side e você precisa dizer sim ou não? Eu começaria perguntando qual problema ela resolve, porque nem todo problema de medição se resolve no servidor.
O time ou a agência trouxe uma proposta de rastreamento server-side, com implantação e mensalidade, e você precisa decidir se isso muda alguma coisa no negócio. Eu começaria pedindo uma resposta simples: que problema concreto isso resolve e a estrutura de hoje não resolve?
Vale separar duas coisas. Uma é a qualidade do que a empresa mede, se o evento certo é registrado e se a venda chega à medição. A outra é o caminho que esses dados fazem até cada ferramenta. O server-side mexe no caminho. Pode valer a pena só por isso, mesmo sem mudar nenhuma decisão de campanha, mas a qualidade da medição continua sendo outro trabalho.
O que a empresa passa a controlar
Pela introdução do Google, o contêiner do servidor roda num projeto Google Cloud ou em outro ambiente que a empresa escolhe, e ela passa a controlar a modelagem e o destino dos dados. Na prática, ele fica no meio do caminho: o site manda os dados para ele, e só depois eles seguem para cada ferramenta, com o que a empresa decidiu deixar passar.
Só que poder filtrar não garante que alguém vá filtrar. Eu pediria na proposta quais campos vão para cada fornecedor, quais ficam de fora e quem confere isso depois.
Os fundamentos do server-side também citam menos código de terceiros carregado no navegador, o que ajuda a velocidade da página. Aí eu pediria a lista do que sai do site e uma comparação de antes e depois, porque instalar o servidor, sozinho, não prova nada.
A mesma fonte diz que o servidor complementa as tags do navegador e não as substitui. Para capturar cliques e formulários preenchidos, a tag do GA4 continua na página e envia esses dados ao servidor. Se a proposta prometer tirar todo o rastreamento do site, eu pediria para explicarem como.
A matriz que eu usaria antes de aprovar
Eu pediria ao time para apontar em qual linha está o problema que motivou a proposta. Se forem várias, cada uma pede resposta própria, porque juntar tudo sob “rastreamento ruim” impede de avaliar o investimento.
| Situação | O server-side ajuda? | O que resolver antes |
|---|---|---|
| Precisamos controlar os dados enviados a cada fornecedor. | Sim, controla composição e destino. | Definir os campos de cada destino. |
| Há código de terceiros demais no navegador. | Pode ajudar, se parte do processamento passar ao servidor. | Listar o que sai e o que precisa ficar. |
| Queremos concentrar os envios num lugar só. | Sim, para os fluxos que passarem pelo contêiner. | Mapear origens, destinos e quem opera. |
| O mesmo evento representa ações diferentes. | Não corrige a definição do evento. | Definir o que deve ser medido. |
| O CRM tem registros incompletos ou etapas inconsistentes. | Não corrige o registro comercial. | Padronizar etapas e quem preenche. |
| O usuário negou consentimento. | Não transforma a negativa em autorização. | Definir e respeitar as regras de consentimento. |
| A venda fechada nunca entra na medição. | Não cria a informação ausente. | Definir onde a venda é registrada e como chega à medição. |
Se a justificativa depende das quatro últimas linhas, eu adiaria. Uma necessidade clara de controlar os envios, por outro lado, justifica avaliar o server-side em separado. E consentimento negado continua sendo um limite que o servidor não muda.
Dois exemplos hipotéticos, duas decisões
Exemplo hipotético 1: uma empresa de software com venda consultiva recebe pedidos de contato, mas o CRM mistura oportunidades abertas, contratos assinados e negócios perdidos. O fornecedor propõe server-side para entregar “mais dados ao marketing”. Eu arrumaria o CRM e definiria o que conta como venda antes, porque mandar mais eventos não diz quais contatos viraram receita.
Exemplo hipotético 2: outra empresa já tem eventos bem definidos e um CRM consistente. O que ela quer é limitar os campos que chegam aos fornecedores e tirar scripts externos do site. Aqui eu consideraria o investimento, desde que a proposta mostrasse os filtros e os códigos retirados. O ganho seria saber o que sai para cada ferramenta, mesmo que os relatórios de campanha continuassem iguais.
O custo inclui manter a estrutura funcionando
O guia de Cloud Run estima cerca de US$ 45 por mês por servidor na configuração que descreve e recomenda pelo menos duas instâncias, para reduzir o risco de perder dados se um servidor cair. É a estimativa da documentação em outubro de 2026, não um orçamento para a sua empresa. Como a página em português é tradução automática, eu conferiria os termos no original em inglês.
O mesmo guia avisa que o registro de solicitações pode gerar cobrança relevante com muito tráfego e recomenda atualizar o servidor a cada versão principal, que traz correções de segurança. Por isso eu pediria que a estimativa do fornecedor dissesse qual volume de tráfego considerou.
E deixaria por escrito quem acompanha falhas e atualiza o ambiente. Sem esse nome, a proposta cobre a entrega e esquece o que vem depois dela.
Como eu fecharia a decisão
Meu próximo passo seria pedir ao time ou ao fornecedor uma página de decisão com cinco respostas:
- Qual problema existe hoje e qual evidência mostra isso?
- O que muda nos dados enviados, nos destinos ou nos códigos do navegador?
- Como vamos verificar que a mudança resolveu o problema?
- Qual é o custo inicial e o recorrente, com manutenção?
- Quem opera o ambiente e como reverter se der errado?
Com isso em mãos, eu compararia o benefício que dá para verificar com o custo completo. Se faltasse uma definição básica de medição, ela viria primeiro. Para cobrar evidência com o mesmo rigor, a próxima leitura é o que cobrar nos entregáveis de uma auditoria de Google Ads.
