Розробка AI-сегментації клієнтів: кластеризація + LLM-опис

Чому AI-сегментація клієнтів впирається в ручні правила

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

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

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

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

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

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

AI-сегментація клієнтів знімає це інакше. Модель шукає спільні закономірності за десятками ознак одразу — частота, давність, склад кошика, канали, реакція на минулі кампанії — і виділяє групи там, де ручна сегментація бази бачить однорідну масу.

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

Сегментація за поведінкою: що зникає з ручної роботи

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

Поведінкові ознаки клієнтів змінюють саму логіку — сегмент перераховується за діями, а не за разово заданим фільтром.

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

Ознаки рахуються в ковзних вікнах на 7, 30 і 90 днів і нормуються — профіль не залежить від масштабу клієнта, а оновлюється інкрементально, без повного перерахунку.

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

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

Оновлення сегментів без аналітика йде за розкладом: перерахунок, потім перезбирання описів; ручна правка потрібна лише в разі зміни бізнес-правил.

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

Порівняння підходів: правила, кластеризація, гібрид

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

Тому порівняння методів сегментації має сенс вести за трьома осями — пояснюваність результату, стійкість до нових даних і трудомісткість підтримки.

Чиста кластеризація рідко доходить до впровадження: мітки виду «кластер 3» нічого не кажуть бізнесу. Гібридний підхід до сегментації знімає це обмеження — мовна модель описує склад кожного кластера й пропонує зрозумілу назву, а правила задають межі, за які сегмент не виходить.

Етапи впровадження: від аудиту даних до передачі

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

1. Аудит даних для сегментації. Розбираємо транзакції, звернення, активність у продукті, записи облікової системи. Перевіряємо глибину історії, повноту полів і ключ, за яким записи зводяться до одного клієнта. На виході — карта джерел із явними обмеженнями.

2. Схема ознак. Сирі поля переводимо в поведінкові: частота й давність покупок, динаміка за рівні вікна, частка повернень, глибина користування продуктом. Ознака, яку не можна пояснити бізнес-логікою, у розбиття не йде.

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

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

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

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

Що передаємо на руки: артефакти та регламенти

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

• Словник даних. За кожною ознакою — джерело, формула розрахунку, вікно агрегації, одиниці, частка пропусків і правило їх заповнення, відповідальний за поле.
• Схеми потоків даних. Звідки надходять події та угоди, де рахуються вітрини, у який момент підключається модель і куди йдуть готові мітки.
• Правила доступу. Хто працює з вихідними даними, хто — лише зі знеособленими вивантаженнями, як оформлюються разові звернення і як вони журналюються.
• Регламент перенавчання. Тригери (зсув розподілу, падіння метрик, зміна бізнес-правил), періодичність прогонів, порядок перевірки якості до виведення нової версії в роботу.
• Картки сегментів. Назва, ознаки-маркери, типові дії для команди, межі застосовності — щоб кластер не трактували по-своєму.
• Інструкції для суміжних команд. Як отримати свіжу сегментацію, як оспорити віднесення клієнта, до кого йти при збої розрахунку.
• Журнал версій моделі. Яка версія дала поточні мітки, чим відрізняється від попередньої, як повернутися на минулу без втрати розмітки.
• Документація рішення. Архітектурна схема, точки інтеграції, чек-лист приймання та порядок передачі новому інженеру.

Кейс: як скоротили ручну розмітку бази

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

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

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

Перезбирання сегментів за розкладом запускаємо в Airflow, тому групи оновлюються без участі аналітика.

Метрики до та після

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

Тому кампанія, запущена на групі, не розсипається під час наступного перезбирання — частка переходів без змін у поведінці впала з 22% до 4%.

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

Чим кластеризація відрізняється від правил за ознаками?

Правила за ознаками задає людина: «купував за останні 30 днів, сума вища за поріг — активний клієнт». Така сегментація передбачувана, легко пояснюється й відтворюється, тому її беруть, коли межі сегментів відомі з логіки роботи з клієнтами.

Слабке місце — пороги призначаються вручну, а на десятках ознак людина перестає бачити, які поєднання реально розрізняють аудиторію.

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

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

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

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

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

На практиці підходи поєднують: правила задають жорсткі обмеження, кластеризація шукає структуру всередині.

Часті технічні питання про дані та приватність

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

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

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

Як знеособлюються клієнтські дані?

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

Як ви перевіряєте якість сегментів?

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

Кому належать модель і дані?

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

Що надіслати для оцінки і з чого почнемо

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

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

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