Когортный анализ требует неизменной даты первого события: агенты сохраняют историю для сравнения

Представим клиента, который впервые заплатил 12 июня 2026 года, а затем продлил подписку 12 июля. В модели по первой оплате он остаётся в июньской когорте. Июльская оплата показывает, что июньский клиент продолжил платить; нового клиента в июле она не создаёт.

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

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

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

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

Для нашего примера выберем долю клиентов исходной группы, у которых была хотя бы одна успешная оплата в рассматриваемом календарном месяце. В числителе считаем клиентов, не количество платежей. Две оплаты одного клиента в июле не превращают его в двух удержанных клиентов.

Такой показатель описывает повторные оплаты. Он не равен доле клиентов с действующим доступом: годовой плательщик может иметь доступ без ежемесячных платежей. Если важно использование продукта, выберите содержательное действие в нём. Не соединяйте разные показатели в одну кривую под общей подписью. На старте онбординг нового пользователя проверяют по первому полезному действию, а не регистрации.

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

Ниже вымышленные данные: в июне впервые заплатили 100 клиентов, в июле 80, в августе 60. Срез включает события, известные системе до 1 октября 2026 года, 00:00 МСК, и только календарные месяцы, завершившиеся к этой границе. Это учебная матрица, не наши продажи.

В первом месяце после старта заплатили 60 из 100 июньских клиентов, 48 из 80 июльских и 36 из 60 августовских. Во всех трёх случаях получается 60%. Размеры групп различаются, а доля повторно заплативших одинакова. Во втором месяце у двух зрелых групп доля составляет 40%.

У августовской группы второй месяц приходится на октябрь и ещё не завершён. Здесь нельзя ставить 0%: отсутствие завершённого периода не доказывает отсутствие оплат. Календарный месяц также не равен интервалу в 30 суток от личной даты покупки. Если нужен такой интервал, его рассчитывают по другому правилу.

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

Нужно различать время события и время его получения. Оплата могла произойти в июне, а приехать в систему в июле. Для группы важен июнь; для повторения отчёта, построенного до получения этой записи, важно, что тогда система о ней ещё не знала.

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

Хранить историю не значит собирать в журнале все поля клиента навсегда. Идентификатора и нужных бизнес-фактов часто достаточно для расчёта; вопросы персональных данных при разработке разобраны отдельно. Полную архитектуру Event Sourcing внедрять ради одной таблицы необязательно: журнал нужных событий можно добавить в существующую базу.

Теперь условие «неизменная дата» можно уточнить. Продление и правка карточки не меняют первый факт. Но если пришла ранее неизвестная оплата с более ранней датой, старт нужно исправить. Объяснимое исправление создаёт новую версию отчёта; оно не должно молча подменять уже сохранённый результат.

В постановке задачи агентам зафиксируйте единицу клиента: человек, аккаунт или компания-плательщик. Затем событие старта, событие возврата, часовой пояс, границы периода и порядок учёта возвратов. Иначе агент сам заполнит пропуски правдоподобными решениями, которые могут не отвечать вашему вопросу.

Инженер ведёт машину агентов: они могут написать приём событий, сбор истории, распределение клиентов по группам и проверки. Бизнес выбирает смысл показателя. Проверяющий должен отдельно сверить результат на маленьком наборе событий, где ожидаемый ответ известен заранее.

Приёмка относится к ответственности за ошибки ИИ: правильная формула в коде ещё не подтверждает правильность исходных данных. Для повтора сохраните доступный набор входных событий, границу их приёма, версии правил и объединения клиентов. Повтор на той же версии обязан дать тот же результат; новая версия должна объяснять разницу.

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

При ревью 9 сентября 2026 года, до начала продаж, выяснилось: если отправка письма срывалась, повтор уведомления об оплате не запускал новую отправку. Доступ уже существовал, и обработчик делал вывод, что повторная работа не нужна. Для клиента эти вещи различаются: получить право доступа и получить письмо со ссылкой.

Отправку связали с журналом писем. Если успешной отправки нет, её можно повторить; если есть, повтор не создаёт лишнее письмо. По тому же ревью оплату связали с конкретным продуктом: само получение корректного уведомления ещё не доказывало покупку именно курса.

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

Разработка становится предметом заказа, когда события разбросаны по системам, исходная дата теряется, отчёт нужно обновлять регулярно или нельзя объяснить расхождение с прошлым месяцем. Если исторические события вовсе не сохранились, агенты не восстановят их по одному текущему статусу. Тогда обозначьте начало достоверного наблюдения.

Для следующего шага руководителю можно перейти к обсуждению проекта. На подписке на разработку «Один проект» инженер ведёт машину ИИ-агентов: она может собрать историю событий, распределение по когортам и проверку расчёта. Цена на 8 октября 2026 года составляет 250 000 ₽/мес. Это подписка на поток работы, а не отдельная цена когортного отчёта.

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

Закрепите выбранное первое событие. Продление дополняет историю, а не превращает старого клиента в нового.

Определите, что означает возврат клиента: оплата, действие в продукте или действующий доступ. Считайте клиентов отдельно от транзакций.

Сравнивайте одинаковый номер периода после старта. Не подменяйте незавершённый период нулём.

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