PostHog: когда аналитика, A/B и события живут в одном OSS — и когда это лишний уикенд

PostHog: когда аналитика, A/B и события живут в одном OSS — и когда это лишний уикенд

PostHog часто берут как self-hosted замену SaaS-аналитике: события, воронки, ретеншн, feature flags, запись сессий и простые эксперименты в одном месте. Для команд, которым нужен контроль над данными и API без зоопарка из трёх сервисов, это удобно.

Но “один стек” не значит “дешевле”. Self-host обычно тянет за собой БД, очередь, хранилище, бэкапы, мониторинг и обновления. Если в команде нет человека, который любит чинить пайплайны событий и разбираться, почему часть ивентов приехала дублями, экономия быстро съедается временем DevOps и аналитика.

Брать PostHog имеет смысл, если:
— у вас много продуктовых событий и нужен доступ к сырым данным;
— важны feature flags и basic experimentation без отдельного SaaS;
— вы готовы жить с настройкой схемы, ретеншна и прав доступа.
Платить SaaS проще, если нужен стабильный старт без инфраструктурного хвоста.

Ещё один частый промах — пытаться заменить им всё сразу. Для арб-стека PostHog хорош как слой продуктовой аналитики, но не как единственный источник истины по атрибуции, рекламным данным и отчётности. Сначала проверьте, какие вопросы он закрывает, а какие всё равно останутся на стороне трекера или BI.

Если нужен контроль и единая продуктовая панель — PostHog оправдан. Если цель только “сэкономить на подписке”, сначала посчитайте поддержку: иногда OSS выходит дороже, чем аккуратный SaaS.