Procjena rizika od odliva kupaca pomoću SQL-a i mašinskog učenja

Početna » piton » Procjena rizika od odliva kupaca pomoću SQL-a i mašinskog učenja

Odliv kupaca je jedan od onih tihih ubica profita. što polako nagriza rast ako ga ne mjerite pravilno i ne reagujete na vrijeme. Dobra vijest je da danas možete izgraditi robusne modele rizika od odliva direktno pomoću SQL-a na vašem skladištu podataka, kombinirajući klasične tehnike mašinskog učenja, upravljane usluge u oblaku i vrlo praktične poslovne metrike.

Ovaj vodič vas vodi kroz kompletnu procjenu rizika od odliva korisnika pomoću SQL-a. u različitim scenarijima: od korištenja Amazon Redshift ML i Amazon SageMaker za treniranje modela čistim SQL-om, do kreiranja logističkih regresijskih modela odliva korisnika na web događajima, pa sve do naprednijih tehnika poput podešavanja hiperparametara i rukovanja neuravnoteženim podacima (odliv naspram neodliva) inspirisanih radnim procesima zasnovanim na Pythonu. Cilj je da vam detaljno pokažemo kako da pređete sa sirovih podataka na praktične ocjene rizika koje vaši marketinški, timovi za uspjeh kupaca i finansijski timovi zapravo mogu koristiti.

Zašto je procjena rizika od odliva korisnika pomoću SQL-a važna za vaše poslovanje

Predviđanje koji će kupci vjerovatno otići jedan je od slučajeva upotrebe s najvećim povratom ulaganja (ROI). za primijenjeno mašinsko učenje i analitiku. Gubitak kupca je obično mnogo skuplji od njegovog zadržavanja, a mala poboljšanja u zadržavanju imaju nesrazmjeran utjecaj na prihod i dugoročnu profitabilnost.

SQL igra centralnu ulogu u ovom putovanju jer se većina transakcijskih, bihevioralnih i korisničkih podataka već nalazi u bazama podataka i skladištima podataka u oblaku; pregled sistema za pohranu podataka pomaže u razumijevanju kako ih iskoristiti. Ako vaši timovi mogu kreirati, obučavati i implementirati modele odliva korisnika direktno iz SQL-a, izbjegavaju stalni izvoz podataka, promjenu alata i složene inženjerske procese, drastično smanjujući vrijeme ostvarivanja vrijednosti.

Moderne cloud platforme sada brišu granicu između analitike i strojnog učenja.Servisi poput Amazon Redshift ML omogućavaju analitičarima podataka i programerima da grade, obučavaju i koriste ML modele iz poznatih SQL naredbi, a istovremeno se oslanjaju na potpuno upravljane servise poput Amazon SageMaker i SageMaker Autopilot. To znači da možete upravljati modelima odliva korisnika bez da postanete ML inženjer s punim radnim vremenom.

Pored tehnologije, analiza odliva korisnika mora ostati čvrsto povezana s poslovnom stvarnošću.: kako definirate „aktivnog“ kupca, koji signali ukazuju na rizik, koji je prag neaktivnosti važan (30, 60, 90 dana...) i koliko ste spremni uložiti u kampanje zadržavanja kupaca na osnovu predviđenog rizika. Tehnike koje ćemo obraditi su dovoljno fleksibilne da se prilagode vrlo različitim industrijama: bankarstvu, telekomunikacijama, SaaS-u, e-trgovini i drugima.

Korištenje Amazon Redshift ML-a za izgradnju modela odliva i rizika pomoću SQL-a

Amazon Redshift ML je odlična ilustracija kako dovesti ML tamo gdje se vaši podaci već nalaze.Omogućava vam kreiranje, obuku i implementaciju modela pomoću SQL naredbi unutar Amazon Redshifta, dok Amazon SageMaker obavlja sav težak posao u pozadini.

U praksi, Redshift ML predstavlja vaš obučeni model kao SQL funkciju. da možete pozivati ​​upite, kontrolne ploče i ETL poslove. Za slučajeve upotrebe odliva i rizika, to znači da možete besprijekorno ugraditi predviđanja kao što su „visokorizični kupac“, „vjerovatnoća neizvršenja kreditnih obaveza“ ili „vjerovatnoća odliva“ u svoje standardne izvještaje i podatkovne kanale.

Ispod haube, Redshift ML se oslanja na Amazon SageMaker Autopilot.Autopilot automatski istražuje više algoritama i hiperparametara, obučava i podešava kandidatske modele te odabire najbolji s obzirom na vaš cilj i podatke. Zadržavate potpunu vidljivost i kontrolu, ali preskačete većinu niskonivojskih ML instalacija.

Krajnji rezultat je poznato iskustvo za programereNapišete SQL CREATE MODEL naredbu preko vaših Redshift tabela, pokažete na S3 bucket za međuartefakte, a kada se obuka završi, dobijete SQL skalarnu funkciju koja se može koristiti za zaključivanje na velikoj skali u vašem skladištu.

Primjer od početka do kraja: kreditni rizik i predviđanje slično odlivu klijenata u Redshiftu

Da bismo utemeljili koncepte, pogledajmo konkretan primjer zasnovan na finansijskom riziku.Iako je ciljna varijabla u ovom slučaju kreditni rizik (visok vs. nizak), tijek rada je identičan klasičnom predviđanju odliva kupaca: označili ste historijske podatke, trenirali binarni klasifikator, a zatim na zahtjev ocjenjujete nove ili postojeće kupce.

Primjer skupa podataka dolazi iz UCI Machine Learning Repositoryja i uključuje 1,001 zapis, od kojih svaki opisuje bankarskog klijenta sa 14 atributa vezanih za njegov finansijski profil i odnos s institucijom. Iako skromne veličine prema modernim standardima, dovoljan je da ilustruje proces od sirovih podataka do implementiranog SQL modela.

Ključni atributi (karakteristike) u ovom skupu podataka pokrivaju i demografsko i finansijsko ponašanje:

• postojeća provjera: status postojećeg tekućeg računa.
• trajanjemjeseci veze ili trajanje kredita.
• iznos kreditatraženi iznos kredita.
• uštedetrenutni nivo štednje.
• zaposlenje oddužina trenutnog zaposlenja.
• seksspol kupca.
• statusbračni status.
• starost: starost kupca.
• stanovanjestambena situacija (vlastito, iznajmljeno, itd.).
• postojeći kreditibroj postojećih kredita.
• posaoradni status.
• vrsta posla: vrsta posla.
• izdržavane osobebroj izdržavanih osoba.
• rizik: ciljna varijabla; pokazuje da li se kupac smatra visokorizičnim.

Ciljna varijabla, rizik, je binarna, dakle, ovo je klasičan problem binarne klasifikacije. Možete shvatiti rizik = TAČNO kao analogiju oznaci odljeva kupaca, gdje želite identificirati kupce koji će vjerovatno prestati s plaćanjem ili će otići kako biste mogli proaktivno djelovati.

Uprkos malom skupu podataka, postavka odražava stvarni ML tok rada.I dalje dijelite podatke na skupove za obuku i zaključivanje, definirate odgovarajuću shemu u Redshiftu, kreirate S3 odjeljak za podatke za obuku i artefakte te konfigurirate IAM ulogu s pristupom S3 i SageMakeru. U produkciji biste ovo jednostavno skalirali s više redova i bogatijim skupovima funkcija.

Priprema okruženja i podataka za Redshift

Prije treniranja bilo kojeg modela, morate se uvjeriti da su Redshift klaster i dozvole na mjestu.Klaster možete kreirati putem AWS Management Console-a ili koristiti CloudFormation predložak koji automatizira konfiguraciju mreže i sigurnosti.

Prilikom pružanja usluga putem konzole, obično birate tip i broj čvorova (na primjer, dc2.large s dva čvora za demonstraciju), postavite port baze podataka, glavno korisničko ime i lozinku i, što je ključno, dodajte IAM ulogu koja klasteru daje pristup S3 kontejneru u kojem se nalaze vaše CSV datoteke za obuku i zaključivanje.

Ako preferirate infrastrukturu kao kod, predložak CloudFormation može pokrenuti Redshift klaster. zajedno sa svojim sigurnosnim grupama, podmrežnom grupom i IAM ulogom u jednom potezu. Iz perspektive modeliranja rizika od odliva, važan dio je jednostavno da klaster može čitati iz i pisati u određeni S3 bucket.

Nakon što se klaster pokrene, prelazite na Redshift Query Editor.Odatle se povezujete s bazom podataka, provjeravate svoje vjerodajnice i počinjete kreiranjem dvije tabele: jedne za obuku (historijski označeni kupci) i jedne za zaključivanje (zapisi koje ćete kasnije koristiti za testiranje performansi modela).

Shema tabele za obuku blisko odražava strukturu CSV-a:

• Tekstualne kolone za atribute kao što su postojeći tekući račun, ušteđevina, zaposlenje od, spol, status, smještaj, posao i vrsta posla.
• Numeričke kolone za trajanje, iznos kredita, godine, postojeće kredite i izdržavane osobe.
• Logička vrijednost rizika u koloni, koja se koristi kao cilj koji treba predvidjeti.

Učitavanje podataka se obavlja putem Redshift COPY naredbe., koji povlači podatke iz S3 koristeći IAM ulogu, specificira CSV format, rukovanje zaglavljem i delimiter, te popunjava i tabele za obuku i inferenciju. Nakon što operacije COPY uspješno završe, možete provjeriti stablo objekata u editoru kako biste potvrdili tabele i broj redova.

Kreiranje i treniranje Redshift ML modela pomoću SQL-a

Kada su podaci na mjestu, sljedeći korak je treniranje Redshift ML modela korištenjem CREATE MODEL naredbe.Ovdje SageMaker Autopilot stupa na scenu kako bi testirao više kandidatskih algoritama i hiperparametara za vaš problem binarne klasifikacije.

Naredba CREATE MODEL odabira sve relevantne kolone prediktora iz risk_prediction_training, označava kolonu rizika kao TARGET i definira naziv SQL funkcije koja će se kasnije koristiti za zaključivanje o vašem skladištu podataka.

Potrebna su dva ključna podešavanja: IAM_ROLE i S3_BUCKETIAM uloga mora dozvoliti listanje i čitanje iz S3 bucket-a, a S3 bucket koriste Redshift i SageMaker za razmjenu podataka za obuku i artefakata modela. Također možete odrediti MAX_RUNTIME u sekundama kako biste ograničili koliko dugo Autopilot smije eksperimentirati.

Uobičajeno je da se problemi u vezi povjerenja pojave prvi put.Ako SageMaker ne može preuzeti IAM ulogu povezanu s vašim Redshift klasterom, naredba CREATE MODEL neće uspjeti. Zatim morate prilagoditi politiku povjerenja uloge kako biste uključili sagemaker.amazonaws.com kao pouzdanog principala usluge.

Ako postoji prethodni model s istim imenom, možete ga ukloniti korištenjem opcije DROP MODEL prije ponovnog kreiranja. Ovo vam omogućava da iterirate na svojoj strategiji modeliranja ili prilagodite postavke bez zatrpavanja okruženja zastarjelim modelima.

Praćenje obuke i validacija Redshift ML modela

Vrijeme obuke će varirati ovisno o veličini podataka i ograničenjima vremena izvođenja, ali za uzorak skupa podataka o kreditnom riziku možete očekivati ​​nešto oko sat vremena. Tokom tog vremena možete provjeriti status modela i metapodatke pokretanjem naredbe SHOW MODEL s nazivom modela.

SHOW MODEL otkriva ključne informacije kao što su status obuke (na primjer, OBUKA, SPREMAN), odabrani algoritam, objektivna metrika i rezultati validacije. Za binarnu klasifikaciju, jedna od ključnih metrika je često F1 rezultat, koji se kreće od 0 do 1 i uravnotežuje preciznost i prisjećanje.

Kada model dobije status SPREMAN, možete početi s procjenom njegovih prediktivnih performansi. korištenjem odvojenog skupa podataka za zaključivanje koji model nikada nije vidio tokom obuke. Ovo odražava scenario iz stvarnog svijeta u kojem se novi kupci boduju u hodu.

Jednostavna prva provjera je izračunavanje ukupne tačnostiTo radite pokretanjem SQL upita koji: izdvaja stvarnu oznaku rizika, poziva funkciju modela (na primjer, func_risk_prediction_model) da bi se dobila predviđena oznaka, označava tačna naspram netačnih predviđanja, a zatim agregira da bi se izračunao broj_tačnih podijeljen sa ukupnim brojem.

Pored same tačnosti, možete izračunati agregatne distribucije rizika na skupu zaključivanja.Na primjer, možete prebrojati koliko je kupaca dodijeljeno svakoj kategoriji rizika (visok, nizak, neodređen) kako biste razumjeli ponašanje modela i koliko bi slučajeva bilo označeno za daljnji pregled ili proaktivne mjere zadržavanja.

Definiranje karakteristika ponašanja kupaca za SQL modele odliva kupaca

Prelazeći sa kreditnog rizika na stvarni odliv klijenata, primjenjuju se isti principi ML-a.Potrebni su vam označeni historijski podaci i značajne funkcije koje bilježe kako se kupci ponašaju i razvijaju tokom vremena. Za e-trgovinu ili digitalne proizvode, to obično znači agregiranje metrike kupovine i interakcije po kupcu.

Tipičan SQL model odliva počinje od tabele web događaja ili transakcija, gdje svaki red predstavlja kupovinu ili trgovački događaj s poljima kao što su vremenske oznake, ID-ovi narudžbi, cijene i količine proizvoda i identifikatori korisnika.

Iz ovih sirovih događaja možete konstruirati moćne karakteristike ponašanja koji sažimaju historiju klijenta:

• ukupne_kupovineukupan broj završenih kupovina po kupcu.
• ukupni_prihod: kumulativni prihod koji je generirao taj kupac.
• prosječna vrijednost narudžbe: prosječna vrijednost korpe; ukupni_prihod podijeljen sa ukupnim_kupovinama.
• životni_život_kupca: dana između prve i posljednje kupovine.
• dana_od_zadnje_kupovine: nedavnost, mjereno kao broj dana od najnovije kupovine do referentnog datuma.
• učestalost_kupovinebroj različitih mjeseci u kojima je kupac kupovao, uzimajući u obzir redovnost.

Ove karakteristike su ključne jer odliv rijetko je slučajan.Kupci koji progresivno kupuju rjeđe, troše manje i ignoriraju vaš marketing obično šalju jasne signale da bi mogli otići. Zabilježavanje učestalosti, nedavnosti i novčane vrijednosti (klasični RFM trio) u SQL-u je obično prvi korak.

U osnovi svega ovoga je pouzdan identifikator kupca.U mnogim postavkama digitalne analitike, Experience Cloud ID (ECID) ili sličan ID pohranjen u polju kao što je identityMap.id omogućava vam da povežete događaje iz različitih sesija i uređaja u jednu historiju korisnika.

Zahtjevi za podatke i pretpostavke za web-bazirano modeliranje odliva korisnika

Da biste trenirali model odliva korisnika direktno iz web događaja, vaš skup podataka mora ispunjavati određene minimalne zahtjeve.Svaki red treba da predstavlja transakciju ili kupovinu sa dovoljno detalja da se mogu agregirati u karakteristike na nivou kupca.

Tipična obavezna polja uključuju:

• identitetMap.id: stabilan identifikator korisnika tokom više sesija.
• Lista_proizvoda.cijenaUkupnoukupni trošak artikala po transakciji.
• ProizvodListItems.količinaukupna količina artikala.
• timestamp: datum/vrijeme događaja u formatu kompatibilnom s funkcijama datuma/vremena kao što je DATEDIFF (na primjer, GGGG-MM-DD HH:MM:SS).
• commerce.order.purchaseID: vrijednost koja nije nula i koja potvrđuje završenu kupovinu.

Historijska dubina je važnaDa biste razlikovali privremenu neaktivnost od stvarnog odljeva kupaca, potrebno vam je dovoljno mjeseci podataka da biste vidjeli više ciklusa kupovine po kupcu, posebno u vertikalama s dugim intervalima kupovine (putovanja, osiguranje, B2B ugovori itd.).

Model također ovisi o jasnoj, operativnoj definiciji odliva korisnika.Uobičajeno, praktično pravilo za e-trgovinu je da se kupac smatra napuštenim ako nije kupovao u posljednjih 90 dana u odnosu na referentni datum. Ovaj prag se može prilagoditi (30, 60, 180 dana) na osnovu vašeg normalnog ciklusa kupovine.

Nakon što je skup podataka strukturiran i pretpostavke jasne, možete koristiti SQL za kreiranje oznaka (odbačene naspram neodbačenih) poređenjem vrijednosti dana od posljednje kupovine (days_since_last_purchase) sa vašim pragom, a zatim generisanjem tabele za obuku koja hrani podatke u logističkoj regresiji ili drugom algoritmu za klasifikaciju.

Izgradnja logističkog regresijskog modela odliva korisnika pomoću SQL-a

Logistička regresija je prirodno rješenje za predviđanje odliva korisnika pomoću SQL-a. jer daje vjerovatnoće između 0 i 1 i često je podržan izvorno ili putem ML ekstenzija u modernim analitičkim bazama podataka i platformama za podatke o kupcima.

Proces modeliranja se obično odvija u tri fazeInženjering karakteristika, dodjeljivanje oznaka i obuka modela.

Prvo, agregirate svoje web događaje u redove na nivou korisnika izračunavanje ukupnih_kupovina, ukupnih_prihoda, prosječne_vrijednosti_narudžbe, životnog_života_kupca, dana_od_poslednje_kupovine i učestalosti_kupovina. Ovo se može uraditi u jednoj SQL naredbi sa GROUP BY i window funkcijama ili u fazama sa međutabelama.

Drugo, kreirate oznaku odliva na osnovu pravila neaktivnostiNa primjer, churned = 1 ako je days_since_last_purchase > 90, inače churned = 0. Ovaj označeni skup podataka postaje vaš ulaz za rutinu obuke logističke regresije, koja se može pozvati putem SQL CREATE MODEL naredbe ili funkcije specifične za dobavljača.

Treće, trenirate model logističke regresije specificirajući koje kolone su karakteristike i koja kolona je ciljna oznaka (odliv korisnika). ML mehanizam uči koeficijente koji odražavaju kako svaka karakteristika doprinosi riziku od odliva korisnika, što može biti vrlo korisno za poslovne zainteresovane strane.

Izlaz modela je obično tabela ili prikaz sa jednim redom po korisniku., uključujući projektovane karakteristike i oznaku odliva. Kasnije, kada koristite model za predviđanje, dobićete dodatnu kolonu predviđanja koja predstavlja ili predviđenu oznaku (0 ili 1) ili vjerovatnoću odliva.

Evaluacija modela odliva korisnika: metrike koje su zaista važne

Treniranje modela odliva korisnika je samo pola bitke; morate rigorozno procijeniti njegove performanse. prije nego što se implementira u produkcijske kampanje. SQL-bazirani ML okviri često otkrivaju pomoćne funkcije za evaluaciju, kao što je funkcija model_evaluate, koje izračunavaju uobičajene metrike.

Za odliv korisnika, ključno je gledati dalje od sirove tačnostiTačnost jednostavno mjeri procenat tačnih predviđanja, ali u neuravnoteženim problemima (gdje većina kupaca ne odlazi) model može biti „tačan“, a istovremeno gotovo beskoristan za vaše poslovanje.

Ključne metrike za predviđanje odliva korisnika uključuju:

• AUC-ROC: mjeri sposobnost modela da razlikuje korisnike koji prelaze granicu od korisnika koji ne prelaze granicu u svim pragovima klasifikacije; vrijednosti bliže 1 ukazuju na jaču diskriminaciju.
• preciznost: udio predviđenih preusmjeravanja koji su zaista preusmjeravanja; visoka preciznost znači manje lažnih alarma i efikasnije trošenje zadržavanja.
• opoziv: udio stvarnih korisnika koji odustaju od kupovine, a koje model ispravno identificira; visoka razina prisjećanja osigurava da nećete propustiti mnogo rizičnih kupaca.
• F1 rezultat: harmonijska sredina preciznosti i prisjećanja, korisna kada vam je potrebna ravnoteža između hvatanja mnogo prevrtanja i izbjegavanja previše lažno pozitivnih rezultata.

U mnogim stvarnim projektima odliva korisnika, poslovnim dionicima je važnija preciznost i prisjećanje u pozitivnoj klasi. (predviđeni odliv kupaca) nego o globalnoj tačnosti. Uostalom, cilj je efikasno ciljati ponude za zadržavanje kupaca, a ne izgledati dobro na osnovu jedne prosječne metrike.

SQL-vođena evaluacija se obično vrši na osnovu određenog skupa testova. koji nije korišten za obuku. Ovaj skup podataka prosljeđujete funkciji model_evaluate ili ekvivalentnoj, dobijate AUC-ROC, tačnost, preciznost i prisjetljivost, a zatim iterirate na inženjeringu karakteristika, pragovima ili algoritmima na osnovu tih rezultata.

Tehnike inspirisane Pythonom za poboljšanje modela odliva korisnika

Mnoge najbolje prakse u modeliranju odliva korisnika dolaze iz šireg ML ekosistema., gdje se Python i biblioteke poput scikit-learn, imbalanced-learn i drugih široko koriste. Međutim, koncepti se mogu prenijeti na SQL-centrične tokove rada ili hibridne postavke gdje SQL rješava kreiranje funkcija, a Python napredno modeliranje.

Uobičajeni obrazac je započeti istraživanje odliva korisnika s javnim skupom podataka. kao što je CSV datoteka o odlivu klijenata banke iz Kaggle-a. Ovi skupovi podataka obično uključuju demografske podatke (dob, državu, spol), trajanje računa, broj proizvoda, kreditni rejting i da li je klijent izašao (odšao).

Uobičajeni tijek rada počinje učitavanjem i pregledom skupa podatakaprovjera broja redova i kolona, ​​sumiranje numeričkih karakteristika, istraživanje ciljne distribucije i identifikovanje očigledno nebitnih atributa poput prezimena kupaca ili neprozirnih ID-ova koji neće pomoći u predviđanju.

Vizualno istraživanje je posebno korisnoCrtanje distribucija i boxplotova kontinuiranih varijabli (poput starosti ili staža) podijeljenih prema oznaci fluktuacije može brzo otkriti koje karakteristike imaju objašnjavajuću moć. Histogrami za kategoričke varijable (spol, država) pokazuju da li određene kategorije koreliraju s većom fluktuacijom.

Tokom ove istraživačke faze također tražite probleme s kvalitetom podataka: nedostajuće vrijednosti, ekstremne vrijednosti koje odstupaju od standarda, dominantne kategorije i sumnjivi obrasci. Sve ovo može utjecati na performanse modela u budućnosti i može zahtijevati čišćenje, ograničavanje ili ponovno kodiranje.

Kategoričke varijable su još jedna ključna tačkaML algoritmi obično očekuju numerički unos, tako da tekstualne kategorije moraju biti kodirane. Jednostavni ordinalni koderi mapiraju kategorije na cijele brojeve, što može funkcionirati, ali može uvesti umjetno uređenje (npr. kodovi boja gdje 6 nije "veće od" 2 u bilo kojem smislenom smislu). Sofisticiranija kodiranja poput one-hot ili ciljnog kodiranja obično daju bolje modele, iako po cijenu više funkcija.

Od prvog modela odliva korisnika do robusne evaluacije

Nakon osnovnog čišćenja i kodiranja, može se trenirati prvi model odliva korisnika.— na primjer, klasifikator slučajne šume, koji je robustan, dobro obrađuje nelinearne odnose i zahtijeva relativno malo skaliranja karakteristika.

Zatim podatke dijelite na skupove za obuku i testne skupove (na primjer, 70% obuke, 30% testiranja) za simuliranje budućih, neviđenih kupaca. Model se prilagođava skupu za obuku i evaluira na skupu za testiranje korištenjem metrika poput tačnosti, preciznosti, prisjećanja i F1 rezultata.

U ovoj fazi je vrlo lako biti zaveden visokotačnim brojkamaU problemima neuravnoteženog odliva korisnika, model može postići visoku tačnost jednostavnim predviđanjem većinske klase (one koje nisu odliv korisnika), dok jedva hvata stvarne odlive korisnika. Zato su preciznost, podsjetnik i F1 specifični za klasu odliva korisnika mnogo relevantniji.

ROC kriva i njena površina ispod krive (AUC) pružaju nijansiraniji pogled, pokazujući kompromis između stope istinski pozitivnih i stope lažno pozitivnih rezultata na svim pragovima. Krivulja koja jasno dominira dijagonalnom baznom linijom ukazuje na koristan model, ali opet, morate to povezati s kompromisima između poslovnih troškova i koristi.

Odabir prave metrike evaluacije je poslovna odlukaAko je zadržavanje kupaca skupo, možete preferirati visoku preciznost (ciljati samo one koji vjerovatno odustaju). Ako je gubitak kupca izuzetno skup, možete prihvatiti više lažno pozitivnih rezultata i fokusirati se na prisjećanje (uhvatiti što više onih koji odustaju), čak i ako to znači kontaktirati više kupaca.

Podešavanje hiperparametara i rješavanje neuravnoteženih oznaka odliva

Nakon što je uspostavljen osnovni model odliva korisnika, sljedeći veliki dobici obično dolaze od podešavanja hiperparametara.Hiperparametri su konfiguracijske vrijednosti izvan procesa obuke (broj stabala, dubina stabla, brzina učenja itd.) koje mogu dramatično utjecati na kvalitetu modela.

Praktičan pristup je definiranje prostora pretraživanja hiperparametara (mreža ili nasumični rasponi za svaki parametar), a zatim istražiti podskup kombinacija korištenjem randomiziranog pretraživanja ili Bayesove optimizacije. Za svaku konfiguraciju kandidata, unakrsna validacija se provodi na podacima za obuku, a metrika poput F1 rezultata se koristi za njihovo poređenje.

Za odliv igrača, F1 je često bolji cilj od čiste tačnosti. jer balansira preciznost i pamćenje, što je ono što vam je obično važno kada dajete prioritet kupcima koji su u riziku.

Još jedan veliki izazov u modeliranju odliva korisnika je neravnoteža oznaka.U vašim historijskim podacima obično ima mnogo više onih koji ne generiraju promjene nego onih koji generiraju promjene. Ako se ne riješe, većina algoritama će naučiti "igrati na sigurno" i većinu vremena predviđati većinsku klasu.

Postoji nekoliko strategija za rješavanje neuravnoteženih podataka o odlivu korisnika.:

• Preuzorkovanje manjinske klase korištenjem tehnika poput SMOTE, ADASYN ili SVMSMOTE, koje sintetiziraju nove manjinske primjere interpolacijom između postojećih.
• Nedovoljno uzorkovanje većinske klase smanjiti skup podataka, a istovremeno uravnotežiti klase (ponekad u kombinaciji s prekomjernim uzorkovanjem).
• Korištenje algoritama ili omotača koji interno obrađuju težine klasa ili uravnotežene podskupove, kao što su uravnotežene slučajne šume koje treniraju svako stablo na bootstrap uzorku uravnoteženom prema klasama.

Empirijski je ključno da vaš skup testova ostane netaknut i neuravnotežen., što odražava stvarnu distribuciju proizvodnje. Možete previše uzorkovati ili na drugi način manipulisati samo skupom za obuku; u suprotnom, metrike evaluacije će biti previše optimistične i neće predstavljati stvarne performanse.

U mnogim eksperimentima, korištenje balansiranja na nivou algoritma (poput balansirane slučajne šume) bez promjene sirovih podataka za obuku je donio značajna poboljšanja u preciznosti i F1, ponekad za deset postotnih poena ili više. Za model odliva kupaca, ovo se može prevesti u znatno bolje ciljanje kupaca u riziku i veći povrat ulaganja u kampanje zadržavanja kupaca.

Imajte na umu da svaki procentualni poen poboljšanja u efektivnom zadržavanju može imati ogroman uticaj. na osnovu ponavljajućih prihoda i vrijednosti životnog vijeka kupca. Precizno otkrivanje većeg broja korisnika koji odlaze nije konačni cilj, ali vam daje prednost za implementaciju ponuda, poboljšanja usluga i personaliziranih intervencija tamo gdje su najvažnije.

Sve u svemu, kombinovanje SQL-nativnih ML mogućnosti (kao što su Amazon Redshift ML i SQL-vođena logistička regresija) sa solidnim praksama mašinskog učenja (inženjering funkcija, odgovarajuće metrike, podešavanje hiperparametara i rukovanje neravnotežom) daje vam moćan set alata za procjenu rizika od odliva direktno tamo gdje se vaši podaci nalaze. Bez obzira da li poslujete u finansijama, telekomunikacijama, e-trgovini ili SaaS-u, ove tehnike vam omogućavaju da transformišete sirove istorije interakcija u jasne rezultate rizika od odliva na koje marketinški i operativni timovi mogu sa sigurnošću da djeluju, zaoštravajući povratnu spregu između analitike i poslovnih odluka.