Reconciliação servidor-vs-cliente
Clientes regularmente comparam seus números do Zenovay com GA4, recibos do Stripe ou seus próprios logs de backend e descobrem que os números não batem exatamente. Às vezes o Zenovay reporta mais eventos. Às vezes menos. A resposta honesta é que toda ferramenta de analytics — Zenovay incluído — está fazendo uma estimativa baseada no que chegou ao navegador, no que chegou ao servidor e no que foi confirmado por um webhook.
Reconciliação é o mecanismo do Zenovay para quantificar essa lacuna com rótulos de confiança em vez de fingir que ela não existe.
O que ela compara
A reconciliação roda como um job diário que compara três camadas de verdade, por site, por tipo de métrica, por dia:
| Camada | O que mede | Onde vive |
|---|---|---|
| Cliente | Eventos disparados pelo tracker do navegador | page_views, user_events com source = 'browser' |
| Servidor | Eventos ingeridos via POST /api/v1/events | Mesmas tabelas, source = 'server' |
| Webhook | Confirmações de webhook do Stripe / LemonSqueezy / Polar | payment_events com status = 'succeeded' |
Para cada tripla (site, dia, métrica) registra: quantos eventos cada camada viu, quantos casaram, a porcentagem de perda estimada e uma razão principal de mismatch escolhida de um conjunto fixo.
Os três tipos de métrica V1
A V1 cobre as três métricas que possuem uma camada de verdade inequívoca:
- Páginas vistas — cliente (navegador) vs servidor (
POST /api/v1/events). - Conclusões de objetivos — eventos de objetivo do cliente vs do servidor.
- Eventos de receita — eventos de compra do cliente vs verdade do webhook do Stripe (
payment_events).
Eventos personalizados, chamadas identify e outros tipos de eventos estão fora do escopo da V1 — eles não têm uma camada de verdade comparável.
Como a perda é estimada
Para páginas vistas e objetivos, a camada de verdade é server_count. Para receita, é webhook_count (o webhook do provedor de pagamento é a fonte da verdade — foi ele quem efetivamente cobrou o cliente).
perda_estimada = (verdade - cliente) / verdade × 100
Valores negativos são permitidos: se o servidor capturou mais eventos do que o tracker do navegador, isso também é informação — significa que seu tracker perdeu eventos que a ingestão do servidor capturou, que é exatamente a razão para rodar os dois.
Rótulos de confiança
Toda linha de reconciliação carrega um de três rótulos:
| Rótulo | Quando se aplica |
|---|---|
| Confiança alta | Ambas as camadas têm ≥100 eventos cada e a perda estimada é menor que 30 %. |
| Confiança média | Uma das camadas está na faixa de 50–100 eventos, ou a perda está entre 30 % e 60 %. |
| Dados limitados | Menos de 50 eventos em alguma camada, perda acima de 60 %, ou apenas uma camada presente. |
«Dados limitados» não é um problema a ser corrigido — apenas significa que a amostra é pequena ou unilateral demais para uma conclusão confiável. Os rótulos de confiança mantêm a visão Trust honesta sobre o que sabe.
Razões de mismatch
Quando a reconciliação detecta uma lacuna significativa, ela escolhe uma de sete razões, ordenadas por prioridade de detecção:
| Razão | Regra de detecção | Acionável? |
|---|---|---|
webhook_delay | Cliente > webhook em ≥20 % E a contagem de webhook de hoje está ≥2σ abaixo da média de 6 dias | ✓ |
client_blocked | Servidor > cliente em ≥10 % | ✓ |
route_mapping | As 1-2 rotas principais representam ≥50 % da lacuna | ✓ |
duplicate_suppression | O pipeline de ingestão deduplicou eventos do navegador dentro do dia | informativa |
id_stitching | Alta variância de eventos cliente sem par entre segmentos de visitantes | informativa |
no_server_layer | server_count = 0 e client_count > 0 | informativa |
unknown | Nenhum limite atingido | informativa |
Três razões são acionáveis — a ação é sua (corrigir seu CSP, configurar retry do SDK, verificar entrega do webhook do Stripe). As outras quatro fornecem contexto diagnóstico.
Onde ver
Abra qualquer dashboard de domínio em app.zenovay.com e selecione a aba Trust. Você verá:
- A perda de rastreamento estimada dos últimos 7 dias, com rótulo de confiança.
- Um detalhamento por métrica (páginas vistas, objetivos, receita) mostrando contagens de cliente / servidor / casados e a lacuna visualizada como seção listrada de uma barra de completude.
- As principais razões de mismatch ordenadas por impacto em eventos, com passos de ação para as acionáveis.
- (Pro e acima) Uma tabela drilldown por rota que mostra exatamente quais rotas contribuem mais para a lacuna.
O que não é
- Não é garantia de exatidão. É uma medição da qualidade de medição.
- Não é uma tentativa de corrigir a lacuna. As correções — configuração de CSP, configuração de webhook, normalização de rotas — estão do seu lado.
- Não nomeia serviços ou fornecedores de terceiros que você já não usa. As razões de mismatch permanecem genéricas para que os passos de ação continuem relevantes seja qual for seu stack.
- Não cria nova coleta de dados. A reconciliação lê linhas existentes de
page_views,user_eventsepayment_events— sem novos cookies, sem novos identificadores, e a garantia de rastreamento sem cookies permanece inalterada.
Disponibilidade por plano
A aba Trust em si está disponível em todos os planos. O drilldown por rota e os passos de ação para razões acionáveis estão disponíveis a partir do Pro. Free mostra agregados e nomes de razão sem o detalhe de rota.
Conceitos relacionados
- Taxa de rejeição — outro sinal de qualidade que se beneficia do contexto de reconciliação.
- Ingestão de eventos do servidor — o endpoint
POST /api/v1/eventsque alimenta a camada servidor da reconciliação. - Rastreamento sem cookies — por que o tracker em memória não polui a reconciliação com identificadores obsoletos.