Análisis Predictivo de AppsFlyer: por qué ofrece una ventaja competitiva imbatible

LinkedIn LinkedIn
En la siguiente columna de AppsFlyer, se detalla paso a paso cómo fue el proceso de creación de una solución imprescindible para los desarrolladores de apps hoy en día: la de análisis predictivo. Se trata de una herramienta que permite predecir con una precisión asombrosa cuál será el comportamiento de los usuarios de la aplicación, y este texto revela las claves que hacen de ella una ventaja competitiva inimitable.

Ahora que la privacidad es la mayor preocupación de los marketers, el futuro pertenece al análisis predictivo.

El futuro es ahora.

AppsFlyer lleva trabajando en una solución de análisis predictivo desde finales de 2019, mucho antes de que la privacidad se convirtiera en un asunto tan importante.

La introducción de insights predictivos en la pila tecnológica del desarrollador medio de aplicaciones puede ofrecer a los clientes de AppsFlyer una ventaja competitiva sin precedentes, así como mejorar muchos de los productos de AppsFlyer, desde la incrementalidad hasta la protección contra el fraude.

El primer paso en la aplicación de estos insights se llevó a cabo a través de las predicciones del valor de la vida de la campaña (LTV): estimar el valor futuro de una campaña en las primeras etapas de su ejecución, y eliminar el período de espera innecesario antes de que lleguen los resultados.

Definición de la matriz de Life Time Value (LTV)

El LTV de cada campaña suele determinarse en las semanas siguientes a la instalación de una aplicación, mientras que las decisiones sobre la UA sólo se toman en tiempo real y con la información actual. Esto significa que cualquier decisión, en cualquier momento, conllevará cierto grado de incertidumbre sobre el LTV.

El gestor medio de UA podría lanzar una campaña y esperar a que lleguen los datos iniciales de LTV del usuario antes de tomar decisiones de optimización. Esto puede llevar hasta 30 días o, en muchos casos, más tiempo. El uso de herramientas avanzadas de BI y análisis puede reducir este periodo a 10-15 días.

Sin embargo, 10-15 días siguen siendo muchos. Nuestro objetivo era eliminar este periodo de espera (el “periodo de incertidumbre”) durante el cual las campañas podían perder dinero mientras esperaban los resultados. Para ello, nos propusimos el ambicioso objetivo de ofrecer un insight predictivo del LTV de los usuarios para el día 30, basándonos en las primeras 24 horas de participación de los usuarios.

Pero, ¿cómo se puede aplicar una fórmula de LTV a la infinita variedad de cálculos de LTV que utilizan los clientes de AppsFlyer?

Tras realizar un completo estudio de mercado, nuestro equipo redujo las posibilidades a tres pilares principales que encapsulan los aspectos clave de la toma de decisiones en la actividad de adquisición de usuarios:

  • Retención: medir el tiempo que se espera que un usuario utilice la aplicación
  • Compromiso: analizar el nivel de compromiso del usuario con el entorno de la aplicación
  • Monetización: puntuación del potencial de generación de ingresos de un usuario a través de anuncios, compras, etc.

Cada uno de los pilares mencionados se mide en escalas diferentes, por lo que primero debemos normalizarlos. Para ello decidimos aplicar un sistema de puntuación relativa que asocia a cada pilar una única puntuación prevista que va del 1 al 9.

Además, un factor clave a tener en cuenta es el costo de la campaña y, por tanto, medir el LTV de un usuario en relación con el costo de adquisición del mismo. Aunque no se requiere una predicción del costo porque es una cifra fija, sigue siendo necesaria una puntuación para que se ajuste al sistema de puntuación normalizado.

Crea una solución basada en los activos disponibles

Ahora era el momento de empezar a explorar los datos disponibles e identificar los data points adecuados que pueden convertirse en etiquetas y características de aprendizaje automático.

Nos dimos cuenta de que, independientemente del enfoque que utilizáramos, tendríamos que abarcar un diseño multitenencia, es decir, una solución que sirviera para el mayor número posible de clientes de AppsFlyer a pesar de las diferencias inherentes a los modelos de vertical, uso, popularidad y negocio.

Inicialmente nos centramos en los data points que estaban ampliamente disponibles en todos los clientes de AppsFlyer. Factores clave como la recurrencia, la frecuencia de uso, las compras in-app y los ingresos por publicidad dentro de la aplicación eran los componentes “obvios” con la lógica de monetización de cualquier aplicación.

Los eventos in-app de AppsFlyer son un excelente ejemplo de este tipo de datos, ya que se anima a todos los clientes a utilizarlos de una forma u otra.

Con los eventos in-app, AppsFlyer siempre ha proporcionado a sus clientes flexibilidad, tanto en el tiempo (cuando un evento debe ser activado / después de qué acciones), como en los nombres de los eventos de contenido o cualquier otro parámetro que vale la pena informar.

Por un lado, esto significa que los propietarios de las aplicaciones pueden adaptar estos eventos in-app para que se ajusten a sus propias necesidades específicas, proporcionando insights valiosos y relevantes sobre su ecosistema.

Por otro lado, parte de esta información no puede convertirse en una característica o etiqueta de aprendizaje automático, al menos no sin una capa de mediación que traduzca la información que lleva un evento in-app a la categoría correspondiente del componente LTV.

Decidimos abordar este problema desde ambos ángulos y construimos un proceso que analiza los datos históricos de los eventos de los clientes y determina la “jerarquía” probabilística de los eventos.

Paralelamente, recomendamos a nuestros clientes que asignen los eventos a las categorías correspondientes en función de la importancia de estos eventos para su lógica de LTV.

La combinación de estos métodos nos permitió aprovechar los datos históricos de los clientes y crear nuestros conjuntos de datos de entrenamiento de aprendizaje automático.

Validación del proceso

Una vez que pudimos validar con nuestros socios de diseño que los data points que elegimos eran óptimos para describir mejor el LTV del usuario, pudimos proceder a inspeccionar su distribución dentro de nuestro conjunto de datos seleccionado. La distribución de las características u objetivos dentro del conjunto de datos tiene una gran importancia para un aprendizaje automático preciso.

Trabajar con un conjunto de datos disperso, en el que casi todos los “objetivos” se distribuyen en torno al mismo punto, no dará grandes resultados. Por ejemplo, si un desarrollador de aplicaciones solo informa del nivel de progreso cuando un usuario alcanza el nivel 500, pero de hecho el 99,9% de todos los usuarios de la aplicación nunca alcanzarán ese nivel, acabaremos con una distribución de características/objetivos que no puede utilizarse para nuestra predicción de compromiso.

Este es un punto de decisión crucial en el proceso de onboarding de cualquier app, si no hace un uso significativo de AppsFlyer (enviando eventos in-app, proporcionando información de compra, y eventos de ingresos por publicidad, etc.), no podremos crear un modelo de predicción que sea fiable y suficientemente preciso. Por lo tanto, un cliente debe aprovechar al máximo las capacidades de AppsFlyer antes del onboarding.

Después de asegurarnos de que el proceso que creamos para transformar los raw data de los clientes en los componentes de LTV que deseamos predecir funciona bien (para las aplicaciones elegibles), nos centramos en garantizar que el sistema de puntuación es el adecuado, es decir, que describe con precisión los datos analizados (en términos de desviación estándar y distribución), y que puede ser más beneficioso para nuestros clientes que necesitan tomar decisiones de UA con claridad y confianza.

 

Hemos optado por aplicar la puntuación Stanine con puntuaciones en la escala de 1 a 9. Es conveniente tanto por sus diferencias de puntuación (no demasiado pequeñas para que la diferencia no pierda sentido, ni demasiado grandes para que refleje diferencias importantes entre las campañas), como por su distribución estándar de dos, que permite calcular fácilmente el percentil de una campaña.

En algunos casos, cuando la distribución de los datos no era “perfectamente normal” pero sí se asemejaba a una distribución normal, hicimos uso de las transformaciones de Box Cox para redistribuir la audiencia meta a una distribución más cercana a la normal.

La naturaleza de las series temporales de LTV impulsó nuestra hipótesis de que una solución basada en RNN probablemente podría dar los mejores resultados. Después de algunas pruebas e investigaciones, decidimos utilizar Tensorflow como marco de aprendizaje automático y empezamos a desarrollar nuestro algoritmo utilizando la API Keras.Sequential, para luego pasar a la API Functional, que permitía más flexibilidad; sin embargo, era más compleja.

Analicemos el proceso de unión de todas las piezas que han hecho posible esta solución.

Construcción del producto

Decidimos crear nuestro sistema de producción utilizando Amazon SageMaker para la inferencia en tiempo real. Amazon SageMaker ofrece una solución de endpoint en tiempo real y multitenencia, que puede personalizarse para funcionar con varios marcos de ML y admite algoritmos personalizados como el que desarrollamos.

Construcción del producto

“Este es un gran ejemplo de cómo se puede utilizar Amazon SageMaker para simplificar y agilizar el desarrollo de productos basados en el aprendizaje automático a escala. Amazon SageMaker proporcionó a AppsFlyer la flexibilidad de aportar sus propios algoritmos de ML y seguir disfrutando de las ventajas de un servicio administrado. SageMaker se utiliza para entrenar, optimizar e implementar múltiples modelos de aprendizaje automático de manera escalable, automatizada y rentable. Además, gracias al uso de los Endpoints Multi-Model, AppsFlyer pudo reducir la carga de orquestar el despliegue y las actualizaciones de múltiples modelos simplemente copiándolos a S3.”

Orit Alul y Chaitanya Hazarey, Arquitectos de Soluciones de AWS

También decidimos utilizar los servicios administrados de AWS, como AWS Lambda, Amazon SQS y AWS DynamoDB, para acelerar el proceso de desarrollo y, al mismo tiempo, seguir obteniendo la escalabilidad y la estabilidad que requería nuestro producto.

El sistema de producción ingiere eventos en tiempo real de los SDKs de los clientes, que llegan a través de temas de Kafka. Los datos de los eventos y los metadatos del usuario se almacenan en tablas de DynamoDB y se realiza un proceso de decisión por cada evento consumido.

Si se produce una inferencia después del evento actual, cuando se decide una inferencia, los metadatos del usuario “predicted” se envían a una función Lambda a través de SQS. Los datos del evento se cargan dentro de la función Lambda, se transforman para ML y se envían a SageMaker para su inferencia. Una vez que se recibe el resultado, se almacena en otra tabla de DynamoDB.

Este proceso genera puntuaciones de usuario que pueden ser solicitadas por el SDK del cliente como valores de conversión de SKAdNetwork en cualquier momento, y se actualizan con frecuencia a lo largo del tiempo para maximizar la precisión de las predicciones.

Entrenamiento de modelos

Entrenamiento de modelos

Antes del onboarding de una nueva aplicación a Predict, es necesario un periodo de entrenamiento en el que se analizan y revisan todos los datos históricos de origen de la aplicación mediante Amazon SageMaker. El proceso está destinado a identificar y modelar diferentes tipos de correlaciones, y se repetirá hasta que se alcancen niveles satisfactorios de precisión del modelo.

La precisión del modelo se revisa utilizando múltiples estadísticas: MAE, el error medio absoluto del modelo (por categoría), RMSE, el error cuadrático medio, y Kappa de Cohen para garantizar la validez e integridad del modelo.

Se realizan los ajustes necesarios en el modelo introduciendo data points adicionales, modificando los pesos relativos de determinados eventos y las etiquetas. Todo ello en un intento de perfeccionar el modelo antes de su lanzamiento.

Una vez que se haya completado el onboarding y se hayan lanzado las campañas, los nuevos usuarios comenzarán a descargar la aplicación y a interactuar con ella, generando nuevos datos a través del SDK de AppsFlyer.

Predict calcula la puntuación de los beneficios de un usuario basándose en los tres pilares: Compromiso, Retención y Monetización. Esta puntuación de beneficio se compara con el costo de la campaña para proporcionar una puntuación completa y procesable.

Entrenamiento de modelos

El proceso de reevaluación de la puntuación se repite constantemente durante la ventana de medición del usuario (normalmente 24 horas) con el objetivo de producir una puntuación predictiva precisa.

Al igual que con otros productos de AppsFlyer, la infraestructura de AWS nos permite operar esta compleja operación a escala, y productos como Amazon SageMaker nos permiten operarla de forma multitenencia que nos permite crear, y operar modelos predictivos únicos a través de diferentes aplicaciones y desarrolladores de forma aislada.

El análisis predictivo no sólo nos proporciona una importante ventaja competitiva gracias a la capacidad de prever lo que está por venir, sino que también supone un importante salto adelante en cuanto a la forma de optimizar y comercializar nuestros productos.

Ya no importa quién es el usuario, sino sólo lo que su comportamiento puede decirnos.

Share.