Anwenden des strukturierten Frameworks: Beispiel „Kundenabwanderung“

In diesem Beispiel werden Sie Schritt für Schritt durch den Prozess des Definierens einer Frage für maschinelles Lernen geführt. Sie erfahren, wie Sie geschäftliches Wissen mit dem Framework aus Ereignisauslöser, Ziel, Vorhersagepunkt und Features kombinieren, um eine gut definierte Frage zu strukturieren.

Der Ausgangspunkt ist der Geschäftsfall „Wird ein Kunde abwandern?“ Mithilfe des strukturierten Frameworks können Sie diese Frage konkreter formulieren, sodass ein Algorithmus für maschinelles Lernen damit eine Vorhersage treffen kann.

Ereignisauslöser

Der Ereignisauslöser ist eine Aktion oder ein Ereignis, das die Erstellung einer neuen Vorhersage auslöst. Wir identifizieren den Ereignisauslöser als „ein Kunde ein Abonnement abgeschlossen“. In den Daten wird dies als die Erstellung eines neuen Kunden dargestellt. Wir möchten auf Kundenebene vorhersagen, ob der Kunde abwandern wird. Daher muss jede Zeile einen einzelnen Kunden darstellen.

Wir wissen aufgrund unserer geschäftlichen Kenntnisse (und bestätigen dies durch Prüfung der Daten), dass die Abwanderung unter unseren neuen Kunden am höchsten ist. Daher entscheiden wir, uns spezifisch auf neue Kunden zu konzentrieren. Der Ereignisauslöser besteht darin, dass ein neuer Kunde ein Abonnement abgeschlossen hat. Wir stellen uns für jeden Kunden eine individuelle Zeitleiste vor, die am Tag des Abonnementabschlusses beginnt.

Ziel

Das Ziel ist das Ergebnis, das wir vorhersagen möchten. Wir möchten die Abwanderung vorhersagen. Unser allgemeines Ziel lautet also: „Wird ein Kunde abwandern?“ Wir benötigen aber konkretere Angaben, um ein hochwertiges Modell für maschinelles Lernen zu erstellen. Zunächst legen wir fest, dass „Abwanderung“ bedeutet, dass ein Kunde uns anruft, um sein Abonnement zu kündigen.

Als Nächstes bestimmen wir den Zeitrahmen (den Horizont), in dem der Kündigungsanruf erfolgen muss. Wir schauen uns mehrere Kunden an, die gekündigt haben, und stellen fest, dass die Zeitleiste nicht einheitlich ist. Einige Kunden kündigen nach 45 Tagen, andere erst viel später nach 110 Tagen.

Wir haben ein kostenloses 90-Tage-Probe-Abo und wissen, dass viel Kunden nach dem Probezeitraum abwandern. Basierend auf diesem geschäftlichen Kontext bietet es sich zunächst an, einen Horizont von 90 Tagen zu verwenden. Wir möchten vorhersagen, wer wahrscheinlich kündigen wird, um uns rechtzeitig an diese Kunden wenden und Anreize anbieten zu können (z. B. Rabatte oder zusätzliche Abonnementfunktionen), die sie zum Bleiben bewegen.

Ein Histogramm, das angibt, wie viele Tage nach dem Abonnement Kunden gekündigt haben, bestätigt unsere geschäftliche Intuition. In der Abbildung sind die Daten für alle Kunden zu sehen, die in den letzten drei Jahren abgewandert sind.

Ein 90-Tage-Horizont bietet sich als guter Ausgangspunkt an. Wenn wir aber diesen Horizont in unserem Histogramm einzeichnen, stellen wir fest, dass viele Kunden auch einige Tage nach dem 90-Tage-Probezeitraum noch abwandern. Der Grund kann sein, dass sie feststellen, dass ihre Kreditkarte belastet wird, oder dass sie einige Tage später die Mitteilung erhalten, dass ihre Zahlungsmethode abgelehnt wurde, und erst dann anrufen, um ihr Abonnement zu kündigen.

Da wir diese Kunden in unserem Modell als „abgewandert“ einschließen möchten, entscheiden wir, dass es sinnvoller ist, 110 Tage als unseren Zielhorizont zu verwenden. Wenn wir 110 Tage verwenden, erfassen wir die meisten Kunden, deren Abwanderung wahrscheinlich mit dem kostenlosen Probezeitraum zusammenhängt.

Nachdem wir jetzt unser Ziel definiert haben, können wir festlegen, wo die Daten gespeichert werden und wie sie bereinigt werden müssen, um die Zielspalte im Datensatz zu erstellen. In diesem Beispiel gehen wir wie folgt vor:

1. Kundenstatus aus Salesforce abrufen.

2. Status, Kundenerstellungsdatum und Kundenkündigungsdatum extrahieren:

   

3. Die extrahierten Daten bereinigen und in die Zielspalte umwandeln:

   

Wir haben jetzt unseren Ereignisauslöser (ein neuer Kunde hat ein Abonnement abgeschlossen) und unser Ziel (der Kunde hat innerhalb von 110 Tagen nach dem Abonnement angerufen, um das Abonnement zu kündigen). Sie sind auf der Zeitleiste der Abbildung dargestellt.

Vorhersagepunkt

Der Vorhersagepunkt ist der festgelegte Zeitpunkt, zu dem Sie aufhören, Daten für Features zu erfassen und beginnen, das Ziel für jede Zeile vorherzusagen. Der Vorhersagepunkt kann an jedem Zeitpunkt zwischen dem Ereignisauslöser (dem Tag des Abonnements) und dem Zielhorizont (Tag 110 nach dem Abonnement) liegen. Zur Auswahl eines Ausgangspunkts können wir über die Maßnahme nachdenken, die wir ergreifen möchten.

In unserem Beispiel hat das Kundensupportteam vielleicht um 30 Tage Zeit gebeten, um sich mit Kundenbindungsangeboten an die Kunden zu wenden, nachdem deren Abwanderung vorhergesagt wurde. Das bedeutet, dass wir die Vorhersage mindestens 30 Tage vor dem Zielhorizont erstellen müssen, also bis zum Tag 80.

Wenn wir Tag 80 als unseren Vorhersagepunkt wählen, haben wir 80 Tage Zeit, um Daten über neue Kunden zu erfassen, nachdem sie ein Abonnement abgeschlossen haben. Dieser Zeitraum zwischen dem Ereignisauslöser und dem Vorhersagepunkt wird als Datenkumulationszeitfenster bezeichnet. Die während des Datenkumulationszeitfensters erfassten Daten werden zum Erstellen von Features verwendet.

Wenn Tag 80 als Vorhersagepunkt verwendet wird, bleibt ein 30-tägiges Maßnahmenzeitfenster. Das ist der Zeitraum zwischen dem Vorhersagepunkt und dem Zielhorizont. Dies ist das 30-Tage-Zeitfenster, das vom Kundensupportteam für die Kontaktaufnahme mit den Kunden angefordert wurde.

Wir müssen uns aber nicht nur das erforderliche Mindestzeitfenster überlegen, das für auf die Vorhersagen gestützte Maßnahmen erforderlich ist, sondern auch das Histogramm der Tage bis zur Abwanderung betrachten. Wenn der Tag-80-Vorhersagepunkt angewendet wird, erhalten wir Folgendes:

Wenn wir dieses Histogramm betrachten, wird uns klar, dass der Geschäftswert mit einem Tag-80-Vorhersagepunkt nicht maximiert wird. Obwohl die Daten von 80 Tagen dazu beitragen, die Genauigkeit des Modells zu verbessern, sind die Kosten bezüglich der Fähigkeit zum Ergreifen von Maßnahmen hoch.

• Erstens sind bis zum Tag 80 bereits viele Kunden abgewandert. Sie sind während des Datenkumulationszeitfensters abgewandert – also noch bevor wir überhaupt Vorhersagen treffen konnten. Das bedeutet auch, dass wir sie nicht in den Trainingsdatensatz einschließen sollten, weil wir das Ergebnis bereits vor der Vorhersage kennen.

• Zweitens kündigen viele Kunden zwischen Tag 80 und 90, sodass das Kundensupportteam nicht die vollen 30 Tage Zeit hat, sich an diese Kunden zu wenden.

Wenn der Vorhersagepunkt auf Tag 60 verschoben wird, sind Genauigkeit und Fähigkeit zum Ergreifen von Maßnahmen ausgewogener. Wir haben immer noch 60 Tage, um Daten für die Features in unserem Modell zu erfassen, aber wir erstellen die Vorhersage jetzt frühzeitig genug, damit das Kundensupportteam 30 Tage Zeit hat, um sich an die meisten der Kunden zu wenden, die unserer Vorhersage zufolge kündigen werden. Durch die Verkleinerung des Datenkumulationszeitfensters ist eine geringfügige Abnahme der Modellgenauigkeit zu erwarten, aber auch eine Vorhersage mit wesentlich besseren Maßnahmenmöglichkeiten.

Features

Nachdem der Ereignisauslöser, das Ziel und der Vorhersagepunkt definiert wurden, können wir den letzten Teil zu unserem Datensatz hinzufügen: die Features. Features sind die bekannten Attribute bzw. Beobachtungen für jede Datenzeile im Trainingsdatensatz, aus denen die Algorithmen für maschinelles Lernen allgemeine Muster lernen. Die Algorithmen verwenden dann die Features, um Vorhersagen zu treffen, wenn ihnen eine neue Datenzeile im Anwendungsdatensatz vorgelegt wird.

Stellen Sie sich Features als Ihre Hypothesen vor, die sich auf geschäftliches Wissen darüber stützen, was das Ergebnis beeinflusst. Einige der Features in unserem Beispiel sind beispielsweise der Kundenstandort, die Lead-Quelle, der Registrierungsmonat, die Anzahl der Anmeldungen oder die Anzahl der aktiven Benutzer.

Es gibt zwei Kategorien von Features:

• Feste Features sind die unkompliziertesten, da sie sich im Zeitverlauf nicht ändern. In unserem Beispiel werden der Kundenstandort (bei Abschluss des Abonnements), die Lead-Quelle und der Registrierungsmonat alle als feste Features betrachtet. Sie sind bekannt, sobald der Kunde das Abonnement abgeschlossen hat (direkt beim Ereignisauslöser), und unabhängig von der Position des Vorhersagepunkts sind sie sowohl bekannt als auch konstant.

• Zeitfensterabhängige Features sind etwas komplizierter. Dies sind die Features, die basierend auf den erfassten Informationen zwischen dem Ereignisauslöser und dem Vorhersagepunkt erfasst werden. Es ist wichtig, sicherzustellen, dass Sie nur Daten verwenden, die rechtzeitig bekannt werden, andernfalls kann das Modell Datenlecks aufweisen. (Weitere Informationen finden Sie unter Datenleck.)

In einem einfachen Modell werden möglicherweise nur Informationen verwendet, die an Tag 0 bekannt sind, also nur feste Features. In diesem Fall liegt der Vorhersagepunkt an Tag 0, wie in der Abbildung gezeigt.

Der sich ergebende Datensatz sieht etwa so aus:

Möglicherweise möchten wir aber auch Daten verwenden, die erfasst wurden, nachdem der Kunde ein Abonnement abgeschlossen hat, wie in unserem Beispiel mit dem Vorhersagepunkt an Tag 60.

Jetzt können wir die in den ersten 60 Tagen nach dem Abonnement des Kunden erfassten Informationen verwenden, um zeitfensterabhängige Features zu unserem Modell hinzuzufügen. Unser Datensatz für dieses Modell gleicht dem in der folgenden Tabelle und enthält jetzt die zeitfensterabhängigen Features „Anmeldungen erste 60 Tage“ und „Aktive Benutzer nach 60 Tagen“.

Beachten Sie, dass in diesem Beispiel die Features das gesamte Datenkumulationszeitfenster darstellen. Sie können auch kleiner sein. Beispielsweise können wir die Anmeldungen in den ersten 10 Tagen oder die Anmeldungen von Tag 30-60 messen. Die Features dürfen nur keine Informationen nach dem Vorhersagepunkt enthalten.

Die Erfassung von zeitfensterabhängigen Features kann komplizierter sein, weil sie Datumsangaben und mehr Aufwand erfordert, um zu gewährleisten, dass die Features innerhalb des Datenkumulationszeitfensters liegen und Datenlecks zu vermeiden. Diese Features können sich aber auch als besonders leistungsstark erweisen, da sie Informationen umfassen, die näher am Vorhersagezeitpunkt erfasst wurden.

Die sich ergebende Frage für maschinelles Lernen

Wir haben mit dem einfachen Anwendungsfall „Wird ein Kunde kündigen?“ begonnen. Dann haben wir unseren Ereignisauslöser als „Ein neuer Kunde schließt ein Abonnement ab“ definiert, weil wir Vorhersagen auf Ebene der einzelnen Kunden erstellen möchten.

Wir haben unser Ziel mit einem spezifischen Ergebnis definiert („Kunde ruft an, um sein Abonnement zu kündigen (Ja oder Nein)“) und den Horizont auf 110 Tage festgelegt, weil das der Zeitpunkt ist, bis zu dem die meisten Probezeitraumkunden gekündigt haben.

Nach Betrachten des Histogramms dazu, wie viele Tage nach dem Abonnement Kunden in den letzten drei Jahren anriefen, um zu kündigen, haben wir beschlossen, den Vorhersagepunkt auf 60 Tage nach dem Abonnement festzulegen. Damit haben wir 60 Tage Zeit, um Informationen zu erfassen (das Datenkumulationszeitfenster), bevor wir unsere Vorhersage erstellen. Das gibt dem Kundensupportteam auch noch genügend Zeit, aufgrund der Vorhersage Maßnahmen zu ergreifen, um die Anzahl der Kündigungen zu reduzieren.

Abschließend haben wir Daten zu Kunden erfasst, die vor Tag 60 verfügbar sind, um Features zu erstellen.

Die sich ergebende Frage für maschinelles Lernen lautet: „Wird ein Kunde gestützt auf die ersten 60 Tagen Aktivität bis zum Tag 110 anrufen, um zu kündigen?“

Der Datensatz,der jetzt für automatisiertes maschinelles Lernen verwendet werden kann, gleicht der Tabelle unten. „Standort“, „Lead-Quelle“, „Beitrittsmonat“ und „Abonnementbetrag“ sind feste Features, „Anmeldungen erste 60 Tage“ und „Aktive Benutzer nach 60 Tagen“ sind zeitfensterabhängige Features und „Nach 110 Tagen abgewandert“ ist die Zielspalte.