Своя аналитика вместо платного тарифа: цена миллиона просмотров

MAATRIX

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

Как считается цена миллиона просмотров в облачной аналитике

Большинство коммерческих сервисов веб-аналитики (в том числе более приватные, ориентированные на защиту данных, а не только классические счётчики) продают доступ по одной из двух схем: фиксированные тарифные пороги по объёму трафика (условно: до 100 тысяч просмотров — один тариф, до 1 миллиона — следующий, и так по нарастающей) или оплата за фактическое количество событий сверх лимита. В обоих случаях итоговая цена — переменная величина, которая растёт вместе с посещаемостью сайта.

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

Цена_за_1M_просмотров = (Месячная_плата_по_тарифу / Просмотры_включённые_в_тариф) × 1 000 000

Ключевая проблема этой формулы — она нелинейная. Переход через границу тарифа (условно с "до 500 тысяч" на "до 1 миллиона") часто означает не пропорциональный, а скачкообразный рост платежа, потому что провайдер закладывает маржу на каждый следующий тир. Если у вас сайт с сезонным трафиком — блог, который взлетает в соцсетях, интернет-магазин перед праздниками, новостной проект с вирусными всплесками — вы рискуете месяц оплачивать тариф "на вырост", а потом резко доплачивать за превышение.

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

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

Сколько стоит свой сервер под аналитику

Self-hosted веб-аналитика — открытые системы вроде Matomo, Plausible, Umami или PostHog, развёрнутые на собственном VPS, — устроена принципиально иначе. Вы платите не за объём данных, а за вычислительные ресурсы: сколько CPU, RAM и диска нужно системе, чтобы принимать и хранить события. Аренда сервера стоит фиксированную сумму в месяц независимо от того, обработала система 10 тысяч просмотров или 10 миллионов (пока хватает ресурсов конфигурации).

Возьмём условный пример. VPS с 2 CPU и 4 GB RAM — типичная стартовая конфигурация для Umami или Plausible на средний сайт — стоит фиксированную сумму аренды в месяц. Разделите эту сумму на фактическое число просмотров за месяц, и получите цену за миллион:

Цена_за_1M_просмотров_self-hosted = Стоимость_аренды_сервера_в_месяц / (Просмотры_за_месяц / 1 000 000)

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

Это asymmetричная экономика: у облачного тарифа кривая расходов идёт вверх вместе с трафиком, у self-hosted — вниз. Пересечение этих двух кривых и есть точка, где стоит менять решение.

Не забывайте закладывать в стоимость self-hosted не только аренду сервера, но и:

• бэкапы базы данных (отдельный диск или удалённое хранилище);
• домен и SSL-сертификат (обычно бесплатно через Let's Encrypt, но время на настройку стоит денег, если считать в человеко-часах);
• обновления и мониторинг — время администратора, даже если это несколько часов в месяц.

На каком трафике self-hosted становится выгоднее

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

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

Практический способ проверить это для конкретного проекта — построить простую таблицу на пальцах:

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

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

Как быстро поднять self-hosted аналитику: практический план

Разворачивание самой популярной open-source аналитики занимает от получаса до пары часов в зависимости от опыта. Минимальный набор — Docker и Docker Compose на чистом сервере.

Пример compose-файла для лёгкой аналитики (условная схема, конкретные версии образов уточняйте в официальной документации на момент установки):

version: "3.8"
services:
  analytics-db:
    image: postgres:16-alpine
    restart: always
    environment:
      POSTGRES_DB: analytics
      POSTGRES_USER: analytics
      POSTGRES_PASSWORD: change_me_strong_password
    volumes:
      - analytics_db_data:/var/lib/postgresql/data

  analytics-app:
    image: analytics-app-image:latest
    restart: always
    ports:
      - "3000:3000"
    environment:
      DATABASE_URL: postgresql://analytics:change_me_strong_password@analytics-db:5432/analytics
      APP_SECRET: change_me_random_secret
    depends_on:
      - analytics-db

volumes:
  analytics_db_data:

После docker compose up -d система поднимается на порту 3000, дальше нужно:

1. Настроить обратный прокси (Nginx или Caddy) с выпуском SSL-сертификата — без HTTPS браузеры будут блокировать отправку трекинг-скрипта на многих сайтах.
2. Создать сайт внутри панели аналитики и получить код отслеживания (обычно короткий <script>-тег).
3. Вставить скрипт в шаблон сайта — через CMS, конструктор или напрямую в HTML.
4. Настроить регулярный бэкап базы данных (pg_dump по расписанию через cron — минимум раз в сутки).
5. Ограничить доступ к панели администратора по IP или через VPN, если аналитика содержит чувствительные данные о посетителях.

Для конкретных систем — Matomo, Plausible, Umami, PostHog — на блоге есть отдельные пошаговые инструкции с готовыми docker-compose файлами и разбором частых ошибок; общий принцип везде похожий, разница в требованиях к ресурсам и в глубине собираемых метрик.

Данные посетителей остаются у вас — и это не мелочь

Экономика — не единственная причина переезжать на self-hosted. Когда аналитика работает на стороннем облачном сервисе, каждый визит на ваш сайт превращается в запись в чужой базе данных: IP-адреса (или их производные), поведение на странице, источники трафика, иногда — более детальные профили поведения, если сервис их строит. Вы не контролируете, как долго эти данные хранятся, кому ещё they доступны в рамках инфраструктуры провайдера и что происходит при смене владельца сервиса или утечке.

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

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

Честно о минусах: что теряется при переезде на свой сервер

Self-hosted аналитика не бесплатна в широком смысле — вы платите временем вместо денег, и это стоит признать прямо, а не маскировать разговором об экономии.

• Обновления на вас. Облачный сервис обновляется без вашего участия; на своём сервере патчи безопасности и новые версии нужно накатывать самостоятельно — иначе вы постепенно накапливаете технический долг.
• Отказоустойчивость — ваша забота. Если сервер упадёт, аналитика перестанет собирать данные, пока вы не восстановите сервис. У облачных провайдеров обычно есть SLA и резервирование "из коробки".
• Масштабирование при взрывном росте требует ручных действий. Если трафик внезапно вырос в 10 раз (вирусный пост, попадание в топ), self-hosted решение может не выдержать нагрузку без апгрейда ресурсов — а апгрейд требует времени, которого может не быть в моменте.
• Часть продвинутых функций может отсутствовать. Некоторые коммерческие сервисы предлагают глубокую сегментацию аудитории, встроенные A/B-тесты или интеграции, которых нет в базовой self-hosted-версии того же класса продукта.

Разумный компромисс для многих проектов — начать с self-hosted на небольшом сервере, зная его пределы, и держать план "Б": либо апгрейд конфигурации сервера при росте нагрузки, либо перенос базы данных на отдельную более мощную машину, если аналитика становится узким местом. Это не решение "раз и навсегда", а рабочий процесс, который пересматривается по мере роста проекта — как и сравнение Matomo и Plausible стоит пересматривать при смене требований к глубине метрик.

Итог по цифрам: когда считать деньги, а когда — контроль

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

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

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