Свой сервер аналитики вместо зарубежного счётчика: практический разбор

MAATRIX

У вас на сайте стоит зарубежный счётчик посещаемости, и в какой-то момент вы замечаете, что цифры «плывут»: у трети посетителей скрипт не грузится вообще, отчёты доступны только через VPN, а данные о поведении ваших пользователей физически лежат на серверах в другой юрисдикции. Решение не в том, чтобы смириться с потерями или искать очередной обходной путь — а в том, чтобы поставить веб-аналитику на собственный сервер, под своим доменом, под своим контролем. Ниже — практический разбор: какую платформу выбрать, какой сервер под неё нужен, что вы теряете при переходе и что реально получаете взамен.

Почему зарубежный счётчик становится проблемой

Три проблемы накладываются друг на друга, и по отдельности с каждой можно было бы жить, но вместе они делают зарубежную аналитику ненадёжным источником данных.

Первая — доступность самого сервиса. Кабинет и API периодически недоступны без VPN, интерфейс может тормозить или отваливаться на обновлении отчётов, а зависимость от стабильности стороннего соединения — это риск, который вы не контролируете.

Вторая — блокировка скрипта у части аудитории. Браузерные блокировщики рекламы и трекеров (uBlock Origin, AdGuard, встроенные защиты Brave и Safari) включают домены крупных зарубежных аналитических сервисов в свои списки по умолчанию. По ряду независимых оценок разных лет доля пользователей с активным блокировщиком в рунете исчисляется десятками процентов — точная цифра зависит от аудитории сайта и меняется со временем, но факт остаётся: часть трафика вы просто не видите, и это не случайные визиты, а зачастую наиболее технически подкованная и платёжеспособная аудитория.

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

Собственный сервер аналитики снимает все три проблемы разом: скрипт грузится с вашего домена, отчёты доступны из панели на вашем сервере, а данные не покидают инфраструктуру, которую вы контролируете.

Какую платформу выбрать

На рынке open source веб-аналитики есть несколько зрелых вариантов, и выбор определяется не абстрактным «что лучше», а тем, что вам действительно нужно от отчётов.

Matomo — самый функционально полный вариант, исторически позиционируется как замена Google Analytics «один в один»: воронки, карты кликов, сегментация аудитории, отслеживание событий и целей, готовые плагины под разные CMS. Плата за функциональность — более тяжёлая база данных и заметно больше ресурсов на сбор и обработку событий при сопоставимом трафике.

Plausible — противоположный полюс: лёгкий, быстрый, с минималистичным набором метрик (источники трафика, страницы, устройства, страны, конверсии по целям) и куда более скромными требованиями к серверу. Осознанно жертвует детализацией ради простоты и скорости — нет карт кликов, сессионного плеера, сложных воронок из коробки.

Umami и PostHog — тоже стоит держать в поле зрения: Umami похож на Plausible по философии (лёгкий, простой), PostHog ближе к продуктовой аналитике (события, флаги фич, A/B-тесты) и по требованиям к серверу заметно тяжелее обоих.

Сравнение по сути:

Если вам нужна замена привычным детальным отчётам маркетолога — берите Matomo и закладывайте под него сервер побольше. Если аналитика нужна в первую очередь владельцу или разработчику для понимания «откуда трафик и что конвертит» — Plausible или Umami закроют это с меньшими накладными расходами. Более развёрнутое сравнение конкретно Matomo и Plausible — в статье «Matomo или Plausible: что выгоднее и когда».

Требования к серверу под такую нагрузку

Нагрузка от веб-аналитики специфична: это не постоянный ровный поток, а всплески в часы пиковой посещаемости сайта, плюс периодическая тяжёлая работа — построение агрегированных отчётов и архивация исторических данных (у Matomo это отдельный процесс, который стоит вынести в cron, а не оставлять на «показ по требованию»).

Ориентировочные рамки для сайта с посещаемостью до нескольких сотен тысяч визитов в месяц — именно ориентировочные, ваша цифра может отличаться в зависимости от количества отслеживаемых событий, целей и глубины истории:

• Matomo: от 2 vCPU / 4 ГБ RAM для старта, для комфортной работы с архивацией отчётов и без просадок при пиках — 4 vCPU / 8 ГБ RAM и выше. MySQL/MariaDB под Matomo быстро становится узким местом на больших объёмах — таблицы логов растут линейно с числом визитов, и без тюнинга и партиционирования на горизонте года-двух это заметно.
• Plausible / Umami: заметно легче за счёт другой модели хранения (ClickHouse у Plausible, SQLite/Postgres у Umami в зависимости от версии) — часто хватает 1-2 vCPU / 2 ГБ RAM для среднего сайта, и это одна из причин, почему их выбирают именно ради экономии на инфраструктуре.

Отдельно — диск и его тип. Аналитика пишет много мелких транзакций (каждое событие — запись в базу), поэтому SSD/NVMe здесь не роскошь, а необходимость: на HDD запись логов посещений на нагруженном сайте становится узким местом раньше, чем CPU или память.

Практический пример конфигурации Docker Compose для Matomo, если хотите сразу увидеть рабочий файл, а не собирать окружение вручную, есть в статье «Matomo в Docker Compose: готовый файл» — там же разобраны типовые грабли первого запуска.

Пошаговый план миграции

Переезд лучше делать без резкого обрыва старых данных — какое-то время оба счётчика работают параллельно, чтобы свериться и не потерять исторический ряд для сравнения показателей год к году.

1. Разверните аналитику на отдельном сервере или в отдельном контейнере, не на том же хосте, где крутится боевой сайт — иначе всплеск трафика на сайте одновременно нагрузит и аналитику, и наоборот, а при инциденте вы рискуете потерять и продакшн, и данные о том, что происходило перед падением.
2. Настройте домен под трекинг-скрипт — свой поддомен (например, stats.вашдомен.ру) вместо прямого обращения к IP или домену платформы. Это не только про удобство: часть блокировщиков реагирует именно на характерные пути в URL известных аналитических сервисов, и собственный домен снижает вероятность попадания под фильтр.
3. Разместите сервер в юрисдикции, которая соответствует вашим требованиям. Если аудитория преимущественно в России и важна низкая задержка до посетителей — берите сервер в РФ; если данные не подпадают под требования локализации и приоритет — доступность из разных регионов, подойдёт сервер в Великобритании или США.
4. Прогоните оба счётчика параллельно 2-4 недели, сверьте расхождения в цифрах (они будут — методики подсчёта уникальных визитов у разных систем отличаются) и зафиксируйте для себя, какой источник теперь считается основным.
5. Перенастройте цели и события — это самая трудоёмкая часть, потому что автоматической миграции целей между разными платформами аналитики обычно нет, их придётся пересоздавать вручную с той же логикой (клик по кнопке, отправка формы, достижение страницы «спасибо»).
6. Настройте бэкапы базы аналитики отдельно от бэкапов основного сайта — это независимый актив с собственной ценностью (историческая статистика), и его потеря не должна зависеть от расписания бэкапов продакшна.
7. Отключите старый счётчик только после того, как убедитесь, что новая система собирает данные стабильно хотя бы месяц, включая пиковые дни (акции, рассылки, сезонные всплески).

Что вы теряете при переходе

Быть честным здесь важнее, чем продавать переход как решение без компромиссов — они есть, и лучше знать о них заранее.

Готовые интеграции с рекламными кабинетами. Крупные зарубежные платформы аналитики годами встраивались в экосистему своих же рекламных инструментов — импорт конверсий в один клик, автоматическая разметка UTM, готовые отчёты по эффективности кампаний прямо в интерфейсе. У self-hosted решений такой глубокой интеграции по умолчанию нет: связку с рекламными кабинетами (в том числе с Яндекс Директом) придётся собирать через API вручную или искать сторонние коннекторы, и это дополнительная работа на старте, которую нельзя недооценивать, если у вас активная рекламная кампания с оптимизацией по конверсиям.

Привычные отчёты и знакомый интерфейс. Если в команде есть маркетолог, который годами работал в интерфейсе конкретного зарубежного сервиса, переучивание — реальные издержки, не только про кнопки, но и про доверие к цифрам: первое время люди будут сверять новые отчёты со старыми и сомневаться в расхождениях. Ближе всего к привычному интерфейсу по функциональности — Matomo; у Plausible и Umami набор отчётов принципиально более скромный, и часть привычных срезов данных там просто не строится.

Готовая инфраструктура и поддержка вендора. У зарубежного облачного сервиса аптайм, масштабирование и резервное копирование — не ваша забота. На своём сервере это становится вашей ответственностью: обновления платформы, мониторинг доступности, план на случай сбоя базы данных — придётся настраивать самостоятельно или доверить управляемому хостингу.

Экосистема готовых плагинов и виджетов. У крупных зарубежных решений тысячи сторонних интеграций — от систем email-рассылок до CRM. У self-hosted аналитики экосистема заметно меньше, и часть связок придётся делать через универсальные вебхуки или писать самостоятельно.

Что вы выигрываете

Полный контроль над данными. Данные о поведении посетителей физически находятся на сервере, который принадлежит вам. Вы решаете, как долго их хранить, кто имеет к ним доступ, куда идут бэкапы и в какой юрисдикции всё это физически размещено — без зависимости от политики стороннего сервиса, которая может измениться без вашего участия.

Отсутствие утечки данных за границу. Для сайтов, где это принципиально — государственные и окологосударственные организации, медицина, финансовый сектор, работа с закрытой корпоративной информацией — self-hosted аналитика снимает саму постановку вопроса «а куда физически уходят данные о наших пользователях».

Меньше потерянного трафика из-за блокировок. Скрипт со своего домена и без характерных путей известных трекеров реже попадает под фильтры блокировщиков рекламы — это не гарантия (популярные списки блокировки обновляются и со временем могут добавить и ваш домен по паттернам), но на практике доля заблокированных запросов у self-hosted аналитики обычно ниже, чем у известных зарубежных сервисов, которые блокировщики целят прицельно.

Независимость от доступности сервиса. Аналитика работает столько, сколько работает ваш собственный сервер, а не зависит от того, доступен ли сторонний дата-центр без VPN сегодня утром.

Предсказуемые расходы. Вместо тарифной сетки, привязанной к объёму трафика или числу событий, вы платите за сервер фиксированную сумму независимо от того, сколько у вас посетителей — подробный расчёт экономики на конкретных цифрах есть в статье «Своя аналитика вместо платного тарифа: цена миллиона просмотров».

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