¿Puede SKAN medir el pago de una suscripción tras el free trial?

A veces, y solo como coarse value (bajo, medio o alto), nunca como fine value. El cobro tras un free trial ocurre en Apple y llega a RevenueCat de servidor a servidor. SKAN solo registra lo que la app escribe en el dispositivo. Así que el pago cuenta solo si tu único escritor del valor de conversión se ejecuta en la app antes de que se cierre la ventana en la que cae. La duración del trial cambia la respuesta. Sin trial, el primer pago puede caer en la primera ventana como fine value. El free trial más corto que ofrece Apple (3 días) ya lo empuja a la segunda ventana, y uno de 1 semana normalmente a la tercera, los dos solo como coarse value. Un trial que termina después del día 35 se queda fuera de todas las ventanas.

Alcance: subscription apps de iOS con RevenueCat, un MMP (AppsFlyer y Singular son los dos cuyas reglas de reenvío comprobé) o Firebase, en SKAdNetwork 4 y AdAttributionKit, que compran en Meta y Google, todas las regiones. Comprobé cada dato de plataforma en la página del propio proveedor el 1 de octubre de 2026.

¿Qué pasa entre “RevenueCat registró el pago” y “el dispositivo actualizó el valor”?

Seis pasos, y el hueco está entre el tercero y el quinto.

1. Primer arranque. El reloj de Apple empieza aquí. La página de SKAdNetwork Receiving postbacks in multiple conversion windows fija tres ventanas desde el primer arranque: días 0 a 2, 3 a 7 y 8 a 35. Solo el primer postback puede llevar un fine value, que el método de actualización de Apple define como un número de 0 a 63.
2. Inicio del trial. Normalmente en el paywall de la primera sesión, dentro de la ventana 1, donde el SDK del dispositivo lo ve.
3. Pago confirmado. Cuando termina el trial, el App Store cobra. La página Event Types and Fields de RevenueCat registra un primer cobro correcto como un RENEWAL con is_trial_conversion en true. Un trial que nadie canceló no es un pago, y un entitlement activo tampoco. La página de Apple Reducing involuntary subscriber churn dice que una renovación fallida pasa a reintento de cobro hasta 60 días y que, con Billing Grace Period activado, el usuario conserva el acceso completo mientras Apple intenta cobrar.
4. Reenvío del servidor. RevenueCat envía el evento al MMP de servidor a servidor. La página SKAN Conversion Studio de AppsFlyer dice que AppsFlyer recalcula el valor, que el SDK actualiza el dispositivo si la app está abierta y que, si no, el servidor espera a la siguiente apertura de la app, que debe ocurrir antes de que venza la ventana o el evento se descarta. La S2S Support for Conversion Models FAQ de Singular describe la misma espera para una función que le pides a Singular que active. Solo funciona en su modo SKAN gestionado, y si la ventana se cierra o el usuario nunca vuelve a abrir la app, Singular no puede actualizar el valor.
5. Ejecución en el dispositivo. El SDK llama al método de actualización de Apple. El valor cae en la ventana que esté abierta en ese momento, no en la ventana en la que ocurrió el cobro. La página updatePostbackConversionValue de Apple dice que el fine value se ignora después de la primera ventana.
6. Postback. Cuando la ventana se cierra, Apple envía el postback tras un retraso aleatorio: de 24 a 48 horas para el primero, de 24 a 144 horas para el segundo y el tercero. Apple dice también que la app tiene que actualizar el valor durante cada ventana para optar a más de un postback, así que un usuario que nunca abre la app entre el día 3 y el día 7 deja la ventana 2 sin nada que reportar. Un anuncio en el tier más bajo de Apple, Tier 0, no recibe ni el segundo ni el tercer postback.

¿Quién escribe el valor de conversión?

Un solo escritor, en el dispositivo. Todos los métodos de actualización que documenta Apple son llamadas que hace la app. No encontré ninguna API de servidor.

RevenueCat no es ese escritor. Su página de Meta Ads dice que “doesn’t update SKAN conversion values” (no actualiza los valores de conversión de SKAN) y recomienda un solo actualizador, sea la app, el SDK de Meta o un MMP, para que los valores no entren en conflicto. Su página de Singular dice que no puede modificarlos desde sus eventos de servidor. Su página de AppsFlyer también te pide eliminar el seguimiento de revenue del lado del cliente para evitar contar dos veces, lo que significa que con esta configuración incluso una compra del día 0 solo puede llegar al SDK de AppsFlyer a través del reenvío del servidor.

Un segundo escritor es el fallo del que avisan los proveedores. La página de Google Set up your SKAdNetwork conversion value schema dice que es muy recomendable configurar el esquema en un solo lugar. La versión de Google Analytics de Set up your SKAdNetwork conversion value schema tiene una opción que deja al SDK de Firebase fijar el valor de cada ventana, y la página Get started with Google Analytics for iOS+ de Firebase dice que el SDK registra la app en SKAdNetwork automáticamente salvo que pongas GOOGLE_ANALYTICS_REGISTRATION_WITH_AD_NETWORK_ENABLED en NO. El artículo SKAN 4.0 anomalies explained de AppsFlyer dice que cualquier actualización anula la anterior, incluidas las actualizaciones al estilo de SKAN 3 y los registros de instalación de otro SDK. Ese artículo se publicó por primera vez en agosto de 2023 y es la versión de un proveedor, no la de Apple. La página del método de Apple no dice qué pasa cuando dos SDK lo llaman.

AdAttributionKit no añade un escritor. La página de Apple Understanding AdAttributionKit and SKAdNetwork interoperability dice que las llamadas de valor de conversión de SKAdNetwork se replican en AdAttributionKit y que solo gana una impresión entre los dos frameworks.

¿En qué ventana puede caer el primer pago?

La tabla supone que el trial empieza en la primera sesión. Un trial que empieza el día 2 mueve todas las fechas dos días más tarde. Las duraciones de trial son las duraciones de free trial que Apple lista en Set up introductory offers for auto-renewable subscriptions, donde la más corta es de 3 días. Las celdas de la ventana 2 y la ventana 3 valen solo para anuncios en Tier 1 o superior, porque un anuncio en Tier 0 no recibe ningún postback después del primero.

Súmale el retraso del postback para leerla como un calendario. Un pago de la ventana 3 llega a tu MMP entre el día 36 y el día 41 desde el primer arranque, salvo que la ventana se haya bloqueado antes.

¿Qué cubre la propia guía de RevenueCat y qué deja fuera?

La guía How to use RevenueCat server-to-server events for SKAdNetwork attribution de RevenueCat, publicada el 18 de febrero de 2025, es la guía de un proveedor más detallada que conozco sobre este problema. Sitúa los trials de menos de siete días en la ventana dos y los trials de siete días en la ventana tres, lo que coincide con la tabla, y ofrece dos soluciones: comprobar el estado del trial cada vez que la app pasa a primer plano, y un push silencioso cuando termina el trial. También dice que su enfoque no garantiza una precisión total. Lo que yo le añado:

• Los límites de Apple al push silencioso. La página de Apple Pushing background updates to your App dice que las notificaciones en segundo plano tienen prioridad baja, que la entrega no está garantizada, que el sistema puede limitarlas (Apple dice que no envíes más de dos o tres por hora) y que una notificación retenida se descarta si se fuerza el cierre de la app. Una de las conclusiones de la guía, que usar las notificaciones de servidor de Apple a través de RevenueCat registra las conversiones sin que el usuario abra la app, va más lejos de lo que respalda la documentación de Apple.
• El escritor. El código de la guía escribe en SKAdNetwork desde la app. Si el SDK de tu MMP también escribe, ahora tienes dos escritores. Yo pasaría el evento por tu único escritor.
• Pago frente a entitlement. La comprobación de la guía lee un entitlement activo que ya no está en su periodo de trial. Yo asociaría el valor al cobro realizado, porque Billing Grace Period puede mantener activo un entitlement mientras Apple todavía intenta cobrar.
• Lo que hacen las plataformas con el valor, en la sección siguiente.
• Cambios en el framework desde entonces. La página AdAttributionKit Updates de Apple lista cambios en junio de 2024 y junio de 2025, y nada en 2026 a fecha de esta comprobación.

¿Qué hacen Google y Meta con un pago de trial que llega como coarse value?

Google dice que no lo usa. La página de esquema de Google Ads dice que el modelado de conversiones de Google usa solo fine values y que “we currently do not support SKAN version 4’s coarse conversion values” (actualmente no admitimos los coarse conversion values de la versión 4 de SKAN). La misma página pide más de 10 eventos de conversión al día por cada evento del esquema y unas 50 instalaciones al día. Esas son las pautas de esquema de Google, no el umbral de privacidad de Apple, y Apple no publica ningún número de instalaciones para sus tiers. Así que, para las App Campaigns de iOS, la señal de SKAN de la que aprende Google es lo que pasa en los dos primeros días. Las conversiones modeladas de Google y su Integrated Conversion Measurement son independientes de SKAN, y pongo las tres lado a lado en por qué Google Ads, el MMP y SKAN reportan conversiones de iOS distintas.

Meta tiene su propia configuración. Configure Apple’s SKAdNetwork in Meta Events Manager te deja configurar eventos con fine values y coarse values para SKAdNetwork 4, según las recomendaciones de Meta, importando el esquema de tu MMP o a mano, y dice que Meta está introduciendo poco a poco el soporte de SKAdNetwork 4 y que quizá todavía no lo tengas. Prepare your app integration for Apple’s SKAdNetwork pide a las apps que usan el SDK de Facebook para iOS la versión 16.2.1 o posterior, y desaconseja reducir los valores de conversión o usar lock windows. AppsFlyer ofrece las dos cosas: un ajuste que deja que un revenue negativo, como un reembolso, baje el valor, y un bloqueo que envía el postback antes. Si Meta es donde va la mayor parte de tu presupuesto de iOS, decide esos dos ajustes con el consejo de Meta delante. La página de configuración dice que los eventos con coarse values pueden ayudar al rendimiento de los anuncios. No dice cómo pondera la entrega un coarse value de la ventana 3, y no encontré ninguna página de Meta que confirme postbacks de AdAttributionKit, así que no afirmo ninguna de las dos cosas.

¿Qué significa esto para el evento de optimización de Meta?

En SKAN, el pago del trial llega tarde, como coarse value, y solo para los usuarios que abren la app después de pagar. Un evento de la primera sesión llega en la ventana 1 y puede ser un fine value. Así que los eventos que SKAN puede reportar a Meta con rapidez son los tempranos: un inicio de trial, un inicio de trial con una condición que predice el pago, o un plan de pago comprado el día 0. El pago puede seguir en el esquema para las ventanas 2 y 3, como coarse value. Ahí lo leería como un reporte tardío sobre la cohorte y no contaría con él para orientar la entrega, porque Meta no dice cómo la pondera. Aggregated Event Measurement de Meta es una ruta aparte con sus propias reglas, y cuando Events Manager marca ahí el trial o la compra como no elegibles, las comprobaciones están en por qué los eventos de trial y compra no son elegibles para Meta AEM. La elección del evento en sí está en qué evento debería optimizar una subscription app.

¿Qué cambia para un juego móvil?

La mayor parte del problema de reenvío desaparece, porque el pago ocurre en la sesión. Cuando el SDK del MMP registra una compra in app en el propio dispositivo, puede escribir el valor en esa sesión, y la ventana 1 puede llevarlo como fine value. Conversion Studio de AppsFlyer puede medir el revenue total, incluido el ad revenue, a través de un solo evento, af_skad_revenue, y señala que los valores de ad revenue nunca son negativos. Un juego híbrido puede repartir sus 64 fine values de la ventana 1 entre compras, ad revenue y progresión, y usar los coarse values de las ventanas 2 y 3 para la retención o una primera compra.

La parte más difícil es el volumen. Apple fija el tier a partir del tamaño del grupo, un soft launch es pequeño por diseño, y un anuncio en Tier 0 recibe un solo postback sin valor. Menos campañas y más grandes superan los tiers antes, algo que explico en menos campañas, más señal. Qué tiene que demostrar un soft launch, y el esquema de SKAN para ello, está en UA de juegos móviles.

¿Cómo lo pruebas antes de subir el gasto?

Haría cuatro comprobaciones antes de que un esquema de trial lleve presupuesto. Cada una sale de las páginas de proveedores de arriba.

1. El escritor. Un solo SDK llama al método de actualización de Apple, y Google y Meta reciben el mismo esquema que sigue ese SDK. La opción de Firebase para fijar valores y las actualizaciones de SKAN de cualquier otro SDK están desactivadas.
2. El evento. El pago corresponde al cobro realizado, el RENEWAL de RevenueCat con is_trial_conversion, no al inicio del trial más la ausencia de cancelación.
3. Las dos rutas de reenvío. AppsFlyer documenta dos rutas para un evento de servidor: el SDK actualiza el valor al momento si la app está en uso, o el servidor lo retiene hasta el siguiente arranque de la app. Traza una conversión de trial reenviada por cada ruta en un dispositivo de prueba y anota cuándo se ejecutó la llamada de actualización.
4. La lectura de la cohorte. Para una cohorte madura, como mínimo el día 41 desde el primer arranque, compara las conversiones de trial que RevenueCat registra para los usuarios que tu MMP atribuye a esa red con los valores de pago que tu MMP decodificó para las ventanas 2 y 3. La brecha mezcla pagos escritos demasiado tarde, anuncios en Tier 0 que no reciben ningún postback posterior y diferencias de atribución entre las dos fuentes, así que repórtala como una brecha. No la escales para rellenar la diferencia.

¿Dónde encaja esto en mi trabajo?

En signal engineering, la parte de iOS se traduce en un solo escritor, un esquema hecho a la medida de tu trial y tu volumen, y por escrito lo que SKAN mostrará y lo que no, antes de que nadie juzgue una campaña con él. Si no sabes si el problema es la medición, el growth audit sirve para averiguarlo.

Fuentes

Todas verificadas el 1 de octubre de 2026.

• Apple Developer: Receiving postbacks in multiple conversion windows para SKAdNetwork, y la página de AdAttributionKit del mismo nombre, sin fechas de página.
• Apple Developer: Set up introductory offers for auto-renewable subscriptions, sin fecha de página.
• Apple Developer: Understanding AdAttributionKit and SKAdNetwork interoperability, sin fecha de página.
• Apple Developer: updatePostbackConversionValue(_:coarseValue:lockWindow:completionHandler:), sin fecha de página.
• Apple Developer: AdAttributionKit Updates, entradas de junio de 2024 y junio de 2025.
• Apple Developer: Pushing background updates to your App, sin fecha de página.
• Apple Developer: Reducing involuntary subscriber churn, sin fecha de página.
• Google Ads Help: Set up your SKAdNetwork conversion value schema, sin fecha de página.
• Google Analytics Help: Set up your SKAdNetwork conversion value schema, sin fecha de página.
• Firebase: Get started with Google Analytics for iOS+, última actualización el 1 de octubre de 2026.
• Meta Business Help Center: Configure Apple’s SKAdNetwork in Meta Events Manager, sin fecha de página.
• Meta Business Help Center: Prepare your app integration for Apple’s SKAdNetwork, sin fecha de página.
• AppsFlyer: SKAN Conversion Studio, actualizado el 26 de abril de 2026.
• Blog de AppsFlyer: SKAN 4.0 anomalies explained, publicado el 8 de agosto de 2023, modificado el 13 de noviembre de 2025.
• Singular: S2S Support for Conversion Models FAQ, actualizado el 17 de diciembre de 2024.
• Documentación de RevenueCat: Meta Ads, AppsFlyer, Singular y Event Types and Fields, sin fechas de página.
• Blog de RevenueCat: How to use RevenueCat server-to-server events for SKAdNetwork attribution, publicado el 18 de febrero de 2025, actualizado el 19 de febrero de 2025.