Настройка динамических сегментов: как сделать, чтобы база пересобиралась сама

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

На отчетах это незаметно: рассылки уходят, открытия есть, выручка капает. Деньги теряются в зазоре между моментом, когда клиент изменил поведение, и моментом, когда система это заметила. Мы попросили Егора Череватенко, CRM-маркетолога ClientCore, разложить по шагам, как настройка динамических сегментов этот зазор закрывает и где чаще всего ломается.

Сколько стоит сегмент, который пересобирают раз в месяц

Начнем с денег, потому что без них разговор о сегментации звучит как гигиена. Возьмем условный ритейл: средний чек 4 000 ₽, за месяц в зону риска оттока переходят 3 000 клиентов. Если реактивационное письмо приходит в первые дни после того, как клиент «замолчал», возвращается, допустим, 8%. Если оно приходит через две–три недели, когда человек уже привык покупать у конкурента, возвращается около 3%.

Разница в 5 процентных пунктов — это 150 заказов, или 600 000 ₽ в месяц. И это один сегмент. Добавьте окно второй покупки у новичков: оно короткое, и ручная выгрузка раз в месяц пропускает его почти целиком. Добавьте скидки, которые уходят уже вернувшимся клиентам, и маржу, сгоревшую на людях, которые купили бы и без промокода.

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

На аудитах я первым делом смотрю дату последнего пересчета каждого сегмента. Регулярно вижу „активную базу“, которую не трогали два месяца, и рассылку на нее каждую неделю. В такой базе к моменту отправки бывает до трети людей, которые по факту уже не активны, и еще столько же новых, которые туда не попали».

Егор Череватенко

CRM-маркетолог, ClientCore

Условия входа и выхода: сегмент как правило

Динамический сегмент — это описанное правило, по которому система сама решает, кто сейчас внутри. Ключевое слово «сейчас». Большинство проблем начинается с того, что правило входа продумали, а про выход забыли.

Пример. Сегмент «риск оттока»: не покупал 90–180 дней. Вход понятен. А что происходит, когда человек купил? Если условие строится от даты последней покупки, он выпадет автоматически при следующем пересчете. Если сегмент собрали один раз статичным списком, клиент так и останется «уходящим» и продолжит получать письма «мы скучаем» с купоном.

Поэтому правила мы прописываем парами:

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

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

Как обновлять сегменты автоматически и с какой частотой

Вопрос «как обновлять сегменты автоматически» звучит технически, но отвечать на него приходится через бизнес-логику. Частота пересчета зависит от того, как быстро устаревает решение, которое вы принимаете на основе сегмента.

Мы раскладываем сегменты на три группы:

1. Событийные — брошенная корзина, первая покупка, просмотр товара, падение цены. Здесь пересчет по расписанию не годится вообще: условие проверяется в момент события прямо внутри триггера. 2. Поведенческие — RFM-группы, риск оттока, «готов к повторной покупке». Ежедневного пересчета хватает почти всегда, для коротких циклов покупки можно чаще. 3. Стратегические — LTV-группы, сегменты для медиапланирования и look-alike, аналитические срезы. Им достаточно раза в неделю или в месяц, потому что решения по ним принимаются медленно.

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

Хороший тест: спросите себя, что сломается, если сегмент обновится на сутки позже. Для корзины — сломается все, первые три–четыре часа дают основную часть возвратов. Для LTV-сегмента — ничего. Отсюда и частота. Ставить всем „раз в час“ так же плохо, как всем „раз в месяц“».

Егор Череватенко

CRM-маркетолог, ClientCore

Пересечения сегментов: кто получит письмо, если клиент сразу в трех

Клиент одновременно VIP, находится в риске оттока и бросил корзину. Если сегменты живут сами по себе, он получит три письма за день: благодарность за лояльность, «мы скучаем» со скидкой 15% и напоминание о корзине. Скидку он, скорее всего, применит к корзине, которую оформил бы и так, а к бренду начнет относиться как к назойливому продавцу.

Конфликты пересечений решаются тремя механиками, и обычно нужны все:

• Иерархия приоритетов. Явно записанный порядок: событийные триггеры важнее массовых рассылок, реактивация важнее кросс-продаж, сервисные сообщения важнее всего. Если клиент попадает в два сценария, срабатывает старший.
• Взаимоисключение. Некоторые сегменты по смыслу не должны пересекаться. Новичок не может быть в «риске оттока», VIP не должен получать базовую скидку. Это прописывается прямо в условиях входа.
• Частотный лимит. Общий потолок коммуникаций на клиента за период по всем каналам. Даже при идеальных приоритетах без лимита активный клиент получит слишком много.

Связка сегментов со сценариями

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

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

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

Эффект от такой связки хорошо виден, когда компания уходит от рассылок «на всю базу». В проекте для MINIDINO письма раньше получали все подряд, без разбора сегментов. Мы пересобрали логику в пользу точности вместо охвата, и эффективность email выросла на 110% за квартал без роста числа отправок (кейс). Похожая история была с FINNTRAIL: каждое письмо уходило всей базе разом. После перехода на сегментированные и персонализированные рассылки выручка email-канала выросла на 15% (кейс).

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

Егор Череватенко

CRM-маркетолог, ClientCore

Сегментация в Mindbox: что обычно недонастроено

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

Что встречаем чаще всего:

• Кладбище сегментаций. Десятки сегментов, созданных под разовые акции, с похожими названиями. Половина не пересчитывается, но на них все еще ссылаются старые сценарии.
• Сегменты из импорта. Клиентов загружают файлом из внешней аналитики, и сегмент живет до следующей загрузки. Это та же ручная выгрузка раз в месяц, только внутри Mindbox.
• Неполные данные. Офлайн-заказы приходят с задержкой или без привязки к клиенту, и RFM считается только по сайту. Человек, который регулярно покупает в рознице, для системы «уходящий».
• Фильтры, продублированные в каждом сценарии. Одно и то же условие «не покупал 90 дней» прописано в пяти местах по-разному. Меняешь в одном — остальные живут по старым правилам.

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

Настройка динамических сегментов под ключ: как идет работа

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

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

Обычно первые сегменты переходят на автоматический пересчет в течение двух–трех недель, полная пересборка модели с ревизией сценариев занимает 1–2 месяца в зависимости от объема.