Vurdering av kundefrafallsrisiko med SQL og maskinlæring

Home » Python » Vurdering av kundefrafallsrisiko med SQL og maskinlæring

Kundefrafall er en av de stille profittdreperne som sakte undergraver veksten hvis du ikke måler det riktig og handler i tide. Den gode nyheten er at du i dag kan bygge robuste churn-risikomodeller direkte med SQL oppå datalageret ditt, og kombinere klassiske maskinlæringsteknikker, administrerte skytjenester og svært praktiske forretningsmålinger.

Denne veiledningen tar deg gjennom hele prosessen med evaluering av kundeavfallsrisiko med SQL på tvers av ulike scenarier: fra å bruke Amazon Redshift ML og Amazon SageMaker til å trene modeller med ren SQL, til å lage logistiske regresjons-churnmodeller på webhendelser, og helt til mer avanserte teknikker som hyperparameterjustering og håndtering av ubalanserte data (churn vs. ikke-churn) inspirert av Python-baserte arbeidsflyter. Målet er å vise deg i detalj hvordan du går fra rådata til handlingsrettede risikoscore som markedsførings-, kundesuksess- og finansteamene dine faktisk kan bruke.

Hvorfor risikovurdering med SQL er viktig for bedriften din

Å forutsi hvilke kunder som sannsynligvis vil forlate butikken er et av bruksområdene med høyest avkastning for anvendt maskinlæring og analyse. Å miste en kunde er vanligvis mye dyrere enn å beholde dem, og små forbedringer i kundelojalitet har en uforholdsmessig stor innvirkning på inntekter og langsiktig lønnsomhet.

SQL spiller en sentral rolle i denne reisen fordi de fleste transaksjons-, atferds- og kundedata allerede finnes i databaser og skybaserte datalagre; en oversikt over datalagringssystemer hjelper å forstå hvordan man kan utnytte dem. Hvis teamene dine kan opprette, trene og distribuere churn-modeller direkte fra SQL, unngår de konstant dataeksport, verktøybytte og komplekse ingeniørpipeliner, noe som reduserer tiden til verdi drastisk.

Moderne skyplattformer visker nå ut grensen mellom analyse og maskinlæringTjenester som Amazon Redshift ML lar dataanalytikere og utviklere bygge, trene og bruke ML-modeller fra kjente SQL-setninger, samtidig som de fortsatt er avhengige av fullstendig administrerte tjenester som Amazon SageMaker og SageMaker Autopilot. Det betyr at du kan kjøre på churn-modeller uten å bli en fulltids ML-ingeniør.

I tillegg til teknologien må churn-analysen forbli tett knyttet til forretningsvirkeligheten: hvordan du definerer en «aktiv» kunde, hvilke signaler indikerer risiko, hvilken terskel for inaktivitet som er viktig (30, 60, 90 dager…), og hvor mye du er villig til å investere i retensjonskampanjer basert på forventet risiko. Teknikkene vi skal dekke er fleksible nok til å tilpasse seg svært forskjellige bransjer: bank, telekom, SaaS, e-handel og mer.

Bruk av Amazon Redshift ML til å bygge churn- og risikomodeller med SQL

Amazon Redshift ML er et godt eksempel på hvordan man kan bringe ML dit dataene dine allerede finnes.Den lar deg opprette, trene og distribuere modeller ved hjelp av SQL-kommandoer i Amazon Redshift, mens Amazon SageMaker gjør det tunge arbeidet i bakgrunnen.

I praksis eksponerer Redshift ML den trente modellen din som en SQL-funksjon. som du kan kalle inn spørringer, dashbord og ETL-jobber. For brukstilfeller for churn og risiko betyr det at du sømløst kan integrere prediksjoner som «høyrisikokunde», «sannsynlighet for kredittmislighold» eller «sannsynlighet for churn» i standard rapportering og datapipeliner.

Under panseret er Redshift ML avhengig av Amazon SageMaker AutopilotAutopilot utforsker automatisk flere algoritmer og hyperparametere, trener og finjusterer kandidatmodeller, og velger den beste gitt målet og dataene dine. Du beholder full oversikt og kontroll, men du hopper over det meste av den lavnivåbaserte maskinlæringsprosessen.

Sluttresultatet er en kjent utvikleropplevelseDu skriver en SQL CREATE MODEL-setning oppå Redshift-tabellene dine, peker på en S3-bøtte for mellomliggende artefakter, og når treningen er fullført, får du en SQL-skalarfunksjon som kan brukes til inferens i stor skala på tvers av lageret ditt.

Ende-til-ende eksempel: kredittrisiko og churn-lignende prediksjon i Redshift

For å begrunne konseptene, la oss gå gjennom et konkret eksempel basert på finansiell risiko.Selv om målvariabelen i dette tilfellet er kredittrisiko (høy vs. lav), er arbeidsflyten identisk med en klassisk churn-prediksjon: du har merket historiske data, du trener en binær klassifikator, og deretter scorer du nye eller eksisterende kunder på forespørsel.

Eksempeldatasettet kommer fra UCI Machine Learning Repository og inkluderer 1,001 poster, som hver beskriver en bankkunde med 14 attributter knyttet til deres økonomiske profil og forhold til institusjonen. Selv om den er beskjeden i størrelse etter moderne standarder, er den nok til å illustrere prosessen fra rådata til distribuert SQL-modell.

De viktigste attributtene (funksjonene) i dette datasettet dekker både demografisk og økonomisk atferd.:

• eksisterende sjekkstatus for den eksisterende brukskontoen.
• varighetmåneder med forhold eller kredittvarighet.
• kredittbeløp: forespurt kredittbeløp.
• sparingnåværende sparenivå.
• ansettelse sidenlengden på nåværende ansettelse.
• kjønnkundens kjønn.
• status: sivilstatus.
• alderkundens alder.
• bolig: boligsituasjon (eie, leie osv.).
• eksisterende kreditterantall eksisterende studiepoeng.
• jobbansettelsesstatus.
• jobbtype: type jobb.
• avhengigeantall pårørende.
• risiko: målvariabel; indikerer om kunden anses som høyrisiko.

Målvariabelen, risiko, er binær, så dette er et klassisk binært klassifiseringsproblem. Du kan tenke på risiko = SANN som analogt med en churn-etikett, der du vil identifisere kunder som sannsynligvis vil misligholde eller forlate kunden, slik at du kan handle proaktivt.

Til tross for det lille datasettet, gjenspeiler oppsettet en ekte ML-arbeidsflytDu deler fortsatt data inn i tog- og inferenssett, definerer et passende skjema i Redshift, oppretter en S3-bøtte for treningsdata og artefakter, og konfigurerer en IAM-rolle med tilgang til S3 og SageMaker. I produksjon skalerer du ganske enkelt opp dette med flere rader og rikere funksjonssett.

Klargjøring av Redshift-miljøet og dataene

Før du trener noen modell, må du sørge for at Redshift-klyngen og tillatelsene er på plass.Du kan enten opprette klyngen via AWS Management Console eller bruke en CloudFormation-mal som automatiserer nettverks- og sikkerhetskonfigurasjonen.

Når du klargjør via konsollen, velger du vanligvis en nodetype og antall (for eksempel dc2.large med to noder for en demo), angi en databaseport, et hovedbrukernavn og et hovedpassord, og viktigst av alt, legg til en IAM-rolle som gir klyngen tilgang til S3-bøtta der CSV-filene for trening og inferens ligger.

Hvis du foretrekker infrastruktur som kode, kan en CloudFormation-mal starte Redshift-klyngen. sammen med sikkerhetsgruppene, delnettgruppen og IAM-rollen på én gang. Fra perspektivet til churn-risikomodellering er det viktigste ganske enkelt at klyngen kan lese fra og skrive til den angitte S3-bøtten.

Når klyngen kjører, går du til Redshift Query EditorDerfra kobler du deg til databasen, bekrefter legitimasjonen din og begynner med å opprette to tabeller: én for trening (historiske merkede kunder) og én for inferens (poster du senere vil bruke til å teste modellens ytelse).

Treningstabellskjemaet speiler CSV-strukturen nøye:

• Tekstkolonner for attributter som eksisterende sjekkkonto, sparing, ansettelse siden, kjønn, status, bolig, jobb og jobbtype.
• Numeriske kolonner for varighet, kredittbeløp, alder, eksisterende kreditter og forsørgede.
• En boolsk kolonnerisiko, brukt som målet som skal forutsies.

Datainnlasting håndteres via Redshift COPY-kommandoen, som henter fra S3 ved hjelp av IAM-rollen, spesifiserer CSV-format, headerhåndtering og skilletegn, og fyller ut både trenings- og inferenstabellene. Etter at COPY-operasjonene er fullført, kan du sjekke objekttreet i redigeringsprogrammet for å bekrefte tabellene og radantallene.

Opprette og trene en Redshift ML-modell med SQL

Med dataene på plass, er neste trinn å trene en Redshift ML-modell ved hjelp av en CREATE MODEL-setning.Det er her SageMaker Autopilot kommer inn under dyna for å teste flere kandidatalgoritmer og hyperparametere for ditt binære klassifiseringsproblem.

CREATE MODEL-kommandoen velger alle relevante prediktorkolonner fra risk_prediction_training, angir risiko-kolonnen som TARGET, og definerer navnet på SQL-funksjonen som senere skal brukes til inferens over datavarehuset ditt.

To viktige innstillinger kreves: IAM_ROLE og S3_BUCKETIAM-rollen må tillate listing og lesing fra S3-bøtten, og S3-bøtten brukes av Redshift og SageMaker til å utveksle treningsdata og modellartefakter. Du kan også spesifisere en MAX_RUNTIME i sekunder for å begrense hvor lenge Autopilot har lov til å eksperimentere.

Det er vanlig å støte på tillitsproblemer første gangHvis SageMaker ikke kan overta IAM-rollen som er knyttet til Redshift-klyngen din, vil CREATE MODEL-kommandoen mislykkes. Du må deretter justere rollens tillitspolicy for å inkludere sagemaker.amazonaws.com som en klarert tjenesteprinsipper.

Hvis en tidligere modell med samme navn finnes, kan du slette den bruker DROP MODEL før du gjenskaper den. Dette lar deg iterere modelleringsstrategien din eller justere innstillinger uten å fylle miljøet med foreldede modeller.

Overvåking av trening og validering av Redshift ML-modellen

Treningstiden vil variere basert på datastørrelse og kjøretidsgrenser, men for eksempeldatasettet for kredittrisiko kan du forvente noe i størrelsesorden en time. I løpet av den tiden kan du sjekke modellstatus og metadata ved å kjøre VIS MODELL med modellnavnet.

VIS MODELLEN avslører viktig informasjon som for eksempel treningsstatus (for eksempel OPPLÆRING, KLAR), den valgte algoritmen, objektiv metrikk og valideringspoeng. For binær klassifisering er en av de viktigste metrikkene ofte F1-poengsummen, som går fra 0 til 1 og balanserer presisjon og gjenkjenning.

Når modellens status er KLAR, kan du begynne å evaluere dens prediktive ytelse ved hjelp av det separate inferensdatasettet som modellen aldri har sett under trening. Dette speiler et reelt scenario der nye kunder blir scoret underveis.

En enkel første sjekk er å beregne den totale nøyaktighetenDu gjør dette ved å kjøre en SQL-spørring som: trekker ut den faktiske risikoetiketten, kaller modellfunksjonen (for eksempel func_risk_prediction_model) for å hente den predikerte etiketten, flagger riktige vs. feil prediksjoner, og deretter aggregerer for å beregne num_correct delt på total.

Utover rå nøyaktighet kan du beregne samlede risikofordelinger på inferenssettetFor eksempel kan du telle hvor mange kunder som er tildelt hver risikokategori (høy, lav, ubestemt) for å forstå modellens atferd og hvor mange saker som vil bli flagget for videre gjennomgang eller proaktive retensjonstiltak.

Definere kundeatferdsfunksjoner for SQL-kundeavgangmodeller

Fra kredittrisiko til faktisk churn gjelder de samme ML-prinsippeneDu trenger merkede historiske data og meningsfulle funksjoner som fanger opp hvordan kunder oppfører seg og utvikler seg over tid. For e-handel eller digitale produkter betyr dette vanligvis å samle kjøps- og interaksjonsmålinger per kunde.

En typisk SQL-churnmodell starter fra en tabell over netthendelser eller -transaksjoner, der hver rad representerer et kjøp eller en handelshendelse med felt som tidsstempler, ordre-ID-er, produktpriser og -mengder og brukeridentifikatorer.

Fra disse rå hendelsene kan du konstruere kraftige atferdstrekk som oppsummerer en kundes historikk:

• totale_kjøptotalt antall fullførte kjøp per kunde.
• total_inntekt: kumulativ inntekt generert av den kunden.
• gjnsn._ordreverdigjennomsnittlig handlekurvverdi; total_inntekt delt på total_kjøp.
• kundens_levetiddager mellom første og siste kjøp.
• dager_siden_siste_kjøp: nylighet, målt som dager fra det siste kjøpet til en referansedato.
• kjøpsfrekvensAntall forskjellige måneder kunden kjøpte, med register over regelmessighet.

Disse funksjonene er avgjørende fordi churn sjelden er tilfeldigKunder som gradvis kjøper sjeldnere, bruker mindre penger og ignorerer markedsføringen din, sender vanligvis klare signaler om at de kanskje er i ferd med å dra. Å fange opp frekvens, nylighet og pengeverdi (den klassiske RFM-trioen) i SQL er vanligvis det første trinnet.

Alt dette ligger i en pålitelig kundeidentifikatorI mange oppsett for digital analyse er det en Experience Cloud ID (ECID) eller lignende ID lagret i et felt som identityMap.id som lar deg sette sammen hendelser på tvers av økter og enheter i én kundehistorikk.

Datakrav og forutsetninger for nettbasert modellering av kundefrafall

For å trene en churn-modell direkte fra netthendelser, må datasettet ditt oppfylle visse minimumskrav.Hver rad skal representere en transaksjon eller kjøpshendelse med nok detaljer til å kunne aggregeres til funksjoner på kundenivå.

De typiske obligatoriske feltene inkluderer:

• identitetskart.iden stabil kundeidentifikator på tvers av økter.
• produktListeVarer.prisTotal: total kostnad for varer per transaksjon.
• produktListeVarer.antall: total mengde varer.
• tidsstempel: hendelsesdato og -klokkeslett i et format som er kompatibelt med dato-/klokkeslettfunksjoner som DATEDIFF (for eksempel ÅÅÅÅ-MM-DD TT:MM:SS).
• handel.ordre.kjøpsIDen verdi som ikke er null, men som bekrefter et fullført kjøp.

Historisk dybde er viktigFor å skille mellom midlertidig inaktivitet og reell kundefrafall, trenger du nok måneder med data til å se flere kjøpssykluser per kunde, spesielt i vertikaler med lange kjøpsintervaller (reise, forsikring, B2B-kontrakter osv.).

Modellen er også avhengig av en klar, operasjonell definisjon av churnEn vanlig, praktisk regel for netthandel er å anse en kunde som churn-kunde hvis de ikke har kjøpt noe de siste 90 dagene i forhold til en referansedato. Denne terskelen kan tilpasses (30, 60, 180 dager) basert på din normale kjøpssyklus.

Når datasettet er strukturert og forutsetningene er klare, kan du bruke SQL til å lage etiketter (churned vs. not churned) ved å sammenligne days_since_last_purchase med terskelen din, og deretter generere treningstabellen som mater den logistiske regresjonen eller annen klassifiseringsalgoritme.

Bygge en logistisk regresjonsmodell for churn med SQL

Logistisk regresjon er en naturlig løsning for churn-prediksjon med SQL fordi den gir sannsynligheter mellom 0 og 1 og ofte støttes innebygd eller via ML-utvidelser i moderne analysedatabaser og kundedataplattformer.

Modelleringsprosessen går vanligvis i tre faserfunksjonsteknikk, etiketttildeling og modelltrening.

Først samler du netthendelsene dine i rader på kundenivå beregner totale_kjøp, total_inntekt, gjnsn._ordreverdi, kundens_levetid, dager_siden_siste_kjøp og kjøpsfrekvens. Dette kan gjøres i en enkelt SQL-setning med GROUP BY og vindusfunksjoner, eller i trinn med mellomliggende tabeller.

For det andre oppretter du en churn-etikett basert på en inaktivitetsregelFor eksempel, churned = 1 hvis days_since_last_purchase > 90, ellers churned = 0. Dette merkede datasettet blir input til den logistiske regresjonstreningsrutinen, som kan kalles via en SQL CREATE MODEL-setning eller en leverandørspesifikk funksjon.

For det tredje trener du den logistiske regresjonsmodellen som spesifiserer hvilke kolonner som er funksjoner. og hvilken kolonne som er måletiketten (churned). ML-motoren lærer koeffisienter som gjenspeiler hvordan hver funksjon bidrar til churn-risiko, noe som kan være svært innsiktsfullt for interessenter i forretningsverdenen.

Modellutdataene er vanligvis en tabell eller visning med én rad per kunde, inkludert de konstruerte funksjonene og den churn-etiketten. Senere, når du bruker modellen til prediksjon, får du en ekstra prediksjonskolonne som representerer enten den predikerte etiketten (0 eller 1) eller churn-sannsynligheten.

Evaluering av churn-modeller: målinger som faktisk betyr noe

Å trene en churn-modell er bare halve jobben; du må grundig evaluere ytelsen før den distribueres i produksjonskampanjer. SQL-baserte ML-rammeverk eksponerer ofte evalueringshjelpemidler, for eksempel en model_evaluate-funksjon, som beregner vanlige målinger.

For churn er det avgjørende å se utover rå nøyaktighetNøyaktighet måler ganske enkelt prosentandelen av riktige spådommer, men i ubalanserte problemer (der de fleste kunder ikke forlater kundene) kan en modell være «nøyaktig» samtidig som den er nesten ubrukelig for bedriften din.

Viktige målinger for churn-prediksjon inkluderer:

• AUC-ROC: måler modellens evne til å skille mellom «churners» og «non-churners» på tvers av alle klassifiseringsterskler; verdier nærmere 1 indikerer sterkere diskriminering.
• Precision: andel av forventede churnere som faktisk er churnere; høy presisjon betyr færre falske alarmer og mer effektive utgifter til retensjon.
• Husker: andel av faktiske kunder som forlater virksomheten og som modellen identifiserer riktig; høy gjenkallelse sikrer at du ikke går glipp av mange kunder i faresonen.
• F1-poengsum: harmonisk gjennomsnitt av presisjon og tilbakekalling, nyttig når du trenger en balanse mellom å fange mange churners og unngå for mange falske positiver.

I mange virkelige churn-prosjekter bryr forretningsinteressenter seg mer om presisjon og gjenkjenning av den positive klassen. (kunder som forventes å forlate kunde) enn global nøyaktighet. Målet er tross alt å målrette tilbud om kundebevaring effektivt, ikke å se bra ut på én gjennomsnittlig måleenhet.

SQL-drevet evaluering gjøres vanligvis mot et hold-out testsett som ikke ble brukt til trening. Du sender dette datasettet til model_evaluate-funksjonen eller tilsvarende, henter AUC-ROC, nøyaktighet, presisjon og gjenkalling, og itererer deretter på funksjonsutvikling, terskler eller algoritmer basert på disse resultatene.

Python-inspirerte teknikker for å forbedre churn-modeller

Mange beste fremgangsmåter innen churn-modellering kommer fra det bredere ML-økosystemet, hvor Python og biblioteker som scikit-learn, imbalanced-learn og andre er mye brukt. Konseptene kan imidlertid overføres til SQL-sentriske arbeidsflyter eller hybridoppsett hvor SQL håndterer funksjonsoppretting og Python håndterer avansert modellering.

Et vanlig mønster er å begynne å utforske churn med et offentlig datasett for eksempel en CSV-fil om bankfrafall fra Kaggle. Disse datasettene inkluderer vanligvis demografi (alder, land, kjønn), kontoens varighet, antall produkter, kredittscore og om kunden har gått ut (frafalt).

Den vanlige arbeidsflyten starter med å laste inn og inspisere datasettet: kontroll av antall rader og kolonner, oppsummering av numeriske funksjoner, utforskning av målfordelingen og identifisering av åpenbart irrelevante attributter som kundenes etternavn eller ugjennomsiktige ID-er som ikke vil hjelpe med prediksjon.

Visuell utforskning er spesielt nyttigÅ plotte fordelinger og boksplott av kontinuerlige variabler (som alder eller ansettelsestid) delt etter churn-merkelapp kan raskt avsløre hvilke funksjoner som har forklaringskraft. Histogrammer for kategoriske variabler (kjønn, land) viser om visse kategorier korrelerer med høyere churn.

I løpet av denne utforskende fasen ser du også etter problemer med datakvalitetenmanglende verdier, ekstreme avvikere, dominerende kategorier og mistenkelige mønstre. Alle disse kan påvirke ytelsen til nedstrømsmodeller og kan kreve rengjøring, avkorting eller ny koding.

Kategoriske variabler er et annet viktig poeng. ML-algoritmer forventer vanligvis numerisk input, så tekstkategorier må kodes. Enkle ordinære kodere tilordner kategorier til heltall, noe som kan fungere, men kan introdusere kunstig rekkefølge (f.eks. fargekoder der 6 ikke er "større enn" 2 i noen meningsfull forstand). Mer sofistikerte kodinger som one-hot eller target-koding gir vanligvis bedre modeller, om enn på bekostning av flere funksjoner.

Fra den første churn-modellen til robust evaluering

Etter grunnleggende rengjøring og koding kan en første churn-modell trenes– for eksempel en tilfeldig skogklassifikator, som er robust, håndterer ikke-lineære forhold godt og krever relativt lite funksjonsskalering.

Deretter deler du dataene inn i trenings- og testsett (for eksempel 70 % trening, 30 % testing) for å simulere fremtidige, usynlige kunder. Modellen tilpasses treningssettet og evalueres på testsettet ved hjelp av målinger som nøyaktighet, presisjon, gjenkjenning og F1-poengsum.

På dette stadiet er det veldig lett å bli villedet av tall med høy nøyaktighet.I problemer med ubalansert churn kan en modell oppnå høy nøyaktighet ganske enkelt ved alltid å forutsi majoritetsklassen (ikke-churn), samtidig som den knapt fanger opp noen faktiske churn-faktorer. Derfor er presisjon, gjenkallelse og F1 spesifikk for churn-klassen mye mer relevant.

ROC-kurven og dens areal under kurven (AUC) gi et mer nyansert bilde som viser avveiningen mellom sann positiv rate og falsk positiv rate på tvers av alle terskler. En kurve som tydelig dominerer den diagonale grunnlinjen indikerer en nyttig modell, men igjen må du relatere dette til forretningsmessige kostnad/nytte-avveininger.

Å velge riktig evalueringsmåling er en forretningsavgjørelseHvis det er dyrt å oppsøke kunder for å beholde kundene, kan det være lurt å foretrekke høy presisjon (bare målrette mot potensielle kunder som forlater kundene). Hvis det er ekstremt kostbart å miste en kunde, kan det være lurt å akseptere flere falske positiver og fokusere på tilbakekalling (fange opp så mange kunder som forlater kundene som mulig), selv om det betyr å kontakte flere kunder.

Hyperparameterjustering og håndtering av ubalanserte churn-etiketter

Når en grunnleggende churn-modell er på plass, kommer de neste store gevinstene vanligvis fra hyperparameterjusteringHyperparametere er konfigurasjonsverdier utenfor treningsprosessen (antall trær, tredybde, læringshastighet osv.) som kan påvirke modellkvaliteten dramatisk.

En praktisk tilnærming er å definere et hyperparametersøkerom (et rutenett eller tilfeldige områder for hver parameter) og deretter utforske et delsett av kombinasjoner ved hjelp av randomisert søk eller Bayesiansk optimalisering. For hver kandidatkonfigurasjon kjøres kryssvalidering på treningsdataene, og en metrikk som F1-poengsum brukes til å sammenligne dem.

For churn er F1 ofte et bedre mål enn ren nøyaktighet fordi den balanserer presisjon og gjenkjenning, som er det du vanligvis bryr deg om når du prioriterer kunder i faresonen.

En annen stor utfordring i churn-modellering er ubalanse i etiketterDet er vanligvis mange flere ikke-churners enn churners i de historiske dataene dine. Hvis de ikke blir adressert, vil de fleste algoritmer lære å «spille trygt» og forutsi majoritetsklassen mesteparten av tiden.

Det finnes flere strategier for å håndtere ubalanserte kundeavfallsdata:

• Oversampling av minoritetsklassen ved hjelp av teknikker som SMOTE, ADASYN eller SVMSMOTE, som syntetiserer nye minoritetseksempler ved å interpolere mellom eksisterende.
• Undersampling av majoritetsklassen å krympe datasettet samtidig som klassene gjøres mer balanserte (noen ganger kombinert med oversampling).
• Bruk av algoritmer eller innpakningsprogrammer som håndterer klassevekter eller balanserte delmengder internt, for eksempel balanserte tilfeldige skoger som trener hvert tre på et klassebalansert bootstrap-utvalg.

Empirisk sett er det avgjørende at testsettet ditt forblir urørt og ubalansert, som gjenspeiler den sanne produksjonsfordelingen. Du kan oversample eller på annen måte manipulere bare treningssettet; ellers vil evalueringsmålingene være for optimistiske og ikke representative for ytelsen i den virkelige verden.

I mange eksperimenter, bruk av balansering på algoritmenivå (som en balansert tilfeldig skog) uten å endre de rå treningsdataene har gitt betydelige gevinster i presisjon og F1, noen ganger med ti prosentpoeng eller mer. For en churn-modell kan dette føre til betydelig bedre målretting av kunder i faresonen og høyere avkastning på retensjonskampanjer.

Husk at hvert prosentpoeng med forbedring i effektiv retensjon kan ha en enorm innvirkning på gjentakende inntekter og kundens livstidsverdi. Å nøyaktig oppdage flere churn-avganger er ikke det endelige målet, men det gir deg innflytelsen til å implementere tilbud, tjenesteforbedringer og personlige tiltak der de betyr mest.

Alt i alt gir kombinasjonen av SQL-native ML-funksjoner (som Amazon Redshift ML og SQL-drevet logistisk regresjon) med solide maskinlæringspraksiser (funksjonsteknikk, riktige målinger, hyperparameterjustering og ubalansehåndtering) deg et kraftig verktøysett for å evaluere churn-risiko direkte der dataene dine befinner seg. Enten du opererer innen finans, telekom, e-handel eller SaaS, lar disse teknikkene deg transformere rå interaksjonshistorikk til tydelige churn-risikoscore som markedsførings- og driftsteam trygt kan handle ut fra, og dermed stramme inn tilbakemeldingssløyfen mellom analyser og forretningsbeslutninger.