PostHog без хаоса: как не утонуть в событиях и получить воронку, а не свалку

PostHog без хаоса: как не утонуть в событиях и получить воронку, а не свалку

Если ставите PostHog на лендинг, в SaaS или мобильный онбординг, начинайте не с «всех кликов», а с 3–5 бизнес-событий: visit, lead_start, lead_submit, signup, purchase. Всё остальное — только если оно помогает объяснить провал воронки.

Главная ошибка — одинаковые имена для разных смыслов. Событие button_click бесполезно, пока не понятно: где кликнули, зачем и к чему он ведёт. Лучше naming по схеме: action + object + context. Например: cta_click_pricing, form_submit_checkout, paywall_view_trial. Тогда фильтры, cohort-анализ и сегменты не разваливаются.

Вторая ловушка — не передавать свойства. Без properties вы видите факт, но не причину. Минимум: page, source, variant, device, plan, step. Для арбитража это сразу показывает, где ломается связка: преленд, оффер, форма, checkout. И отдельно проверяйте дубли: один и тот же lead_submit должен прилетать один раз, иначе воронка врёт.

Третье правило: не строить дашборд до того, как есть ответ на вопрос. Сначала задайте 1–2 сценария: «почему просел signup?» или «на каком шаге умирает trial-to-paid?». Потом уже добавляйте retention, cohorts и path analysis. Тогда PostHog работает как инструмент поиска утечки, а не как музей графиков.

Сначала смысл события, потом дашборд. Иначе PostHog честно покажет не продукт, а ваш шум.