Mixpanel ломают не события, а плохая схема именования и лишние свойства

Mixpanel ломают не события, а плохая схема именования и лишние свойства

Если в проекте 200+ event names, а отчёты не сходятся между командой продукта и UA, проблема обычно не в инструменте. В Mixpanel быстро уезжает аналитика, когда события называют по-разному: Sign Up, signup, registration — это три разные сущности для графиков и cohort.

Рабочий минимум для схемы:
— одно действие = одно имя события;
— имя в глагольной форме: `checkout_started`, `plan_selected`;
— свойства не дублируют событие, а дают контекст: `source`, `plan`, `device`, `step`;
— PII не тащим в свойства, иначе потом чистить воронки больнее, чем настроить их заново.

Ещё одна частая ошибка — пихать в Mixpanel всё подряд. Если событие не отвечает на вопрос про воронку, retention или monetization, ему место в сыром логе или warehouse, а не в продуктовой панели. Иначе funnel-view превращается в свалку, где любой drop объясняют «ну, наверное, пользователи странные».

Для старта достаточно 10–15 событий, которые покрывают путь до ключевого действия: визит, просмотр оффера, старт формы, отправка, оплата, возврат. Остальное добавляйте только под конкретную гипотезу или сегмент.

Хорошая аналитика в Mixpanel начинается не с дашборда, а с жёсткой дисциплины по событиям и свойствам.