Tracking de eventos e conversões

Por que tracking inconsistente envenena toda análise depois

Análise de marketing é construída sobre dados de tracking. Quando o tracking está quebrado, todo relatório depois mente — e ninguém percebe. Os sintomas típicos: a taxa de conversão informada no painel é maior que a real (eventos duplicados); a atribuição de canal aponta para o canal errado (parâmetro de campanha mal configurado); o custo de aquisição de cliente está subestimado (conversões offline não integradas); a campanha aparece com bom desempenho mas o time de vendas não vê o reflexo no pipeline (definição de conversão diferente entre marketing e vendas).

Causa raiz quase sempre é a mesma: implementação foi feita sem método. Vários colaboradores adicionaram eventos ao longo do tempo, cada um nomeou do seu jeito, ninguém documentou. Em dois ou três anos, a conta do Google Analytics 4 tem 300 eventos, 80 conversões marcadas, naming inconsistente entre áreas, e a equipe não sabe qual conversão usar como métrica primária. Pior: a equipe usa eventos diferentes em relatórios diferentes para a mesma diretoria, com números que não batem.

Evento vs. conversão: a distinção fundamental

Eventos são qualquer interação rastreada do usuário com site ou aplicativo: visita a página, clique em botão, rolagem até o fim, envio de formulário, abertura de email, visualização de produto, abandono de carrinho, login. Conversões são o subconjunto pequeno de eventos que importa para o negócio — geralmente entre 5 e 15 em operação madura, não 80.

Conversão precisa atender a três critérios: (1) representa resultado de negócio (geração de contato qualificado, compra, ativação de assinatura, recadastro), não comportamento intermediário; (2) é estável o suficiente para servir de otimização em plataforma de mídia paga durante semanas ou meses; (3) é compreendida da mesma forma por marketing, vendas, produto e financeiro.

Quando todo evento vira conversão, conversão perde sentido. O painel mostra "1.847 conversões no mês" — soma de 12 tipos de conversão diferentes, e ninguém sabe quantas vendas houve nem quantos contatos qualificados. Disciplina de definir poucas conversões críticas é o que torna o relatório útil para diretoria.

Método: do funil aos eventos certos

1. Comece pelo funil de negócio

Antes de listar eventos, mapeie o funil. Em B2B: visita ao site ? leitura de conteúdo ? pedido de demonstração ? contato qualificado por marketing ? contato qualificado por vendas ? oportunidade ? cliente. Em e-commerce: visita ao site ? visualização de produto ? adição ao carrinho ? início do checkout ? compra ? recompra. Cada estágio do funil é candidato a evento; só alguns estágios são candidatos a conversão.

2. Mapeie eventos por estágio

Para cada estágio do funil, defina o evento que sinaliza passagem. Visita ao site é evento "page_view" (já vem nativo no Google Analytics 4). Leitura de conteúdo é "scroll_90" (rolagem até 90% da página). Pedido de demonstração é "demo_request_submit". E assim sucessivamente. Cada evento tem definição técnica precisa (qual gatilho dispara, em que página, com que parâmetro).

3. Escolha as 5 a 15 conversões críticas

Do conjunto de eventos, marque como conversão apenas as 5 a 15 mais importantes para decisão de negócio. Em B2B: pedido de demonstração, contato qualificado, oportunidade aberta. Em e-commerce: compra, recompra, carrinho recuperado. Não marque "visita à página de preço" como conversão — é evento intermediário, não resultado.

4. Documente em dicionário de dados

Para cada evento e cada conversão, planilha estruturada com colunas: nome técnico (formato_snake_case), descrição em linguagem natural, gatilho preciso, parâmetros associados, área dona, marcação de conversão sim ou não, motivo da marcação. Esse documento vive em local compartilhado (Notion, Confluence, planilha) e é consultado antes de adicionar qualquer evento novo.

Naming convention: a disciplina que evita caos em três anos

Naming convention é a regra de como nomear evento. Sem regra, em três anos a conta tem evento_lead, leadEvent, novo-lead, lead_new, LeadCadastro e Lead_form_submit — todos significando a mesma coisa, mas com seis nomes diferentes. Análise depois precisa unificar manualmente, e quase sempre alguém esquece de algum.

Regra prática que funciona: snake_case (palavras em minúscula separadas por sublinhado), prefixo por área ou estágio do funil, verbo no início indicando ação. Exemplos: lead_form_submit (envio do formulário de contato), checkout_step_complete (conclusão de uma etapa do checkout), product_view (visualização de produto), purchase_complete (compra completa), email_open (abertura de email).

Outras regras úteis: nomes em inglês (linguagem padrão de ferramentas e bibliotecas), sem acento ou caractere especial, máximo 40 caracteres, evitar abreviações ambíguas. Parâmetros associados também seguem padrão (product_id, product_category, product_price, transaction_value, currency). Quando há subevento, padrão por dois pontos (checkout:step_1, checkout:step_2, checkout:complete).

Conversões offline: CRM para Google Analytics 4

Em B2B, a maior parte do funil acontece fora do site — o contato é gerado em formulário, mas a oportunidade qualificada e a venda fechada acontecem no CRM, meses depois. Rastreamento que para no formulário perde informação crítica de qualidade do contato gerado.

Conversão offline é a integração que devolve para o Google Analytics 4 (e para Google Ads, Meta Ads) o resultado real do contato: virou oportunidade? virou venda? qual valor? quanto tempo demorou? Existem duas formas práticas: importação de conversões por arquivo (exporta CSV do CRM e carrega no Google Analytics 4 ou Google Ads, em fluxo semanal ou diário) e API de conversões em tempo quase real (CRM dispara webhook para Google Analytics 4 ou Meta Conversion API a cada mudança de estágio).

Pré-condição é identificador comum: o contato gerado no site recebe um identificador (geralmente o GCLID do Google Ads ou o ID de usuário do Google Analytics 4) que é gravado no CRM. Quando a venda fecha meses depois, o identificador permite ligar a conversão final ao clique de anúncio original. Sem identificador, integração de conversão offline não funciona.

Resolução cross-device: o problema que não some

Usuário acessa o site no celular durante o almoço, volta no notebook do trabalho à tarde, finaliza a compra no tablet à noite. Para o Google Analytics 4 são três usuários distintos — não há vínculo nativo entre os três dispositivos. Atribuição quebra: o último dispositivo recebe todo o crédito da conversão; os dois primeiros parecem ter trazido visita sem resultado.

Resolução de identidade é o processo de ligar os três dispositivos como uma pessoa só. Caminhos práticos: (1) login no site — usuário logado em vários dispositivos ata os fios; (2) plataforma de dados de cliente (Segment, mParticle, Snowplow) que mantém ID de usuário persistente; (3) identificador comum em vários domínios (gtag.js com user_id parameter). Sem identidade resolvida, a métrica cross-device é estimada por modelo do Google, com incerteza alta.

Rastreamento no servidor (server-side): resiliência contra bloqueadores

Bloqueadores de anúncio (uBlock Origin, AdBlock Plus, Brave navegador) interceptam scripts de rastreamento que rodam no navegador. ITP (Intelligent Tracking Prevention) da Apple e o fim dos cookies de terceiros no Chrome reduzem ainda mais a confiabilidade do rastreamento no navegador. Estima-se que 20% a 40% dos eventos podem ser perdidos no rastreamento client-side em segmentos como tecnologia e mídia.

Rastreamento server-side move a captura do evento do navegador para o servidor da empresa, com biblioteca dedicada (Server-side Tagging do Google Tag Manager, Snowplow, biblioteca Meta Conversions API). O servidor enrique e envia o evento para plataforma de análise (Google Analytics 4), plataforma de mídia paga (Google Ads, Meta Ads) e plataforma de dados de cliente.

Vantagens: resiliente a bloqueadores, controle sobre o que sai do servidor, melhor para LGPD (mais fácil aplicar consentimento e expurgo). Desvantagens: custo de infraestrutura (servidor próprio ou serviço gerenciado), complexidade de implementação, exige desenvolvedor para manutenção.

LGPD: consentimento e base legal por finalidade

A Lei Geral de Proteção de Dados (Lei 13.709 de 2018) trata dado de rastreamento como dado pessoal quando permite identificar pessoa natural — o que inclui ID de cookie, identificador de aplicativo, endereço IP e em muitos casos GCLID e Facebook Browser ID. Coleta exige base legal e, na prática, para finalidade de marketing e publicidade, a base mais segura é consentimento explícito.

Implementação prática: banner de consentimento (Cookiebot, OneTrust, Iubenda ou implementação própria) que cumpre os requisitos da LGPD — opção para aceitar tudo, recusar tudo, configurar por categoria (necessário, analítico, marketing, personalização); registro auditável da escolha; possibilidade de mudar a escolha depois. Eventos de rastreamento só disparam após o consentimento.

O Consent Mode v2 do Google é a forma técnica de propagar a escolha do usuário para os serviços do Google (Google Analytics 4, Google Ads). Sem Consent Mode v2 configurado, a partir de 2024 o Google Ads passou a limitar acesso a recursos para anunciantes no Espaço Econômico Europeu — e o padrão tende a alcançar outros mercados.

Governança: o dicionário de dados que ninguém quer manter

Dicionário de dados é o documento de referência onde todo evento e toda conversão estão registrados com nome técnico, descrição, gatilho, parâmetros, área dona e marcação de conversão. Sem dicionário, ninguém sabe o que cada evento significa; com dicionário desatualizado, a confiança no dado some ainda mais.

Manutenção do dicionário precisa de processo, não só boa intenção. Modelo prático: qualquer evento novo passa por solicitação de mudança escrita (mesmo informal: ticket no Jira, post em canal de mensagem dedicado, pull request em sistema de controle de versões). A solicitação contém: nome proposto seguindo a naming convention, descrição, gatilho, parâmetros, justificativa, marcação de conversão. Pessoa responsável pelo dicionário aprova, ajusta o nome se necessário, atualiza o documento.

Em operação grande, o dicionário vive em sistema de controle de versões com revisão obrigatória — mudança no tracking passa por revisão técnica antes de subir para produção. Em operação pequena, planilha bem mantida resolve. O ponto é o processo de aprovação, não a ferramenta.

Erros comuns em tracking

Cem conversões marcadas. Time foi marcando como conversão qualquer evento ao longo dos anos. Hoje há 100 conversões e ninguém sabe qual usar. Painel mostra número alto mas mistura categorias incomparáveis. Solução: desmarcar tudo e marcar 5 a 15 conversões críticas com critério claro.

Naming inconsistente. O mesmo evento aparece com cinco nomes diferentes ao longo do tempo. Análise depois precisa unificar manualmente. Solução: naming convention escrita, aplicada em todo evento novo, e auditoria periódica de eventos antigos para padronização.

Eventos duplicados. O mesmo evento dispara duas vezes — uma em script do site, outra em Google Tag Manager. O contador cresce sem que comportamento real tenha mudado. Solução: auditoria de gatilhos, especialmente após mudanças no site ou no Google Tag Manager.

Sem documentação. Eventos foram implementados em três diferentes consultorias, ninguém documentou. Quando o profissional sai, o conhecimento sai junto. Solução: dicionário de dados atualizado, fora de ferramenta proprietária.

LGPD ignorada. Eventos disparam antes de consentimento, ou consentimento é tratado como caixa marcada por padrão. Risco regulatório real. Solução: banner conforme, eventos condicionais ao consentimento, registro auditável.

Cross-device quebrado. Usuário em três dispositivos vira três usuários distintos no painel. Atribuição quebra. Solução: ID de usuário persistente via login ou plataforma de dados de cliente.