Оцінка ризику відтоку клієнтів за допомогою SQL та машинного навчання

Home » Python » Оцінка ризику відтоку клієнтів за допомогою SQL та машинного навчання

Відтік клієнтів – один із тих тихих убивць прибутку що повільно руйнує зростання, якщо ви не вимірюєте його належним чином і не реагуєте вчасно. Гарна новина полягає в тому, що сьогодні ви можете створювати надійні моделі ризику відтоку безпосередньо за допомогою SQL поверх вашого сховища даних, поєднуючи класичні методи машинного навчання, керовані хмарні сервіси та дуже практичні бізнес-метрики.

Цей посібник проведе вас через комплексну оцінку ризику відтоку за допомогою SQL у різних сценаріях: від використання Amazon Redshift ML та Amazon SageMaker для навчання моделей на чистому SQL до створення логістичних регресійних моделей відтоку клієнтів для веб-подій, аж до більш просунутих методів, таких як налаштування гіперпараметрів та обробка незбалансованих даних (відтік проти відтоку), натхненних робочими процесами на основі Python. Мета полягає в тому, щоб детально показати вам, як перейти від необроблених даних до практичних оцінок ризику, які ваші команди з маркетингу, успіху клієнтів та фінансів можуть реально використовувати.

Чому оцінка ризику відтоку за допомогою SQL важлива для вашого бізнесу

Прогнозування того, які клієнти, ймовірно, підуть, є одним із випадків використання з найвищою рентабельністю інвестицій. для прикладного машинного навчання та аналітики. Втрата клієнта зазвичай набагато дорожча, ніж його утримання, а невеликі покращення в утриманні мають непропорційний вплив на дохід та довгострокову прибутковість.

SQL відіграє центральну роль у цьому процесі оскільки більшість транзакційних, поведінкових та клієнтських даних вже зберігаються в базах даних та хмарних сховищах даних; огляд систем зберігання даних допомагає зрозуміти, як їх використовувати. Якщо ваші команди можуть створювати, навчати та розгортати моделі відтоку безпосередньо з SQL, вони уникають постійного експорту даних, перемикання інструментів та складних інженерних конвеєрів, що значно скорочує час отримання вигоди.

Сучасні хмарні платформи тепер розмивають межу між аналітикою та машинним навчанням.Такі сервіси, як Amazon Redshift ML, дозволяють аналітикам даних та розробникам створювати, навчати та використовувати моделі машинного навчання на основі знайомих SQL-запитів, водночас покладаючись на повністю керовані сервіси, такі як Amazon SageMaker та SageMaker Autopilot. Це означає, що ви можете створювати моделі відтоку користувачів, не стаючи повноцінним інженером машинного навчання.

Окрім технологій, аналіз відтоку клієнтів має залишатися тісно пов'язаним з бізнес-реаліями.: як ви визначаєте «активного» клієнта, які сигнали вказують на ризик, який поріг неактивності має значення (30, 60, 90 днів…), і скільки ви готові інвестувати в кампанії утримання клієнтів на основі прогнозованого ризику. Методи, які ми розглянемо, достатньо гнучкі, щоб адаптуватися до дуже різних галузей: банківської справи, телекомунікацій, SaaS, електронної комерції тощо.

Використання Amazon Redshift ML для створення моделей відтоку та ризиків за допомогою SQL

Amazon Redshift ML – чудова ілюстрація того, як перенести ML туди, де вже зберігаються ваші дані.Це дозволяє створювати, навчати та розгортати моделі за допомогою команд SQL всередині Amazon Redshift, тоді як Amazon SageMaker виконує важку роботу у фоновому режимі.

На практиці, Redshift ML надає доступ до вашої навченої моделі як функції SQL. що ви можете викликати запити, панелі інструментів та завдання ETL. Для випадків використання відтоку та ризику це означає, що ви можете безперешкодно вбудовувати такі прогнози, як «клієнт високого ризику», «ймовірність дефолту за кредитом» або «ймовірність відтоку», у свої стандартні звіти та конвеєри даних.

Під капотом Redshift ML спирається на Amazon SageMaker Autopilot.Автопілот автоматично досліджує кілька алгоритмів і гіперпараметрів, навчає та налаштовує моделі-кандидати, а також вибирає найкращу з них, враховуючи вашу мету та дані. Ви зберігаєте повну видимість і контроль, але пропускаєте більшість низькорівневих процедур машинного навчання.

Кінцевий результат — звичний для розробників досвід: ви пишете оператор SQL CREATE MODEL поверх ваших таблиць Redshift, вказуєте на корзину S3 для проміжних артефактів, і після завершення навчання ви отримуєте скалярну функцію SQL, яку можна використовувати для виведення в масштабі по всьому вашому сховищу.

Приклад від початку до кінця: кредитний ризик та прогнозування, подібне до відтоку клієнтів, у Redshift

Щоб закріпити концепції, давайте розглянемо конкретний приклад, заснований на фінансовому ризикуХоча цільовою змінною в цьому випадку є кредитний ризик (високий проти низького), робочий процес ідентичний класичному прогнозуванню відтоку клієнтів: ви маркували історичні дані, навчаєте бінарний класифікатор, а потім оцінюєте нових або існуючих клієнтів на вимогу.

Зразок набору даних взято з репозиторію машинного навчання UCI і містить 1,001 запис, кожен з яких описує клієнта банку з 14 атрибутами, пов'язаними з його фінансовим профілем та взаємовідносинами з установою. Хоча за сучасними стандартами розмір скромний, його достатньо, щоб проілюструвати процес від необроблених даних до розгорнутої SQL-моделі.

Ключові атрибути (ознаки) в цьому наборі даних охоплюють як демографічну, так і фінансову поведінку:

• існуюча перевірка: стан існуючого поточного рахунку.
• тривалістьмісяці стосунків або тривалість кредиту.
• сума кредиту: запитувана сума кредиту.
• заощадженняпоточний рівень заощаджень.
• зайнятість зтривалість поточного трудового стажу.
• сексстать клієнта.
• статуссімейний стан.
• віквік клієнта.
• житложитлова ситуація (власне, орендоване тощо).
• існуючі кредитикількість існуючих кредитів.
• роботастатус зайнятості.
• тип роботи: вид роботи.
• утриманцікількість утриманців.
• ризик: цільова змінна; вказує, чи вважається клієнт високоризикованим.

Цільова змінна, ризик, є бінарною, отже, це класична задача бінарної класифікації. Ви можете розглядати ризик = TRUE як аналог мітки відтоку, де ви хочете ідентифікувати клієнтів, які, ймовірно, не здійснять зобов'язання або підуть, щоб ви могли діяти проактивно.

Незважаючи на невеликий набір даних, налаштування відображає реальний робочий процес машинного навчання.: ви все ще розділяєте дані на набори для навчання та висновків, визначаєте відповідну схему в Redshift, створюєте корзину S3 для навчальних даних та артефактів і налаштовуєте роль IAM з доступом до S3 та SageMaker. У продакшені ви просто масштабуєте це за допомогою більшої кількості рядків та багатших наборів функцій.

Підготовка середовища та даних Redshift

Перед навчанням будь-якої моделі потрібно переконатися, що кластер Redshift та дозволи налаштовані.Ви можете створити кластер через консоль керування AWS або скористатися шаблоном CloudFormation, який автоматизує налаштування мережі та безпеки.

Під час налаштування через консоль ви зазвичай вибираєте тип і кількість вузлів (наприклад, dc2.large з двома вузлами для демонстрації), встановіть порт бази даних, головне ім'я користувача та пароль і, що найважливіше, приєднайте роль IAM, яка надає кластеру доступ до корзини S3, де знаходяться ваші навчальні та логічні CSV-файли.

Якщо ви надаєте перевагу інфраструктурі як коду, шаблон CloudFormation може розкрутити кластер Redshift. разом із групами безпеки, групою підмережі та роллю IAM одночасно. З точки зору моделювання ризику відтоку, важливо просто те, що кластер може читати та записувати дані з призначеного корзини S3.

Після запуску кластера ви переходите до редактора запитів Redshift.Звідти ви підключаєтеся до бази даних, перевіряєте свої облікові дані та починаєте зі створення двох таблиць: однієї для навчання (історичні позначені клієнти) та однієї для логічного висновку (записи, які ви використовуватимете пізніше для перевірки продуктивності моделі).

Схема навчальної таблиці точно відображає структуру CSV:

• Текстові стовпці для таких атрибутів, як наявний розрахунковий рахунок, заощадження, зайнятість з моменту отримання, стать, статус, житло, робота та тип роботи.
• Числові стовпці для тривалості, суми кредиту, віку, наявних кредитів та утриманців.
• Логічне значення ризику в стовпці, що використовується як ціль для прогнозування.

Завантаження даних здійснюється за допомогою команди Redshift COPY., який отримує дані з S3 за допомогою ролі IAM, визначає формат CSV, обробку заголовків та роздільник, а також заповнює як навчальну таблицю, так і таблицю виводу. Після успішного виконання операцій COPY ви можете перевірити дерево об'єктів у редакторі, щоб підтвердити таблиці та кількість рядків.

Створення та навчання моделі машинного навчання Redshift за допомогою SQL

Після отримання даних наступним кроком є ​​навчання моделі машинного навчання Redshift за допомогою оператора CREATE MODEL.Саме тут SageMaker Autopilot вступає в дію, щоб протестувати кілька алгоритмів-кандидатів та гіперпараметрів для вашої задачі бінарної класифікації.

Команда CREATE MODEL вибирає всі відповідні стовпці-предиктори з risk_prediction_training, позначає стовпець ризику як ЦІЛЬ та визначає ім'я функції SQL, яка пізніше буде використана для виведення даних у вашому сховищі даних.

Потрібні два ключові налаштування: IAM_ROLE та S3_BUCKETРоль IAM повинна дозволяти перегляд та читання з корзини S3, а корзина S3 використовується Redshift та SageMaker для обміну навчальними даними та артефактами моделі. Ви також можете вказати MAX_RUNTIME у секундах, щоб обмежити тривалість експериментів Autopilot.

Часто трапляється, що проблеми з довірливими стосунками виникають вперше.Якщо SageMaker не може взяти на себе роль IAM, пов’язану з вашим кластером Redshift, команда CREATE MODEL не вдасться. Тоді вам потрібно налаштувати політику довіри ролі, щоб включити sagemaker.amazonaws.com як довірений принципал служби.

Якщо існує попередня модель з такою ж назвою, ви можете її видалити використання DROP MODEL перед її повторним створенням. Це дозволяє вам ітерувати стратегію моделювання або налаштовувати параметри, не захаращуючи середовище застарілими моделями.

Моніторинг навчання та валідація моделі машинного навчання Redshift

Час навчання залежатиме від розміру даних та обмежень часу виконання., але для зразка набору даних про кредитний ризик можна очікувати приблизно години. Протягом цього часу ви можете перевірити стан моделі та метадані, виконавши команду SHOW MODEL з назвою моделі.

SHOW MODEL розкриває ключову інформацію такі як статус навчання (наприклад, НАВЧАННЯ, ГОТОВО), вибраний алгоритм, об'єктивна метрика та бали валідації. Для бінарної класифікації однією з ключових метрик часто є бал F1, який коливається від 0 до 1 та врівноважує точність та повноту.

Щойно модель перейде до статусу ГОТОВО, ви можете почати оцінювати її прогностичну ефективність. використовуючи окремий набір даних для виведення, який модель ніколи не бачила під час навчання. Це відображає реальний сценарій, де нові клієнти оцінюються на льоту.

Проста перша перевірка полягає в обчисленні загальної точностіВи робите це, запускаючи SQL-запит, який: витягує фактичну мітку ризику, викликає функцію моделі (наприклад, func_risk_prediction_model) для отримання передбачуваної мітки, позначає правильні та неправильні прогнози, а потім виконує агрегацію для обчислення num_correct, поділеного на total.

Окрім грубої точності, ви можете обчислити сукупний розподіл ризиків на наборі висновківНаприклад, ви можете підрахувати, скільки клієнтів призначено до кожної категорії ризику (високий, низький, невизначений), щоб зрозуміти поведінку моделі та скільки випадків буде позначено для подальшого перегляду або проактивних заходів щодо утримання.

Визначення особливостей поведінки клієнтів для моделей відтоку клієнтів SQL

Переходячи від кредитного ризику до фактичного відтоку, застосовуються ті ж принципи MLВам потрібні марковані історичні дані та змістовні функції, які фіксують поведінку клієнтів та їхню еволюцію з часом. Для електронної комерції або цифрових продуктів це зазвичай означає агрегування показників покупок та взаємодії для кожного клієнта.

Типова модель відтоку SQL починається з таблиці веб-подій або транзакцій., де кожен рядок представляє подію покупки або комерції з такими полями, як позначки часу, ідентифікатори замовлень, ціни та кількість товарів, а також ідентифікатори користувачів.

З цих первинних подій можна створити потужні поведінкові особливості що підсумовують історію клієнта:

• загальна кількість_покупокзагальна кількість завершених покупок на одного клієнта.
• загальний_дохід: сукупний дохід, отриманий цим клієнтом.
• середнє значення_замовленнясередня вартість кошика; загальний_дохід, поділений на загальну_кількість_покупок.
• customer_lifetimeднів між першою та останньою покупкою.
• днів_з_останньої_покупкиДата свіжості, що вимірюється кількістю днів від останньої покупки до контрольної дати.
• частота_покупоккількість окремих місяців, протягом яких клієнт здійснював покупку, з урахуванням регулярності.

Ці особливості є критично важливими, оскільки відтік клієнтів рідко буває випадковим.Клієнти, які поступово купують рідше, витрачають менше та ігнорують ваш маркетинг, зазвичай посилають чіткі сигнали про те, що вони, можливо, ось-ось підуть. Визначення частоти, давності та грошової цінності (класичне тріо RFM) у SQL зазвичай є першим кроком.

В основі всього цього лежить надійний ідентифікатор клієнта.У багатьох системах цифрової аналітики ідентифікатор Experience Cloud (ECID) або подібний ідентифікатор, що зберігається в полі, такому як identityMap.id, дозволяє об’єднувати події з різних сеансів та пристроїв в одну історію клієнта.

Вимоги до даних та припущення для веб-моделювання відтоку клієнтів

Щоб навчити модель відтоку безпосередньо з веб-подій, ваш набір даних має відповідати певним мінімальним вимогам.Кожен рядок має представляти транзакцію або подію покупки з достатньою кількістю деталей для агрегації в характеристики рівня клієнта.

Типові обов'язкові поля включають:

• ідентифікаційна мапа.id: стабільний ідентифікатор клієнта, що використовується протягом кількох сесій.
• productListItems.priceTotal: загальна вартість товарів на одну транзакцію.
• productListItems.quantity: загальна кількість товарів.
• відмітка часу: дата й час події у форматі, сумісному з функціями дати/часу, такими як DATEDIFF (наприклад, РРРР-ММ-ДД ГГ:ММ:СС).
• commerce.order.purchaseID: ненульове значення, яке підтверджує завершення покупки.

Історична глибина важливаЩоб розрізнити тимчасову бездіяльність та реальний відтік клієнтів, вам потрібно достатньо місяців даних, щоб побачити кілька циклів покупок для кожного клієнта, особливо у вертикалях з тривалими інтервалами покупок (подорожі, страхування, контракти B2B тощо).

Модель також залежить від чіткого, операційного визначення відтоку клієнтів.Загальноприйнятим практичним правилом для електронної комерції є те, що клієнт вважається таким, що покинув сервіс, якщо він не здійснював покупок протягом останніх 90 днів відносно контрольної дати. Цей поріг можна адаптувати (30, 60, 180 днів) залежно від вашого звичайного циклу покупок.

Після того, як набір даних структуровано, а припущення зрозумілі, можна використовувати SQL для створення міток. (відхилено чи не відхилено) шляхом порівняння значення days_since_last_purchase з вашим порогом, а потім створення навчальної таблиці, яка буде використовуватись для логістичної регресії або іншого алгоритму класифікації.

Побудова логістичної регресійної моделі відтоку за допомогою SQL

Логістична регресія є природним варіантом для прогнозування відтоку клієнтів за допомогою SQL оскільки він видає ймовірності між 0 та 1 і часто підтримується нативно або через розширення машинного навчання в сучасних аналітичних базах даних та платформах даних клієнтів.

Процес моделювання зазвичай відбувається у три фази: інженерія ознак, призначення міток та навчання моделі.

Спочатку ви об’єднуєте свої веб-події в рядки на рівні клієнтів обчислення total_purchases, total_revenue, avg_order_value, customer_lifetime, days_since_last_purchase та purchase_frequency. Це можна зробити одним SQL-запитом за допомогою GROUP BY та віконних функцій або поетапно за допомогою проміжних таблиць.

По-друге, ви створюєте мітку відтоку на основі правила неактивностіНаприклад, churned = 1, якщо days_since_last_purchase > 90, інакше churned = 0. Цей позначений набір даних стає вашими вхідними даними для навчальної процедури логістичної регресії, яку можна викликати за допомогою оператора SQL CREATE MODEL або функції, специфічної для постачальника.

По-третє, ви навчаєте модель логістичної регресії, визначаючи, які стовпці є ознаками і який стовпець є цільовою міткою (відмова). Механізм машинного навчання вивчає коефіцієнти, які відображають, як кожна функція сприяє ризику відтоку, що може бути дуже корисним для зацікавлених сторін бізнесу.

Вихід моделі зазвичай являє собою таблицю або представлення з одним рядком на клієнта., включаючи спроектовані функції та мітку відтоку. Пізніше, коли ви використовуватимете модель для прогнозування, ви отримаєте додатковий стовпець прогнозування, який представлятиме або прогнозовану мітку (0 або 1), або ймовірність відтоку.

Оцінка моделей відтоку клієнтів: показники, які дійсно мають значення

Навчання моделі відтоку клієнтів – це лише півсправи; ви повинні ретельно оцінити її ефективність перед розгортанням його у виробничих кампаніях. Фреймворки машинного навчання на основі SQL часто надають помічники оцінки, такі як функція model_evaluate, яка обчислює загальні метрики.

Для відтоку клієнтів важливо дивитися далі простої точностіТочність просто вимірює відсоток правильних прогнозів, але в незбалансованих проблемах (де більшість клієнтів не відходять) модель може бути «точною», але водночас майже марною для вашого бізнесу.

Ключові показники для прогнозування відтоку клієнтів включають:

• АМУ-РПЦ: вимірює здатність моделі розрізняти тих, хто відмовляється від користувачів, за всіма порогами класифікації; значення ближчі до 1 вказують на сильнішу дискримінацію.
• Точність: частка передбачуваних відходів, які дійсно є відходами; висока точність означає менше хибних тривог та ефективніші витрати на утримання.
• Згадувати: частка фактичних клієнтів, які відмовилися від покупок, і яких модель правильно визначає; високий рівень відкликання гарантує, що ви не пропустите багатьох клієнтів, що перебувають у групі ризику.
• F1 бал: гармонійне середнє точності та повноти, корисне, коли вам потрібен баланс між виявленням великої кількості помилкових результатів та уникненням занадто великої кількості хибнопозитивних результатів.

У багатьох реальних проектах, спрямованих на зменшення відтоку клієнтів, зацікавлені сторони бізнесу більше дбають про точність та повноту в позитивному класі. (клієнти, щодо яких прогнозується відтік), ніж щодо глобальної точності. Зрештою, мета полягає в тому, щоб ефективно орієнтуватися на пропозиції утримання клієнтів, а не в тому, щоб добре виглядати на основі одного усередненого показника.

Оцінювання на основі SQL зазвичай виконується на наборі тестів, що вимагають певних зусиль. який не використовувався для навчання. Ви передаєте цей набір даних до функції model_evaluate або еквівалентної, отримуєте AUC-ROC, точність, прецизійність та повноту, а потім виконуєте ітерації щодо інженерії ознак, порогів або алгоритмів на основі цих результатів.

Методи, натхненні Python, для покращення моделей відтоку користувачів

Багато найкращих практик моделювання відтоку клієнтів походять із ширшої екосистеми машинного навчання (ML)., де широко використовуються Python та бібліотеки, такі як scikit-learn, imbalanced-learn та інші. Однак ці концепції можна перенести на робочі процеси, орієнтовані на SQL, або гібридні схеми, де SQL займається створенням функцій, а Python — розширеним моделюванням.

Поширеною схемою є початок дослідження відтоку даних із загальнодоступного набору даних. наприклад, CSV-файл із даними про відтік клієнтів банку з Kaggle. Ці набори даних зазвичай включають демографічні дані (вік, країну, стать), термін дії рахунку, кількість продуктів, кредитний рейтинг та чи вийшов клієнт (відплив клієнта).

Звичайний робочий процес починається із завантаження та перевірки набору даних: перевірка кількості рядків і стовпців, підсумовування числових ознак, дослідження цільового розподілу та виявлення очевидно нерелевантних атрибутів, таких як прізвища клієнтів або непрозорі ідентифікатори, які не допоможуть прогнозуванню.

Візуальне дослідження особливо кориснеПобудова розподілів та коробкових діаграм безперервних змінних (таких як вік або стаж), розділених за міткою відтоку, може швидко виявити, які ознаки мають пояснювальну силу. Гістограми для категоріальних змінних (стать, країна) показують, чи певні категорії корелюють з вищим відтоком.

Під час цієї дослідницької фази ви також шукаєте проблеми з якістю даних: відсутні значення, екстремальні викиди, домінантні категорії та підозрілі закономірності. Усе це може вплинути на продуктивність моделі в подальшому процесі та може вимагати очищення, обмеження або перекодування.

Категоричні змінні – ще один важливий моментАлгоритми машинного навчання зазвичай очікують числового введення, тому текстові категорії мають бути закодовані. Прості порядкові кодери відображають категорії на цілі числа, що може працювати, але може вводити штучне впорядкування (наприклад, кольорові коди, де 6 не є «більшим за» 2 у будь-якому значущому сенсі). Більш складні кодування, такі як одноразове або цільове кодування, зазвичай дають кращі моделі, хоча й ціною збільшення кількості функцій.

Від першої моделі відтоку клієнтів до надійної оцінки

Після базового очищення та кодування можна навчити першу модель відтоку— наприклад, класифікатор випадкового лісу, який є стійким, добре обробляє нелінійні зв'язки та вимагає відносно невеликого масштабування ознак.

Потім ви розділяєте дані на навчальні та тестові набори (наприклад, 70% навчання, 30% тестування) для моделювання майбутніх, невидимих ​​клієнтів. Модель підганяється до навчального набору та оцінюється на тестовому наборі за допомогою таких показників, як точність, прецизійність, повнота та F1-бал.

На цьому етапі дуже легко ввести в оману високоточні цифриУ задачах незбалансованого відтоку клієнтів модель може досягти високої точності, просто завжди прогнозуючи клас більшості (невідтоки), ледве виявляючи фактичні відтоки. Ось чому точність, повнота та F1, специфічні для класу відтоку, набагато важливіші.

Крива ROC та її площа під кривою (AUC) забезпечують більш нюансований погляд, показуючи компроміс між рівнем істинно позитивних результатів та рівнем хибнопозитивних результатів для всіх порогових значень. Крива, яка чітко домінує над діагональною базовою лінією, вказує на корисну модель, але знову ж таки, ви повинні пов'язати це з компромісами між бізнес-витратами та вигодами.

Вибір правильної метрики оцінки – це бізнес-рішенняЯкщо робота з утриманням клієнтів є дорогою, ви можете віддати перевагу високій точності (орієнтуватися лише на тих, хто ймовірно відмовиться від покупки). Якщо втрата клієнта є надзвичайно дорогою, ви можете прийняти більше хибнопозитивних результатів і зосередитися на запам'ятовуванні (виявити якомога більше клієнтів, які відмовилися від покупки), навіть якщо це означає звернення до більшої кількості клієнтів.

Налаштування гіперпараметрів та обробка незбалансованих міток відтоку

Після того, як базова модель відтоку клієнтів створена, наступні великі переваги зазвичай пов'язані з налаштуванням гіперпараметрів.Гіперпараметри – це значення конфігурації, зовнішні по відношенню до процесу навчання (кількість дерев, глибина дерева, швидкість навчання тощо), які можуть суттєво вплинути на якість моделі.

Практичний підхід полягає у визначенні простору пошуку гіперпараметрів (сітка або випадкові діапазони для кожного параметра), а потім досліджують підмножину комбінацій за допомогою рандомізованого пошуку або баєсівської оптимізації. Для кожної конфігурації-кандидата виконується перехресна перевірка навчальних даних, а для їх порівняння використовується метрика, така як F1-оцінка.

Для відтоку F1 часто є кращою метою, ніж чиста точність. тому що це балансує між точністю та запам'ятовуваністю, що зазвичай є важливим під час визначення пріоритетів для клієнтів з групи ризику.

Ще однією серйозною проблемою моделювання відтоку є дисбаланс міток: у ваших історичних даних зазвичай набагато більше не-чернерів, ніж тих, хто їх виявляє. Якщо їх не враховувати, більшість алгоритмів навчаться «грати безпечно» та здебільшого передбачатимуть клас більшості.

Існує кілька стратегій обробки незбалансованих даних про відтік клієнтів:

• Надмірна вибірка класу меншин використовуючи такі методи, як SMOTE, ADASYN або SVMSMOTE, які синтезують нові приклади меншин шляхом інтерполяції між існуючими.
• Недостатня вибірка для класу більшості скоротити набір даних, одночасно роблячи класи більш збалансованими (іноді в поєднанні з надмірною вибіркою).
• Використання алгоритмів або обгорток, які обробляють ваги класів або збалансовані підмножини внутрішньо, наприклад, збалансовані випадкові ліси, які навчають кожне дерево на збалансованій за класами вибірці бутстрепу.

Емпірично, вкрай важливо, щоб ваш тестовий набір залишався недоторканим та незбалансованим, що відображає справжній розподіл продукції. Ви можете надмірно дискретизувати або іншим чином маніпулювати лише навчальним набором; інакше показники оцінки будуть надмірно оптимістичними та не відображатимуть реальну продуктивність.

У багатьох експериментах використання балансування на рівні алгоритмів (наприклад, збалансованого випадкового лісу) без зміни необроблених навчальних даних призвело до значного покращення точності та F1, іноді на десять відсоткових пунктів або більше. Для моделі відтоку клієнтів це може призвести до значно кращого таргетування клієнтів групи ризику та вищої рентабельності інвестицій у кампанії утримання.

Пам’ятайте, що кожен відсоток покращення ефективного утримання може мати надзвичайно великий вплив. на основі регулярного доходу та цінності життя клієнта. Точне виявлення більшої кількості клієнтів, які відмовляються від послуг, не є кінцевою метою, але це дає вам можливість розгортати пропозиції, покращувати послуги та персоналізовані втручання там, де це найважливіше.

Загалом, поєднання можливостей машинного навчання, налаштованих на SQL (таких як Amazon Redshift ML та логістична регресія, керована SQL) з надійними практиками машинного навчання (розробка функцій, належні метрики, налаштування гіперпараметрів та обробка дисбалансів) надає вам потужний інструментарій для оцінки ризику відтоку безпосередньо там, де зберігаються ваші дані. Незалежно від того, чи працюєте ви у сфері фінансів, телекомунікацій, електронної комерції чи SaaS, ці методи дозволяють вам перетворити необроблені історії взаємодії на чіткі оцінки ризику відтоку, на які маркетингові та операційні команди можуть впевнено діяти, зміцнюючи цикл зворотного зв'язку між аналітикою та бізнес-рішеннями.