Fale Conosco

Firebase Analytics vs. AppsFlyer: Qual Escolher para Seu Aplicativo?

Fábio Oliveira

Firebase é telemetria de produto; AppsFlyer é MMP. Quando só o primeiro basta, quando o híbrido paga UA multi-canal — e por que DAU nunca bate.

Contexto

Growth pergunta: “a gente precisa de AppsFlyer ou o Firebase já cobre?” Eng responde que o SDK do Google já está no app. Mídia olha o Meta e o TikTok e vê instalação “orgânica” no GA4. Produto abre o funil in-app e o MMP não tem a tela de onboarding.

Não é empate de features. São dois jobs. Firebase Analytics (GA4 for Apps) mede o que acontece dentro do produto. AppsFlyer — e outros MMPs — mede de onde veio o usuário pago, com regras que as redes aceitam como auditoria. Tratar um como substituto do outro é o atalho que deixa ROAS cego ou o warehouse vazio.

O cenário também mudou: ATT e o fim do identificador fácil no iOS; Privacy Sandbox no Android; e os Firebase Dynamic Links encerrados em agosto de 2025. Deep link “de graça no Firebase” não é mais opção. Este guia é a regra de decisão para PM/Growth — e o mapa que mídia e eng precisam assinar juntos.

Dois paradigmas (não um ranking)

Firebase Analytics é product analytics first-party. Eventos e user properties, retenção, integração com Remote Config, A/B e FCM. Export contínuo para BigQuery sem taxa de licença do Analytics em si. Atribuição nativa forte no Google Ads; fora disso, Meta/TikTok/Apple Search Ads costumam aparecer genéricos ou incham orgânico.

AppsFlyer é Mobile Measurement Partner. Clique/impressão → install → evento pós-install em dezenas de redes, com janelas e modelos que UA usa para CPA/ROAS. Protect360 tenta barrar fraude (TTI anômalo, hijack, farms) antes de você pagar o install. OneLink cobre deep link direto e deferred (contexto depois da loja) — o buraco que o FDL deixou.

Outros MMPs (Adjust, Branch, etc.) ocupam o mesmo assento de atribuição. A comparação aqui é Firebase vs AppsFlyer porque é o par que mais aparece na mesa brasileira: “já temos Firebase, será que precisa pagar MMP?”

O que o Firebase faz bem

  • Instrumentação inicial barata: first_open, telas, engagement_time_msec, versão do app.
  • Funil de produto: tutorial, paywall, purchase in-app — no mesmo modelo de evento do GA4.
  • Warehouse: evento cru no BigQuery para coorte, churn, LTV se você tiver engenharia de dados.
  • Operação do app: Remote Config e mensagens no mesmo ecossistema Google.

Limites que doem em UA:

  • Atribuição multi-canal opaca.
  • Relatórios da consola rasos até você declarar dimensão custom ou ir ao SQL.
  • Sem suíte de fraude de mídia nem OneLink.
  • Links dinâmicos nativos: serviço morto (FDL retorna 404). Quem ainda aponta campanha para *.page.link está quebrado.

SDK no Application.onCreate() sem gate de consentimento continua sendo problema de LGPD e telemetria — Firebase “grátis” não isenta o controlador.

O que o AppsFlyer faz bem

  • Fonte única de verdade para install pago em Meta, Google, TikTok, ASA, afiliados.
  • Antifraude (Protect360) como linha de defesa do budget, não como “relatório depois”.
  • OneLink: um URL, app instalado ou não; deferred deep link depois que o FDL sumiu.
  • Export log-level (API, webhook, ETL) para cruzar com o resto do stack.

O que ele não substitui: mapa fino de telas, Remote Config, export BigQuery gratuito do Firebase, nem o modelo mental de produto. Usar só MMP e “ver o app pelo dashboard de mídia” deixa growth cego no meio do funil. Em React Native e Flutter, tela automática do Firebase mente — instrumentação no router: tagueamento RN e Flutter.

Custo: planos por conversão e contrato enterprise — consulte o vendor; não trate um preço de blog como tabela oficial.

Por que DAU e install nunca batem

Reunião clássica: AppsFlyer mostra mais usuários ativos que o Firebase (às vezes a diferença é grande). Quase nunca é “SDK mal instalado”.

  • Foreground: Firebase conta ativo se houve evento com a UI visível. Init em background (push silencioso, sync) não entra. O MMP costuma contar no boot do SDK, tela ou não.
  • Reinstall: MMP pode reatribuir (janela de inatividade) como nova conversão paga. Firebase reconhece returning / não dispara first_open de novo.
  • Fuso e janela de atribuição diferentes entre painéis e redes.

Não force os dois números a coincidir. Defina qual ferramenta é a fonte para cada KPI: install/ROAS no MMP; DAU de produto e retenção no Firebase (ou no BQ).

Arquitetura híbrida (o padrão com UA paga)

  1. Clique/OneLink → AppsFlyer atribui e filtra fraude.
  2. No primeiro open, o app lê metadados (rede, campanha, adset, criativo) e grava user properties / parâmetros de sessão no Firebase.
  3. Daí em diante, telemetria de produto (onboarding, feature, receita) já nasce com canal.
  4. BigQuery junta evento Firebase enriquecido → LTV e retenção por campanha, sem pedir isso ao dashboard do MMP.

Sem o passo 2, você tem dois silos: mídia otimiza install; produto otimiza tela; ninguém fecha o ciclo.

Como decidir

Só Firebase faz sentido se:

  • early stage, budget apertado;
  • crescimento orgânico / ASO / Google Ads como canal dominante;
  • prioridade é product-market fit e funil in-app, não auditoria multi-rede.

Firebase + MMP (AppsFlyer ou equivalente) quando:

  • spend relevante em Meta, TikTok, ASA, afiliados;
  • você precisa de ROAS auditável e antifraude;
  • deep/deferred link é jornada real (e o FDL não volta).

ATT, SKAN e AdAttributionKit mudam a precisão no iOS — implementação (conversion value, postbacks, S2S) está em tracking pós-ATT. O recado de privacidade: não desenhe UA como se IDFA fosse o default; ver anonimização e privacidade.

Checklist

  1. Job documentado: produto no Firebase; atribuição paga no MMP (se houver UA multi-canal).
  2. Ninguém usa FDL / page.link em campanha viva.
  3. Se há MMP: canal/campanha fluem para user properties no Firebase no primeiro open.
  4. KPI de DAU tem uma fonte; discrepância explicada (foreground vs init), não “bug”.
  5. Consent/ATT antes de ads ID e auto-collect — telemetria no app.
  6. BigQuery ligado se vocês vão cruzar LTV × campanha.
  7. Fraude: se o install pago escala, Protect360 (ou equivalente) não é “nice to have”.
  8. Preço do MMP revisado no contrato, não copiado de comparativo antigo.

Próximo passo

A escolha errada não é “pagar AppsFlyer”. É achar que o Firebase atribui TikTok, ou que o MMP substitui o funil de produto. Com UA paga, o desenho é híbrido; com orgânico e Google, Firebase aguenta o começo.

Se o app já tem os dois SDKs e os números brigam toda segunda, o trabalho é mapa de ownership + passagem de campanha para o Firebase — não mais um dashboard.

Se quiser, partimos do seu stack (Firebase só vs Firebase + MMP) e fechamos: o que cada time olha, o que para de ser “orgânico misterioso” e o que precisa de evento in-app de verdade. Mapa de eventos para AEO/VO nas redes: eventos in-app para campanhas de install.