Анализ оттока с ИИ: событие, база и расчёт

Анализ оттока клиентов с ИИ начинается не с модели, а с определения события: что именно считаем уходом и кто попадает в базу. Ниже — рабочая последовательность для контрактного оттока, полный вымышленный журнал подписок, копируемый промпт и эталонный расчёт, с которым можно сверить ответ нейросети. Учебный пример не заменяет клиентский кейс: все записи придуманы, модель прогнозирования не обучалась, поэтому 50% из набора нельзя читать как рыночную норму.

ИИ здесь полезен на узком участке: превратить выгрузку подписок в проверяемую таблицу с явными ID числителя и знаменателя. Решение о границах периода и трактовке спорных записей остаётся за человеком, который знает бизнес-правила. GigaChat, по документации, работает с прикреплёнными файлами DOCX, PDF и TXT и принимает промпты на анализ текста (Работа с документами в ГигаЧат). Это про разбор текста, а не про готовый расчёт churn.

Определите событие оттока

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

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

Зафиксируйте базу и границы

Стартовая база — подписки, активные на начало периода. Период удобно брать полуоткрытым: [начало, конец). Тогда событие ровно в момент конца не попадает в числитель, а событие за миг до конца — попадает. Это не формальность: без закреплённой границы две команды получат разные проценты из одной таблицы.

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

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

Попросите ИИ подготовить проверяемую таблицу

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

Ты помогаешь посчитать контрактный отток стартовой базы подписок за период.

Период: [2026-01-01T00:00:00+03:00, 2026-02-01T00:00:00+03:00).
Правила:
- В стартовую базу входят подписки, у которых active_at_start = true.
- Событие оттока: ended_at внутри периода, то есть начало <= ended_at < конец.
- ended_at ровно на правой границе (2026-02-01T00:00:00+03:00) в числитель НЕ входит.
- Категории проверяются по порядку: сначала review (неизвестны started_at, active_at_start или segment), затем excluded_before_start (ended_at раньше начала периода), затем new_in_period (active_at_start = false, started_at внутри [начало, конец), не исключённые ранее), затем стартовая база (active_at_start = true). Первое совпадение фиксирует категорию.
- new_in_period считать отдельно, в знаменатель стартовой базы не добавлять.
- Для C ended_at = null допустим: подписка активна на старте, прекращение не зарегистрировано, остаётся в starting_ids и не входит в churn_ids.
- Никаких выводов о причинах ухода, вероятностях или нормах. Только арифметика по правилам.

Входные записи (id, segment, active_at_start, started_at, ended_at):
A, basic, true, 2025-12-01T00:00:00+03:00, 2026-01-10T12:00:00+03:00
B, pro, true, 2025-11-01T00:00:00+03:00, 2026-01-31T23:59:00+03:00
C, basic, true, 2025-10-01T00:00:00+03:00, null
D, pro, true, 2025-12-01T00:00:00+03:00, 2026-02-01T00:00:00+03:00
E, basic, false, 2026-01-05T00:00:00+03:00, 2026-01-25T00:00:00+03:00
F, pro, false, 2025-10-01T00:00:00+03:00, 2025-12-31T23:00:00+03:00
G, null, null, null, null

Верни строго такую схему:
1) starting_ids — список ID стартовой базы.
2) churn_ids — список ID из starting_ids с событием оттока.
3) numerator и denominator — числа, churn_percent = numerator/denominator*100 с одним знаком после запятой.
4) groups — для каждого segment из starting_ids: starting_ids, churn_ids, fraction вида "1/2", percent.
5) new_in_period, new_churned_in_period, excluded_before_start, review — списки ID.
6) boundary_case — короткое пояснение по записи, чья дата совпала с правой границей.
7) observation — сравнение групп только по посчитанному показателю.
8) not_established — что этот расчёт не доказывает.
Если какое-то поле нельзя определить по правилам, оставь его пустым и добавь ID в review. Не додумывай данные.

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

Учебный пример

Учебный пример

Ниже — полный вход и эталон, с которым сверяем ответ. Все записи вымышлены.

ID	Тариф	Активна на старте	Начало	Окончание	Куда попадает
A	basic	да	2025-12-01	2026-01-10 12:00	стартовая база, числитель
B	pro	да	2025-11-01	2026-01-31 23:59	стартовая база, числитель
C	basic	да	2025-10-01	—	стартовая база, осталась
D	pro	да	2025-12-01	2026-02-01 00:00	стартовая база, граница
E	basic	нет	2026-01-05	2026-01-25	новая за период
F	pro	нет	2025-10-01	2025-12-31 23:00	исключена до старта
G	—	—	—	—	review

Стартовая база — A, B, C, D: четыре подписки. Событие оттока внутри января — A и B. D закончилась ровно на правой границе и в январский числитель не входит. C осталась активной. Итого 2 из 4, то есть 50% по правилу расчёта. Это число описывает только этот учебный набор.

По группам: basic — A и C, ушла A, доля 1/2 и 50%. pro — B и D, ушёл B, доля 1/2 и 50%. E — новая подписка внутри периода, которая там же и закончилась; в знаменатель стартовой базы её не добавляем. F закончилась до начала периода и исключена. G без истории уходит в review и не считается ни активной, ни ушедшей.

По посчитанному показателю разницы между группами нет: обе дают 1/2. Из этого не следует, что тариф не влияет на удержание — при двух подписках в группе такой вывод не построить, а отсутствие различия ничего не доказывает в обратную сторону. Расчёт также не говорит о причинах ухода, вероятности уйти для конкретного клиента и о том, сработает ли какое-либо удержание.

Эталон результата для сверки:

starting_ids: A, B, C, D
churn_ids: A, B
numerator: 2
denominator: 4
churn_percent: 50.0
groups:
  basic — starting_ids: A, C; churn_ids: A; fraction: 1/2; percent: 50.0
  pro — starting_ids: B, D; churn_ids: B; fraction: 1/2; percent: 50.0
new_in_period: E
new_churned_in_period: E
excluded_before_start: F
review: G
boundary_case: D не входит в январский числитель: событие совпадает с исключённой правой границей.
observation: в обеих группах по одному прекращению из двух стартовых подписок; наблюдаемой разницы по заданному показателю нет.
not_established: причины ухода, вероятность ухода конкретного клиента, эффект коммуникаций, рыночная норма оттока.

Посчитайте отток и группы

Сверка идёт по спискам, а не по проценту. Сначала проверьте знаменатель: вошла ли каждая стартовая подписка и не попала ли туда новая. Затем числитель: каждая ли дата окончания внутри полуоткрытого окна. Отдельно пройдитесь по границе D и по review G — это места, где чаще всего расходятся ручной и машинный расчёт.

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

Для сравнения групп считаем долю в каждой отдельно, не общий процент по всем записям. Здесь получается по 1/2 в каждой, но сам расчёт доли по сегментам нужен, чтобы увидеть структуру, а не только итог.

Выберите следующую проверку

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

Эффект удержания проверяется отдельным экспериментом: группа получает воздействие, контрольная — нет, и сравнивается доля ушедших после этого. По одной доле из 2/4 вводить скидку или менять тариф рано: такой шаг не опирается на измеренный эффект.

Практический следующий шаг — повторить расчёт на своей выгрузке по тому же правилу и сохранить списки ID рядом с процентом. Если нужен более широкий разрез, когортный анализ и RFM отвечают на другие вопросы: первый показывает поведение групп по времени, второй — распределение клиентов по давности, частоте и деньгам (когортный анализ, RFM-сегментация). Их числитель и знаменатель отличаются от контрактного оттока, поэтому проценты из разных отчётов напрямую не сравниваем.