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

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

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

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

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

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

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

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

Что делать

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

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

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

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

Сравнивайте на одинаковом вопросе

Список функций поставщика мало говорит о пригодности для вашей команды. Подготовьте несколько рабочих задач:

построить путь от регистрации до первого результата;
посчитать удержание одной когорты;
сравнить роли или тарифы;
открыть историю участников, остановившихся между шагами;
проверить агрегат по исходным данным;
выгрузить результат или события в нужном формате.

Сравнивайте определение, время настройки, проверяемость и ограничения, а не только внешний вид отчёта.

Когда разумно оставить оба инструмента

Маркетинговый и продуктовый контуры могут дополнять друг друга:

Метрика связывает кампании, визиты и цели публичного сайта;
продуктовая система исследует авторизованные события, аккаунты, когорты и рабочие сценарии;
CRM и биллинг подтверждают клиента, подписку и оплату;
BI соединяет управленческие показатели.

Не обязательно переносить каждый маркетинговый отчёт в продуктовую аналитику. Важнее согласовать идентификаторы и границы источников.

Когда миграция оправдана

Другой инструмент имеет смысл, если текущий процесс не закрывает обязательный вопрос или требует неприемлемых ручных действий. До перехода:

зафиксируйте отчёты и определения;
выгрузите контрольный период;
сопоставьте пользователей и аккаунты;
подключите новый поток параллельно;
сравните числа;
опишите допустимые расхождения;
только затем переключайте владельцев отчётов.

Практический сценарий перехода описан на странице миграции, а критерии выбора системы — на странице платформы продуктовой аналитики.

Если основной вопрос связан не с каналом трафика, а с последовательностью действий конкретного человека, сравните подходы на странице аналитики поведения пользователей.

Не смешивайте факт и интерпретацию

Каким бы инструментом ни пользовалась команда, клик по кнопке не равен подтверждённой оплате, визит не равен полученной ценности, а корреляция функции с retention не доказывает причинный эффект. Надёжность определяется контрактом событий и системами-источниками.

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