Umami или PostHog: что выгоднее и когда

MAATRIX

Google Analytics для многих закрыт или неудобен — нужен собственный сервер аналитики, желательно вне юрисдикции, где можно спокойно обрабатывать данные пользователей. Тут почти всегда всплывают два имени: Umami и PostHog. Оба self-hosted, оба открытый код, но решают разные задачи — и если поставить не то, вы либо перегрузите сервер, либо не получите нужных данных. Разберём, чем они отличаются на практике и что выбрать под конкретный сценарий.

Что это вообще такое

Umami — это простой счётчик посещений в духе Google Analytics, только приватный. Он считает визиты, просмотры страниц, источники трафика, устройства, геолокацию по IP — без куки, без персональных данных, без банера согласия в большинстве юрисдикций (хотя тут стоит свериться с локальным законодательством, а не полагаться на маркетинг проекта). Интерфейс — один дашборд на сайт, графики, топ-страницы, топ-рефереры. Всё.

PostHog — это продуктовая аналитика с претензией на замену целого стека: event-трекинг, воронки, когорты, session replay (запись сессий пользователей), feature flags, A/B-тесты, heatmaps, опросы в приложении, интеграция с data warehouse. По сути это не «счётчик», а платформа для продуктовых команд, которые хотят понимать, как именно пользователь взаимодействует с продуктом, а не просто «сколько человек зашло».

Разница в философии прямая: Umami отвечает на вопрос «сколько и откуда», PostHog — «что именно делают и почему уходят».

Ресурсы на сервере: разница на порядок

Это первое, что нужно понять перед арендой сервера — требования отличаются кардинально.

Umami:

• Node.js-приложение + PostgreSQL (или MySQL)
• На небольшой сайт (до 50-100 тыс. визитов в месяц) хватает 1 vCPU / 1-2 ГБ RAM
• База растёт медленно — события компактные, агрегация встроена

PostHog (self-hosted, полный стек):

• Django-приложение + ClickHouse (для событий) + PostgreSQL (для метаданных) + Redis + Kafka (или RedPanda в новых версиях) + плюс воркеры для обработки очередей
• Минимум для стабильной работы — 4 vCPU / 8 ГБ RAM, и это без запаса под session replay
• Если включаете запись сессий — диск и трафик растут быстро, session replay пишет по сути видеопоток действий

Официально PostHog сам рекомендует для self-hosted минимум 4 CPU / 16 ГБ RAM на продакшен-инстанс — это не капризы, а следствие архитектуры из шести-семи сервисов, которые общаются друг с другом. Sandstorm-версии на 2 ГБ RAM живут, но начинают падать при первой же нагрузке.

Таблица для ориентира (конкретные цифры у вас будут отличаться в зависимости от трафика и настроек):

Если внутренние ссылки помогают определиться с железом, посмотрите сравнение ClickHouse и PostgreSQL для аналитики — PostHog как раз строится вокруг ClickHouse, и там объясняется, почему для событийных данных выбрали именно его.

Установка: пять минут против получаса

Umami разворачивается одним docker-compose.yml:

version: "3"
services:
  umami:
    image: ghcr.io/umami-software/umami:postgresql-latest
    ports:
      - "3000:3000"
    environment:
      DATABASE_URL: postgresql://umami:umami@db:5432/umami
      DATABASE_TYPE: postgresql
      APP_SECRET: замените-на-случайную-строку-32-символа
    depends_on:
      - db
    restart: always
  db:
    image: postgres:15-alpine
    environment:
      POSTGRES_DB: umami
      POSTGRES_USER: umami
      POSTGRES_PASSWORD: umami
    volumes:
      - umami-db-data:/var/lib/postgresql/data
    restart: always
volumes:
  umami-db-data:

docker compose up -d

Через минуту-две контейнер поднят, вход по адресу http://ваш-сервер:3000, логин admin/umami по умолчанию (сразу смените пароль).

PostHog для self-hosted через docker-compose официально не рекомендуется для продакшена — команда PostHog прямо пишет в документации, что docker-compose deployment подходит для тестов и небольших нагрузок, а для серьёзного использования советуют Kubernetes (helm-чарт) или их облако. Это важный нюанс: если вы ставите PostHog «для себя» через compose, будьте готовы к тому, что при росте трафика придётся переезжать на более серьёзную оркестрацию. Минимальный compose-запуск выглядит так:

git clone https://github.com/PostHog/posthog.git
cd posthog
docker compose up -d

Но там поднимается 10+ контейнеров: web, worker, plugins, clickhouse, postgres, redis, kafka/redpanda, object storage (minio) и другие. Первый запуск занимает не минуты, а десять-пятнадцать, плюс миграции базы.

Про то, как правильно готовить продакшен-инстанс на Docker Compose в принципе — от лимитов ресурсов до healthcheck — есть отдельный разбор: Docker Compose для продакшена на Ubuntu 24.04.

Что считает каждый инструмент

Umami даёт:

• уникальных посетителей и просмотры страниц
• источники трафика (referrer, UTM-метки)
• устройства, браузеры, ОС, страны
• время на сайте, bounce rate
• простые custom events (клик по кнопке, отправка формы) — по одному событию, без параметров-цепочек

Этого достаточно для блога, лендинга, магазина без сложной воронки — когда вопрос «откуда трафик и что читают» закрывает 90% потребностей.

PostHog даёт всё это плюс:

• произвольные события с параметрами (event: "checkout_completed", properties: {amount: 49, plan: "pro"})
• воронки (funnel) — сколько пользователей дошло от шага 1 до шага 5
• когортный анализ — как ведут себя пользователи, пришедшие в разные периоды
• session replay — видеозапись действий пользователя на странице
• feature flags и A/B-тесты прямо из коробки
• SQL-запросы к сырым событиям (HogQL)

Если ваша задача — «понять, почему 70% бросают корзину на третьем шаге оформления заказа», Umami физически не даст такого ответа: там нет воронок и нет привязки событий к пользовательским сессиям в том виде, в каком это нужно для продуктовой аналитики.

Приватность и юридический аспект

Umami изначально проектировался как privacy-first: не использует куки для идентификации по умолчанию, не собирает персональные данные, хэширует IP для подсчёта уникальных посетителей. Это снижает необходимость в cookie-банере в большинстве сценариев (но не отменяет обязанность самостоятельно проверить требования вашей юрисдикции).

PostHog по умолчанию куда более «жадный» до данных — он изначально считает user ID, привязывает события к конкретному пользователю, пишет session replay (то есть буквально записывает, как человек двигал мышкой и что вводил в поля — с автоматическим маскированием паролей, но это надо явно проверять в настройках). Для GDPR-совместимости PostHog даёт инструменты (anonymization, opt-out, data retention policies), но их нужно осознанно настраивать — из коробки инструмент собирает много.

Если данные пользователей должны физически находиться в конкретной юрисдикции (например, для российских компаний по 152-ФЗ), это отдельный вопрос выбора локации сервера, а не только самого инструмента — подробнее в статье где законно держать сервер с персональными данными.

Обвязка: reverse proxy, SSL, домен

Оба инструмента отдаются через HTTP и в проде должны стоять за reverse proxy с SSL. Пример для Umami через Caddy (автоматический SSL по Let's Encrypt):

analytics.example.com {
    reverse_proxy localhost:3000
}

Для PostHog то же самое, но проксировать нужно несколько путей (веб-интерфейс и приём событий обычно на одном порту, но если используете отдельный ingestion endpoint — учтите это в конфиге). Если сомневаетесь, что ставить — Caddy или nginx, вот честное сравнение: Caddy или Nginx — что выбрать для сервера. Для одного простого сервиса вроде Umami Caddy обычно быстрее настроить именно из-за авто-SSL одной строкой; для более сложной топологии с несколькими бэкендами (как у PostHog) разница уже не так критична.

Отдельный момент — скрипт трекинга на клиентском сайте. У Umami это одна лёгкая строка (~2 КБ), у PostHog SDK заметно тяжелее, особенно с включённым session replay — это стоит учитывать, если для вас важна скорость загрузки страницы.

Что выгоднее по деньгам

Здесь считать нужно не цену лицензии (оба open source, MIT/бизнес-лицензия соответственно, self-hosted бесплатен по функциональности), а стоимость инфраструктуры и времени администрирования.

• Umami на VPS 1-2 ГБ RAM — минимальные затраты, обслуживание сводится к обновлению образа раз в пару месяцев и бэкапу базы. Полноценно работает на бюджетном тарифе.
• PostHog self-hosted на 8-16 ГБ RAM — заметно дороже по железу, плюс требует больше внимания: обновления многокомпонентного стека, мониторинг Kafka/ClickHouse, разбор миграций между мажорными версиями.
• PostHog Cloud (облачная версия от разработчиков) — если задача только в том, чтобы получить продуктовую аналитику без забот об инфраструктуре, для небольших объёмов есть бесплатный тир облака, и практический вопрос часто звучит не «self-host или нет», а «self-host ради приватности данных или облако ради экономии времени».

Итоговая логика простая: если нужен self-hosted PostHog именно ради контроля над данными (например, требование хранить события в своей юрисдикции), закладывайте в бюджет выделенный сервер уровня 8+ ГБ RAM и время на администрирование стека из нескольких сервисов. Если для той же задачи достаточно знать посещаемость и источники трафика — Umami закроет её на сервере в разы дешевле, и обслуживания там почти нет.

Частые вопросы