В этой задаче когортный анализ с ИИ — способ построить таблицу удержания и проверить её по событиям, а не повод сразу просить нейросеть назвать причину изменений. Сначала фиксируем, что считаем возвратом и к какой дате относим пользователя; числовую матрицу считаем отдельно и сверяем по ID. Ниже — полный учебный расчёт D1, D7 и D30 с двумя входными файлами, часовым поясом, датой среза и незрелыми окнами.
Определите удержание
В примере когорта — пользователи с одной местной календарной датой регистрации. Единица анализа — уникальный зарегистрированный пользователь, а возвратом считается только событие app_open. В справке Google Analytics критерий включения задаёт условие добавления пользователя в когорту, а критерий возврата — условие, при котором пользователь остаётся в ней. Справка Google Analytics о когортном исследовании
До загрузки данных выберите способ расчёта. В документации Amplitude Return On описывает возврат в конкретный день после стартового события. Документация Amplitude о режимах удержания Режим Return On or After учитывает возврат в день N или позже; для D7 это означает семь дней или более после первого использования. Документация Amplitude о режимах удержания
В примере выбран exact-day по календарным датам Europe/Moscow: D1 — календарный день после даты регистрации, D7 — через семь календарных дней, D30 — через тридцать. Это не скользящее окно в 24 часа. Return On or After тоже не означает возврат до дня N: в этом режиме учитывается день N или любой более поздний день. Наш расчёт — учебная таблица по указанным правилам, а не выгрузка или отчёт GA4 либо Amplitude.
Подготовьте два файла
Полный комплект со скриптом и контрольными файлами находится в ZIP-архиве. Отдельно доступны registrations.csv и events.csv. Первый файл задаёт пользователей и время регистрации, второй — события, пользователя, время события и его явный тип.
registrations.csv
user_id,registered_at
a,2026-01-01T09:00:00+03:00
b,2026-01-01T15:00:00+03:00
c,2026-02-28T22:30:00+00:00
d,2026-03-01T20:00:00+03:00
e,2026-03-08T21:30:00+00:00
f,2026-03-09T22:00:00+03:00
events.csv
event_id,user_id,occurred_at,event_type
1,a,2026-01-02T09:00:00+03:00,app_open
2,a,2026-01-08T10:00:00+03:00,app_open
2,a,2026-01-08T10:00:00+03:00,app_open
3,a,2026-01-08T12:00:00+03:00,app_open
4,b,2026-01-08T18:00:00+03:00,app_open
5,b,2026-01-31T10:00:00+03:00,app_open
6,c,2026-03-01T22:00:00+00:00,app_open
7,d,2026-03-02T20:00:00+03:00,app_open
8,c,2026-03-08T10:00:00+03:00,app_open
9,e,2026-03-10T09:00:00+03:00,app_open
10,x,2026-03-02T10:00:00+03:00,app_open
11,f,2026-03-11T10:00:00+03:00,app_open
12,d,2026-03-01T10:00:00+03:00,app_open
13,d,2026-03-08T11:00:00+03:00,pageview
Здесь все данные вымышлены. Время всех событий и регистраций содержит смещение часового пояса. Для расчёта зафиксированы правила:
- Перед определением даты переводить время регистрации и события в
Europe/Moscow. - Когорту определять по местной календарной дате регистрации; знаменатель — число уникальных пользователей, зарегистрированных в эту дату.
- Считать возвратом хотя бы один
app_openв целевую календарную дату. Несколько таких событий одного пользователя в один день дают одного пользователя в числителе. - Повторную строку с тем же
event_id, событие неизвестного пользователя, событие до регистрации и событие после среза исключать с указанием причины. - События с типом, отличным от
app_open, не считать возвратом. Поэтомуpageviewпользователяdсevent_id=13не входит в числитель. - Считать окно зрелым только после того, как целевые календарные сутки полностью завершились к моменту среза.
Срез — 2026-03-10T12:00:00+00:00, то есть 10 марта, 15:00 по Москве. Если переносить пример на рабочие данные, эти правила нужно подтвердить для конкретного продукта: например, определить событие возврата и часовой пояс отчёта.
Постройте матрицу
Для каждой зрелой ячейки формула одна:
удержание Dn = число уникальных пользователей когорты с хотя бы одним app_open в дату регистрации + N / число уникальных пользователей в когорте
Агенту можно поручить проверить структуру двух файлов, применить заранее заданные правила и собрать список исключений с ID и причинами — если ему действительно предоставлен доступ к файлам и среде исполнения. Числовые значения следует получать запуском скрипта, а не выдавать оценку языковой модели за выполненное вычисление. Человеку остаётся уточнить отсутствующие бизнес-правила и принять решения по исключениям, которые эти правила не покрывают; вручную перечитывать каждую корректную строку не требуется.
В учебном комплекте матрицу рассчитал локальный скрипт run.py, а девять контрольных ячеек сверены отдельным SQL-расчётом. Это не отчёт аналитического сервиса и не проверка возможностей какой-либо модели. Промпт ниже — предлагаемая инструкция для проверки и объяснения; его не запускали на модели. Без настроенного доступа к файлам и исполнению агент не может подтвердить их содержимое или запуск скрипта.
Работай только с файлами и результатами, к которым у тебя действительно настроен доступ. Если доступа нет, сообщи, что проверить содержимое файлов нельзя; не придумывай значения и не утверждай, что скрипт запускался.
Проверь структуру registrations.csv и events.csv. В registrations.csv ожидаются user_id и registered_at. В events.csv ожидаются event_id, user_id, occurred_at и event_type. Не додумывай отсутствующие поля или бизнес-правила.
Правила расчёта:
- часовой пояс Europe/Moscow;
- когорта — местная календарная дата регистрации;
- единица анализа — уникальный зарегистрированный пользователь;
- возврат — только event_type=app_open;
- окна — exact-day D1, D7 и D30 по календарным датам, не rolling;
- срез — 2026-03-10T12:00:00+00:00;
- окно зрелое, только если целевые календарные сутки полностью завершились к моменту среза.
Проверь повторные event_id, неизвестные user_id, события до регистрации и после среза, а также event_type, отличный от app_open. Для каждой исключённой строки укажи event_id и причину. Не считай pageview возвратом. Не принимай бизнес-решение, если заданные правила не определяют ответ.
Числовую матрицу получай запуском предоставленного скрипта, если исполнение доступно. Не подменяй выполнение оценкой языковой модели. Для каждой из девяти ячеек выведи дату когорты, день, список returned_users, числитель, знаменатель и статус окна. Сверь результат с expected_cohort.csv. expected-cohort.csv — прежнее совместимое имя эталона; cohort.csv — вычисленный результат. Если скрипт не запускался, прямо укажи это.
Сверь контрольные ячейки по составу пользователей и значениям. В незрелой ячейке оставь числитель и долю пустыми, а не записывай ноль. Если строки или правила не дают ответа, перечисли неопределённость и не заполняй её догадкой.
Не выводи причины различий между когортами и не смешивай удержание с LTV, RFM или атрибуцией.
Ниже — полный ожидаемый контроль. По нему можно проверить и состав пользователей, и каждую дробь. В комплекте expected_cohort.csv — контрольный эталон, expected-cohort.csv — сохранённое совместимое прежнее имя, а cohort.csv — вычисленный результат. Скрипт сравнивает результат с эталоном; если прежнее имя уже существует, комплект проверяет совпадение его содержимого с основным эталоном до копирования.
| Когорта регистрации | День | Вернувшиеся пользователи | Числитель | Знаменатель | Удержание | Статус окна |
|---|---|---|---|---|---|---|
| 2026-01-01 | D1 | a | 1 | 2 | 50% | зрелое |
| 2026-01-01 | D7 | a, b | 2 | 2 | 100% | зрелое |
| 2026-01-01 | D30 | b | 1 | 2 | 50% | зрелое |
| 2026-03-01 | D1 | c, d | 2 | 2 | 100% | зрелое |
| 2026-03-01 | D7 | c | 1 | 2 | 50% | зрелое |
| 2026-03-01 | D30 | — | неизвестен | 2 | неизвестно | незрелое |
| 2026-03-09 | D1 | — | неизвестен | 2 | неизвестно | незрелое |
| 2026-03-09 | D7 | — | неизвестен | 2 | неизвестно | незрелое |
| 2026-03-09 | D30 | — | неизвестен | 2 | неизвестно | незрелое |
Содержимое expected_cohort.csv:
cohort_date,day,denominator,numerator,retention,status,returned_users
2026-01-01,1,2,1,0.5,mature,a
2026-01-01,7,2,2,1.0,mature,a|b
2026-01-01,30,2,1,0.5,mature,b
2026-03-01,1,2,2,1.0,mature,c|d
2026-03-01,7,2,1,0.5,mature,c
2026-03-01,30,2,,,immature,
2026-03-09,1,2,,,immature,
2026-03-09,7,2,,,immature,
2026-03-09,30,2,,,immature,
В результате 6 пользователей, 3 когорты и 9 ячеек: 5 зрелых и 4 незрелые. В events.csv 14 строк; исключены 5 — повторная строка, событие неизвестного пользователя, событие после среза, событие до регистрации и событие неподходящего типа.
Сверьте ячейку D7
Процент не показывает, правильно ли отобраны пользователи. Сначала проверьте, кто вошёл в числитель, затем — числитель и знаменатель.
Когорта 2026-01-01, D7. В знаменателе a и b, всего 2 пользователя. Целевая дата — 8 января по Москве. У a есть события event_id=2 и event_id=3; повторная строка с event_id=2 не добавляет второго пользователя. У b есть event_id=4. В числителе a и b, то есть 2/2 = 100%.
Когорта 2026-03-01, D7. В знаменателе c и d, всего 2 пользователя. Целевая дата — 8 марта по Москве. У c есть подходящий app_open с event_id=8. У d есть pageview с event_id=13, но это событие не удовлетворяет правилу возврата. В числителе только c: 1/2 = 50%. Если ошибочно принять pageview за возврат, результат изменится на 2/2.
Часовой пояс меняет календарную дату события или регистрации. Регистрация c в 2026-02-28 22:30 UTC — это 1 марта, 01:30 по Москве, поэтому c входит в когорту 1 марта. Событие app_open с event_id=6 произошло 1 марта в 22:00 UTC, то есть 2 марта в 01:00 по Москве, и попало в D1.
У когорты 9 марта целевая дата D1 — 10 марта. Эти сутки заканчиваются 11 марта в 00:00 по Москве, уже после среза 10 марта в 15:00. Событие app_open пользователя e утром 10 марта не делает окно зрелым: числитель и доля пока неизвестны, а не равны нулю. По той же причине D30 когорты 1 марта на дату среза незрелый.
Полный список исключений из примера:
event_id,event_type,reason
2,app_open,duplicate_event
10,app_open,unknown_user
11,app_open,after_snapshot
12,app_open,before_registration
13,pageview,non_return_event
Учебный пример
Все бизнес-данные вымышлены. Код, файлы и вычисления выполнены локально; это не клиентский кейс, не выполненный полевой A/B-тест и не бенчмарк качества ИИ. Полный комплект со скриптом и контрольными файлами доступен в ZIP-архиве.
Ограничьте выводы
Матрица показывает долю пользователей, вернувшихся в выбранные календарные дни по заданному правилу. Разница между когортами сама по себе не доказывает причину. Возможное продуктовое объяснение — отдельная гипотеза; её нужно проверять отдельно подходящими данными, а не выводить из одной таблицы удержания.
Здесь рассчитано удержание по событиям. Не объединяйте его с LTV, RFM или атрибуцией: это другие вопросы, и эта матрица на них не отвечает. Для отдельного разбора данных можно открыть материал «Анализ маркетинговых данных с нейросетью», а для сегментации — «Сегментация клиентов с ИИ». Эти материалы не заменяют определение события, расчёт и проверку ячеек.
Для рабочих данных сначала согласуйте событие возврата, единицу анализа, часовой пояс и время среза. Затем зафиксируйте правила, поручите агенту проверить записи по ним, посчитать матрицу скриптом и вывести исключения. Сверьте контрольные ячейки по ID; спорные бизнес-правила оставьте на решение человека. Незрелые окна не заполняйте нулями — дождитесь завершения наблюдения.
Автор метода «Машиночитаемый маркетинг»