Glossário de mensuração de conversão: 40 termos que todo profissional de tráfego precisa dominar

Rastreamento de conversão deixou de ser "colocar um pixel no site" há muito tempo. Com a erosão do cookie de terceiros, o bloqueio de scripts pelo navegador e a exigência de consentimento, a coleta confiável de eventos migrou para o servidor — e trouxe um vocabulário próprio, denso e cheio de siglas. Quem não domina a diferença entre event_id e dedupe key, ou entre EMQ e match rate, opera no escuro e culpa a plataforma quando os números não batem.

Este glossário reúne os termos que aparecem no dia a dia de quem configura, audita ou depura mensuração server-side. É um dicionário de referência para consultar quando um relatório da Conversions API contradiz o painel, quando o cliente pergunta por que o número de compras no anúncio difere do checkout, ou quando você precisa explicar por que o hash do e-mail importa. Cada termo traz uma definição precisa e, quando ajuda, um exemplo concreto.

Fundamentos#

Conceitos base do rastreamento de eventos#

Evento (event) — A unidade atômica da mensuração: uma ação registrada com um nome, um instante e um conjunto de dados associados. Exemplos canônicos são PageView, ViewContent, AddToCart, Purchase e Lead. Todo o sistema de conversão é, no fundo, um fluxo de eventos coletados, transmitidos, deduplicados e atribuídos.

Pixel (browser event) — O evento disparado a partir do navegador do usuário, tradicionalmente por um trecho de JavaScript carregado na página. É o método mais antigo de coleta e o mais frágil hoje: bloqueadores de anúncio, restrições do navegador e falhas de rede fazem uma parcela relevante dos disparos nunca chegar ao destino.

Server-side (server event) — O evento enviado a partir do seu servidor diretamente para a API da plataforma, sem depender do navegador para a transmissão final. É mais resiliente a bloqueio e perda, porque a chamada sai de uma infraestrutura que você controla e não pode ser interceptada por extensões do cliente.

Payload — O corpo de dados de uma requisição de evento, geralmente em JSON. Reúne o nome do evento, o instante, os dados do usuário (hasheados) e os dados customizados. É o objeto que você inspeciona para entender exatamente o que foi enviado.

``json { "event_name": "Purchase", "event_time": 1718900000, "event_id": "ord_8f3a91c2", "action_source": "website", "event_source_url": "https://loja.exemplo.com/checkout/sucesso", "user_data": { "em": ["b4c9a289323b21a01c3e940f150eb9b8c542587f1abfd8f0e1cc1ffc5e475514"], "ph": ["e2b1f6..."] }, "custom_data": { "currency": "BRL", "value": 259.90 } } ``

event_id — Um identificador único atribuído a uma ocorrência específica de evento. É a chave que permite reconhecer que o disparo do pixel no navegador e o disparo server-side se referem à mesma compra, e não a duas compras distintas. Sem um event_id consistente entre os dois canais, a deduplicação não acontece.

Deduplicação (dedupe) — O processo pelo qual a plataforma descarta cópias de um mesmo evento recebidas por canais diferentes (pixel e servidor), contando-o uma única vez. É essencial em qualquer implementação híbrida: você envia pelos dois caminhos para maximizar a chance de entrega, mas quer que só um seja contabilizado.

Dedupe key — A combinação de campos usada para decidir se dois eventos são o mesmo. O par mais comum é event_id + event_name; quando o event_id não está presente, algumas plataformas recorrem a heurísticas por fbp/fbc + event_name + janela de tempo, que são bem menos confiáveis.

Idempotência — A propriedade de uma operação que, executada várias vezes com a mesma entrada, produz o mesmo resultado que uma única execução. Na mensuração, é o que garante que reenviar um evento (por retry de rede) não infle a contagem. O event_id é o mecanismo que torna o envio idempotente.

Data layer — Uma estrutura de dados (tipicamente um objeto JavaScript na página) que centraliza as informações de contexto — produto, valor, categoria, id do usuário logado — para que as tags leiam dali em vez de raspar o DOM. É a fonte de verdade do lado do cliente e o ponto de partida de qualquer tagueamento organizado.

Identidade e correspondência#

Como o evento é ligado a uma pessoa#

PII (Personally Identifiable Information) — Dado que identifica uma pessoa física: e-mail, telefone, nome, endereço, CPF. É insumo valioso para correspondência, mas sensível por natureza — por isso nunca trafega em texto puro para as plataformas de anúncio; vai sempre hasheado.

Hashing / SHA-256 — Função de mão única que transforma um valor (como um e-mail) em uma string de comprimento fixo, irreversível. As plataformas exigem SHA-256 para os campos de identidade: você hasheia o e-mail localmente e envia o hash, permitindo a correspondência sem expor o dado original. A normalização prévia (minúsculas, remoção de espaços) é obrigatória, senão o mesmo e-mail gera hashes diferentes.

``text e-mail: Fulano@Exemplo.com normalizado: fulano@exemplo.com SHA-256: b4c9a289323b21a01c3e940f150eb9b8c542587f1abfd8f0e1cc1ffc5e475514 ``

user_data — O bloco do payload que carrega os sinais de identidade do usuário: e-mail (em), telefone (ph), nome, cidade, CEP, além de identificadores de navegador e clique. Quanto mais campos válidos e bem normalizados você fornece, maior a probabilidade de a plataforma encontrar a pessoa correspondente.

Match rate (taxa de correspondência) — A proporção de eventos enviados que a plataforma conseguiu associar a um usuário conhecido. Um match rate baixo indica dados de identidade escassos, malformados ou mal normalizados, e reduz diretamente a qualidade da otimização e da atribuição.

EMQ (Event Match Quality) — Uma pontuação (comumente de 0 a 10) que estima o quão bem os parâmetros de identidade de um evento permitem a correspondência. Não é o match rate: é uma avaliação da riqueza dos sinais que você envia. Subir o EMQ passa por incluir mais campos de user_data, normalizá-los corretamente e priorizar identificadores fortes como e-mail e telefone.

first-party data — Dado coletado diretamente na relação com o seu público — cadastro, compra, formulário — sob sua responsabilidade e (idealmente) com consentimento. É o ativo central da mensuração pós-cookie, porque não depende de terceiros e alimenta a correspondência com sinais de alta qualidade.

third-party cookie (cookie de terceiro) — Cookie definido por um domínio diferente do que o usuário está visitando, historicamente usado para rastrear pessoas entre sites. Está sendo descontinuado e bloqueado pelos navegadores, o que é justamente a razão de a mensuração ter migrado para first-party data e servidor.

Click ID — Identificador que uma plataforma anexa à URL de destino quando alguém clica no anúncio, permitindo religar a conversão ao clique original. Os mais comuns são fbclid (Meta) e gclid (Google). Capturar e persistir esse valor no primeiro acesso é decisivo para a atribuição server-side.

fbp / fbc — Cookies de primeira parte da Meta: _fbp é um identificador de navegador gerado pelo pixel; _fbc deriva do fbclid capturado no clique. Enviados no user_data, funcionam como âncoras de correspondência quando o e-mail ou telefone não estão disponíveis.

UTM — Parâmetros de URL padronizados (utm_source, utm_medium, utm_campaign, utm_content, utm_term) que marcam a origem de um acesso. São a base da atribuição em ferramentas de analytics, mas vivem no lado do cliente e não substituem os click IDs para atribuição dentro das plataformas de anúncio.

Plataformas e APIs#

Os canais de envio server-side#

CAPI (Conversions API) — A API da Meta para receber eventos direto do servidor, em paralelo ou substituição ao pixel. Aceita os mesmos eventos do pixel, com user_data hasheado, e usa event_id para deduplicar contra o disparo do navegador. É o padrão de fato para mensuração resiliente no ecossistema Meta.

Measurement Protocol — O mecanismo do Google Analytics para enviar eventos ao GA4 via requisições HTTP diretas do servidor, sem o gtag do navegador. Exige um api_secret e um client_id/user_id para associar o evento à sessão correta. É como conversões offline e server-side entram no GA4.

Endpoint — O endereço HTTP para o qual você envia a requisição de evento. Cada plataforma e cada versão de API tem o seu; enviar para o endpoint errado, ou para uma versão obsoleta, é causa comum de eventos que "somem" sem erro visível.

Access token — A credencial que autentica a chamada server-side à API da plataforma. É um segredo: vive apenas no servidor, nunca no bundle do navegador nem em variável exposta ao cliente. Vazá-lo permite que terceiros enviem eventos falsos em nome da sua conta.

Test event code — Um código temporário que você inclui no payload para que os eventos apareçam numa aba de testes da plataforma, sem contaminar os dados de produção. É a ferramenta primária para validar uma integração nova antes de ligá-la de verdade.

Server-side tagging / sGTM — Arquitetura em que um contêiner de tags roda num servidor seu (o caso mais conhecido é o Google Tag Manager server-side) e recebe os eventos do cliente para redistribuí-los às plataformas. Concentra a lógica de tagueamento fora do navegador, reduz o JavaScript de terceiros na página e dá controle sobre o que sai para cada destino.

Container (contêiner) — A unidade de configuração de um gerenciador de tags: agrupa tags, triggers e variáveis. No modelo server-side, o contêiner é o que roda na sua infraestrutura e processa os eventos recebidos antes de encaminhá-los.

Webhook — Uma chamada HTTP que um sistema faz ao seu servidor quando um evento acontece do lado dele — por exemplo, o gateway de pagamento notificando uma compra aprovada. É uma fonte confiável de conversões server-side, porque parte do sistema que tem a verdade da transação.

action_source — Campo que informa à plataforma onde a conversão ocorreu: website, app, email, phone_call, chat, physical_store, system_generated etc. Preenchê-lo corretamente afeta como o evento é interpretado e atribuído; um evento de webhook de pagamento, por exemplo, costuma ser website ou system_generated, não outro valor qualquer.

event_source_url — A URL da página onde o evento se originou. Ajuda na correspondência e na validação do evento, e para eventos de navegador deve refletir a página real; para eventos puramente server-side (como um webhook), pode representar a página do checkout associada.

custom_data — O bloco do payload com os dados específicos da conversão que não são identidade: value, currency, content_ids, content_type, num_items, order_id. É o que alimenta relatórios de ROAS e otimização por valor.

Atribuição#

Ligando a conversão à fonte de tráfego#

Atribuição — O processo de creditar uma conversão a um ou mais pontos de contato do usuário com a mídia. É onde os números divergem: a mesma compra pode ser atribuída a canais diferentes conforme o modelo, a janela e a fonte de dados usados.

Janela de atribuição (attribution window) — O período após um clique ou visualização dentro do qual uma conversão ainda é creditada àquela interação. Configurações comuns são "7 dias de clique e 1 dia de visualização". Comparar dois relatórios com janelas diferentes é comparar coisas distintas — e a causa mais frequente de "os números não batem".

Click-through vs. view-through — Atribuição por clique (a pessoa clicou no anúncio e depois converteu) versus por visualização (a pessoa viu o anúncio, não clicou, e converteu depois). View-through infla o crédito da plataforma e costuma explicar por que o painel de anúncio reporta mais conversões que o seu checkout.

Offline conversion (conversão offline) — Conversão que acontece fora do ambiente digital rastreável — venda por telefone, fechamento no CRM, compra na loja física — e é importada depois para a plataforma, correspondida por dados de identidade. Fecha o ciclo entre o clique online e a receita que só se concretiza offline.

Enhanced conversions (conversões otimizadas) — Recurso do Google que complementa a conversão com dados de identidade first-party hasheados (e-mail, telefone) para melhorar a correspondência quando o cookie sozinho não basta. É o análogo, no Google, de enriquecer o user_data que a CAPI já usa.

Backfill — O reenvio de eventos históricos para uma plataforma, geralmente para preencher uma lacuna de coleta ou subir dados offline acumulados. Exige atenção ao event_time correto de cada evento e ao respeito às janelas de aceitação da API, que costumam recusar eventos muito antigos.

Privacidade e consentimento#

O que pode ser coletado, e quando#

Consent mode (modo de consentimento) — Mecanismo que ajusta o comportamento das tags conforme a escolha do usuário no banner de cookies. Sem consentimento para mídia, as tags operam de forma limitada (ou modelada), em vez de simplesmente coletar tudo. Ignorar o consent mode é risco legal e distorce os dados.

Dado de consentimento (consent data) — O registro da autorização (ou negativa) do usuário para cada finalidade de tratamento: analytics, personalização, mídia. Precisa acompanhar o evento e ser respeitado tanto no cliente quanto no servidor — enviar um evento server-side de um usuário que negou consentimento não torna a coleta legítima.

Modelagem de conversão (conversion modeling) — Estimativa estatística de conversões que não puderam ser observadas diretamente (por falta de consentimento ou de cookie), usada para preencher lacunas nos relatórios. É uma inferência da plataforma, não uma contagem — útil para tendência, tratada com cuidado para decisões finas.

Operação e qualidade#

Manter a mensuração saudável no dia a dia#

Retry / fila (queue) — A estratégia de reenviar eventos que falharam na primeira tentativa, a partir de uma fila persistente no servidor. Combinada com event_id (idempotência), garante que uma indisponibilidade momentânea da API não vire perda de conversão nem contagem duplicada.

Latência de evento (event latency) — O intervalo entre a ação do usuário e a chegada do evento à plataforma. Latência alta atrapalha a otimização em tempo quase real e pode fazer o evento cair fora de uma janela de aceitação; o event_time original deve sempre refletir o momento da ação, não o do envio.

Freshness / janela de aceitação — O prazo máximo, contado a partir do event_time, dentro do qual a API aceita um evento. Eventos além desse limite são recusados — armadilha clássica em backfill e em filas que acumularam durante uma queda longa.

Data discrepancy (discrepância de dados) — A diferença esperada entre duas fontes que medem a "mesma" coisa: painel de anúncio vs. GA4 vs. banco de pedidos. Quase sempre se explica por janela de atribuição, view-through, deduplicação imperfeita ou fuso horário — e não por "bug". Diagnosticar sua origem é metade do trabalho.

Setup híbrido (hybrid) — Arquitetura em que pixel e servidor coexistem: o navegador dispara para cobertura imediata, o servidor para resiliência, e a deduplicação por event_id garante contagem única. É a configuração recomendada na maioria dos casos — não "servidor em vez de pixel", e sim "servidor além do pixel".

Validação de payload — A conferência de que o corpo enviado tem os campos obrigatórios, os tipos corretos e os valores normalizados antes de sair para a API. Evita que eventos silenciosamente rejeitados corroam a mensuração sem gerar alarme.

Estes termos formam o vocabulário mínimo para operar mensuração de conversão com propriedade. A regra prática que costura todos eles: colete first-party data com consentimento, hasheie a identidade antes de transmitir, envie pelo servidor com um event_id estável, deduplique contra o pixel e monitore EMQ, match rate e discrepância como sinais vitais. Quando os números não baterem — e uma hora não vão bater —, o problema quase sempre mora em um destes conceitos, não numa falha misteriosa da plataforma.