Hodnocení rizika odchodu zákazníků pomocí SQL a strojového učení

Home » PYTHON » Hodnocení rizika odchodu zákazníků pomocí SQL a strojového učení

Odliv zákazníků je jedním z těch tichých zabijáků zisku. ...což pomalu narušuje růst, pokud jej správně neměříte a včas nereagujete. Dobrou zprávou je, že dnes můžete vytvářet robustní modely rizika odchodu zákazníků přímo s SQL na vašem datovém skladu, kombinující klasické techniky strojového učení, spravované cloudové služby a velmi praktické obchodní metriky.

Tato příručka vás provede kompletním procesem vyhodnocení rizika odchodu uživatelů pomocí SQL. napříč různými scénáři: od použití Amazon Redshift ML a Amazon SageMaker k trénování modelů s čistým SQL, přes vytváření logistických regresních modelů churn na webových událostech, až po pokročilejší techniky, jako je ladění hyperparametrů a zpracování nevyvážených dat (churn vs. non-churn) inspirované pracovními postupy založenými na Pythonu. Cílem je podrobně ukázat, jak přejít od nezpracovaných dat k akčním skóre rizika, která mohou vaše marketingové, zákaznické a finanční týmy skutečně využít.

Proč je pro vaši firmu důležité vyhodnocovat riziko odchodu zákazníků pomocí SQL

Předvídání, kteří zákazníci pravděpodobně odejdou, je jedním z případů použití s ​​nejvyšší návratností investic. pro aplikované strojové učení a analytiku. Ztráta zákazníka je obvykle mnohem dražší než jeho udržení a malá zlepšení v udržení zákazníků mají neúměrný dopad na tržby a dlouhodobou ziskovost.

SQL hraje v této cestě ústřední roli protože většina transakčních, behaviorálních a zákaznických dat se již nachází v databázích a cloudových datových skladech; přehled systémů pro ukládání dat pomáhá pochopit, jak je využít. Pokud vaše týmy mohou vytvářet, trénovat a nasazovat modely odchodu zákazníků přímo z SQL, vyhnou se neustálému exportu dat, přepínání mezi nástroji a složitým inženýrským procesům, což drasticky zkracuje dobu dosažení hodnoty.

Moderní cloudové platformy nyní stírají hranici mezi analytikou a strojovým učením.Služby jako Amazon Redshift ML umožňují datovým analytikům a vývojářům vytvářet, trénovat a používat modely ML ze známých příkazů SQL, a přitom se stále spoléhají na plně spravované služby, jako jsou Amazon SageMaker a SageMaker Autopilot. To znamená, že můžete zvládat modely odchodu zákazníků, aniž byste se museli stát inženýrem ML na plný úvazek.

Kromě technologií musí analýza odchodu zákazníků zůstat úzce propojena s obchodní realitou.: jak definujete „aktivního“ zákazníka, které signály indikují riziko, jaká je důležitá hranice neaktivity (30, 60, 90 dní…) a kolik jste ochotni investovat do retenčních kampaní na základě předpokládaného rizika. Techniky, které budeme probírat, jsou dostatečně flexibilní, aby se přizpůsobily velmi různým odvětvím: bankovnictví, telekomunikace, SaaS, e-commerce a další.

Použití Amazon Redshift ML k vytváření modelů odchodu zákazníků a rizik pomocí SQL

Amazon Redshift ML je skvělou ukázkou toho, jak přenést ML tam, kde již vaše data existují.Umožňuje vám vytvářet, trénovat a nasazovat modely pomocí SQL příkazů v rámci Amazon Redshift, zatímco Amazon SageMaker provádí těžkou práci na pozadí.

V praxi Redshift ML zpřístupňuje váš trénovaný model jako SQL funkci. že můžete volat dotazy, dashboardy a úlohy ETL. Pro případy odchodu zákazníků a rizik to znamená, že můžete bez problémů začlenit predikce, jako je „vysoce rizikový zákazník“, „pravděpodobnost selhání úvěruschopnosti“ nebo „pravděpodobnost odchodu zákazníků“, do svých standardních reportingových a datových kanálů.

Pod kapotou se Redshift ML spoléhá na Amazon SageMaker AutopilotAutopilot automaticky prozkoumává více algoritmů a hyperparametrů, trénuje a ladí kandidátské modely a vybírá ten nejlepší na základě vašeho cíle a dat. Zachováváte si plný přehled a kontrolu, ale přeskočíte většinu nízkoúrovňových strojových učebních úprav.

Konečným výsledkem je známé vývojářské prostředíNapíšete příkaz SQL CREATE MODEL nad tabulky Redshift, ukážete na S3 bucket pro mezilehlé artefakty a po dokončení trénování získáte skalární funkci SQL, kterou lze použít pro inferenci ve velkém měřítku v celém vašem datovém skladu.

Komplexní příklad: kreditní riziko a predikce podobná fluktuaci zákazníků v Redshift

Pro ujasnění těchto konceptů si projděme konkrétní příklad založený na finančním riziku.Ačkoli je cílovou proměnnou v tomto případě úvěrové riziko (vysoké vs. nízké), pracovní postup je identický s klasickou predikcí odchodu zákazníků: označíte historická data, natrénujete binární klasifikátor a poté na vyžádání ohodnotíte nové nebo stávající zákazníky.

Ukázková datová sada pochází z repozitáře strojového učení UCI. a obsahuje 1 001 záznamů, z nichž každý popisuje bankovního zákazníka se 14 atributy souvisejícími s jeho finančním profilem a vztahem k instituci. I když je podle moderních standardů skromný, stačí k ilustraci procesu od nezpracovaných dat až po nasazený SQL model.

Klíčové atributy (rysy) v této datové sadě zahrnují jak demografické, tak i finanční chování.:

• existujícíkontrola: stav stávajícího běžného účtu.
• trváníměsíce vztahu nebo délka trvání úvěru.
• výše kreditupožadovaná výše kreditu.
• úspory: aktuální úroveň úspor.
• zaměstnání od rokudélka současného zaměstnání.
• pohlavípohlaví zákazníka.
• postavenírodinný stav.
• stářívěk zákazníka.
• bydleníbytová situace (vlastní, nájemní atd.).
• existující kredity: počet existujících kreditů.
• prácepracovní status.
• typ práce: druh práce.
• závislé osobypočet vyživovaných osob.
• riziko: cílová proměnná; označuje, zda je zákazník považován za vysoce rizikového.

Cílová proměnná, riziko, je binární, takže se jedná o klasický binární klasifikační problém. Riziko = TRUE si můžete představit jako analogii k označení odchodu zákazníků, kde chcete identifikovat zákazníky, kteří pravděpodobně nebudou platit nebo odejdou, abyste mohli jednat proaktivně.

Navzdory malé datové sadě nastavení odráží reálný pracovní postup strojového učení.: stále rozdělujete data do trénovacích a inferenčních sad, definujete vhodné schéma v Redshiftu, vytvoříte S3 bucket pro trénovací data a artefakty a nakonfigurujete roli IAM s přístupem k S3 a SageMakeru. V produkčním prostředí byste to jednoduše škálovali s více řádky a bohatšími sadami funkcí.

Příprava prostředí a dat pro Redshift

Před trénováním jakéhokoli modelu se musíte ujistit, že je k dispozici cluster Redshift a oprávnění.Cluster můžete vytvořit buď pomocí konzole AWS Management Console, nebo použít šablonu CloudFormation, která automatizuje konfiguraci sítě a zabezpečení.

Při zřizování přes konzoli obvykle vyberete typ a počet uzlů. (například dc2.large se dvěma uzly pro demonstraci), nastavte port databáze, hlavní uživatelské jméno a heslo a zásadně připojte roli IAM, která clusteru udělí přístup k úložišti S3, kde se nacházejí vaše trénovací a inferenční soubory CSV.

Pokud dáváte přednost infrastruktuře jako kódu, šablona CloudFormation může roztočit cluster Redshift. spolu s jeho bezpečnostními skupinami, skupinou podsítě a rolí IAM najednou. Z pohledu modelování rizika odchodu uživatelů je důležité jednoduše to, že cluster může číst a zapisovat do určeného úložiště S3.

Jakmile je cluster spuštěn, přejdete do editoru dotazů Redshift.Odtud se připojíte k databázi, ověříte své přihlašovací údaje a začnete vytvořením dvou tabulek: jedné pro trénování (historičtí označení zákazníci) a druhé pro inferenci (záznamy, které později použijete k testování výkonu modelu).

Schéma trénovací tabulky se velmi věrně odráží strukturu CSV.:

• Textové sloupce pro atributy jako existující účetní, úspory, zaměstnání od, pohlaví, status, bydlení, zaměstnání a typ zaměstnání.
• Číselné sloupce pro dobu trvání, výši kreditu, věk, stávající kredity a vyživované osoby.
• Logická hodnota rizika ve sloupci, použitá jako cíl, který má být predikován.

Načítání dat se provádí pomocí příkazu Redshift COPY., který stahuje data z S3 pomocí role IAM, specifikuje formát CSV, zpracování záhlaví a oddělovač a naplní trénovací i inferenční tabulky. Po úspěšném provedení operací COPY můžete v editoru zkontrolovat strom objektů a ověřit tabulky a počet řádků.

Vytvoření a trénování modelu Redshift ML pomocí SQL

S daty na místě je dalším krokem trénování modelu Redshift ML pomocí příkazu CREATE MODEL.A právě zde se do hry zapojí SageMaker Autopilot, který otestuje více kandidátských algoritmů a hyperparametrů pro váš problém binární klasifikace.

Příkaz CREATE MODEL vybere všechny relevantní sloupce prediktorů. z risk_prediction_training označuje sloupec rizika jako CÍL a definuje název funkce SQL, která bude později použita pro inferenci nad vaším datovým skladem.

Jsou vyžadována dvě klíčová nastavení: IAM_ROLE a S3_BUCKETRole IAM musí umožňovat výpis a čtení z úložiště S3 a úložiště S3 používají Redshift a SageMaker k výměně trénovacích dat a artefaktů modelu. Můžete také zadat MAX_RUNTIME v sekundách, abyste omezili dobu, po kterou může Autopilot experimentovat.

Je běžné, že se s problémy v důvěrném vztahu setkáte hned napoprvé.Pokud SageMaker nemůže převzít roli IAM přidruženou k vašemu clusteru Redshift, příkaz CREATE MODEL selže. Poté je třeba upravit zásady důvěryhodnosti role tak, aby zahrnovaly sagemaker.amazonaws.com jako důvěryhodný objekt služby.

Pokud existuje předchozí model se stejným názvem, můžete ho odstranit. použití příkazu DROP MODEL před jeho opětovným vytvořením. To vám umožní iterovat ve strategii modelování nebo upravovat nastavení, aniž byste zahlcovali své prostředí zastaralými modely.

Monitorování školení a validace modelu Redshift ML

Doba trénování se bude lišit v závislosti na velikosti dat a limitech běhové doby., ale u vzorové sady dat o úvěrovém riziku můžete očekávat zhruba hodinu. Během této doby můžete zkontrolovat stav modelu a metadata spuštěním příkazu SHOW MODEL s názvem modelu.

SHOW MODEL odhaluje klíčové informace jako je stav trénování (například TRÉNINK, PŘIPRAVENO), vybraný algoritmus, objektivní metrika a skóre validace. Pro binární klasifikaci je jednou z klíčových metrik často skóre F1, které se pohybuje od 0 do 1 a vyvažuje přesnost a úplnost.

Jakmile je model ve stavu PŘIPRAVENO, můžete začít vyhodnocovat jeho prediktivní výkon. s použitím samostatné inferenční datové sady, kterou model během trénování nikdy neviděl. To odráží reálný scénář, kde jsou noví zákazníci hodnoceni za chodu.

Jednoduchá první kontrola spočívá ve výpočtu celkové přesnostiToho dosáhnete spuštěním dotazu SQL, který: extrahuje skutečný popisek rizika, zavolá modelovou funkci (například func_risk_prediction_model) pro získání predikovaného popisku, označí správné a nesprávné predikce a poté provede agregaci pro výpočet num_correct děleno celkovým součtem.

Kromě hrubé přesnosti můžete vypočítat agregované rozdělení rizik na inferenční množiněMůžete například spočítat, kolik zákazníků je přiřazeno do každé kategorie rizika (vysoké, nízké, neurčité), abyste pochopili chování modelu a kolik případů by bylo označeno k další kontrole nebo proaktivním opatřením v oblasti uchovávání zákazníků.

Definování funkcí chování zákazníků pro modely churnů v SQL

Při přechodu od úvěrového rizika k skutečnému odchodu zákazníků platí stejné principy praní peněz.Potřebujete popisovaná historická data a smysluplné funkce, které zachycují, jak se zákazníci chovají a vyvíjejí v čase. U e-commerce nebo digitálních produktů to obvykle znamená agregaci metrik nákupů a interakcí na zákazníka.

Typický model SQL churn začíná tabulkou webových událostí nebo transakcí., kde každý řádek představuje nákupní nebo obchodní událost s poli, jako jsou časová razítka, ID objednávek, ceny a množství produktů a identifikátory uživatelů.

Z těchto nezpracovaných událostí můžete vytvořit silné behaviorální rysy které shrnují historii zákazníka:

• celkový počet nákupůcelkový počet dokončených nákupů na zákazníka.
• celkový_příjemkumulativní příjmy generované daným zákazníkem.
• průměrná hodnota_objednávkyprůměrná hodnota košíku; celkové_tržby_dělené_celkovým_početem_nákupů.
• zákaznická_životnostdny mezi prvním a posledním nákupem.
• dní_od_posledního_nákupuaktuálnost, měřená jako počet dní od posledního nákupu do referenčního data.
• frekvence_nákupůpočet různých měsíců, ve kterých zákazník nakupoval, s ohledem na pravidelnost.

Tyto vlastnosti jsou klíčové, protože odliv je zřídka náhodný.Zákazníci, kteří postupně nakupují méně často, utrácejí méně a ignorují váš marketing, obvykle vysílají jasné signály, že se chystají odejít. Zachycení frekvence, aktuálnosti a peněžní hodnoty (klasické trio RFM) v SQL je obvykle prvním krokem.

Základem toho všeho je spolehlivý identifikátor zákazníkaV mnoha nastaveních digitální analytiky umožňuje ID Experience Cloud (ECID) nebo podobné ID uložené v poli, jako je identityMap.id, propojit události napříč relacemi a zařízeními do jediné historie zákazníka.

Požadavky na data a předpoklady pro webové modelování odchodu zákazníků

Pro trénování modelu odchodu zákazníků přímo z webových událostí musí vaše datová sada splňovat určité minimální požadavky.Každý řádek by měl představovat transakci nebo nákupní událost s dostatečnými podrobnostmi, aby je bylo možné agregovat do charakteristik na úrovni zákazníka.

Mezi typická povinná pole patří:

• identityMap.id: stabilní identifikátor zákazníka napříč relacemi.
• productListItems.priceTotalcelková cena položek na transakci.
• productListItems.quantitycelkové množství položek.
• timestamp: datum a čas události ve formátu kompatibilním s funkcemi data/času, jako je DATEDIFF (například RRRR-MM-DD HH:MM:SS).
• commerce.order.purchaseID: nenulová hodnota, která potvrzuje dokončení nákupu.

Historická hloubka je důležitáAbyste rozlišili mezi dočasnou neaktivitou a skutečným odchodem zákazníků, potřebujete dostatek měsíců dat, abyste viděli více nákupních cyklů na zákazníka, zejména ve vertikálech s dlouhými nákupními intervaly (cestování, pojištění, B2B smlouvy atd.).

Model také závisí na jasné, operativní definici odchodu zákazníků.Běžným praktickým pravidlem pro elektronický obchod je považovat zákazníka za opuštěného, ​​pokud v posledních 90 dnech vzhledem k referenčnímu datu neprovedl žádný nákup. Tuto hranici lze upravit (30, 60, 180 dní) na základě vašeho běžného nákupního cyklu.

Jakmile je datová sada strukturovaná a předpoklady jasné, můžete k vytvoření popisků použít SQL. (odmrštěné vs. neodmrštěné) porovnáním hodnoty days_since_last_purchase s vaší prahovou hodnotou a následným vygenerováním trénovací tabulky, která slouží jako zdroj pro logistickou regresi nebo jiný klasifikační algoritmus.

Vytvoření logistického regresního modelu fluktuace pomocí SQL

Logistická regrese je přirozenou volbou pro predikci odchodu zákazníků pomocí SQL protože vydává pravděpodobnosti mezi 0 a 1 a je často podporován nativně nebo prostřednictvím rozšíření strojového učení v moderních analytických databázích a platformách zákaznických dat.

Proces modelování obvykle probíhá ve třech fázíchinženýrství prvků, přiřazování popisků a trénování modelů.

Nejprve agregujete webové události do řádků na úrovni zákazníků. výpočet celkových_nákupů (total_purchases), celkových_tržeb (total_revenue), průměrné_hodnoty_objednávek (avg_order_value), životnosti_zákazníků (customer_lifetime), dnů_od_posledního_nákupu (days_since_last_purchase) a frekvence_nákupů (purchase_frequency). To lze provést jedním příkazem SQL pomocí funkce GROUP BY a okenních funkcí nebo postupně s mezilehlými tabulkami.

Za druhé, na základě pravidla nečinnosti vytvoříte štítek pro odchod zákazníků.Například churned = 1, pokud days_since_last_purchase > 90, jinak churned = 0. Tato označená datová sada se stane vaším vstupem pro trénovací rutinu logistické regrese, kterou lze vyvolat pomocí příkazu SQL CREATE MODEL nebo funkce specifické pro dodavatele.

Za třetí, trénujete logistický regresní model a určujete, které sloupce jsou prvky. a který sloupec je cílovým popiskem (churned). ML engine se učí koeficienty, které odrážejí, jak každá funkce přispívá k riziku churn, což může být pro obchodní zainteresované strany velmi užitečné.

Výstupem modelu je obvykle tabulka nebo pohled s jedním řádkem na zákazníka., včetně navržených funkcí a pravděpodobnosti odchodu. Později, když použijete model pro predikci, získáte další sloupec predikce, který bude představovat buď predikovaný popisek (0 nebo 1), nebo pravděpodobnost odchodu.

Hodnocení modelů odchodu zákazníků: metriky, na kterých skutečně záleží

Trénování modelu fluktuace je jen polovina úspěchu; musíte důkladně vyhodnotit jeho výkon. před nasazením v produkčních kampaních. Rámce strojového učení založené na SQL často zpřístupňují pomocné nástroje pro vyhodnocování, jako je například funkce model_evaluate, které počítají běžné metriky.

Pro odliv zákazníků je klíčové dívat se nad rámec hrubé přesnostiPřesnost jednoduše měří procento správných předpovědí, ale v nevyvážených problémech (kde většina zákazníků neodchází) může být model „přesný“, ale pro vaši firmu téměř nepoužitelný.

Mezi klíčové metriky pro predikci odchodu zákazníků patří:

• AUC-ROC: měří schopnost modelu rozlišit uživatele, kteří odmítli odeslat zprávu, od těch, kteří ji odmítli, napříč všemi klasifikačními prahy; hodnoty bližší 1 naznačují silnější rozlišování.
• PřesnostPodíl předpokládaných odchodů, které skutečně odchody udělají; vysoká přesnost znamená méně falešných poplachů a efektivnější vynakládání prostředků na udržení zákazníků.
• OdvoláníPodíl skutečných zákazníků, kteří odešli z prodeje a které model správně identifikuje; vysoká míra spolehlivosti zajišťuje, že nepřehlédnete mnoho rizikových zákazníků.
• skóre F1: harmonický průměr přesnosti a úplnosti, užitečný, když potřebujete rovnováhu mezi zachycením mnoha churnerů a vyhnutím se příliš velkému počtu falešně pozitivních výsledků.

V mnoha reálných projektech zaměřených na odchod zákazníků se obchodní partneři více zajímají o přesnost a spolehlivost pozitivní třídy. (zákazníci, u kterých se předpokládá odchod zákazníků) než o globální přesnost. Koneckonců, cílem je efektivně zacílit nabídky na udržení zákazníků, ne vypadat dobře na základě jediné průměrné metriky.

Vyhodnocování řízené SQL se obvykle provádí na základě testovací sady. který nebyl použit pro trénování. Tuto datovou sadu předáte funkci model_evaluate nebo ekvivalentní funkci, získáte AUC-ROC, přesnost, preciznost a úplnost a poté na základě těchto výsledků iterujete v inženýrství prvků, prahových hodnotách nebo algoritmech.

Techniky inspirované Pythonem pro vylepšení modelů odchodu uživatelů

Mnoho osvědčených postupů v modelování odchodu zákazníků pochází z širšího ekosystému strojového učení (ML)., kde se široce používá Python a knihovny jako scikit-learn, balanced-learn a další. Tyto koncepty jsou však přenositelné do pracovních postupů zaměřených na SQL nebo hybridních nastavení, kde SQL řeší vytváření funkcí a Python pokročilé modelování.

Běžným vzorem je začít zkoumat odchody uživatelů s veřejnou datovou sadou. například CSV soubor s údaji o odchodu zákazníka z banky z Kaggle. Tyto datové sady obvykle zahrnují demografické údaje (věk, zemi, pohlaví), délku trvání účtu, počet produktů, kreditní skóre a to, zda zákazník odešel (zrušil účet).

Obvyklý pracovní postup začíná načtením a kontrolou datové sady.: kontrola počtu řádků a sloupců, shrnutí numerických rysů, prozkoumání cílového rozdělení a identifikace zjevně irelevantních atributů, jako jsou příjmení zákazníků nebo neprůhledná ID, která nepomohou s predikcí.

Vizuální průzkum je obzvláště užitečnýVykreslení rozdělení a krabicových grafů spojitých proměnných (jako je věk nebo délka zaměstnání) rozdělených podle označení fluktuace může rychle odhalit, které charakteristiky mají vysvětlující sílu. Histogramy pro kategoriální proměnné (pohlaví, země) ukazují, zda určité kategorie korelují s vyšší fluktuací.

Během této průzkumné fáze také hledáte problémy s kvalitou dat.chybějící hodnoty, extrémní odlehlé hodnoty, dominantní kategorie a podezřelé vzorce. Všechny tyto faktory mohou ovlivnit výkon následného modelu a mohou vyžadovat čištění, omezení nebo překódování.

Kategorické proměnné jsou dalším klíčovým bodemAlgoritmy ML obvykle očekávají číselný vstup, takže textové kategorie musí být kódovány. Jednoduché ordinální kodéry mapují kategorie na celá čísla, což může fungovat, ale může zavádět umělé řazení (např. barevné kódy, kde 6 není „větší než“ 2 v žádném smysluplném smyslu). Sofistikovanější kódování, jako je one-hot nebo cílové kódování, obvykle vedou k lepším modelům, i když za cenu většího počtu funkcí.

Od prvního modelu odlivu zákazníků k robustnímu vyhodnocení

Po základním čištění a kódování lze natrénovat první model fluktuace.—například klasifikátor náhodných lesů, který je robustní, dobře zpracovává nelineární vztahy a vyžaduje relativně malé škálování rysů.

Poté rozdělíte data do trénovacích a testovacích sad (například 70 % trénování, 30 % testování) pro simulaci budoucích, neviditelných zákazníků. Model je přizpůsoben trénovací sadě a vyhodnocen na testovací sadě pomocí metrik, jako je přesnost, preciznost, úplnost a F1 skóre.

V této fázi je velmi snadné nechat se zmást vysoce přesnými číslyV problémech s nevyváženým odchodem zákazníků může model dosáhnout vysoké přesnosti jednoduše tím, že vždy předpovídá většinovou třídu (neodchod zákazníků), zatímco sotva zachytí skutečné odchody zákazníků. Proto jsou přesnost, úplnost a F1 specifické pro danou třídu odchodu zákazníků mnohem relevantnější.

ROC křivka a její plocha pod křivkou (AUC) poskytují podrobnější pohled a ukazují kompromis mezi mírou skutečně pozitivních a falešně pozitivních výsledků napříč všemi prahovými hodnotami. Křivka, která jasně dominuje diagonální základní linii, naznačuje užitečný model, ale opět je nutné to vztáhnout k kompromisům mezi obchodními náklady a přínosy.

Výběr správné hodnotící metriky je obchodním rozhodnutímPokud je oslovování zákazníků zaměřené na udržení zákazníků nákladné, můžete upřednostnit vysokou přesnost (zaměřit se pouze na pravděpodobné odchody zákazníků). Pokud je ztráta zákazníka extrémně nákladná, můžete akceptovat více falešně pozitivních výsledků a zaměřit se na jejich zapamatovatelnost (zachytit co nejvíce odchodů zákazníků), i kdyby to znamenalo kontaktovat více zákazníků.

Ladění hyperparametrů a řešení nevyvážených popisků odchodu

Jakmile je zaveden základní model odlivu zákazníků, další velké zisky obvykle plynou z ladění hyperparametrů.Hyperparametry jsou konfigurační hodnoty externí vůči trénovacímu procesu (počet stromů, hloubka stromu, rychlost učení atd.), které mohou dramaticky ovlivnit kvalitu modelu.

Praktickým přístupem je definovat vyhledávací prostor hyperparametrů (mřížka nebo náhodné rozsahy pro každý parametr) a poté prozkoumat podmnožinu kombinací pomocí randomizovaného vyhledávání nebo Bayesovské optimalizace. Pro každou kandidátskou konfiguraci se provede křížová validace trénovacích dat a k jejich porovnání se použije metrika, jako je skóre F1.

Pro odliv hráčů je F1 často lepším cílem než čistá přesnost. protože vyvažuje přesnost a zapamatovatelnost, což je to, na čem vám obvykle záleží při upřednostňování rizikových zákazníků.

Další velkou výzvou v modelování fluktuace je nerovnováha štítků.V historických datech je obvykle mnohem více ne-churnerů než těch, kteří churnery předávají. Pokud se jimi nezabýváme, většina algoritmů se naučí „hrát na jistotu“ a většinou předpovídat většinovou třídu.

Existuje několik strategií pro zvládání nevyvážených dat o odchodu zákazníků.:

• Nadměrné vzorkování menšinové třídy s využitím technik jako SMOTE, ADASYN nebo SVMSMOTE, které syntetizují nové příklady menšin interpolací mezi existujícími.
• Nedostatečné vzorkování většinové třídy zmenšit datovou sadu a zároveň vyvážit třídy (někdy v kombinaci s převzorkováním).
• Používání algoritmů nebo obalů, které interně zpracovávají váhy tříd nebo vyvážené podmnožiny, například vyvážené náhodné lesy, které trénují každý strom na bootstrapovém vzorku vyváženém podle tříd.

Empiricky je zásadní, aby vaše testovací sada zůstala nedotčená a nevyvážená., což odráží skutečné rozdělení produkce. Můžete převzorkovat nebo jinak manipulovat pouze s trénovací sadou; jinak budou metriky hodnocení příliš optimistické a nebudou reprezentativní pro reálný výkon.

V mnoha experimentech s využitím vyvažování na úrovni algoritmů (jako vyvážený náhodný les) bez změny nezpracovaných trénovacích dat přineslo značné zlepšení v přesnosti a F1, někdy o deset procentních bodů nebo i více. U modelu odchodu zákazníků se to může promítnout do výrazně lepšího cílení na rizikové zákazníky a vyšší návratnosti investic do retenčních kampaní.

Nezapomeňte, že každé procento zlepšení v efektivní retenci může mít obrovský dopad. na opakujících se příjmech a celoživotní hodnotě zákazníka. Přesná detekce většího počtu odchodů zákazníků není konečným cílem, ale dává vám to možnost zavést nabídky, vylepšení služeb a personalizované intervence tam, kde na nich nejvíce záleží.

Celkově vzato, kombinace nativních funkcí strojového učení (jako je Amazon Redshift ML a SQL-řízená logistická regrese) se solidními postupy strojového učení (inženýrství funkcí, správné metriky, ladění hyperparametrů a zpracování nerovnováhy) vám poskytuje výkonnou sadu nástrojů pro vyhodnocování rizika odchodu zákazníků přímo tam, kde se vaše data nacházejí. Ať už působíte ve financích, telekomunikacích, elektronickém obchodování nebo SaaS, tyto techniky vám umožňují transformovat nezpracované historie interakcí do jasných skóre rizika odchodu zákazníků, na která mohou marketingové a provozní týmy s jistotou reagovat, a tím zpřísnit zpětnou vazbu mezi analytikou a obchodními rozhodnutími.