Toma dos semanas de instalación de la misma campaña, $10.000 de gasto y 2.000 instalaciones cada una. La semana más antigua muestra 78% de ROAS hasta la fecha y la más joven, 57%. Un dashboard que se queda ahí lee la semana más joven como la que hay que recortar. En cada antigüedad que ambas semanas han alcanzado, la más joven va cerca de 30% por delante. El revenue hasta la fecha te dijo qué antigüedad tenía cada cohorte. No te dijo cuál era mejor.
Leo las cohortes pagadas de tres maneras. A la misma antigüedad. Sobre proceeds, después de la store, los impuestos y los reembolsos. En celdas con suficientes compras para que el número signifique algo. Las cifras de cuentas de más abajo salen de estudios que he publicado, una cuenta cada uno. Cada número del ejemplo resuelto es aritmética sobre un supuesto marcado como tal.
¿Por qué engaña el revenue hasta la fecha?
El revenue se acumula con el tiempo. Una cohorte instalada hace 56 días ha tenido 56 días para pagar, renovar y ver anuncios. Una instalada hace 14 días ha tenido 14. Si comparas sus totales, has sumado antigüedad al rendimiento. La solución es indexar cada cohorte por días desde la instalación y comparar solo en las antigüedades que ambas hayan alcanzado.
Las herramientas ya funcionan así, y por eso desconfío de cualquier reporte que no lo haga. App Store Connect Analytics de Apple reporta descarga a pago en Day 1, Day 7 y Day 35 para cada cohorte de descargas. El dashboard de cohortes de AppsFlyer agrupa a los usuarios por fecha de adquisición, cuenta esa fecha como day 0 y basa los días de cohorte en días calendario, no en el timestamp de la instalación. Un usuario que instala a las 23:50 tiene, por tanto, diez minutos de day 0. Dos herramientas pueden discrepar en el revenue de D0 solo por esa razón.
Los puntos de control son convenciones. Apple eligió 35 días, SKAN termina en el día 35, muchos equipos usan 28. Lo que no es una convención es la regla que hay debajo. Misma antigüedad, o no hay comparación. Mi rutina es D0 y D7 para la lectura temprana y D28 para la decisión, en el reporte de cohortes del MMP. D28 es la antigüedad contra la que comprobé el day 0 en el estudio de $606K, donde el ROAS de day 0 ordenó 38 campañas de Meta casi igual que el de day 28, con una correlación de rango de +0,96, parte de la cual ya viene incorporada, ya que el revenue de day 0 es parte del revenue de day 28. Así que confío en D0 para ordenar cohortes entre sí, y espero a D28 para el número absoluto que comparo con el target.
¿Cómo se ve una comparación a la misma antigüedad?
A la misma antigüedad, la semana de instalación más joven va por delante cerca de 30% en cada punto de control que ha alcanzado, aunque su revenue hasta la fecha se vea peor. Todos los números de esta sección son ilustrativos. Dos semanas de instalación de la misma campaña, $10.000 de gasto y 2.000 instalaciones cada una, es decir, un CPI de $5,00. La semana A tiene hoy 56 días de antigüedad y la semana B, 14. Las celdas son proceeds acumulados por instalación, después de la comisión de la store, los impuestos y los reembolsos.
| Semana de instalación | D0 | D7 | D14 | D28 | D56 | Hasta la fecha |
|---|---|---|---|---|---|---|
| Semana A, 56 días de antigüedad | $0,90 | $1,60 | $2,20 | $3,00 | $3,90 | $7.800, 78% de ROAS |
| Semana B, 14 días de antigüedad | $1,20 | $2,10 | $2,85 | $5.700, 57% de ROAS |
La lectura equivocada es la última columna. La semana A ha devuelto $7.800 frente a los $5.700 de la semana B, así que la semana A parece tener mejor segmentación o mejores creativos, y la semana B parece candidata a un recorte. La semana A ha tenido cuatro veces más tiempo para generar revenue.
La lectura correcta es cualquier columna que ambas semanas tengan completa. En D0, B va 33% por delante. En D7, 31% por delante. En D14, $2,85 frente a $2,20, 30% por delante, que equivale a 57% de ROAS frente a 44%. La semana B es la mejor cohorte en cada antigüedad que ha alcanzado, y la lectura ingenua tenía el veredicto al revés.
Cohortes ilustrativas de la tabla de arriba, CPI de $5,00. El gráfico de la izquierda suma antigüedad al rendimiento. El gráfico de la derecha compara solo el rendimiento.
La semana B tiene 14 días y mi antigüedad de decisión es D28, así que hay una segunda pregunta. ¿Qué hago con su gasto durante dos semanas? Lo proyecto a partir de cohortes más antiguas. La semana A pasó de $2,20 en D14 a $3,00 en D28, un multiplicador de 1,36. Aplicado a los $2,85 de la semana B, da unos $3,89 por instalación en D28, o 78% de ROAS. Una sola cohorte más antigua es una suposición, así que tomo el rango de ese multiplicador de D14 a D28 en varias cohortes más antiguas. Usa cohortes con un mix parecido de países y de creativos. Digamos que el rango va de 1,25 a 1,45. La semana B queda entonces entre $3,56 y $4,13, entre 71% y 83% de ROAS en D28.
Que esa banda decida algo depende del target. Si el target de D28 es 70%, los dos extremos lo superan y la semana B puede escalar ya. Si es 75%, la banda queda a ambos lados de la línea, la semana B queda en vigilancia con un gasto constante, y la vuelvo a leer en D28. Los multiplicadores solo valen mientras el producto, los precios, el paywall y el mix de canales se mantengan cerca de los de las cohortes más antiguas. Tras un test de paywall o un mercado nuevo, vuelve a calcular el rango desde cero.
¿Qué revenue es el dinero?
Mide las cohortes sobre proceeds para cualquier decisión de rentabilidad o de payback, es decir, sobre lo que te llega después de la comisión de la store, los impuestos y los reembolsos. Para el dinero uso los proceeds de RevenueCat. Para el reparto por campaña uso el revenue del MMP, y lo trato como un número bruto para ordenar, nunca como cash.
Apple define Sales como el importe total facturado a los clientes y Proceeds como el importe que recibes, avisa de que los proceeds de Sales and Trends no son definitivos, y estima los importes en dólares estadounidenses con los tipos de cambio del mes anterior. La brecha entre los dos es la comisión y el impuesto cuando el precio lo incluye, y los reembolsos se descuentan de ambos. Expuse cómo mueven los proceeds la comisión de la store, los impuestos y los reembolsos en el artículo sobre el techo de CPA. La comisión es 30%, 26%, 15%, o 10% más un 5% de comisión de facturación, según la store, el programa, la región y la antigüedad del suscriptor, y la tabla de tarifas de 2026 de Google Play amplió aún más el rango.
RevenueCat mantiene separadas las capas. Su gráfico de revenue resta primero los reembolsos y luego estima los impuestos y la comisión para llegar a los proceeds, y su guía de reconciliación vincula el precio al cliente de Apple con su cifra de revenue y la parte del partner de Apple con sus proceeds. Dos advertencias. Los impuestos y la comisión son estimaciones de RevenueCat, no lo que declara la store. Y Charts v3 resta un reembolso el día en que ocurre, mientras que una lectura de cohortes necesita asignarlo de vuelta a la compra que revirtió, así que mueve los reembolsos a su cohorte original antes de comparar semanas.
El número del MMP es otra cosa. Adjust y AppsFlyer reportan el revenue que les haya enviado el SDK o el servidor, bruto o neto según tu configuración, y yo lo trato como bruto. Lo reportan dentro de sus propias reglas y ventanas de atribución. Comparar un LTV de RevenueCat con un ROAS de Adjust compara dos bases a la vez. Escribí sobre las tres comparaciones entre Meta, RevenueCat y Adjust y las verificaciones que hacen que una diferencia sea confiable. Para este artículo la regla es una base, una moneda, un calendario, en cada nivel del análisis.
¿Qué tan pequeña puede ser una celda antes de que el número no signifique nada?
Una celda necesita 50 compras antes de que yo la lea, porque cada desglose que añades multiplica las celdas y divide a los usuarios de cada una. Una campaña con 2.000 instalaciones repartidas en 10 países, 2 stores y 5 creativos da 100 celdas de 20 instalaciones. Con una tasa de pagadores de 3%, eso es menos de un pagador por celda.
Saqué el número de una cuenta que medí, $1,2M en 22 semanas, donde el ROAS de un anuncio en una semana predijo mejor el ROAS de la semana siguiente cuando el anuncio tenía 50 compras o más esa semana, y aun así la correlación fue de 0,44. Por debajo de 50 no leo la celda. La agrupo, uniendo semanas o uniendo países en tiers, hasta que supera la línea.
La estadística dice lo mismo en otro idioma. Una tasa de pagadores es una proporción, y la fórmula estándar de su margen de error se comporta mal con recuentos pequeños, lo que explica que Brown, Cai y DasGupta recomienden el intervalo de Wilson como alternativa. Una tasa de pagadores de 3% sobre 1.000 instalaciones, 30 pagadores, tiene un intervalo de Wilson del 95% de aproximadamente 2,1% a 4,3%. El mismo 3% sobre 100 instalaciones, 3 pagadores, va de aproximadamente 1,0% a 8,5%. La segunda celda no puede distinguir un país fuerte de uno débil, y por mucho que la mires eso no cambia.
Dos hábitos más evitan que las celdas pequeñas te mientan. Fija la antigüedad de decisión antes de mirar, porque revisar a diario y actuar la primera vez que una cohorte cruza la línea es el problema de la parada opcional que ya conocen quienes hacen A/B tests. Y trata a un ganador sorprendente en una celda pequeña como una hipótesis. Gelman y Loken llaman a ese problema el jardín de los senderos que se bifurcan. Con suficientes desgloses, alguna celda va a verse muy bien por casualidad, y con otro conjunto de datos habría sido otra celda la que se viera muy bien. El resultado de un subgrupo cuenta cuando se repite en la siguiente semana de cohorte independiente.
¿Cómo hago bien el análisis de cohortes?
Empieza por todo el negocio por semana de instalación y después baja solo hasta donde la celda siga teniendo 50 compras o más.
- Todo el negocio, proceeds por semana de instalación, a la misma antigüedad. Reconcilia primero con los totales de la store y de RevenueCat.
- Por store. Las tablas de tarifas, los regímenes de atribución y las reglas de reembolso varían, así que lee iOS y Android antes de mezclarlos.
- Por canal, sobre la base del MMP, siguiendo la ratio entre el número de la plataforma y el número del MMP como factor de calibración.
- Por campaña dentro del canal.
- Por país dentro de la campaña, solo donde el país supera el umbral.
- Por creativo, el nivel más ruidoso. Léelo como una señal de dirección y agrupa semanas.
¿Cómo comparo el ROAS entre países de forma justa?
Compara los países a la misma antigüedad de cohorte, sobre proceeds por instalación, dentro de una sola store, con la tasa de pagadores y su intervalo al lado, porque los países difieren en lo que vale un pagador antes de cualquier diferencia en lo bien que funcionan los anuncios. Apple fija precios comparables en 175 storefronts con los impuestos y los tipos de cambio ya incorporados, y los desarrolladores pueden cambiar cualquiera de ellos a mano. Cuando el precio incluye IVA, la comisión se calcula después del impuesto. La tarifa de la store puede cambiar según la región. El mix de planes cambia, así que los proceeds por pagador también cambian aunque el precio sea el mismo.
Luego está el mix. Dos campañas pueden ordenarse en un sentido dentro de cada país y en el contrario en blended, que es la paradoja de Simpson, llamada así por el artículo de 1951 de Edward Simpson, aplicada a un plan de medios. Ilustrativo: la campaña X corre a 70% de ROAS en Tier 1 con $8.000 y a 130% en Tier 3 con $2.000, y en blended da 82%. La campaña Y corre a 60% en Tier 1 con $2.000 y a 120% en Tier 3 con $8.000, y en blended da 108%. X gana a Y en cada tier y pierde en blended, únicamente por dónde fue el gasto. La comparación correcta depende de qué mix puedes comprar de verdad a escala, y solo lo descubres mirando por dentro.
En mi auditoría de $383K de gasto de Meta tROAS, un país había corrido a 28% de ROAS durante tres meses dentro de una campaña que marcaba 70% blended, y nada a nivel de campaña se movió. Califiqué cada país en D0 y en All ROAS contra el target propio de la campaña, esperé tres meses antes de excluir nada, y fijé primero un piso de gasto, porque un país con $80 detrás tiene un ROAS ruidoso, no un veredicto. Esa auditoría muestra el problema del mix a nivel de país. Lo que añade este artículo es la regla de la misma antigüedad y el umbral.
¿Qué pasa con el revenue que el MMP llama orgánico?
Una parte es revenue pagado que el MMP no pudo rastrear. Bajo ATT, una parte del revenue pagado de iOS no tiene ningún click que rastrear, así que cae en orgánico, y una tabla de cohortes solo muestra el revenue que pudiste atribuir. En las instalaciones orgánicas y pagadas de iOS de una cuenta a lo largo de 103 días, en los días con 100 instalaciones pagadas adicionales en iOS aparecieron cerca de 28 instalaciones orgánicas más en iOS, una pendiente de 0,277 en iOS frente a 0,059 en Android, donde el install referrer todavía funciona. Las cohortes pagadas de iOS de esa cuenta se veían como un piso, y la brecha entre las dos pendientes es la parte que hay que dimensionar con un holdout.
SKAN hace el piso más bajo y más tardío. Con SKAN 4, una campaña recibe como máximo tres postbacks, que cubren los días 0 a 2, 3 a 7 y 8 a 35, el fine value llega solo en el primero, y en el tier de crowd anonymity más bajo no llega ningún valor. Todo el revenue posterior al día 35 que un dashboard asigna a una campaña de iOS es modelado. El reporting de Meta funciona con sus propias ventanas, y su documentación para desarrolladores dice que Facebook por lo general tiene una ventana de atribución mayor que la mayoría de los mobile measurement partners. Así que mantén separadas tres capas y no las juntes en un solo ROAS. Proceeds atribuidos de forma determinista, el piso del paid. Proceeds modelados o probabilísticos, etiquetados con el método. Proceeds no atribuidos, reportados por separado y asignados al paid solo mediante un supuesto declarado, como un halo medido o un resultado de holdout.
Tampoco está resuelta la dirección de la interacción con el orgánico, y yo no la daría por hecha a tu favor. En eBay, Blake, Nosko y Tadelis encontraron retornos de la búsqueda pagada que eran una fracción de lo que decía la atribución, con anuncios de keywords de marca que no mostraron ningún beneficio medible a corto plazo. En un gran desarrollador de juegos móviles de EE. UU., Ju, Zhao y Aral encontraron el signo contrario. Apagar sus anuncios en todo el mundo redujo entre 20% y 30% las instalaciones orgánicas, y cada $100 de gasto vino acompañado de unas 32 instalaciones pagadas y 2 orgánicas, que ellos atribuyen a que las instalaciones pagadas mejoran el ranking en la store. Es un preprint de una sola empresa, revisado en julio de 2026, y las cifras cambiaron entre versiones. Otro canal, otro producto, otra respuesta. Tu cuenta tiene su propio número, y los dos reportes de mi artículo sobre el orgánico en iOS son por donde empiezo a buscarlo.
¿Cuándo tiene una cohorte la antigüedad suficiente para juzgarla?
Tres pruebas, y una cohorte tiene que pasarlas todas.
Las ventanas se han cerrado. La ventana de SKAN de 35 días más el retraso del postback, la ventana de atribución de la plataforma, la exposición principal a reembolsos y la finalización de los proceeds por parte de la store. Antes de eso, parte del número todavía está llegando.
Los eventos de revenue han tenido tiempo de ocurrir. Un plan anual se puede leer poco después de que el trial convierte, y la siguiente incógnita es la renovación dentro de un año. Un plan mensual no habrá renovado todavía en D28, así que saco ese revenue de la curva de cohortes más antiguas y dejo que decida la banda de más abajo. Los juegos con compras y anuncios siguen generando revenue, así que la madurez es cuestión de criterio, y la tercera prueba, más abajo, es donde lo aplico. Cuánto tiempo puedes esperar es tarea del techo, y el techo se fija antes de que exista la cohorte.
El revenue posterior no cambiaría la decisión. La banda del ejemplo resuelto. Si los multiplicadores bajo y alto de cohortes más antiguas dejan a la cohorte joven del mismo lado del target, la decisión está tomada, y esperar solo añade precisión a un veredicto que no va a cambiar. Si caen a ambos lados, la cohorte sigue en vigilancia.
¿Qué no puede decirte una tabla de cohortes?
No puede decirte qué causó el gasto. La atribución es un libro contable de quién quedó asociado a qué, bajo las reglas de un solo sistema. Gordon, Zettelmeyer, Bhargava y Chapsky compararon 15 experimentos de publicidad en Facebook, 1.600 millones de impresiones, con los métodos observacionales que los equipos usan a diario, y encontraron que esos métodos a menudo no lograban recuperar lo que medían los experimentos, incluso con un condicionamiento extenso. Dos de los autores trabajaban en Facebook, los datos son de Facebook, y los experimentos fueron campañas de Facebook de 2015 en EE. UU., no instalaciones de apps, lo cual es una razón para leerlo con cuidado, no una razón para descartarlo. Solo un holdout o un experimento geográfico responde a la pregunta causal, y incluso esos son ruidosos. Lewis y Rao mostraron en 25 experimentos de campo que las compras individuales son tan volátiles en relación con el costo de los anuncios que los intervalos informativos necesitan muestras enormes. Expuse cómo haría el test para una red en el artículo sobre la incrementalidad de AppLovin.
No puede decirte el origen del revenue de SKAN pasado el día 35 ni por debajo del umbral de crowd anonymity. No puede decirte qué hará una cohorte tras un cambio de precio, un paywall nuevo, un mercado nuevo o una nueva tabla de tarifas, porque los multiplicadores asumen que el futuro se parece a las cohortes más antiguas. Y la reconciliación entre sistemas explica las brechas entre ellos sin decirte qué sistema tiene la atribución correcta. Cada uno acierta para una pregunta distinta: la store para el cash, RevenueCat para el estado de las suscripciones, el MMP para el crédito entre redes, la plataforma de ads para su propia señal de optimización. Y si la pregunta es por qué empeoró una cohorte y no cuál es mejor, eso es mi diagnóstico para un CPI que sube y un ROAS estancado, y empieza por el registro de cambios, no por la tabla de cohortes.
¿Qué deberías comprobar antes de decir que una cohorte es rentable?
- La misma antigüedad. Cada comparación en un día que ambas cohortes hayan alcanzado, D0 y D7 para ordenar, D28 para decidir.
- Proceeds. Después de la comisión, los impuestos y los reembolsos, con los reembolsos devueltos a la cohorte de la que vinieron, en una sola moneda y un solo calendario.
- El umbral. 50 compras en la celda, o la agrupas.
- Store antes que blend. iOS y Android se leen por separado antes de cualquier número combinado.
- La comprobación del mix. ¿El ganador sigue ganando dentro de cada tier de países?
- Replicación. Una celda sorprendente tiene que repetirse en la siguiente semana de cohorte.
- La banda. Para cohortes jóvenes, un multiplicador bajo y uno alto de cohortes más antiguas, y una decisión solo cuando ambos caen del mismo lado del target.
- La capa orgánica. Proceeds deterministas, modelados y no atribuidos, mantenidos por separado.
Si no puedes completar esas ocho líneas para tu cuenta, el growth audit es donde leo las cohortes y aplico los umbrales en una cuenta, y se puede reservar por separado, con cualquier nivel de gasto.
Fuentes y alcance
Todas verificadas el 5 de octubre de 2026. La documentación de las plataformas cambia sin aviso, así que revisa la fecha antes de citar una ventana o una tarifa. El ejemplo resuelto, la ilustración de la paradoja de Simpson y los intervalos de Wilson son aritmética sobre supuestos marcados como tales, no datos de una cuenta. Las cifras de cuentas que enlazo corresponden a una sola cuenta cada una, observadas y no experimentales.
- Apple: Analytics dashboard, App Store Connect Analytics Help.
- Apple: View units, proceeds, sales, and pre-orders, App Store Connect Help.
- Apple: Manage pricing for auto renewable subscriptions, App Store Connect Help.
- AppsFlyer: Cohort and retention dashboard, AppsFlyer Help Center.
- Adjust: How SKAdNetwork 4 works, Adjust Help Center.
- Apple: Changes for apps in the European Union, actualizado el 18 de agosto de 2026, para la tarifa del 26% dentro de la App Store.
- Google: Service fees, Play Console Help.
- Meta: App Events API, Meta for Developers.
- RevenueCat: Revenue chart, Charts v3 y Reconciling with App Store Financial Reports, RevenueCat Docs.
- Brown, Cai y DasGupta: Interval Estimation for a Binomial Proportion, Statistical Science 16(2), 2001.
- Gelman y Loken: The Statistical Crisis in Science, American Scientist 102(6), 2014.
- Simpson: The Interpretation of Interaction in Contingency Tables, Journal of the Royal Statistical Society, Series B 13(2), 1951.
- Stanford Encyclopedia of Philosophy: Simpson’s Paradox, como texto explicativo.
- Gordon, Zettelmeyer, Bhargava y Chapsky: A Comparison of Approaches to Advertising Measurement, Marketing Science 38(2), 2019, 15 experimentos de Facebook en EE. UU., dos autores en Facebook.
- Blake, Nosko y Tadelis: Consumer Heterogeneity and Paid Search Effectiveness, Econometrica 83(1), 2015, eBay, autores vinculados a eBay en ese momento.
- Ju, Zhao y Aral: Advertising Spillovers in Mobile Apps: Evidence from Ad Shutoffs and Store Rankings, preprint de arXiv, enviado en abril de 2025 y revisado en julio de 2026, un desarrollador de juegos de EE. UU.
- Lewis y Rao: The Unfavorable Economics of Measuring the Returns to Advertising, Quarterly Journal of Economics 130(4), 2015.
Preguntas frecuentes
¿Cómo sé cuáles de mis cohortes de instalaciones pagadas de una app están haciendo payback de verdad?
Alinea cada cohorte por días desde la instalación y compáralas solo en las antigüedades que ambas hayan alcanzado, sobre proceeds después de la comisión de la store, los impuestos y los reembolsos. El revenue hasta la fecha premia a la cohorte más antigua por ser más antigua. Leo D0 y D7 como lectura temprana, decido en D28, y solo en celdas con 50 compras o más. Por debajo de eso agrupo semanas, o agrupo países en tiers.
¿Cómo hago bien el análisis de cohortes en la adquisición pagada de usuarios?
Empieza por todo el negocio por semana de instalación, después divide por store, luego por canal, luego por campaña, y baja a país y creativo solo donde la celda siga teniendo 50 compras o más. Compara las cohortes solo a la misma antigüedad, mantén una base de revenue, una moneda y un calendario en cada nivel, y trata a un ganador sorprendente en una celda pequeña como una hipótesis que hay que volver a probar en la siguiente semana de cohorte.
¿Debo medir el ROAS de cohorte sobre el revenue bruto o sobre los proceeds?
Mide el ROAS de cohorte sobre proceeds para cualquier decisión de rentabilidad o de payback. Apple y Google se llevan su comisión una vez descontado el impuesto cuando el precio lo incluye, y los reembolsos te quitan lo que ya habías recibido. El revenue del MMP y de las plataformas de ads es bruto o neto según lo que haya enviado el SDK, así que lo trato como bruto, uso los proceeds de RevenueCat como el dinero y el revenue del MMP solo para repartir ese dinero por campaña.
¿Cómo mido el ROAS entre países sin engañarme?
Compara los países a la misma antigüedad de cohorte, sobre proceeds, dentro de una sola store antes de mezclar las stores, y solo donde el país supere el umbral de compras. Los precios, los impuestos, la tarifa de la store y el mix de planes cambian de un país a otro, así que un número blended esconde la dispersión. En mi auditoría de $383K, un país corrió a 28% de ROAS durante tres meses dentro de una campaña que marcaba 70%.
¿Cuándo tiene una cohorte la antigüedad suficiente para juzgarla?
Una cohorte tiene la antigüedad suficiente para juzgarla cuando sus ventanas de reporte se han cerrado, los eventos de revenue que importan han tenido tiempo de ocurrir y el rango de resultados plausibles ya no queda a ambos lados de tu target. Para un plan anual eso ocurre poco después de que el trial convierte. Para un plan mensual la primera renovación cae después de D28, así que ese revenue sale de la curva de cohortes más antiguas y el rango que da tiene que superar el target. Mi antigüedad de decisión es D28, y uso D0 para ordenar, porque D0 ordenó 38 campañas casi igual que D28 en mi estudio de $606K.