# Настройка динамических сегментов: как сделать, чтобы база пересобиралась сама > Сегменты обновляются раз в месяц вручную, а клиент за это время успевает купить или уйти. Разбираем правила входа и выхода, пересчет и связку со сценариями. **Рубрика:** Статьи **Автор:** Егор Череватенко, CRM-маркетолог, ClientCore **Дата:** 2026-11-12 Обычная картина в компании с живой базой и внедренной CRM. Раз в месяц маркетолог выгружает клиентов, фильтрует их в таблице, собирает «спящих», «VIP» и «новичков» и загружает обратно. Через неделю сегмент уже устарел. Половина «спящих» вернулась сама и получает письмо со скидкой, которую можно было не давать. Новые клиенты, пришедшие после выгрузки, никуда не попали и ждут следующего месяца. На отчетах это незаметно: рассылки уходят, открытия есть, выручка капает. Деньги теряются в зазоре между моментом, когда клиент изменил поведение, и моментом, когда система это заметила. Мы попросили Егора Череватенко, CRM-маркетолога ClientCore, разложить по шагам, как настройка динамических сегментов этот зазор закрывает и где чаще всего ломается. > **Читайте также:** [Настройка персональных предложений по сегментам: как перейти от одного оффера для всех к экономике по ценности клиента](https://clientcore.ru/blog/articles/nastroyka-personalnyh-predlozheniy-po-segmentam-kak-pereyti-ot-odnogo-offera-dlya-vseh-k-ekonomike-po-cennosti-klienta) ## Сколько стоит сегмент, который пересобирают раз в месяц Начнем с денег, потому что без них разговор о сегментации звучит как гигиена. Возьмем условный ритейл: средний чек 4 000 ₽, за месяц в зону риска оттока переходят 3 000 клиентов. Если реактивационное письмо приходит в первые дни после того, как клиент «замолчал», возвращается, допустим, 8%. Если оно приходит через две–три недели, когда человек уже привык покупать у конкурента, возвращается около 3%. Разница в 5 процентных пунктов — это 150 заказов, или 600 000 ₽ в месяц. И это один сегмент. Добавьте окно второй покупки у новичков: оно короткое, и ручная выгрузка раз в месяц пропускает его почти целиком. Добавьте скидки, которые уходят уже вернувшимся клиентам, и маржу, сгоревшую на людях, которые купили бы и без промокода. Цифры условные, ваши будут другими. Но порядок потерь обычно именно такой, и считается он за полчаса: берете время реакции на каждый ключевой сегмент и смотрите, как конверсия падает с каждой неделей опоздания. > На аудитах я первым делом смотрю дату последнего пересчета каждого сегмента. Регулярно вижу „активную базу“, которую не трогали два месяца, и рассылку на нее каждую неделю. В такой базе к моменту отправки бывает до трети людей, которые по факту уже не активны, и еще столько же новых, которые туда не попали». > > — Егор Череватенко, CRM-маркетолог, ClientCore **Норма** - у каждого рабочего сегмента известна частота обновления и она записана - время от события до попадания клиента в сегмент измеряется часами или днями - потери от задержки посчитаны хотя бы для двух-трех ключевых сегментов **Red flag** - сегменты собираются в Excel и загружаются файлом - никто не может сказать, когда сегмент обновлялся последний раз - в одной рассылке оказываются клиенты, купившие вчера и год назад ## Условия входа и выхода: сегмент как правило Динамический сегмент — это описанное правило, по которому система сама решает, кто сейчас внутри. Ключевое слово «сейчас». Большинство проблем начинается с того, что правило входа продумали, а про выход забыли. Пример. Сегмент «риск оттока»: не покупал 90–180 дней. Вход понятен. А что происходит, когда человек купил? Если условие строится от даты последней покупки, он выпадет автоматически при следующем пересчете. Если сегмент собрали один раз статичным списком, клиент так и останется «уходящим» и продолжит получать письма «мы скучаем» с купоном. Поэтому правила мы прописываем парами: - **Вход** — какое поведение или атрибут переводит клиента в сегмент: давность и частота покупок, сумма за период, категория, канал, статус в программе лояльности. - **Выход** — какое событие выводит его обратно: покупка, отписка, переход в более ценный сегмент, истечение срока. - **Удержание** — сколько клиент может находиться внутри, прежде чем его переведут дальше. Человек, который полгода сидит в «риске оттока» и не реагирует, уже в другом статусе, и бюджет на него нужен другой. Отдельно стоит проверить границы. «90 дней» считается от даты заказа или от даты доставки? Учитываются ли возвраты? Попадает ли офлайн-покупка в тот же расчет, что и онлайн? Если ответы не зафиксированы, через полгода два маркетолога соберут два разных «риска оттока» и будут спорить о цифрах. ## Как обновлять сегменты автоматически и с какой частотой Вопрос «как обновлять сегменты автоматически» звучит технически, но отвечать на него приходится через бизнес-логику. Частота пересчета зависит от того, как быстро устаревает решение, которое вы принимаете на основе сегмента. Мы раскладываем сегменты на три группы: 1. **Событийные** — брошенная корзина, первая покупка, просмотр товара, падение цены. Здесь пересчет по расписанию не годится вообще: условие проверяется в момент события прямо внутри триггера. 2. **Поведенческие** — RFM-группы, риск оттока, «готов к повторной покупке». Ежедневного пересчета хватает почти всегда, для коротких циклов покупки можно чаще. 3. **Стратегические** — LTV-группы, сегменты для медиапланирования и look-alike, аналитические срезы. Им достаточно раза в неделю или в месяц, потому что решения по ним принимаются медленно. Частый перекос — когда все сегменты пересчитываются с одной частотой, «чтобы было единообразно». Либо брошенная корзина ждет ночного пересчета и теряет первые часы, когда конверсия максимальная. Либо система каждый час гоняет тяжелые аналитические срезы, которые никому не нужны чаще раза в неделю, и тормозит остальное. > Хороший тест: спросите себя, что сломается, если сегмент обновится на сутки позже. Для корзины — сломается все, первые три–четыре часа дают основную часть возвратов. Для LTV-сегмента — ничего. Отсюда и частота. Ставить всем „раз в час“ так же плохо, как всем „раз в месяц“». > > — Егор Череватенко, CRM-маркетолог, ClientCore ## Пересечения сегментов: кто получит письмо, если клиент сразу в трех Клиент одновременно VIP, находится в риске оттока и бросил корзину. Если сегменты живут сами по себе, он получит три письма за день: благодарность за лояльность, «мы скучаем» со скидкой 15% и напоминание о корзине. Скидку он, скорее всего, применит к корзине, которую оформил бы и так, а к бренду начнет относиться как к назойливому продавцу. Конфликты пересечений решаются тремя механиками, и обычно нужны все: - **Иерархия приоритетов.** Явно записанный порядок: событийные триггеры важнее массовых рассылок, реактивация важнее кросс-продаж, сервисные сообщения важнее всего. Если клиент попадает в два сценария, срабатывает старший. - **Взаимоисключение.** Некоторые сегменты по смыслу не должны пересекаться. Новичок не может быть в «риске оттока», VIP не должен получать базовую скидку. Это прописывается прямо в условиях входа. - **Частотный лимит.** Общий потолок коммуникаций на клиента за период по всем каналам. Даже при идеальных приоритетах без лимита активный клиент получит слишком много. **Норма** - есть одна таблица приоритетов, которую видят и маркетинг, и CRM-команда - условия входа учитывают, где клиент уже находится - лимит касаний настроен на уровне платформы и общий для всех каналов **Red flag** - каждый сценарий настраивали разные люди, и никто не знает, как они пересекаются - скидки разного размера одновременно уходят одному клиенту - отписки растут после запуска новых триггеров, а причину никто не ищет ## Связка сегментов со сценариями Сегмент без сценария — аналитика. Сценарий без живого сегмента — рассылка вслепую. Ценность появляется, когда переход клиента между сегментами сам запускает нужную коммуникацию. Как это выглядит в работе. Клиент сделал первую покупку и попал в «новички». Запускается цепочка онбординга с подводкой ко второму заказу. Купил второй раз — вышел из «новичков», цепочка остановилась, он перешел в «развивающиеся», и там работает своя логика: кросс-сейл по категории, приглашение в программу лояльности. Перестал покупать — система увидела это по дате последнего заказа, перевела в «риск оттока» и запустила реактивацию. Вернулся — реактивация обрывается на том письме, где он купил. Главное здесь — правила остановки. Если цепочка не проверяет выход из сегмента перед каждым шагом, клиент, купивший после первого письма, получит еще четыре. Мы видим это регулярно: сценарии запускаются по входу, а выход никто не связал с остановкой. Эффект от такой связки хорошо виден, когда компания уходит от рассылок «на всю базу». В проекте для MINIDINO письма раньше получали все подряд, без разбора сегментов. Мы пересобрали логику в пользу точности вместо охвата, и эффективность email выросла на 110% за квартал без роста числа отправок ([кейс](https://clientcore.ru/blog/articles/keis-minidino-rost-effektivnosti-email)). Похожая история была с FINNTRAIL: каждое письмо уходило всей базе разом. После перехода на сегментированные и персонализированные рассылки выручка email-канала выросла на 15% ([кейс](https://clientcore.ru/blog/articles/keis-finntrail-rost-vyruchki-email)). > Когда принимаю проект, прошу показать любого клиента и пройти его путь: в каких сегментах он сейчас, какие сценарии на него действуют, что он получит завтра. Если команде на это нужно больше пяти минут и три вкладки, связка сегментов со сценариями не работает. Скорее всего, там есть люди, которые получают противоречащие друг другу письма». > > — Егор Череватенко, CRM-маркетолог, ClientCore ## Сегментация в Mindbox: что обычно недонастроено Большинство наших клиентов работают в Mindbox, и проблема почти никогда не в платформе. Инструменты для динамической сегментации там есть: сегментации с пересчетом по расписанию, фильтры по действиям и заказам прямо в триггерах, вычисляемые поля клиента. Сложности возникают на стороне тех, кто всем этим пользуется. Что встречаем чаще всего: - **Кладбище сегментаций.** Десятки сегментов, созданных под разовые акции, с похожими названиями. Половина не пересчитывается, но на них все еще ссылаются старые сценарии. - **Сегменты из импорта.** Клиентов загружают файлом из внешней аналитики, и сегмент живет до следующей загрузки. Это та же ручная выгрузка раз в месяц, только внутри Mindbox. - **Неполные данные.** Офлайн-заказы приходят с задержкой или без привязки к клиенту, и RFM считается только по сайту. Человек, который регулярно покупает в рознице, для системы «уходящий». - **Фильтры, продублированные в каждом сценарии.** Одно и то же условие «не покупал 90 дней» прописано в пяти местах по-разному. Меняешь в одном — остальные живут по старым правилам. Лечится это ревизией: что из сегментов реально используется, что пересчитывается, откуда берутся данные. Дальше остается единый справочник сегментов, на который ссылаются все сценарии. ## Настройка динамических сегментов под ключ: как идет работа Когда к нам приходят с задачей настроить динамические сегменты, работа делится на этапы. Работаем с командами в Москве, Санкт-Петербурге и других городах. Настройка динамических сегментов в Москве и в СПб по процессу ничем не отличается, все делается в вашем аккаунте платформы удаленно. 1. **Аудит текущего состояния.** Какие сегменты есть, как часто обновляются, на какие сценарии завязаны, где данные неполные. На выходе — карта сегментов и список конфликтов. 2. **Расчет потерь.** Для ключевых сегментов считаем, сколько выручки уходит из-за задержки обновления и пересечений. Это задает очередность: начинаем с того, что дает больше денег. 3. **Модель сегментации.** Описываем правила входа, выхода и удержания, частоту пересчета, приоритеты и взаимоисключения. Документ понятен и маркетингу, и технической команде. 4. **Настройка в платформе.** Собираем сегменты, переводим ручные выгрузки на автоматический пересчет, чистим дубли фильтров, связываем сегменты со сценариями и правилами остановки. 5. **Проверка и мониторинг.** Прогоняем тестовых клиентов по всем переходам, ставим контроль размеров сегментов. Если «риск оттока» за ночь вырос вдвое, это сигнал проблемы с данными, и узнать о нем лучше до отправки рассылки. Обычно первые сегменты переходят на автоматический пересчет в течение двух–трех недель, полная пересборка модели с ревизией сценариев занимает 1–2 месяца в зависимости от объема. **Норма** - у каждого сегмента есть владелец и описание в одном документе - размер ключевых сегментов отслеживается, резкие скачки разбираются - новые сценарии ссылаются на существующие сегменты, а не создают свои копии **Red flag** - новый сегмент появляется под каждую акцию и остается навсегда - никто не проверяет, сколько клиентов в сегменте перед отправкой - после ухода сотрудника никто не понимает, как устроена логика > **Читайте также:** [Настройка сегментов по поведению: какие действия клиента должны менять коммуникацию уже сегодня](https://clientcore.ru/blog/articles/nastroyka-segmentov-po-povedeniyu-kakie-deystviya-klienta-dolzhny-menyat-kommunikaciyu-uzhe-segodnya) --- [Открыть статью на сайте](https://clientcore.ru/blog/articles/nastroyka-dinamicheskih-segmentov-kak-sdelat-chtoby-baza-peresobiralas-sama)