<b>Product analytics ломается не в дашборде, а в названии событий и границах воронки</b>

<b>Product analytics ломается не в дашборде, а в названии событий и границах воронки</b>

Когда команды спорят о цифрах, проблема часто не в BI, а в том, что один и тот же шаг назвали по-разному. Для старта достаточно зафиксировать 3 вещи: что считается событием, где у него начинается и заканчивается смысл, и какие параметры обязательны.

— События именуют по действию: <code>signup_started</code>, <code>checkout_submitted</code>, а не «кнопка 1»
— У каждого ключевого события есть 2–4 параметра: источник, экран, товар/оффер, статус
— Воронка строится только на шагах, где пользователь реально выбирает путь, а не просто открывает экран

Дальше смотрят не на «все события», а на узкие места: где много стартов и мало завершений, где шаги повторяются, где один и тот же пользователь ломает последовательность. Если воронка отваливается на одном экране, обычно там либо плохой UX, либо не хватает одного обязательного поля, либо событие трекается слишком поздно.

Хорошая схема — сначала описать 5–7 критичных действий на бумаге, потом уже заводить их в GA4, Amplitude, Mixpanel или PostHog. Иначе вы получите красивый отчет, который не объясняет, почему просела конверсия.

Сначала фиксируйте смысл события, потом рисуйте графики. Тогда аналитика начинает отвечать на вопросы команды, а не плодить новые.