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

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

PostHog обычно берут как замену связке из событийного трекера, воронок, A/B-обвязки и части session replay. Для арб-стека это удобно, когда хочется свой контур данных и меньше зависеть от SaaS-лимитов.

Но self-host тут не «поставил и забыл». Нужны PostgreSQL/ClickHouse, фоновые задачи, бэкапы, логика ретеншена и человек, который не забудет чистить события. Если команда маленькая, поддержка быстро съедает экономию на лицензии.

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

Не брать, если нужен только простой счётчик конверсий или нет ресурса на поддержку хранилищ и очередей. В таких случаях самописный трекер или лёгкий SaaS часто дешевле по TCO, чем «бесплатный» OSS.

Итог: PostHog хорош, когда аналитика — часть инфраструктуры, а не побочный проект. Если нет дежурного на данные и апдейты, экономия быстро превращается в долг по техподдержке.