А потому что надо сначала думать, а потом делать
На изображении - Шебайган Элвирова. Все необходимые разрешения на использование образа получены, гонорар выплачен дыней
10 месяцев self-hosted Umami. Почему своя аналитика обошлась мне в 34 000 ₽
Десять месяцев назад я подключил три своих проекта к self-hosted Umami. Аналитика работала в отдельном приложении, данные хранились в PostgreSQL, резервные копии создавались в Timeweb Cloud
За это время инфраструктура обошлась мне примерно в 34 000 рублей - без учёта нескольких выходных, потраченных на обновления, миграции и восстановление сервиса
Зачем я поднял Umami
Мне хотелось убрать ещё одну внешнюю зависимость и проверить, насколько удобно владеть всей цепочкой аналитики самостоятельно
Летом 2025 года я подключил Umami к Gloc - своему open-source расширению. В аналитику отправлялись не только просмотры страниц, но и прикладные события, предупреждения и ошибки
30 августа я перенёс базу и приложение в Timeweb Cloud, а осенью подключил к ним личный сайт и ещё один небольшой проект(триггером послужил период описанный здесь)
В результате получился отдельный контур аналитики для трёх продуктов
- Umami как приложение
- PostgreSQL как хранилище
- инфраструктура в Timeweb Cloud
- собственные события и дашборды
- моя ответственность за обновления и доступность системы
- резервные копии
На старте это ощущалось правильно. Никакого перегруженного интерфейса, десятков рекламных отчётов и ощущения, что на маленький авторский сайт устанавливаешь комбайн размером с завод. Открываешь Umami - и сразу видишь главное: посещения, страницы, источники, устройства, страны и события
UX системы максимально интуитивен и не требует освоения отдельной профессии
Что мне понравилось в Umami
Прямой контроль над данными
При self-hosted установке база находится в выбранной тобой инфраструктуре. Можно напрямую обращаться к PostgreSQL, выполнять собственные запросы, строить нестандартные отчёты, управлять резервными копиями и удалять данные без посредников
Разумеется, размещение в Timeweb Cloud не означает физического владения сервером. Но я сам выбирал провайдера и конфигурацию, управлял базой и определял жизненный цикл данных
Это заметно больше контроля, чем при использовании внешнего аналитического сервиса
Простой интерфейс
Umami хорошо отвечает на базовые вопросы
- сколько посетителей пришло
- откуда они пришли
- какие страницы открывали
- с каких устройств заходили
- какие события совершали
- как проходили через воронку
- какие UTM-метки приводили трафик
Для личного сайта этого часто достаточно. С моим уровнем трафика, сложная аналитическая система выглядит смешно
Приватность
Базовый трекинг Umami работает без cookies и не предназначен для сбора персональных данных. При самостоятельном размещении дополнительно контролируешь провайдера и регион хранения
Это не освобождает владельца сайта от ответственности. Можно самостоятельно начать передавать в события лишние параметры или включить запись сессий, содержащих чувствительную информацию
Но стартовая позиция Umami выглядит более деликатной, чем у любые общедоступные аналитические платформы
Яндекс Метрика, например, использует анонимные идентификаторы в cookies и localStorage. Владелец сайта должен уведомлять пользователей об обработке данных и получать согласие там, где этого требует законодательство
как-то работал на продукте где одна из юрисдикций располагалась в Евросоюзе, и только по кукам необходимо было изучить несколько публичных документов, чтобы реализовать все согласно нормативам ЕС
Umami давно перестал быть просто счётчиком
Актуальный Umami умеет работать с событиями, целями, воронками, retention, UTM-метками, journey, revenue и Core Web Vitals. Есть API, команды, настраиваемые доски и многое другое
Поэтому сегодня некорректно описывать Umami как "красивый счётчик посещений". Это полноценная аналитическая система
Но вот вопрос - нужна ли мне собственная аналитическая система как ещё один продукт на сопровождении?
Где обнаружилась настоящая цена
Сам Umami бесплатный. Но рядом с ним не возникает бесплатный сервер, PostgreSQL, резервные копии и инженер, который всё это обслуживает
Моя фактическая цена состояла из
- денег
- времени и ответственности за доступность
Деньги
На момент завершения эксперимента инфраструктура стоила около 113 рублей в день
| Компонент | В день | Примерно в месяц |
|---|---|---|
| App Platform | 75,74 ₽ | 2 270 ₽ |
| PostgreSQL | 16,26 ₽ | 490 ₽ |
| Резервные копии | 15,74 ₽ | 470 ₽ |
| Публичный IP | 5,90 ₽ | 180 ₽ |
| Итого | 113,64 ₽ | около 3 400 ₽ |
За десять месяцев получилось около 34 000 рублей
Важно: это стоимость выбранной мной конфигурации с отдельным приложением, управляемой базой, резервными копиями и публичным IP. Я думаю этот прайс возможно оптимизировать
Думаю можно разместить дешевле - например, запустить приложение и PostgreSQL на одном сервере или использовать хостинги с бесплатными тарифами. Но тогда часть денежной экономии сконвертируется в доп администрирование или ограничения платформы
Время
Первоначальное развёртывание заняло один вечер. Единственной заметной проблемой оказалась интеграция с Docusaurus: с помощью GPT я перебрал несколько вариантов конфигурации, пока один из них не заработал
Но стоимость self-hosted решения проявилась не при установке, а позже
Обновления и миграции иногда занимали значительную часть выходных. Приходилось вручную запускать скрипты миграции, разбираться с изменениями схемы и возвращать данные в консистентное состояние (это самое болезненное потому, что в моей конфигурации 1 BD у которой 4 TPS/мин. Не много, но тем не менее)
Несколько задержек были связаны с ошибками деплоя на стороне облачной платформы. В одном из случаев после внутренних миграций Timeweb Cloud поддержка предложила удалить приложение и развернуть его заново
Точное количество потраченных часов я не записывал, поэтому не буду задним числом превращать его в красивую цифру. Но именно время оказалось самой неприятной скрытой частью стоимости
Цена недоступности
При использовании внешнего сервиса его доступность остаётся проблемой провайдера. При self-hosted установке она становится моей проблемой
Если моя инфраструктура перестаёт работать, события больше не собираются. Восстановить пропущенные посещения задним числом невозможно
Чтобы считать такой сервис надёжным, нужно следить за самим приложением, базой, резервными копиями и деплоями. Получается мониторинг вокруг системы, которая сама должна помогать наблюдать за продуктами
Для бизнеса с требованиями к данным и непрерывности это может быть оправдано. Для аналитики личного сайта - уже нет
Umami и Метрика по-разному видели роботов
Ещё одно заметное различие обнаружилось в роботном трафике. На моём сайте Яндекс Метрика иногда относила к роботам почти весь трафик за период. В Umami большая часть этих посещений не появлялась
Это не обязательно означает, что один сервис работает правильно, а другой ошибается. Клиентские счётчики могут видеть по разному подмножества автоматического трафика. Многие роботы не исполняют JavaScript, а разные платформы используют разные способы определения и классификации таких посещений
Но для маленького сайта это существенно. Если почти весь трафик за день создан роботами, условные двадцать посещений превращаются в одного-двух реальных читателей. Без отдельного определения роботов исходные цифры легко переоценить. Здесь Метрика давала мне больше контекста
Тепловые карты
Изначально я относил отсутствие тепловых карт и записи сессий к недостаткам Umami. За время эксперимента продукт изменился: в актуальных версиях появились и heatmap, и session replay
При этом у Метрики остаётся более зрелый набор поведенческих инструментов: вебвизор, карты кликов, ссылок и скроллинга, а также аналитика форм. Всё это работает из коробки и не требует обслуживания отдельного контура
Umami и Яндекс Метрика. Сравнение без победителя
| Критерий | Self-hosted Umami | Яндекс Метрика |
|---|---|---|
| Деньги | Продукт бесплатный, но инфраструктура и резервные копии оплачиваются | Стандартный сервис предоставляется бесплатно |
| Обслуживание | Полностью на владельце | На стороне Яндекса |
| Данные | Прямой доступ к собственной базе | Данные хранятся и обрабатываются внешним провайдером, доступны интерфейс и API |
| Приватность | Базовый трекинг без cookies, инфраструктуру выбирает владелец | Используются cookies и localStorage, возникают дополнительные обязанности по уведомлению пользователей |
| Интерфейс | Компактный и сфокусированный | Больше отчётов, сегментов и настроек, но выше порог входа |
| Поведение пользователей | Есть heatmap и session replay | Вебвизор, карты кликов, ссылок и скроллинга, аналитика форм |
| Контент и реклама | Цели, воронки, retention, revenue и UTM; рекламные интеграции нужно строить самостоятельно | Контентная и e-commerce аналитика, глубокая интеграция с Яндекс Директом |
| Автоматизация | API и прямой доступ к PostgreSQL | Reports API, Logs API и Measurement Protocol в рамках модели и квот сервиса |
| Зависимость | От собственной инфраструктуры и способности её поддерживать | От правил, доступности и продуктовых решений Яндекса |
Umami выигрывает там, где важны контроль, переносимость, минимализм и возможность владеть и напрямую работать с данными
Яндекс Метрика выигрывает там, где нужны готовые отчёты и поведенческие инструменты без желания становиться администратором ещё одного сервиса
Бесплатность Метрики устроена иначе. Я не плачу за сервер и сопровождение, но соглашаюсь на внешнее хранение и обработку данных, правила провайдера и ограничения его API
Таким образом, мой выбор выглядит не как "бесплатно против платно", а так
- в Umami я плачу деньгами и временем за дополнительный контроль;
- в Метрике я экономлю деньги и время, но принимаю зависимость от внешнего провайдера
Кому я всё ещё советовал бы Umami
Self-hosted Umami стоит рассмотреть, если
- данные нельзя или не хочется передавать крупной аналитической платформе;
- собственная инфраструктура и PostgreSQL уже существуют, а их сопровождение встроено в процессы;
- нужен единый компактный интерфейс для нескольких проектов;
- важен прямой API или доступ к базе;
- есть требования к провайдеру, региону хранения, резервным копиям и сроку жизни данных;
- аналитика сама является частью продукта или инженерного эксперимента.
Яндекс Метрика практичнее, если:
- нужен бесплатный старт без отдельного сервера;
- хочется получить готовые отчёты, карты и Вебвизор;
- проект ориентирован на российский рынок или использует Яндекс Директ;
- нет времени обслуживать ещё одно приложение;
- прямой контроль над базой не является обязательным требованием.
Что сейчас
Я выключаю Umami, потому что за десять месяцев не нашёл для своих трёх проектов задачи, оправдывающей постоянную стоимость отдельного сервиса
Мне нравилось владеть всей цепочкой, проектировать, изучать, настраивать ее. Нравился чистый интерфейс. Нравилось, что я могу открыть PostgreSQL и добраться до данных без ограничений внешнего API
Но аналитика существует не для того, чтобы любоваться аналитикой. Она должна влиять на решения
За десять месяцев прямой доступ к базе, собственная инфраструктура и дополнительные возможности контроля ни разу не повлияли на развитие моих проектов настолько, чтобы оправдать примерно 3 400 рублей в месяц и периодическое обслуживание
Для текущих задач мне достаточно внешнего счётчика и периодических срезов. Если понадобится понять, где посетители застревают, у Метрики уже есть поведенческие инструменты
Если контроль над данными когда-нибудь станет настоящим требованием, а не инженерным интересом, я смогу снова поднять Umami - уже понимая полную цену решения
Итог
Эксперимент с Umami не был техническим провалом. Но было бы нечестно утверждать, что полученные знания автоматически окупили 34 000 рублей. Я мог выбрать более дешёвую архитектуру или раньше понять, что моим проектам не требуется отдельный контур аналитики
Главный результат эксперимента оказался не техническим
Я убедился, что контроль имеет ценность только тогда, когда ты им пользуешься. Я платил за возможность напрямую распоряжаться аналитическими данными - и за десять месяцев эта возможность ни разу не изменила мои решения настолько, чтобы оправдать расходы