PostHog как self-hosted аналитика: где экономит бюджет, а где съедает DevOps-время

PostHog заменяет продуктовую аналитику, событийный трекинг, воронки, записи сессий и часть feature flags. Для команды это удобно: один стек вместо набора SaaS-сервисов, единая схема событий и контроль над данными. Но “поставил и забыл” тут не работает — аналитика любит аккуратную инфраструктуру и дисциплину в событиях.

Брать self-host стоит, если у вас уже есть DevOps-ресурс, понятная модель событий и боль от разрозненных подписок. Особенно когда важны контроль доступа, свои retention-политики и возможность допиливать пайплайны под внутренние процессы. Если же команда маленькая, а аналитика нужна “чтобы просто смотреть дашборды”, SaaS часто дешевле по TCO, чем свой сервер с обновлениями и бэкапами.

Что обычно недооценивают:
— объём событий и стоимость хранения;
— очереди, очередность ingestion и ретраи;
— качество схемы: мусорные event names потом не лечатся;
— время на миграцию, если решите уехать обратно в SaaS.

Отдельный риск — ожидание, что PostHog сам наведёт порядок в продуктовой аналитике. Он только собирает и показывает данные; если события кривые, отчёты будут такими же кривыми. Поэтому сначала проектируйте taxonomy, потом подключайте SDK, и только затем раскатывайте дашборды.

Если нужен контроль, гибкость и есть кто будет это поддерживать — хороший кандидат. Если нужен “инструмент без сюрпризов”, считайте не цену софта, а цену недель, которые DevOps потратит на поддержку.