Event Tracking em aplicativos móveis: o que é, tipos de eventos e como configurar

O que é Event Tracking?

Event Tracking é o processo de coleta, armazenamento e análise de ações discretas do usuário no aplicativo. Cada evento consiste em um nome (event_name) e um conjunto de parâmetros (event_params). Por exemplo, o evento purchase tem os parâmetros price, currency, product_id, quantity.

Ao contrário do Screen View, que registra o fato de abrir uma tela, o Event Tracking descreve exatamente o que o usuário faz nessa tela: clicou no botão “Comprar”, abriu o carrinho, aplicou um código promocional. Sem eventos, é impossível entender a motivação e o contexto das ações do usuário.

Estrutura do evento

Cada Analytics Event contém campos obrigatórios e opcionais. Obrigatórios: event_name, event_timestamp, user_id (ou device_id). Opcionais: parâmetros que descrevem o contexto.

O parâmetro revenue é especialmente importante — ele é enviado para plataformas MMP para cálculo automático de ROAS e LTV.

Tipos de eventos em análise móvel

Os eventos são classificados por origem e propósito. Essa divisão ajuda a organizar a estrutura de dados e atribuir direitos de acesso para diferentes equipes.

Eventos automáticos (SDK)

Os SDKs das plataformas de análise coletam automaticamente eventos básicos: app_install, app_remove, session_start, screen_view. O Firebase Analytics gera cerca de 20 eventos automáticos sem uma única linha de código. Esses eventos cobrem métricas básicas, mas não fornecem compreensão da lógica de negócios.

Eventos personalizados

Os eventos personalizados são o que torna o Event Tracking valioso. Eles descrevem ações de negócio: add_to_cart, start_subscription, level_complete, share_content, search_performed. Eventos personalizados exigem envio explícito do código do aplicativo.

// Enviando um evento personalizado para o Firebase
val bundle = Bundle().apply {
    putString(AnalyticsParam.ITEM_ID, "prod_789")
    putString(AnalyticsParam.ITEM_NAME, "Premium Subscription")
    putString(AnalyticsParam.CURRENCY, "USD")
    putDouble(AnalyticsParam.PRICE, 29.99)
    putString(AnalyticsParam.SOURCE, "onboarding_screen")
}
FirebaseAnalytics.getInstance(this)
    .logEvent("subscribe_premium", bundle)

No exemplo, o evento subscribe_premium contém quatro parâmetros de contexto. O parâmetro source permite identificar de qual tela o usuário se inscreveu — integração, configurações ou paywall.

User Properties e Super Properties

Além dos eventos, o Event Tracking inclui User Properties — atributos vinculados ao usuário: nível de assinatura, país, versão do aplicativo. Uma User Property é enviada uma vez e se aplica a todos os eventos subsequentes da sessão. Isso permite segmentar a análise sem adicionar parâmetros a cada evento.

Super Properties (Amplitude) ou Global Properties (Mixpanel) — atributos vinculados a uma sessão, não a um usuário. São usadas para testes A/B: variant_id como Super Property é adicionado a todos os eventos da sessão, e o analista pode ver a qual grupo o usuário pertence.

Eventos de receita

Os eventos de receita são uma classe separada para registrar transações. Eles contêm o valor, a moeda e o tipo de compra (assinatura, compra única, restauração). As plataformas MMP (AppsFlyer, Adjust) exigem eventos de receita para calcular o ROAS.

De acordo com a Branch (2024), aplicativos que transmitem corretamente eventos de receita para MMP obtêm dados de atribuição 25% mais precisos e podem otimizar campanhas para LTV em vez de CPI.

Como configurar Event Tracking?

A configuração do Event Tracking envolve três etapas: planejamento do esquema de eventos, integração do SDK e validação de dados.

Etapa 1: Design do esquema de eventos

Crie uma Taxonomia de Eventos — um documento que descreve cada evento: nome, parâmetros, gatilho de envio, proprietário. Exemplo para e-commerce: order_completed → parâmetros: order_id, total_price, items_count, payment_method, shipping_city.

• Cada evento responde à pergunta: o que o usuário fez?
• Cada parâmetro responde à pergunta: em que contexto?
• Evite eventos sem parâmetros — eles são inúteis para análise

Etapa 2: Integração do SDK

Integre o SDK de análise ao seu projeto. Firebase Analytics, Amplitude, Mixpanel — qualquer SDK requer inicialização em Application.onCreate(). Exemplo para Flutter:

import 'package:firebase_analytics/firebase_analytics.dart';

class AnalyticsService {
  final _analytics = FirebaseAnalytics.instance();

  Future<void> logPurchase({
    required String productId,
    required double price,
    required String currency,
  }) async {
    await _analytics.logEvent(
      name: 'purchase_completed',
      parameters: {
        'product_id': productId,
        'price': price,
        'currency': currency,
        'timestamp': DateTime.now().millisecondsSinceEpoch,
      },
    );
  }
}

A classe AnalyticsService centraliza o envio de todos os eventos. Cada método corresponde a uma ação de negócio. Isso simplifica a localização da origem — se um evento não chega, você procura pelo nome do método no código. À medida que o projeto escala, o número de métodos pode crescer para 50–100, mas a estrutura permanece legível devido ao agrupamento por funcionalidade.

Etapa 3: Validação via DebugView

O Firebase DebugView permite ver os eventos em tempo real em um dispositivo de desenvolvimento. Ative-o: adb shell setprop debug.firebase.analytics.app your.package. Todos os eventos aparecerão no console do Firebase com um atraso de menos de 5 segundos.

Após ativar o DebugView, abra o aplicativo e execute um cenário de teste — registro, compra, navegação pelo catálogo. No console, verifique: se todos os eventos foram enviados, se os parâmetros corretos foram transmitidos, se não há duplicação. A Amplitude oferece uma ferramenta semelhante — Amplitude Debugger para iOS e Android.

A validação automática via CI/CD é o próximo nível de qualidade. Adicione um script ao pipeline que verifica se cada evento do esquema foi enviado pelo menos uma vez durante a execução do teste. Isso evita implantar versões com eventos ausentes e economiza tempo dos engenheiros de QA.

Melhores práticas de nomeação de eventos

A nomeação de eventos é o aspecto mais subestimado do Event Tracking. Um nome incorreto torna a análise inútil quando o projeto tem mais de 50 eventos.

Padrão Objeto + Ação

Use o padrão object_action (minúsculas, snake_case): product_added, cart_opened, payment_failed, subscription_cancelled. O objeto é a entidade, a ação é o verbo no passado. Lê-se como uma frase: “produto adicionado,” “carrinho aberto.”

• product_viewed, não “tap_on_product_card” (o evento é um resultado, não uma ação)
• order_completed, não “successful_payment_transaction” (curto e claro)
• level_started, não “begin_level_with_parameters” (sem palavras extras)

Padrões proibidos

NÃO use espaços (“Add to Cart”), CamelCase (“AddToCart”), pontos (“add.to.cart”) nem hífens (“add-to-cart”). A maioria dos SDKs recomenda snake_case. NÃO use nomes de elementos de UI (“btn_submit_clicked”) — o evento deve ser de negócio, não técnico.

Para prefixos, adicione o nome da funcionalidade ou tela: onboarding_step_completed, checkout_payment_selected. Isso permite filtrar eventos por funcionalidade nos relatórios.

Tipos de parâmetros de eventos

Os parâmetros são divididos em três tipos: string (valor), number (número para agregação), boolean (indicador). Os parâmetros string contêm dados categóricos: país, fonte de tráfego, nome do produto. Os parâmetros number servem para métricas: preço, quantidade, duração. Os parâmetros boolean indicam estado: is_trial, is_promo_applied.

Evite passar objetos ou arrays em um único parâmetro — as plataformas de análise não conseguem analisá-los. Em vez de uma string JSON em um campo, passe vários parâmetros simples. Por exemplo, em vez de items_count_total, passe items_count e total_price separadamente.

Plataformas para Event Tracking

A escolha da plataforma de Event Tracking depende da escala do projeto e da equipe. Vamos considerar três opções de diferentes níveis.

Firebase Analytics (gratuito, até 500 eventos)

Firebase é a escolha padrão para startups. Limite gratuito — 500 event_name diferentes, número ilimitado de parâmetros. Integração com BigQuery para análise personalizada. Desvantagens: segmentação limitada, sem vinculação automática de eventos em sessões.

Amplitude (Pro a partir de $1.000/mês)

Amplitude é uma plataforma de análise de produto. Suporta Coortes Comportamentais, Análise de Funil, Pathfinder. Permite criar eventos virtuais a partir de combinações de eventos reais. Integra-se com mais de 50 ferramentas através do Segment.

Segment (a partir de $120/mês)

Segment é um middleware para gerenciamento de eventos. Você envia eventos para o Segment, e ele os distribui para mais de 300 ferramentas. Útil em ambientes empresariais onde Firebase, Amplitude, Mixpanel, Braze e Salesforce são usados simultaneamente.

PostHog (alternativa open-source)

PostHog é uma plataforma de análise de produto open-source com seu próprio Event Tracking. Suporta captura automática de eventos, gravação de sessões e feature flags. É implantado em seu próprio servidor, o que é crítico para projetos com GDPR ou dados confidenciais. Fornece uma API compatível com Python para pipelines ETL.

Para projetos Flutter, recomenda-se flutterfire_analytics + Amplitude através do plugin amplitude_flutter. Para React Native — react-native-firebase + mixpanel-react-native.