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