Прогноз оттока клиентов: 3 подхода к детектированию риска

Подход 1: Пороговые правила на основе RFM

Самый распространённый способ детектировать отток — задать порог давности последней покупки (Recency) и считать клиента «уходящим», если он не вернулся за N дней. Например: клиент зоомагазина, покупавший корм раз в месяц, молчит уже 45 дней — флаг риска поднят. Это логично, дёшево в реализации и понятно любому маркетологу.

Плюсы: прозрачная логика, нет зависимости от объёма данных, быстро внедряется даже в простой CRM. Минусы: порог одинаков для всех — а реальные циклы покупки у каждого клиента разные. Пенсионерка, покупающая очки раз в два года, и студент, заходящий каждые три месяца, получат одинаковый «тревожный» статус в одинаковые дни — хотя первая ведёт себя нормально, а второй уже ушёл к конкуренту. RFM-пороги хорошо работают как первый фильтр, но систематически ошибаются на неоднородных базах.

Когда выбирать: небольшая база (до 5 000 активных клиентов), единый продукт с предсказуемым циклом, ресурсов на аналитику нет. Это стартовая точка, а не финальное решение.

Подход 2: ML-скоринг на исторических данных

Машинное обучение позволяет персонализировать сам порог — модель учитывает индивидуальный ритм покупок каждого клиента, его реакцию на коммуникации, изменение среднего чека, ассортиментный сдвиг и десятки других признаков. На выходе каждый клиент получает вероятность оттока (например, 0,73), а не просто бинарный флаг.

Плюсы: модель адаптируется к реальному поведению конкретной базы, умеет различать «временно молчащих» и «реально ушедших», снижает число ложных тревог. Хорошая модель видит ранние сигналы — ещё до того, как клиент пропустит плановую покупку. Минусы: нужны исторические данные достаточного объёма и качества (как правило, от 10 000–20 000 транзакций), модель требует периодической переобучки, а интерпретировать результат маркетологу без технической поддержки бывает сложно.

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

Подход 3: Событийные триггеры — реакция на поведенческий сигнал

Вместо того чтобы ждать, когда пройдёт N дней, событийный подход реагирует на конкретное действие — или его отсутствие. Клиент клиники отменил запись без переноса. Покупатель оптики открыл письмо с акцией, но не перешёл по ссылке. Клиент зоомагазина впервые за год купил только один товар вместо обычной корзины из пяти позиций. Каждое из этих событий — слабый сигнал, но в комбинации они дают надёжный ранний маркер.

Плюсы: высокая скорость реакции (сигнал фиксируется в момент события, а не через неделю при пересчёте базы), легко объяснить команде («мы пишем клиенту, потому что он отменил визит»), хорошо работает даже на небольших базах. Минусы: требует качественной интеграции между всеми точками контакта — CRM, сайтом, кассой, email-платформой. Если данные из разных систем не синхронизированы в реальном времени, события теряются или запаздывают. Кроме того, событийная логика не учитывает долгосрочный тренд — она видит вспышку, но не медленное угасание.

Событийные триггеры особенно эффективны в связке с ML-скорингом: модель определяет группу риска, а триггер выбирает момент для коммуникации внутри этой группы.

Как три подхода соотносятся на практике: сводная таблица

Чтобы не выбирать «лучший» подход абстрактно, полезно смотреть на три параметра: скорость сигнала, требования к данным и цена ошибки. RFM-пороги дают сигнал медленно (по расписанию), данных требуют минимум, но цена ошибки высока на неоднородных базах. ML-скоринг работает быстрее при правильной архитектуре, требует богатой истории, зато снижает число ложных срабатываний. Событийные триггеры — самые быстрые, но слепы к медленным трендам и критически зависят от полноты интеграций.

Для большинства бизнесов с повторными продажами оптимальная архитектура выглядит так: ML-скоринг формирует приоритетный список риска, событийные триггеры определяют момент касания, а RFM служит резервным фильтром для клиентов с короткой историей. Ни один из подходов в изоляции не перекрывает весь спектр сигналов.

Что это значит для CRM-процесса в реальной компании

Главная практическая проблема — не алгоритм, а операционализация. Даже если прогноз оттока точен, он бесполезен, если менеджер увидит его через три дня в экселе и потратит два часа на ручное формирование предложения. Прогноз должен автоматически превращаться в готовую сделку или задачу в CRM — с персональным оффером, подходящим каналом и правильным моментом. Именно разрыв между аналитикой и действием съедает большую часть потенциала удержания.

Для компаний, работающих на 1С и стандартных CRM, это особенно актуально: данные о поведении клиентов есть, но они разрознены, и связать прогноз с конкретным действием менеджера технически непросто без специализированного слоя автоматизации.

Вывод

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

Если хотите посмотреть, как такая цепочка выглядит на данных вашей базы — в «Умном цикле» можно запустить пилот прямо на вашем сервере, без передачи данных наружу. Обсудить конкретику под ваш бизнес можно на демо-сессии.

«Умный цикл» строит такой прогноз автоматически

Берёт данные из вашей учётной системы, считает следующую покупку каждого клиента и кладёт готовую сделку в CRM. Покажем на демо «горячий список» по вашей базе.