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

Почему персонализация email-рассылок ломается на масштабе

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

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

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

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

Что даёт рекомендательный подбор в рассылках

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

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

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

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

Персонализация email-рассылок: подходы и ограничения

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

Что реально сравнивают

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

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

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

1. Аудит данных. Разбираем, какие события собираются, сколько истории хранится, у какой доли получателей есть поведенческий профиль и где пропуски. Итог — перечень пробелов и решение: что закрываем сбором, а что обходим правилами.
2. Карта событий. Сводим действия к единой схеме: что считаем сигналом, за какое окно, с каким весом, как сопоставляем адрес и профиль. Расхождения в названиях событий убираем на этом шаге.
3. Настройка подбора. Модель учится на согласованной истории; для новых получателей задаём холодный старт — блок по популярности сегмента, пока поведения не хватает. Отдельно ограничиваем частоту, чтобы рост открытий не оплачивался отписками.
4. Проверка на группе. Часть потока продолжает получать прежние письма, и мы сравниваем открытия, переходы, долю заказов и отписки. Эффект должен держаться на нескольких рассылках, а не на одной удачной.
5. Регламент отката. До включения фиксируем порог метрик и порядок действий при его пробитии: возврат на прежнюю схему за один прогон, без правок в коде.
6. Запуск и передача. Включаем постепенно — сначала на долю потока, затем на весь. Передаём документацию, доступы и обучение вашей команды.

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

Артефакты проекта: правила подбора и регламенты

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

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

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

Кейс: как вырос отклик регулярной рассылки

Что было до внедрения

Сеть магазинов товаров для дома отправляла регулярную рассылку по расписанию: маркетолог выгружал сегменты, вручную отбирал товары и правил подборки под каждый выпуск. На выпуск уходило шесть-восемь часов работы, до 70% позиций в письме заменялись руками — правила сегментации не учитывали историю покупок, давность визита и остаток на складе. Отклик держался около 2,3% переходов, доля отписок — 0,8% на выпуск: одним и тем же людям приходили одни и те же блоки.

Что изменили

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

Что стало после

Отклик на письмо вырос до 5,4% переходов, доля отписок снизилась до 0,4%. Сборка выпуска занимает около 35 минут, а доля ручных правок в подборе предложений упала с 70% до 15% — маркетолог проверяет выдачу и снимает отдельные позиции. Контур отдаёт журнал по каждому выпуску, поэтому динамика отклика видна по сегментам, а не только по всей базе.

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

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

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

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

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

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

Частые технические вопросы по внедрению подбора

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

Какой объём истории событий нужен для старта?

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

Как обезопасить персональные данные?

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

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

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

Обсудим задачу: какие данные нужны для старта

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

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

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