Índice

Sponsors

cic kodak3 kodak3

logo-atdl

Asociación Técnica de Diarios Latinoamericanos

Índice

Boletín Semanal Enero 20, 2023
 

Adquirir nuevos usuarios es costoso y un desafío central para la mayoría de los sitios web de noticias en línea. Los modelos predictivos de aprendizaje automático reducen los costos de adquisición de clientes en una pequeña cantidad. En este artículo, Alexander Held, científico de datos de Der Spiegel, presenta el enfoque de ML utilizado para predecir suscripciones duraderas y permite la segmentación de los lectores según su afinidad para suscribirse.

Varios proyectos de investigación de audiencia en Der Spiegel sugieren que la decisión de una suscripción de noticias no es una acción repentina e instantánea. En cambio, esta es una decisión informada basada en nuestra experiencia y el comportamiento de nuestros lectores.² Esto se aplica al menos para los visitantes que sobreviven a nuestra fase de prueba gratuita y no están interesados únicamente en el contenido de un artículo de pago específico.

Las características de participación efectivas son adecuadas para crear un modelo de predicción de suscripción. Por lo tanto, desarrollamos un enfoque de aprendizaje automático que se puede utilizar para predecir suscripciones duraderas y nos permite segmentar a los lectores según su afinidad para suscribirse.

Para obtener un resumen del sistema de aprendizaje automático que hemos construido en Der Speigel, este artículo repasará los datos y características (1), el modelo (2), la evaluación (3), las operaciones de ML (4) y los siguientes pasos (5).

Datos y características

A medida que planeamos entrenar un modelo de aprendizaje automático para hacer predicciones, necesitamos una fuente de datos de la que aprender. Por lo tanto, según Adobe Data Feed de spiegel.de, los datos de seguimiento de sitios web sin procesar de spiegel.de, las funciones de uso se derivan a nivel de dispositivo, donde actualmente desarrollamos cuatro clases de funciones de entrada:

-Compromiso: web_visit, app_visit, avg_time_spent_article, avg_time_spent_article_across_sessions, mean_articles_read, mean_visit_duration, number_articles_read, paywall_loads, total_visit_duration, visit_subscription_page, number_of_visits

-Ubicación: estados federales

-Referencia: URL agregadas

-Editorial: departamento, tipo (texto, audio, vídeo) y formato (op-ed, investigativo, ...)

Ya existe una larga acumulación de otras características potenciales, pero el primer paso del desarrollo fue principalmente sobre la implementación de una canalización de ML de extremo a extremo. Parafraseando la cuarta regla de la Guía de Google ML: Mantenga el primer modelo simple y obtenga la infraestructura correcta. El primer modelo proporciona el mayor impulso a su producto, por lo que no necesita ser elegante. Pero se encontrará con muchos más problemas de infraestructura de los que espera. ³

De todos modos, la creación de características adecuadas es solo una parte de la ingeniería de características. Con los datos del viaje del cliente involucrados, también establecemos ventanas deslizantes dentro de nuestros viajes de usuario. Establecemos ventanas de retrospectiva y anticipación para los datos de entrenamiento, por lo que los datos para inferencia solo tienen lo primero. En consecuencia, nuestras características mencionadas anteriormente se calculan en los últimos 30 días por usuario. Para los registros de datos de entrenamiento, hay información sobre si un usuario ha contratado una suscripción, acompañada del número máximo de días que se ha utilizado la suscripción después de la conversión.

Para ello, se considerará un máximo de 40 días desde la compra. Junto con nuestra ventana de retrospectiva, tenemos una ventana deslizante total de setenta días para el entrenamiento. Siguiendo este enfoque, el modelo es flexible, de modo que se puede establecer un umbral de retención para que la capacitación considere únicamente las suscripciones como un valor objetivo para el que los usuarios aún han utilizado su suscripción X días después del pedido real. Esto permite entrenar el modelo para predecir solo suscripciones a largo plazo, donde los lectores permanecen con nosotros durante la fase de prueba. Para ser precisos, actualmente entrenamos el modelo en compras donde los lectores aún usan su suscripción al menos treinta y cinco días después de la conversión. Los viajes que no cumplen con estos criterios están siendo eliminados de la capacitación.

Los diferentes viajes también se descartan a gran escala antes de que se entrene el modelo. Esto es necesario para lograr una calidad predictiva adecuada para el propósito del modelo: la predicción de suscripciones duraderas y la identificación de clientes potencialmente leales. La razón principal para eliminar a los usuarios de la capacitación es que muchos viajes consisten en interacciones muy cortas y / o pocas, incluidas las que llevaron a una suscripción.

La ausencia de una obligación de iniciar sesión sin una suscripción y la baja calidad de los datos en el nivel del dispositivo de cookies está causando estos problemas de calidad de datos. Por lo tanto, al menos el 70% de los viajes de los usuarios que condujeron a la conversión no se incluyen en el entrenamiento de modelos porque no traen suficiente calidad con ellos.

También es importante decir que un número aún mayor de viajes de usuario que no condujeron a una suscripción se eliminan del conjunto de datos de entrenamiento porque también incluyen solo interacciones muy cortas y / o pocas. Estas circunstancias descritas anteriormente son uno de los mayores desafíos para esta tarea de ML.

Entrenar nuestro modelo solo en un subconjunto de casos positivos afecta naturalmente la inferencia porque los mismos viajes cortos e incompletos también están presentes en el conjunto de datos de clasificación.

Es importante tener esto en cuenta si el modelo se valida en datos no vistos sin subestablecerlos de acuerdo con los datos de entrenamiento. En ese caso, terminamos con un llamado sesgo de servicio de tren, donde los datos invisibles provienen de una distribución diferente, por lo que el modelo no se generaliza correctamente.

Por esta razón, nuestro modelo no está funcionando bien en la predicción de la suma total de suscripciones diarias, lo que se esperaba y no es el objetivo de nuestro modelo. En el otro extremo, se vuelve preciso al predecir suscripciones explícitamente duraderas. Aún más crítico en la identificación de clientes potenciales.

Finalmente, es importante tener en cuenta que nuestra tarea de ML "disponible" es un problema de clasificación binaria altamente desequilibrado, donde tenemos más usuarios que no se suscribieron en comparación con los viajes que terminan en una suscripción. Por lo tanto, muestreamos los casos negativos y, con eso, eliminamos grandes cantidades de viajes de los datos de entrenamiento una vez más.

Actualmente vemos el mejor rendimiento si equilibramos los datos de entrenamiento de uno a nueve, donde por cada viaje con una suscripción, tenemos nueve viajes sin suscripción.

Modelo

¿Necesitamos ML para identificar mejor a los clientes potenciales y predecir suscripciones duraderas? Las soluciones de ML solo son útiles cuando hay patrones complejos que aprender. Por lo tanto, la pregunta es la misma que con cualquier otro sistema de ML: ¿Es el patrón complejo y muy difícil de especificar manualmente? Si es así, en lugar de decirle a nuestro sistema cómo calcular la afinidad para suscribirse de una lista de características, dejamos que nuestro sistema de ML descubra el patrón en sí.⁴

Parafraseemos la Guía de ML de Google: "Una simple heurística puede sacar su producto por la puerta. Una heurística compleja es insostenible. Una vez que tenga datos y una idea básica de lo que está tratando de lograr, pase al aprendizaje automático. Como en la mayoría de las tareas de ingeniería de software, querrá actualizar constantemente su enfoque, ya sea un modelo heurístico o un modelo de aprendizaje automático, y encontrará que el modelo de aprendizaje automático es más fácil de actualizar y mantener (consulte la Regla # 16).

Por lo tanto, para nuestro enfoque, se entrena un modelo de bosque aleatorio en las características descritas anteriormente. El modelo se utiliza para proporcionar a todos los usuarios una puntuación del modelo entre 0 y 100. Cuanto mayor sea el valor, más limitado será el usuario para la suscripción.

El método de entrenamiento utilizado es sklearn.ensemble.RandomForestClassifier, que se ejecuta con un tiempo de entrenamiento de menos de tres horas, de las cuales la validación cruzada y la selección de características ocupan la mayor parte del tiempo. Hemos pasado por una fase de experimentación del modelo, donde optamos por descartar los siguientes enfoques debido a aumentos de rendimiento insuficientes:

-Random Forest supera a XGBoost

-SMOTE con submuestreo aleatorio de la clase mayoritaria no creó ningún aumento en el modelo

-RFECV (eliminación recursiva de características con validación cruzada) supera a otros métodos de selección de características como SelectKBest() o SelectFromModel()

-El RandomForestClassifier() básico supera a RandomForestClassifier(class_weight='balanced_subsample') y BalancedRandomForestClassifier()

Evaluación

Aplicamos la eliminación de características recursivas en un bucle de validación cruzada para encontrar el número óptimo y estimar la importancia de las características individuales. Como resultado, de la lista de características descrita anteriormente, solo las características de la participación en categorías se consideraron relevantes durante este proceso. Parece que ninguna de las características de ubicación, referencia o editorial tiene mucho poder predictivo.

Con estas características seleccionadas, el modelo actual en producción funcionó como tal durante la validación cruzada de los datos de entrenamiento: precisión: 0.71, recuperación: 0.41, puntuación F1: 0.54 y precisión: 0.93.

Si nos fijamos en la matriz de confusión, el modelo puede identificar fácilmente la mayoría de los viajes que no condujeron a una suscripción. Además, identificar alrededor del cuarenta por ciento de las conversiones reales (recuerdo) parece aceptable. Sin embargo, es importante tener en cuenta que eliminamos los viajes con etiquetas positivas con pocas interacciones antes del entrenamiento, como se describió anteriormente en la sección datos y características.

Por esta razón, nuestro desempeño en el retiro solo es evaluable en estas circunstancias. Además, una precisión del 71% también parece satisfactoria, especialmente si tenemos en cuenta lo útiles que pueden ser los falsos positivos, ya que estos usuarios se comportan como suscriptores potenciales, por lo que estarían interesados en ser dirigidos con campañas específicas.

Además de usar un umbral para dividir los puntajes del modelo predicho en un clasificador binario donde solo los viajes con una puntuación > 0.5 se conciben como suscripciones exitosas (como hicimos para la matriz de confusión vista anteriormente), usamos los puntajes del modelo como probabilidades reales de la probabilidad de que un usuario se suscriba con nosotros.

Encontramos un clasificador bien calibrado colocando las puntuaciones del modelo predicho en grupos y comparándolas con la proporción de predicciones en cada grupo que eran suscripciones reales. Esta proporción es mayor para los grupos más altos, por lo que la probabilidad está más o menos en línea con la predicción promedio para ese grupo.⁵ Tenga en cuenta que los cubos con puntuaciones de modelo más altas contienen significativamente menos usuarios.

Operaciones de ML

Nuestro modelo se vuelve a entrenar mensualmente, y todos los datos históricos de entrenamiento se utilizan para el reentrenamiento. Por lo tanto, se vuelve más preciso con el tiempo porque tiene más datos de entrada en cuenta durante un período más prolongado. Cada modelo entrenado se versiona y el conjunto de datos de entrenamiento y la selección de características se guardan con el modelo. Además, hay un documento de evaluación creado automáticamente para cada modelo, que contiene validación cruzada y de retención con las cifras clave más importantes, como la precisión y el recuerdo.

No utilizamos herramientas como DVC o MLflow para el control de versiones o el seguimiento de experimentos, sino que tenemos todo el proyecto envuelto en una aplicación Django. Esto nos permite utilizar comandos de administración para controlar y servir la mayoría de los flujos de trabajo diarios, como el preprocesamiento de datos y la ingeniería de características, la creación del conjunto de datos de clasificación y el servicio de clasificaciones a través del modelo, la carga de puntuaciones de modelos en Adobe o la ejecución de monitores.

En una cadencia mensual, también activamos flujos de trabajo para crear el conjunto de datos de entrenamiento y entrenar un nuevo modelo. Además, la capacidad de Django para inicializar módulos nos ayuda a capturar registros y monitorear datos en diferentes niveles, desde datos de seguimiento sin procesar hasta características derivadas o predicciones.

El modelo actualmente en producción está sirviendo predicciones en modo por lotes, donde todos los usuarios que visitaron nuestro sitio web ayer obtienen puntajes nuevos o actualizados. El alcance de este proyecto incluyó la usabilidad de las puntuaciones del modelo resultante en Adobe Analytics diariamente para el análisis accesible de varias partes interesadas.

Desde Analytics, enviamos segmentos para usuarios con puntuaciones altas a Adobe Target diariamente, para poder personalizar nuestro producto en función de las puntuaciones del modelo. Para ello, utilizamos la API de fuentes de datos de Adobe para poder adjuntar puntuaciones a nivel de sesión de usuario.

Por último, todos los componentes del sistema ML se ejecutan en Azure. Los datos sin procesar de Adobe Data Feed se almacenan en archivos parqué binarios en almacenamientos de blobs de Azure y las tareas de procesamiento de datos se escriben en PySpark para poder usar el procesamiento por lotes distribuido.

Como infraestructura informática, dependemos de una máquina virtual de tamaño mediano y para los repositorios de código y la integración continua, usamos Azure DevOps. El desarrollo se realiza en VS Code, ya que se integra sin problemas con nuestro ecosistema de Azure.

Próximos pasos

-Cambio en la distribución de datos: las noticias y el gusto del usuario fluctúan. Lo que está de moda hoy podría ser una noticia vieja mañana.⁶ Ya hemos creado funciones para capturar el uso del departamento editorial, pero aún no muestran mucho poder predictivo. Al crear estas características, es posible que debamos considerar cambios rápidos y sustanciales en los datos de entrenamiento, lo que también significa repensar los tiempos apropiados para el reentrenamiento y la ingeniería de características.

-Retorno de la inversión: Los informes anecdóticos afirman que el 90% de los modelos de ML no llegan a producción, y otros afirman que el 85% de los proyectos de ML no entregan valor. ⁷ Mientras teníamos nuestro modelo en producción, comenzamos a buscar enfoques y campañas adecuadas para evaluar si nuestro modelo valía la pena la inversión.

-Encuestas dirigidas: Usar nuestros puntajes de modelos para dirigirse a los visitantes con encuestas específicas para descubrir qué motivos y actitudes los separan puede ser muy perspicaz. Esto es extremadamente relevante si piensa en la fracción de varianza que nuestras características no pueden explicar sobre el comportamiento de uso, sino en factores más cualitativos como el precio percibido o el valor agregado de la suscripción. En //medium.com/@helloheld/combining-user-research-data-science-methods-e6fb9bbff369">otro post de medium escribí sobre cómo combinamos la investigación de usuarios y los métodos de ciencia de datos en Der Spiegel.

-Equilibrio precisión-recuperación: Vemos potencial en ajustar diferentes umbrales de probabilidad a favor de la precisión o el recuerdo. Especialmente un mayor número de falsos positivos podría ser un segmento interesante para trabajar, ya que naturalmente se comportan como visitantes que generalmente se suscriben con nosotros.

-Cambiar a predicciones continuas: en lugar de un clasificador binario, podemos replantear nuestra tarea general de ML como un problema de regresión, donde predecimos el número de días que un usuario mantendrá su suscripción.

-Compare los modelos ML y RFV: solo se seleccionaron características de participación durante el proceso de selección de características recursivas, y ninguna de las características de ubicación, referencia o editorial parece tener mucho poder predictivo. Esto nos llevó a la pregunta, ¿cuáles son las diferencias entre muchas puntuaciones de compromiso a medida, como los modelos RFV en el Financial Times, y los puntajes basados en el aprendizaje automático?