PostHog ломается не в установке, а в схеме событий: 5 правил до первого дашборда

PostHog удобен, когда нужно быстро увидеть поведение пользователя: клики, переходы, retention, простые фичер-эвенты. Но если начать без структуры, через неделю получаете мусорный график и спор в команде о том, «почему цифры не сходятся».

— Имена событий пишите по одному шаблону: verb_object, без «click1» и «test_event».
— Не смешивайте UI и бизнес-события: button_clicked и payment_started — разные уровни.
— Для ключевых действий задавайте обязательные свойства: source, plan, device, funnel_step.
— Отдельно фиксируйте ошибки и отмены, иначе воронка будет выглядеть красивее реальности.
— Сразу договоритесь, что считается уникальным пользователем: device_id, user_id или оба.

Если нужен анализ воронки, сначала проверьте не график, а три вещи: событие стартует там, где должно; свойства приходят стабильно; шаги не дублируются из-за повторных отправок. В PostHog это особенно важно, потому что быстрый трекинг легко превращается в быстрый самообман.

Хорошая схема событий экономит недели на разборе «почему упал checkout» — потом уже можно строить cohort, retention и feature adoption без ручной чистки.