Cómo desarrollar una estrategia de analytics para las aplicaciones de suscripción en iOS 14.5 y las versiones posteriores

Los servicios de suscripción están en pleno apogeo, y actualmente generan un promedio de gasto por cliente de 20 dólares al mes. Además, aunque solo el 1% de las aplicaciones realizan su monetización por medio de suscripciones, más del 90% del gasto de los consumidores móviles proviene de las aplicaciones de suscripción. Con tantos ingresos en juego, es esencial que los desarrolladores sean eficientes al optimizar su embudo.

Como mencionamos en un artículo reciente creado en colaboración con gamesindustry.biz, para las aplicaciones que se monetizan por medio de suscripciones, es aun más importante contar con una buena estrategia de autorización de los usuarios tras la llegada de iOS 14.5, a fin de garantizar la recopilación de datos determinísticos sólidos en todos los puntos de su ciclo de vida. Para las aplicaciones de suscripción, el recorrido de los usuarios suele ser más largo y complejo que en otras estrategias de monetización, por lo que vale la pena tener la mayor cantidad de datos posible.

Sin embargo, incluso para los usuarios que no otorgan su autorización, el hecho de contar con un plan sólido de SKAdNetwork te dará la oportunidad de calcular el valor del ciclo de vida (LTV) de los usuarios con cierta confianza.

Consejos para obtener la autorización

Al obtener tasas de autorización altas, las aplicaciones podrán disfrutar una ventaja competitiva considerable, pues tendrán acceso a los datos determinísticos reales acerca de sus usuarios y podrán crear modelos basados en el comportamiento de los usuarios que otorgan su autorización.

El uso de solicitudes previas a la autorización puede servir para explicarles a los usuarios el beneficio que obtienen al autorizar el tracking a nivel de usuario, y existen muchos consejos para crear la mejor solicitud previa a la autorización.

Para las aplicaciones de suscripción, la información sobre los momentos en que la forma de pago de los usuarios genera un error, así como cuando ponen en pausa, cancelan o reanudan sus suscripciones, son datos clave que pueden ayudar a optimizar la aplicación. Con la solución de tracking de suscripciones de Adjust, puedes obtener una vista sin precedentes del ciclo de vida de los usuarios. Sin embargo, al no contar con el IDFA, cada vez es más difícil obtener datos confiables sobre la manera en que los usuarios recorren este laberinto hacia la conversión.

Uso de SKAdNetwork

Las aplicaciones que se monetizan por medio de suscripciones enfrentan una dificultad doble en iOS 14.5 y las versiones posteriores. En primer lugar, tienen el desafío de diferir de manera confiable el temporizador de SKAdNetwork más allá de 24 horas, incluso si puede resultar útil para recopilar señales de los usuarios.

Aunque es posible extender el temporizador al utilizar un bit para prolongar la ventana de conversión, el cual simplemente active una actualización del valor de conversión (por ejemplo, de 000001 a 000011 y así sucesivamente) a fin de ganar otras 24 horas, esto requiere que el usuario inicie sesión todos los días para que el activador del valor de conversión se pueda ejecutar con la aplicación en primer plano. Si el usuario no vuelve a abrir la aplicación, no se puede actualizar el valor de conversión, por lo que no recibirás los datos que esperabas recopilar al prolongar el temporizador.

Además, es difícil obtener suficientes datos por parte del usuario durante las primeras 24 horas como para hacer predicciones confiables a largo plazo. Debido al límite de 6 bits para los valores posibles, el número de puntos de contacto potenciales es bastante limitado, por lo que debes concentrarte en los más significativos y aprovechar al máximo las primeras 24 horas.

Señal vs. Ruido

Existen dos opciones principales para utilizar los 6 bits que te permite SKAdNetwork. La primera es el uso de un enfoque de "enmascaramiento de bits", con el que cada uno de los 6 bits se asigna a un evento, y el valor de 0 o 1 del bit correspondiente te indica si el evento se presentó o no.

Nuestra solución estándar de SKAdNetwork te permite asignar los eventos de conversión a los eventos de suscripción de los que ya estás haciendo el tracking en el Dashboard de Adjust.

La segunda opción es asignar rangos de valores a los diferentes valores de conversión, lo que te permite crear "buckets" de usuarios según su posición dentro de los rangos que defines. Nuestro sistema avanzado de administración de valores de conversión te permite crear esquemas personalizados para definir estos buckets.

Para las aplicaciones de streaming de video o citas, el engagement de los usuarios es una de las métricas más importantes, por lo que algunas empresas están haciendo la optimización mediante las condiciones "sessions" en nuestra solución avanzada de valores de conversión.

La condición "sessions" te permite hacer el tracking del total de sesiones registradas. En el siguiente ejemplo, el valor de conversión "3" se devolverá si el usuario registra entre 5 y 10 sesiones.

"sessions": { "count_min": 5, "count_max": 10 }

• count_min (el valor predeterminado es 1): el número total de sesiones con tracking no debe ser menor que el número especificado;
• count_max (el valor predeterminado es ilimitado): el número total de sesiones con tracking no debe ser mayor que el número especificado;

Creación de un modelo

La elaboración de modelos predictivos del valor del ciclo de vida (LTV) utiliza el comportamiento de un usuario en el primer día en que utiliza la aplicación para predecir los ingresos que generará a mediano plazo. Esta elaboración de modelos predictivos funciona mejor cuando se usa en buckets o categorías más amplias.

Por este motivo, las aplicaciones de suscripción pueden preferir utilizar el "inicio de una prueba" como la señal de SKAdNetwork hacia la que se orienta la optimización, ya que esto puede suceder de manera más confiable durante la ventana en la que tienen visibilidad, y porque es una acción llena de intent que se presenta dentro de esa ventana inicial.

Sin embargo, el uso del "inicio de una prueba" sin ningún otro dato puede resultar contraproducente. Además, al no contar con información sobre los eventos que se presentan durante la prueba, sin el IDFA, será aún más difícil suponer que una prueba gratuita se convierta forzosamente en un usuario que genera ingresos.

La versión de prueba

Por este motivo, puede ser mejor tomar en cuenta el "inicio de una prueba" junto con otra señal relacionada que tenga el potencial de enriquecer el tipo de prueba. Por ejemplo, un usuario puede activar el "inicio de una prueba" y recibir la asignación de un valor de conversión inicial. Luego, puedes actualizar el valor de conversión si el usuario cancela la prueba durante la ventana de valor de conversión. Al hacer esto, se elimina inmediatamente a un gran número de personas que tienen pocas probabilidades de hacer un pago y se crea un bucket amplio de usuarios con "prueba cancelada", los cuales podemos suponer que tendrán un LTV menor.

Por otro lado, podrías hacer el tracking de las personas que se inscriben en una prueba gratuita e incluyen su información de pago. Las personas que incluyen su información de pago indican desde el principio que están dispuestas a hacer una conversión, por lo que tal vez tengan más probabilidades de convertirse en usuarios de pago a largo plazo.

Si tienes alguna pregunta acerca de la implementación de iOS 14.5 y las versiones posteriores, comunícate con tu CSM o con tu Account Manager. Puedes descargar nuestra guía aquí o visitar nuestro centro de recursos para iOS 14.5 y las versiones posteriores.