PostHog часто ставят как «аналитику бесплатно», а потом внезапно платят DevOps-временем

PostHog часто ставят как «аналитику бесплатно», а потом внезапно платят DevOps-временем

PostHog заменяет продуктовую аналитику, event tracking, сессии, A/B и часть in-app тулов. Сильная сторона — всё в одном месте: события, фичефлаги, записи сессий, ретеншн. Но за это платите не только сервером, а ещё схемой событий, правами доступа, бэкапами и тем, кто будет разруливать, когда поток данных ломается.

Самый частый просчёт — тащить его как «просто Метрику для событий». Без нормальной таксономии событий через месяц там начинается мусор: разные названия одного и того же действия, дубли, пустые свойства, сломанные воронки. Ещё одна ловушка — включить всё подряд: записи сессий и автотрекинг быстро раздувают хранение и шум в интерфейсе.

Брать стоит, если у вас есть инженер, который умеет держать Docker/SQL/очереди и вы реально используете фичефлаги или product analytics каждый день. Платить SaaS разумнее, если нужна просто чистая воронка без ночных дежурств, миграций и ручной настройки лимитов.

Для self-host считайте не только железо. Минимум: сервер под приложение, БД, место под события, резервные копии, мониторинг, обновления и 2-4 часа в неделю на поддержку. Если этого нет, «open source» легко превращается в скрытую подписку на усталость.

Правило простое: сначала описываете схему событий и ответственного за её качество, потом поднимаете PostHog. Иначе вы внедрите не аналитику, а склад сырых данных.