Amplitude cookbook: как мы диагностировали “провал в воронке” на этапе активации и вернули рост активаций в B2B SaaS
Компания/бренд: B2B SaaS (продукт для аналитики и операционной отчётности в компаниях)
Задача
Партнёрская коммуникация (вебинары + контентные рассылки) привела поток регистраций, но команда продаж фиксировала: **часть пользователей не доходила до активации** (первого “полезного действия” в продукте), а значит, конверсия в MQL/SQL проседала. В терминах 2026 года это типичный сдвиг: классическая лидогенерация слабее, выигрывает тот, кто быстрее превращает интерес в ценность для пользователя — через активацию и дальнейшее удержание.
Решение в Amplitude (разбор по шагам)
1) Зафиксировали “активацию” как событие
Чтобы не спорить о субъективности, в продуктовой аналитике определили активацию строго как событие “First Value Action” (например: подключение источника данных + создание первого отчёта). Важно: измеряли не “визит на страницу”, а действие, которое коррелирует с последующей ценностью.
2) Построили воронку с разрезом по источнику привлечения
Воронка: Registration → Activation.
Добавили разрезы:
— канал первого касания (кампании вебинаров, рассылки, organic),
— тип аккаунта (SMB/Enterprise по плану или признаку в CRM),
— устройство/браузер.
Задача была не “поймать виноватого”, а понять, где именно ломается процесс: на регистрации или дальше.
3) Сделали cohort-нарезку по дате регистрации и “провал по времени”
На графике когорт увидели характерный эффект: падение активаций не было постоянным — оно концентрировалось в конкретных неделях. Это подсказало, что проблема может быть в изменениях продукта/онбординга или в аудитории кампаний (например, расширили таргетинг).
4) Сравнили поведение “неактивировавшихся” сегментов
Дальше разложили путь пользователя после регистрации:
— какие шаги выполнялись,
— где они “застревали” (время до события, частота попыток, доля отмен),
— какие элементы онбординга не приводили к действию.
Здесь Amplitude помог тем, что можно быстро проверить гипотезы без ручного просмотра сессий: какие события в продукте идут “до” активации и насколько они обязательны.
5) Проверили качество данных и события до вывода “вина”
Перед правками в продукте убедились, что проблема не в трекинге:
— корректность названий событий,
— одинаковые свойства (например, план/роль пользователя),
— отсутствие дублирования или пропусков.
На практике часто выясняется: “воронка упала”, но на самом деле изменился схематичный параметр в событии.
Конкретный результат
После корректировки онбординга (упростили первый шаг и убрали 1 лишнее подтверждение в сценарии подключения; плюс добавили подсказку пользователям, которые чаще всего “зависали” на предпоследнем экране) доля пользователей, дошедших до **активации**, выросла.
Что важно: рост держался именно в тех когортных группах, где ранее наблюдался провал, то есть это было похоже на эффект от изменений, а не на сезонность.
Уроки для читателя (Amplitude-подход)
— “Провал в воронке” почти всегда локализуется: сначала фиксируйте событие активации, потом смотрите воронку по разрезам и когортам, а не на общем сводном графике.
— В B2B SaaS ответственность за выручку становится общей (маркетинг + продажи + customer success), поэтому активация — это мост между лидом и продажей: улучшения онбординга дают прибыльнее эффекта, чем бесконечная оптимизация верхней части воронки.
— Если причина не очевидна, начинайте с проверки данных: трекинг и свойства событий — первое, что нужно исключить, прежде чем чинить продукт.
Если хотите, в следующем посте разберу шаблон “диагностической воронки” в Amplitude: какие разрезы добавить для B2B SaaS, и какие события стоит связать с активацией, чтобы не измерять “активность ради активности”.
— @AmplitudeCookbookRuPro
Компания/бренд: B2B SaaS (продукт для аналитики и операционной отчётности в компаниях)
Задача
Партнёрская коммуникация (вебинары + контентные рассылки) привела поток регистраций, но команда продаж фиксировала: **часть пользователей не доходила до активации** (первого “полезного действия” в продукте), а значит, конверсия в MQL/SQL проседала. В терминах 2026 года это типичный сдвиг: классическая лидогенерация слабее, выигрывает тот, кто быстрее превращает интерес в ценность для пользователя — через активацию и дальнейшее удержание.
Решение в Amplitude (разбор по шагам)
1) Зафиксировали “активацию” как событие
Чтобы не спорить о субъективности, в продуктовой аналитике определили активацию строго как событие “First Value Action” (например: подключение источника данных + создание первого отчёта). Важно: измеряли не “визит на страницу”, а действие, которое коррелирует с последующей ценностью.
2) Построили воронку с разрезом по источнику привлечения
Воронка: Registration → Activation.
Добавили разрезы:
— канал первого касания (кампании вебинаров, рассылки, organic),
— тип аккаунта (SMB/Enterprise по плану или признаку в CRM),
— устройство/браузер.
Задача была не “поймать виноватого”, а понять, где именно ломается процесс: на регистрации или дальше.
3) Сделали cohort-нарезку по дате регистрации и “провал по времени”
На графике когорт увидели характерный эффект: падение активаций не было постоянным — оно концентрировалось в конкретных неделях. Это подсказало, что проблема может быть в изменениях продукта/онбординга или в аудитории кампаний (например, расширили таргетинг).
4) Сравнили поведение “неактивировавшихся” сегментов
Дальше разложили путь пользователя после регистрации:
— какие шаги выполнялись,
— где они “застревали” (время до события, частота попыток, доля отмен),
— какие элементы онбординга не приводили к действию.
Здесь Amplitude помог тем, что можно быстро проверить гипотезы без ручного просмотра сессий: какие события в продукте идут “до” активации и насколько они обязательны.
5) Проверили качество данных и события до вывода “вина”
Перед правками в продукте убедились, что проблема не в трекинге:
— корректность названий событий,
— одинаковые свойства (например, план/роль пользователя),
— отсутствие дублирования или пропусков.
На практике часто выясняется: “воронка упала”, но на самом деле изменился схематичный параметр в событии.
Конкретный результат
После корректировки онбординга (упростили первый шаг и убрали 1 лишнее подтверждение в сценарии подключения; плюс добавили подсказку пользователям, которые чаще всего “зависали” на предпоследнем экране) доля пользователей, дошедших до **активации**, выросла.
Что важно: рост держался именно в тех когортных группах, где ранее наблюдался провал, то есть это было похоже на эффект от изменений, а не на сезонность.
Уроки для читателя (Amplitude-подход)
— “Провал в воронке” почти всегда локализуется: сначала фиксируйте событие активации, потом смотрите воронку по разрезам и когортам, а не на общем сводном графике.
— В B2B SaaS ответственность за выручку становится общей (маркетинг + продажи + customer success), поэтому активация — это мост между лидом и продажей: улучшения онбординга дают прибыльнее эффекта, чем бесконечная оптимизация верхней части воронки.
— Если причина не очевидна, начинайте с проверки данных: трекинг и свойства событий — первое, что нужно исключить, прежде чем чинить продукт.
Если хотите, в следующем посте разберу шаблон “диагностической воронки” в Amplitude: какие разрезы добавить для B2B SaaS, и какие события стоит связать с активацией, чтобы не измерять “активность ради активности”.
— @AmplitudeCookbookRuPro
Amplitude cookbook: почему я перестал смотреть на «конверсию по воронке» и начал строить диагностические когорты
В Амплитуде у команды почти всегда есть один любимый отчет: воронка с конверсией «из шага A в шаг B». Это удобно для презентаций и всегда проигрывает в диагностике. В 2026 году (когда поисковый спрос дробится, креативы производятся быстрее, а privacy-first атрибуция стирает часть сигналов) воронка без когорт — это красивая картинка, но не инструмент управления.
Моя позиция простая: я рассматриваю воронку только как справку, а решение принимаю на основании диагностических когорт и их поведения во времени.
Что я меняю в Amplitude на практике
1) Вместо «конверсия за период» я строю когорту по событию входа
Например:
— когорта: пользователей, которые сделали событие `Signup Started` за неделю N
— сравнение: как они доходят до `Payment Submitted` / `Purchase Completed` на разных «днях после старта»
Так я вижу, что происходит не “в среднем”, а с группами, которые действительно столкнулись с фрикцией в разное время.
2) Я разделяю «проблему привлечения» и «проблему активации» через retention в пределах онбординга
На языке Amplitude это выглядит так: я смотрю не на факт выполнения шага B, а на долю людей, которые возвращаются к продукту после шага A.
— когорта по `Signup Started`
— метрика: доля, совершившая повторное действие (например, `Profile Completed` или `Checkout Started`) в течение 1–3 дней
Если повторные попытки есть — значит продукт не “непонятный”, проблема скорее в том, что часть людей не проходит именно ключевой барьер на конкретном шаге (форма, выбор, валидация, загрузка). Если повторных попыток нет — проблема чаще в качестве входа или в том, что человек не получил обещание, которое ожидал.
3) Я включаю “контрольные” сегменты, а не только целевую аудиторию
Чтобы не попасть в ловушку “все плохо, значит надо ребрендить”, я сравниваю как минимум две группы:
— пользователи из сегмента «известная технология/канал» (где атрибуция обычно надежнее на уровне источника)
— пользователи из остального трафика (где данных меньше)
Суть не в том, чтобы “доказать виноватый канал”. Суть — проверить, одинаков ли паттерн фрикции по времени. В одном из наших проектов паттерн был одинаковым: воронка по шагу оплаты падала у всех, но у части сегментов люди возвращались на второй день. Значит, не “качество трафика”, а временная нестабильность/ошибка на шаге — и дальше мы уже копали технически, по событиям и их последовательностям.
4) Я строю диагностические последовательности, а не “next event”
Вместо стандартного “что было дальше по порядку” я смотрю последовательности с окнами:
— `Checkout Started` → (в течение 30 минут) `Payment Method Selected`
— затем `Payment Method Selected` → `Payment Submitted` (в течение 60 минут)
Почему это важно: многие сбои в реальности проявляются не как “человек ушел”, а как “он завис на выборе/валидации”. Такие вещи теряются, если просто смотреть next step без времени.
Один практический ориентир (из моей работы)
Когда мы в Amplitude перешли от “воронки за месяц” к когорте по `Checkout Started` и измерению “вернулся ли человек за 24 часа”, мы перестали спорить о “конверсия просела из‑за креатива” и нашли точечную причину: событие, связанное с подтверждением способа оплаты, с определенных устройств фиксировалось с задержкой или не фиксировалось вообще. Итог — исправление в трекинге и синхронизация событий дала прирост не только по конверсии шага, но и по retention онбординга (люди перестали бросать процесс на середине).
Как это оформить в Amplitude за один рабочий цикл
— Создайте когорты по событию входа (A), за неделю/две
— Постройте кривые достижения шагов B/C в разрезе “дней после A”
— Добавьте сегменты по критичным параметрам (устройство, план/тип аккаунта, роль в B2B — кто создает сессию)
— Сравните: где провал “сразу” (ранняя активация) и где “после” (обучение/возврат/фрикция)
…
В Амплитуде у команды почти всегда есть один любимый отчет: воронка с конверсией «из шага A в шаг B». Это удобно для презентаций и всегда проигрывает в диагностике. В 2026 году (когда поисковый спрос дробится, креативы производятся быстрее, а privacy-first атрибуция стирает часть сигналов) воронка без когорт — это красивая картинка, но не инструмент управления.
Моя позиция простая: я рассматриваю воронку только как справку, а решение принимаю на основании диагностических когорт и их поведения во времени.
Что я меняю в Amplitude на практике
1) Вместо «конверсия за период» я строю когорту по событию входа
Например:
— когорта: пользователей, которые сделали событие `Signup Started` за неделю N
— сравнение: как они доходят до `Payment Submitted` / `Purchase Completed` на разных «днях после старта»
Так я вижу, что происходит не “в среднем”, а с группами, которые действительно столкнулись с фрикцией в разное время.
2) Я разделяю «проблему привлечения» и «проблему активации» через retention в пределах онбординга
На языке Amplitude это выглядит так: я смотрю не на факт выполнения шага B, а на долю людей, которые возвращаются к продукту после шага A.
— когорта по `Signup Started`
— метрика: доля, совершившая повторное действие (например, `Profile Completed` или `Checkout Started`) в течение 1–3 дней
Если повторные попытки есть — значит продукт не “непонятный”, проблема скорее в том, что часть людей не проходит именно ключевой барьер на конкретном шаге (форма, выбор, валидация, загрузка). Если повторных попыток нет — проблема чаще в качестве входа или в том, что человек не получил обещание, которое ожидал.
3) Я включаю “контрольные” сегменты, а не только целевую аудиторию
Чтобы не попасть в ловушку “все плохо, значит надо ребрендить”, я сравниваю как минимум две группы:
— пользователи из сегмента «известная технология/канал» (где атрибуция обычно надежнее на уровне источника)
— пользователи из остального трафика (где данных меньше)
Суть не в том, чтобы “доказать виноватый канал”. Суть — проверить, одинаков ли паттерн фрикции по времени. В одном из наших проектов паттерн был одинаковым: воронка по шагу оплаты падала у всех, но у части сегментов люди возвращались на второй день. Значит, не “качество трафика”, а временная нестабильность/ошибка на шаге — и дальше мы уже копали технически, по событиям и их последовательностям.
4) Я строю диагностические последовательности, а не “next event”
Вместо стандартного “что было дальше по порядку” я смотрю последовательности с окнами:
— `Checkout Started` → (в течение 30 минут) `Payment Method Selected`
— затем `Payment Method Selected` → `Payment Submitted` (в течение 60 минут)
Почему это важно: многие сбои в реальности проявляются не как “человек ушел”, а как “он завис на выборе/валидации”. Такие вещи теряются, если просто смотреть next step без времени.
Один практический ориентир (из моей работы)
Когда мы в Amplitude перешли от “воронки за месяц” к когорте по `Checkout Started` и измерению “вернулся ли человек за 24 часа”, мы перестали спорить о “конверсия просела из‑за креатива” и нашли точечную причину: событие, связанное с подтверждением способа оплаты, с определенных устройств фиксировалось с задержкой или не фиксировалось вообще. Итог — исправление в трекинге и синхронизация событий дала прирост не только по конверсии шага, но и по retention онбординга (люди перестали бросать процесс на середине).
Как это оформить в Amplitude за один рабочий цикл
— Создайте когорты по событию входа (A), за неделю/две
— Постройте кривые достижения шагов B/C в разрезе “дней после A”
— Добавьте сегменты по критичным параметрам (устройство, план/тип аккаунта, роль в B2B — кто создает сессию)
— Сравните: где провал “сразу” (ранняя активация) и где “после” (обучение/возврат/фрикция)
…
Amplitude — не про «события», а про управляемую правду: как я перестраиваю продуктовую аналитику под RevOps
В 2026 я всё чаще вижу одну и ту же ошибку в настройке Amplitude: события собирают как список того, что “может быть полезным”, а не как модель того, что реально двигает выручку. В результате отчёты красивы, дашборды насыщены, но вопрос “почему упала конверсия в оплату/пробу?” остаётся без ответа. Потому что данных не хватает не там, где кажется, а в местах управленческой логики.
Я перестраиваю продуктовую аналитику так: сначала фиксирую последовательность ценности (value journey) не “по экранчикам”, а по решениям пользователя. Затем уже под эту последовательность раскладываю события в Amplitude. Только так можно связать поведение продукта с коммерческими метриками — и не скатиться в last-click-магии, которые privacy-first эпоха всё хуже тянет.
Практика из команды, где мы “лечили” не трекинг, а разрыв между маркетингом и продуктом. Проблема: маркетинг обвинял продукт, продукт обвинял аналитику, а цифры упирались в MQL/SQL, которые начали расплываться. Мы не спорили, мы построили единый путь: активация → первая ценность → повторное использование → готовность к коммерческому шагу. И оказалось, что провал был не в “входе”, а в моменте, когда пользователь должен понять ценность без участия менеджера.
Как именно я это делаю в Amplitude (без “магии” и без лишних событий):
1) Определяю 3–5 бизнес-решений вместо 20–30 продуктовых действий
Пример для B2B-сервиса: “выбрал сценарий”, “подключил ключевой источник данных”, “создал первый артефакт”, “вернулся и использовал результат”. Это решения, которые можно сравнить между когортами.
2) Строю события вокруг этих решений, а не вокруг кликов
Клик “Открыть форму” сам по себе не отвечает на вопрос. В Amplitude я добиваюсь, чтобы событие означало факт достижения намерения: например, “Artifact_created” или “Source_connected_success”. Если событие не имеет бизнес-смысла, оно не должно быть in the critical path.
3) Включаю “момент истины” в воронку через группы событий, а не через один шаг
В Amplitude удобно собирать воронки так, чтобы шаг был не одним событием, а условием: “в течение 24 часов после Source_connected_success пользователь совершил Artifact_created И вернулся (Return_to_product)”. Это снижает шум от случайных сессий и лучше отражает реальную динамику принятия решения.
4) Ставлю измерение качества данных как KPI
Моя минимальная метрика качества трекинга: доля событий, у которых заполнены нужные свойства (properties). Например, “plan_type”, “scenario_type”, “entry_channel”, “org_size”. У нас однажды выяснилось, что до 18% событий “создания артефакта” приходили без scenario_type — и все сегментации “по сценарию” стали статистической иллюзией. Как только мы поправили схему отправки — сегменты ожили и модель причинности начала сходиться.
Почему это важно именно под RevOps:
— В 2026 маркетинг отвечает за выручку вместе с продажами и customer success, а значит аналитика должна отвечать на вопрос “где в journey ломается ценность” до того, как пользователь превращается в MQL/SQL или становится проблемой CS.
— Когда атрибуция размывается (server-side, MMM, incrementality вытесняют last-click), поведение в продукте становится главным источником управляемой правды. Именно поэтому value journey — это фундамент, а не “красивый график”.
Один принцип, который я повторяю каждый раз при ревизии Amplitude: **не увеличивайте количество событий — увеличивайте точность смыслов**. Если у вас сейчас сотни событий, но воронка по бизнес-решениям всё равно “не бьётся” — значит проблема не в количестве, а в определениях шагов и свойствах, которые позволяют сегментировать пользователей так, чтобы сравнение было честным.
Если хотите, в следующем посте разберу шаблон того, как я оформляю список “бизнес-решений” и соответствующие event-schemas под конкретный тип продукта (e-com, B2B SaaS, marketplace) — и как это переводить в Amplitude funnels + cohorts, чтобы у RevOps появился общий язык.
— @AmplitudeCookbookRuPro
В 2026 я всё чаще вижу одну и ту же ошибку в настройке Amplitude: события собирают как список того, что “может быть полезным”, а не как модель того, что реально двигает выручку. В результате отчёты красивы, дашборды насыщены, но вопрос “почему упала конверсия в оплату/пробу?” остаётся без ответа. Потому что данных не хватает не там, где кажется, а в местах управленческой логики.
Я перестраиваю продуктовую аналитику так: сначала фиксирую последовательность ценности (value journey) не “по экранчикам”, а по решениям пользователя. Затем уже под эту последовательность раскладываю события в Amplitude. Только так можно связать поведение продукта с коммерческими метриками — и не скатиться в last-click-магии, которые privacy-first эпоха всё хуже тянет.
Практика из команды, где мы “лечили” не трекинг, а разрыв между маркетингом и продуктом. Проблема: маркетинг обвинял продукт, продукт обвинял аналитику, а цифры упирались в MQL/SQL, которые начали расплываться. Мы не спорили, мы построили единый путь: активация → первая ценность → повторное использование → готовность к коммерческому шагу. И оказалось, что провал был не в “входе”, а в моменте, когда пользователь должен понять ценность без участия менеджера.
Как именно я это делаю в Amplitude (без “магии” и без лишних событий):
1) Определяю 3–5 бизнес-решений вместо 20–30 продуктовых действий
Пример для B2B-сервиса: “выбрал сценарий”, “подключил ключевой источник данных”, “создал первый артефакт”, “вернулся и использовал результат”. Это решения, которые можно сравнить между когортами.
2) Строю события вокруг этих решений, а не вокруг кликов
Клик “Открыть форму” сам по себе не отвечает на вопрос. В Amplitude я добиваюсь, чтобы событие означало факт достижения намерения: например, “Artifact_created” или “Source_connected_success”. Если событие не имеет бизнес-смысла, оно не должно быть in the critical path.
3) Включаю “момент истины” в воронку через группы событий, а не через один шаг
В Amplitude удобно собирать воронки так, чтобы шаг был не одним событием, а условием: “в течение 24 часов после Source_connected_success пользователь совершил Artifact_created И вернулся (Return_to_product)”. Это снижает шум от случайных сессий и лучше отражает реальную динамику принятия решения.
4) Ставлю измерение качества данных как KPI
Моя минимальная метрика качества трекинга: доля событий, у которых заполнены нужные свойства (properties). Например, “plan_type”, “scenario_type”, “entry_channel”, “org_size”. У нас однажды выяснилось, что до 18% событий “создания артефакта” приходили без scenario_type — и все сегментации “по сценарию” стали статистической иллюзией. Как только мы поправили схему отправки — сегменты ожили и модель причинности начала сходиться.
Почему это важно именно под RevOps:
— В 2026 маркетинг отвечает за выручку вместе с продажами и customer success, а значит аналитика должна отвечать на вопрос “где в journey ломается ценность” до того, как пользователь превращается в MQL/SQL или становится проблемой CS.
— Когда атрибуция размывается (server-side, MMM, incrementality вытесняют last-click), поведение в продукте становится главным источником управляемой правды. Именно поэтому value journey — это фундамент, а не “красивый график”.
Один принцип, который я повторяю каждый раз при ревизии Amplitude: **не увеличивайте количество событий — увеличивайте точность смыслов**. Если у вас сейчас сотни событий, но воронка по бизнес-решениям всё равно “не бьётся” — значит проблема не в количестве, а в определениях шагов и свойствах, которые позволяют сегментировать пользователей так, чтобы сравнение было честным.
Если хотите, в следующем посте разберу шаблон того, как я оформляю список “бизнес-решений” и соответствующие event-schemas под конкретный тип продукта (e-com, B2B SaaS, marketplace) — и как это переводить в Amplitude funnels + cohorts, чтобы у RevOps появился общий язык.
— @AmplitudeCookbookRuPro
Проверяйте GTM до выката: как выстроить QA через Environments
Если у вас в Google Tag Manager несколько людей трогают один контейнер, без отдельной среды тестирования быстро начинаются сюрпризы: не тот тег, не тот триггер, не та версия. Режимы Environments как раз нужны, чтобы разнести разработку, проверку и прод.
— Создайте отдельные среды для работы.
Обычно хватает минимум двух контуров: тестовый и боевой.
Так вы не гоняете черновые изменения сразу на сайт с живым трафиком.
— Привяжите каждую среду к своему фрагменту кода.
У GTM для каждой среды свой snippet — его ставят только на нужный контур.
Это позволяет проверять контейнер на staging-сайте, не затрагивая прод.
— Публикуйте изменения только после проверки в нужной среде.
Сначала грузите новую версию в тестовый контур и смотрите, как она ведёт себя в браузере.
Ловите ошибки в триггерах, переменных и передаче событий до релиза.
— Сверяйте, что данные доходят туда, куда вы задумали.
Проверяйте не только факт срабатывания тега, но и параметры события, user properties и порядок отправки.
Для аналитики это критично: одна ошибка в разметке ломает отчёты в Amplitude дальше по цепочке.
— Разделяйте ответственность между командами.
Маркетинг, аналитика и разработка должны понимать, кто меняет что именно и в какой среде.
Так QA становится не ручной «проверкой на глаз», а повторяемым процессом.
— Документируйте, какая версия где живёт.
Фиксируйте, какой контейнер и какая среда соответствуют staging, production и внутреннему тесту.
Это экономит время, когда нужно откатить изменение или быстро найти источник ошибки.
Когда это пригодится: при частых правках GTM, перед запуском новых событий в Amplitude и в командах, где несколько специалистов одновременно работают с одной аналитической разметкой.
— @AmplitudeCookbookRuPro
Если у вас в Google Tag Manager несколько людей трогают один контейнер, без отдельной среды тестирования быстро начинаются сюрпризы: не тот тег, не тот триггер, не та версия. Режимы Environments как раз нужны, чтобы разнести разработку, проверку и прод.
— Создайте отдельные среды для работы.
Обычно хватает минимум двух контуров: тестовый и боевой.
Так вы не гоняете черновые изменения сразу на сайт с живым трафиком.
— Привяжите каждую среду к своему фрагменту кода.
У GTM для каждой среды свой snippet — его ставят только на нужный контур.
Это позволяет проверять контейнер на staging-сайте, не затрагивая прод.
— Публикуйте изменения только после проверки в нужной среде.
Сначала грузите новую версию в тестовый контур и смотрите, как она ведёт себя в браузере.
Ловите ошибки в триггерах, переменных и передаче событий до релиза.
— Сверяйте, что данные доходят туда, куда вы задумали.
Проверяйте не только факт срабатывания тега, но и параметры события, user properties и порядок отправки.
Для аналитики это критично: одна ошибка в разметке ломает отчёты в Amplitude дальше по цепочке.
— Разделяйте ответственность между командами.
Маркетинг, аналитика и разработка должны понимать, кто меняет что именно и в какой среде.
Так QA становится не ручной «проверкой на глаз», а повторяемым процессом.
— Документируйте, какая версия где живёт.
Фиксируйте, какой контейнер и какая среда соответствуют staging, production и внутреннему тесту.
Это экономит время, когда нужно откатить изменение или быстро найти источник ошибки.
Когда это пригодится: при частых правках GTM, перед запуском новых событий в Amplitude и в командах, где несколько специалистов одновременно работают с одной аналитической разметкой.
— @AmplitudeCookbookRuPro
Атрибуция в эпоху без файлов cookie
В мире, где last-click (атрибуция по последнему клику) окончательно теряет точность, фокус смещается на маркетинговое моделирование микса и инкрементальность. Как вы перестраиваете аналитику в Amplitude?
ВАРИАНТЫ:
1. Переходим на server-side (серверную) передачу событий
2. Внедряем прогнозную аналитику по LTV (пожизненной ценности)
3. Доверяем только сквозной аналитике по RevOps
4. Тестируем incremental lift (прирост от рекламы)
— @AmplitudeCookbookRuPro
В мире, где last-click (атрибуция по последнему клику) окончательно теряет точность, фокус смещается на маркетинговое моделирование микса и инкрементальность. Как вы перестраиваете аналитику в Amplitude?
ВАРИАНТЫ:
1. Переходим на server-side (серверную) передачу событий
2. Внедряем прогнозную аналитику по LTV (пожизненной ценности)
3. Доверяем только сквозной аналитике по RevOps
4. Тестируем incremental lift (прирост от рекламы)
— @AmplitudeCookbookRuPro
Доступ к членам массива в Data Layer (для чистых событий в Amplitude)
Чтобы события в Amplitude собирались без “дыр”, важно корректно читать структуру из Data Layer. Если в пуше вы отправляете массив (например, список продуктов, категорий, параметров кампании), берите элементы по индексу.
— 1) Определите, что именно хранится в Data Layer
Проверьте, есть ли поле, где лежит массив: например, productIds, categories или items. Запишите точное имя переменной и структуру (массив внутри объекта или просто массив).
— 2) Доступ к элементам массива делайте по индексу
В JavaScript значение элемента берите через квадратные скобки: `arr[0]` — первый элемент (индексация с нуля). Для второго — `arr[1]`, для третьего — `arr[2]`.
— 3) В GTM извлеките нужный индекс через Variable (переменная)
Создайте переменную GTM типа “Custom JavaScript” или аналогичную и внутри обратитесь к массиву: `dataLayer.find(...)[INDEX]` (или к конкретному полю, если оно уже доступно). Индекс подставляйте явно.
— 4) Передайте в Amplitude не весь массив, а строго нужные элементы
Amplitude удобнее получать плоские параметры: например, `first_product_id`, `primary_category`. Если вы шлёте “сырой” массив как строку — часто получаются разные форматы и теряется качество анализа.
— 5) Защититесь от пустых массивов и отсутствующих элементов
Добавьте проверки: если `arr.length > INDEX`, иначе возвращайте `undefined` или пропускайте параметр. Так вы избегаете “сваливания” отчётов из‑за неверных значений.
— 6) Согласуйте схему параметров с вашей моделью аналитики
Решите, какой индекс соответствует вашей логике (например, “главный продукт” = первый элемент). Закрепите это в спецификации событий, чтобы RevOps и аналитики не трактовали порядок по-разному.
— 7) Проверьте, что значение реально доходит до Amplitude
Включите debug-поток в GTM и проверьте отображение параметров в Amplitude для одного пользователя/сессии. Смотрите именно конкретный параметр по индексу, а не общий payload.
когда это пригодится: когда в Data Layer вы пушите массивы и нужно извлечь 1–2 ключевых значения, чтобы событие в Amplitude оставалось стабильным для когорт, funnel и удержания.
— @AmplitudeCookbookRuPro
Чтобы события в Amplitude собирались без “дыр”, важно корректно читать структуру из Data Layer. Если в пуше вы отправляете массив (например, список продуктов, категорий, параметров кампании), берите элементы по индексу.
— 1) Определите, что именно хранится в Data Layer
Проверьте, есть ли поле, где лежит массив: например, productIds, categories или items. Запишите точное имя переменной и структуру (массив внутри объекта или просто массив).
— 2) Доступ к элементам массива делайте по индексу
В JavaScript значение элемента берите через квадратные скобки: `arr[0]` — первый элемент (индексация с нуля). Для второго — `arr[1]`, для третьего — `arr[2]`.
— 3) В GTM извлеките нужный индекс через Variable (переменная)
Создайте переменную GTM типа “Custom JavaScript” или аналогичную и внутри обратитесь к массиву: `dataLayer.find(...)[INDEX]` (или к конкретному полю, если оно уже доступно). Индекс подставляйте явно.
— 4) Передайте в Amplitude не весь массив, а строго нужные элементы
Amplitude удобнее получать плоские параметры: например, `first_product_id`, `primary_category`. Если вы шлёте “сырой” массив как строку — часто получаются разные форматы и теряется качество анализа.
— 5) Защититесь от пустых массивов и отсутствующих элементов
Добавьте проверки: если `arr.length > INDEX`, иначе возвращайте `undefined` или пропускайте параметр. Так вы избегаете “сваливания” отчётов из‑за неверных значений.
— 6) Согласуйте схему параметров с вашей моделью аналитики
Решите, какой индекс соответствует вашей логике (например, “главный продукт” = первый элемент). Закрепите это в спецификации событий, чтобы RevOps и аналитики не трактовали порядок по-разному.
— 7) Проверьте, что значение реально доходит до Amplitude
Включите debug-поток в GTM и проверьте отображение параметров в Amplitude для одного пользователя/сессии. Смотрите именно конкретный параметр по индексу, а не общий payload.
когда это пригодится: когда в Data Layer вы пушите массивы и нужно извлечь 1–2 ключевых значения, чтобы событие в Amplitude оставалось стабильным для когорт, funnel и удержания.
— @AmplitudeCookbookRuPro
Как Amplitude помог понять, почему пользователи не доходят до активации
У многих B2B-продуктов проблема не в трафике, а в том, что пользователь заходит и «застревает» до первой ценности. Формально регистрация есть, а дальше — тишина. В 2026-м, когда классическая воронка MQL→SQL слабеет, такие провалы особенно дорого обходятся: маркетинг приводит не лид, а будущую выручку, и терять её на первом шаге слишком дорого.
В одном из кейсов команда продукта подключила Amplitude, чтобы разобрать путь пользователя не на уровне общих цифр, а по событиям. Задача была простой по формулировке и сложной по сути: понять, где именно ломается активация, и какие действия реально связаны с переходом к целевому поведению.
Что сделали:
— собрали последовательность ключевых событий в первые минуты и первые дни после регистрации;
— посмотрели не только общий конверсионный процент, но и сегменты по источникам трафика, устройствам и первым действиям;
— выделили шаги, после которых вероятность дойти до активации заметно менялась;
— сравнили поведение тех, кто дошёл до целевого действия, и тех, кто ушёл раньше.
Результат был не в «магической кнопке», а в точной диагностике: команда увидела, какие первые действия создают максимальный шанс на активацию, а какие только имитируют вовлечённость. Это позволило не распылять усилия на весь поток пользователей, а переделать онбординг и коммуникации вокруг самых важных шагов.
**Главный урок для маркетолога и продуктовой команды:** в аналитике ценность не в том, чтобы смотреть на общую конверсию, а в том, чтобы найти событие-предиктор — действие, которое лучше всего объясняет дальнейшее поведение. В эпоху privacy-first атрибуции и слабого last-click это особенно важно: побеждает не тот, кто «привёл больше», а тот, кто быстрее понял, где возникает реальная ценность.
Если у вас тоже проседает активация, начните не с новых кампаний, а с разборки первых 3–5 шагов в Amplitude. Часто ответ уже там.
— @AmplitudeCookbookRuPro
У многих B2B-продуктов проблема не в трафике, а в том, что пользователь заходит и «застревает» до первой ценности. Формально регистрация есть, а дальше — тишина. В 2026-м, когда классическая воронка MQL→SQL слабеет, такие провалы особенно дорого обходятся: маркетинг приводит не лид, а будущую выручку, и терять её на первом шаге слишком дорого.
В одном из кейсов команда продукта подключила Amplitude, чтобы разобрать путь пользователя не на уровне общих цифр, а по событиям. Задача была простой по формулировке и сложной по сути: понять, где именно ломается активация, и какие действия реально связаны с переходом к целевому поведению.
Что сделали:
— собрали последовательность ключевых событий в первые минуты и первые дни после регистрации;
— посмотрели не только общий конверсионный процент, но и сегменты по источникам трафика, устройствам и первым действиям;
— выделили шаги, после которых вероятность дойти до активации заметно менялась;
— сравнили поведение тех, кто дошёл до целевого действия, и тех, кто ушёл раньше.
Результат был не в «магической кнопке», а в точной диагностике: команда увидела, какие первые действия создают максимальный шанс на активацию, а какие только имитируют вовлечённость. Это позволило не распылять усилия на весь поток пользователей, а переделать онбординг и коммуникации вокруг самых важных шагов.
**Главный урок для маркетолога и продуктовой команды:** в аналитике ценность не в том, чтобы смотреть на общую конверсию, а в том, чтобы найти событие-предиктор — действие, которое лучше всего объясняет дальнейшее поведение. В эпоху privacy-first атрибуции и слабого last-click это особенно важно: побеждает не тот, кто «привёл больше», а тот, кто быстрее понял, где возникает реальная ценность.
Если у вас тоже проседает активация, начните не с новых кампаний, а с разборки первых 3–5 шагов в Amplitude. Часто ответ уже там.
— @AmplitudeCookbookRuPro
Смерть атрибуции по последнему клику
В эпоху маркетинга, ориентированного на выручку (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