Тысяча визитов в месяц: GoatCounter здесь честнее, чем Matomo

MAATRIX

Заводите блог или сайт-визитку, гуглите «self-hosted аналитика без Google» — и первая же статья ведёт к Matomo: PHP, MySQL, cron-архивация, веб-установщик на пять экранов. Для сайта с сотней визитов в день это как купить грузовик для поездки за хлебом — работать будет, но большая часть возможностей и ресурсов простаивает без дела. Для небольшого сайта с редким, спокойным трафиком есть вариант проще: GoatCounter — один бинарник на Go, SQLite вместо полноценной СУБД и дашборд, который отвечает на реальные вопросы владельца блога, а не пытается заменить отдел маркетинговой аналитики.

GoatCounter в двух словах: чем он архитектурно не похож на Matomo

Matomo — это классический LAMP/LEMP-стек: PHP-FPM, Nginx или Apache, MySQL или MariaDB, плюс фоновый процесс core:archive, который по расписанию агрегирует сырые логи посещений в отчёты. Это тяжёлая, но гибкая машина — она умеет воронки, сегментацию, e-commerce трекинг, десятки плагинов. Цена за гибкость — четыре движущиеся части, за которыми нужно следить: веб-сервер, PHP-пул, база данных и cron.

GoatCounter устроен принципиально иначе. Это один статически скомпилированный бинарник на Go, который сам себе и веб-сервер, и обработчик трекинга, и генератор отчётов — никакого PHP-FPM и отдельного процесса архивации не требуется, отчёты считаются на лету по запросу. Хранилище по умолчанию — SQLite, один файл на диске; для более крупных инсталляций с несколькими сайтами и заметным трафиком проект поддерживает переход на PostgreSQL, но для типичного личного блога или сайта мастерской это обычно избыточно. У проекта также есть бесплатный хостинг на goatcounter.com для личных некоммерческих сайтов с ограничениями по трафику — но раз вы читаете блог про VPS, вас, скорее всего, интересует вариант, где данные посетителей физически лежат на вашем сервере, а не у стороннего провайдера.

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

Ресурсы: сколько на самом деле ест каждый вариант

Матомо честно предупреждает в документации, что «1 ГБ RAM достаточно для старта» — и это правда только для веб-установщика. Проблема, которую подробно разбирали в статье сколько RAM нужно для Matomo, в другом: реальный расход памяти у Matomo даёт не сам PHP-процесс (он лёгкий), а фоновая архивация поверх MySQL — на активном сайте она способна съедать от полутора сотен мегабайт до гигабайта с лишним за один прогон, и это без учёта самой базы данных.

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

Ориентировочная картина для планирования (это не бенчмарк, а порядок величин — у вас со своим набором плагинов и трафиком будет немного иначе):

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

Установка на VPS: бинарник, системный пользователь, systemd

Разворачиваем на чистом Ubuntu 24.04. Никакой базы данных ставить не нужно — SQLite идёт «внутри» самого бинарника.

Создаём отдельного системного пользователя и рабочую директорию — по тем же соображениям, по которым любой сетевой сервис не стоит держать под root:

sudo useradd -r -s /usr/sbin/nologin -d /opt/goatcounter goatcounter
sudo mkdir -p /opt/goatcounter/db
sudo chown -R goatcounter:goatcounter /opt/goatcounter

Скачиваем актуальный релиз под linux-amd64 со страницы Releases проекта (arp242/goatcounter на GitHub) и распаковываем:

cd /opt/goatcounter
sudo -u goatcounter wget -O goatcounter.gz \
  https://github.com/arp242/goatcounter/releases/latest/download/goatcounter-linux-amd64.gz
sudo -u goatcounter gunzip goatcounter.gz
sudo chmod +x goatcounter

Создаём первый сайт — это разовая операция, которая инициализирует SQLite-файл и заводит учётную запись администратора:

sudo -u goatcounter ./goatcounter db create site \
  -db sqlite://db/goatcounter.sqlite3 \
  -vhost stats.example.com \
  -user.email you@example.com

Флаги команд у GoatCounter между релизами иногда меняются чуть заметнее, чем хотелось бы — если команда выше не сработает дословно на вашей версии, ./goatcounter help db и ./goatcounter help serve покажут актуальный синтаксис для скачанного релиза.

Дальше — systemd-юнит, чтобы сервис поднимался при загрузке и рестартовал сам себя при падении:

# /etc/systemd/system/goatcounter.service
[Unit]
Description=GoatCounter web analytics
After=network.target

[Service]
Type=simple
User=goatcounter
Group=goatcounter
WorkingDirectory=/opt/goatcounter
ExecStart=/opt/goatcounter/goatcounter serve -db sqlite://db/goatcounter.sqlite3 -listen localhost:8080 -tls none
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now goatcounter
sudo systemctl status goatcounter

Флаг -tls none отключает встроенный автоматический TLS у GoatCounter — сертификатами и HTTPS в такой схеме занимается внешний реверс-прокси, а сам GoatCounter слушает только на localhost и наружу не торчит.

SSL и домен: реверс-прокси перед GoatCounter

Для приёма трафика на 443-й порт с валидным сертификатом удобнее всего поставить перед GoatCounter Caddy или Nginx — какой из них выбрать под конкретную задачу, подробно разобрано в статье Caddy или Nginx: что выбрать для сервера. Для одного статичного бэкенда без сложной логики Caddy выигрывает лаконичностью — автоматический Let's Encrypt в несколько строк конфига:

stats.example.com {
    reverse_proxy localhost:8080
}

Эквивалентный вариант на Nginx (сертификат в этом случае нужно получить отдельно, например через certbot):

server {
    listen 443 ssl;
    server_name stats.example.com;

    ssl_certificate     /etc/letsencrypt/live/stats.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/stats.example.com/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

После этого на сайт, который вы хотите считать, добавляется одна строка перед закрывающим </body>:

<script data-goatcounter="https://stats.example.com/count"
        async src="//stats.example.com/count.js"></script>

Никакого баннера согласия, никакого SDK с десятком зависимостей — статический скрипт весом в несколько килобайт, который не блокирует рендер страницы.

Что видно в дашборде — и чего там принципиально нет

Честность здесь важнее маркетинга: GoatCounter не пытается быть маленьким Matomo, он сознательно закрывает более узкий круг вопросов.

Что есть и работает хорошо:

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

Чего в GoatCounter принципиально нет и не будет — это осознанная позиция автора проекта, а не недоработка:

• воронок продаж и сложной сегментации поведения («посетители, которые зашли со страницы X и не купили»);
• тепловых карт и записи сессий;
• e-commerce трекинга и интеграции с CRM;
• ролей и множественных прав доступа для команды — это инструмент одного администратора, а не платформа для отдела маркетинга.

Если вам реально нужна глубина — сегменты, воронки, кастомные отчёты — не мучайте GoatCounter, он для этого не создавался. Такое честное сравнение архитектур двух подходов к аналитике уже разбиралось на примере Matomo и Plausible в статье Matomo или Plausible: что выгоднее и когда — GoatCounter по философии стоит даже ближе к Plausible, чем к Matomo, но требует ещё меньше ресурсов сервера за счёт SQLite вместо связки Postgres+ClickHouse.

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

Приватность по умолчанию: без cookies и без слежки между визитами

GoatCounter изначально не использует cookies и не хранит ничего, что позволяет опознать конкретного человека при повторном визите: вместо постоянного идентификатора посетителя используется хэш из IP-адреса, User-Agent и соли, которая автоматически меняется раз в сутки. Это значит, что «уникальный посетитель» в отчётах — это по сути уникальный посетитель за конкретный день, а не отслеживаемый через недели и месяцы профиль, как это делают классические трекеры на постоянных cookie-идентификаторах.

Скрипт также по умолчанию уважает заголовок Do Not Track браузера и не запрашивает никаких разрешений у посетителя — именно поэтому официальная позиция проекта в том, что баннер согласия на cookie для GoatCounter обычно не требуется. Для сайтов, которые ориентируются на российскую аудиторию, отдельно стоит разобраться, что вообще считается персональными данными на сайте и какие шаги реально нужны по закону — это подробно и человеческим языком разобрано в статье 152-ФЗ простыми словами для небольшого сайта. Сам факт того, что данные посетителей физически лежат на вашем сервере, а не утекают к стороннему облачному сервису — уже весомый плюс по сравнению с любым внешним SaaS-счётчиком, вне зависимости от юрисдикции.

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

Когда маленького счётчика уже мало

Честный разбор не был бы честным без списка сигналов, что пора вырастать из GoatCounter в сторону Matomo или другого полноценного инструмента:

• вам нужны воронки продаж или сегментация поведения — «показать посетителей, которые зашли с рекламы и не оформили заказ»;
• вы ведёте интернет-магазин и хотите e-commerce трекинг — конверсии, средний чек, товары в отчётах;
• в команде несколько человек с разным уровнем доступа к аналитике разных сайтов;
• нужна интеграция с CRM или API для выгрузки сырых данных в свою систему отчётности;
• трафик вырос на порядки, и вопрос уже не «хватит ли SQLite», а «нужна ли полноценная BI-система поверх аналитики».

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

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