· 12 min · Samet Durgun · Datos de plataforma verificados el

¿Es AppLovin incremental para mi app y cómo lo compruebo?

Soy Samet Durgun, fractional Head of UA. Llevo el paid UA de apps de suscripción y juegos móviles, y aquí escribo lo que veo en las cuentas que manejo. Este artículo pertenece al tema Fractional Head of UA; más sobre mí.

AppLovin es incremental para tu app solo en la medida en que apagarlo te costaría instalaciones y revenue que no conseguirías en ningún otro sitio. Ninguna cifra de ROAS en tu MMP ni en el dashboard de AppLovin responde a eso, porque esas cifras muestran crédito, no causa. El test que lo responde es un holdout geográfico: AppLovin apagado en regiones emparejadas y encendido en todas las demás, al mismo tiempo, con los resultados sacados de los datos de las stores y del backend y reportados como ROAS incremental con un intervalo de confianza. Lo que cambia la respuesta es si puedes medir el resultado por geografía. Los países sirven para cualquier app; los estados y las áreas metropolitanas de Estados Unidos, solo si tus datos permiten dividir el país así. Si no, la respuesta es que todavía no lo sabes.

Alcance: campañas de apps de AppLovin Ads (iOS y Android) atribuidas a través de un MMP, en cualquier región, con las páginas de AppLovin, Impact, Apple, Google, Meta y Haus verificadas el 1 de octubre de 2026. Las páginas de soporte de AppLovin no llevan fecha de actualización, así que toma la fecha de verificación como la única fecha.

No he publicado ningún resultado de incrementalidad de AppLovin. Lo que sigue es el método que aplicaría en una cuenta, construido a partir de la propia documentación de AppLovin y de las herramientas públicas de experimentos, no un informe de resultados.

¿Qué se atribuye AppLovin en una cuenta de app?

En apps, AppLovin no decide la atribución por su cuenta. Su página Set up MMP tracking dice que para lanzar campañas en AppLovin Ads tienes que configurar el tracking con un mobile measurement partner (Adjust, AppsFlyer, Kochava, Tenjin, Singular o Branch), y que el tracking debería estar configurado antes de que se active ninguna campaña. AppLovin renombró su plataforma como AppLovin Ads y la abrió a todos los anunciantes el 22 de junio de 2026; Axon sigue siendo el nombre de su sistema de recomendación con IA.

Las páginas de cada partner detallan los ajustes. La página de AppsFlyer de AppLovin pide postbacks de instalación y de eventos in app para “All media sources, including organic” (todas las fuentes de medios, incluido el orgánico), la atribución view through de instalaciones activada, un lookback de click through de al menos 7 días y un lookback de view through de al menos 24 horas. Su página de Adjust pide datos de todas las fuentes de atribución, una ventana de click de al menos 7 días y una ventana de impresiones de al menos 24 horas.

Así que la afirmación de que AppLovin cuenta solo clicks, y de que por tanto es conservador, no debería trasladarse a las apps. Viene del artículo de AppLovin de junio de 2026 Different numbers, one channel: making sense of AppLovin through a measurement lens, que está escrito sobre todo para marcas de ecommerce y de consumo y dice que ahí el reporting en la plataforma recoge solo la atribución click through.

Una ventana de view through muestra que AppLovin sirvió un anuncio a ese dispositivo dentro de la ventana previa a la instalación y que el MMP le dio el crédito. No muestra que el anuncio causara la instalación. Alguien que vio un playable y habría instalado desde la búsqueda esa misma noche se cuenta igual. Los postbacks orgánicos tampoco significan que AppLovin reciba crédito por los usuarios orgánicos; le envían a AppLovin datos de cada instalación y cada evento, mientras que el MMP sigue decidiendo a quién se le da el crédito.

El revenue atribuido también puede estar mal antes de que la incrementalidad entre siquiera en juego. En la prueba de estrategias de puja de Google Ads de $27K que corrí en febrero de 2026, el evento de revenue de la cuenta enviaba $1 en lugar de $0 cuando una conversión no tenía valor. Eso infló el ROAS que reportó Google en todos los casos, y sobre todo en iOS. Así que antes de probar qué causa una red, comprobaría qué se le está enviando. Los números atribuidos también discrepan entre sí cuando no hay nada roto, y el artículo sobre por qué Google Ads, tu MMP y SKAN reportan conversiones de iOS distintas explica qué brechas son normales.

¿Qué significa en realidad un porcentaje de incrementalidad?

Depende del denominador, y dos números muy distintos reciben la misma etiqueta.

  • Lift sobre una línea base: el porcentaje en que las regiones tratadas superan lo que el control predice para ellas. La base es lo que habría pasado sin AppLovin.
  • Parte incremental del revenue atribuido: el porcentaje del revenue que se le acreditó a AppLovin que no habría existido sin él. La base es el revenue atribuido.

Ninguno de los dos es una cifra de costo. Una cifra de lift no dice nada sobre eficiencia hasta que divides el revenue incremental entre el gasto que lo produjo. El número que yo reportaría es el ROAS incremental, el revenue incremental dividido entre el gasto de AppLovin en las regiones tratadas, junto al ROAS atribuido de las mismas regiones y fechas. El incremental también puede salir por encima del atribuido: en una cuenta que estudié, los días con 100 instalaciones pagadas más de Meta en iOS mostraban en el MMP unas 28 instalaciones orgánicas más, señal de que la atribución también puede quedarse corta con el paid.

Antes de actuar según la cifra de lift de cualquiera, querría saber qué resultado se midió, cuánto se gastó, cuánto duró el test y lo ancho que es el intervalo.

¿Por qué apagar y encender AppLovin no lo responde?

Porque las semanas también cambian. Apagar AppLovin en marzo y volver a encenderlo en abril compara dos meses distintos: la estacionalidad, un evento de live ops, un destacado en la store, un test de precios y los cambios en Meta o Google caen todos en la misma comparación, y el gasto en paid se arrastra a instalaciones orgánicas posteriores. La página Intro to analysis de Meridian, de Google, estima el contrafactual con una regresión basada en el tiempo, que necesita series temporales del periodo previo al test y del propio test, más el diseño y la asignación de geos hechos antes del test. El grupo de control tiene que correr al mismo tiempo que el tratamiento.

¿Cómo diseñaría un holdout geográfico para AppLovin?

Elige una unidad geográfica que puedas segmentar y medir. La Campaign Management API de AppLovin segmenta por country_code. Solo dentro de Estados Unidos, acepta también region_codes (estados) o metro_names (áreas metropolitanas), que no se pueden combinar. No encontré ningún campo de exclusión geográfica, así que una región de holdout es simplemente una que dejas sin segmentar.

Acepta que el test rompe durante un tiempo el consejo de escalado de AppLovin. Scale your campaign recomienda seleccionar todos los países a los que das soporte con un único presupuesto global, y un presupuesto que dé para entre 15 y 20 conversiones diarias como mínimo en toda la campaña. Un holdout quita regiones a propósito, así que las regiones tratadas siguen necesitando presupuesto suficiente para ese volumen de conversiones.

Dimensiónalo antes de gastar. La GeoLift Methodology de código abierto de Meta combina el control sintético aumentado para la estimación con el control sintético generalizado para la inferencia, y sus calculadoras de potencia sugieren la duración del test, la inversión y qué mercados usar y cuántos. Para los tests que hace con marcas, el artículo de medición de AppLovin dice que los holdouts suelen ser del 20 al 50% de la huella geográfica, diseñados para al menos un 90% de potencia estadística, y que las campañas deberían haber salido de la fase de aprendizaje y tener una entrega estable antes de que empiece un test. Son cifras para marcas, no una regla para apps, pero el requisito de potencia sí se traslada.

Mantén constante todo lo demás. Deja sin cambios el goal, el target y el set de creativos de AppLovin, y no reconstruyas campañas durante el test: la API fija goal_type y roas_day_target solo en la creación. Deja iguales los presupuestos de los demás canales, los precios, las promociones y los live ops en las regiones tratadas y de control, o que al menos se muevan a la par.

Córrelo más allá de la ventana de optimización. La página Setting up your app campaign de AppLovin ofrece targets Day 7 y Day 28 y dice que las ventanas más largas “generally target highest value users” (en general apuntan a los usuarios de mayor valor). Si la campaña optimiza a Day 28, las cohortes instaladas durante el test tienen que madurar hasta la misma edad en ambos grupos antes de que yo lea el revenue.

Pregunta Qué la responde De dónde salen los números Qué no puede decirte
¿Qué se atribuyó AppLovin? La atribución del MMP, con ventanas de click de al menos 7 días y ventanas de view de al menos 24 horas Reportes del MMP Si esos usuarios habrían llegado de todos modos
¿Qué partner tocó el pedido? Incrementality % de Impact El modelo de atribución de Impact Nada causal; no tiene grupo de control
¿Qué causó AppLovin? Holdout geográfico, lift y ROAS incremental con un intervalo Consolas de las stores por territorio, revenue del backend Los efectos en regiones o periodos fuera del test
¿Cómo se compara AppLovin dentro del mix a lo largo del tiempo? MMM calibrado con experimentos Series temporales de gasto y de resultados La causa, salvo que un experimento lo ancle

¿De dónde salen los datos de resultados?

No del dashboard de AppLovin, ni solo de las instalaciones atribuidas por el MMP, porque esos son los números que se están poniendo a prueba. App Store Connect Analytics te deja filtrar las métricas de la app por territorio, que Apple determina por la dirección de facturación del cliente. La página View app statistics de Google Play lista country/region, el país o la región del usuario, como dimensión. El revenue sale de tu backend de suscripciones o de tu propio libro contable, dividido de la misma forma.

Ninguna de las dos consolas de store lista los estados de Estados Unidos, así que un test por estados o áreas metropolitanas necesita datos de resultados que registren el estado. Yo lo confirmaría antes de elegir el diseño, porque decide si Estados Unidos se puede dividir siquiera.

¿Cómo leo el resultado?

Reportaría cuatro números: instalaciones incrementales, revenue incremental, ROAS incremental y su intervalo de confianza, junto al ROAS atribuido de las mismas regiones y fechas. El análisis de Meridian reporta la misma estructura: lift, lift porcentual, intervalos de confianza, valores p y conversiones incrementales por dólar, que equipara al ROAS incremental cuando el resultado es revenue.

Un resultado que no es significativo suele ser no concluyente, no un cero: el intervalo muestra qué tamaño de efecto pudo habérsele escapado al test. Si el intervalo es ancho, el siguiente paso es un test más largo o más grande, no un veredicto. Si es estrecho, usaría la ratio entre el ROAS incremental y el atribuido como factor de trabajo sobre los targets de AppLovin, solo para esas regiones y ese periodo. El artículo de medición de AppLovin describe un test de incrementalidad como un experimento de un momento concreto en el que el tamaño del holdout, el nivel de presupuesto, la duración del test, la composición de los geos y la estabilidad de la campaña interactúan entre sí, así que volvería a testear cuando cambien.

¿Dónde encajan el MMM y los estudios de lift?

El MMM ayuda cuando un experimento lo ancla. La página Calibrate treatment priors de Meridian dice que los experimentos y los MMM suelen tener estimandos distintos: el contrafactual del MMM es gasto cero, mientras que algunos experimentos miden contra un gasto reducido, en una ventana, una región y una configuración concretas. Dice que no hay una fórmula única para traducir un experimento a un prior, y su CalibrationBuilder añade incertidumbre a los experimentos más antiguos y ajusta por la escala del gasto. Un MMM sin ningún experimento detrás da una estimación del efecto de AppLovin, no un test de ese efecto.

Los resultados de lift de AppLovin publicados que encontré tratan de marcas. El artículo de Haus Is AppLovin More Than a Hype Channel? Lessons From Haus Incrementality Tests cubre holdouts geográficos de enero de 2025 a marzo de 2026. Los anunciantes que aparecen en él son marcas DTC y omnicanal, así que es un contexto útil pero dice poco sobre apps o juegos. Si una red se ofrece a hacerte un test de lift, pide el diseño, la fuente de los datos de resultados y el intervalo antes de que empiece el test. El equipo de una red ve una sola red, y por eso mismo no puede ser quien decida sobre todo el mix; el artículo sobre quién debería llevar la UA de un juego móvil después del soft launch trata ese tema.

¿Por qué el Incrementality % de Impact es crédito modelado y no lift?

Esto surge cuando un canal de partners o afiliados convive con AppLovin y reclama los mismos usuarios. El Incrementality FAQ de Impact define Incrementality % como el crédito fraccional total del modelo dividido entre el total de pedidos en los que participó el partner. El modelo es un “U-Shaped Time Decay Attribution Model” con un decaimiento temporal de 7 días que da más peso a la primera y a la última interacción. La misma página dice que un Incrementality % alto significa que el partner está aportando “real additional value” (valor adicional real).

La puntuación solo describe la posición de un partner en los caminos que vio Impact, no lo que habría pasado sin él. El Incrementality by Partner Report divide los roles en % Introduce, % Influence, % Close y % Solo, define Adjusted CPA como el costo total de las acciones dividido entre las acciones incrementales y Adjusted ROAS como el revenue incremental dividido entre el costo total de las acciones, y recomienda al menos 30 días de datos. Esas entradas incrementales son el crédito modelado, así que las cifras ajustadas también son modeladas. La página Incrementality Dashboard Explained dice que la función necesita ediciones o complementos específicos. La misma lógica de holdout responde a la pregunta causal para un partner.

¿Dónde encaja esto en mi trabajo?

Para un juego que compra en AppLovin junto a Meta, mi página de UA de juegos móviles explica cómo encajan los dos. El growth audit lee lo que se le envía a cada red y dice cuándo la atribución no puede zanjar una pregunta, como la de si AppLovin fue incremental, que antes necesita un test. Se puede reservar por separado, con cualquier nivel de gasto.

Fuentes

Todas verificadas el 1 de octubre de 2026.

Preguntas frecuentes

¿AppLovin cuenta instalaciones view through en las campañas de apps?

En las campañas de apps, la atribución pasa por tu MMP, y las páginas de configuración de AppLovin piden ventanas de view through. Su página de AppsFlyer pide que la atribución view through de instalaciones esté activada, con un lookback de view through de al menos 24 horas junto a un lookback de click through de al menos 7 días, y su página de Adjust pide una ventana de impresiones de al menos 24 horas. La afirmación de que AppLovin reporta solo clicks viene de su artículo de medición de junio de 2026, escrito sobre todo para marcas de ecommerce y de consumo, y describe el reporting de AppLovin en su propia plataforma.

¿Apagar AppLovin y volver a encenderlo demuestra si es incremental?

Por sí solo, no. Una comparación de antes y después mezcla el canal con todo lo demás que cambió en esas semanas: la estacionalidad, los eventos de live ops, los destacados en la store, otros canales y el arrastre del gasto anterior. Lo que separa a AppLovin del calendario es un holdout geográfico: regiones sin AppLovin medidas en las mismas semanas que las regiones con él, frente a un modelo ajustado con las semanas previas al test.

¿Puede el MMM decirme si AppLovin funciona para mi app?

Puede apoyar la respuesta, no zanjarla. La documentación de Meridian de Google dice que los experimentos de incrementalidad son quizá la base más sólida para fijar los priors del modelo, y avisa de que los experimentos y el MMM suelen definir el ROI de forma distinta: el contrafactual del MMM es gasto cero, mientras que un test puede comparar contra un gasto reducido, en su propia ventana de tiempo, sus regiones y sus ajustes de campaña. Un modelo sin ningún experimento detrás es una estimación del efecto de AppLovin, no una prueba.

¿El Incrementality % de Impact es el resultado de un test de lift?

No. Impact lo define como el crédito fraccional total de su modelo de atribución en forma de U con decaimiento temporal, dividido entre el total de pedidos en los que participó el partner, con el primer y el último contacto como los de más peso. Describe dónde se sitúa un partner en el camino de conversión. No compara usuarios expuestos con un grupo de control, así que no puede decirte qué habría pasado sin el partner.