¿Por qué Google Ads, mi MMP y SKAN dan conversiones iOS distintas?

Google Ads, tu MMP y SKAN no van a reportar las mismas conversiones de iOS, porque cuentan cosas distintas, las atribuyen a momentos distintos y ven usuarios distintos. No uses ninguno como el único número verdadero. Usa Google Ads para el feedback de puja, el MMP para repartir presupuesto entre canales y tu fuente de revenue para finanzas, y observa si la brecha entre ellos se mueve. La condición que cambia la respuesta es la región: para los usuarios de iOS en el EEE, el Reino Unido y Suiza no hay claims de ICM en el MMP, así que ahí la vista del MMP sobre Google es más limitada y SKAN pesa más.

Alcance: App Campaigns de Google para instalaciones en iOS, medidas a través de un partner de atribución (para el lado del MMP uso la documentación de AppsFlyer, y otros MMP tienen sus propias reglas), todas las regiones, con la excepción regional de arriba. Cada dato de plataforma de abajo se comprobó contra la página primaria el 29 de septiembre de 2026. Para el lado de Meta del mismo problema, lee Meta vs RevenueCat vs Adjust. Para la configuración que produce los claims de ICM en primer lugar, lee la guía de configuración de ICM y de la medición en el dispositivo.

¿Dónde vive cada número de iOS y qué cuenta?

Google publica su propia comparación lado a lado en Understanding iOS App campaign measurement and reporting. Lee la tabla de esa página. En resumen:

• Las conversiones modeladas de Google Ads están en las tablas Campaigns y Ad groups. Incluyen conversiones click through y engaged view, no view through. Google dice que pueden retrasarse hasta cinco días, y cubren a todos los usuarios, incluidos los del EEE, el Reino Unido y Suiza.
• Los claims de ICM en tu MMP son los claims de instalación de Google enviados a tu partner de atribución y mostrados en su interfaz. La página de Google dice que estos datos no están disponibles hoy en el reporting de Google Ads, y añade que la medición de iOS en Google Ads cambiará en el futuro para alinearse más con ICM en las apps con ICM y datos de eventos de medición en el dispositivo, sin dar fecha. About Integrated Conversion Measurement for App Campaigns lo describe como reporting a nivel de evento y lista la medición de conversiones en el dispositivo con datos de eventos como el requisito de iOS.
• Los postbacks de SKAdNetwork llegan a los reportes de tu MMP o de BI. En Google Ads solo aparecen las instalaciones de SKAdNetwork, en un reporte dedicado de SKAdNetwork. SKAN es el único de los tres que incluye conversiones view through, y Google recomienda revisarlo cada 30 días por los retrasos variables.

Dentro de AppsFlyer, la página Google Ads (AdWords) Integration setup for advertisers dice que los claims deterministas de Google muestran un match_type de srn en los datos en bruto, y los claims de ICM muestran “probabilistic”. Esa única columna te permite separar las instalaciones de Google del MMP en los dos tipos antes de comparar nada.

¿Por qué difieren los números incluso con todo bien configurado?

Porque las diferencias vienen de serie. La página Google Ads (AdWords) FAQ and discrepancies de AppsFlyer lista las causas, y la mayoría son definiciones, no errores.

Cada lado muestra solo su propio modelo. AppsFlyer dice que Google Ads muestra las instalaciones del modelado interno de Google y no muestra las instalaciones de ICM, mientras que AppsFlyer muestra los claims de ICM y no muestra las instalaciones modeladas internamente por Google. Dos modelos, dos resultados, ningún total compartido.

Momento del click frente a momento del arranque. Google Ads registra la instalación en el momento del click. AppsFlyer la registra en el momento del arranque. La página Understand your conversion tracking data de Google confirma que las columnas de conversiones principales se basan en el momento del click, y ofrece una columna “Conversions (by conv. time)” para cuando necesitas la fecha de la conversión. Los eventos in app siguen la misma división: Google los atribuye al momento del click, y el dashboard de AppsFlyer los atribuye al momento de la instalación.

Último click frente a cada interacción. AppsFlyer atribuye el último click y trata las interacciones anteriores como asistencias. Google, como self reporting network, atribuye todas las instalaciones posteriores a una interacción con sus anuncios, dentro de su propia ventana.

Ventanas. Para las conversiones modeladas, la comparación de Google lista una ventana de click through configurable con 30 días por defecto y una ventana de engaged view configurable con 2 días por defecto. Para ICM lista una ventana configurable en la interfaz del partner de atribución, de 6 horas a 30 días, pero nombra a AppsFlyer como excepción sin decir en qué se diferencia. La página de configuración de AppsFlyer tiene su propio ajuste de lookback de click through para instalaciones y recomienda 30 días para igualar a Google Ads. Para SKAN, Google lista una ventana de click through configurable de 30 días, una ventana de engaged view de 30 días que no se puede cambiar y una ventana de view through configurable de 1 día.

Reglas de view through. AppsFlyer señala que Google Ads pone las conversiones view through en la columna All conversions, no en Conversions, salvo que lo configures de otra forma. La comparación de Google dice que ICM incluye conversiones click through y engaged view pero no view through, y la página de configuración de AppsFlyer dice que Google hoy solo reclama clicks en iOS, no impresiones.

El retraso del modelado. Hasta cinco días para las conversiones modeladas de Google Ads. Los últimos días de cualquier reporte de Google Ads están incompletos.

Cobertura del EEE, el Reino Unido y Suiza. La página About on-device conversion measurement for iOS App campaigns de Google dice que la medición en el dispositivo con datos de eventos está inactiva para los usuarios de allí, y el Bulletin: AppsFlyer and Google attribution solution (Open BETA) de AppsFlyer dice que ICM no está disponible para el tráfico de iOS de esas regiones. Las conversiones modeladas y SKAN siguen cubriéndolos. Así que espera que la brecha entre Google Ads y el MMP dependa de qué parte de tu tráfico de iOS de Google venga de esas tres regiones.

Redescargas. Google Ads aplica lo que hayas configurado como redescarga frente a instalación nueva, mientras que ICM usa una definición fija, según la comparación de Google. AppsFlyer añade que Google Ads muestra las reinstalaciones como una conversión session_start, mientras que AppsFlyer las pone en sus datos de retargeting.

Alcance del costo. La página de discrepancias de AppsFlyer dice que recibe el costo de Google de todos los canales de una campaña pero solo atribuye las conversiones de YouTube y Display en las App Campaigns de iOS, así que el CPI se ve más alto en AppsFlyer. Su página de configuración, editada más tarde, dice que cualquier App Campaign de iOS para instalaciones puede atribuirse a través de ICM. Las dos páginas se leen distinto, así que revisa tus propios datos en bruto en busca de instalaciones probabilísticas de Google antes de decidir cuál descripción encaja con tu cuenta.

Deduplicación de SKAN. La misma página de discrepancias dice que AppsFlyer muestra solo los postbacks con did_win=TRUE, mientras que el dashboard de Google Ads no los separa de los did_win=NULL, así que el recuento de instalaciones de SKAN del MMP puede ser menor.

¿Cómo concilio Google Ads, el MMP y SKAN?

Con una hoja de trabajo, una fila por campo, rellenada para las tres fuentes antes de mirar los totales. El objetivo es nombrar cada motivo conocido de la brecha, para que lo que quede sea lo bastante pequeño como para investigarlo.

Campo	Google Ads modelado	MMP (claims de ICM y srn)	SKAN
Fuente del reporte	Tablas Campaigns y Ad groups	El dashboard o los datos en bruto de tu partner de atribución, separados por match_type	Reportes del MMP o de BI; el reporte de SKAdNetwork en Google Ads
Definición del evento	La acción de conversión importada a la que filtras, por ejemplo solo first_open	El nombre del evento de instalación o in app en el MMP	El evento o los eventos que mapea tu esquema de valores de conversión
Ventana de atribución	Ventanas de click through y de engaged view configuradas	El ajuste de lookback del MMP, y cómo se aplica a los claims de ICM	Las ventanas de Apple más las ventanas SKAN de Google
Base de fecha de la cohorte o del evento	Fecha del click, o “by conv. time” si cambias de columna	Fecha de arranque para las instalaciones; fecha de instalación para los eventos en el dashboard, fecha del evento en los datos en bruto	Fecha estimada de instalación
Zona horaria	La zona que usa el reporte de Google Ads	La zona que usa la app en el MMP	La zona que usa tu reporte de SKAN
Antigüedad de la cohorte	Al menos cinco días después del último click, más la ventana	Pasado el lookback del MMP	Pasado el último postback del que dependes
Reinstalaciones	Tus ajustes de redescarga; reinstalaciones como session_start	Reatribuciones en los datos de retargeting	La comparación de Google no da ninguna regla; anota cómo las trata tu MMP
Base del revenue	El valor asociado a la acción de conversión importada, y de dónde viene	El revenue que envía el SDK o el servidor, bruto o neto, con o sin reembolsos	El revenue implícito en el esquema de valores de conversión
Diferencia residual sin explicar	Déjalo en blanco hasta que todas las filas de arriba coincidan

Algunas celdas necesitan una fuente detrás. La fecha de SKAN es una estimación: la página SKAN Conversion Studio de AppsFlyer deriva la hora de instalación de la hora de llegada del postback menos un rango medio de última actividad y un retraso fijo del postback de iOS. La misma página dice que SKAN 4 envía tres postbacks, después de las ventanas que terminan los días 2, 7 y 35. La página de Apple sobre AdAttributionKit Receiving postbacks in multiple conversion windows da las mismas tres ventanas, de los días 0 a 2, de 3 a 7 y de 8 a 35 desde el primer arranque, con postbacks enviados tras un retraso aleatorio de 24 a 48 horas para el primero y de 24 a 144 horas para los demás, y solo el primer postback puede llevar un fine value. Para el revenue, Set up your SKAdNetwork conversion value schema de Google dice que su modelado de conversiones usa solo fine conversion values y hoy no admite los coarse conversion values de SKAN 4, así que el valor que llega a SKAN solo como coarse value, como pasa en el segundo y el tercer postback, no alimenta el modelado de Google. AppsFlyer también advierte de que los datos de Google Ads importados desde Firebase están estructurados de otra forma y no son del todo comparables con los datos de AppsFlyer, así que anota la fuente de importación en la fila del revenue.

¿Cómo se ve una distancia que no es normal?

Aquí tienes un caso de mi propio trabajo. En febrero y marzo de 2026 llevé App Campaigns de Google para una subscription app en Android y iOS, con AppsFlyer como MMP e ICM activado en iOS. Es la misma cuenta de mi prueba de estrategia de puja. En 39 días y $88.920, Google Ads reportó un ROAS de 37,7% en todas las campañas. AppsFlyer mostró un ROAS lifetime de 29,8% y de 17,0% en day 0.

La primera lección es la fila de la base del revenue de la hoja de trabajo. Frente a la cifra de day 0 de AppsFlyer, Google se veía 21 puntos demasiado alto. Frente al ROAS lifetime de AppsFlyer, la brecha era de 8 puntos. Las mismas campañas, el mismo gasto, y el tamaño de la “discrepancia” dependió de qué columna de AppsFlyer elegimos. La mayoría de las campañas individuales quedaron a unos 10 puntos de AppsFlyer, en ambos sentidos, lo cual explican los motivos de arriba.

La segunda lección es qué suele significar una brecha muy fuera de ese rango. La campaña de iOS con Max Conversion Value gastó $11.312 y mostró un ROAS de 71,4% en Google Ads frente a un ROAS lifetime de 17,3% en AppsFlyer, 54 puntos de diferencia. Los motivos documentados fueron los primeros sospechosos: conversiones modeladas, view through, ventanas distintas. La causa era más simple. El evento de revenue de la app, AllRevenue, le pasaba a Google un valor de $1 cuando no había valor de conversión, en lugar de $0. Eso inflaba el ROAS de Google en todas partes, y en iOS, donde los volúmenes de conversión eran menores, tapaba los números reales. Ninguna fila de la hoja de trabajo lo habría explicado, porque nada de eso era una definición. Era un valor equivocado.

¿Cuál es el procedimiento, paso a paso?

Cuando audito esto, reviso primero qué envía cada evento, luego la base de fechas y el filtro de eventos, porque cada uno se confirma rápido y cualquiera de ellos puede mover una comparación por sí solo.

1. Revisa los valores antes que los modelos. Mira el valor que cada evento de revenue envía de verdad a Google, incluidos los eventos que no llevan revenue. Un valor por defecto de 1 donde debería haber 0 o nada infla todos los números basados en valor que muestra Google, y ningún modelo de atribución lo explica.
2. Compara solo cohortes maduras. Deja fuera al menos los últimos cinco días en Google Ads, y deja fuera más días cuando el evento ocurra más tarde que la instalación. La propia comparación de Google dice que esperes la duración completa de la ventana de conversión antes de evaluar una campaña, y la página Set a recommended initial Target ROAS for your App campaigns de Google sugiere una ventana de 14 a 30 días que excluya el periodo más reciente. Para SKAN, espera los postbacks en los que te apoyas.
3. Elige un evento y una ventana. En Google Ads, AppsFlyer señala que el reporte de conversiones puede mezclar instalaciones, compras y suscripciones, así que filtra a la conversión de instalación antes de comparar instalaciones. Luego pon las ventanas de la hoja de trabajo en paralelo.
4. Pon todo sobre la misma base de fechas. Usa “Conversions (by conv. time)” en Google Ads cuando compares contra un MMP que cuenta por fecha de arranque, o compara totales semanales donde un día de desfase se diluye.
5. Separa las instalaciones de Google del MMP por match_type. Las filas srn y probabilistic vienen de métodos de claim distintos, así que compara cada una por separado y registra su peso a lo largo del tiempo.
6. Nunca sumes SKAN a los totales modelados. Miden las mismas campañas con métodos distintos. Ponlos uno junto al otro, no uno encima del otro.
7. Trata el cambio en la brecha como la señal, no la brecha. Una brecha estable entre Google Ads y el MMP es una propiedad de los dos métodos. Una brecha que se duplica en una semana es una pregunta: una versión nueva del SDK, un cambio de consentimiento, una región nueva, una acción de conversión cambiada, un ajuste nuevo de redescargas.

Los ajustes de privacidad entran en esta lista solo como datos que anotar. La página de configuración de AppsFlyer dice que, con su interruptor Aggregated Advanced Privacy activado, los datos atribuidos a Google en los reportes en bruto se muestran como restricted, y que el enmascaramiento de IP puede afectar a ICM. Esas son decisiones de privacidad del dueño de la app. Yo anoto cómo están configuradas; no las desactivo para que los números coincidan.

¿Qué número debo usar para cada decisión?

Feedback de puja: Google Ads. Los objetivos de tCPA y tROAS se fijan y se juzgan en Google Ads, contra las conversiones que reporta Google Ads. Cuando me pregunto si un objetivo es demasiado ajustado, leo la propia columna de Google, en días ya maduros, sobre la ventana de 14 a 30 días que sugiere Google. Comprobar un objetivo de Google contra números del MMP mezcla dos modelos y puede llevarte a cambiar un objetivo que estaba bien.

Presupuesto entre canales: el MMP. Aplica una sola regla de último click en todas las redes, algo que Google y Meta no pueden hacer el uno por el otro. Eso lo convierte en el lugar más justo para comparar Google contra Meta o cualquier otra cosa, siempre que recuerdes que solo cuenta las instalaciones de Google que Google le reclama, y que la parte de tu tráfico de iOS de Google que viene del EEE, el Reino Unido y Suiza no tiene claims de ICM en absoluto. Donde esa parte es grande, uso SKAN como segunda lectura de la dirección.

Finanzas: ninguna de las plataformas de ads. El revenue debe venir de donde se cobra: tu plataforma de suscripciones o las stores, cruzado con el gasto en paid con las comprobaciones de el artículo de conciliación de Meta. El MMP te da revenue por canal, y SKAN te da una comprobación independiente de si un canal se está moviendo, pero ninguno de los tres es un libro contable.

Esto forma parte del trabajo de signal engineering que hago: decidir qué evento ve cada sistema, desde qué fuente, y cómo se leen las brechas entre ellos. Si tus números de iOS de Google no coinciden y no sabes qué brecha es normal, un growth audit empieza con esta hoja de trabajo, y se puede reservar por separado con cualquier nivel de gasto.

Fuentes

Todas las páginas verificadas el 29 de septiembre de 2026.

1. Understanding iOS App campaign measurement and reporting, Google Ads Help, sin fecha de página
2. About Integrated Conversion Measurement for App Campaigns, Google Ads Help
3. About on-device conversion measurement for iOS App campaigns, Google Ads Help
4. Understand your conversion tracking data, Google Ads Help
5. Set a recommended initial Target ROAS for your App campaigns, Google Ads Help
6. Set up your SKAdNetwork conversion value schema, Google Ads Help
7. Google Ads (AdWords) FAQ and discrepancies, AppsFlyer, última edición 16 de marzo de 2026
8. Google Ads (AdWords) Integration setup for advertisers, AppsFlyer, última edición 15 de septiembre de 2026
9. Bulletin: AppsFlyer and Google attribution solution (Open BETA), AppsFlyer, última edición 5 de agosto de 2026
10. SKAN Conversion Studio, AppsFlyer, última edición 26 de abril de 2026
11. Receiving postbacks in multiple conversion windows, Apple Developer, sin fecha de página

Preguntas frecuentes

¿Puedo sumar las instalaciones de SKAN a las de Google Ads para tener el total de iOS?

No. Google describe las conversiones modeladas, ICM y SKAdNetwork como tres formas de medir las mismas App Campaigns de iOS, dice que la elección entre ellas depende del estado de tu implementación, y señala que las conversiones modeladas se apoyan en SKAdNetwork cuando corresponde. Sus instalaciones se solapan. Sumarlas cuenta a los mismos usuarios más de una vez. Compáralas en paralelo, sobre el mismo evento y la misma ventana.

¿Por qué Google Ads no muestra las instalaciones de ICM que muestra mi MMP?

Porque Google las mantiene separadas hoy. La página de medición de iOS de Google dice que los datos de ICM no están disponibles en el reporting de Google Ads, y AppsFlyer dice que Google Ads no muestra las instalaciones basadas en ICM, mientras que AppsFlyer muestra los claims de ICM y no muestra las instalaciones modeladas internamente por Google. Cada lado muestra su propio modelo. Google dice que la medición de iOS en Google Ads se acercará más a ICM para las apps con ICM y datos de eventos de medición en el dispositivo, pero no da fecha.

¿Por qué mi CPI de Google es más alto en AppsFlyer que en Google Ads?

La página de discrepancias de AppsFlyer dice que recibe el costo de Google de todos los canales de una campaña, pero atribuye las conversiones de las App Campaigns de iOS solo de YouTube y Display, así que el MMP divide el costo total entre menos instalaciones. Revisa tus datos en bruto en busca de claims probabilísticos de ICM antes de dar por hecho que eso sigue describiendo tu cuenta.

¿Cuánto debo esperar antes de comparar los tres números?

Google dice que las conversiones modeladas de iOS pueden tardar hasta cinco días y recomienda esperar la ventana de conversión completa antes de juzgar una campaña. SKAN es más lento: la tercera ventana de conversión de Apple termina 35 días después del primer arranque, y ese postback llega tras un retraso aleatorio adicional de hasta 144 horas.

¿Funciona ICM para los usuarios de iOS en el EEE, el Reino Unido y Suiza?

No, a 29 de septiembre de 2026. La página de medición en el dispositivo de Google dice que la medición en el dispositivo con datos de eventos, que Google indica como el requisito de iOS para ICM, está inactiva para los usuarios de allí, y el boletín de ICM de AppsFlyer dice que ICM no está disponible para el tráfico de iOS de esas regiones. Las conversiones modeladas de Google Ads y SKAN sí los cubren.