Eventos de produto sem taxonomia viram caos em escala: signup, SignUp e user_signed_up coexistem, parâmetros mudam de nome a cada sprint, e o analista gasta metade do tempo traduzindo em vez de analisando. Event design — nomenclatura, propriedades, versionamento e governança — é infraestrutura de analytics tanto quanto warehouse ou BI. Produto que shipa feature sem evento definido shipa feature invisível.

O que é event design e por que importa antes de escalar?

Event design define como ações de usuário viram dados estruturados: nome do evento (snake_case, verbo+objeto), propriedades obrigatórias e opcionais, tipos, valores permitidos e regras de quando disparar. É contrato entre produto, engenharia e analytics — não afterthought de sprint.

Sem design upfront, cada squad inventa convenção. Mixpanel/Amplitude/GA4/PostHog recebem lixo igualmente bem estruturado — dashboards serão lixo proporcional. Retrabalho de taxonomia em produto maduro custa meses; investimento inicial em design custa dias.

Como estruturar nomenclatura de eventos?

Padrão recomendado: object_action em snake_case — project_created, checkout_started, onboarding_step_completed. Verbo no passado para ação concluída; presente para estado (subscription_active). Prefixo de domínio se necessário: billing_invoice_paid vs marketing_banner_clicked.

Proibido: camelCase misturado, espaços, nomes genéricos (click, action, event1), nomes de feature (new_dashboard_v2_click). Mantenha lista de eventos aprovados — PR de instrumentação referencia evento existente ou propõe novo via RFC.

• Formato: object_action snake_case
• Lista aprovada versionada no git
• RFC para evento novo com owner e use case
• Prefixo de domínio quando escala
• Nunca rename silencioso — versionar ou alias

Quais propriedades incluir em cada evento?

Toda evento: timestamp (automático), user_id ou anonymous_id, session context. Propriedades de negócio específicas: project_created → project_id, template_type; checkout_started → cart_value, item_count. Evite PII desnecessária (email, CPF) — use IDs.

Distinção event properties (específicas da ação) vs user properties (atributos do usuário, atualizados separadamente). Cardinalidade controlada: plan_tier (3 valores) sim; project_name (ilimitado) não — use project_id e join com dim_product.

Tipo	Exemplo	Cardinalidade	Onde vive
Event property	template_type: ‘blank’|’template’	Baixa (<20)	No evento
User property	plan_tier: ‘free’|’pro’|’enterprise’	Baixa	Identify/setUserProperty
Super property	app_version, platform	Baixa	Enviado em todo evento
Group property	account_id, account_plan	Média	B2B account-level
Alta cardinalidade	project_id, url_path	Alta	ID sim; texto livre não

Como versionar eventos sem quebrar histórico?

Preferir backward-compatible changes: adicionar propriedade optional > rename. Se rename necessário, periodo de dual-fire (evento antigo + novo) por 2 semanas com alias no warehouse. Nunca delete evento em produção sem deprecação documentada.

schema_version como propriedade quando lógica muda significativamente. No warehouse, view de compatibilidade mapeia v1 e v2 para schema unificado. Dashboards consomem view — não evento raw.

Como alinhar produto, engenharia e analytics no event design?

Tracking plan documentado (Amplitude Taxonomy, Notion, ou YAML no git): evento, trigger, properties, screenshot/mockup, owner, status (planned/active/deprecated). Review de instrumentação no PR — checklist: evento na taxonomia? properties corretas? teste em staging?

Product manager define ‘o que medir’; analytics define ‘como nomear e estruturar’; engenharia implementa e testa. Analytics ops valida em staging antes de merge. Três vozes, um contrato.

• Tracking plan como source of truth
• PR checklist de instrumentação
• Validação em staging pré-merge
• Owner por evento (PM ou analyst)
• Changelog de taxonomia publicado

GA4 vs product analytics tool: design unificado ou separado?

GA4 serve marketing web (acquisition, landing, conversão macro). Product tool (Amplitude, Mixpanel, PostHog) serve comportamento pós-login profundo. Taxonomias separadas com overlap intencional: signup_completed vai para ambos; feature_flag_evaluated só product.

Unificar nomenclatura onde evento existe nos dois — facilita join no warehouse. Prefixo ga_ ou pa_ se necessário para disambiguar. Não force todo evento de produto no GA4 — cardinalidade e limites de custom dimensions quebram.

Quais erros de event design quebram analytics em escala?

Auto-track everything: centenas de clicks irrelevantes, sinal enterrado em ruído. Property sprawl: 40 properties por evento, 35 sempre null. String livre onde enum bastava — analytics vira NLP. Instrumentar só happy path — erro e abandon sem evento.

Deploy sem teste: evento não dispara, dispara duplo, ou property undefined por 2 sprints. Monitoramento de volume por evento (alerta se project_created cai 50%) pega regressão cedo.

Checklist prático

• Tracking plan documentado e versionado no git
• Nomenclatura object_action snake_case enforced
• RFC process para eventos novos
• PR checklist de instrumentação
• Validação em staging antes de produção
• Cardinalidade de properties auditada
• Monitoramento de volume por evento crítico
• Changelog de taxonomia comunicado ao time

Erros comuns

• Auto-track de clicks sem curadoria
• Rename de evento sem dual-fire ou alias
• Property de alta cardinalidade (nome, URL completa)
• PII em event properties
• Instrumentar sem tracking plan aprovado
• Deploy sem validar evento em staging

Perguntas frequentes