LGPD no App: Como Coletar Telemetria sem Violar os Direitos do Usuário

Contexto

No cold start, o app dispara Firebase Analytics, Crashlytics, Adjust ou Sentry — muitas vezes antes de qualquer tela de privacidade. Para o dev, é "só telemetria". Para a LGPD, cada hit pode ser dado pessoal.

Identificadores como IDFA (iOS), GAID (Android), IP, token de instalação e device ID não são "técnicos demais para contar". Se permitem reidentificar alguém ou montar perfil comportamental, entram no Art. 5º da LGPD.

Além da lei, as lojas impõem regras próprias: Apple exige App Tracking Transparency (ATT) e Privacy Manifests; Google exige a seção Data Safety na Play Store. Declarar uma coisa na loja e o SDK fazer outra no código é receita para rejeição do app — e notificação da ANPD.

O objetivo deste guia é operacional: classificar o que você coleta, escolher a base legal certa e desenhar uma arquitetura que dev e PM consigam implementar sem whitepaper jurídico.

Problema

Três erros aparecem em quase todo app que audito:

O controlador do app responde pelo que o SDK envia — mesmo que você não tenha lido o payload. Integrar Firebase ou Adjust no Application.onCreate() sem gate de consentimento não transfere a responsabilidade para o vendor.

Há também uma distinção que jurídico e engenharia costumam confundir: logs de acesso (Marco Civil, Art. 15) não são a mesma coisa que telemetria de produto. O primeiro é obrigatório por lei (IP, data/hora, duração — mínimo 6 meses). O segundo segue LGPD, minimização e base legal explícita.

Mapa de telemetria

Antes de discutir SDK, mapeie cada evento que sai do app:

Se o evento não cabe em nenhuma linha, pare. Evento sem classificação não sobe para produção.

Base legal na prática

Quando legítimo interesse funciona

Crash reports, métricas de latência, consumo de memória e erros de rede costumam se encaixar em legítimo interesse — desde que:

• a finalidade seja concreta ("corrigir crash na tela X"), não genérica ("melhorias futuras");
• você colete o mínimo (sem PII no stack trace);
• exista opt-out simples nas configurações do app.

A ANPD, no guia de cookies, reconhece que ferramentas de medição imprescindíveis ao funcionamento podem usar legítimo interesse com transparência e opção de oposição.

Quando exige consentimento

Ative consentimento (e no iOS, o prompt ATT) quando o fluxo envolve:

• IDFA ou GAID para ads/remarketing;
• rastreamento entre apps ou sites;
• profiling para publicidade direcionada;
• compartilhamento com data brokers.

Sem opt-in, o SDK até pode disparar — mas o tratamento é irregular.

Para entender por que hash de device ID não resolve o problema sozinho:

Guia de anonimização e privacidade em analytics mobile e web

Teste de balanceamento (LIA) em 3 passos

Para telemetria baseada em legítimo interesse, documente um LIA simplificado antes de liberar evento novo:

1. Finalidade

Responda: "Este dado resolve qual problema técnico concreto?"

Ruim: "Coletar métricas para eventuais melhorias." Bom: "Identificar crash em CheckoutActivity na versão 2.4.1 com Android 14."

2. Necessidade

Responda: "Existe forma menos invasiva de chegar ao mesmo diagnóstico?"

Se dá para usar contadores agregados ou excluir identificador persistente, faça. Coletar IMEI para saber que a tela travou é desproporcional.

3. Balanceamento

Pondere interesse do controlador vs expectativa do usuário. Salvaguardas mínimas:

• pseudonimização na origem;
• prazo de retenção curto (30–90 dias para crash);
• opt-out visível;
• criptografia TLS 1.3 em trânsito.

Registre isso no RoPA (Registro de Operações, Art. 37). Evento no código sem linha no RoPA é dívida de compliance.

Arquitetura técnica

Traduza Privacy by Design (Art. 46) em pipeline:

1. Evento no app — dispara localmente.
2. Filtro de minimização — remove PII, trunca IP, substitui device ID por token salgado.
3. Gate de consentimento — ads/IDFA só passam com opt-in; crash segue com LI + opt-out.
4. Destinos separados — logs MCI em storage isolado (6 meses); analytics em ambiente distinto.

No iOS, o gate de ads passa pelo prompt nativo do ATT. No Android, controle GAID via APIs de advertising ID e painel in-app.

Técnicas que funcionam na prática:

• Hash salgado com rotação — substitui identificador direto por token de via única; rotaciona o salt periodicamente.
• Edge processing — agrega contadores no device antes de enviar (ex.: "3 telas visitadas" em vez de log linha a linha).
• IP anonymization — truncar ou descartar IP antes de persistir no vendor.

Governança de SDKs

Firebase Analytics, Crashlytics, Adjust, Sentry e Mapbox são controlados por você na qualidade de controlador — não de "usuário passivo do vendor".

Checklist de auditoria:

1. Proxy de tráfego — Charles, mitmproxy ou Proxyman na build de debug; inspecione payload na primeira abertura.
2. Desabilitar auto-collect — setAnalyticsCollectionEnabled(false) até consentimento; equivalentes nos MMPs.
3. Suprimir IDFA/GAID — não inicialize módulos de ads sem opt-in.
4. Alinhar manifestos — PrivacyInfo.xcprivacy (iOS) e Data Safety (Android) devem refletir o tráfego real.
5. Contratos — SCCs ou cláusulas adequadas se o vendor processa fora do Brasil (Art. 33).

Para o passo técnico de configuração de SDKs:

Firebase e SDKs mobile: guia curto para tech leads

Consentimento no app

No mobile, espaço de tela é curto — use aviso em camadas, como recomenda a ANPD:

Primeiro nível (banner no onboarding):

• resumo claro das finalidades;
• botões com igual destaque visual: "Aceitar todos", "Rejeitar não necessários", "Gerenciar preferências";
• nada de botão verde gigante para aceite e link escondido para recusar.

Segundo nível (painel de preferências):

• categorias separadas: Essencial, Analytics, Publicidade;
• toggles desligados por padrão para tudo que depende de consentimento;
• revogação permanente em Configurações → Privacidade.

Os padrões de consentimento em camadas na web seguem a mesma lógica:

Consent Mode v2 sem quebrar métricas no GA4

Exigências das lojas

Rejeição na loja costuma ser o primeiro sinal. Notificação da ANPD é o segundo — e mais caro.

Checklist rápido

Próximo passo

Telemetria compliant não é "desligar analytics". É separar fluxos, documentar bases legais e provar que o que está na loja é o que roda no app.

Use o checklist acima como diagnóstico interno. Se você está subindo evento novo ou herdou um app com cinco SDKs no init, o movimento seguinte é mapear inventário, auditar tráfego e redesenhar a pipeline com gates de consentimento — antes da próxima release ou revisão da loja.

Se quiser uma leitura externa da implementação, peça uma auditoria de eventos app/web: o objetivo é medir com utilidade técnica e sair do risco de compliance cosmético.