Ao integrar um SDK de mediação SaaS típico, seu fluxo de eventos — cada solicitação de anúncio, cada impressão, cada identificador de usuário — é enviado primeiro aos servidores do fornecedor. Ele processa os dados, enriquece as informações e, às vezes, devolve ao seu data warehouse uma cópia com informações sensíveis removidas. Quando você finalmente acessa os dados, eles já passaram por um sistema que você não controla.
Um SDK nativo do Firebase funciona no sentido inverso. Os eventos são gravados primeiro no seu próprio Firestore e BigQuery. O fornecedor lê os dados do seu projeto, e não o contrário. A diferença parece teórica até a primeira auditoria de GDPR.
O que muda quando seu projeto tem o controle dos dados
- Solicitações de exclusão se resolvem com uma única consulta no Firestore — sem chamado para o fornecedor, sem SLA
- Os custos do BigQuery são previsíveis, porque você controla o esquema de exportação
- As migrações de esquema seguem seu cronograma, não as notas de versão do fornecedor
- A lista de suboperadores que você precisa declarar diminui, muitas vezes drasticamente
As contrapartidas que ninguém menciona na reunião de vendas
Ser nativo do Firebase não significa ser gratuito. Você paga ao Google pelo armazenamento e pelas consultas que, de outra forma, ficariam a cargo do fornecedor. Para um app com 5 milhões de DAU, a conta do BigQuery fica entre US$ 400 e US$ 1.200 por mês — um valor relevante, mas quase um erro de arredondamento diante da receita de anúncios que ele protege.
Você também precisa pensar nas cotas. Gravações por segundo no Firestore, inserções via streaming no BigQuery e inicializações a frio de Cloud Functions são limitações reais que um SDK SaaS absorve sem que você perceba. O Apps Kit SDK inclui uma camada de controle de fluxo (backpressure) que agrupa gravações em lotes para manter a maioria dos apps com menos de 1 milhão de DAU dentro das cotas do nível gratuito.
Quanto você realmente paga ao Google
O modelo de custos não tem surpresas, e essa é a ideia: cada item pode ser acompanhado no seu próprio console de faturamento. Estas são as faixas que observamos em implementações ativas do Apps Kit SDK em 2026, já considerando a camada de backpressure e a expiração das partições do BigQuery após 90 dias, que configuramos por padrão.
- 1 milhão de DAU: Firestore US$ 40–90, armazenamento no BigQuery US$ 20–50, consultas no BigQuery US$ 30–80, Cloud Functions US$ 10–30 — total abaixo de US$ 250/mês
- 5 milhões de DAU: Firestore US$ 180–350, armazenamento no BigQuery US$ 100–220, consultas no BigQuery US$ 120–400, Cloud Functions US$ 40–110 — total de US$ 400–1.200/mês
- 25 milhões de DAU: Firestore US$ 700–1.400, armazenamento no BigQuery US$ 450–900, consultas no BigQuery US$ 500–1.800, Cloud Functions US$ 150–400 — total de US$ 1.800–4.800/mês
Ajustes de custo que realmente fazem diferença na conta
A maior parte da variação acima vem de três decisões. Primeiro, inserir dados via streaming no BigQuery ou em lotes pelo GCS — o processamento em lotes reduz o custo de ingestão em 80% ou mais, em troca de um atraso de 30 minutos nos relatórios. Segundo, a expiração das partições — 90 dias cobrem todas as consultas operacionais de que já precisamos; dados brutos mais antigos devem ir para armazenamento de acesso infrequente. Terceiro, boas práticas de consulta — um único dashboard com um SELECT * sem limites sobre um ano de impressões pode custar mais do que todo o restante somado.
Por que isso importa ainda mais em 2026
Duas mudanças regulatórias alteraram essa conta neste ano. Os requisitos de portabilidade de dados do DMA agora se aplicam a qualquer fornecedor que processe dados de usuários finais da UE, e o prazo para adequação à fiscalização do DPDP indiano terminou em março. Ambos os regimes pressupõem que você consiga gerar, sob demanda, uma exportação completa de todos os eventos vinculados a um usuário.
Se o fornecedor do seu SDK é a fonte oficial dos dados, você depende das ferramentas de exportação dele. Se o seu projeto Firebase é a fonte oficial, a exportação é uma consulta que você já sabe escrever.
Como uma auditoria de GDPR / DPDP acontece na prática
Quando um órgão regulador ou um grande cliente corporativo solicita uma auditoria, ele quer quatro itens: uma lista de todos os suboperadores que lidam com dados de usuários finais, uma exportação completa dos dados de um usuário específico, um comprovante de exclusão e uma descrição da sua política de retenção. Com um SDK SaaS, você obtém o primeiro lendo a documentação do fornecedor, os dois seguintes abrindo chamados e o quarto na base da suposição.
Com uma arquitetura nativa do Firebase, os quatro itens podem ser obtidos por consultas sob seu controle. Suboperadores: lista dos serviços do GCP no seu projeto. Exportação de dados do usuário: uma consulta no Firestore e outra no BigQuery, ambas incluídas como modelos no SDK. Comprovante de exclusão: uma Cloud Function que retorna a contagem de registros afetados. Retenção: sua política de expiração de partições, visível no console. A auditoria deixa de ser uma correria de duas semanas e passa a ser uma tarefa de meio dia.
Como migrar de um SDK SaaS sem comprometer a atribuição
A migração que assusta as equipes é aquela que elas imaginam fazer em uma única versão do app. Não fazemos assim. O SDK nativo do Firebase é implantado junto com o SDK SaaS existente por duas a quatro semanas, gravando no novo pipeline enquanto o antigo continua alimentando todos os dashboards e MMP já utilizados.
- Semana 1: integre o SDK nativo do Firebase em modo sombra, sem mudanças visíveis para o usuário, e valide a paridade dos eventos no BigQuery
- Semana 2: redirecione os postbacks de atribuição para o fluxo nativo do Firebase e mantenha a mediação no SDK antigo
- Semana 3: migre a mediação e mantenha o SDK SaaS enviando eventos apenas para consulta, como referência em caso de divergência
- Semana 4: remova o SDK SaaS na próxima atualização do app, eliminando qualquer dependência dele
Quando o SaaS ainda é a melhor opção
Se sua equipe não usa Firebase e não pretende adotá-lo, a carga operacional adicional de um SDK nativo do Firebase é real. A mediação SaaS é a escolha certa para estúdios que querem integrar e não se preocupar mais, e para protótipos em que o controle dos dados ainda não é um ativo estratégico. A decisão não é técnica — trata-se de quem você quer que controle a trilha de auditoria.
Ter o controle do fluxo de eventos não é uma declaração de compromisso com a privacidade. É a diferença entre negociar seu próximo contrato com um fornecedor em uma posição de força ou tendo apenas uma captura de tela em mãos.
O que fazer neste trimestre
Se você já usa Firebase Analytics, está a 60% do caminho para adotar um SDK de anúncios nativo do Firebase e provavelmente nem percebeu. Dedique uma sprint à implantação da integração em modo sombra descrita acima e decida com base no relatório de paridade dos dados — não na apresentação de vendas. A maioria das equipes que concluem a fase de modo sombra decide fazer a migração em até noventa dias.
