Веб-аналитика долгое время «по умолчанию» ассоциировалась с Google Analytics. Однако в реальных проектах все чаще возникают ситуации, когда этот инструмент начинает раздражать не из‑за интерфейса или функционала, а по причинам юридического и этического характера. Параллельно обнаруживается неожиданный эффект: при переходе на self-hosted аналитику (то есть на систему, развёрнутую на собственном виртуальном сервере) понимание поведения посетителей часто становится точнее и прикладнее.
Ниже приведена практическая схема замены Google Analytics на собственную аналитику на VPS/VDS: от выбора подхода до развертывания, подключения счётчика, настройки приватности и организации обслуживания. Материал ориентирован на типовой сценарий контентного сайта, корпоративного ресурса или небольшого сервиса, где важны источники трафика, воронки и события, но нежелательны «серые зоны» по персональным данным.
Почему Google Analytics начал раздражать «юридически и морально»
Юридическая часть обычно упирается в трансграничную передачу данных и статус персональных данных. В ЕС после решения Schrems II и последующих разъяснений некоторые регуляторы публично указывали на риски использования Google Analytics в контексте передачи данных в третьи страны без достаточных гарантий. В других юрисдикциях встречаются собственные требования к локализации или к порядку уведомления пользователей.
В российском контуре дополнительно вспоминают 152‑ФЗ и практику трактовки идентификаторов (IP-адрес, cookie, online-идентификаторы) как персональных данных при определённых условиях. В таких условиях внешняя аналитика превращается из «простого счётчика» в элемент юридических рисков: нужно разбираться, какие данные и куда уходят, на каком основании, как оформлены согласия и договорные отношения с обработчиком.
Моральная часть обычно связана не с конкретными настройками, а с моделью индустрии: аналитика от крупной рекламной платформы воспринимается как компонент профилирования, а не как нейтральная статистика. Это влияет на доверие аудитории и на отношение к баннерам согласия: пользователи устают от «cookie-стен», а владельцы сайтов – от попыток совместить маркетинговые задачи с принципом минимизации данных.
На практике эти причины редко идут поодиночке. Чаще встречается связка: «непонятные юридические последствия + ощущение, что трекинг избыточен + желание держать данные у себя».
Что даёт self-hosted аналитика на VPS/VDS
Self-hosted аналитика – это не «анти-Google», а смена модели владения: сбор и хранение данных контролируются владельцем проекта. Такой подход обычно разворачивается на виртуальном сервере (VPS) или виртуальном выделенном сервере (VDS). В разговорной практике термины часто используют как синонимы; принципиально важнее другое – наличие root-доступа и предсказуемой юрисдикции размещения.
Ключевые эффекты, которые чаще всего проявляются после переезда аналитики на VPS:
- Контроль над данными и сроками хранения – понятны место хранения, резервные копии, политика удаления
- Прозрачность – меньше «чёрного ящика»: доступна база событий, логи, конфигурация трекера
- Гибкость событий – проще подстроить модель событий под редакционные и продуктовые задачи (клики по элементам, дочитывания, поиск по сайту, отправка форм)
- Упрощение комплаенса – становится легче объяснить, какие данные собираются и кто является обработчиком. При этом обязанности по информированию пользователей и обеспечению безопасности никуда не исчезают
Важно учитывать и обратную сторону: self-hosted аналитика требует администрирования (обновления, бэкапы, мониторинг), а также дисциплины в настройках приватности. Риски смещаются с внешнего поставщика на инфраструктуру проекта.
Выбор подхода: логи сервера или JS‑трекер
Перед развёртыванием на VPS полезно определиться, какой тип аналитики нужен. На практике встречаются два базовых подхода, которые иногда комбинируются.
1. Аналитика по логам (log-based)
Данные берутся из access-log веб‑сервера (Nginx/Apache). Популярные представители: GoAccess, AWStats и похожие решения.
- Плюсы: нет JavaScript на странице; проще с приватностью (нет cookie и сторонних пикселей); видно технические детали запросов, коды ответов, 404/500, нагрузку
- Минусы: слабая работа с событиями и воронками; сложнее отделять людей от ботов; нет полноценной атрибуции по UTM в том виде, к которому привык маркетинг; в SPA (single-page application) без дополнительных действий виден один URL
- Когда подходит: базовая статистика для контентного сайта, технический мониторинг качества контента и ошибок, оценка нагрузки
2. Событийная аналитика через JavaScript (tag-based)
На страницы ставится небольшой скрипт, отправляющий просмотры и события в систему аналитики.
- Плюсы: события, цели, воронки, сегментация; понятная атрибуция кампаний; удобно анализировать поведение (клики, отправка форм, дочитывания)
- Минусы: часть аудитории режется блокировщиками; требуется аккуратная настройка приватности; появляется дополнительная точка отказа (endpoint приёма событий)
- Когда подходит: нужен поведенческий анализ и маркетинговая атрибуция, но без передачи данных третьим сторонам
Для сценария «замена Google Analytics и углубление понимания аудитории» чаще выбирается JS‑подход, а логи остаются как технический «второй источник правды» – для ошибок, ботов и нагрузочных аномалий.
Какие self-hosted системы обычно выбирают вместо Google Analytics
Выбор движка зависит от требований. Ниже – ориентиры без привязки к «единственно правильному» варианту.
- Matomo – наиболее близок к классической веб‑аналитике: цели, сегменты, отчёты по кампаниям, e-commerce (в зависимости от конфигурации). Требовательнее к ресурсам и к качеству настройки (очистка данных, производительность базы)
- Plausible / Umami – «privacy-first» инструменты с простыми отчётами и событиями. Быстрее внедряются, проще обслуживаются, но обычно уступают по глубине отчётов и гибкости сложных воронок
- PostHog и похожие продуктовые платформы – полезны для приложений и продуктовой аналитики (feature flags, эксперименты, когорты), но могут быть избыточны для обычного сайта и ощутимо тяжелее по инфраструктуре
В рамках одного VPS/VDS наиболее предсказуемо стартуют лёгкие решения (Plausible/Umami) или Matomo при понимании, что потребуется больше внимания к базе данных и оптимизации. Далее приведена практическая схема развёртывания «лёгкого» стека, который часто выбирают как минимально болезненную замену Google Analytics.
Инфраструктура: что требуется от виртуального сервера
Для self-hosted аналитики важны не «красивые цифры» в тарифах, а несколько прикладных характеристик:
- Юрисдикция и география – место обработки данных должно соответствовать требованиям проекта. Для аудитории из РФ часто выбирают размещение в РФ (например, Москва), чтобы проще решать вопросы локализации
- Диск и бэкапы – события быстро «съедают» место. Желателен SSD и понятный план резервного копирования
- Доступность обновлений – аналитика работает постоянно, поэтому важно иметь возможность регулярно обновлять ОС и контейнеры без долгих простоев
Как пример провайдера, у которого встречается аренда VPS/VDS с размещением в Москве, можно упомянуть VPS.house. Принципиально, чтобы у выбранной площадки были понятны условия обработки данных и администрирования сервера.
В дальнейших шагах подразумевается типовая Linux‑машина (Debian/Ubuntu) с публичным IP и доменным именем для панели аналитики.
Практическая схема развертывания: Umami (или аналог) в Docker
Один из распространённых способов установки self-hosted аналитики на VPS – Docker Compose. Такой подход упрощает обновления и изоляцию компонентов: отдельные контейнеры для приложения и базы данных.
Шаг 1. Подготовка VPS/VDS: базовая гигиена
Минимальный набор действий перед установкой аналитики:
- Обновить пакеты ОС
- Создать отдельного пользователя, отключить вход по паролю по SSH (оставить ключи), запретить root‑логин
- Включить firewall и открыть только нужные порты (обычно 22, 80, 443)
- Настроить корректное время (NTP), чтобы события и отчёты не «плыли»
Пример команд (упрощённо):
sudo apt update && sudo apt upgrade -y
sudo adduser analyticsadmin
sudo usermod -aG sudo analyticsadmin
sudo apt install -y ufw
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
Шаг 2. Установка Docker и Compose
В современных Debian/Ubuntu обычно достаточно установить Docker Engine и плагин compose из репозиториев или по официальной инструкции. Для production‑сценария важнее не «как именно поставить», а обеспечить регулярные обновления и ограничение доступа к сокету Docker.
Проверка после установки:
docker –version
docker compose version
Шаг 3. Docker Compose для аналитики и базы
Ниже – примерная структура (названия и переменные могут отличаться у разных систем). Важно заложить сразу:
- отдельный volume для базы
- секреты (пароли) вне публичных репозиториев
- персистентность и автоматический рестарт
Пример docker-compose.yml (схематично):
version: «3»
services:
db:
image: postgres:16
environment:
POSTGRES_DB: analytics
POSTGRES_USER: analytics
POSTGRES_PASSWORD: СЛОЖНЫЙ_ПАРОЛЬ
volumes:
– db_data:/var/lib/postgresql/data
restart: unless-stopped
app:
image: ghcr.io/umami-software/umami:postgresql-latest
environment:
DATABASE_URL: postgresql://analytics:СЛОЖНЫЙ_ПАРОЛЬ@db:5432/analytics
APP_SECRET: ДЛИННЫЙ_СЕКРЕТ_ДЛЯ_СЕССИЙ
depends_on:
– db
restart: unless-stopped
volumes:
db_data:
После создания файла сервис поднимается командой docker compose up -d. При первом запуске часть систем автоматически применяет миграции базы; если требуется ручной шаг, он описан в документации конкретного продукта.
Шаг 4. Reverse proxy и HTTPS
Оставлять панель аналитики на «голом» порту контейнера не стоит: потребуется HTTPS, а иногда и дополнительные политики доступа. Типовая схема:
- публичный домен вида analytics.example.com указывает A‑записью на IP VPS
- Nginx принимает входящий трафик 80/443
- внутри Nginx проксирует запросы в контейнер приложения
Фрагмент конфигурации Nginx (идея):
server {
listen 80;
server_name analytics.example.com;
location / {
proxy_pass http://127.0.0.1:3000;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
Сертификат обычно выпускается через Let’s Encrypt (certbot). В production‑сценарии важны автоматическое продление и контроль за тем, чтобы редирект на HTTPS не ломал загрузку трекера.
Шаг 5. Ограничение доступа к админке
Панель аналитики – административный интерфейс с чувствительными данными. Помимо сильных паролей и 2FA (если поддерживается) на практике применяют:
- IP‑allowlist для административных URL (если есть статические IP у редакции/офиса)
- дополнительную HTTP‑аутентификацию на уровне Nginx для маршрутов админки
- отдельный домен для панели, не совпадающий с доменом приёма событий (чтобы не смешивать публичные endpoint и админку)
Подключение счётчика и события: как начать понимать посетителей глубже
После установки аналитики ключевой вопрос – не «видны ли визиты», а «какие данные действительно помогают принимать решения». У Google Analytics по умолчанию много готовых отчётов, но сам принцип «чужая система, чужие правила агрегации» часто мешает формулировать нестандартные вопросы. Self-hosted аналитика выигрывает тем, что события задаются под конкретные задачи.
Минимальный набор: просмотры, источники, кампании
Большинство систем поддерживает UTM‑метки и referrer. На старте достаточно:
- проверить корректность определения источников (органика, рефералы, соцсети)
- привести UTM‑разметку к единому стандарту
- исключить служебный трафик (IP редакции, тестовые стенды)
События, которые реально «приближают» к поведению
В редакционных и контентных проектах обычно дают наибольшую отдачу не «абстрактные метрики вовлечённости», а события, привязанные к контенту и интерфейсу:
- Дочитывание – достижение 50/75/90% прокрутки, но с фильтром по времени на странице (чтобы отсечь случайные скроллы)
- Клик по ключевым элементам – подписка, кнопка «читать дальше», переходы в спецпроекты, скачивание файла
- Внутренний поиск – какие запросы вводятся, на каких страницах возникает потребность в поиске
- Ошибки форм – отправка формы + ошибка валидации (если есть lead‑формы)
- Переходы по внешним ссылкам – для материалов с большим количеством источников
В product‑сценариях (личный кабинет, сервис) в фокус обычно попадают события по ключевым шагам воронки: «регистрация → подтверждение → первая ценность → повторный визит».
Почему после переезда на VPS понимание аудитории часто улучшается
Причины здесь не магические, а инженерные:
- Становится доступна сырая база событий. При необходимости можно проверить агрегаты, выбрать произвольные срезы и убедиться, что цифры объяснимы (например, почему «вырос прямой трафик»)
- Меньше неожиданных ограничений. В некоторых облачных системах часть отчётов ограничивается порогами, семплированием или скрытием данных. В self-hosted подходе эти компромиссы зависят в первую очередь от настроек и ресурсов сервера
- Проще связать аналитику с техническими данными – ошибками 404/500, временем ответа, релизами. Корреляции «после выкладки выросли отказы» обнаруживаются быстрее, когда логи и события находятся в одной инфраструктуре
Приватность: что настраивается в self-hosted аналитике
Переезд на собственный VPS не делает аналитику автоматически «легальной» или «этичной». Однако появляется возможность внедрить принцип минимизации данных техническими средствами, а не только текстом в политике.
На практике полезно проверить и зафиксировать следующие настройки (названия пунктов зависят от выбранной системы):
- Анонимизация IP или усечение (например, обнуление части адреса), если такая опция доступна и соответствует модели обработки данных
- Отключение избыточных идентификаторов – user-id, device fingerprinting и прочие техники, которые усложняют правовую позицию и воспринимаются аудиторией негативно
- Cookie-less режим (если поддерживается) – для базовой статистики по просмотрам и источникам он часто достаточен и снижает зависимость от баннеров согласия в ряде юрисдикций. При этом юридические требования нужно проверять отдельно: в некоторых странах даже cookie-less трекинг может считаться обработкой персональных данных
- Сроки хранения – ретеншн по событиям и логам должен соответствовать цели обработки. Бессрочное хранение «на всякий случай» – типовой анти‑паттерн
- Опции opt-out – ссылка или переключатель для отказа от аналитики, если это требуется внутренними правилами или законом
Отдельно стоит помнить про «чувствительные» параметры URL: иногда в query string оказываются e-mail, номера заказов, токены. В self-hosted системах часто есть возможность исключать параметры из записи, и эту фильтрацию лучше включать сразу.
Обслуживание: обновления, бэкапы, мониторинг
Самостоятельная аналитика на VPS – это не разовая установка, а сервис. Без обслуживания постепенно накапливаются риски: от утечек до банальной потери статистики после сбоя диска.
Резервное копирование
Критично резервировать именно базу данных аналитики. Типовой минимум:
- ежедневный pg_dump/mysqldump в файл
- шифрование архива (при хранении вне сервера)
- выгрузка копий на отдельное хранилище (объектное или другой сервер)
- периодическая проверка восстановления (restore test)
Если аналитика используется для отчётности, полезно отдельно фиксировать версию схемы (миграции) и версию приложения, чтобы восстановление не превратилось в расследование.
Обновления и безопасность
Для контейнерных установок обновление обычно сводится к:
- обновлению образов (docker compose pull)
- перезапуску сервисов (docker compose up -d)
- контролю совместимости миграций базы
- патчам ОС (ядро, OpenSSL, Nginx)
На практике обновления лучше планировать: аналитика связана со сбором данных, и простой в момент пикового трафика приводит к «дырам» в статистике.
Мониторинг
Минимальный мониторинг включает:
- свободное место на диске
- здоровье базы (ошибки записи, рост таблиц)
- доступность endpoint приёма событий
- ошибки приложения (5xx) и аномалии по нагрузке
Даже простые алерты по диску и 5xx обычно дают больше пользы, чем сложные дашборды «на вырост».
Типовые ошибки при переезде с Google Analytics
- Ожидание полного функционального паритета. Google Analytics – экосистема с рекламными интеграциями и скрытой логикой обработки. Self-hosted системы чаще проще, зато прозрачнее. Целесообразно заранее выписать список критичных метрик и событий, а не пытаться воспроизвести все отчёты
- Сбор лишнего. Собственная инфраструктура соблазняет «писать всё». В результате растёт база, усложняется комплаенс и падает качество анализа. Лучше начинать с небольшого набора событий, привязанных к решениям
- Непродуманная схема доменов. Если endpoint трекера расположен на отдельном домене, блокировщики могут резать его агрессивнее. Если расположен на основном домене – повышаются требования к разделению публичного endpoint и админки
- Отсутствие фильтрации служебного трафика. Тестирование редакцией и разработкой может «съесть» статистику, особенно на небольших объёмах
- Нет бэкапов. Потеря базы в self-hosted аналитике означает потерю истории без возможности «восстановить из облака»
Короткий чек-лист: как выглядит корректный результат
Переезд с Google Analytics на self-hosted аналитику на виртуальном сервере можно считать успешным, если выполняются условия:
- счётчик стабильно собирает просмотры и источники без заметных провалов
- ключевые события (подписки, клики, дочитывания, отправка форм) фиксируются и имеют понятные определения
- включены меры приватности (минимизация данных, исключение параметров URL, сроки хранения)
- панель администрирования закрыта от «случайного интернета»
- настроены бэкапы базы и проверено восстановление
- обновления ОС и контейнеров запланированы и выполняются регулярно
Для старта обычно достаточно арендовать виртуальный сервер под self-hosted аналитику или аналогичный VPS/VDS у любого провайдера с подходящей юрисдикцией, после чего развернуть выбранную систему и постепенно добавлять события под конкретные вопросы к аудитории.
Итог
Раздражение от Google Analytics часто связано не с «неудобным отчётом», а с сочетанием юридических рисков и морального дискомфорта от участия в экосистеме тотального трекинга. Self-hosted аналитика на VPS/VDS позволяет перенести контроль над данными и логикой измерений на сторону проекта. При грамотной настройке приватности, событий и обслуживания такой подход не только снижает зависимость от внешней платформы, но и помогает точнее объяснять поведение посетителей – за счёт прозрачности данных и возможности измерять именно то, что важно для редакционных и продуктовых решений.