Tillämpning av det strukturerade ramverket: Exemplet kundförlust

I det här exemplet visas processen för att definiera en fråga för maskininlärning steg för steg. Du kommer att lära dig hur du kombinerar affärsinformation med ramverket för händelseutlösare, mål, prognospunkter och funktioner för att strukturera en väldefinierad fråga.

Utgångspunkten är affärssituationen "Kommer en kund att gå förlorad?". Med hjälp av det strukturerade ramverket kommer vi att definiera detta som något mer specifikt som kan förutsägas av en algoritm för maskininlärning.

Händelseutlösare

Händelseutlösaren är en åtgärd eller händelse som aktiverar skapandet av en ny prognos. Vi identifierar vår händelseutlösare som "en kund har tecknat en prenumeration". Detta representeras i data som att en ny kund skapas. Vi vill förutsäga på kundnivå om kunden kommer att förloras, så varje rad måste representera en enskild kund.

Med hjälp av vår kunskap om affärsverksamheten och genom att kontrollera data vet vi att det är bland våra nya kunder som de största förlusterna sker. Vi beslutar därför att fokusera särskilt på nya kunder. Händelseutlösaren är att en ny kund registrerar sig och vi kan tänka oss att varje kund har en individuell tidslinje som börjar den dag då kunden registrerar sig.

Mål

Målet är det resultat som vi försöker förutsäga. Vi vill förutsäga kundförlust, så vi vet att vårt allmänna mål är "Kommer en kund att förloras?". Men vi måste vara mer specifika för att skapa en kvalitetsmodell för maskininlärning. Till att börja med bestämmer vi att "förlust" innebär att en kund hör av sig till oss för att säga upp sin prenumeration.

Därefter bestämmer vi inom vilken tidsram (horisonten) som uppsägningen ska göras. När vi tittar på flera kunder som har gjort uppsägningar ser vi att tidslinjen inte är konsekvent. Vissa kunder säger upp prenumerationen efter 45 dagar och andra inte förrän efter 110 dagar.

Vi har ett kostnadsfritt 90-dagars provprogram och vet att många kunder går förlorade efter provprogrammet. Med utgångspunkt i detta företagssammanhang är vår första tanke att använda en horisont på 90 dagar. Genom att förutse vilka kunder som förväntas säga upp prenumerationen planerar vi att kontakta dessa kunder i förväg och erbjuda incitament (t.ex. rabatter eller ytterligare prenumerationsfunktioner) för att uppmuntra dem att stanna kvar.

Ett histogram över hur många dagar efter registreringen kunderna har sagt upp tjänsten bekräftar vår affärsmässiga intuition. I figuren kan vi se data för alla kunder som har gått förlorade under de senaste tre åren.

Att välja en horisont på 90 dagar verkar vara en bra början. Men när vi ritar upp den horisonten på vårt histogram inser vi att det fortsätter att ske många kundförluster under några dagar efter provperioden på 90 dagar. Anledningen kan vara att kunderna ser att deras kreditkort debiteras eller att de får ett meddelande om att deras betalningsmetod har nekats några dagar senare och att de först därefter ringer in för att säga upp sin prenumeration.

Eftersom vi vill inkludera dessa kunder som "förlorade" i vår modell beslutar vi att det är mer meningsfullt att använda 110 dagar som vår målhorisont. Genom att använda 110 dagar fångar vi upp de flesta kunder vars uppsägning sannolikt är relaterad till programmet för gratis provperiod.

Nu när vi har definierat vårt mål kan vi bestämma var data lagras och hur de behöver rensas för att bygga upp målkolumnen i datauppsättningen. I det här exemplet gör vi följande:

1. Hämta kundstatusen från Salesforce.

2. Extrahera status, datum då kunden skapades och datum då kunden gjorde uppsägningen:

   

3. Rensa och omvandla de extraherade uppgifterna till målkolumnen:

   

Vi har nu definierat vår händelseutlösare (en ny kund har registrerat sig) och vårt mål (kunden ringde för att avbryta sin prenumeration inom 110 dagar efter tecknandet). Dessa illustreras på tidslinjen i figuren.

Prognospunkt

Prognospunkten är den tidpunkt då du slutar samla in data för funktioner och förutsäger målet för varje rad. Prognospunkten kan ligga var som helst mellan händelseutlösaren (dagen då prenumerationen tecknas) och målhorisonten (dag 110 efter tecknandet). För att välja en utgångspunkt kan vi tänka på den åtgärd vi vill vidta.

I vårt exempel kanske kundsupportteamet har bett om 30 dagar för att kontakta kunderna med erbjudanden för att behålla kunderna när det har förutspåtts att kunderna kommer att förloras. Detta innebär att vi bör göra en prognos senast 30 dagar före målhorisonten, det vill säga senast dag 80.

Om vi väljer dag 80 som vår prognospunkt får vi 80 dagar på oss att samla in data om nya kunder när de kommer in. Denna tidsram mellan händelseutlösaren och prognospunkten kallas för datainsamlingsfönstret. Data som samlas in under datainsamlingsfönstret används för att generera funktioner.

Genom att dag 80 används som prognospunkt uppstår ett handlingsfönster på 30 dagar, vilket är tiden mellan prognospunkten och målhorisonten. Detta är det 30-dagarsfönster som kundsupportteamet begärde för att kontakta kunderna.

Förutom att tänka på det minsta handlingsfönster som krävs för att vidta åtgärder med anledning av prognoserna måste vi också titta på histogrammet över antalet dagar till kundförlust. Om vi tillämpar prognospunkten för dag 80 får vi följande:

När vi tittar på detta histogram inser vi att det inte går att maximera affärsvärdet genom att använda en prognospunkt för dag 80. Även om 80 dagars data bidrar till att öka modellens noggrannhet, kostar det mycket i fråga om användbarhet:

• För det första har många kunder redan förlorats vid dag 80, så de kommer att ha förlorats under datainsamlingsfönstret – innan vi ens har gjort några prognoser. Detta innebär också att vi inte skulle vilja inkludera dem i vår träningsdatauppsättning eftersom vi skulle känna till resultatet innan vi gör prognosen.

• För det andra är det många kunder som förloras runt dag 80–90, så kundstödsgruppen har inte hela 30 dagar på sig att kontakta dessa kunder.

Att flytta prognospunkten till dag 60 ger en bättre balans mellan noggrannhet och handlingsförmåga. Vi har fortfarande 60 dagar på oss att samla in data som vi kan använda för funktioner i vår modell, men vi förutsäger nu tillräckligt tidigt för att kundstödsgruppen ska ha 30 dagar på sig att kontakta de flesta av de kunder som vi förutsäger kommer att förloras. Genom att förkorta datainsamlingsfönstret kan vi förvänta oss en liten minskning av modellens noggrannhet, men en mycket mer användbar prognos.

Funktioner

När händelseutlösaren, målet och prognospunkten har definierats är vi redo att lägga till den sista delen i vår datauppsättning: funktionerna. Funktioner är kända attribut, eller observationer, för varje datarad i träningsdatauppsättningen från vilka algoritmerna för maskininlärning lär sig allmänna mönster. Algoritmerna använder sedan funktionerna för att göra prognoser när de får en ny datarad i den tillämpade datauppsättningen.

Tänk på funktioner som dina hypoteser som baseras på affärsinformation om vad som påverkar resultatet. I vårt exempel kan vissa funktioner vara kundens plats, ämneskälla, registreringsmånad, antal inloggningar eller antal aktiva användare.

Det finns två kategorier av funktioner:

• Fasta funktioner är de enklaste eftersom de inte förändras med tiden. I vårt exempel betraktas kundens plats (vid registrering), ämneskälla och registreringsmånad som fasta funktioner. De blir kända så snart en kund registrerar sig (direkt vid händelseutlösaren) och oavsett var vi placerar vår prognospunkt kommer de att vara både kända och konstanta.

• Fönsterberoende funktioner är något mer komplicerade. Dessa funktioner samlas in baserat på information som samlas in mellan händelseutlösaren och prognospunkten. Det är viktigt att se till att du endast använder data som skulle vara kända i tid, annars kan modellen få dataläckage. (Mer information finns i Dataläckage.)

En enkel modell kan endast använda information som är känd dag 0, dvs. endast fasta funktioner. Detta skulle ge en prognospunkt vid dag 0, som visas i figuren.

Det resulterande datauppsättningen skulle se ut ungefär så här:

Men vi kan också vilja använda data som samlas in när kunden har tecknat en prenumeration, som i vårt exempel med prognospunkten vid dag 60.

Nu kan vi använda information som samlats in under de första 60 dagarna efter att en kund har registrerat sig för att lägga till fönsterberoende funktioner i vår modell. Vår datauppsättning för den här modellen kan se ut som följande tabell – nu med de fönsterberoende funktionerna Inloggningar de första 60 dagarna och Aktiva användare vid 60 dagar.

Observera att funktionerna i det här exemplet återspeglar hela datainsamlingsfönstret. De kan också vara mindre. Vi kan till exempel mäta inloggningar de första tio dagarna eller inloggningar dag 30–60, så länge funktionerna inte innehåller någon information efter prognospunkten.

Fönsterberoende funktioner kan vara mer komplicerade att samla in eftersom de kräver datum och kräver extra ansträngningar för att se till att de faller inom datainsamlingsfönstret för att undvika dataläckage. Men de kan också vara några av de mest kraftfulla funktionerna eftersom de kan återspegla information som samlats in mycket närmare tidpunkten för prognosen.

Den resulterande frågan för maskininlärning

Vi började med det enkla användningsfallet "Kommer en kund att förloras?". Vi definierade sedan vår händelseutlösare som "En ny kund registrerar sig" eftersom vi ville göra prognoser på individuell kundnivå.

Vi definierade vårt mål med ett specifikt resultat – "Kunden ringde för att säga upp sin prenumeration (Ja eller Nej)" – och satte horisonten till 110 dagar eftersom det är den tid då de flesta av våra provperiodskunder har sagt upp sin prenumeration.

När vi tittade på ett histogram över hur många dagar efter registreringen kunderna ringde för att säga upp prenumerationen under de senaste tre åren bestämde vi oss för en prognospunkt på 60 dagar efter registreringen. Detta skulle ge oss 60 dagar för att samla in information (datainsamlingsfönstret) innan vi gör vår prognos, men det skulle ändå ge kundsupportteamet tid att vidta åtgärder med anledning av prognoserna för att minska kundförlusterna.

Slutligen samlade vi in uppgifter om kunder som skulle vara tillgängliga före dag 60 för att generera funktioner.

Vår fråga för maskininlärning blir följande: "Efter de första 60 dagarna av aktivitet, kommer en kund att ringa för att säga upp prenumerationen senast dag 110?"

Datauppsättningen, som nu är redo att användas för automatiserad maskininlärning, ser ut som i tabellen nedan. Plats, Ämneskälla, Registreringsmånad och Prenumerationsbelopp är fasta funktioner, Inloggningar de första 60 dagarna och Aktiva användare vid 60 dagar är fönsterberoende funktioner och Förlust vid 110 dagar är målkolumnen.