BigQuery для retention-маркетинга: почему событийная схема устарела

BigQuery для retention-маркетинга: почему событийная схема устарела

Последние полгода я всё чаще вижу одну и ту же ошибку в хранилищах маркетинговых команд. Событийная аналитика в BigQuery построена вокруг таблицы events с полями user_id, event_name, timestamp. В 2020-м этого хватало. Сейчас — нет.

Причина простая. Средний чек в e-com просел на 5–8%, ставка сместилась с первой покупки на удержание и жизненный цикл клиента. А жизненный цикл — это не цепочка событий, это набор состояний: онбординг, активация, привычка, отток, возврат. Событийная модель хранит факт клика, но не хранит контекст состояния. В результате каждый запрос «сколько пользователей в фазе привычки» превращается в пятиэтажный SQL с оконными функциями и костылями.

Что я предлагаю командам, с которыми работаю.

Первый шаг — добавить справочник user_states рядом с events. Ключ user_id, поля state, state_entered_at, state_exited_at, trigger_event. Обновление через MERGE по факту смены состояния. Так вы получаете срез «кто где сейчас» за секунды, а не за минуты.

Второй шаг — выделить таблицу transitions. Каждый переход состояние → состояние с метриками времени, источника, суммы. Это основа для расчёта вероятностей оттока и uplift-моделей (прогнозирования дополнительной конверсии).

Третий шаг — отказаться от BigQuery export из GA4 как единственного источника. Server-side атрибуция через GTM SS (серверный тег-менеджер) и CRM-события должны литься в ту же витрину, что и медийные данные. Иначе MMM (маркетинг-микс моделирование) и инкрементность считаются на неполной картине.

Главный тезис: событийная модель описывает действия, а retention-маркетинг в 2026-м требует описания состояний. Разница между ними — это разница между отчётом «что было» и ответом «что делать дальше».

— @BigQuery4MarketingPro