Reconciliação servidor versus cliente
Clientes regularmente comparam seus números do Zenovay contra GA4, recibos do Stripe ou seus próprios logs de backend e descobrem que os números não alinham perfeitamente. Às vezes o Zenovay relata mais eventos. Às vezes menos. A resposta honesta é que toda ferramenta de análise — 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 ele compara
Reconciliação é executada como um trabalho diário que compara três camadas de verdade de eventos, por site, por tipo de métrica, por dia:
| Camada | O que mede | Onde existe |
|---|---|---|
| Cliente | Eventos acionados pelo rastreador 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 (website, day, metric) ela registra: quantos eventos cada camada viu, quantos combinaram, a porcentagem estimada de perda e uma razão de desajuste primária classificada de um conjunto fixo.
Os três tipos de métrica V1
V1 cobre as três métricas que têm uma camada de verdade inequívoca:
- Visualizações de página — cliente (navegador) versus servidor (
POST /api/v1/events). - Conclusões de metas — eventos de meta do cliente versus eventos de meta do lado do servidor.
- Eventos de receita — eventos de compra do cliente versus verdade webhook do Stripe (
payment_events).
Eventos personalizados, chamadas identify e outros tipos de evento estão fora do escopo do V1 — não têm uma camada de verdade comparável.
Como a perda é estimada
Para visualizações de página e metas, a camada de verdade é server_count. Para receita, a camada de verdade é webhook_count (o webhook do provedor de pagamento é a fonte da verdade — é isso que realmente cobrou do cliente).
estimatedLoss = (truth - client) / truth × 100
Valores negativos são permitidos: se o servidor capturou mais eventos do que o rastreador do navegador fez, isso é informação também — significa que seu rastreador perdeu eventos que a ingestão do lado do servidor capturou, que é justamente o objetivo de executar ambos.
Rótulos de confiança
Cada linha de reconciliação possui um de três rótulos:
| Rótulo | Quando se aplica |
|---|---|
| Alta confiança | Ambas as camadas têm cada uma ≥100 eventos e a perda estimada é menor que 30%. |
| Confiança média | Uma camada está na faixa de 50–100 eventos, ou a perda fica entre 30% e 60%. |
| Dados limitados | Menos de 50 eventos em uma camada, a perda excede 60%, ou apenas uma camada está presente. |
"Dados limitados" não é um problema a corrigir — apenas significa que a amostra é muito pequena ou unilateral para tirar uma conclusão confiante. Os rótulos de confiança mantêm a visualização Trust honesta sobre o que sabe.
Razões de desajuste
Quando a reconciliação detecta uma lacuna significativa, ela escolhe uma de sete razões, classificadas por prioridade de detecção:
| Razão | Regra de detecção | Acionável? |
|---|---|---|
webhook_delay | Cliente > webhook por ≥20% E a contagem de webhook de hoje é ≥2σ abaixo da média dos últimos 6 dias | ✓ |
client_blocked | Servidor > cliente por ≥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 | informacional |
id_stitching | Alta variância em cliente não correspondido entre segmentos de visitante | informacional |
no_server_layer | server_count = 0 e client_count > 0 | informacional |
unknown | Nenhum limite foi acionado | informacional |
Três razões são acionáveis — significa que a ação é sua (corrigir sua CSP, configurar SDK retry, verificar entrega de webhook do Stripe). As outras quatro são contexto de diagnóstico.
Onde ver
Abra Domains, clique em seu site, depois selecione a aba Trust (em Reliability). Você verá:
- A perda de rastreamento estimada para os últimos 7 dias, com um rótulo de confiança.
- Uma divisão por métrica (visualizações de página, metas, receita) mostrando contagens de cliente / servidor / correspondidas e a lacuna visualizada como uma seção listrada de uma barra de integridade.
- As principais razões de desajuste classificadas pelo impacto do evento, com etapas de ação para as acionáveis.
- (Pro e acima) Uma análise por rota mostrando exatamente quais rotas contribuem mais para a lacuna.
O que não é
- Não é uma garantia de exatidão. É uma medição da qualidade da medição.
- Não é uma tentativa de corrigir a lacuna. As correções — configuração de CSP, configuração de webhook, normalização de rota — são responsabilidade sua.
- Não nomeia serviços de terceiros ou fornecedores que você já não esteja usando. As razões de desajuste permanecem genéricas para que as etapas de ação permaneçam relevantes qualquer que seja sua pilha.
- Não cria coleta de dados nova. Reconciliação lê linhas existentes de
page_views,user_eventsepayment_events— não há novos cookies, novos identificadores, e a garantia de rastreamento sem cookies permanece inalterada.
Disponibilidade do plano
A aba Trust está disponível em todos os planos. A análise por rota e as etapas de ação para razões acionáveis estão disponíveis no Pro e acima. Free mostra agregados e nomes de razão sem o detalhe em nível 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 lado do servidor — o endpoint
POST /api/v1/eventsque capacita a camada de servidor da reconciliação. - Rastreamento sem cookies — por que o rastreador em memória não polui a reconciliação com identificadores obsoletos.