PostHog: OSS-аналитика, которая легко превращается в ещё один сервис поддержки

PostHog: OSS-аналитика, которая легко превращается в ещё один сервис поддержки

PostHog закрывает трекинг событий, продуктовую аналитику, воронки, записи сессий и feature flags. Для команды это часто выглядит как замена сразу нескольких SaaS, но реальная цена — не только сервер, а ещё схема событий, ретеншн данных и регулярная чистка мусора.

Самый частый просчёт — ставить PostHog «как есть» и ждать магии. Без нормальной таксономии событий быстро получается свалка из event_1, button_click и signup_done. Перед внедрением нужны: единый нейминг, список обязательных свойств, правила для UTM/рефов и ответственный за схему. Иначе аналитика начнёт врать раньше, чем окупится.

Self-host имеет смысл, если у вас уже есть DevOps-процесс, запас по хранилищу и кто-то готов следить за очередями, миграциями и бэкапами. В маленькой команде он часто съедает больше времени, чем экономит денег: обновления, алерты, очереди, ClickHouse, права доступа. Тогда SaaS проще и честнее по TCO.

Брать PostHog стоит, если нужен контроль над данными, кастомные события и тесная связка с продуктом. Платить за SaaS разумнее, если аналитика нужна «без дежурства по выходным» и без отдельного человека на инфраструктуру.

Вывод: PostHog — не «бесплатный Mixpanel», а аналитический стек, который окупается только при дисциплине в событиях и готовности поддерживать его как прод-сервис.