Existe uma diferença clara entre empresas que “trabalham com dados” e aquelas que efetivamente usam dados para crescer.
Essa diferença não está nas ferramentas adotadas, nem no volume de dados coletados. Ela está na forma como essas empresas estruturam eventos e properties.
Na prática, é aqui que se define se analytics será um suporte operacional ou um motor real de crescimento.
O conceito é simples. A execução é tudo.
No nível mais básico:
- Eventos representam o que aconteceu;
- Properties explicam o contexto desse acontecimento;
Até aqui, nada novo. O problema é que a maioria das empresas para nesse entendimento superficial, o que dificulta a evolução da análise.
Porque eventos e properties não são um conceito técnico. São uma decisão de modelagem do negócio em forma de dados.
Em analytics, eventos registram ações e properties adicionam o contexto necessário para interpretar essas ações. Uma boa taxonomia começa pelas perguntas de negócio que a empresa precisa responder e só depois define o que deve ser instrumentado.
Eventos não são cliques. São momentos de valor.
Cliques, rolagem e outras interações ajudam quando respondem a uma pergunta clara, como localizar um ponto de abandono. Para medir resultados da jornada, priorize eventos que representem etapas verificáveis.
Empresas mais maduras fazem uma pergunta diferente: quais são os momentos que realmente importam na jornada?
E passam a modelar eventos como:
- Início de checkout;
- Conclusão de onboarding;
- Primeiro momento de valor;
- Uso recorrente de uma funcionalidade-chave.
Ou seja, eventos deixam de ser ações isoladas e passam a representar etapas críticas da experiência.
Properties: onde o dado deixa de ser volume e vira inteligência
Sem properties, você conta eventos. Com properties, você entende comportamento.
Uma compra, isoladamente, é apenas um número. Mas quando você adiciona contexto, ela se transforma em algo analisável:
- Canal de origem;
- Método de pagamento;
- Categoria de produto;
- Perfil do usuário;
É nesse ponto que a análise deixa de ser descritiva e começa a ser estratégica.
As propriedades ajudam a localizar onde a mudança ocorreu e a formular hipóteses que a equipe pode investigar.
O erro que mais custa caro: complexidade no lugar errado
Existe um padrão recorrente em empresas de todos os tamanhos.
Elas criam:
- Centenas de eventos;
- Nomenclaturas inconsistentes;
- Estruturas impossíveis de escalar;
E, ao mesmo tempo, deixam de investir onde realmente importa: na qualidade e consistência das properties.
O resultado é previsível: muitos dados e pouca resposta.
O verdadeiro salto de maturidade
Empresas iniciantes perguntam: “quais eventos precisamos trackear?”
Empresas mais maduras perguntam: “quais decisões precisamos tomar?”
Essa inversão muda tudo. Porque eventos e properties passam a ser desenhados de trás para frente, a partir das perguntas de negócio.
Quando isso começa a funcionar de verdade
É aqui que o jogo muda.
Com uma estrutura bem definida, você consegue responder perguntas como:
- Quais canais geram usuários com maior LTV;
- Qual combinação de produto + preço + pagamento maximiza conversão;
- Quais comportamentos indicam retenção ou risco de churn;
- Quais features realmente movem o engajamento.
E mais importante: você responde isso sem depender de ciclos longos de BI ou consultas manuais.
O impacto da taxonomia em outras áreas
Eventos e properties não vivem isolados. Eles alimentam:
- CDPs;
- CRM;
- Motores de personalização;
- Campanhas de mídia;
- Testes e experimentação.
Se a base está mal estruturada, todo o restante herda o problema. Segmentações ficam imprecisas, personalizações não escalam, mídia perde eficiência e a empresa passa a operar com uma falsa sensação de maturidade.
Conclusão
Eventos e properties parecem um detalhe técnico, mas, na prática, são uma das decisões mais estratégicas de toda a arquitetura de dados.
Empresas que tratam isso como implementação acabam presas em relatórios.
Empresas que tratam isso como modelagem de negócio constroem vantagem competitiva.
No fim, a diferença não está no quanto você mede. Está no quanto você consegue entender, e agir, a partir do que mede.
Leia também: Identity Graph: como combinar identidade determinística e probabilística para viabilizar o marketing omnichannel
Material de Apoio
Guia Prático: como estruturar Eventos e Properties que respondem perguntas de negócio
1. Princípio base: eventos descrevem ação, properties dão contexto
Antes de nomear:
- Evento = o que aconteceu
- Property = detalhes do contexto dessa ação
Exemplo simples:
- Evento: checkout_started
- Properties: payment_method, cart_value, user_type
Se misturar isso, seu tracking vira bagunça rápido.
2. Padrão recomendado para nomes de eventos
Aqui é onde muita empresa erra. Use sempre:
verbo + objeto + (contexto opcional)
Exemplos bons:
- product_viewed
- checkout_started
- payment_failed
- account_created
- search_performed
- loan_simulation_completed
Evite:
- click_button (genérico demais)
- step1, event123 (inútil pra negócio)
- checkout (não diz o que aconteceu)
3. Estrutura por jornada (isso muda o jogo)
Organize seus eventos por etapas do funil/jornada:
Aquisição
- landing_page_viewed
- signup_started
- signup_completed
Ativação
- onboarding_started
- onboarding_completed
- first_transaction_completed
Engajamento
- feature_used
- search_performed
- notification_clicked
Monetização
- checkout_started
- payment_completed
- subscription_activated
Retenção
- session_started
- app_opened
- user_returned
Isso te permite construir funnels e cohorts sem esforço depois.
4. Padrão para Properties (aqui mora a inteligência)
Properties devem responder:
- Quem? → user_id, user_type
- Onde? → page, screen, channel
- O quê? → product_id, category
- Como? → payment_method, device
- Quanto? → value, quantity
Exemplos:
Evento: payment_completed
Properties:
- payment_method: pix
- transaction_value: 250
- installments: 1
- product_category: insurance
5. Naming conventions (padrão que evita caos)
Defina regras claras:
- lowercase sempre: checkout_started
- usar underscore _, nunca espaço
- sem acento
- inglês (padrão global e escalável)
- evitar abreviações obscuras
6. Erros clássicos (evite isso a todo custo)
- Criar eventos duplicados com nomes diferentes (checkout_start vs checkout_started);
- Colocar informação no nome em vez de property (payment_pix_success);
- Não versionar mudanças (quebra histórico);
- Não documentar (ninguém sabe o que é o quê).
7. Exemplos prontos (contexto banco digital / varejo)
Exemplo hipotético de banco digital
- account_opening_started
- account_approved
- pix_transfer_completed
- loan_requested
- loan_approved
Properties:
- company_size
- monthly_revenue_range
- transaction_value
Exemplo hipotético de varejo farmacêutico
- product_viewed
- add_to_cart
- checkout_started
- purchase_completed
Properties:
- product_category
- store_type: online | physical
- delivery_type: pickup | delivery
8. Nível avançado (isso te diferencia)
Se quiser jogar em nível alto (e isso conecta com GEO, IA e produto):
- crie eventos baseados em intenção, não só ação
Ex: high_intent_product_viewed - adicione propriedades de qualidade da experiência
Ex: error_type, latency_ms - inclua contexto de jornada
Ex: step_number, funnel_stage
Como validar eventos antes de publicar o tracking
Escolha uma pergunta, como “Em qual etapa o checkout perde mais clientes no celular?”. Documente cada evento com gatilho, fonte responsável e campos obrigatórios. Compare os eventos de compra com os pedidos confirmados no mesmo período.
| Evento de exemplo | O que testar |
|---|---|
checkout_started | Dispara quando uma tentativa de checkout começa. Confirme se voltar ou atualizar a tela mantém o mesmo identificador da tentativa. |
payment_failed | Dispara após uma tentativa com falha. Capture uma categoria de erro para diagnóstico e teste o fluxo sem coletar dados do cartão. |
payment_completed | Registra a confirmação de pagamento. Use o identificador da transação para testar duplicidades entre eventos de navegador e servidor. |
Os nomes da tabela são exemplos de uma taxonomia própria. Em GA4, use a implementação de e-commerce e valide os eventos recomendados conforme a documentação do Google. Quando o painel divergir do sistema de pedidos, revise a governança das fontes e regras de qualidade antes de interpretar a conversão.
Menos teoria, mais aplicação real. Siga o Tudo Sobre CDP no LinkedIn.
