PostHog: когда продуктовая аналитика съедает меньше времени, чем настройка трекера

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

Но self-host здесь не «поставил и забыл». Из коробки нужен PostgreSQL, ClickHouse, очереди, объектное хранилище и нормальный мониторинг. Если у вас уже есть DevOps-процессы и привычка держать сервисы под присмотром, ок. Если нет — репозиторий быстро превращается в ещё одного постоянного жильца на сервере.

На что смотреть перед внедрением:
— какие события реально нужны, а какие вы просто «на всякий случай» шлёте в аналитику;
— сможете ли вы поддерживать схему событий без зоопарка названий;
— кто будет чистить мусорные свойства, дубли и кривые источники;
— нужен ли вам self-host ради контроля данных, или SaaS закроет задачу дешевле по TCO.

PostHog хорош, когда аналитика нужна продуктовой команде каждый день и вы готовы платить временем инженеров за контроль и гибкость. Если задача — просто смотреть конверсию и не заводить ещё один мини-кластер, SaaS часто честнее.

Выбирайте PostHog не по лозунгу «open source», а по тому, сколько часов в месяц вы готовы тратить на поддержку вокруг аналитики.