Analytics no app: como medir tela, acao e funil sem poluir o React Native

Muito app corporativo entra em producao sem uma resposta simples para perguntas importantes: que telas as pessoas realmente usam? em que etapa do fluxo elas abandonam? qual acao gera valor de negocio de verdade? quando a equipe diz que uma funcionalidade ajudou, existe evidencia ou so impressao? Na ausencia dessa leitura, o time tanto pode navegar no escuro quanto cair no erro oposto: instrumentar clique demais, mandar evento demais e transformar analytics em ruido espalhado pelo projeto.

Em React Native, analytics nao deveria nascer como enfeite. Ele precisa conversar com navegacao, API, sessao, rollout, observabilidade e privacidade. Se o desenho nasce ruim, o app mede o tap no botao em vez do sucesso real da operacao, duplica screen view, mistura usuario interno com visitante, polui o codigo e ainda deixa suporte sem contexto acionavel.

Este guia organiza uma abordagem pratica para analytics em app corporativo com React Native: taxonomia de eventos, screen tracking, user properties, user ID, validacao em DebugView e relacao entre funil de produto e comportamento confirmado pelo backend.

1. Analytics nao e o mesmo que observabilidade

Antes de instrumentar qualquer SDK, vale separar dois mundos que frequentemente se misturam:

• observabilidade: erro, crash, latencia, release, contexto tecnico e investigacao operacional;
• analytics de produto: tela visitada, acao concluida, uso de funcionalidade, conversao de fluxo e comportamento agregado.

Os dois se ajudam, mas nao fazem a mesma coisa. O artigo observabilidade do app em producao ja cobre crash, release e sinais tecnicos. Aqui o foco e medir uso e funil sem transformar analytics em um log paralelo de tudo o que o app faz.

2. Comece pelas perguntas de negocio e operacao

O erro mais comum e abrir o SDK e sair disparando evento para qualquer toque. Antes disso, liste o que o time realmente quer responder. Exemplos uteis em app corporativo:

• quais telas sustentam o uso recorrente?
• em que passo um cadastro ou checklist trava?
• quantas pessoas abriram um fluxo e quantas terminaram com sucesso?
• que funcionalidade nova foi de fato usada depois do rollout?
• qual perfil de usuario usa determinada area com frequencia?

Quando as perguntas ficam claras, a instrumentacao ganha foco. Sem isso, o projeto coleta uma pilha de eventos que nao ajuda decisao nenhuma.

3. Taxonomia de eventos vale mais do que volume de eventos

Analytics bom nasce de nomes consistentes. Analytics fraco vira colecao de verbos aleatorios espalhados pelo codigo. Uma taxonomia minima ajuda bastante:

• eventos de navegacao: tela aberta, fluxo iniciado, detalhe visualizado;
• eventos de engajamento: filtro aplicado, aba usada, item salvo como rascunho;
• eventos de operacao: checklist enviado, anexo confirmado, sincronizacao concluida;
• eventos de erro de produto: fluxo bloqueado por validacao, permissao negada, fila pausada;
• eventos de rollout e experimento: recurso liberado, grupo de flag, comportamento alternativo.

O objetivo nao e ter centenas de eventos. E tornar previsivel o que cada nome representa, com parametros comparaveis entre versoes.

4. Use eventos recomendados quando fizer sentido e complete com eventos proprios

A documentacao do Firebase Analytics recomenda registrar os eventos recomendados que facam sentido para o app e usar os parametros prescritos para ganhar relatorios mais ricos e compatibilidade com recursos da plataforma. Ela tambem permite eventos customizados quando a necessidade nao se encaixa no conjunto recomendado.

Em app corporativo, isso leva a uma regra simples:

• usar evento recomendado quando o caso couber com clareza;
• criar evento proprio quando o fluxo for especifico do produto;
• padronizar parametros em vez de inventar nomes novos para a mesma ideia.

Isso e melhor do que usar evento generico para tudo ou criar um dialeto indecifravel de analytics sem qualquer consistencia.

5. Nao meca clique quando o que importa e resultado confirmado

Se o usuario toca em enviar, mas a API falha, o negocio nao ganhou uma conclusao real. Por isso, em varios fluxos o evento importante nao nasce no clique do botao. Ele nasce no sucesso confirmado da operacao.

Exemplos:

• nao registrar envio concluido no tap do CTA, mas sim depois da resposta valida da API;
• nao registrar upload completo antes de o backend confirmar o anexo;
• nao contar checklist finalizado quando ele ficou apenas salvo em rascunho;
• separar inicio de fluxo, tentativa e sucesso.

Essa disciplina aproxima analytics do artigo Google Ads, UTM e formulario de contato, em que a conversao do site tambem depende do momento correto do disparo.

6. Screen tracking em React Native pede intencao

A documentacao do Firebase explica que Analytics pode registrar automaticamente algumas informacoes de tela e que, quando ocorre transicao de tela, um evento screen_view identifica a nova tela. Ela tambem deixa claro que screenviews podem ser registrados manualmente, o que e util quando o app nao usa uma Activity ou ViewController separado para cada tela que voce quer medir.

Esse ponto importa muito em React Native. A documentacao do React Navigation mostra um caminho pratico para screen tracking usando onStateChange no NavigationContainer, leitura da rota ativa e comparacao com a rota anterior. Ela tambem avisa que onStateChange nao roda no render inicial, entao a tela inicial precisa ser tratada separadamente.

Em outras palavras:

• o app precisa saber qual rota atual ficou ativa;
• nao deve disparar screen view duplicado a cada rerender;
• a tela inicial precisa de tratamento proprio;
• navegacao aninhada pede cuidado para descobrir a rota efetivamente visivel.

Screen tracking mal desenhado cria relatórios inflados e faz parecer que o produto usa mais telas do que realmente usa.

7. Parametro de evento, user property e user ID nao sao a mesma coisa

Esses tres conceitos costumam se confundir, mas resolvem problemas diferentes:

• parametro de evento: contexto daquele acontecimento especifico;
• user property: atributo mais estavel do usuario ou do contexto dele;
• user ID: identificador controlado pela sua organizacao para ligar eventos do mesmo usuario entre contextos suportados.

A documentacao do Firebase sobre user properties informa que elas descrevem segmentos da base, como preferencia de idioma ou localizacao, e que podem ser usadas em audiences. A mesma pagina tambem informa que e possivel configurar ate 25 user properties por projeto. Isso por si so ja ajuda a evitar exagero: user property e para contexto mais duradouro, nao para qualquer detalhe de tela.

8. User ID exige cuidado com privacidade

A documentacao do Firebase sobre user ID e bem direta: o uso e opcional, serve para associar analytics de um mesmo usuario entre contextos e nao pode conter informacao pessoal identificavel que terceiros consigam usar para descobrir quem e a pessoa. A propria documentacao cita que e melhor usar um identificador interno, ou ate uma versao derivada dele, do que e-mail ou outro dado pessoal direto.

Em app corporativo, isso leva a algumas regras saudaveis:

• nao usar e-mail como user ID no analytics;
• preferir identificador interno do sistema, sem exposicao pessoal direta;
• registrar em politica de privacidade o uso de identificadores e medicao;
• separar claramente identificacao para analytics de autenticacao de negocio.

Se a equipe nao precisa dessa correlacao mais profunda, o proprio Firebase lembra que o user_pseudo_id gerado automaticamente ja resolve muitos cenarios de leitura por dispositivo.

9. User properties devem ser poucas e realmente uteis

Como user properties sao limitadas e mais estaveis, vale reservar esse recurso para dimensoes que ajudam comparacao de uso, como:

• perfil ou tipo de conta;
• plataforma;
• ambiente ou canal de distribuicao;
• fase de rollout;
• tenant ou agrupamento interno quando houver politica adequada.

O que nao vale e transformar cada detalhe de fluxo em user property. Estado de tela, botao clicado e tentativa momentanea normalmente combinam muito mais com parametro de evento.

10. Default parameters ajudam a manter contexto consistente

A documentacao do Firebase tambem destaca que parametros padrao podem ser associados a todos os eventos futuros, e substituidos quando um evento especifico informa valor proprio. Isso e util para evitar repeticao manual quando certos contextos devem viajar com grande parte da telemetria.

Em app corporativo, isso pode fazer sentido para atributos como:

• versao do app;
• canal de release;
• grupo de rollout;
• tenant atual quando a politica permitir;
• ambiente ou modulo principal.

O importante e nao exagerar. Parametro default bom reduz duplicacao. Parametro default em excesso contamina tudo e dificulta a leitura.

11. Analytics precisa conversar com feature flags, offline e release

Depois dos artigos sobre feature flags e configuracao remota, persistencia local e background task, a ligacao fica clara: analytics nao mede so o fluxo bonito da rede perfeita. Ele tambem precisa dizer em que contexto o app estava operando.

Isso inclui perguntas como:

• o usuario estava em grupo de rollout diferente?
• a funcionalidade estava ligada por feature flag?
• a acao foi concluida online ou ficou em fila local?
• o app estava em versao antiga, mas ainda suportada?

Sem esse contexto, o time enxerga numero agregado e nao entende por que parte da base se comportou de forma diferente.

12. DebugView e fase obrigatoria de validacao

A documentacao do Firebase sobre DebugView informa que essa visao permite enxergar os eventos brutos enviados por dispositivos de desenvolvimento quase em tempo real. Ela tambem explica por que isso e importante: validacao de instrumentacao, descoberta de erro e confirmacao de que eventos e user properties estao sendo registrados corretamente.

Outro ponto valioso da mesma documentacao e que, em modo debug, os eventos usados nessa validacao ficam fora dos dados gerais de Analytics e nao entram na exportacao diaria para BigQuery. Isso protege a leitura de producao enquanto a equipe ajusta o rastreamento.

Em resumo, DebugView deveria entrar no checklist de qualquer implementacao de analytics mobile, nao como luxo, mas como etapa basica de confianca.

13. Nao misture analytics com log de debug permanente

Quando um time fica inseguro, ele tenta compensar instrumentando tudo no analytics. O problema e que analytics nao foi feito para substituir log de investigacao tecnica. Alguns sinais devem morar em observabilidade, outros em analytics de produto.

Uma forma pratica de separar:

• erro tecnico detalhado, stack e latencia: observabilidade;
• uso de recurso, etapa de fluxo e conversao: analytics;
• status operacional que ajuda os dois lados: pode aparecer nos dois, em formatos diferentes.

Essa divisao deixa o app mais limpo e tambem melhora governanca de dados.

14. Um checklist pratico de instrumentacao

1. Listar perguntas reais de negocio e operacao.
2. Definir poucos eventos essenciais por fluxo.
3. Nomear eventos e parametros com taxonomia consistente.
4. Separar inicio, tentativa, sucesso e erro quando fizer sentido.
5. Implementar screen tracking sem duplicar screen view.
6. Usar user properties apenas para contexto estavel.
7. Evitar PII em user ID e parametros.
8. Validar tudo em DebugView antes de confiar nos relatorios.
9. Revisar a cada release se os eventos ainda respondem as perguntas certas.

15. Erros comuns

• medir clique em vez de resultado confirmado;
• disparar screen view a cada rerender;
• usar e-mail como user ID;
• transformar qualquer detalhe em user property;
• misturar analytics de produto com log tecnico de erro;
• instrumentar evento sem plano de leitura posterior;
• validar so em producao sem passar por DebugView;
• deixar feature flag e rollout fora do contexto analitico.

16. Quando vale um diagnostico tecnico

Se o app ja roda em producao, mas a equipe nao consegue responder o que e usado, onde o funil quebra, como um rollout afetou comportamento ou se os sinais de produto estao coerentes com a API e com a operacao real, talvez a instrumentacao precise de desenho, nao apenas de SDK. Nessa hora, um diagnostico tecnico ajuda a revisar a taxonomia, a relacao entre app e backend e a fronteira entre analytics, observabilidade e privacidade.

Analytics bom nao e o que mede mais coisas. E o que mede as coisas certas, no momento certo, com nomes consistentes e contexto suficiente para virar decisao.

Referencias editoriais: Firebase Analytics - Log events, Firebase Analytics - Measure screenviews, Firebase Analytics - Set user properties, Firebase Analytics - Set a user ID, Firebase Analytics - Debug events e React Navigation - Screen tracking for analytics.