¿Firebase o un MMP? Para las startups de apps la respuesta es ambos

Todo fundador de una app que hace adquisición de pago acaba haciéndose la misma pregunta: ¿necesitamos un Mobile Measurement Partner o basta con Firebase? La respuesta honesta es que resuelven problemas distintos. Firebase mide Google. Un MMP mide todo lo demás, y “todo lo demás” es más grande de lo que la mayoría de las comparativas admite. No es solo Meta y TikTok. Es tus instalaciones orgánicas, tus canales propios y cada deep link que envías. En cuanto gastas dinero de verdad en más de un canal, necesitas ambos, y necesitas una decisión clara sobre qué fuente alimenta qué plataforma.

Pasé un año construyendo y depurando exactamente este stack para un marketplace de reservas suizo: Firebase y Adjust funcionando en paralelo, alimentando Google Ads y Meta. La mayor parte de lo que sé sobre esto lo aprendí de cosas que se rompían en silencio.

Este es el primer post de una serie de tres partes sobre seguimiento de apps. Este cubre la arquitectura: por qué una sola herramienta no es suficiente, qué mide realmente un MMP, cómo funcionan los dos pipelines y quién debe alimentar qué. La segunda parte cubre los modos de fallo silencioso. La tercera parte cubre el hueco de atribución en iOS que casi cualquier app con campañas web-to-app tiene ahora mismo.

En resumen

• La atribución de Firebase solo se conecta con Google Ads. Meta, TikTok y otras redes apenas ven los datos de Firebase; las instalaciones y conversiones de esos canales acaban mal atribuidas o clasificadas como orgánicas.
• Un MMP no es solo un apaño para Meta. Un Mobile Measurement Partner (Adjust, AppsFlyer, Branch, Airbridge) atribuye instalaciones y eventos in-app en todas las fuentes: redes de pago, tráfico orgánico, canales propios (email, banners en el sitio, offline/QR) y los deep links que los impulsan. Envía las conversiones de vuelta a cada red del lado del servidor.
• La prueba más clara es el mix de canales que revela. En la app que gestioné, las compras in-app de un mes se repartieron entre el tráfico orgánico (la fuente individual más grande), Apple Search Ads, un banner web-to-app, el email y el social de pago. Una vista solo con Firebase habría colapsado casi todo eso en “orgánico/directo”.
• Usa ambos, como pipelines paralelos. En la práctica suelen ser rutas de código separadas dentro de tu app, y los ingresos deben configurarse de forma independiente en cada una. Uno puede romperse mientras el otro funciona. Los nuestros discreparon en los ingresos por un factor de aproximadamente 8x durante un tiempo, en silencio.
• Decide quién alimenta qué: Firebase como fuente principal de conversiones para Google Ads (señal más rápida y rica), el MMP como secundaria ahí, y el MMP como la única vía de conversión hacia Meta y la única vista honesta del tráfico orgánico y de canales propios.
• Un MMP no es un requisito desde el día uno para todo el mundo. Con un gasto mínimo en Meta o TikTok, el propio SDK de la plataforma reporta bien por sí solo. El MMP se vuelve imprescindible en cuanto escalas o gestionas tres o más fuentes, porque es entonces cuando tiene que deduplicar reclamaciones solapadas y atribuir cada fuente correctamente.
• Si te saltas la decisión sobre la fuente, o cuentas conversiones por duplicado o dejas a una plataforma sin señal. Ambas cosas arruinan el bidding en silencio.

Por qué Firebase por sí solo no es suficiente

Firebase (a través de GA4) es gratis, está profundamente integrado con Google y es genuinamente bueno en lo que hace: rastrea eventos in-app, construye audiencias y alimenta conversiones directamente al bidding de Google Ads sin código extra más allá del SDK que ya instalaste.

La limitación es estructural. La atribución de Firebase se conecta con Google Ads y esencialmente con nada más. Ejecuta Meta App Ads o TikTok en paralelo, y Firebase no tiene visibilidad de esos clics. Las conversiones que generaron aparecen como orgánicas o directas. Los análisis de profesionales son tajantes al respecto: las instalaciones generadas por Meta están gravemente infrarreportadas en una configuración solo con Firebase.

Pero Meta es solo el punto ciego más obvio. Firebase es igual de ciego ante Apple Search Ads, ante una campaña de email que hace deep link dentro de la app, ante un banner de “descarga la app” en el sitio, ante un flyer offline con un código QR. Todo ello cae en el mismo cubo indiferenciado de “orgánico/directo”. Si todo tu presupuesto de pago son Google App Campaigns, Firebase por sí solo es defendible. En el momento en que un segundo canal te importa, sea de pago o propio, vuelas a ciegas sobre él.

Qué mide realmente un MMP (y no es solo Meta)

Un Mobile Measurement Partner se sitúa entre tu app y el mundo exterior. Cada instalación y cada evento in-app se atribuye a una fuente, se deduplica entre canales, con filtrado de fraude. La mayoría de las comparativas se detienen ahí y presentan el MMP como “la forma de medir Meta”. Eso lo infravalora. Tres tareas importan tanto como la de las redes de pago:

El tráfico orgánico y los canales propios se vuelven visibles. El MMP atribuye instalaciones y eventos que nunca tocaron una red publicitaria: navegación y búsqueda en la App Store, referidos, tu lista de email, banners en el sitio, códigos QR offline. En el marketplace que gestioné, el MMP rastreaba más de diez canales distintos, y el tráfico orgánico era de forma consistente la fuente individual más grande de reservas in-app, mayor que cualquier canal de pago. Ese es precisamente el número que una configuración solo con Firebase no puede darte, porque archiva el tráfico orgánico y todo-lo-que-no-es-Google bajo la misma etiqueta. No puedes decidir si invertir en ASO, en referidos o en email si la herramienta literalmente no puede verlos.

Los deep links son una función del MMP, no un efecto secundario. Los enlaces de seguimiento que emite un MMP son también deep links (y deferred deep links): llevan a un usuario desde un email, un SMS, un smart-banner web, un código QR o un enlace de influencer al lugar correcto dentro de la app, incluso a través de una instalación desde la App Store, y atribuyen todo el recorrido. Así es como se mide de verdad el owned media. Un ejemplo concreto: un canal de Instagram que gestionamos de forma orgánica fue invisible durante meses, clasificado como “orgánico/directo”. El mes en que le añadimos los enlaces de seguimiento personalizados del MMP, se convirtió en una fuente medida de la noche a la mañana. Sin gasto nuevo, solo atribución que por fin existía.

Una única vista cross-channel deduplicada. Como cada fuente reporta a través de la misma capa, el MMP es el único lugar donde existe una imagen combinada y deduplicada de todo el funnel. Es contra lo que reconcilias todo lo demás.

Así que “un MMP mide a todos los demás” es literal. Es el árbitro de las redes de pago y la única medición honesta que tienes del tráfico orgánico, propio y de deep links.

Vale la pena señalar una advertencia, porque es la otra cara del mismo mecanismo: la atribución de un MMP es tan buena como los enlaces que hay detrás. En nuestro stack, el banner de la app en el sitio no podía pasar la fuente original a través del enlace del MMP, así que cada instalación a través de él quedaba clasificada como “website_banner” y su verdadera fuente de origen (búsqueda de pago, Meta, orgánico) se perdía. La medición de deep links y canales propios es real y valiosa, pero hay que cablearla deliberadamente, enlace por enlace, o infravalora en silencio lo que sea que generó el tráfico.

Por qué un MMP por sí solo tampoco es suficiente

Si el MMP lo ve todo, ¿por qué no usar solo el MMP? Dos razones, ambas aprendidas en producción:

Google puja mejor sobre su propia señal. Google Ads acepta conversiones de un MMP, pero la vía de Firebase es más rápida y rica. Los eventos de Firebase llegan con más granularidad y menos retraso, lo que importa para el bidding con tROAS y tCPA. En la cuenta que gestiono, Firebase se convirtió en la fuente principal para Google Ads porque la señal era sencillamente mejor.

El pipeline del MMP tiene más piezas móviles. En nuestra implementación, los eventos de Firebase iban directamente desde la app vía el SDK de Firebase, mientras que el MMP recibía los eventos a través de una customer data platform (RudderStack) que los mapeaba al SDK de Adjust. Dos rutas de código, dos lugares donde configurar los ingresos, dos superficies de fallo. Más sobre lo que eso nos costó en la segunda parte, pero el punto arquitectónico se sostiene: la vía del MMP rara vez es la sencilla.

La arquitectura de doble stack

Esta es la forma que funciona, y que volvería a construir:

App events
  ├── Firebase SDK (direct)
  │     └── GA4 → Google Ads          (Primary for Google)
  └── CDP or direct → MMP SDK (Adjust)
        ├── → Meta (S2S postbacks)     (ONLY path to Meta)
        ├── → Google Ads               (Secondary, cross-check)
        ├── → TikTok / Apple Search Ads / others
        └── → organic, email, banner, QR / deep links  (attribution + routing)

Tres propiedades de esta configuración importan más que cualquier elección de herramienta:

1. Los pipelines son independientes. Firebase y el MMP no comparten estado. Un evento puede llevar ingresos en uno y llegar sin ellos al otro. Trátalos como dos productos separados que resulta que describen al mismo usuario.

2. Los ingresos se configuran dos veces, deliberadamente. La llamada de Firebase y la llamada del MMP necesitan cada una el valor y la moneda adjuntos explícitamente. Asumir que uno hereda del otro es la suposición más cara en el seguimiento de apps. En nuestro stack, los dos pipelines discreparon en los ingresos capturados por un factor de aproximadamente 8x durante un tiempo. Un pipeline adjuntaba los valores correctamente mientras el otro los descartaba en silencio, y nada daba error. La solución fue a nivel de código, en un solo pipeline. (La autopsia completa está en la segunda parte.)

3. Cada plataforma recibe su mejor fuente disponible. Lo que nos lleva a la decisión que la mayoría de los equipos nunca toma explícitamente.

Quién alimenta qué: la decisión operativa

Esta es la parte que las comparativas de herramientas se saltan, y es la parte que decide la calidad de tu bidding.

Google Ads: Firebase como principal, MMP como secundaria. Importa ambas, pero marca las acciones de conversión de Firebase como principales (usadas para el bidding) y las del MMP como secundarias (solo observación). Obtienes la señal más rápida de Google para Smart Bidding más una comprobación cruzada independiente del MMP. Nunca configures ambas como principales: Google contará la misma compra dos veces, y tu CPA reportado parecerá mejor que la realidad mientras el bidding optimiza hacia una ficción.

Meta y otras redes: el MMP, punto. Firebase no habla con Meta. Los postbacks del lado del servidor del MMP son tu única vía limpia de conversión para App Ads, incluidos los valores de conversión que Meta necesita para la optimización por valor. Lo mismo aplica a TikTok y Apple Search Ads. Esto también significa que la calidad de su señal es tan buena como tu pipeline del MMP, que es exactamente donde el nuestro perdía ingresos en silencio. Una excepción, al principio de todo: por debajo de un gasto trivial, los propios SDKs de Meta y TikTok pueden reportar sus eventos directamente, por lo que añadir el MMP es en realidad una decisión de escalado (más sobre el momento oportuno más abajo).

Canales orgánicos, propios y con deep link: el MMP es la única fuente. No hay equivalente en Firebase para “cuántas reservas vinieron del deep link del email, del banner en el sitio o del tráfico orgánico”. Si quieres tomar decisiones sobre ASO, referidos o CRM con datos en lugar de con sensaciones, de aquí es de donde vienen.

Reporting: GA4 para el comportamiento, el MMP para la atribución cross-channel, tu backend para la verdad. Tres números que nunca coincidirán a la perfección, y no necesitan hacerlo. Lo que necesitan es reconciliarse dentro de una tolerancia que hayas decidido de antemano. Cuando los ingresos de la app en el MMP son una fracción de lo que muestra el backend, eso no es un problema de filosofía de atribución. Eso es un bug.

Cuándo añadir el MMP

Secuéncialo por gasto, no por ambición, y sé honesto sobre tu etapa. Un MMP no es un requisito desde el día uno para toda app.

• Solo Google, presupuesto pequeño: Firebase por sí solo está bien. Configúralo correctamente (eventos, valores, conversiones importadas) y ahórrate la cuota del MMP.
• Un segundo canal, pero con gasto mínimo: aquí también puedes posponer el MMP. Meta y TikTok tienen ambos sus propios SDKs que reportan los eventos de la app directamente a cada plataforma, y con unos pocos cientos de euros al mes eso basta para optimizar un único canal. La trampa es que cada plataforma se autoatribuye de forma aislada, así que nada se deduplica y no tienes una única vista cross-channel honesta. Con un gasto trivial ese hueco es tolerable. Solo ten claro que es un parche, no el destino.
• Escalando, o con tres o más fuentes: ahora el MMP es la respuesta, y esta es la razón por la que existe. Una vez que fluye presupuesto de verdad a través de Google, Meta, TikTok, más el tráfico orgánico y los canales propios, las plataformas empiezan a reclamar la misma instalación y la misma compra, y tus números se inflan. El MMP es la capa que deduplica cada evento a una única fuente de verdad y atribuye cada instalación y conversión a la fuente que realmente la ganó. Añádelo antes de escalar, no después, porque la atribución retroactiva no existe: todo lo que corra antes de que se lance el SDK es inmedible para siempre.
• A escala sigue rindiendo: exportaciones de cohortes, filtrado de fraude, routing de deep links para campañas de ciclo de vida y gestión de SKAdNetwork en iOS.

El precio de los MMPs suele escalar con las instalaciones o eventos atribuidos. Para una app en fase temprana los tramos de entrada son modestos frente a incluso un presupuesto de pago pequeño, y una vez que estás escalando, la alternativa, comprar instalaciones que no puedes atribuir y dejar que cada plataforma cuente por duplicado, es más cara que cualquier herramienta.

Errores comunes

1. Tratar el MMP como un reemplazo de Firebase en Google. Pierdes la mejor señal de bidding de Google y no ganas nada.
2. Tratar el MMP como “solo la tubería de Meta”. Pagaste por medición cross-channel, orgánica y de deep links. Úsala. El canal que hace visible podría ser el más grande que tienes.
3. Ambas fuentes configuradas como principales en Google Ads. Conversiones contadas por duplicado, dashboards halagadores, bidding corrompido.
4. Asumir que los ingresos fluyen a ambos pipelines porque el evento lo hace. Que lleguen los nombres de eventos no es lo mismo que que lleguen los valores. Verifica cada pipeline por separado.
5. Añadir el MMP después de haber lanzado las campañas. La atribución empieza cuando se lanza el SDK, no cuando firmaste el contrato.
6. Nadie es dueño del mapeo. Los eventos web, los eventos de Firebase y los eventos del MMP necesitan un mapeo documentado (qué evento de app equivale a qué conversión en qué plataforma, y qué deep link alimenta qué canal). Sin él, cada sesión de depuración empieza desde cero.

FAQ

¿Es GA4 lo mismo que Firebase para el seguimiento de apps?

A efectos de esta discusión, básicamente sí: el SDK de Firebase alimenta GA4, y Google Ads importa las conversiones desde ahí. El par es un único pipeline.

¿Qué MMP debería elegir una startup?

Adjust, AppsFlyer, Branch y Airbridge cubren todos la tarea principal. Elige según el modelo de precios, las redes que realmente usas, tus necesidades de deep linking y el encaje del SDK con tu stack. La arquitectura de este post aplica a todos ellos.

¿Puedo enviar datos de Firebase a Meta de alguna manera?

No de forma útil. La atribución de apps de Meta funciona sobre su SDK o sobre los postbacks del lado del servidor del MMP. Precisamente por eso el MMP se gana su sitio el día en que Meta recibe presupuesto.

Si la mayoría de nuestras instalaciones son orgánicas, ¿seguimos necesitando un MMP?

Ese es el argumento más fuerte a favor de uno, no en contra. Firebase no puede distinguir el tráfico orgánico de Meta, del email o de un banner web-to-app. Los archiva juntos. Si el tráfico orgánico es tu mayor fuente, un MMP es la única forma de confirmarlo, protegerlo y hacerlo crecer (ASO, referidos, campañas de ciclo de vida con deep link) con datos reales.

¿Los dos pipelines cuentan los ingresos por duplicado en mi reporting?

Solo si los mezclas. Mantén Google Ads deduplicado vía principal/secundaria, y trata GA4, el MMP y tu backend como tres vistas con huecos conocidos y esperados.

¿Y qué pasa con iOS y SKAdNetwork?

iOS añade una tercera capa de medición (SKAN/AdAttributionKit) encima de ambos pipelines, más la mecánica de gBraid para las campañas web-to-app. Eso es la tercera parte de esta serie; la versión corta es que la atribución en iOS falla de formas que Android nunca te muestra.

Puntos clave

1. Firebase mide Google; un MMP mide todo lo demás: redes de pago, y con la misma importancia el tráfico orgánico, los canales propios y los deep links. Ambos, en paralelo, es la respuesta estándar en cuanto más de un canal importa.
2. El MMP no es solo la tubería de Meta. En una app real, su output más valioso fue ver que el tráfico orgánico, invisible para Firebase, era la fuente individual más grande de reservas.
3. Los pipelines son rutas de código independientes. Los ingresos deben configurarse explícitamente en cada una, y uno puede romperse mientras el otro funciona.
4. Haz la decisión sobre la fuente explícita: Firebase principal para Google Ads, MMP secundaria ahí, MMP en exclusiva para Meta y para la medición de canales orgánicos/propios/con deep link.
5. Reconcilia las tres vistas (GA4, MMP, backend) según un calendario, con una tolerancia. Una discrepancia más allá de ella es un bug, no una filosofía.

Siguiente en la serie: los cinco modos de fallo silencioso que desplegué en este mismo stack, y la checklist de monitorización que habría cazado cada uno antes.

Si estás cableando esto ahora, o sospechas que un pipeline está descartando ingresos en silencio como hizo el nuestro, compruébalo antes de escalar, porque no deberías pujar sobre números en los que aún no puedes confiar. Una auditoría de seguimiento de apps completa te dirá en cuál de estos dos grupos estás, y si prefieres simplemente obtener una segunda opinión primero, estaré encantado de revisar tu configuración.

Fuentes: Google Ads Help, importing app conversions from Firebase and App Attribution Partners; AppSprint, Firebase vs MMP; AppsFlyer on measuring Google App Campaigns; Adjust on deep linking and deferred deep linking; experiencia de implementación propia sobre un stack dual de Firebase + Adjust (2026).