PostHog в продукте и CPA: какие события собирать, чтобы не утонуть в шуме

PostHog в продукте и CPA: какие события собирать, чтобы не утонуть в шуме

Если ставите PostHog «для всего», через неделю получите красивый, но бесполезный склад событий. Работает другая схема: сначала рисуем 1–2 ключевые воронки, потом привязываем к ним события и свойства.

Для лендинга и оффера базовый набор такой:
— view_landing, click_cta, start_checkout, submit_form, purchase
— source, campaign, device, geo, landing_variant
— отдельный event для ошибок: form_error, payment_error, validation_fail

Главное правило: одно действие = одно событие. Не смешивайте в click_cta и клик по меню, и клик по кнопке заявки. Иначе воронка станет ломаной, а A/B-тест — нечитаемым. Для свойств держите короткие и стабильные названия: без «new», «test2», «temp». Для server-side событий оставляйте подтверждение критичных шагов: отправка формы, оплата, успешная регистрация.

PostHog удобно использовать как слой проверки гипотез: смотреть путь пользователя, строить cohorts, отлавливать, где отваливается checkout. Но ценность появляется только тогда, когда события одинаково трактуются маркетингом, продуктом и разработкой.

Если команда спорит, «почему конверсия упала», начните не с дашборда, а с карты событий. Сначала порядок в taxonomy, потом уже любые выводы.