Prédire le churn grâce au ML

Dans un secteur aussi concurrentiel que celui des technologies, les clients sont libres d’aller et venir. Il est admis que l’acquisition de nouveaux clients engendre des coûts bien plus élevés que les investissements permettant de fidéliser les clients déjà existants. Un indicateur important utilisé en marketing pour quantifier la perte de clients, est le taux de churn. Ce taux mesure le ratio entre le nombre de clients perdus et le nombre de clients total mesuré sur une période donnée.

Ainsi, l’une des stratégies qui permet de réduire la perte de clients consiste à prédire le risque de churn d’un client pour anticiper son départ et réagir au préalable en proposant des stratégies de rétention et de fidélisation adéquates.

La prédiction du taux de churn peut être réalisée en utilisant des algorithmes de machine learning entraînés sur les données historiques des clients.

Il existe différents algorithmes de machine learning que l’on peut utiliser afin de prédire le taux de churn. Dans cet article, nous allons présenter ceux que nous avons utilisés dans le cas de Drovio, une plateforme de collaboration à distance. Pour répondre à leur problématique, nous avons choisi d’appliquer une classe d’algorithmes qui s’est avérée particulièrement efficace : les méthodes d’ensemble learning. Cette classe regroupe principalement deux méthodes: les méthodes de boosting (eg. Gradient boosting) et les méthodes de bagging (Random Forest).

Pour notre étude nous avons comparé la performance de chacune de ces deux méthodes, accompagnées d’une simple régression logistique. Pour le modèle gradient boosting, nous avons utilisé la librairie scikit-learn. Les résultats de la méthode Random Forest étant les meilleurs, ce sont ses résultats que nous présentons par la suite.

Prédiction de taux de churn des utilisateurs de Drovio, une plateforme de collaboration à distance

Drovio est une plateforme de pair-programming et de collaboration entre équipes qui permet aux utilisateurs de partager le contrôle de leur écran et interagir avec les applications de leurs espaces respectifs. Au cours de la période de crise du coronavirus, l’utilisation de Drovio a explosé et a montré comment ce type d’outil peut jouer un rôle clé dans la réussite d’une collaboration à distance.

Dans le but de fidéliser ses clients et d’optimiser l’usage de la plateforme, Drovio a souhaité mettre en place une prédiction du taux de churn.

L’un des principaux challenges dans le cas de Drovio était de trouver la bonne définition de churn adaptée à leur contexte et leurs utilisateurs. En effet, les données de Drovio n’étaient pas labellisées comme le nécessite un modèle de machine learning. Nous devions donc annoter dans un premier temps les utilisateurs en tant que “churner” ou “non churner” parmi les dizaines de milliers d’utilisateurs actifs. Pour ce faire, nous nous sommes basés sur la définition suivante : à un instant “t” où l’on regarde les données, nous considérons comme churner tout utilisateur dont la durée d’inactivité à cet instant “t” dépasse la moyenne de ses précédentes périodes d’inactivité. Par exemple, un utilisateur qui s’est connecté tous les 7 à 10 jours depuis 2 ans et est inactif depuis 8 jours sera considéré comme non-churner. A l’inverse, le même utilisateur inactif depuis 30 jours pourra être considéré comme churner une fois des critères complémentaires appliqués (périodes de vacances, prise en compte de l’erreur statistique).

Cette définition (voir schéma ci-après) a l’avantage d’être dynamique puisqu’elle prend en compte l’historique des utilisateurs. Elle est également spécifique à chaque utilisateur puisqu’elle se base sur l’activité propre à chacun d’entre eux. Une fois cette définition établie, nous exécutons l’annotation des données et nous les mettons à jour à chaque arrivée de nouvelles tables automatiquement via un pipeline exécuté sur Google Cloud Platform.

Cette base servira à l’entraînement de notre modèle, et nous prédisons par la suite les futurs churners pour les 15 jours suivants la date d’exécution du modèle. L’avantage de ce type de démarche, est que nous sommes en mesure de corriger nos prédictions s’il s’avère qu’elles étaient fausses. Par exemple, si l’on avait prédit qu’un utilisateur serait churner dans 15 jours, nous pouvons vérifier son activité 15 jours plus tard et corriger notre base d’entraînement.

Figure 1 : identification d’un churner vs non-churner en fonction des périodes d’activité

• Un événement correspond à une activité de l’utilisateur
• Les flèches en pointillés représentent les durées moyennes d’inactivité d’un utilisateur
• Les flèche en trait continu, la durée d’inactivité maximale d’un utilisateur
• L’instant n est celui de l’analyse

Outre l’élaboration du modèle de prédiction de churn, notre travail devait également garantir l’automatisation de l’ingestion des données, leurs traitements, et l’industrialisation du modèle, le tout en optimisant les ressources et les coûts associés. Ceci est rendu possible grâce aux puissants services fournis par les plateformes du cloud computing. Dans ce cas, nous avons construit une architecture autour des outils de l’univers Google Cloud Platform (GCP).

De l’ingestion de données au déploiement du modèle en production:

L’ensemble du pipeline de chargement et d’ingestion de données ainsi que le déploiement du modèle en production a été réalisé sur GCP (https://cloud.google.com/). Cela implique le recours à plusieurs services pour chacune des trois étapes-clé. Dans le paragraphe suivant, nous donnons les grandes lignes suivies pour réaliser les trois étapes clé, à savoir: le chargement des données, leur transformation, et le déploiement du modèle.

Les données de Drovio sont déposées sur Google Cloud Storage (GCS), le service de stockage de GCP. Afin de les traiter, nous avons déployé des pipelines de transfert automatisé vers BigQuery. Nous avons eu recours à deux méthodes d’ingestion en fonction du type et du volume de données et de la complexité des tâches à réaliser : l’utilisation combinée de DataFlow et Apache Beam pour les plus lourdes et l’utilisation de Cloud Function pour les tâches les plus simples.

Figure 2 : processus d’ingestion avec DataFlow et Apache Beam

Figure 3 : processus d’ingestion avec Cloud Function

BigQuery est le datawarehouse de GCP qui permet une interrogation optimisée et extrêmement efficace sur de gros volumes de données. Ainsi à partir de BigQuery, nous pouvons réaliser des requêtes SQL et construire les tables qui nous seront utiles pour alimenter nos modèles de Machine Learning qui ont été déployés en production grâce au service AI Platform. La totalité des requêtes SQL est codée en Java ce qui permet de les modifier facilement. L’ensemble est hébergé sur GitHub.

Modèle et résultats

Le modèle de machine learning peut prédire le taux de churn en classifiant les utilisateurs de façon binaire: “churner” ou “non churner”. En revanche, il nous semble plus pertinent de prédire la probabilité de churn et de classer les utilisateurs en plusieurs groupes selon le risque de churn. Ce risque est d’autant plus élevé lorsque la probabilité de churn augmente. Les résultats de notre modèle sont extraits à partir de AI Platform et mis à disposition de Drovio sous la forme d’un dashboard Data Studio.

En termes de performance, notre modèle permet d’obtenir de bons scores qui peuvent encore être améliorés notamment grâce aux corrections de prédiction à +15 jours que nous pouvons réaliser à chaque itération. Les métriques utilisées pour évaluer notre modèle sont résumés dans le tableau suivant:

Figure 4 : matrice de confusion

Parmi les scores présentés sur le dashboard, la matrice de confusion permet de mesurer la spécificité (taux de vrais négatifs), la précision (taux de prédiction positive correcte) ou encore le rappel (taux de vrais positifs) du modèle. L’exactitude globale du modèle (ou accuracy) est de 0,81 : ainsi dans 81% des cas, la prédiction effectuée par le modèle s’est avérée être exacte lorsque nous l’avons comparée quinze jours après avec les nouvelles données des utilisateurs. Dans le cas présent, c’est un niveau de précision satisfaisant en première approche. A mesure que l’historique de données s’étoffe, nous apprenons à affiner la prédiction. Un niveau d’exactitude de 90% serait considéré comme un très bon score.

Le F1 score (ou moyenne harmonique) pondère de manière égale le rappel et la précision, et ne prend pas en compte le nombre élevé de vrais négatifs, donnant ainsi une autre perception des performances du modèle spécifiquement sur la détection des churners.

Le seuil de probabilité défini par défaut pour différencier les deux groupes (churners vs. non-churners) est de 0,5. Autrement dit, lorsque le risque est supérieur à 0,5 l’utilisateur est considéré comme un churner par le modèle. Nous pouvons toutefois regarder la répartition des utilisateurs suivant la probabilité retournée par le modèle.

Figure 5 : probabilité de churn

Conclusion :

Malgré l’importance d’un modèle pertinent et de données cohérentes, ce projet nous a montré que les étapes d’ingestion et d’industrialisation étaient primordiales. Sans la puissance des technologies du Cloud telle que Google Cloud Platform, nous ne pourrions pas arriver à la production d’un KPI fiable et mis à jour régulièrement.

Cet indicateur, très important en marketing, permet d’ouvrir des perspectives intéressantes en termes de stratégies de rétention d’utilisateurs.

Par exemple, une initiative assez courante dans le cas d’un taux de churn trop haut, est de multiplier les interactions avec les utilisateurs: via des questionnaires, une présence sur les réseaux sociaux ou une campagne de mails. Ces actions permettent de détecter les potentiels problèmes des clients et de pouvoir s’adapter en fonction. Le taux de churn alors généré par l’algorithme pourrait être un réel outil d’arbitrage, en temps réel, sur la performance de ces initiatives.