Cuando integras un SDK SaaS de mediación publicitaria típico, tu flujo de eventos —cada solicitud de anuncio, cada impresión y cada identificador de usuario— se envía primero a los servidores del proveedor. Allí lo procesan, lo enriquecen y, a veces, devuelven una copia con los datos sensibles ocultos a tu almacén de datos. Cuando por fin puedes ver los datos, ya han pasado por un sistema que no controlas.
Un SDK nativo de Firebase funciona al revés. Los eventos se escriben primero en tus propios Firestore y BigQuery. El proveedor lee los datos de tu proyecto, no al contrario. La diferencia parece teórica hasta que llega la primera auditoría de GDPR.
Qué cambia cuando los datos están bajo el control de tu proyecto
- Las solicitudes de eliminación se resuelven con una sola consulta a Firestore: sin abrir tickets al proveedor ni depender de un SLA
- Los costes de BigQuery son predecibles porque tú controlas el esquema de exportación
- Las migraciones de esquema siguen tu calendario, no las notas de versión del proveedor
- La lista de subencargados del tratamiento que debes declarar se reduce, a menudo de forma drástica
Las contrapartidas que nadie menciona en la llamada comercial
Una arquitectura nativa de Firebase no está exenta de costes. Pagas a Google por el almacenamiento y las consultas que, de otro modo, habrías delegado en el proveedor. Para una app con 5 millones de DAU, la factura de BigQuery oscila entre 400 y 1.200 USD al mes: una cantidad relevante, pero insignificante frente a los ingresos publicitarios que protege.
También tienes que tener en cuenta las cuotas. Las escrituras por segundo en Firestore, las inserciones en streaming de BigQuery y los arranques en frío de Cloud Functions son limitaciones reales que un SDK SaaS gestiona sin que lo notes. Apps Kit SDK incluye una capa de control de flujo que agrupa las escrituras en lotes para mantenerse dentro de las cuotas del nivel gratuito en la mayoría de las apps con menos de 1 millón de DAU.
Cuánto pagas realmente a Google
El modelo de costes no tiene sorpresas, y esa es la idea: puedes ver cada partida en tu propia consola de facturación. Estos son los rangos que observamos en las implementaciones activas de Apps Kit SDK en 2026, tras aplicar la capa de control de flujo y la caducidad de particiones de BigQuery a los 90 días que incluimos de forma predeterminada.
- 1 millón de DAU: Firestore, 40–90 USD; almacenamiento de BigQuery, 20–50 USD; consultas de BigQuery, 30–80 USD; Cloud Functions, 10–30 USD. Total: menos de 250 USD/mes
- 5 millones de DAU: Firestore, 180–350 USD; almacenamiento de BigQuery, 100–220 USD; consultas de BigQuery, 120–400 USD; Cloud Functions, 40–110 USD. Total: 400–1.200 USD/mes
- 25 millones de DAU: Firestore, 700–1.400 USD; almacenamiento de BigQuery, 450–900 USD; consultas de BigQuery, 500–1.800 USD; Cloud Functions, 150–400 USD. Total: 1.800–4.800 USD/mes
Ajustes que realmente reducen la factura
La mayor parte de la variación anterior depende de tres decisiones. La primera es si insertas datos en BigQuery en streaming o por lotes a través de GCS: el procesamiento por lotes reduce el coste de ingesta en más de un 80 %, a cambio de un retraso de 30 minutos en los informes. La segunda es la caducidad de las particiones: 90 días cubren todas las consultas operativas que hemos necesitado hasta ahora; los datos sin procesar más antiguos deben pasar a almacenamiento en frío. La tercera son las buenas prácticas de consulta: un solo panel con un SELECT * sin restricciones sobre un año de impresiones puede costar más que todo lo demás junto.
Por qué esto importa más en 2026
Dos cambios normativos han alterado el panorama este año. Los requisitos de portabilidad de datos de la DMA se aplican ahora a cualquier proveedor que trate datos de usuarios finales de la UE, y el plazo de adaptación para la aplicación de la DPDP de la India terminó en marzo. Ambos marcos normativos dan por hecho que puedes generar, cuando se te solicite, una exportación completa de todos los eventos vinculados a un usuario.
Si el sistema del proveedor de tu SDK es la fuente oficial de datos, dependes de sus herramientas de exportación. Si esa fuente oficial es tu proyecto de Firebase, la exportación se resuelve con una consulta que ya sabes escribir.
Cómo se desarrolla realmente una auditoría de GDPR / DPDP
Cuando un regulador o un gran cliente empresarial solicita una auditoría, pide cuatro evidencias: una lista de todos los subencargados del tratamiento que acceden a datos de usuarios finales, una exportación completa de los datos de un usuario concreto, una prueba de eliminación y una descripción de tu calendario de conservación de datos. Con un SDK SaaS, preparas la primera leyendo la documentación del proveedor; las dos siguientes, abriendo tickets; y la cuarta, haciendo suposiciones.
Con una arquitectura nativa de Firebase, las cuatro se obtienen mediante consultas bajo tu control. Subencargados del tratamiento: la lista de servicios de GCP de tu proyecto. Exportación de datos del usuario: una consulta a Firestore y otra a BigQuery, ambas incluidas como plantillas en el SDK. Prueba de eliminación: una función de Cloud Functions que devuelve el número de filas afectadas. Conservación: tu política de caducidad de particiones, visible en la consola. La auditoría pasa de ser dos semanas de prisas a una tarea de medio día.
Cómo migrar desde un SDK SaaS sin romper la atribución
La migración que asusta a los equipos es la que imaginan hacer en una sola versión. Nosotros no la hacemos así. El SDK nativo de Firebase se despliega junto al SDK SaaS existente durante entre dos y cuatro semanas: escribe en el nuevo flujo de datos mientras el anterior sigue alimentando todos los paneles y MMP existentes.
- Semana 1: integra el SDK nativo de Firebase en modo sombra, sin cambios visibles para el usuario, y valida la paridad de eventos en BigQuery
- Semana 2: redirige los postbacks de atribución al flujo nativo de Firebase y mantén la mediación en el SDK anterior
- Semana 3: cambia la mediación al nuevo SDK y mantén el SDK SaaS emitiendo eventos en modo de solo lectura para resolver discrepancias
- Semana 4: elimina el SDK SaaS en la siguiente actualización de la app para no dejar ninguna dependencia
Cuándo sigue ganando SaaS
Si tu equipo no usa Firebase ni tiene previsto hacerlo, la carga operativa adicional de un SDK nativo de Firebase es real. La mediación SaaS es la opción adecuada para los estudios que quieren lanzar su app y olvidarse de la infraestructura, y para los prototipos en los que el control de los datos aún no es un activo estratégico. La decisión no es técnica: se trata de quién quieres que controle el registro de auditoría.
Tener el control del flujo de eventos no es una simple postura sobre privacidad. Es la diferencia entre negociar tu próximo contrato con un proveedor desde una posición de fuerza o con una captura de pantalla como único respaldo.
Qué hacer este trimestre
Si ya usas Firebase Analytics, tienes recorrido el 60 % del camino hacia un SDK publicitario nativo de Firebase y probablemente no lo sepas. Dedica un sprint a desplegar la integración en modo sombra descrita arriba y decide a partir del informe de paridad de datos, no de la presentación comercial. La mayoría de los equipos que completan la fase en modo sombra deciden hacer el cambio en menos de noventa días.
