Application du cadre structuré : Exemple de la perte de clientèle

Cet exemple vous guidera tout au long du processus de définition d'une question d'apprentissage machine, étape par étape. Vous apprendrez à combiner des connaissances métier avec le cadre d'un déclencheur d'événement, d'une cible, d'un point de prédiction et de caractéristiques pour structurer une question bien définie.

Le point de départ du cas d'utilisation est le suivant : « Allons-nous perdre un client ? ». Grâce au recours à un cadre structuré, nous allons réduire cette question à quelque chose de plus spécifique susceptible d'être prédit par un algorithme d'apprentissage machine.

Déclencheur d'événement

Un déclencheur d'événement est une action ou un événement qui déclenche la création d'une nouvelle prédiction. Nous identifions notre déclencheur d'événement comme suit : « un client s'est abonné ». Cela est représenté dans les données comme la création d'un nouveau client. Nous souhaitons savoir, au niveau du client, si nous allons le perdre. Par conséquent, chaque ligne doit représenter un seul client.

En mettant à profit nos connaissances métier et en les vérifiant dans les données, nous savons que la perte de clientèle est la plus forte chez nos nouveaux clients. Nous décidons par conséquent de nous concentrer spécifiquement sur les nouveaux clients. Le déclencheur d'événement, c'est l'abonnement d'un nouveau client. Et nous considérons que chaque client a une chronologie individuelle à partir du jour où il s'abonne.

Cible

La cible est le résultat que nous tentons de prédire. Nous voulons prédire la perte de clientèle. Nous savons donc que notre cible générale est la suivante : « Allons-nous perdre un client ? ». Mais nous devons être plus précis, pour créer un modèle d'apprentissage machine de qualité. Pour commencer, nous définissons la « perte » comme l'appel d'un client pour annuler son abonnement.

Ensuite, nous décidons de la chronologie (l'horizon) au cours de laquelle cet appel d'annulation doit avoir lieu. Si nous nous penchons sur différents clients qui ont annulé leur abonnement, nous constatons que la chronologie n'est pas uniforme. Certains clients annulent au bout de 45 jours, tandis que d'autres n'annulent que bien plus tard, au bout de 110 jours.

Nous avons un programme d'essai gratuit de 90 jours et nous savons que nous perdons un grand nombre de clients à partir de cet essai. Suivant ce contexte métier, notre première réaction est d'utiliser un horizon de 90 jours. En prédisant qui va annuler son abonnement, nous voulons toucher les clients en avance et les motiver (en leur proposant des remises ou des fonctions d'abonnement supplémentaires) pour les encourager à rester.

Un histogramme du nombre de jours au bout duquel les clients abonnés ont annulé leur abonnement confirme notre intuition. Sur la figure, nous voyons les données de tous les clients que nous avons perdus au cours des trois dernières années.

La sélection d'un horizon à 90 jours semble un bon début. Cependant, lorsque nous traçons cet horizon sur l'histogramme, nous constatons que nous continuons à perdre un grand nombre de clients quelques jours après la période d'essai gratuit de 90 jours. Peut-être parce qu'ils voient que leur carte de crédit est débitée ; ou parce qu'ils reçoivent une notification leur indiquant que leur mode de paiement a été refusé quelques jours plus tard ; et que c'est seulement à ce moment-là qu'ils annulent leur abonnement.

Nous voulons inclure ces clients comme « perdus » dans notre modèle ; par conséquent, nous décidons qu'il est plus judicieux d'utiliser un horizon cible à 110 jours. En utilisant 110 jours, nous capturons la plupart des clients dont la perte est probablement liée au programme d'essai gratuit.

Maintenant que la cible est définie, nous pouvons déterminer l'emplacement de stockage des données et la manière dont les nettoyer pour créer la colonne cible dans l'ensemble de données. Dans cet exemple, nous procédons comme suit :

1. Nous extrayons l'état des clients de Salesforce.

2. Nous extrayons l'état, la date de création du client et la date d'annulation du client :

   

3. Nous nettoyons et transformons les données extraites dans la colonne cible :

   

Nous avons maintenant défini notre déclencheur d'événement (l'abonnement d'un nouveau client) et notre cible (le client a appelé pour annuler son abonnement au cours des 110 jours d'abonnement). Ces informations sont illustrées sur la chronologie de la figure.

Point de prédiction

Le point de prédiction est le moment désigné auquel vous arrêtez de collecter des données pour obtenir des caractéristiques et prédisez la cible pour chaque ligne. Le point de prédiction peut tomber à tout moment entre le déclencheur d'événement (le jour de l'abonnement) et l'horizon cible (110 jours après l'abonnement). Pour sélectionner un point de départ, nous pouvons penser à l'action que nous souhaitons entreprendre.

Dans notre exemple, peut-être l'équipe d'assistance à la clientèle a-t-elle demandé 30 jours pour proposer aux clients des offres de fidélisation une fois qu'il a été prédit que nous allions perdre ces clients. Cela signifie qu'au plus tard, nous voulons une prédiction 30 jours avant l'horizon cible, à savoir, d'ici le 80e jour.

Si nous sélectionnons le 80e jour comme notre point de prédiction, cela nous donne 80 jours pour collecter des données sur les nouveaux clients lorsqu'ils arrivent. Ce cadre temporel entre le déclencheur d'événement et le point de prédiction est appelé fenêtre d'accumulation de données. Les données collectées au cours de la fenêtre d'accumulation de données sont utilisées pour générer des caractéristiques.

L'utilisation du 80e jour comme point de prédiction nous laisse une fenêtre d'action de 30 jours, qui correspond au temps entre le point de prédiction et l'horizon cible. Il s'agit de la fenêtre de 30 jours au cours de laquelle l'équipe d'assistance à la clientèle a demandé de contacter les clients.

En plus de prévoir la fenêtre d'action minimale nécessaire pour agir en fonction des prédictions, nous devons également nous pencher sur l'histogramme des jours avant la perte de clientèle. En appliquant un point de prédiction au 80e jour, nous obtiendrions le résultat suivant :

Si nous nous penchons sur cet histogramme, nous constatons que l'utilisation d'un point de prédiction au 80e jour n'optimise pas la valeur métier. Même si 80 jours de données permettent d'augmenter l'exactitude du modèle, cela affecte fortement la capacité d'action :

• Tout d'abord, au 80e jour, nous avons déjà perdu un grand nombre de clients, qui sont donc partis au cours de la fenêtre d'accumulation de données, avant que nous puissions même réaliser des prédictions. Cela signifie également que nous ne devons pas les inclure dans notre ensemble de données d'apprentissage, car nous en connaîtrions le résultat avant de réaliser la prédiction.

• Ensuite, nous perdons un grand nombre de clients entre le 80e et le 90e jours. L'équipe d'assistance à la clientèle ne dispose donc pas de 30 jours complets pour contacter ces clients.

Si on déplace le point de prédiction au 60e jour, cela nous offre un meilleur équilibre entre exactitude et capacité d'action. Il nous reste encore 60 jours pour collecter des données à utiliser pour les caractéristiques de notre modèle ; mais, à présent, nous réalisons des prédictions suffisamment tôt pour laisser à l'équipe d'assistance à la clientèle 30 jours pour contacter la plupart des clients que, selon nos prédictions, nous allons perdre. En réduisant la fenêtre d'accumulation de données, nous pouvons espérer une faible réduction de l'exactitude du modèle, mais une prédiction permettant d'agir plus efficacement.

Caractéristiques

Une fois le déclencheur d'événement, la cible et le point de prédiction définis, nous sommes prêts à ajouter la dernière partie à notre ensemble de données : les caractéristiques. Les caractéristiques sont les attributs connus, ou observations, de chaque ligne de données de l'ensemble de données d'apprentissage dont les algorithmes d'apprentissage machine apprennent les patterns généraux. Les algorithmes utilisent ensuite les caractéristiques pour réaliser des prédictions lorsqu'on leur présente une nouvelle ligne de données dans l'ensemble de données à appliquer.

Vous pouvez imaginer les caractéristiques comme des hypothèses basées sur les connaissances métier susceptibles d'influencer le résultat. Dans notre exemple, certaines caractéristiques peuvent être l'emplacement d'un client, la source du lead, le mois d'abonnement, le nombre de connexions ou le nombre d'utilisateurs actifs.

Il existe deux catégories de caractéristiques :

• Les Caractéristiques fixes sont les caractéristiques les plus simples, car elles ne changent pas au fil du temps. Dans notre exemple, l'emplacement du client (lors de l'abonnement), la source du lead et le mois d'abonnement sont tous considérés comme des caractéristiques fixes. Ces caractéristiques sont connues dès l'abonnement d'un client (précisément au déclencheur d'événement) et, quel que soit l'endroit où nous plaçons le point de prédiction, elles seront connues et constantes.

• Les Caractéristiques dépendantes de la fenêtre sont légèrement plus compliquées. Il s'agit de caractéristiques collectées en fonction des informations obtenues entre le déclencheur d'événement et le point de prédiction. Il est important de s'assurer d'utiliser uniquement des données connues au moment opportun, sinon le modèle risque de souffrir d'une fuite de données. (Pour plus d'informations, voir Fuite de données.)

Il se peut qu'un modèle simple utilise uniquement des informations connues au jour 0, à savoir, uniquement des caractéristiques fixes. Cela donnerait un point de prédiction au jour 0, comme illustré sur la figure.

L'ensemble de données obtenu ressemblerait à ceci :

Mais il se peut que voulions également utiliser des données collectées une fois que le client s'est abonné, comme dans notre exemple avec le point de prédiction au 60e jour.

À présent, nous pouvons utiliser les informations collectées au cours des 60 premiers jours après l'abonnement d'un client pour ajouter à notre modèle des caractéristiques dépendantes de la fenêtre. Notre ensemble de données pour ce modèle peut ressembler au tableau suivant, qui inclut à présent les caractéristiques dépendantes de la fenêtre Logins First 60 Days (Nombre de connexions au cours des 60 premiers jours) et Active Users at 60 days (Utilisateurs actifs à 60 jours).

Notez que, dans cet exemple, les caractéristiques reflètent la fenêtre d'accumulation de données toute entière. Elles peuvent également refléter une fenêtre plus courte. Par exemple, nous pouvons mesurer le nombre de connexions au cours des 10 premiers jours ou les connexions entre le 30e et le 60e jours, à condition que les caractéristiques n'incluent aucune information au-delà du point de prédiction.

Il peut être plus difficile de collecter des caractéristiques dépendantes de la fenêtre, car elles nécessitent des dates et le déploiement d'efforts supplémentaires pour s'assurer qu'elles tombent dans la fenêtre d'accumulation de données afin d'éviter toute fuite de données. Mais il peut également s'agir des caractéristiques les plus performantes, car elles reflètent des informations collectées bien plus proches du moment de prédiction.

Question d'apprentissage machine obtenue

Nous avons commencé avec le simple cas d'utilisation suivant : « Allons-nous perdre un client ? ». Nous avons ensuite défini notre déclencheur d'événement comme étant l'« Abonnement d'un nouveau client », parce que nous voulions faire des prédictions au niveau de chaque client.

Nous avons défini notre cible avec un résultat spécifique : « Le client a appelé pour annuler son abonnement (Oui ou Non) » et établi l'horizon à 110 jours, car cela correspond à la durée pendant laquelle la plupart de nos clients profitant de la période d'essai ont annulé leur abonnement.

Après nous être penchés sur l'histogramme montrant le nombre de jours d'abonnement après lequel les clients ont annulé au cours des trois dernières années, nous nous sommes mis d'accord sur un point de prédiction à 60 jours après l'abonnement. Cela nous donne 60 jours pour collecter des informations (fenêtre d'accumulation de données) avant de faire notre prédiction, tout en laissant le temps à l'équipe d'assistance à la clientèle d'agir en fonction des prédictions afin de réduire la perte de clientèle.

Pour finir, nous avons collecté des données sur les clients qui seraient disponibles avant le 60e jour pour générer des caractéristiques.

La question d'apprentissage machine obtenue est la suivante : « Après les 60 premiers jours d'activité, le client va-t-il appeler pour annuler son abonnement d'ici le 110e jour ? »

Et l'ensemble de données maintenant prêt à être utilisé pour l'apprentissage machine automatisé ressemble au tableau ci-dessous. Location (Emplacement), Lead Source (Source du lead), Month Joined (Mois d'abonnement) et Subscription Amount (Montant d'abonnement) sont des caractéristiques fixes ; Logins First 60 Days (Nombre de connexions au cours des 60 premiers jours) et Active Users at 60 Days (Utilisateurs actifs à 60 jours) sont des caractéristiques dépendantes de la fenêtre ; et Churned by 110 Days (Perte de clients d'ici 110 jours) est la colonne cible.