Почему в Amplitude я сначала настраиваю «правду о пользователе», а не воронки

Почему в Amplitude я сначала настраиваю «правду о пользователе», а не воронки

В командах, с которыми я работаю, чаще всего проблемы с аналитикой выглядят так: воронка “как будто” не бьётся, когорты «плывут», а retention считается «от разных людей» — и каждый раз под этим скрыта одна и та же причина. Мы смотрим на события так, как будто у пользователя есть одна-единственная идентичность. А в реальности у него их минимум две: “кто он” (account/профиль) и “как он меняет доступ” (device/session/логин).

В 2026-м это проявляется особенно больно, потому что:
— пользователи чаще используют разные устройства и контексты входа
— privacy-first подходы ухудшают точность last-click и усиливают важность server-side сопоставления
— AI-overviews в поиске поднимают требования к тому, чтобы наша внутренняя аналитика была непротиворечивой и пригодной для объяснения бизнесу

Моя позиция простая: **воронки и retention — это производные. Сначала я строю “правду о пользователе” в Amplitude**. Только после этого я начинаю думать, где именно “утекает” конверсия.

1) Сначала определяю, какая сущность в продукте “главная”
Я выбираю Primary Entity и фиксирую, что именно будем считать пользователем:
— пользователь как человек (persona)
— или пользователь как аккаунт (account)
— или пользователь как организация (B2B)

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

2) Правило тай-лайна: identity нужно чинить до бизнес-метрик
В Amplitude это обычно сводится к последовательности: user_id (или device_id) → смена статуса в момент логина → закрепление account_id/enterprise_id (если есть B2B-кейс).

Типичная ошибка, которую я вижу чаще всего:
— события “до логина” попадают в один user (device), а после логина начинают считаться как другой
— и в результате user превращается в два разных человека, а retention искусственно «проваливается»

Один раз на проекте по B2B-платформе мы нашли проблему за 40 минут: разница между “logins → activation” в дашборде и “logins → activation” в CRM была не в продукте, а в связке идентичностей. После корректной identity-цепочки конверсия от login к активации выросла не на проценты, а “в масштабах ожидания”: графики стали совпадать по форме, и бизнес наконец перестал спорить, где правда.

3) Проверяю “целостность ключа” по одному наблюдению
Я делаю небольшой контрольный тест, который обычно экономит часы:
— беру 1000 последних завершивших целевое действие (например, “FirstValueAchieved” / “Создано предложение”)
— и проверяю, сколько уникальных user_id/account_id стоит за этими событиями после нормализации

Если из 1000 “успешных” действий получается, условно, 1600 разных user_id — значит, у нас дробление идентичности. Если получается ровно — значит, можно строить воронки без ощущения, что мы меряем разные реальности.

4) И только потом строю воронки, но с оговорками
Когда identity “сшита”, я начинаю воронки. Но по привычке задаю себе вопросы:
— что именно считается входом в воронку: session, login, account creation?
— совпадает ли точка входа с точкой, где маркетинг/продажи считают MQL/SQL? (в 2026-м это важно для RevOps, потому что ответственность за выручку распределена шире, чем “только маркетинг”)
— не смешиваем ли мы события из разных платформ (web/app) в одну сущность без нормализации

Если нужно сравнивать каналы, я не верю “последнему клику”. Я предпочитаю устойчивые признаки: источник кампании в событии, первая активность в продукте, cohort по факту активации. Там, где требуется точнее — поднимаю incrementality/атрибуцию на стороне серверной логики (в Amplitude это обычно реализуется через согласованный measurement layer, а не через ручные надежды на отчёты).

Итог
Я не начинаю с воронок. Я начинаю с того, что пользователь — это не набор событий, а согласованная сущность в вашем measurement. В Amplitude это называется “правильная идентификация”, и именно она делает дальнейшие выводы рабочими: и для retention в e-com, и для RevOps в B2B.
…