RFM в GetCourse: требования к данным для аналитики. блог edtech

RFM‑анализ на GetCourse — это способ быстро понять, где ваш доход на самом деле «лежит» в базе, какие клиенты готовы купить повторно уже завтра, а где вы теряете деньги из‑за хаоса в статусах, таймзонах и дублях. Ниже — полноценная пошаговая карта: от требований к данным и выгрузок до контроля качества и расчёта сегментов. На её основе вы сможете запустить RFM в своём аккаунте, проверить целостность связок «заявка → заказ → платёж», настроить регулярную выгрузку и перевести сегменты в практические кампании — апсейлы, реактивации и удержание. Если внутри уже есть BI, подключите к нему согласованные выгрузки и используйте сквозные отчёты; если BI нет — начните с базовых выгрузок и аккуратного словаря полей.

Для управленческой оценки результата рекомендую сразу заложить опорные витрины и отчёты: зафиксируйте дату отсечения, единую таймзону, валюту отчёта и регламент обработки возвратов/чарджбэков. Это позволит сопоставлять периоды и видеть динамику сегментов, а не получать «разовые картинки». Если команде важно понимать вклад каналов и писем в продажи, добавьте UTM и теги в конвейер — так RFM станет не просто сегментацией, а инструментом, завязанным на фактическую сквозную аналитику.

Работу по RFM удобно делить на три уровня: данные (что и как выгружаем), расчёты (как считаем R, F, M и на каких правилах) и действие (как используем сегменты в кампаниях). В этой статье фокус — на данных и процессе, чтобы расчёты были воспроизводимы, а результаты — устойчивы при повторении.

План статьи:

Контекст и рамка: RFM в экосистеме GetCourse и требования к данным
Типовые риски и способы их предотвратить
Где взять данные в GetCourse: платежи, заявки и сегменты для RFM
Настройка выгрузок: поля, фильтры и форматы для RFM в GetCourse
Теги и метки в GetCourse: нормализация и использование в подготовке данных
Контроль выгрузки и минимальный набор показателей для RFM

Контекст и рамка: RFM в экосистеме GetCourse и требования к данным

Зачем RFM онлайн‑школе: краткая цель и ожидаемые результаты

RFM‑анализ сегментирует пользователей по трем измерениям: давность последней оплаты, частота оплат и суммарная сумма платежей. Для онлайн‑школ это прямой способ найти «ядро» выручки, понять потенциал повторных покупок и вовремя заметить снижение активности до того, как появится отток. На практике RFM позволяет:

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

Результат — рабочие сегменты в разрезе актуальности, активности и вклада в выручку, привязанные к понятным бизнес‑действиям. Если добавить к ним отчётность по жизненной ценности и оттоку, управленческие решения станут заметно точнее — в том числе по метрикам LTV и сроку окупаемости каналов. Здесь помогает готовая аналитика продаж и писем, если она встроена в контур данных.

⚠️Преимущество:

RFM‑подход опирается на фактические оплаты: никакой «оценочной» лояльности, только измеряемые события, подтверждённые транзакциями.

Ключевые определения: Recency, Frequency, Monetary в терминах оплат

Recency (давность) — число дней с момента последней успешной оплаты пользователя до даты отсечения. Чем меньше значение, тем «свежее» платёж и выше вероятность ответа на предложение здесь и сейчас.

Frequency (частота) — количество успешных оплат за выбранный период. Метрика отражает привычку покупать повторно и помогает отличить «одиночный» чек от клиента, склонного к серийным покупкам.

Monetary (сумма) — общий объём денег, внесённый пользователем за период. В многовалютных проектах суммы приводят к валюте отчёта на дату платежа по выбранному курсу.

В GetCourse расчеты базируются на платежах со статусами, подтверждающими успех. Никакие «ожидания», «тесты» и «возвраты» в чистый RFM не попадают.

Сущности данных GetCourse: Пользователь, Заказ, Платёж, Продукт, Сегмент, Тег

Пользователь — основной объект аналитики с уникальным идентификатором (user_id). К нему привязаны заказы и платежи.

Заказ — намерение купить продукт; может содержать несколько платежей. Статус показывает состояние сделки.

Платёж — факт денежного поступления. Именно платёж с успешным статусом попадает в расчёт RFM.

Продукт — курс, программа или иная единица продажи.

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

Тег — маркер для классификации пользователей, заказов, платежей или источников.

Разница между «заказом» и «платежом» принципиальна: заказ фиксирует факт сделки как процесс, а платёж — денежное событие, которое и определяет RFM.

Единица анализа и связка сущностей: на уровне пользователя

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

Границы и допущения: рассрочки, возвраты, нулевые чеки, мультивалюта

Рассрочка — каждый успешный взнос учитывается как отдельный платёж, если внутренним регламентом не задано иное. Это влияет на Frequency и Monetary, но не надо «склеивать» взносы в единый чек, пока правила проекта не требуют обратного.

Возвраты и чарджбэки — полностью исключаются из F и M. Если возврат относится к уже учтённой оплате, запись компенсируется.

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

Мультивалюта — обязательна фиксация исходной и целевой валюты и курса конвертации на дату платежа.

Требования к качеству данных: полнота, статусы, таймзоны, идентификаторы

Ключевые критерии качества набора для RFM:

уникальные user_id (для объединения дублей подготовьте правила сопоставления email/телефона);
корректные статусы платежей с явной маркировкой успешных транзакций;
даты в единой таймзоне проекта;
суммы нормализованы к валюте отчёта и хранят исходную валюту для проверки;
контактные данные не обязательны для расчётов, но важны для коммуникаций и последующих кампаний;
словарь полей и схемы выгрузок храните в одном месте, чтобы расчёты были повторяемыми.

Для управленцев полезно видеть RFM‑результаты на одном экране: в помощь подойдут компактные дашборды с сегментами и динамикой — отобразите «рецентность» и «частоту» в виде матрицы, а рядом — ключевые метрики LTV и оттока по кварталам.

Высокоуровневый процесс подготовки набора под RFM

Проведите инвентаризацию источников: платежи, заказы и пользователи в GetCourse, плюс дополнительные кассы/интеграции, если они есть.

Сформируйте выгрузку всех успешных платежей с привязкой к user_id и метаданным (дата, сумма, валюта, статус, идентификаторы).

Нормализуйте даты и валюты; удалите тестовые и возвратные операции; зафиксируйте правила учёта рассрочек.

Проверьте полноту и уникальность: нет ли дублей по платежам, нет ли «висячих» заказов без платежей.

Подготовьте агрегаты R, F, M по каждому пользователю; сохраните словарь метрик и формулы.

📖Совет:

Сразу задайте «дату отсечения» и включайте её в имя файла выгрузки — это дисциплинирует версионирование и экономит часы при перепроверке.

Заказать Monitor Analytics →

Типовые риски и способы их предотвратить

Большинство ошибок в RFM‑наборе — не математические, а организационные. Выгрузки собирают вручную, статусы трактуют по‑разному, возвраты попадают в набор спустя недели — в результате RFM «пляшет» от отчёта к отчёту. Ниже — контрольные точки, которые уберегут от искажений.

Дубли пользователей. Если регистрируются с разными email и телефонами, а платят через разные кассы, один человек превращается в несколько user_id. Для начала настройте автоматическое объединение дублей по правилам: одинаковый телефон приоритетнее email, добавьте проверку по ФИО и дате рождения (если есть). Для спорных кейсов заведите ручной журнал слияний, чтобы затем воспроизвести фильтры и решения.

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

Несоответствие статусов. Разные подразделения по‑разному понимают «оплачен», «зачислен», «успешно». На уровне RFM допустим только однозначный признак «успешной транзакции». Все промежуточные состояния переводите в сквозной статус‑мэппинг и сохраняйте его в словаре.

Ошибки с таймзоной. Если касса и GetCourse работают в разных поясах, сравнение дня‑к‑дню будет «уезжать». Зафиксируйте единую таймзону проекта и приводите к ней все даты платежей. В имени файла выгрузки тоже отметьте таймзону, чтобы аналитики не гадали, почему «31 декабря» превращается в «1 января».

Конвертация валют. Нельзя оставлять расчётный курс «где‑то в комментариях». Зафиксируйте таблицу курсов на дату платежа и прикладывайте её к выгрузке. При спорных возвратах восстанавливайте сумму в валюте отчёта исходя из курса той даты, когда произошёл исходный платёж.

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

❓Важно:

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

Где взять данные в GetCourse: платежи, заявки и сегменты для RFM

Источники: разделы Продажи (Заказы/Платежи), CRM (Заявки), Пользователи (Сегменты)

В GetCourse опорные данные для RFM расположены в трёх разделах: «Продажи», «CRM» и «Пользователи». В «Продажи» сосредоточены «Заказы» и «Платежи» — именно платежи дают Monetary и Frequency. «CRM/Заявки» пригодится для контроля воронки и проверки, что у оплаченных заявок есть соответствующие заказы. «Пользователи/Сегменты» — инструмент отбора по заданным условиям, где удобнее всего фиксировать принадлежность к группам для будущих кампаний.

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

Роли источников: какие поля несут и для чего в RFM

Платежи — источник сумм и частоты. Обязателен набор: payment_id, user_id, дата и время, сумма, валюта, статус.

Заказы — связка пользователя и продукта с историей изменений. Нужны для валидации и для понимания, «какая» покупка стояла за платежом.

Заявки — полезны для контроля «улившихся» лидов и воронки, но в «чистый» RFM не входят. Они помогают найти системные проблемы, когда заказов много, а платежей мало.

Сегменты — создавайте технические группы («успешные плательщики за период», «все пользователи c F≥2») и экспортируйте их, чтобы быстро сверять расчёты и запускать рассылки. Когда эти сегменты начнут жить в вашей системе, проще наладить повторные продажи из базы с измеримым результатом.

Ключевые идентификаторы: user_id, email, телефон; order_id; payment_id

В связке «пользователь → заказ → платёж» критичны стабильные идентификаторы: user_id на стороне GetCourse, order_id для заказа и payment_id для платежа. Email и телефон — контакты, но они же «мосты» для поиска дублей. Один пользователь может иметь несколько заказов и много платежей; задача RFM — агрегировать их на уровне user_id, не потеряв ни одной транзакции и не задвоив суммы.

Статусы и фильтры: оплата, отмена, возврат, чарджбэк, тестовые операции

В «Платежах» учитываются только статусы, подтверждающие успешную оплату. Все «ошибка», «возврат», «чарджбэк», «отмена», «тест», «ожидание» исключаются. Похожий принцип действует в «Заказах»: интересны только завершённые, оплаченные статусы. Такой отбор убирает шум и делает RFM сопоставимым между периодами.

Особые кейсы: рассрочки и повторные списания, нулевые чеки, купоны

Рассрочка представлена несколькими платежами по одному заказу. Можно учитывать всю сумму по мере поступления взносов или только полные закрытые заказы — решайте регламентом и фиксируйте его в словаре. Повторные списания (например, подписка) — отдельные платежи; нулевые чеки и подарочные купоны не несут значения для Monetary и обычно исключаются. Если купоны влияют на поведение, сохраните их как теги источника, но не как денежные транзакции.

Сегменты пользователей: как фиксировать принадлежность к сегменту

В GetCourse сегмент — динамическая группа по условиям. Для RFM удобно создавать сегменты‑черновики (например, «Оплачивали последние 30 дней», «Имеют ≥2 платежей за 6 месяцев»). Экспорт таких списков позволяет сверить результаты собственных расчётов и быстро запустить рассылки по каждой группе.

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

Проверьте, что у каждой оплаченной заявки есть заказ и подтверждённый платёж. Отдельно найдите «висячие» заказы без платежей и заявки без заказов. Эти списки — индикатор дисциплины команды и корректности интеграций. Только при сквозной целостности RFM будет отражать реальное поведение клиентов, а не артефакты CRM.

Локальный вывод: готовность к настройке выгрузок

Данные для RFM в GetCourse собраны, источники понятны, статусы отфильтрованы, особые кейсы (рассрочки, нулевые чеки) оговорены. Следующий шаг — настроить выгрузки: определить состав полей, формат, валидации и регламенты.

Настройка выгрузок: поля, фильтры и форматы для RFM в GetCourse

Подготовка шаблона: минимальный перечень полей для платежей и пользователей

Базовый шаблон под RFM включает:

payment_id — уникальный идентификатор платежа;
user_id — ключ для агрегации на уровне пользователя; при отсутствии — email (с оговоркой о дублях);
дата и время платежа — для расчёта Recency;
сумма платежа — для Monetary;
валюта — исходная и целевая, если используете конвертацию;
статус оплаты — must have для фильтрации успешных транзакций.

Дополнительные поля: источник платежа (UTM/тег), способ оплаты, комментарий администратора. Эти поля пригодятся для управленческих срезов и проверки влияния кампаний и писем через аналитику продаж и писем.

Выгрузка платежей: фильтры по статусам, датам, валютам; кодировка и разделители

При формировании отчёта по платежам задайте фильтры:

статусы — только «успешно/оплачено»;
дата отсечения — по день включительно (например, 2023‑12‑31);
валюта — выгружайте все с кодом ISO; допускается отдельная выгрузка по каждой валюте;
исключения — тестовые, возвратные, отклонённые платежи.

Формат — CSV, кодировка UTF‑8, разделитель — запятая или точка с запятой (ориентируйтесь на настройки аккаунта). Даты — в формате YYYY‑MM‑DD или ISO 8601 с временем; числовые значения — десятичная точка. Сразу проверьте, что локальные настройки Excel/Google Sheets не ломают формат при открытии.

Выгрузка заказов и заявок: зачем и когда нужны для валидации

Заказы выгружаются для сверки статусов и контроля соответствия платежей: order_id, user_id, статус, дата создания, привязанные платежи (если доступны). Заявки — для оценки воронки и качества лидов: сколько заявок дошло до заказов и затем до платежей. В RFM они не участвуют напрямую, но помогают быстро найти «узкие места» в процессе продаж.

Экспорт сегментов пользователей: фиксация принадлежности к сегментам

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

Когда использовать API: типовые сценарии, ключевые объекты и лимиты

API GetCourse пригоден, когда объём данных велик, выгрузка регулярно повторяется или нужно интегрировать набор в внешнюю систему. Используйте эндпойнты payments, orders, users, segments, помните о лимитах на размер ответа и частоте запросов. Реализуйте пагинацию и сохраняйте курсор/параметры запроса. Формат — JSON; авторизация — по токену/ключу. При регулярных задачах автоматизируйте запуск и логируйте объём, длительность и коды ответов.

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

Контроль выгрузки включает:

приведение дат к таймзоне аккаунта;
устранение дублей по payment_id и user_id;
фильтрацию тестовых и возвратных платежей;
сверку сумм по валютам, контроль «расхождений» между источниками;
фиксацию курса конвертации и даты, к которой он относится.

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

Организация версий и хранение файлов: наименование, дата отсечения, безопасность

Давайте выгрузкам осмысленные имена: payments_2023‑12‑31.csv, orders_2023‑12‑31.csv. Ведите журнал изменений шаблона: какие поля добавлялись/удалялись, когда и зачем. Храните оригиналы в защищённых папках с резервным копированием и ограниченным доступом. Любая обработка персональных данных — только в соответствии с политиками безопасности компании.

🚨Пример:

В корне проекта хранится «Словарь полей RFM v1.4» и «Регламент конвертации валют v2.0». Каждая выгрузка содержит ссылку на актуальную версию словаря в шапке файла.

Локальный вывод: получаем воспроизводимую процедуру выгрузок

Шаблон полей определён, фильтры выставлены, форматы согласованы, контроль качества описан, API при необходимости подключён. Это значит, что у вас воспроизводимая и проверяемая процедура выгрузки данных под RFM.

Заказать Monitor Analytics →

Теги и метки в GetCourse: нормализация и использование в подготовке данных

Какие бывают теги и метки: пользовательские, заказов/платежей, источников

Теги помогают объяснить «почему» за деньгами стоят определённые события. Пользовательские теги — характеристики клиента (например, «vip»), теги заказов и платежей — этапы и способы оплаты, теги источников — атрибуция рекламных кампаний и форм регистрации. Для RFM это важный контекст, который позволяет строить срезы и связывать поведение с каналами и офферами.

Как присваиваются: ручные действия и автоматизации, типовые сценарии

Теги можно ставить вручную (исключения, особые случаи) и автоматически (правила, интеграции, формы). Сценарии: присвоить тег участникам вебинара, отметить тех, кто оплатил через конкретную кассу, зафиксировать кампанию по UTM. Чем прозрачнее и строже правила присвоения, тем меньше шума в выборках.

Нейминг и иерархии: соглашения, префиксы, версия справочника тегов

Введите префиксы и машиночитаемый формат: usr_, order_, pay_, utm_. Пишите в нижнем регистре, без пробелов, с осмысленными суффиксами: utm_google, order_fail. Ведите «Справочник тегов» — кто создал, когда, зачем, статус актуальности. Это избавляет от нескончаемых «webinar/Webinar/Вебинар» и сокращает расшифровку для аналитиков.

Нормализация и очистка: регистр, синонимы, стоп‑теги, дедупликация

Раз в месяц нормализуйте теги: приводите к нижнему регистру, удаляйте лишние символы, заменяйте синонимы, запрещайте стоп‑теги («test», «example»), устраняйте дубли. Дедупликацию можно выполнять при экспорте — если у объекта несколько синонимов, сохраняется только один базовый по справочнику.

Атрибуция источников и исключения сегментов на основе тегов

Соберите карту соответствия UTM → внутренние теги. Это понадобится для очистки обучающих наборов: вы быстро отфильтруете «staff», «test», «internal», а также отделите кампании друг от друга. Когда потребуется отдельный запуск по конкретной группе, теги станут «переключателями» сценариев. Например, можно точечно запустить игровые акции на сегмент «дремлющих» клиентов, чтобы мягко вернуть внимание к продукту без бесконечных скидок.

Контроль качества тегирования: проверочные отчёты и частота аудита

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

Подготовка справочника тегов: поля, хранение, ответственные

Базовые поля: имя тега, назначение, статус, префикс, дата создания, комментарий, ответственный. Храните справочник там же, где словарь полей по RFM, с контролем прав и версии. Ответственный — дата‑аналитик или менеджер продукта — фиксирует любые правки и пометки по кейсам.

Локальный вывод: чистые теги как усилитель RFM

Нормализованные теги уменьшают шум, делают сегментацию точнее и ускоряют дальнейшие действия. Когда теги поддерживаются в актуальном состоянии, кампании запускаются быстрее, а объяснение «почему сегмент вырос» перестаёт быть гаданием.

Запустить игровую акцию →

Контроль выгрузки и минимальный набор показателей для RFM

Контрольные проверки: дубликаты пользователей, неполные контакты, статусы оплат

Перед расчётом RFM выполните базовые проверки:

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

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

Возвраты, чарджбэки и тестовые записи: правила исключения

Возвраты и чарджбэки исключаются из F и M. Если возврат пришёл после отчётной даты, в следующей итерации он уменьшит Monetary, а Frequency — на единицу, если транзакция была единственной. Тестовые транзакции отсеивайте фильтром по статусам и тегам. Для проверки полезно держать небольшой «чёрный список» payment_id, который всегда исключается при повторных расчётах.

Таймзоны и дата отсечения: единые договорённости для проекта

Выберите одну таймзону для проекта (например, Europe/Moscow) и приводите к ней все даты. Дату отсечения фиксируйте в имени выгрузок и в шапке отчёта. Это избавит от постоянных споров «кто что считал» и позволит сравнивать период к периоду без ручной подгонки. Для исторической отчётности сформируйте линейку дат отсечения (например, последняя дата каждого месяца) и придерживайтесь её.

Мультивалюта: конвертация и валюта отчёта

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

Минимальный состав полей: идентификаторы, даты, суммы, статус, валюта

Для каждого платежа в наборе должны присутствовать: user_id, дата и время, сумма (в валюте отчёта), статус (успешно), признак возврата/чарджбэка/теста, валюта исходная и целевая, order_id для трассировки мультизаказных клиентов. Это «скелет» набора, без которого расчёт RFM будет шатким.

Вычисляемые метрики: recency_days, frequency_count, monetary_amount

Recency — число дней между датой отсечения и датой последнего успешного платежа пользователя.
Frequency — количество успешных платежей пользователя в заданном окне (например, 6 или 12 месяцев).
Monetary — сумма успешных платежей за период в валюте отчёта.

Важный нюанс: определите период расчёта (роллинг‑окно) и закрепите его в регламенте. Например, RFM за 12 месяцев с датой отсечения на 31.12.2023. Тогда два специалиста, повторивших расчёт, получат одинаковые результаты.

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

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

Локальный вывод: готовность набора к расчёту RFM

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

Построить отдел работы с базой →

Конкретные шаги: как запустить RFM на GetCourse за 10 дней

День 1–2. Инвентаризация и регламенты

Уточните, какие кассы и интеграции у вас есть; соберите список источников платежей.
Зафиксируйте: таймзону, валюту отчёта, курс конвертации, правила по рассрочке, возвратам, нулевым чекам.
Составьте словарь полей и чек‑лист контроля выгрузок.

День 3–4. Выгрузка и очистка

В «Продажи → Платежи» выгрузите платежи со статусом «успешно/оплачено» за период (например, 12 месяцев), исключив «тест», «возврат», «чарджбэк».
Приведите даты к единой таймзоне; конвертируйте суммы к валюте отчёта, зафиксируйте курс в таблице.
Удалите дубли по payment_id; отметьте спорные записи и вернитесь к кассе за разъяснениями.

День 5. Связки и валидация

Выгрузите «Продажи → Заказы», сопоставьте order_id с платежами, проверьте «висячие» заказы.
Выгрузите «Пользователи → Сегменты» (технические), чтобы сверить позднее попадание пользователей в RFM‑группы.

День 6–7. Расчёт RFM

Для каждого user_id рассчитайте: дату последнего платежа, сумму и количество платежей за период.
Посчитайте recency_days, frequency_count, monetary_amount. Разбейте каждую метрику на квантильные группы (например, 1–5) — получите классическую RFM‑матрицу.

День 8. Проверки и визуализация

Сверьте агрегаты с отчётами кассы и управленческой отчётностью.
Соберите компактные графики: распределение клиентов по R, F, M; вклад групп в выручку; динамика за кварталы. Для этого подойдёт готовая сквозная аналитика, если она уже развернута.

День 9–10. Сегменты и сценарии

Сформируйте сегменты в GetCourse по правилам RFM (например, «R5F4‑5M3‑5» — «самые ценные и активные», «R1‑2F1M1‑2» — «на грани оттока»).
Настройте первые сценарии: реактивация «холодных», апсейлы «тёплым», кросс‑селл «лояльным». Для вовлечения «дремлющих» и увеличения конверсии можно использовать мягкие механики — квизы, челленджи и геймификацию воронки.

Как применять RFM в работе школы: от сегмента к действию

Апсейлы и кросс‑селлы. Сегменты с высокой F и M готовы к расширению пакета: дополнительные модули, клуб, продвинутые тарифы. Запустите аккуратную систему апсейлов, которая предлагает релевантные продукты без навязчивости.

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

Витрины для руководителя. Соберите простые виджеты: «вклад топ‑сегментов в выручку», «доля клиентов с F≥2», «доля оттока по кварталам». Эти экраны удобно держать в дашбордах для руководителя, чтобы видеть эффект кампаний на уровне сегментов.

Почему стоит привлечь эксперта

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

Частые вопросы команды и короткие ответы

— Как выбрать окно для RFM?
Выберите период, соответствующий вашему циклу покупок: для курсов с длительными программами — 12 месяцев, для подписок — 6 месяцев. Главное — закрепите выбор в регламенте.

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

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

— Как разбивать на уровни R, F, M?
Классика — квантильная разбивка на 5 уровней по каждой метрике. Но допускаются пороговые значения, если поведение клиентов неоднородно. Главное — единообразие правил.

— Что делать с «очень большими чеками»?
Проверьте их валидность и решите, убирать ли как выбросы при визуализации. В расчёт Monetary они входят, но аналитические графики можно «обрезать» по перцентилям.

— Как не «сжечь» базу рассылками?
Коммуникация по сегментам должна иметь ценность: прогресс, бонус, новая программа, персональное предложение. RFM — это не повод «спамить», а инструмент точного тайминга и подбора офферов.

Мини‑чек‑лист перед запуском кампаний по RFM

Данные: выгрузки чистые, дублей нет, статусы согласованы, валюта унифицирована, таймзона одна.
Метрики: R, F, M рассчитаны по единым правилам, окно и дата отсечения зафиксированы.
Сегменты: правила сохранены, списки экспортированы в GetCourse и проверены на выборке.
Коммуникации: шаблоны писем и офферов готовы, сценарии активируются по условиям сегмента.
Измерение: назначены KPI и контрольные окна, настроена сквозная аналитика по продажам и письмам.

Финальная мысль

RFM — это дисциплина данных плюс простая, но сильная логика сегментации. Если аккуратно подготовить выгрузки и закрепить регламенты, вы получите устойчивую систему, которая показывает не только «кто купил вчера», но и «кто купит завтра». А дальше — дело техники: перевести сегменты в внятные сценарии и регулярно их измерять. В таких проектах помогает внешняя экспертиза: Артём Седов приходит не «ставить ещё один отчёт», а выстроить процессы, которые превращают цифры в управление — от RFM до понятных панелей и практичных апсейлов.