Клиентская база перед ноябрьскими рассылками — 2 ноября 2026

Сначала проверим, кому собираемся писать

В конце октября Mindbox опубликовал разбор переходов между RFM-сегментами. Материал от 30 октября предлагает смотреть, откуда приходят активные покупатели и куда они уходят. По одному размеру сегмента этого не увидеть: его состав может измениться при прежнем количестве людей. Пример в публикации учебный; принимать его цифры за результаты магазина нельзя.

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

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

Одна покупка может занять несколько строк

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

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

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

Здесь легко увлечься уборкой. Не стоит склеивать всю базу по общему семейному телефону или исправлять спорные записи сразу в рабочей системе. Сначала сохраните исходную выгрузку и перечень предполагаемых исправлений. Сомнительные совпадения лучше вынести на отдельную проверку.

Ошибочное объединение исказит историю обоих покупателей.

Одинаковое название сегмента ничего не гарантирует

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

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

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

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

Сверяем состав, даже если итоги близки

Представим еще один условный расчет. В таблице 420 покупателей, в CDP 427. Только в CDP обнаружены 12 профилей, только в таблице — пять. Чистая разница составляет семь человек, или около 1,7% от таблицы. Но разобраться нужно в 17 профилях: взаимно компенсирующиеся расхождения скрылись за небольшим итогом.

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

Для каждого расхождения нужна причина. Например, заказ появился после времени среза, загрузка задержалась, возврат учтен только с одной стороны, два профиля объединили. Неизвестные причины оставьте отдельной строкой. По результатам получится задание разработчику или аналитику с конкретными записями и ожидаемым правилом обработки. О передаче таких данных между системами подробнее написано в материале об интеграции сайта, CRM и 1С.

Получатели могут устареть раньше письма

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

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

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

Восстановленный файл еще нужно сверить

28 октября Яндекс сообщил о восстановлении доступа к 96% данных на Диске. Компания уточнила, что доля доступных файлов у пользователей различается и восстановление продолжается. Это состояние на дату сообщения. Доступность конкретного рабочего архива сейчас нужно проверять отдельно.

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

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

Что сделать на этой неделе

1. Зафиксировать правила расчета и сверить состав одного сегмента по идентификаторам. Разобрать записи, которые есть только в одной системе, и расхождения внутри совпавших профилей.
2. Проверить актуальность списка перед отправкой: новые покупки, отписки, претензии и пересечения кампаний. Назначить человека, который подтверждает готовность аудитории.
3. Проверить восстановленные рабочие файлы и порядок их повторной загрузки. Сохранить исходники и список полей, которые импорт имеет право изменять.