CRBRASIL
Analytics

Analytics de aplicativo: como estruturar telas, eventos e identidade quando o app usa vários SDKs

Por CRO Brasil ·

Analytics de aplicativo: como estruturar telas, eventos e identidade quando o app usa vários SDKs

O app tem Firebase, CleverTap, UXCam e Clarity. Cada um chama a mesma tela por um nome diferente. Veja como organizar a mensuração mobile para que os dados conversem.

Índice do artigo

O que muda da web para o app

No app não existe Google Tag Manager distribuindo tags nem camada de dados global da mesma forma que na web. Cada ferramenta entra como SDK compilado no aplicativo, cada atualização depende de uma nova versão publicada na loja, e o usuário pode ficar semanas numa versão antiga. Um erro de nomenclatura na web se corrige em minutos; no app, pode conviver com você por meses.

Em uma frase: em app, a mensuração precisa estar certa antes da publicação, porque corrigir custa um ciclo de release.

Camada de abstração: um tracker, vários SDKs

O equivalente mobile da camada de dados é um módulo interno de tracking. O código do app chama apenas esse módulo (ex.: tracker.event('add_to_cart', props)), e ele repassa para cada SDK:

  • Firebase/GA4: evento com os parâmetros recomendados;
  • CleverTap: pushEvent (Android) ou event.push, com as propriedades aceitas;
  • UXCam: logEvent;
  • Clarity: evento pela API do SDK mobile.

Vantagens: um só lugar para mudar nomes, adicionar ou remover ferramentas e aplicar regras de consentimento. É o mesmo princípio do dicionário de eventos (Dicionário de eventos).

Telas: nomes estáveis antes de tudo

Heatmaps, funis e replays mobile dependem do nome da tela. Nomeação automática, baseada em classe ou componente, muda a cada refatoração e quebra a série histórica. A própria documentação da UXCam para React Native recomenda desativar a nomeação automática e marcar as telas manualmente.

Boa prática: mantenha uma lista oficial de telas no dicionário, com o mesmo nome no screen_view do GA4/Firebase, na UXCam e nas demais ferramentas.

Eventos: o mesmo dicionário da web

Use os mesmos nomes de evento da web sempre que a ação for a mesma (add_to_cart é add_to_cart no site e no app). Atenção às regras de cada SDK:

  • CleverTap: chaves de propriedade em texto e valores escalares ou data; até 512 tipos de evento por conta.
  • UXCam: até 100 propriedades por usuário, com números enviados como texto.
  • Clarity (Flutter): Smart Events, Funis e Components ainda não são suportados nesse SDK.

Eventos que acontecem fora do app (pagamento aprovado, pedido faturado) devem entrar pelo servidor, como pela Upload Events API da CleverTap.

Identidade: Install ID x User ID

Todo SDK mobile cria um identificador por instalação. Ele se perde quando o usuário reinstala o app, troca de aparelho ou divide o dispositivo. A solução é o User ID (User ID):

  • UXCam: setUserIdentity uma vez por sessão, depois da inicialização do SDK; o vínculo com o Install ID persiste.
  • CleverTap: onUserLogin no login e no cadastro. No Android, a documentação alerta para não chamar onUserLogin diretamente no onCreate.
  • Clarity (Flutter): setCustomUserId, com identificadores entre 1 e 255 caracteres.

Frameworks: React Native, Expo e Flutter

  • React Native: SDKs como o da UXCam são instalados via npm/yarn, com pod install no iOS.
  • Expo: SDKs com código nativo exigem EAS Build; o fluxo gerenciado puro não basta.
  • Flutter: o Clarity tem o pacote clarity_flutter; verifique sempre quais recursos estão disponíveis no SDK Flutter de cada ferramenta, que costuma ter menos funcionalidades que o nativo. No Clarity Flutter, por exemplo, o upload de sessões offline ainda não é suportado.

Ambientes, builds e QA

  • Separe ambientes: a UXCam permite marcar o ambiente como alpha, beta ou release no iOS, facilitando filtrar sessões de teste.
  • Use builds de debug para validar: logs de integração (como o log da UXCam no Logcat) confirmam se as chamadas estão acontecendo.
  • Checklist por release: telas novas nomeadas, eventos novos no dicionário, identificação testada com conta de teste, mascaramento revisado.

Privacidade no app

  • Mascare telas de login, cadastro e pagamento (a UXCam configura occlusion na inicialização do SDK; Mascaramento de dados sensíveis em session replay).
  • Ligue o consentimento do app às APIs dos SDKs: a CleverTap tem as flags optOut e useIP; o Clarity Flutter tem um método consent para ads e analytics (no iOS, apenas o de analytics tem efeito).
  • Não envie dado pessoal em nome de tela ou evento.

Os erros que mais aparecem

  1. Nomeação automática de telas.
  2. Cada SDK chamado direto do código, sem camada de abstração.
  3. Identificação só no primeiro login, sem repetição por sessão.
  4. Builds de teste misturados com produção.
  5. SDK Flutter ou React Native usado sem checar recursos não suportados.

Perguntas frequentes

Como medir um aplicativo?

Com eventos e telas definidos num dicionário único, um módulo interno de tracking que repassa para cada SDK, identificação por User ID e validação antes de cada release.

Qual a diferença entre analytics web e mobile?

No app, cada ferramenta é um SDK compilado e correções dependem de nova versão na loja; na web, o GTM permite ajustes imediatos.

Como evitar nomes de tela diferentes entre ferramentas?

Nomeando as telas manualmente com uma lista oficial usada em todos os SDKs.

Session replay funciona em Flutter?

Sim, o Microsoft Clarity tem SDK Flutter, com algumas limitações de recursos em relação ao nativo.

Preciso de EAS Build para usar SDKs de analytics no Expo?

Para SDKs com código nativo, como o da UXCam, sim.

Como identificar usuários em app?

Chamando a identificação de cada SDK com o mesmo User ID após login ou cadastro, e repetindo a cada sessão.