Разработка AI-системы для персонализации промоакций

Почему персонализация промоакций даёт сбой на потоке

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

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

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

Точность отбора аудитории и скорость выпуска акций

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

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

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

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

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

Форматы персонализации промоакций: правила, модели, гибрид

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

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

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

Как мы внедряем ИИ-систему: этапы инженерной работы

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

1. Аудит логики акций. Разбираем действующие правила: какие сегменты вы выделяете, по каким признакам даёте скидку или бонус, где правила конфликтуют и дублируют друг друга. Результат — перечень правил с их фактической отдачей и списком тех, что стоит отдать модели.
2. Схема данных. Определяем, какие события нужны для персонализации, как они собираются сегодня и чего не хватает. Фиксируем состав признаков, частоту обновления и правила очистки — без этого любая модель учится на шуме.
3. Проверка на исторических данных. Прогоняем будущую логику на прошлых запусках: сравниваем, какие предложения она выдала бы и как это соотносится с реальными реакциями покупателей. Так гипотезы проверяются до трафика и без риска для текущих кампаний.
4. Сборка и внедрение контура. Собираем контур рекомендаций, подключаем его к системе акций и настраиваем ограничения: частота предложений, приоритеты, стоп-правила. Запуск идёт поэтапно, с возможностью откатить логику к прежней.
5. Обучение команды и передача. Показываем маркетологам и аналитикам, как читать отчёты, менять правила и корректно останавливать эксперимент. Отдаём документацию по схеме данных и регламент обновления модели.

Такой порядок закрывает главный риск персонализации — когда непрозрачная логика живёт отдельно от бизнес-правил и её нельзя ни объяснить, ни быстро остановить.

Пакет передачи: конфигурации, схемы, политики доступа

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

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

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

Кейс: рост доли отклика и сокращение ручных сегментов

До внедрения промо-логика жила в ручных сегментах: маркетолог собирал 6–8 групп в CRM по полу, городу и средней сумме чека, обновлял их раз в квартал и под каждую акцию выгружал списки руками. Доля отклика держалась в узком коридоре и проседала при любом расширении аудитории, а подготовка одной кампании занимала несколько дней — за это время акция успевала потерять актуальность.

Что изменили в контуре решений

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

Метрики до и после

Доля отклика выросла в 2,4 раза на сопоставимой аудитории, число ручных сегментов сократилось примерно на 80%, а подготовка кампании сжалась с нескольких дней до часа. Отдача на одну отправку поднялась без роста объёмов рассылки — часть контактов мы сознательно убрали, чтобы не выжигать базу.

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

Чем отличается сегментация по правилам от моделей ранжирования

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

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

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

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

Технические сомнения: данные, качество, поддержка

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

Как контролируется качество выдачи после запуска?

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

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

Что входит в поддержку после передачи и как устроено дообучение?

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

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

Обсудим задачу и вернёмся с оценкой и планом

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

Что подготовить к обсуждению:

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

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

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