Разработка системы Next Best Action: как повысить ROAS в 4–8 раз

Почему рекомендации не работают: где ломается Next Best Action

Типовой сбой выглядит так: движок рекомендаций в компании есть, но решения он принимает вслепую. Правила подбора лежат в одном месте, история покупок — в другом, обращения в поддержку — в третьем, а поведение на сайте вообще живёт отдельно. Никто не сводит эти сигналы в один профиль, поэтому система видит клиента фрагментами и достраивает картину предположениями.

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

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

Next Best Action устроен иначе — это непрерывный контур, где сигнал, расчёт и действие связаны по времени, а следующее лучшее действие определяется для каждого клиента отдельно, а не для усреднённого сегмента. Ниже разбираем, как этот контур собирается по шагам: от сведения разрозненных источников данных до контроля того, что предложение действительно повлияло на результат.

Эффект внедрения: рост ROAS, точности и удержания

Польза от системы Next Best Action проявляется не в интерфейсе, а в метриках. Ниже — пять изменений, которые заказчик фиксирует в первые недели после запуска; единый профиль клиента и события при этом собираются независимо от того, работает он на Salesforce или на собственной витрине данных.

Точность попадания в целевое действие

Модель ранжирует варианты под конкретного клиента, поэтому персонализация предложения в реальном времени совпадает с его следующим шагом. Доля попаданий в целевое действие и ROAS в сценариях повторных продаж вырастают в разы против единой рассылки по всей базе.

Скорость реакции на спрос

Профиль обновляется событиями, а не ночным пересчётом, поэтому система перестраивает предложение вслед за поведением: брошенная корзина, просмотр, обращение в поддержку. Всплеск спроса отрабатывается за минуты — раньше отчёт по кампании готовили днями.

Отток и повторные покупки

В ранжирование входят сигналы риска: падение частоты покупок, отписки, снижение вовлечённости. Удержание предлагается до ухода, поэтому отток в группах риска падает примерно на треть, а доля повторных покупок в горизонте квартала растёт.

Нагрузка на аналитиков

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

Способы построения рекомендаций: сравнение подходов

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

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

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

Этапы работ: от аудита данных до промышленного запуска

Начинаем не с модели, а с данных: если журнал действий неполный, а целевое событие в разных системах размечено по-разному, алгоритм учится на шуме и выдаёт рекомендации, которые никто не применяет. Поэтому работа идёт фиксированными этапами, и каждый заканчивается проверяемым артефактом.

1. Аудит источников данных. Смотрим, какие системы отдают события, с какой задержкой и в каком виде, где теряются идентификаторы клиента и расходятся справочники.
2. Схема событий и целевого действия. Фиксируем единый словарь: что считаем показом, действием и целевым результатом и как каждое из них связано с профилем клиента.
3. Сборка контура. Пересчёт признаков, хранилище истории и сервис, который выбирает действие в момент обращения канала и отдаёт ответ за время, не влияющее на отклик.
4. Настройка политик. Ограничения по частоте контактов, исключения по сегментам, приоритеты каналов, правила остановки при отклонении качества от ожидаемого.
5. Проверка на исторических данных. Обучаем контур на раннем периоде и смотрим, воспроизводит ли он фактическое поведение на следующем.
6. Постепенный запуск. Доля трафика 5–10% и контрольная группа; следим за долей принятых рекомендаций, охватом и стабильностью отклика.
7. Передача в эксплуатацию. Регламенты переобучения, мониторинг входных данных, панель метрик и обучение команды заказчика.

Артефакты внедрения: модели, правила, документация, регламенты

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

• Обученный контур ранжирования: конфигурация обучения, словари признаков и веса модели — воспроизводится из артефактов одной командой, результат повторяем на той же выборке.
• Описание признаков: для каждого указан источник, окно агрегации, задержка появления данных и допустимая доля пропусков — аналитик видит, почему действие получило высокую оценку.
• Политики доступа и ограничения: исключённые сегменты, потолок частоты коммуникаций, права ролей на данные, порядок согласования новых источников.
• Схема интеграций: какие системы отдают события, какая принимает решение, где стоят очереди и как ведёт себя контур при недоступности источника.
• Инструкции для аналитиков: как добавить признак, переобучить модель и сравнить качество на отложенной выборке, как читать отчёт по выданным рекомендациям.
• Регламент обновления модели: периодичность переобучения, триггеры по деградации целевой метрики, кто согласует выкат новой версии.
• План отката: возврат на предыдущую версию или на базовое правило одним переключателем, условия срабатывания и ответственный за решение.
• Журнал решений и мониторинг: логирование рекомендаций и фактического отклика, оповещения при расхождении прогноза с результатом.

Кейс: рост ROAS и повторных покупок после перехода на персональные рекомендации

Проект запускали у ритейлера с широкой матрицей: маркетинг работал по календарю акций, одна и та же рассылка уходила всей базе, а сегменты аналитик собирал руками в витрине отчётности. На входе зафиксировали базовые метрики: конверсия в целевое действие — 1,9%, доля попаданий рекомендации в топ-3 — 14%, отток — 4,2% активной базы в месяц, цикл подготовки кампании — две недели.

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

Как считали эффект

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

Конверсия в целевое действие выросла до 4,4%, доля попаданий в топ-3 — до 58%, отток сократился примерно на треть. Подготовка кампании занимает 40 минут вместо двух недель, рекомендации пересчитываются раз в сутки по свежим событиям. ROAS на сопоставимом периоде вырос в 4–8 раз в зависимости от категории.

Систему передали аналитикам клиента: признаки, правила и мониторинг качества описаны, переобучение идёт по регламенту, откат на прежний сценарий возможен без остановки рассылок.

Чем Next Best Action отличается от правил и ручных сегментов?

Разница — в том, кто формулирует логику выбора. В правилах её задаёт человек: «клиент не заходил 30 дней и не открыл письмо — предложить возвратный оффер». Такое условие живёт до следующего пересмотра, а ручной сегмент описывает один срез аудитории. Динамический выбор действия работает иначе: алгоритм оценивает все допустимые действия по свежим данным и выбирает лучшее на момент контакта.

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

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

Технические сомнения: холодный старт, разметка, отказоустойчивость

Холодный старт не означает ожидания: первые недели контур работает на правилах и экспертных приоритетах, а модель подключается, когда накоплен достаточный объём подтверждённых исходов. По мере роста данных вес правил снижается автоматически, без переключений руками. Ниже — ответы на возражения, которые звучат до старта чаще всего.

Как быть с редкими событиями?

Обучаем не на самом редком событии, а на его предвестниках: сериях действий, смене частоты, реакциях на прошлые коммуникации. Агрегация на уровне сегментов даёт достаточную выборку, и сигнал не тонет в шуме.

Что делать с неполными данными?

Пропуски помечаем явно, а не заменяем нулями: система знает, что признак отсутствует, и учитывает это в решении. Канал без истории не получает завышенный приоритет по умолчанию.

Не размоет ли модель ограничения бизнес-правилами?

Правила задают жёсткие рамки: что, кому, когда и как часто можно предлагать. Модель оптимизирует выбор внутри этих рамок, а не вместо них, поэтому продуктовые запреты соблюдаются буквально.

Что произойдёт при сбое источника данных?

Контур отдаёт последнее валидное состояние, а не пустой ответ: рекомендации продолжают идти в деградированном режиме. Сбой уходит в мониторинг, пересчёт после восстановления источника идёт автоматически, а журнал хранит, по каким данным строилось каждое предложение.

Обсудим задачу: соберём контур рекомендаций под ваш поток данных

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

Что понадобится от вашей стороны при обсуждении задачи:

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

Дальше мы фиксируем план проверки гипотез, считаем базовую линию по текущим показателям и запускаем контур на части потока, сверяя его с действующим правилом. Опишите задачу — вернёмся с оценкой и планом работ.