Ga naar hoofdinhoud Ga naar aanvullende inhoud

Het gestructureerde kader toepassen: Voorbeeld van klantverloop

Dit voorbeeld beschrijft stapsgewijs hoe het definiëren van een machine learning-vraag in zijn werk gaat. U leert hoe u zakelijke kennis combineert met het kader van gebeurtenistrigger, doel, voorspellingspunt en kenmerken om een goed gedefinieerde vraag op te stellen.

Het beginpunt is de bedrijfscase "Zal een klant vertrekken?". Door het gestructureerde kader te gebruiken, kunnen we deze case verfijnen tot iets specifiekers dat kan worden voorspeld door een machine learning-algoritme.

Gebeurtenistrigger

De gebeurtenistrigger is een actie of een gebeurtenis die het aanmaken van een nieuwe voorspelling triggert. We identificeren onze gebeurtenistrigger als een 'klant die zich heeft aangemeld voor een abonnement'. In de gegevens wordt dit vertegenwoordigd als een nieuwe klant die wordt gemaakt. We willen op klantniveau kunnen voorspellen of de klant al dan niet zal vertrekken en daarom moet iedere rij één klant vertegenwoordigen.

Met behulp van onze zakelijke kennis en door de gegevens te bevestigen, weten we dat het verloop onder onze nieuwe klanten hoog is. We kiezen er daarom voor om ons specifiek te concentreren op nieuwe klanten. De gebeurtenistrigger is dat een nieuwe klant zich aanmeldt. We kunnen iedere klant zien als een individuele tijdlijn die begint op de dag dat deze zich abonneert.

De gebeurtenistrigger is wanneer een nieuwe klant zich abonneert. De horizontale lijn vertegenwoordigt het aantal dagen sinds het abonnement is afgesloten.

Tijdlijn voor een nieuwe klant.

Doel

Het doel is het resultaat dat we willen voorspellen. We willen klantverloop voorspellen, dus we weten dat ons algemene doel "Zal een klant vertrekken?" is. Maar we moeten specifieker zijn om een machine learning-model van goede kwaliteit te kunnen maken. Om te beginnen, beslissen we dat 'vertrekken' betekent dat een klant ons belt om zijn of haar abonnement te beëindigen.

Het doelresultaat is wanneer een klant belt om zijn/haar abonnement te beëindigen.

Klanttijdlijn met een doel.

Daarna beslissen we wat het tijdsbestek (de horizon) is waarin dat telefoontje om het abonnement te beëindigen moet zijn gepleegd. Wanneer we naar verschillende klanten kijken die hun abonnement hebben beëindigd, kunnen we zien dat het tijdsbestek niet consistent is. Sommige klanten beëindigen hun abonnement na 45 dagen en anderen bijvoorbeeld past veel later, na 110 dagen.

Dagen sinds afsluiten van het abonnement tot de klant belt om het abonnement te beëindigen. Iedere regel vertegenwoordigt een andere klant.

Tijdlijnen die het aantal dagen laten zien voordat klanten hun abonnement beëindigen.

We hebben een 90 dagen gratis proef en weten dat veel klanten na deze proef niet blijven. Op basis van deze zakelijke context is ons aanvankelijke idee om een horizon van 90 dagen te gebruiken. Door te voorspellen wie we denken dat een abonnement zal beëindigen, hopen we contact met die klanten te kunnen opnemen voordat ze vertrekken en willen we incentives bieden (zoals kortingen of aanvullende abonnementskenmerken) om ze te stimuleren te blijven.

Een histogram van hoeveel dagen na aanmelding klanten hun abonnement hebben beëindigd, bevestigt onze zakelijke intuïtie. In het cijfer kunnen we gegevens zien van alle klanten die in de afgelopen drie jaar zijn vertrokken.

De verdeling van de beëindigingstelefoontjes voor het aantal dagen sinds het abonnement is afgesloten. De meeste beëindigingen vinden plaats circa 90 dagen nadat de klant een abonnement afsluit.

Histogram dat het aantal dagen laat zien voordat klanten hun abonnement beëindigen.

De keuze voor een horizon van 90 dagen lijkt een goede plek om te beginnen. Wanneer we die horizon echter op ons histogram tekenen, zien we dat er ook na de proefperiode van 90 dagen nog een hoop klanten zijn die zich afmelden. De reden kan zijn dat ze zien dat er kosten in rekening worden gebracht bij hun creditcard of dat ze een paar dagen later een melding krijgen dat hun betaalmethode is afgewezen en pas dan bellen om hun abonnement te beëindigen.

Een horizon van 90 dagen na afsluiten van het abonnement

Histogram waarop de horizon van 90 dagen staat gemarkeerd.

Omdat we deze klanten als 'vertrokken' willen toevoegen aan ons model, kiezen we ervoor dat het logisch is om 110 dagen te gebruiken als onze doelhorizon. Door 110 dagen te gebruiken, ondervangen we de meeste klanten wiens vertrek waarschijnlijk kan worden gerelateerd aan de gratis proefperiode.

Een horizon van 110 dagen na afsluiten van het abonnement

Histogram waarop de horizon van 110 dagen staat gemarkeerd.

Nu dat we ons doel hebben gedefinieerd, kunnen we bepalen waar de gegevens worden opgeslagen en hoe ze moeten worden opgeschoond om de doelkolom in de gegevensverzameling op te bouwen. In dit voorbeeld doen we het volgende:

  1. Vraag de klantstatus op uit Salesforce.

  2. Extraheer de status, de aanmaakdatum van de klant en de datum waarop de klant het abonnement heeft opgezegd:

    Tabel met voorbeeldgegevens.

  3. Schoon de geëxtraheerde gegevens op en transformeer ze in de doelkolom:

    Tabel met voorbeeldgegevens.

We hebben nu onze gebeurtenistrigger (een nieuwe klant heeft zich aangemeld) en ons doel (de klant heeft gebeld om zijn abonnement binnen 110 dagen na aanmelden op te zeggen) gedefinieerd. Ze worden op de tijdlijn in het figuur geïllustreerd.

De gebeurtenistrigger is wanneer een nieuwe klant zich aanmeldt (1), het doelresultaat is wanneer de klant belt om het abonnement te beëindigen (2), en de doelhorizon is 110 dagen na afsluiten van het abonnement (3).

Tijdlijn die de gebeurtenistrigger, het doel en de doelhorizon weergeeft.

Voorspellingspunt

Het voorspellingspunt is het aangewezen moment waarop u stopt met het verzamelen van gegevens voor kenmerken en het doel per rij voorspelt. Het voorspellingspunt kan ergens tussen de gebeurtenistrigger (de dag dat het abonnement wordt afgesloten) en de doelhorizon (dag 110 na afsluiten van abonnement) liggen. Om een beginpunt te kiezen, kunnen we nadenken over de actie die we willen nemen.

In ons voorbeeld kan het zijn dat het klantsuccesteam heeft gevraagd om 30 dagen te tijd om contact op te nemen met de klant met aanbiedingen om de klant te behouden, zodra is voorspeld dat klanten zullen vertrekken. Dit houdt in dat we op zijn minst 30 dagen voor de doelhorizon willen kunnen voorspellen. Dat is dus vóór dag 80.

Het voorspellingspunt (2) is ingesteld op dag 80, tussen de gebeurtenistrigger (1) en de doelhorizon (3).

De tijdlijn toont het voorspellingspunt.

Door dag 80 te kiezen als ons voorspellingspunt, zouden we 80 dagen hebben om gegevens te verzamelen over nieuwe klanten. Dit tijdbestek tussen de gebeurtenistrigger en het voorspellingspunt is het venster voor gegevensaccumulatie. Gegevens die gedurende het venster voor gegevensaccumulatie worden verzameld, worden gebruikt om kenmerken te genereren.

Het venster voor gegevensaccumulatie is de tijd tussen de gebeurtenistrigger en het voorspellingspunt.

De tijdlijn toont het venster voor gegevensaccumulatie tussen de gebeurtenistrigger en het voorspellingspunt.

Door dag 80 te gebruiken als het voorspellingspunt, blijft er een venster van 30 dagen over om actie te ondernemen. Dit is de tijd tussen het voorspellingspunt en de doelhorizon. Dit is het 30-daagse venster waar het klantsuccesteam om heeft gevraagd om contact te kunnen opnemen met klanten.

Het actievenster is de tijd tussen het voorspellingspunt en de doelhorizon.

De tijdlijn toont het venster voor gegevensaccumulatie tussen het voorspellingspunt en de horizon.

Naast dat we moeten nadenken over het minimumvenster voor actie dat nodig is om stappen te kunnen nemen ten aanzien van de voorspellingen, moeten we ook kijken naar het histogram van dagen tot de klant vertrekt. Door het voorspellingspunt van dag 80 toe te passen, krijgen we het volgende:

De verdeling van beëindigingstelefoontjes met het venster voor gegevensaccumulatie en het venster voor actie.

Histogram waarop het voorspellingspunt en de horizon zijn gemarkeerd

Als we naar dit histogram kijken, zien we dat het gebruik van een voorspellingspunt van dag 80 niet leidt tot een maximale bedrijfswaarde. 80 dagen aan gegevens helpt de nauwkeurigheid van het model te vergroten, maar dit gaat sterk ten koste van de mate waarin actie kan worden genomen:

  • Allereerst zijn op dag 80 al veel klanten vertrokken. Ze hebben hun abonnement al tijdens het venster voor gegevensaccumulatie opgezegd en dus nog voordat we voorspellingen doen. Dit betekent tevens dat we ze niet in onze gegevensverzameling voor training zouden willen opnemen, omdat we de uitkomst al zouden weten voordat we de voorspelling kunnen doen.

  • Ten tweede zeggen veel klanten hun abonnement tussen dag 80 en dag 90 op. Het klantsuccesteam zou dus niet de gehele periode van 30 dagen hebben om contact op te nemen met die klanten.

Klanten die hun abonnement opzeggen vóór het voorspellingspunt, worden niet opgenomen in de gegevens voor de training.

Histogram toont het aandeel klanten dat hun abonnement heeft opgezegd vóór het voorspellingspunt.

Door het voorspellingspunt te verzetten naar dag 60 ontstaat er een betere balans tussen nauwkeurigheid en mogelijkheid tot actie nemen. We hebben nog altijd 60 dagen de tijd om gegevens te verzamelen om kenmerken in ons model te definiëren, maar we doen nu vroeg genoeg voorspellingen om het klantsuccesteam 30 dagen te geven alles uit de groep klanten te halen waarvan we voorspellen dat ze hun abonnement zullen opzeggen. Door het venster voor gegevensaccumulatie te verkleinen, kunnen we een kleine afname van de nauwkeurigheid van het model verwachten, maar wel een voorspelling waarmee meer kan worden gedaan.

Door het voorspellingspunt te verplaatsen naar dag 60, wordt het venster voor gegevensaccumulatie verkort, maar krijgen we een langer venster om actie te ondernemen. Dit sluit minder klanten uit van de gegevens voor de training.

Histogram met vroeger voorspellingspunt en groter venster om actie te nemen.

Kenmerken

Nu dat de gebeurtenistrigger, het doel en het voorspellingspunt zijn gedefinieerd, zijn we klaar voor het laatste deel van onze gegevensverzameling: de kenmerken. Kenmerken zijn bekende attributen, of observaties, voor iedere rij van gegevens in de gegevensset voor training op basis waarvan machine learning-algoritmes algemene patronen kunnen leren. De algoritmen gebruiken de kenmerken vervolgens om voorspellingen te genereren wanneer er een nieuwe rij gegevens in de toe te passen gegevensverzameling verschijnt.

Zie kenmerken als uw hypothese die is gebaseerd op zakelijke kennis over wat de uitkomst beïnvloedt. In onze voorbeelden kunnen kenmerken bijvoorbeeld de locatie van de klant, de bron van de lead, de maand van afsluiten, het aantal aanmeldingen of het aantal actieve gebruikers zijn.

Er zijn twee categorieën kenmerken:

  • Vaste kenmerken zijn het duidelijkst omdat ze niet in de loop van de tijd veranderen. In ons voorbeeld zijn de locatie van de klant (op het moment dat het abonnement wordt afgesloten), de bron van de lead en de maand van afsluiten allemaal vaste kenmerken. Het zijn bekende factoren zodra de klant zich aanmeldt (al op het moment van de gebeurtenistrigger) en het maakt niet uit waar we ons voorspellingspunt plaatsen, deze kenmerken zijn bekend en constant.

  • Vensterafhankelijke kenmerken zijn complexer. Dit zijn de kenmerken die worden verzameld op basis van informatieverzameling tussen de gebeurtenistrigger en het voorspellingspunt. Het is belangrijk om ervoor te zorgen dat u alleen gegevens gebruikt die in de loop van de tijd bekend zouden zijn. Anders kan er sprake zijn van gegevenslekken in het model. (Voor meer informatie zie Lekken van gegevens.)

Een eenvoudig model gebruikt mogelijk alleen informatie die bekend is op dag 0, d.w.z. alleen vaste kenmerken. Dit zou een voorspellingspunt op dag 0 bieden, zoals weergegeven in het figuur.

Met een voorspellingspunt op dag 0, hebben we ook 0 dagen om gegevens te verzamelen en kunnen we alleen vaste kenmerken gebruiken die al op dag 0 bekend zijn. Het actievenster is daarmee de volledige 110 dagen.

Histogram met voorspellingspunt op dag 0.

De resulterende gegevensverzameling zou er ongeveer zo uitzien:

Trainingsgegevens met alleen vaste kenmerken

Tabel met voorbeeldgegevens.

Maar misschien willen we ook gegevens gebruiken die zijn verzameld nadat de klant een abonnement heeft afgesloten, zoals in ons voorbeeld waarbij het voorspellingspunt op dag 60 is ingesteld.

Het voorspellingspunt op dag 60 geeft ons 60 dagen om gegevens te verzamelen en 50 dagen om actie te nemen.

Histogram met voorspellingspunt op dag 60.

Nu kunnen we de gegevens die zijn verzameld in de eerste 60 dagen nadat de klant zich heeft aangemeld, gebruiken om vensterafhankelijke kenmerken aan ons model toe te voegen. Onze gegevensset voor dit model zou er zo uit kunnen zien als de volgende tabel, nu mét de vensterafhankelijke kenmerken. Aanmeldingen eerste 60 dagen en actieve gebruikers op 60 dagen.

Voorbeeldgegevens met vensterafhankelijke kenmerken

Tabel met voorbeeldgegevens.

In dit voorbeeld weerspiegelen de kenmerken de totale duur van het venster voor gegevensaccumulatie. Dit kan ook kleiner zijn. We kunnen bijvoorbeeld de aanmeldingen voor de eerste 10 dagen of die voor dag 30-60 meten, zolang de kenmerken geen informatie omvatten na het voorspellingspunt.

Vensterafhankelijke kenmerken kunnen complexer zijn om te verzamelen omdat ze datums en meer inspanningen vereisen om ervoor te zorgen dat ze binnen het venster voor gegevensaccumulatie vallen om lekken van gegevens te vermijden. Maar ze kunnen ook de beste kenmerken zijn omdat ze gegevens weerspiegelen die veel dichter bij de tijd van voorspelling zijn verzameld.

De resulterende machine learning-vraag

We zijn begonnen met een eenvoudige use case "Zal een klant vertrekken?". We hebben vervolgens onze gebeurtenistrigger gedefinieerd als "Een nieuwe klant meldt zich aan" omdat we voorspellingen wilden kunnen maken op het individuele klantniveau.

We hebben ons doel gedefinieerd met een specifieke uitkomst: "Klant heeft gebeld om zijn of haar abonnement op te zeggen (Ja of Nee)". Daarbij hebben we de horizon ingesteld op 110 dagen, omdat dat het moment is waarop de meeste van onze proefklanten hun abonnement hebben stopgezet.

Aan de hand van een histogram van de afgelopen drie jaar van na hoeveel dagen klanten na het afsluiten van hun abonnement ons bellen om het abonnement op te zeggen, hebben we besloten een voorspellingspunt van 60 dagen na afsluiten te kiezen. Dit zou ons 60 dagen geven om gegevens te verzamelen (het venster voor gegevensaccumulatie) voordat we onze voorspelling doen, maar het zou het klantsuccesteam genoeg tijd bieden om actie te ondernemen naar aanleiding van de voorspellingen om zo het klantverloop te verminderen.

Als laatste hebben we vóór dag 60 beschikbare gegevens van klanten verzameld om zo kenmerken te kunnen genereren.

Onze resulterende machine learning-vraag is: "Zal een klant na de eerste 60 dagen van activiteit, bellen om vóór dag 110 zijn of haar abonnement op te zeggen?"

En de gegevensverzameling, die nu klaar is voor gebruik voor geautomatiseerde machine learning, ziet er uit zoals de onderstaande tabel. Locatie, Bron van lead, Lid geworden in maand en Abonnementsbedrag zijn vaste kenmerken. Aanmeldingen eerste 60 dagen en Actieve gebruikers op 60 dagen zijn vensterafhankelijke kenmerken en Vertrokken op 110 dagen is de doelkolom.

Voorbeeldgegevens met vaste kenmerken (1), vensterafhankelijke kenmerken (2), en doel (3)

Tabel met voorbeeldgegevens.

Was deze pagina nuttig?

Als u problemen ervaart op deze pagina of de inhoud onjuist is – een typfout, een ontbrekende stap of een technische fout – laat het ons weten zodat we dit kunnen verbeteren!