Продуктовая аналитика ломается не в BI, а на этапе вопросов к данным

Продуктовая аналитика ломается не в BI, а на этапе вопросов к данным

Если команда не договорилась, какие события и свойства нужны, дашборд только ускорит хаос. Для продуктовой аналитики важно сначала описать: какой шаг воронки считаем, где начинается сессия, что является конверсией, а что — шумом. Иначе retention, CAC и LTV будут жить в разных таблицах и спорить между собой.

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

Частая ошибка — собирать всё подряд «на будущее». В итоге taxonomy разрастается, а команда перестаёт доверять цифрам. Лучше иметь 12 стабильных событий и понятные свойства, чем 120 названий, из которых половина не используется.

Перед новым дашбордом задайте один вопрос: какое решение он должен ускорить. Если ответа нет, это не аналитика, а склад графиков.