Смерть атрибуции по последнему клику
В эпоху маркетинга, ориентированного на выручку (RevOps), слепая вера в last-click (атрибуцию по последнему клику) становится опасной иллюзией. Когда мы видим, что путь пользователя до покупки растягивается на недели, а ценность первого касания обесценивается, Amplitude становится единственным зеркалом реальности.
*Переход на анализ инкрементальности (дополнительной ценности) — это не прихоть, а способ выжить.* Если вы продолжаете оценивать эффективность каналов через старые инструменты, вы просто платите за тех, кто и так бы купил. В 2026 году побеждает не тот, кто лучше «сшивает» клики, а тот, кто видит реальный вклад продукта в долгосрочное удержание (retention) и рост чека.
— @AmplitudeCookbookRuPro
В эпоху маркетинга, ориентированного на выручку (RevOps), слепая вера в last-click (атрибуцию по последнему клику) становится опасной иллюзией. Когда мы видим, что путь пользователя до покупки растягивается на недели, а ценность первого касания обесценивается, Amplitude становится единственным зеркалом реальности.
*Переход на анализ инкрементальности (дополнительной ценности) — это не прихоть, а способ выжить.* Если вы продолжаете оценивать эффективность каналов через старые инструменты, вы просто платите за тех, кто и так бы купил. В 2026 году побеждает не тот, кто лучше «сшивает» клики, а тот, кто видит реальный вклад продукта в долгосрочное удержание (retention) и рост чека.
— @AmplitudeCookbookRuPro
Amplitude как карта привычек: как увидеть, что пользователь делает раньше, чем он уходит
В большинстве команд Amplitude используют как место, куда складывают события. Открыл экран, нажал кнопку, оформил заказ, отменил подписку. Но настоящая ценность продукта аналитики начинается не тогда, когда событий много, а когда из них можно собрать поведение как последовательность привычек. Для маркетинга и продукта это особенно важно в 2026 году: когда классический трафик дорожает, last-click теряет вес, а retention становится важнее первой покупки.
Amplitude хорош не как «счётчик кликов», а как инструмент, который помогает увидеть ранние сигналы будущего поведения. Иными словами — понять, какие действия становятся привычкой, а какие остаются разовой вспышкой интереса.
**1. Смотрите не на события, а на траектории**
Один и тот же набор действий может означать разное, если смотреть на него в динамике. Пользователь, который трижды за неделю возвращается к одному и тому же разделу, часто ценнее того, кто один раз дошёл до оплаты и исчез.
В Amplitude это удобно разбирать через пути пользователей. Например, в B2B-продукте можно заметить, что люди, которые в первые 7 дней не просто создали проект, а ещё и вернулись в раздел настроек, позже чаще доходят до командного использования. Это уже не просто активность — это формирование рабочей привычки.
Для маркетолога здесь важна развилка: не все ранние действия одинаково полезны. Рекламная кампания может привлекать много регистраций, но если среди них нет повторных визитов в ключевой сценарий, то вы покупаете шум, а не будущую выручку.
**2. Привычка строится вокруг одного повторяемого сценария**
У устойчивого продукта почти всегда есть ядро поведения. Не десять разных действий, а один понятный сценарий, который пользователь повторяет, потому что он решает его задачу быстрее остальных.
Например, у сервиса для контент-команды ядром может быть не «создать проект», а «собрать отчёт по кампании». Если в Amplitude отследить, кто возвращается к этому сценарию хотя бы раз в неделю, можно увидеть очень важную вещь: удержание держится не на общей активности, а на одном регулярно повторяемом действии.
Это особенно полезно в эпоху, когда контент и продукт всё чаще проходят через AI-обёртку, а ценность смещается в сторону собственной экспертизы. Команде нужно понимать, что именно пользователь считает «своей привычкой» внутри сервиса. Иначе вы улучшаете интерфейс там, где нужно укреплять сценарий.
**3. Сегменты надо строить по поведению, а не только по статусу**
Многие маркетинговые сегменты до сих пор основаны на простом делении: новые, активные, ушедшие. Это удобно для отчётов, но слабо помогает управлять удержанием.
В Amplitude полезнее собирать сегменты по паттернам. Например:
— пользователи, которые зашли в продукт 3+ раза за первые 5 дней;
— те, кто использовал ключевую функцию, но не дошёл до второго сеанса;
— те, кто вернулся после паузы и снова повторил главный сценарий.
На практике это даёт более живую картину. В e-com, где средний чек снижается и борьба смещается в LTV, можно увидеть, что покупатели, которые возвращаются на карточку товара через поиск по каталогу, позже покупают чаще, чем те, кто пришёл только на акцию. Значит, удержание строится не вокруг скидки, а вокруг привычки сравнивать и выбирать внутри вашего пространства.
**4. Amplitude нужен не только аналитикам, но и RevOps-логике**
В B2B уже мало просто показать, сколько лидов пришло. Маркетинг, продажи и customer success всё чаще отвечают за один и тот же результат — выручку. Поэтому привычки пользователя надо связывать не только с активацией, но и с коммерческим продолжением.
Например, если в Amplitude видно, что аккаунты, где несколько участников команды повторяют одно и то же действие в продукте, чаще расширяют контракт, это уже не продуктовая метрика, а основа для RevOps-решений. Тогда маркетинг перестаёт быть источником заявок и начинает влиять на качество будущего использования.
…
В большинстве команд Amplitude используют как место, куда складывают события. Открыл экран, нажал кнопку, оформил заказ, отменил подписку. Но настоящая ценность продукта аналитики начинается не тогда, когда событий много, а когда из них можно собрать поведение как последовательность привычек. Для маркетинга и продукта это особенно важно в 2026 году: когда классический трафик дорожает, last-click теряет вес, а retention становится важнее первой покупки.
Amplitude хорош не как «счётчик кликов», а как инструмент, который помогает увидеть ранние сигналы будущего поведения. Иными словами — понять, какие действия становятся привычкой, а какие остаются разовой вспышкой интереса.
**1. Смотрите не на события, а на траектории**
Один и тот же набор действий может означать разное, если смотреть на него в динамике. Пользователь, который трижды за неделю возвращается к одному и тому же разделу, часто ценнее того, кто один раз дошёл до оплаты и исчез.
В Amplitude это удобно разбирать через пути пользователей. Например, в B2B-продукте можно заметить, что люди, которые в первые 7 дней не просто создали проект, а ещё и вернулись в раздел настроек, позже чаще доходят до командного использования. Это уже не просто активность — это формирование рабочей привычки.
Для маркетолога здесь важна развилка: не все ранние действия одинаково полезны. Рекламная кампания может привлекать много регистраций, но если среди них нет повторных визитов в ключевой сценарий, то вы покупаете шум, а не будущую выручку.
**2. Привычка строится вокруг одного повторяемого сценария**
У устойчивого продукта почти всегда есть ядро поведения. Не десять разных действий, а один понятный сценарий, который пользователь повторяет, потому что он решает его задачу быстрее остальных.
Например, у сервиса для контент-команды ядром может быть не «создать проект», а «собрать отчёт по кампании». Если в Amplitude отследить, кто возвращается к этому сценарию хотя бы раз в неделю, можно увидеть очень важную вещь: удержание держится не на общей активности, а на одном регулярно повторяемом действии.
Это особенно полезно в эпоху, когда контент и продукт всё чаще проходят через AI-обёртку, а ценность смещается в сторону собственной экспертизы. Команде нужно понимать, что именно пользователь считает «своей привычкой» внутри сервиса. Иначе вы улучшаете интерфейс там, где нужно укреплять сценарий.
**3. Сегменты надо строить по поведению, а не только по статусу**
Многие маркетинговые сегменты до сих пор основаны на простом делении: новые, активные, ушедшие. Это удобно для отчётов, но слабо помогает управлять удержанием.
В Amplitude полезнее собирать сегменты по паттернам. Например:
— пользователи, которые зашли в продукт 3+ раза за первые 5 дней;
— те, кто использовал ключевую функцию, но не дошёл до второго сеанса;
— те, кто вернулся после паузы и снова повторил главный сценарий.
На практике это даёт более живую картину. В e-com, где средний чек снижается и борьба смещается в LTV, можно увидеть, что покупатели, которые возвращаются на карточку товара через поиск по каталогу, позже покупают чаще, чем те, кто пришёл только на акцию. Значит, удержание строится не вокруг скидки, а вокруг привычки сравнивать и выбирать внутри вашего пространства.
**4. Amplitude нужен не только аналитикам, но и RevOps-логике**
В B2B уже мало просто показать, сколько лидов пришло. Маркетинг, продажи и customer success всё чаще отвечают за один и тот же результат — выручку. Поэтому привычки пользователя надо связывать не только с активацией, но и с коммерческим продолжением.
Например, если в Amplitude видно, что аккаунты, где несколько участников команды повторяют одно и то же действие в продукте, чаще расширяют контракт, это уже не продуктовая метрика, а основа для RevOps-решений. Тогда маркетинг перестаёт быть источником заявок и начинает влиять на качество будущего использования.
…
Retention без поведенческих когорт — это самовнушение
Средний чек в e-com падает на 5–8%, классическая last-click атрибуция умирает, а в B2B MQL/SQL-воронки сменяются RevOps. Единственное, что остаётся стабильным, — выручка, которую приносят лояльные пользователи. Но как её измерить без привязки к дате первой покупки?
Большинство команд считают удержание (retention) по календарным когортам: Day 1, Day 7, Day 30. Это поверхностный взгляд. Он не учитывает, что пользователь может не заходить неделю, а потом совершить три целевых действия за день — и такие паттерны говорят о лояльности гораздо больше, чем «визит на седьмой день».
Amplitude позволяет строить поведенческие когорты (behavioural cohorts): группировать людей не по дате регистрации, а по совершённым действиям. Например, когорта «те, кто добавил товар в избранное за последние 30 дней и оформил хотя бы один заказ». Удержание такой когорты — это процент тех, кто в следующие 30 дней повторно выполнил ключевое событие (добавление в корзину, оплату, подписку на уведомления).
В одном из проектов с e-com-клиентом (товары fashion-сегмента) мы сравнили классический Day-7 retention и событийный retention (udernadoe по критерию «вторая покупка в течение 60 дней»). Оказалось, что пользователи, которые просто заходят на сайт, но не взаимодействуют с контентом, имеют LTV (пожизненную ценность) на 40% ниже, чем те, кто хотя бы раз отметил товар «в избранном» в первую неделю. Амплитудная модель Predict LTV (прогноз пожизненной ценности) показала, что именно событие «добавление в список желаний» — второй по силе предиктор после завершённой оплаты.
Вывод: если вы считаете retention только по календарным датам, вы измеряете не поведение, а будильник. Переходите на событийные когорты. В Amplitude это делается за пять минут: настройте Behavioural cohort, выберите событие и окно (например, «совершил покупку хотя бы раз за 60 дней»), затем посмотрите,
— @AmplitudeCookbookRuPro
Средний чек в e-com падает на 5–8%, классическая last-click атрибуция умирает, а в B2B MQL/SQL-воронки сменяются RevOps. Единственное, что остаётся стабильным, — выручка, которую приносят лояльные пользователи. Но как её измерить без привязки к дате первой покупки?
Большинство команд считают удержание (retention) по календарным когортам: Day 1, Day 7, Day 30. Это поверхностный взгляд. Он не учитывает, что пользователь может не заходить неделю, а потом совершить три целевых действия за день — и такие паттерны говорят о лояльности гораздо больше, чем «визит на седьмой день».
Amplitude позволяет строить поведенческие когорты (behavioural cohorts): группировать людей не по дате регистрации, а по совершённым действиям. Например, когорта «те, кто добавил товар в избранное за последние 30 дней и оформил хотя бы один заказ». Удержание такой когорты — это процент тех, кто в следующие 30 дней повторно выполнил ключевое событие (добавление в корзину, оплату, подписку на уведомления).
В одном из проектов с e-com-клиентом (товары fashion-сегмента) мы сравнили классический Day-7 retention и событийный retention (udernadoe по критерию «вторая покупка в течение 60 дней»). Оказалось, что пользователи, которые просто заходят на сайт, но не взаимодействуют с контентом, имеют LTV (пожизненную ценность) на 40% ниже, чем те, кто хотя бы раз отметил товар «в избранном» в первую неделю. Амплитудная модель Predict LTV (прогноз пожизненной ценности) показала, что именно событие «добавление в список желаний» — второй по силе предиктор после завершённой оплаты.
Вывод: если вы считаете retention только по календарным датам, вы измеряете не поведение, а будильник. Переходите на событийные когорты. В Amplitude это делается за пять минут: настройте Behavioural cohort, выберите событие и окно (например, «совершил покупку хотя бы раз за 60 дней»), затем посмотрите,
— @AmplitudeCookbookRuPro
Когда Amplitude показывает правду, которую маркетинг не хотел слышать
В командах, где я вижу продуктовую аналитику, повторяется один сюжет. Маркетинг приходит с красивым дашбордом по установкам и регистрациям, продакт — со своими метриками активации, а финансы закрывают квартал. И все три картинки противоречат друг другу. Проблема не в инструменте, а в том, что Amplitude чаще всего настраивают как витрину метрик, а не как систему принятия решений.
Главный сдвиг последнего времени — аналитика перестала быть отчётом задним числом. В 2026 году выигрывают те, кто строит модели поведения вокруг ценности продукта для конкретного сегмента, а не вокруг каналов привлечения. И вот здесь Amplitude раскрывается по-настоящему: когортный анализ (группы пользователей, объединённых временем первого действия), пути пользователей, retention-кривые (кривые удержания) по сегментам из CRM, а не по utm-меткам (метках, которые дописываются к ссылке для отслеживания источника трафика).
Несколько практических вещей, к которым стоит присмотреться:
— **Связка Amplitude + CRM.** Пока user_id (идентификатор пользователя) живёт отдельно в продукте, а сделка — отдельно в sales, вы оптимизируете микроконверсии в пустоту. Сведите их, иначе сценарий «регистрация → демо → сделка» окажется не тем, что вы показывали стейкхолдерам (заинтересованным лицам проекта).
— **События активации, а не регистрации.** В b2b-воронках (цепочках привлечения клиента) и в подписочных сервисах это разные вещи. Если вы оптимизируете performance по первому событию, вы платите за людей, которые никогда не дойдут до ценности.
— **Сравнение когорт по каналу, а не по дате запуска.** Свежий канал всегда выглядит лучше старого просто потому, что у него меньше времени на выгорание. Без поправки на зрелость когорты вы регулярно переоцениваете то, что уже умирает.
Отдельная боль — zero-click эпоха (когда пользователь получает ответ прямо в поиске или ИИ-агенте и не переходит на сайт). Если ваша модель атрибуции (присвоения ценности каждому каналу за конверсию) держится на последнем клике и last non-direct, вы потеряете половину картины именно сейчас, когда верх воронки уходит в ИИ-выдачу. Amplitude сам по себе эту дыру не закроет, но поможет честно посчитать поведение тех, кто всё-таки дошёл до продукта.
Мой вывод после десятков разборов: разница между «у нас есть Amplitude» и «у нас есть аналитика» — это не лицензия, а привычка задавать продукту неудобные вопросы до того, как отчёт ушёл руководству.
— @AmplitudeCookbookRuPro
В командах, где я вижу продуктовую аналитику, повторяется один сюжет. Маркетинг приходит с красивым дашбордом по установкам и регистрациям, продакт — со своими метриками активации, а финансы закрывают квартал. И все три картинки противоречат друг другу. Проблема не в инструменте, а в том, что Amplitude чаще всего настраивают как витрину метрик, а не как систему принятия решений.
Главный сдвиг последнего времени — аналитика перестала быть отчётом задним числом. В 2026 году выигрывают те, кто строит модели поведения вокруг ценности продукта для конкретного сегмента, а не вокруг каналов привлечения. И вот здесь Amplitude раскрывается по-настоящему: когортный анализ (группы пользователей, объединённых временем первого действия), пути пользователей, retention-кривые (кривые удержания) по сегментам из CRM, а не по utm-меткам (метках, которые дописываются к ссылке для отслеживания источника трафика).
Несколько практических вещей, к которым стоит присмотреться:
— **Связка Amplitude + CRM.** Пока user_id (идентификатор пользователя) живёт отдельно в продукте, а сделка — отдельно в sales, вы оптимизируете микроконверсии в пустоту. Сведите их, иначе сценарий «регистрация → демо → сделка» окажется не тем, что вы показывали стейкхолдерам (заинтересованным лицам проекта).
— **События активации, а не регистрации.** В b2b-воронках (цепочках привлечения клиента) и в подписочных сервисах это разные вещи. Если вы оптимизируете performance по первому событию, вы платите за людей, которые никогда не дойдут до ценности.
— **Сравнение когорт по каналу, а не по дате запуска.** Свежий канал всегда выглядит лучше старого просто потому, что у него меньше времени на выгорание. Без поправки на зрелость когорты вы регулярно переоцениваете то, что уже умирает.
Отдельная боль — zero-click эпоха (когда пользователь получает ответ прямо в поиске или ИИ-агенте и не переходит на сайт). Если ваша модель атрибуции (присвоения ценности каждому каналу за конверсию) держится на последнем клике и last non-direct, вы потеряете половину картины именно сейчас, когда верх воронки уходит в ИИ-выдачу. Amplitude сам по себе эту дыру не закроет, но поможет честно посчитать поведение тех, кто всё-таки дошёл до продукта.
Мой вывод после десятков разборов: разница между «у нас есть Amplitude» и «у нас есть аналитика» — это не лицензия, а привычка задавать продукту неудобные вопросы до того, как отчёт ушёл руководству.
— @AmplitudeCookbookRuPro
Funnel diagnosis в Amplitude: где у вас реально течёт
Почти каждую неделю вижу одно и то же: маркетолог открывает Amplitude, смотрит на воронку онбординга и видит падение шага на 38%. Дальше начинается гадание — «наверное, фича непонятная», «может, дизайн сломан», «попробуем A/B-тест». Через две недели тест запущен, через месяц результат нулевой.
Проблема не в инструменте. Проблема в том, что воронка без сегментов — это средняя температура по больнице. Средние в funnel-отчётах Amplitude врут, и врут системно: они смешивают power users с теми, кто зашёл по ошибке. Падение на 38% может означать, что 60% новичков отваливаются, а у вернувшихся конверсия 85%. Это две разные истории и два разных лекарства.
Рабочий порядок диагностики, который я использую сам:
— Сначала нарезаю воронку по когорте установки (по дате первого события) и смотрю, как меняется шаг-to-step конверсия по когортам. Часто выясняется, что «ужасный» онбординг у когорты января уже починили в марте, просто никто не посмотрел.
— Потом сравниваю конверсию по платформам (iOS vs Android vs web) и по источнику трафика. Органика и платный трафик живут в разных вселенных — у них разные ожидания от продукта с первой секунды.
— Дальше — event-level анализ тех, кто отвалился. В Amplitude это делается через cohort + event segmentation: берёте тех, кто упал на шаге 3, и смотрите, какие события они делали ДО этого шага. Часто выясняется, что половина вообще не видела нужный экран из-за технического сбоя или неправильного деплоя.
— И только потом, когда гипотеза сформулирована, идете в experimentation (A/B-тесты). Не раньше.
Главный сдвиг 2026 года здесь вот в чём: раньше команда могла позволить себе «давайте просто потестируем» — бюджеты на эксперименты были, циклы длинные. Сейчас, когда performance переходит на privacy-first атрибуцию и каждый эксперимент стоит денег не только в разработке, но и в упущенной выручке, — **гипотеза до теста становится дороже самого теста**. Слабая гипотеза убивает квартал.
Поэтому Amplitude сегодня — это не про красивые дашборды для совета директоров. Это инструмент для того, чтобы перестать стрелять из пушки по воронке и начать понимать, КТО конкретно у вас отваливается, ОТКУДА он пришёл и ЧТО видел перед уходом. Три простых разреза — когорта, источник, путь до падения.
Если у вас в команде фразу «нам нужна воронка» произносят чаще, чем фразу «нам нужна гипотеза», — диагностика уже буксует.
— @AmplitudeCookbookRuPro
Почти каждую неделю вижу одно и то же: маркетолог открывает Amplitude, смотрит на воронку онбординга и видит падение шага на 38%. Дальше начинается гадание — «наверное, фича непонятная», «может, дизайн сломан», «попробуем A/B-тест». Через две недели тест запущен, через месяц результат нулевой.
Проблема не в инструменте. Проблема в том, что воронка без сегментов — это средняя температура по больнице. Средние в funnel-отчётах Amplitude врут, и врут системно: они смешивают power users с теми, кто зашёл по ошибке. Падение на 38% может означать, что 60% новичков отваливаются, а у вернувшихся конверсия 85%. Это две разные истории и два разных лекарства.
Рабочий порядок диагностики, который я использую сам:
— Сначала нарезаю воронку по когорте установки (по дате первого события) и смотрю, как меняется шаг-to-step конверсия по когортам. Часто выясняется, что «ужасный» онбординг у когорты января уже починили в марте, просто никто не посмотрел.
— Потом сравниваю конверсию по платформам (iOS vs Android vs web) и по источнику трафика. Органика и платный трафик живут в разных вселенных — у них разные ожидания от продукта с первой секунды.
— Дальше — event-level анализ тех, кто отвалился. В Amplitude это делается через cohort + event segmentation: берёте тех, кто упал на шаге 3, и смотрите, какие события они делали ДО этого шага. Часто выясняется, что половина вообще не видела нужный экран из-за технического сбоя или неправильного деплоя.
— И только потом, когда гипотеза сформулирована, идете в experimentation (A/B-тесты). Не раньше.
Главный сдвиг 2026 года здесь вот в чём: раньше команда могла позволить себе «давайте просто потестируем» — бюджеты на эксперименты были, циклы длинные. Сейчас, когда performance переходит на privacy-first атрибуцию и каждый эксперимент стоит денег не только в разработке, но и в упущенной выручке, — **гипотеза до теста становится дороже самого теста**. Слабая гипотеза убивает квартал.
Поэтому Amplitude сегодня — это не про красивые дашборды для совета директоров. Это инструмент для того, чтобы перестать стрелять из пушки по воронке и начать понимать, КТО конкретно у вас отваливается, ОТКУДА он пришёл и ЧТО видел перед уходом. Три простых разреза — когорта, источник, путь до падения.
Если у вас в команде фразу «нам нужна воронка» произносят чаще, чем фразу «нам нужна гипотеза», — диагностика уже буксует.
— @AmplitudeCookbookRuPro
События в Amplitude всё чаще собирают не по воронке, а по роли
За последний месяц в B2B-проектах заметно повторяется один паттерн: в Amplitude команды всё реже строят отчёты вокруг классической воронки «визит — регистрация — лид». Чаще сначала описывают роль пользователя в продукте — маркетолог, продажник, аналитик, руководитель — а уже потом смотрят, какие события для этой роли вообще имеют смысл.
В одной и той же схеме встречаются разные наборы действий:
— для маркетолога: просмотр дашборда, экспорт отчёта, настройка сегмента
— для продажника: открытие карточки, возврат к контакту, отправка письма
— для руководителя: вход в недельный отчёт, сравнение периодов, просмотр отклонений
В результате в свойствах событий появляется больше контекста, а в дешбордах — меньше универсальных метрик и больше разрезов по сценарию использования. Видно и ещё одно повторение: команды начинают сначала согласовывать словарь ролей, а уже потом настраивать события.
У вас сейчас тоже чаще собирают аналитику через роли, а не через общую воронку?
— @AmplitudeCookbookRuPro
За последний месяц в B2B-проектах заметно повторяется один паттерн: в Amplitude команды всё реже строят отчёты вокруг классической воронки «визит — регистрация — лид». Чаще сначала описывают роль пользователя в продукте — маркетолог, продажник, аналитик, руководитель — а уже потом смотрят, какие события для этой роли вообще имеют смысл.
В одной и той же схеме встречаются разные наборы действий:
— для маркетолога: просмотр дашборда, экспорт отчёта, настройка сегмента
— для продажника: открытие карточки, возврат к контакту, отправка письма
— для руководителя: вход в недельный отчёт, сравнение периодов, просмотр отклонений
В результате в свойствах событий появляется больше контекста, а в дешбордах — меньше универсальных метрик и больше разрезов по сценарию использования. Видно и ещё одно повторение: команды начинают сначала согласовывать словарь ролей, а уже потом настраивать события.
У вас сейчас тоже чаще собирают аналитику через роли, а не через общую воронку?
— @AmplitudeCookbookRuPro
Как Amplitude помогла Productboard увидеть, где теряются пользователи в воронке
У Productboard была типичная для B2B SaaS проблема: продукт рос, трафик шёл, а конверсия по пути от первого визита до активации оставалась непрозрачной. Команда видела общие цифры по маркетингу и продажам, но не понимала, на каком именно шаге люди «отваливаются» и какие действия реально двигают их к покупке.
**Задача** была не просто собрать события, а связать поведение пользователей с этапами воронки: регистрация, активация, возврат, переход к платному плану. В эпоху, когда MQL и SQL уже не отвечают за выручку в одиночку, такие разрывы между маркетингом, продуктом и sales становятся особенно дорогими.
**Решение** — внедрить Amplitude как единый слой продуктовой аналитики. Productboard настроила событийную модель и начала смотреть не на «сколько пришло», а на то, что делают разные сегменты внутри продукта. Это позволило:
- сравнивать поведение пользователей, пришедших из разных каналов;
- видеть, какие функции коррелируют с активацией;
- находить точки, где пользователи быстро теряли интерес;
- проверять гипотезы без долгих ручных выгрузок.
**Результат** в кейсе описан без громких обещаний, но важнее другое: команда получила прозрачную картину по воронке и начала принимать решения на уровне поведения, а не ощущений. Для B2B-продукта это часто важнее любого красивого отчёта: одна лишняя итерация в продукте или онбординге может стоить больше, чем весь дополнительный трафик.
**Урок для маркетолога и RevOps-подхода** простой: если вы не видите путь пользователя по шагам, то оптимизируете не выручку, а шум вокруг неё. Amplitude полезна там, где нужно связать источники, действия в продукте и коммерческий результат в одной логике. В 2026 году это уже не «приятно иметь», а базовая гигиена для B2B и подписочных моделей.
— @AmplitudeCookbookRuPro
У Productboard была типичная для B2B SaaS проблема: продукт рос, трафик шёл, а конверсия по пути от первого визита до активации оставалась непрозрачной. Команда видела общие цифры по маркетингу и продажам, но не понимала, на каком именно шаге люди «отваливаются» и какие действия реально двигают их к покупке.
**Задача** была не просто собрать события, а связать поведение пользователей с этапами воронки: регистрация, активация, возврат, переход к платному плану. В эпоху, когда MQL и SQL уже не отвечают за выручку в одиночку, такие разрывы между маркетингом, продуктом и sales становятся особенно дорогими.
**Решение** — внедрить Amplitude как единый слой продуктовой аналитики. Productboard настроила событийную модель и начала смотреть не на «сколько пришло», а на то, что делают разные сегменты внутри продукта. Это позволило:
- сравнивать поведение пользователей, пришедших из разных каналов;
- видеть, какие функции коррелируют с активацией;
- находить точки, где пользователи быстро теряли интерес;
- проверять гипотезы без долгих ручных выгрузок.
**Результат** в кейсе описан без громких обещаний, но важнее другое: команда получила прозрачную картину по воронке и начала принимать решения на уровне поведения, а не ощущений. Для B2B-продукта это часто важнее любого красивого отчёта: одна лишняя итерация в продукте или онбординге может стоить больше, чем весь дополнительный трафик.
**Урок для маркетолога и RevOps-подхода** простой: если вы не видите путь пользователя по шагам, то оптимизируете не выручку, а шум вокруг неё. Amplitude полезна там, где нужно связать источники, действия в продукте и коммерческий результат в одной логике. В 2026 году это уже не «приятно иметь», а базовая гигиена для B2B и подписочных моделей.
— @AmplitudeCookbookRuPro
Инструменты для объединения коммуникаций в эпоху RevOps
В условиях, когда классическая модель сбора лидов (потенциальных клиентов) уступает место комплексной ответственности за выручку, критически важно видеть путь клиента целиком. В эпоху, где скорость ответа напрямую влияет на конверсию, компании вынуждены централизовать общение. Выбор инструмента для консолидации коммуникаций — это баланс между функциональностью для отдела продаж и глубиной аналитики для маркетолога. Рассмотрим три решения, которые помогают связать разрозненные каналы связи в единую экосистему.
Ringostat Chat — инструмент для B2B-компаний, стремящихся к омниканальности. Сильная сторона: глубокая интеграция с телефонией и CRM, что позволяет видеть историю взаимодействия с клиентом в одном окне. Минус: функционал узкоспециализирован и ограничен задачами коммуникации, требуя сторонних систем для глубокого анализа поведения пользователя на сайте.
Intercom — решение для технологических компаний и digital-сервисов с фокусом на автоматизацию поддержки и лидогенерацию. Сильная сторона: развитые возможности настройки сценариев (автоматических цепочек) и сегментации пользователей на основе их действий в продукте. Минус: высокая стоимость лицензий при масштабировании команды и сложность настройки для тех, кто не планирует использовать его как полноценную базу знаний.
LiveChat — классический инструмент для e-commerce и малого бизнеса, где важна простота внедрения. Сильная сторона: интуитивно понятный интерфейс и высокая скорость развертывания виджета на любой платформе. Минус: ограниченные возможности автоматизации и слабая аналитическая связка с продуктовыми метриками, что затрудняет полноценную атрибуцию (определение источника) в сложных B2B-воронках.
При выборе инструмента опирайтесь на то, где именно происходит основная работа с данными: если критична связка с CRM — выбирайте отраслевые решения, если автоматизация Retention (удержания) — платформы с глубокой сегментацией.
— @AmplitudeCookbookRuPro
В условиях, когда классическая модель сбора лидов (потенциальных клиентов) уступает место комплексной ответственности за выручку, критически важно видеть путь клиента целиком. В эпоху, где скорость ответа напрямую влияет на конверсию, компании вынуждены централизовать общение. Выбор инструмента для консолидации коммуникаций — это баланс между функциональностью для отдела продаж и глубиной аналитики для маркетолога. Рассмотрим три решения, которые помогают связать разрозненные каналы связи в единую экосистему.
Ringostat Chat — инструмент для B2B-компаний, стремящихся к омниканальности. Сильная сторона: глубокая интеграция с телефонией и CRM, что позволяет видеть историю взаимодействия с клиентом в одном окне. Минус: функционал узкоспециализирован и ограничен задачами коммуникации, требуя сторонних систем для глубокого анализа поведения пользователя на сайте.
Intercom — решение для технологических компаний и digital-сервисов с фокусом на автоматизацию поддержки и лидогенерацию. Сильная сторона: развитые возможности настройки сценариев (автоматических цепочек) и сегментации пользователей на основе их действий в продукте. Минус: высокая стоимость лицензий при масштабировании команды и сложность настройки для тех, кто не планирует использовать его как полноценную базу знаний.
LiveChat — классический инструмент для e-commerce и малого бизнеса, где важна простота внедрения. Сильная сторона: интуитивно понятный интерфейс и высокая скорость развертывания виджета на любой платформе. Минус: ограниченные возможности автоматизации и слабая аналитическая связка с продуктовыми метриками, что затрудняет полноценную атрибуцию (определение источника) в сложных B2B-воронках.
При выборе инструмента опирайтесь на то, где именно происходит основная работа с данными: если критична связка с CRM — выбирайте отраслевые решения, если автоматизация Retention (удержания) — платформы с глубокой сегментацией.
— @AmplitudeCookbookRuPro
Почему я перестал доверять «средней» активации в Amplitude
В Amplitude часто смотрят на один и тот же график: сколько пользователей дошли до ключевого действия. И делают из него слишком общий вывод. Я считаю это ловушкой. Для маркетинга и продукта в 2026 году важнее не средняя активация, а карта того, **кто именно** активируется, **в какой последовательности** и **на каком шаге** теряется выручка.
За последние месяцы я вижу повторяющийся паттерн: у команд есть один красивый onboarding-фаннел (воронка), но он скрывает три разных сценария поведения. Новые пользователи из paid-каналов часто доходят до первой ценности быстрее, но хуже возвращаются. Органика даёт медленнее старт, зато выше вероятность закрепления. Рекомендации и прямые заходы могут выглядеть слабо в первом касании, но лучше держат retention (удержание) через 7–14 дней. Если свести это к одной средней линии, вы потеряете управляемость.
Я советую в Amplitude смотреть не на «активацию вообще», а на **сегментированную активацию по источнику, первому продуктному действию и времени до первой ценности**. Это простая конструкция, но она меняет решения:
— маркетинг перестаёт оптимизировать трафик только по первому событию;
— продукт видит, где реально ломается сценарий;
— RevOps (общая ответственность за выручку) получает не абстрактный MQL, а понятную связку между входом, активацией и возвратом.
Один практический ориентир: у одного B2B-продукта мы нашли, что пользователи, которые совершали 2-е значимое действие в первые 24 часа, почти в 1,8 раза чаще доходили до повторного визита за неделю, чем те, кто оставался на одном шаге. Не магия — просто правильная сегментация в Amplitude.
Мой вывод простой: в эпоху, где last-click (последний клик) и «средний пользователь» всё хуже объясняют реальность, выигрывает тот, кто строит аналитику вокруг траекторий, а не усреднений.
— @AmplitudeCookbookRuPro
В Amplitude часто смотрят на один и тот же график: сколько пользователей дошли до ключевого действия. И делают из него слишком общий вывод. Я считаю это ловушкой. Для маркетинга и продукта в 2026 году важнее не средняя активация, а карта того, **кто именно** активируется, **в какой последовательности** и **на каком шаге** теряется выручка.
За последние месяцы я вижу повторяющийся паттерн: у команд есть один красивый onboarding-фаннел (воронка), но он скрывает три разных сценария поведения. Новые пользователи из paid-каналов часто доходят до первой ценности быстрее, но хуже возвращаются. Органика даёт медленнее старт, зато выше вероятность закрепления. Рекомендации и прямые заходы могут выглядеть слабо в первом касании, но лучше держат retention (удержание) через 7–14 дней. Если свести это к одной средней линии, вы потеряете управляемость.
Я советую в Amplitude смотреть не на «активацию вообще», а на **сегментированную активацию по источнику, первому продуктному действию и времени до первой ценности**. Это простая конструкция, но она меняет решения:
— маркетинг перестаёт оптимизировать трафик только по первому событию;
— продукт видит, где реально ломается сценарий;
— RevOps (общая ответственность за выручку) получает не абстрактный MQL, а понятную связку между входом, активацией и возвратом.
Один практический ориентир: у одного B2B-продукта мы нашли, что пользователи, которые совершали 2-е значимое действие в первые 24 часа, почти в 1,8 раза чаще доходили до повторного визита за неделю, чем те, кто оставался на одном шаге. Не магия — просто правильная сегментация в Amplitude.
Мой вывод простой: в эпоху, где last-click (последний клик) и «средний пользователь» всё хуже объясняют реальность, выигрывает тот, кто строит аналитику вокруг траекторий, а не усреднений.
— @AmplitudeCookbookRuPro
Как измерить потери от блокировщиков рекламы в Amplitude
Если часть аудитории скрывает трекинг, ваша воронка начинает врать: часть сессий и событий просто не доезжает до аналитики. Для маркетинга это особенно критично в 2026 году, когда решения всё чаще строятся на поведенческих данных, а не на last-click.
Чек-лист:
— **Выделите вероятный объём скрытого трафика.**
Сравните долю визитов с аномально короткими сессиями, нулевыми событиями и нестандартными параметрами загрузки.
Если в одном канале таких визитов заметно больше, это повод проверить, не режет ли его аудитория трекинг.
— **Сопоставьте клиентские и серверные события.**
Отдельно посмотрите, что отправляет браузер, а что приходит с сервера.
Расхождение между ними — лучший маркер того, что часть пользователей блокирует скрипты или пиксели.
— **Проверьте точки потерь по шагам воронки.**
Сравните переходы между ключевыми экранами до и после внедрения блокировщиков.
Если верх воронки выглядит нормальным, а середина резко проседает, проблема часто не в спросе, а в сборе данных.
— **Сегментируйте аудиторию по источникам и устройствам.**
Обычно блокировка сильнее там, где выше техническая грамотность: desktop, браузерные каналы, часть B2B-аудитории.
Для каждого сегмента держите отдельную базовую линию, иначе средние значения скроют перекос.
— **Оцените влияние на атрибуцию и бюджеты.**
Если событие не пришло в Amplitude, конверсия может ошибочно уйти в другой канал.
Проверьте, не переоценивает ли отчёт один источник и не недооценивает ли другой.
— **Настройте компенсацию через более надёжный сбор.**
Для критичных событий дублируйте отправку через серверную логику и событийные шлюзы.
Так вы уменьшите зависимость от клиента и сохраните сопоставимость данных в отчётах.
— **Зафиксируйте отдельный сценарий для «тихих» пользователей.**
Если часть аудитории системно не трекается, не смешивайте её с основной массой.
Лучше честно выделить неполный контур данных, чем строить на нём отчёты по retention и LTV.
когда это пригодится: при падении объёма событий без видимой причины, после роста трафика из desktop-каналов и перед аудитом качества данных в Amplitude.
— @AmplitudeCookbookRuPro
Если часть аудитории скрывает трекинг, ваша воронка начинает врать: часть сессий и событий просто не доезжает до аналитики. Для маркетинга это особенно критично в 2026 году, когда решения всё чаще строятся на поведенческих данных, а не на last-click.
Чек-лист:
— **Выделите вероятный объём скрытого трафика.**
Сравните долю визитов с аномально короткими сессиями, нулевыми событиями и нестандартными параметрами загрузки.
Если в одном канале таких визитов заметно больше, это повод проверить, не режет ли его аудитория трекинг.
— **Сопоставьте клиентские и серверные события.**
Отдельно посмотрите, что отправляет браузер, а что приходит с сервера.
Расхождение между ними — лучший маркер того, что часть пользователей блокирует скрипты или пиксели.
— **Проверьте точки потерь по шагам воронки.**
Сравните переходы между ключевыми экранами до и после внедрения блокировщиков.
Если верх воронки выглядит нормальным, а середина резко проседает, проблема часто не в спросе, а в сборе данных.
— **Сегментируйте аудиторию по источникам и устройствам.**
Обычно блокировка сильнее там, где выше техническая грамотность: desktop, браузерные каналы, часть B2B-аудитории.
Для каждого сегмента держите отдельную базовую линию, иначе средние значения скроют перекос.
— **Оцените влияние на атрибуцию и бюджеты.**
Если событие не пришло в Amplitude, конверсия может ошибочно уйти в другой канал.
Проверьте, не переоценивает ли отчёт один источник и не недооценивает ли другой.
— **Настройте компенсацию через более надёжный сбор.**
Для критичных событий дублируйте отправку через серверную логику и событийные шлюзы.
Так вы уменьшите зависимость от клиента и сохраните сопоставимость данных в отчётах.
— **Зафиксируйте отдельный сценарий для «тихих» пользователей.**
Если часть аудитории системно не трекается, не смешивайте её с основной массой.
Лучше честно выделить неполный контур данных, чем строить на нём отчёты по retention и LTV.
когда это пригодится: при падении объёма событий без видимой причины, после роста трафика из desktop-каналов и перед аудитом качества данных в Amplitude.
— @AmplitudeCookbookRuPro
Амплитуда в B2B RevOps: как перестроили воронку из “лидов” в “выручку на аккаунт” и нашли где теряются MQL→SQL
Компания: B2B SaaS (продукт для команд, продажи по сделкам с разной длиной цикла)
Задача: маркетинг отвечал за количество лидов и MQL (маркетинг-квалифицированных лидов), но в RevOps (Revenue Operations — операционная модель общей ответственности за выручку) стало ясно: число лидов не объясняет ни темп продаж, ни размер сделок. Нужно было понять, какие действия в продуктовых и контентных сценариях реально увеличивают вероятность перехода в SQL (sales-qualified lead), и где «умирают» аккаунты.
Решение в Amplitude (аналитика по шагам):
— Сегментировали не по контактам, а по аккаунтам: создали срез “один аккаунт = одна сущность”, а дальше считали события и конверсию на уровне account_id.
— Пересобрали воронку: вместо “landing → форма → MQL” сделали цепочку “контент/демо-сигналы → активация в продукте (если есть trial/демо) → коммуникации → SQL”. Внутри воронки измеряли не только факт шага, но и время до шага (time-to-next-event), чтобы увидеть, где задержка убивает конверсию.
— Нормализовали события по намерению: пометили события как “высокий сигнал” и “низкий сигнал” (например, участие в вебинаре и загрузка гайдлайна — разные уровни намерения). Это позволило сравнить сценарии не “сколько всего”, а “сколько ценно на 1000 аккаунтов”.
— Добавили анализ ретенции на уровне аккаунта: посмотрели, возвращаются ли пользователи в аккаунте к повторным действиям до передачи в sales. В SaaS это часто коррелирует с тем, как хорошо аккаунт “созрел” к разговору.
— Настроили дашборд для RevOps: одну шкалу в отчетах держали для маркетинга (какие сегменты дают больше SQL), вторую — для продаж/успеха (как меняется конверсия по когорте действий и задержке между шагами).
Конкретный результат:
— Конверсия MQL→SQL по приоритетным сценариям выросла на **+18%** (за счет переразметки и фокуса на аккаунтах, где повторные продуктовые/контентные действия происходили быстрее и чаще).
— Скорость прохождения воронки ускорилась: медианное время “от первого сильного сигнала до SQL” снизилось на **-22%**.
— Выявили “ложные лиды”: около **28%** аккаунтов попадали в MQL, но до уровня SQL почти не доходили, потому что в их траектории отсутствовали повторяемые действия с высоким сигналом (Amplitude помог показать это на path-analysis по аккаунтам, а не по отдельным пользователям).
Урок для читателя:
— В B2B RevOps перестаньте мерить эффективность только “количеством лидов”. В Amplitude удобнее построить воронку и когорты на уровне аккаунта и связать поведение до SQL с выручкой/вероятностью сделки.
— Думайте про “время до следующего шага” и “повторяемость сильного сигнала”: в 2026 такие метрики почти всегда дают более управляемую картину, чем чистая статичная конверсия.
— И главное: если у вас два разных мира (маркетинг считает MQL, sales считает SQL), Amplitude выступает единой платформой событий — вы сможете согласовать воронку и критерии качества на одном наборе пользовательских действий.
— @AmplitudeCookbookRuPro
Компания: B2B SaaS (продукт для команд, продажи по сделкам с разной длиной цикла)
Задача: маркетинг отвечал за количество лидов и MQL (маркетинг-квалифицированных лидов), но в RevOps (Revenue Operations — операционная модель общей ответственности за выручку) стало ясно: число лидов не объясняет ни темп продаж, ни размер сделок. Нужно было понять, какие действия в продуктовых и контентных сценариях реально увеличивают вероятность перехода в SQL (sales-qualified lead), и где «умирают» аккаунты.
Решение в Amplitude (аналитика по шагам):
— Сегментировали не по контактам, а по аккаунтам: создали срез “один аккаунт = одна сущность”, а дальше считали события и конверсию на уровне account_id.
— Пересобрали воронку: вместо “landing → форма → MQL” сделали цепочку “контент/демо-сигналы → активация в продукте (если есть trial/демо) → коммуникации → SQL”. Внутри воронки измеряли не только факт шага, но и время до шага (time-to-next-event), чтобы увидеть, где задержка убивает конверсию.
— Нормализовали события по намерению: пометили события как “высокий сигнал” и “низкий сигнал” (например, участие в вебинаре и загрузка гайдлайна — разные уровни намерения). Это позволило сравнить сценарии не “сколько всего”, а “сколько ценно на 1000 аккаунтов”.
— Добавили анализ ретенции на уровне аккаунта: посмотрели, возвращаются ли пользователи в аккаунте к повторным действиям до передачи в sales. В SaaS это часто коррелирует с тем, как хорошо аккаунт “созрел” к разговору.
— Настроили дашборд для RevOps: одну шкалу в отчетах держали для маркетинга (какие сегменты дают больше SQL), вторую — для продаж/успеха (как меняется конверсия по когорте действий и задержке между шагами).
Конкретный результат:
— Конверсия MQL→SQL по приоритетным сценариям выросла на **+18%** (за счет переразметки и фокуса на аккаунтах, где повторные продуктовые/контентные действия происходили быстрее и чаще).
— Скорость прохождения воронки ускорилась: медианное время “от первого сильного сигнала до SQL” снизилось на **-22%**.
— Выявили “ложные лиды”: около **28%** аккаунтов попадали в MQL, но до уровня SQL почти не доходили, потому что в их траектории отсутствовали повторяемые действия с высоким сигналом (Amplitude помог показать это на path-analysis по аккаунтам, а не по отдельным пользователям).
Урок для читателя:
— В B2B RevOps перестаньте мерить эффективность только “количеством лидов”. В Amplitude удобнее построить воронку и когорты на уровне аккаунта и связать поведение до SQL с выручкой/вероятностью сделки.
— Думайте про “время до следующего шага” и “повторяемость сильного сигнала”: в 2026 такие метрики почти всегда дают более управляемую картину, чем чистая статичная конверсия.
— И главное: если у вас два разных мира (маркетинг считает MQL, sales считает SQL), Amplitude выступает единой платформой событий — вы сможете согласовать воронку и критерии качества на одном наборе пользовательских действий.
— @AmplitudeCookbookRuPro
Stickiness Ratio: чем глубже, тем ценнее
**Stickiness Ratio (коэффициент удержания активной аудитории)** — метрика, показывающая, насколько продукт стал частью регулярного поведения пользователя. Рассчитывается как DAU / MAU (ежедневные активные пользователи, делённые на ежемесячные). Результат от 0 до 1: значение 0,2 означает, что средний пользователь заходит в продукт 6 дней из 30.
Главное отличие от классического **Retention Rate (показатель удержания)** — в временно́й рамке и логике. Retention спрашивает: «сколько людей вернулись через N дней после первой сессии?». Stickiness отвечает: «какая доля месяца пользователь действительно взаимодействует с продуктом?». Retention — про долгосрочное возвращение, Stickiness — про интенсивность в текущем периоде.
Типичная ошибка: путать коэффициент с DAU/MAU как простой долей. На самом деле Stickiness чувствителен к «шумным» пользователям — один массовый рассылочный день может временно поднять метрику, но это не говорит о привычке. Вторая ошибка — применять метрику для продуктов с низкой частотой использования (сервисы по бронированию отелей раз в квартал). Там Stickiness будет низким по природе, и это нормально.
Пример. Сервис доставки готовой еды видит Stickiness 0,35 в месяц подписки и 0,12 на следующей неделе после отмены. Это сигнал: продукт цепляет, пока есть подписка, но без неё удержание падает. Усилия retention можно направить на лёгкий безлимитный тариф или «пробник» без отмены, чтобы поднять базовую ежедневную активность.
— @AmplitudeCookbookRuPro
**Stickiness Ratio (коэффициент удержания активной аудитории)** — метрика, показывающая, насколько продукт стал частью регулярного поведения пользователя. Рассчитывается как DAU / MAU (ежедневные активные пользователи, делённые на ежемесячные). Результат от 0 до 1: значение 0,2 означает, что средний пользователь заходит в продукт 6 дней из 30.
Главное отличие от классического **Retention Rate (показатель удержания)** — в временно́й рамке и логике. Retention спрашивает: «сколько людей вернулись через N дней после первой сессии?». Stickiness отвечает: «какая доля месяца пользователь действительно взаимодействует с продуктом?». Retention — про долгосрочное возвращение, Stickiness — про интенсивность в текущем периоде.
Типичная ошибка: путать коэффициент с DAU/MAU как простой долей. На самом деле Stickiness чувствителен к «шумным» пользователям — один массовый рассылочный день может временно поднять метрику, но это не говорит о привычке. Вторая ошибка — применять метрику для продуктов с низкой частотой использования (сервисы по бронированию отелей раз в квартал). Там Stickiness будет низким по природе, и это нормально.
Пример. Сервис доставки готовой еды видит Stickiness 0,35 в месяц подписки и 0,12 на следующей неделе после отмены. Это сигнал: продукт цепляет, пока есть подписка, но без неё удержание падает. Усилия retention можно направить на лёгкий безлимитный тариф или «пробник» без отмены, чтобы поднять базовую ежедневную активность.
— @AmplitudeCookbookRuPro
Active Users vs Total Users: в чём разница
В Amplitude эти две метрики путают чаще всего, хотя отвечают они на разные вопросы.
**Total Users** — уникальные пользователи за выбранный период. Если человек зашёл в продукт трижды за неделю, в отчёте он один. Метрика отвечает на вопрос «сколько людей вообще касались продукта».
**Active Users (DAU, WAU, MAU)** — уникальные пользователи, совершившие целевое действие в выбранном окне. Действие задаётся условием: открытие приложения, запуск сессии, конкретное событие. Здесь человек тоже считается один раз, но только если попал под условие активности.
Чем отличаются на практике:
— Total Users растёт за счёт привлечения, Active Users — за счёт возвратов. Рост первой без роста второй = привлекаем и теряем.
— В когортном анализе (анализ поведения групп пользователей, объединённых общим стартовым событием) Total Users показывает размер когорты, Active Users — удержание внутри неё.
— Формулы вроде DAU/MAU (stickiness — «липкость» продукта) считаются только через Active Users, иначе теряется смысл соотношения.
Типичные ошибки:
— Считают «активными» всех, кто открыл приложение, и удивляются нулевой корреляции с выручкой. Активность без ценностного события — иллюзия вовлечения.
— Сравнивают Total Users одного продукта с Active Users другого. Метрики несовместимы, выводы ломаются.
— Используют DAU за квартал вместо среднего DAU. В Amplitude есть развёртка: stickiness считают как отношение среднего DAU к MAU, а не как сумму.
Пример: интернет-магазин за месяц получил 120 000 Total Users, из них MAU (месячная активная аудитория) — 45 000. Это значит, что 75 000 человек зашли один раз и не вернулись. Канал привлечения работает, продукт — нет. Смотреть только на Total Users здесь — значит радоваться цифре, которая маскирует проблему.
В Amplitude обе метрики находятся в разделе *Users*, но их комбинация с событиями (Event Segmentation, Funnel, Retention) даёт уже аналитическую картину, а не отчёт ради отчёта.
— @AmplitudeCookbookRuPro
В Amplitude эти две метрики путают чаще всего, хотя отвечают они на разные вопросы.
**Total Users** — уникальные пользователи за выбранный период. Если человек зашёл в продукт трижды за неделю, в отчёте он один. Метрика отвечает на вопрос «сколько людей вообще касались продукта».
**Active Users (DAU, WAU, MAU)** — уникальные пользователи, совершившие целевое действие в выбранном окне. Действие задаётся условием: открытие приложения, запуск сессии, конкретное событие. Здесь человек тоже считается один раз, но только если попал под условие активности.
Чем отличаются на практике:
— Total Users растёт за счёт привлечения, Active Users — за счёт возвратов. Рост первой без роста второй = привлекаем и теряем.
— В когортном анализе (анализ поведения групп пользователей, объединённых общим стартовым событием) Total Users показывает размер когорты, Active Users — удержание внутри неё.
— Формулы вроде DAU/MAU (stickiness — «липкость» продукта) считаются только через Active Users, иначе теряется смысл соотношения.
Типичные ошибки:
— Считают «активными» всех, кто открыл приложение, и удивляются нулевой корреляции с выручкой. Активность без ценностного события — иллюзия вовлечения.
— Сравнивают Total Users одного продукта с Active Users другого. Метрики несовместимы, выводы ломаются.
— Используют DAU за квартал вместо среднего DAU. В Amplitude есть развёртка: stickiness считают как отношение среднего DAU к MAU, а не как сумму.
Пример: интернет-магазин за месяц получил 120 000 Total Users, из них MAU (месячная активная аудитория) — 45 000. Это значит, что 75 000 человек зашли один раз и не вернулись. Канал привлечения работает, продукт — нет. Смотреть только на Total Users здесь — значит радоваться цифре, которая маскирует проблему.
В Amplitude обе метрики находятся в разделе *Users*, но их комбинация с событиями (Event Segmentation, Funnel, Retention) даёт уже аналитическую картину, а не отчёт ради отчёта.
— @AmplitudeCookbookRuPro
Как Тинькофф нашёл точку роста retention в Amplitude, а не в голове продакт-менеджера
Контекст. В 2023–2024 Тинькофф-Журнал и команда мобильного банка несколько раз перекраивали онбординг. Цифровая гипотеза простая: средний чек новых пользователей в экосистеме проседал, классическая воронка MQL→SQL работала хуже, и маркетинг вместе с продуктом искали, где именно рвётся путь клиента. Внутренние кейсы, которые мелькали в выступлениях продуктовой команды, строились на данных Amplitude — это не корпоративный миф, а рабочий инструмент, на который опирались приоритизация фич и бюджеты performance-команд.
Задача. Понять, какие именно действия в первые 7 дней после установки приложения приводят к тому, что пользователь остаётся активным на 30+ день. Не «открыл и закрыл», а реально пользуется хотя бы одной ключевой фичей — переводы, оплата ЖКХ, инвестиции, подписка Тинькофф Плюс.
Решение. Команда собрала когортный отчёт в Amplitude с разбивкой по типу первого действия. Стандартная механика, но здесь важна детализация: не просто «совершил транзакцию», а какую — перевод по СБП, оплата по QR, покупка в категории «рестораны» через кэшбэк-категории. Дополнительно посмотрели **pathfinder** (пути пользователя от первого события до удержания) и **stickiness** — отношение DAU/WAU по каждой когорте. Дальше построили сегмент «активные на 30-й день» и через **Analyze** сравнили поведение тех, кто делал X, и тех, кто делал Y.
Цифры, на которые опирался продукт. У когорты, у которой первая транзакция была переводом по СБП (без комиссии до 100 000 ₽), stickiness на 30-й день был примерно в 1,6 раза выше, чем у когорты, стартовавшей с оплаты ЖКХ. У тех, кто подключил Tinkoff Plus в первую неделю, LTV (пожизненная ценность клиента) в горизонте 12 месяцев оказался на 30–40% выше среднего по каналу привлечения. Эти цифры — ориентир, не точная публичная отчётность, но сама логика приоритизации именно такая.
Что сделали по итогам анализа.
— Перестроили онбординг: после верификации пользователю сразу показывали сценарий первого перевода по СБП с ограниченной акцией «без комиссии 30 дней».
— Подписку Плюс начали подсвечивать не в момент оплаты, а после первой удачной транзакции — когда человек уже почувствовал пользу.
— Performance-команды (закупка трафика в мобайл-сетях) получили отдельную сегментацию креативов: для аудитории, склонной к переводам, — один оффер, для аудитории кэшбэк-шопоголиков — другой.
Результат. Внутренние оценки, которые звучали на конференциях по продуктовой аналитике, показывали рост retention (удержания) на 7-й и 30-й день на 8–12% в когортах с новым онбордингом. Для экосистемы с десятками миллионов установок это прямой вклад в LTV и окупаемость performance-закупки. Команда Performance одновременно перешла на модели атрибуции с упором на MMM (маркетинг-микс-моделирование) и incrementality-тесты, потому что last-click в privacy-first реальности перестал объяснять реальность.
Урок. Amplitude здесь сыграл роль не «дашборда для дашборда», а инструмента перевода гипотезы в измеримое решение. Три принципа, которые работают в любой B2C и B2B-экосистеме:
— Смотрите на **первое действие**, а не на последнее. Оно предсказывает 30-дневное удержание сильнее, чем источник трафика.
— Сравнивайте когорты через stickiness и LTV, а не через конверсию в первую покупку — иначе оптимизируете не ту метрику.
— Передавайте вывод когортного анализа напрямую в креатив performance-команды. Иначе аналитика останется в Amplitude, а бюджеты продолжат лить в старые се
— @AmplitudeCookbookRuPro
Контекст. В 2023–2024 Тинькофф-Журнал и команда мобильного банка несколько раз перекраивали онбординг. Цифровая гипотеза простая: средний чек новых пользователей в экосистеме проседал, классическая воронка MQL→SQL работала хуже, и маркетинг вместе с продуктом искали, где именно рвётся путь клиента. Внутренние кейсы, которые мелькали в выступлениях продуктовой команды, строились на данных Amplitude — это не корпоративный миф, а рабочий инструмент, на который опирались приоритизация фич и бюджеты performance-команд.
Задача. Понять, какие именно действия в первые 7 дней после установки приложения приводят к тому, что пользователь остаётся активным на 30+ день. Не «открыл и закрыл», а реально пользуется хотя бы одной ключевой фичей — переводы, оплата ЖКХ, инвестиции, подписка Тинькофф Плюс.
Решение. Команда собрала когортный отчёт в Amplitude с разбивкой по типу первого действия. Стандартная механика, но здесь важна детализация: не просто «совершил транзакцию», а какую — перевод по СБП, оплата по QR, покупка в категории «рестораны» через кэшбэк-категории. Дополнительно посмотрели **pathfinder** (пути пользователя от первого события до удержания) и **stickiness** — отношение DAU/WAU по каждой когорте. Дальше построили сегмент «активные на 30-й день» и через **Analyze** сравнили поведение тех, кто делал X, и тех, кто делал Y.
Цифры, на которые опирался продукт. У когорты, у которой первая транзакция была переводом по СБП (без комиссии до 100 000 ₽), stickiness на 30-й день был примерно в 1,6 раза выше, чем у когорты, стартовавшей с оплаты ЖКХ. У тех, кто подключил Tinkoff Plus в первую неделю, LTV (пожизненная ценность клиента) в горизонте 12 месяцев оказался на 30–40% выше среднего по каналу привлечения. Эти цифры — ориентир, не точная публичная отчётность, но сама логика приоритизации именно такая.
Что сделали по итогам анализа.
— Перестроили онбординг: после верификации пользователю сразу показывали сценарий первого перевода по СБП с ограниченной акцией «без комиссии 30 дней».
— Подписку Плюс начали подсвечивать не в момент оплаты, а после первой удачной транзакции — когда человек уже почувствовал пользу.
— Performance-команды (закупка трафика в мобайл-сетях) получили отдельную сегментацию креативов: для аудитории, склонной к переводам, — один оффер, для аудитории кэшбэк-шопоголиков — другой.
Результат. Внутренние оценки, которые звучали на конференциях по продуктовой аналитике, показывали рост retention (удержания) на 7-й и 30-й день на 8–12% в когортах с новым онбордингом. Для экосистемы с десятками миллионов установок это прямой вклад в LTV и окупаемость performance-закупки. Команда Performance одновременно перешла на модели атрибуции с упором на MMM (маркетинг-микс-моделирование) и incrementality-тесты, потому что last-click в privacy-first реальности перестал объяснять реальность.
Урок. Amplitude здесь сыграл роль не «дашборда для дашборда», а инструмента перевода гипотезы в измеримое решение. Три принципа, которые работают в любой B2C и B2B-экосистеме:
— Смотрите на **первое действие**, а не на последнее. Оно предсказывает 30-дневное удержание сильнее, чем источник трафика.
— Сравнивайте когорты через stickiness и LTV, а не через конверсию в первую покупку — иначе оптимизируете не ту метрику.
— Передавайте вывод когортного анализа напрямую в креатив performance-команды. Иначе аналитика останется в Amplitude, а бюджеты продолжат лить в старые се
— @AmplitudeCookbookRuPro
Как удержать внимание пользователя в эпоху Zero-click: кейс оптимизации воронки через Amplitude
В 2026 году пользовательское поведение изменилось: из-за обилия AI-ответов (искусственного интеллекта) люди реже переходят на лендинги, предпочитая получать выжимку смыслов сразу. В условиях снижения среднего чека на 6%, критически важным становится не количество заходов, а глубина взаимодействия с продуктом. Рассмотрим кейс сервиса подписки на товары повседневного спроса, который столкнулся с падением LTV (пожизненной ценности клиента).
Контекст: компания заметила, что пользователи, приходящие через поисковые системы, совершают первую покупку, но процент возвратов (retention) на второй месяц упал на 14% год к году. Маркетинг-команда сфокусировалась на RevOps (объединенной системе управления выручкой), осознав, что классическая воронка от клика до покупки больше не гарантирует долгосрочный доход.
Задача: выявить «точки отвала» в сценарии повторного потребления и понять, какие действия в приложении коррелируют с удержанием в долгосрочной перспективе.
Решение: команда выгрузила данные в Amplitude и построила отчет Retention по когортам (группам пользователей, объединенных по времени регистрации), добавив событийный анализ. Выяснилось, что пользователи, которые в первые 48 часов после покупки использовали функцию «планировщик списка покупок», возвращаются на 32% чаще. Однако путь к этой функции был перегружен лишними шагами. Через воронку Funnel Analysis было найдено узкое место: 60% аудитории терялись на этапе настройки уведомлений о доставке. Аналитики упростили путь, сократив его с четырех экранов до одного с использованием AI-предзаполнения данных на основе истории прошлых заказов.
Результат: после внедрения упрощенного сценария Retention на второй месяц вырос на 9%, а показатель повторных продаж увеличился на 11%. Команда перераспределила бюджеты: вместо закупки трафика на привлечение новых пользователей, фокус сместился на активацию текущей базы через глубокую персонализацию в приложении.
Урок: в эпоху, когда поисковые системы дают ответы без переходов на сайт, ценность продукта сосредоточена внутри вашего приложения. Анализировать только первый заказ — значит терять деньги. Используйте Amplitude для поиска ключевого действия, которое привязывает пользователя к вашему бренду. Если вы не видите, что именно заставляет клиента возвращаться, вы работаете с воронкой вслепую, надеясь на удачу. В 2026 году успех измеряется не кликами, а тем, насколько глубоко пользователь интегрировал ваш сервис в свою ежедневную рутину.
— @AmplitudeCookbookRuPro
В 2026 году пользовательское поведение изменилось: из-за обилия AI-ответов (искусственного интеллекта) люди реже переходят на лендинги, предпочитая получать выжимку смыслов сразу. В условиях снижения среднего чека на 6%, критически важным становится не количество заходов, а глубина взаимодействия с продуктом. Рассмотрим кейс сервиса подписки на товары повседневного спроса, который столкнулся с падением LTV (пожизненной ценности клиента).
Контекст: компания заметила, что пользователи, приходящие через поисковые системы, совершают первую покупку, но процент возвратов (retention) на второй месяц упал на 14% год к году. Маркетинг-команда сфокусировалась на RevOps (объединенной системе управления выручкой), осознав, что классическая воронка от клика до покупки больше не гарантирует долгосрочный доход.
Задача: выявить «точки отвала» в сценарии повторного потребления и понять, какие действия в приложении коррелируют с удержанием в долгосрочной перспективе.
Решение: команда выгрузила данные в Amplitude и построила отчет Retention по когортам (группам пользователей, объединенных по времени регистрации), добавив событийный анализ. Выяснилось, что пользователи, которые в первые 48 часов после покупки использовали функцию «планировщик списка покупок», возвращаются на 32% чаще. Однако путь к этой функции был перегружен лишними шагами. Через воронку Funnel Analysis было найдено узкое место: 60% аудитории терялись на этапе настройки уведомлений о доставке. Аналитики упростили путь, сократив его с четырех экранов до одного с использованием AI-предзаполнения данных на основе истории прошлых заказов.
Результат: после внедрения упрощенного сценария Retention на второй месяц вырос на 9%, а показатель повторных продаж увеличился на 11%. Команда перераспределила бюджеты: вместо закупки трафика на привлечение новых пользователей, фокус сместился на активацию текущей базы через глубокую персонализацию в приложении.
Урок: в эпоху, когда поисковые системы дают ответы без переходов на сайт, ценность продукта сосредоточена внутри вашего приложения. Анализировать только первый заказ — значит терять деньги. Используйте Amplitude для поиска ключевого действия, которое привязывает пользователя к вашему бренду. Если вы не видите, что именно заставляет клиента возвращаться, вы работаете с воронкой вслепую, надеясь на удачу. В 2026 году успех измеряется не кликами, а тем, насколько глубоко пользователь интегрировал ваш сервис в свою ежедневную рутину.
— @AmplitudeCookbookRuPro
Nike и Amplitude: как сократить путь от просмотра до покупки без лишней рекламы
В 2026-м брендам всё сложнее опираться только на last-click-атрибуцию: пользователь видит креатив в ленте, изучает товар в приложении, возвращается через поиск, а покупку завершает уже после нескольких касаний. У Nike похожая задача стояла на стыке приложений, сайта и CRM: понять, какие действия реально ведут к покупке, а какие просто создают шум в отчётах.
**Контекст.** У Nike большая доля трафика идёт из performance-каналов, но классическая отчётность плохо показывает вклад разных шагов в воронке. Команда видела цифры по сессиям и заказам, но не понимала, где именно теряются люди: на выборе размера, в карточке товара или на этапе оплаты.
**Задача.** Снизить разрыв между интересом и покупкой и при этом не раздувать бюджеты на привлечение. В логике 2026 года это уже не про «добрать MQL», а про управление выручкой и удержанием в рамках общей RevOps-логики.
**Решение.** В Amplitude собрали единую событийную модель: просмотр товара, добавление в корзину, поиск по каталогу, выбор размера, старт оплаты, покупка. Дальше построили воронки и когорты, чтобы сравнить, какие сценарии чаще доходят до заказа. Отдельно посмотрели поведение новых и возвращающихся покупателей, а также влияние персональных рекомендаций на конверсию.
Что это дало по практике:
— стало видно, что часть пользователей «застревает» не на цене, а на отсутствии нужного размера;
— выяснилось, что повторный визит через сохранённый список желаний конвертирует заметно лучше, чем холодный повторный заход из рекламы;
— рекомендации в карточке товара помогали не всем одинаково: у части сегментов они ускоряли покупку, у части — только растягивали путь.
**Результат.** После переразметки воронки и пересборки сценариев коммуникации Nike смогла точнее распределять трафик и фокусироваться не на общем числе визитов, а на событиях, которые реально двигают к заказу. В таких кейсах обычно растёт не «активность», а качество конверсии: меньше пустых касаний, выше доля завершённых покупок, понятнее вклад каждого канала.
**Урок.** Если бренд работает в многоканальной среде, Amplitude нужен не для красивых графиков, а для ответа на три вопроса: где теряется спрос, какое действие сокращает путь к покупке и какой сегмент приносит выручку, а не просто трафик. В эпоху privacy-first атрибуции и AI-overviews выигрывает не тот, у кого больше отчётов, а тот, кто лучше связывает поведение пользователя с деньгами.
— @AmplitudeCookbookRuPro
В 2026-м брендам всё сложнее опираться только на last-click-атрибуцию: пользователь видит креатив в ленте, изучает товар в приложении, возвращается через поиск, а покупку завершает уже после нескольких касаний. У Nike похожая задача стояла на стыке приложений, сайта и CRM: понять, какие действия реально ведут к покупке, а какие просто создают шум в отчётах.
**Контекст.** У Nike большая доля трафика идёт из performance-каналов, но классическая отчётность плохо показывает вклад разных шагов в воронке. Команда видела цифры по сессиям и заказам, но не понимала, где именно теряются люди: на выборе размера, в карточке товара или на этапе оплаты.
**Задача.** Снизить разрыв между интересом и покупкой и при этом не раздувать бюджеты на привлечение. В логике 2026 года это уже не про «добрать MQL», а про управление выручкой и удержанием в рамках общей RevOps-логики.
**Решение.** В Amplitude собрали единую событийную модель: просмотр товара, добавление в корзину, поиск по каталогу, выбор размера, старт оплаты, покупка. Дальше построили воронки и когорты, чтобы сравнить, какие сценарии чаще доходят до заказа. Отдельно посмотрели поведение новых и возвращающихся покупателей, а также влияние персональных рекомендаций на конверсию.
Что это дало по практике:
— стало видно, что часть пользователей «застревает» не на цене, а на отсутствии нужного размера;
— выяснилось, что повторный визит через сохранённый список желаний конвертирует заметно лучше, чем холодный повторный заход из рекламы;
— рекомендации в карточке товара помогали не всем одинаково: у части сегментов они ускоряли покупку, у части — только растягивали путь.
**Результат.** После переразметки воронки и пересборки сценариев коммуникации Nike смогла точнее распределять трафик и фокусироваться не на общем числе визитов, а на событиях, которые реально двигают к заказу. В таких кейсах обычно растёт не «активность», а качество конверсии: меньше пустых касаний, выше доля завершённых покупок, понятнее вклад каждого канала.
**Урок.** Если бренд работает в многоканальной среде, Amplitude нужен не для красивых графиков, а для ответа на три вопроса: где теряется спрос, какое действие сокращает путь к покупке и какой сегмент приносит выручку, а не просто трафик. В эпоху privacy-first атрибуции и AI-overviews выигрывает не тот, у кого больше отчётов, а тот, кто лучше связывает поведение пользователя с деньгами.
— @AmplitudeCookbookRuPro
Ограничьте область Custom HTML в Google Tag Manager
Custom HTML в GTM удобно для быстрых внедрений, но у него есть побочный эффект: скрипт легко «засоряет» глобальное пространство имён страницы. Для аналитики это риск конфликтов, нестабильных событий и сложной отладки.
— Проверьте, нужен ли вообще Custom HTML.
Если задача решается встроенным тегом GTM или серверной отправкой событий, выбирайте их. Чем меньше самописного JavaScript на странице, тем ниже шанс сломать сбор данных.
— Изолируйте код в локальной области видимости.
Оберните логику в самовызывающуюся функцию или модуль, чтобы переменные не жили в `window`. Это снижает риск пересечений с кодом сайта, рекламными пикселями и другими тегами.
— Не создавайте глобальные переменные без необходимости.
Любое имя в `window` — это потенциальный конфликт при следующем релизе. Если переменная нужна только внутри тега, держите её внутри функции и не экспортируйте наружу.
— Передавайте данные явно, а не через «магические» переменные страницы.
Подтягивайте нужные значения из dataLayer, DOM или параметров тега. Так проще понять, откуда берётся событие, и проще воспроизводить ошибки.
— Тестируйте тег в изоляции до публикации.
Смотрите, не меняет ли он существующие события, не перезаписывает ли функции и не ломает ли другие теги. В 2026 году, когда атрибуция уходит в server-side и инкрементальность, чистая клиентская логика становится ещё важнее.
— Документируйте, что именно создаёт тег.
Запишите, какие переменные, функции и события он добавляет. Это экономит время маркетингу, разработке и аналитике при ревизии контейнера.
Когда это пригодится: при внедрении кастомных пикселей, нестандартных событий Amplitude, интеграции виджетов и любой клиентской логики, где важны стабильность и точность данных.
— @AmplitudeCookbookRuPro
Custom HTML в GTM удобно для быстрых внедрений, но у него есть побочный эффект: скрипт легко «засоряет» глобальное пространство имён страницы. Для аналитики это риск конфликтов, нестабильных событий и сложной отладки.
— Проверьте, нужен ли вообще Custom HTML.
Если задача решается встроенным тегом GTM или серверной отправкой событий, выбирайте их. Чем меньше самописного JavaScript на странице, тем ниже шанс сломать сбор данных.
— Изолируйте код в локальной области видимости.
Оберните логику в самовызывающуюся функцию или модуль, чтобы переменные не жили в `window`. Это снижает риск пересечений с кодом сайта, рекламными пикселями и другими тегами.
— Не создавайте глобальные переменные без необходимости.
Любое имя в `window` — это потенциальный конфликт при следующем релизе. Если переменная нужна только внутри тега, держите её внутри функции и не экспортируйте наружу.
— Передавайте данные явно, а не через «магические» переменные страницы.
Подтягивайте нужные значения из dataLayer, DOM или параметров тега. Так проще понять, откуда берётся событие, и проще воспроизводить ошибки.
— Тестируйте тег в изоляции до публикации.
Смотрите, не меняет ли он существующие события, не перезаписывает ли функции и не ломает ли другие теги. В 2026 году, когда атрибуция уходит в server-side и инкрементальность, чистая клиентская логика становится ещё важнее.
— Документируйте, что именно создаёт тег.
Запишите, какие переменные, функции и события он добавляет. Это экономит время маркетингу, разработке и аналитике при ревизии контейнера.
Когда это пригодится: при внедрении кастомных пикселей, нестандартных событий Amplitude, интеграции виджетов и любой клиентской логики, где важны стабильность и точность данных.
— @AmplitudeCookbookRuPro