Выгрузили клиентскую базу, присвоили всем три цифры и получили десятки групп. А дальше хочется отправить скидку тем, кто давно не покупал. Здесь легко пропустить главное: человек мог приобрести товар в другом канале, его два аккаунта могли разойтись по разным сегментам, а повторная покупка могла состояться и без рассылки.
В Гуси-Лебеди предлагаем начинать RFM-анализ с конкретного вопроса: кому, зачем и какое предложение мы собираемся сделать? Затем подготовить историю покупок, рассчитать показатели и проверить действие. Ниже разберём весь путь на условном примере интернет-магазина. Цифры в примере придуманы для объяснения расчёта, это не результаты нашего проекта.
RFM-анализ группирует покупателей по трём признакам: Recency, давности последней покупки; Frequency, количеству покупок за выбранный период; Monetary, сумме покупок за этот период. Расшифровка помогает запомнить метод, но ценность появляется, когда определения совпадают с тем, что действительно хранится в вашей CRM.
Как подготовить данные для RFM-анализа
Начните с одной строки на покупку: идентификатор клиента, идентификатор заказа, дата, статус и сумма. После очистки из этих строк получится одна строка на клиента. Если выгрузка содержит позиции товара, три позиции одного заказа нельзя посчитать как три покупки. Если система повторно отправила событие оплаты, это тоже не новый заказ.
Для нашего условного магазина будем учитывать завершённые оплаченные заказы. Полностью отменённые продажи исключим, частичные возвраты вычтем из суммы соответствующего заказа. Это правило примера, его нужно согласовать с устройством вашего учёта. Сохраните исходную выгрузку и отдельно результат очистки, чтобы любую итоговую сумму можно было проверить по заказам.
Один покупатель должен иметь один устойчивый идентификатор. Совпадение имени само по себе не доказывает, что это один человек. Общий телефон семьи тоже может объединить разных покупателей. Используйте правила идентификации из своей системы и отмечайте спорные объединения, а не склеивайте записи автоматически по первому похожему полю.
Зафиксируйте дату расчёта и окно истории. Например, анализируем завершённые покупки с 1 июля по 30 сентября 2026 года включительно, расчёт делаем на 1 октября. Для данных со временем нужен ещё единый часовой пояс. Не меняйте период между клиентами или между показателями без отдельного объяснения.
Сверьте итог очищенной выгрузки с отчётом продаж за тот же период и по тем же статусам. Расхождение требует проверки: могут отличаться правила возвратов, дата события или доступность каналов. Если офлайн-продажи не попали в выгрузку, сегмент означает «давно не покупал в доступной нам истории», а не «перестал покупать вообще».
Лиды без покупок стоит выделить отдельно. У них нет даты последней покупки, поэтому нулевая давность была бы неверной: ноль дней означает покупку сегодня. Когда отчёты расходятся из-за передачи данных, сначала разберите интеграцию CRM с сайтом, а затем стройте сегменты.
Как рассчитать Recency, Frequency и Monetary: пример
Для каждого клиента найдите последнюю учитываемую покупку, посчитайте уникальные заказы и сложите их суммы. В нашем примере R измеряется в календарных днях между 1 октября и датой последней покупки. F и M считаются внутри одного окна с июля по сентябрь.
| Клиент | Последняя покупка | R, дней | F, заказов | M, рублей |
|---|---|---|---|---|
| А | 28 сентября | 3 | 4 | 12 000 |
| Б | 2 августа | 60 | 2 | 7 000 |
| В | 30 сентября | 1 | 1 | 3 000 |
Допустим, клиент Б оформил в этом окне заказы на 4 000 и 5 000 рублей, а по второму вернул товары на 2 000 рублей. При согласованном выше правиле M равен 4 000 + 5 000 - 2 000 = 7 000 рублей. F остаётся равным двум: частичный возврат скорректировал сумму, а не создал дополнительную покупку.
В Excel, если фиксированная дата расчёта стоит в C2, а дата последней покупки в B2, разность =C2-B2 даст число дней. Ячейки должны содержать настоящие даты, а результат нужно показывать числом. Для воспроизводимого отчёта сохраните дату расчёта: функция текущей даты будет менять R при каждом открытии файла.
В демопримере Loginom также сначала группируют покупки по клиенту, затем рассчитывают давность и присваивают категории. Конкретные пороги там относятся к демонстрации. Переносить их суммы и сроки в свой магазин без проверки не стоит.
Monetary не равно прибыли. Клиент с большой суммой покупок может приобретать товары с небольшой маржой или требовать дорогого обслуживания. Для решения о скидке дополнительно нужны затраты и экономика предложения. Как отдельно считать ценность клиента во времени, объясняем в статье о расчёте LTV.
У клиента В всего один заказ, но это может быть новая покупка нового клиента. У покупателя, пришедшего вчера, ещё не было тех же трёх месяцев для повторных заказов, что у давнего клиента. Перед сравнением проверьте дату первой покупки: иногда новым покупателям нужна отдельная группа и сценарий знакомства с магазином.
Как выбрать границы и не запутаться в RFM-сегментах
Сырые значения R, F и M уже позволяют увидеть различия. Баллы нужны для удобства работы, а не для придания отчёту научного вида. Можно выбрать пороги, соответствующие циклу покупки, или разделить базу по квантилям, то есть по положению покупателей в распределении значений. Во втором случае группы описывают клиентов относительно друг друга.
Сначала определите направление шкалы. Здесь договоримся: 3 означает более недавнюю покупку, больше заказов или большую сумму. Для R это меньшее число дней; для F и M, наоборот, большее значение. В других источниках встречается обратная нумерация. Код 111 нельзя понимать как «лучших» или «худших» клиентов без словаря конкретного отчёта.
Для объяснения зададим следующие условные пороги: R до 7 дней включительно получает 3, от 8 до 30 получает 2, больше 30 получает 1. F от 4 заказов получает 3, от 2 до 3 получает 2, один заказ получает 1. M от 10 000 рублей получает 3, от 5 000 до суммы меньше 10 000 получает 2, меньше 5 000 получает 1. Эти границы не рекомендуются как норма: они выбраны только для нашего примера.
Тогда у клиента А код 333, у Б код 122, у В код 311. А покупал недавно, несколько раз и на большую сумму внутри выбранного окна. Б покупал раньше, дважды, на среднюю по нашей шкале сумму. В купил недавно один раз. Код описывает историю, но не доказывает лояльность, причину перерыва или готовность купить снова.
Три оценки по трём признакам дают 3 × 3 × 3 = 27 возможных кодов. Не обязательно заполнять все 27 ячеек и создавать 27 рассылок. Можно объединить подходящие коды в несколько рабочих групп: недавние повторные покупатели, новые покупатели, давние покупатели с несколькими заказами. Для каждой сохраните точное правило попадания.
Квантили тоже не снимают вопросы. Когда большинство людей купили один раз, одинаковые значения F могут попасть на границу. Заранее задайте правило работы с совпадениями. Если вся база давно не покупала, её «самая недавняя» треть всё равно не обязательно активна по меркам вашего бизнеса.
Не смешивайте RFM с ABC-анализом: в ABC обычно ранжируют объекты по выбранному вкладу и группируют их по накопленной доле. RFM одновременно описывает три стороны покупательской истории. Для выбора следующего действия полезны обе модели, но обозначения отвечают на разные вопросы.
Как проверить, помогает ли работа с сегментом
Возьмём группу вроде клиента Б: раньше было несколько покупок, последняя давно. Возможная гипотеза: напоминание о подходящих расходных материалах поможет вернуться. Но сначала проверьте историю товаров, их наличие и пригодность предложения. Не стоит автоматически выдавать скидку каждому с низким R.
Для недавнего первого покупателя может быть полезнее помощь с использованием товара. Для постоянного покупателя можно проверить уведомление о наличии привычного товара. А если человек обратился с нерешённой проблемой, задача поддержки важнее новой продажи. Это варианты для проверки, а не готовый рецепт успешной рассылки.
- Сохраните состав сегмента на момент запуска и правило его отбора.
- Сформулируйте одно предложение, доступное участникам, и проверяемую цель.
- Если размер базы и условия позволяют, случайно разделите сопоставимых участников на группу сообщения и контроль без этой коммуникации.
- Выберите одинаковое окно наблюдения для обеих групп и считайте покупки, возвраты, затраты на предложение и отписки.
- Сравните результат с учётом размера групп и неопределённости, прежде чем распространять действие на всю базу.
Если после письма появились заказы, это ещё не показывает, сколько заказов добавило письмо. Покупатели из контрольной группы тоже могут вернуться сами. Разная численность групп требует сравнения долей, а не только количества заказов. На нескольких наблюдениях нельзя уверенно объявить победителя по небольшому отличию.
Предположим, скидка увеличила число покупок, но уменьшила вклад после затрат. Для бизнеса это другой результат, чем просто рост конверсии. Поэтому заранее выберите, какое решение примете по итогам: продолжить предложение, поменять его или остановить. Не подбирайте удобный показатель уже после просмотра результата.
В разборе Mindbox показаны разные коммуникации с RFM-группами. Для собственного запуска важно дополнить сценарий проверкой условий контакта, исключением отказавшихся от сообщений и защитой от повторной отправки. Организацию таких цепочек рассматриваем в материале об автоматизации маркетинга.
RFM стоит обновлять с частотой, полезной для вашего цикла покупки. Зафиксируйте период пересчёта и версию порогов: иначе изменение доли сегмента можно ошибочно объяснить поведением клиентов, хотя поменялись правила. Метод менее полезен там, где повторных покупок почти нет или история короткая. Универсального минимального числа клиентов для всех задач мы здесь не задаём.
В Гуси-Лебеди предлагаем передавать в работу не только названия сегментов, но и выгрузку, словарь показателей, границы и план проверки. При настройке продвижения для разных групп покупателей это позволяет связывать сообщение с конкретной задачей и оценивать результат по продажам и затратам.