Где возможностей Метрики недостаточно для продуктовых вопросов

Сначала честно: Яндекс Метрика — не «только маркетинг». По официальной документации в ней есть воронки, история посетителей и сессий с Webvisor и эксперименты Директа. Эти источники проверены 12.07.2026.

Что уже умеет Метрика

Метрика связывает трафик, цели и визиты; воронки показывают прохождение шагов, а раздел «Посетители» даёт перейти от агрегата к истории человека и записи его сессии. Для кампаний Директа есть сценарий экспериментов. Это полноценные возможности, а не маркетинговые ярлыки.

Когда нужен другой рабочий процесс

Граница проходит не по линии «Метрика — маркетинг, ActionPulse — продукт». Она зависит от вашей схемы событий, способа идентификации, горизонта анализа и нужных срезов. Отдельный инструмент имеет смысл рассматривать, если команде нужны:

• На каком шаге между «создал проект» и «пригласил коллегу» теряется больше всего людей?
• Какая доля майской когорты вернулась на четвёртой неделе?
• Отличается ли retention тех, кто прошёл онбординг, от тех, кто его пропустил?
• Можно ли повторить эти расчёты по SQL на исходных событиях?

Перед заменой инструмента попробуйте собрать эти отчёты в текущем стеке. Если цифры уже получаются, новая система не нужна только из-за ярлыка «продуктовая».

Что делать

Три шага, в этом порядке.

Перейти на событийную модель. Каждое ключевое действие — отдельное событие с именем и временем: signup_completed, project_created, payment_succeeded. Схема должна хранить данные, нужные для заранее согласованных отчётов.

Определить actor_id. Если это допустимо для вашей модели обработки данных, используйте стабильный псевдонимный идентификатор после логина и анонимный id до него. Схему склейки и сроки хранения нужно согласовать с требованиями к персональным данным.

Разметить ключевые действия. Не всё подряд, а 10–20 событий вокруг активации и оплаты. Десяток событий с понятными именами полезнее сотни автособранных кликов.

Метрику при этом никто не отменяет: её возможности могут закрыть и маркетинговые, и часть продуктовых сценариев. Если нужен другой контракт событий, retention, когорты или SQL, сравнивайте оба инструмента на одинаковом наборе событий и мигрируйте только после сверки.