著者 VPS向けセルフホストWeb解析ツールの選び方
Plausible、Umami、Matomo、GoatCounter、GoAccessを小規模VPSで比較します。1 GBで動く構成、2 GB以上必要なClickHouse、DB、ディスク増加、リバースプロキシ、広告ブロッカーによる計測漏れを解説します。
VPS で運用するセルフホスト型 Web アクセス解析ツールはどれを選ぶべきか？
セルフホスト型の Web アクセス解析は、2 つの方式に分かれます。方式を間違えると、製品選びを間違えるより大きな負担になります。一方は、訪問者のブラウザーで小さなスクリプトを実行し、そのスクリプトが送信したデータを保存します。もう一方は、Web サーバーがすでに出力しているアクセスログを読み取ります。データベースや必要なメモリを含め、その後の構成はこの選択で決まります。
小規模なサーバーの場合の簡単な結論です。GoatCounter と Medama は、1 つのプロセスで 1 つのファイルを扱うため、1 GB に収まります。Umami は Postgres コンテナを追加で使用しますが、技術に詳しくない人でも読めるダッシュボードを提供します。Plausible Community Edition と Rybbit はどちらも ClickHouse を実行するため、2 GB 以上の RAM を計画してください。Matomo は本格的な製品であり、アクセス量に応じたサイズのサーバーが必要です。GoAccess は既存のログを読み取るため、ページには何も追加しません。
スクリプトタグとサーバーログ: それぞれが確認できる内容
スクリプトタグはブラウザーを計測します。ページが読み込まれ、スクリプトが実行され、collector に1回リクエストを送信します。この連鎖のどこかが途切れると、こちらでは確認できません。JavaScript が無効になっている場合、リクエストをブロックするフィルターリストがある場合、collector へのリクエストが失敗した場合、またはスクリプトを実行しないクローラーの場合が該当します。
ログパーサーはリクエストを計測します。Web サーバーは、追加のソフトウェアをインストールしていなくても、リクエストごとに1行を書き込むため、データはすでにディスク上にあります。すべてのクローラーと、スクリプトタグのないファイルへのすべてのアクセスを確認できます。一方、ブラウザー内部で何が起きたかは確認できません。また、ブラウザーキャッシュや、サーバーの前段にある CDN (content delivery network) から配信されたページも確認できません。そのリクエストはサーバーに到達していないためです。
2つの数値は一致しませんが、どちらも間違いではありません。Matomo は両方に対応しています。また、JavaScript tracker と比較して、log import で失われる情報として、画面解像度とページタイトル、イベント、コンテンツトラッキング、ヒートマップ、セッション録画、フォーム分析を挙げています。これは、ブラウザーではなくリクエストを数えることによる代償です。
ボットトラフィックも差が生じる要因です。ログベースの集計には、フィルタリングしない限りクローラーが含まれます。一般的なサイトでは、クローラーの割合が結論を変えるほど大きくなることがあります。GoAccess と Matomo の log import は、どちらも既知のボットをフィルタリングします。ただし、user agent を偽装するクローラーは、どちらでもフィルタリングできません。そのため、ログベースの集計と サーバーで AI クローラーをブロックする を組み合わせ、ブロック前ではなくブロック後にログを確認するのが有効です。
GoAccess: 既存のログからアクセス解析
ディストリビューションのパッケージはリリースへの追随が遅れるため、プロジェクト独自の Debian および Ubuntu リポジトリからインストールします。
wget -O - https://deb.goaccess.io/gnugpg.key | gpg --dearmor | sudo tee /usr/share/keyrings/goaccess.gpg >/dev/null
echo "deb [signed-by=/usr/share/keyrings/goaccess.gpg arch=$(dpkg --print-architecture)] https://deb.goaccess.io/ $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/goaccess.list
sudo apt-get update
sudo apt-get install goaccess次に、ログを指定して静的レポートを書き出します。
goaccess /var/log/nginx/access.log -o ~/report.html --log-format=COMBINED通常のユーザーでこのコマンドを実行すると Permission denied で失敗します。Ubuntu では nginx のログの所有者が root で、グループが adm だからです。sudo usermod -aG adm $USER で自分をそのグループに追加し、グループメンバーシップはログイン時に読み込まれるため、ログアウトしてから再度ログインします。再実行する前に id を実行し、一覧に adm が表示されることを確認します。
ライブログに対するレポートには、logrotate によってまだ移動されていないログの内容しか含まれません。昨日のリクエストは access.log.1 にあり、さらに古いログは圧縮されています。そのため、週次の集計ではローテーション済みのファイルも読み込む必要があります。
zcat /var/log/nginx/access.log.*.gz | goaccess - --log-format=COMBINED -o ~/last-week.html--real-time-html というライブモードもあります。このモードでは WebSocket 経由でページを更新します。そのため、別のポートと専用のプロキシルールが必要です。多くのサイトでは、cron で1時間ごとにレポートを書き出せば十分であり、保護すべき範囲も小さくなります。
GoatCounter: 1 つの Go バイナリと 1 つの SQLite ファイル
GoatCounter は静的リンクされたバイナリとしてリリースされるため、ランタイムをインストールする必要はありません。リリースページからビルドを取得して実行するか、イメージを使用します。
docker run -p 8080:8080 -v goatcounter-data:/home/goatcounter/goatcounter-data arp242/goatcounterバイナリとして実行すると、goatcounter serve はポート 8080 で待ち受け、./goatcounter-data/db.sqlite3 に SQLite データベースを作成します。インスタンスがすでにプロキシの背後にある場合は、Web ウィザードではなくコマンドラインから最初のサイトを作成します。
goatcounter db create site -vhost=stats.example.com -user.email=me@example.comgoatcounter serve -listen=:443 -tls=tls,rdr,acme を使用すると、ACME（自動証明書管理環境）によって証明書を自動管理できます。これは、他のサービスを実行していないサーバーで便利です。nginx または Caddy がすでにポート 443 を使用している場合は、GoatCounter を 8080 で待ち受けさせ、そこへプロキシします。トラッキングスクリプトのサイズは、プロジェクトの説明では約 3.5K です。JavaScript を含まないページ向けに、トラッキングピクセルも用意されています。負荷の高いサイトで SQLite が制限になる場合は、同じバイナリで goatcounter serve -db 'postgresql+dbname=goatcounter' を使用して Postgres を利用できます。バックアップはファイルをコピーするだけです。これが、この構成のツールを選ぶ実際の理由です。
Medama: 256 MBを要求する単一コンテナ
Medamaは、ここで扱う最新の単一バイナリ方式です。設計上 Cookie を使用せず、プロジェクトではトラッカーが 1 KB未満であることに加え、メモリ 256 MBの仮想マシン上で小規模サイトを実行できると説明しています。これらはプロジェクトが公開している主張であり、このガイドで測定した値ではありません。
docker volume create medama-data
docker run -d -p 127.0.0.1:8080:8080 -v medama-data:/app/data ghcr.io/medama-io/medama:latest公式コマンドでは、ポートを 8080:8080 として公開します。上記の loopback プレフィックスは意図的なもので、その理由は reverse proxy のセクションで説明します。初回ログインは admin で行い、パスワードは CHANGE_ME_ON_FIRST_LOGIN です。このパスワードの名前が、そのまま手順になっています。
記録されている失敗条件が 1 つあります。ログインできるのは HTTPS 経由、または localhost の場合だけです。そのため、証明書を設定する前に proxy を構成すると、正しいパスワードでもフォームに拒否され、理由も表示されません。先に TLS (transport layer security) の設定を完了してからログインしてください。
Umami: Postgres と、見慣れたダッシュボード
git clone https://github.com/umami-software/umami.git
cd umami
docker compose up -dこれにより、ポート 3000 でアプリケーションが起動し、その横で PostgreSQL コンテナも起動します。ドキュメントでは、PostgreSQL v12.14 以上が必要です。ソースからビルドする場合は、Node.js 18.18 以上も必要です。ビルド済みイメージ docker.umami.is/umami-software/umami:postgresql-latest も用意されています。このイメージでは、すでに運用しているデータベースを指す DATABASE_URL の設定が必要です。
初回ログインのユーザー名は admin、パスワードは umami です。DNS をこのサーバーに向ける前に変更してください。DNS レコードが解決され、プロキシが応答した時点で、インスタンスはインターネットから到達可能になるためです。Compose の詳細、環境ファイル、再起動ポリシーについては、内容を確認していないスタックをコピーせず、VPS 上の Docker Compose スタックを参照してください。
構成は Node プロセスと Postgres で成り立ちます。単一のバイナリよりは重い一方、ClickHouse を実行する構成よりは大幅に軽量です。
Plausible Community Edition: ClickHouse が必要メモリ量の下限を決める
git clone -b v3.2.1 --single-branch https://github.com/plausible/community-edition plausible-ce
cd plausible-ce
touch .env
echo "BASE_URL=https://stats.example.com" >> .env
echo "SECRET_KEY_BASE=$(openssl rand -base64 48)" >> .env
docker compose up -d2026 年 8 月時点の最新版は v3.2.1 です。clone コマンドでは意図的にこのバージョンを固定しています。この構成は、アプリケーション、アカウントと設定を管理する Postgres、イベントデータを管理する ClickHouse の 3 つで成り立ちます。SECRET_KEY_BASE は少なくとも 64 byte の文字列である必要があり、openssl の呼び出しで生成できます。
Plausible 自体の要件では、ClickHouse とアプリケーションが out of memory killer の対象にならないよう、少なくとも 2 GB の RAM が必要です。また、ClickHouse が必要とする SSE 4.2 または NEON をサポートする CPU も必要です。2 つ目の要件は、VPS を契約する前に確認してください。これは、ARM と x86 VPS の選び方における実用上の違いの 1 つです。ClickHouse は利用可能だと判断したメモリをできるだけ使用するため、共有サーバーではCompose でコンテナのメモリ使用量に上限を設定する方法に従って上限を設定してください。
BASE_URL は公開 URL と完全に一致する必要があります。一致しないと、ログイン後にアプリケーションが誤ったホストへリダイレクトします。セッション Cookie もブラウザーがアクセスしていないドメイン向けに書き込まれるため、エラーメッセージが表示されないままログインフォームに戻されます。
付属の compose ファイルはポートを公開しません。前段にプロキシを置く構成が前提だからです。デフォルトのアプリケーションポートを loopback のみに公開する override を追加します。
cat > compose.override.yml << EOF
services:
plausible:
ports:
- 127.0.0.1:8000:8000
EOFMatomo: 完全な製品構成と必要なサーバー
Matomo は PHP と MySQL または MariaDB で動作するため、コンテナスタックではなく従来型の Web スタックに適しています。また、ここで扱うツールの中で、トラフィック量に応じたハードウェア要件を公開しているのは Matomo だけです。
The data behind this chart
[
{
"label": "100K/month",
"cpu_cores": 2,
"ram_gb": 2,
"disk_gb": 50
},
{
"label": "1M/month",
"cpu_cores": 4,
"ram_gb": 8,
"disk_gb": 250
},
{
"label": "10M/month",
"cpu_cores": 8,
"ram_gb": 16,
"disk_gb": 400
}
]これらは 2026 年 8 月時点で Matomo が公開している最小要件であり、このガイドで測定した値ではありません。月間 100,000 ページビューまでは、2 CPU コア、2 GB の RAM、50 GB の SSD が必要で、1 台のサーバーでアプリケーションとデータベースの両方を動かします。1M/month では、RAM が 8 GB、ディスクが 250 GB になります。10M/month では Matomo は 2 台のサーバーを推奨しており、最後の行にはデータベースサーバーの要件として、RAM 16 GB、ディスク 400 GB が示されています。これらのディスク容量は、データセット全体を 1 つの SQLite ファイルに保存する単一バイナリ型の選択肢と並べて確認してください。
多くの人が意外に感じるのは、アーカイブ処理です。Matomo はデフォルトでは、誰かがダッシュボードを開いたときにレポートを生成します。そのため、データが増えるほどダッシュボードの表示が遅くなり、最終的にはタイムアウトします。文書化されている対策は、一般設定でブラウザーから起動されるアーカイブ処理を無効にし、代わりに Matomo のファイルを所有するユーザーとして、Matomo のディレクトリから cron で archiver を実行することです。
php console core:archive --url=https://analytics.example.comMatomo は、処理済みのレポートテーブルとは別に、生のログテーブルも保持します。また、古い生データと古いレポートをスケジュールに従って削除できます。ディスクが満杯になってからではなく、インストール時にこの機能を有効にしてください。Matomo はサーバーのアクセスログもインポートできるため、ここで扱う製品の中で、両方の方式に対応する唯一の製品です。
Rybbit と新しいスタック
git clone https://github.com/rybbit-io/rybbit.git
cd rybbit
chmod +x *.sh
./setup.sh your.domain.nameRybbit は、モダンなダッシュボードを備えた新しいプロジェクトです。セットアップスクリプトは環境ファイルを作成し、Docker Compose でスタックを起動します。ClickHouse を実行し、独自の Web サーバーとして Caddy も起動します。Caddy は 443 番ポートを使用し、指定したドメインの証明書を取得します。nginx がすでに 443 番ポートを使用しているサーバーでは、スクリプトでポートをバインドできません。そのため、プロジェクトの手動 Compose 手順を使い、既存のプロキシの背後に配置してください。ドキュメントでは、少なくとも 2 GB の RAM、Ubuntu 24 LTS でのテスト、ARM 環境では ClickHouse の要件として ARMv8.2-A 以降が必要とされています。
新しいプロジェクトには、避けられない注意点があります。機能の追加が速い一方で、破壊的変更も発生します。タグを固定し、pull の前にリリースノートを確認してください。最初にデータベースをバックアップしてください。
保持期間とディスク増加量: 自分の環境で測定する
ディスク使用量の増加は、ツールがイベントごとに保存する内容によって異なります。GoatCounter はアクセスをカウンターに集約するため、ファイルサイズは生のアクセス量よりも、異なるページ数と日数に応じて増加します。Umami と Matomo はイベントごとに行を保存します。さらに Matomo は、生データに加えて処理済みのレポート用テーブルも保存します。ClickHouse はイベントを列形式で保存し、強く圧縮します。そのため、Plausible は行指向のデータストアなら負荷になるアクセス量にも対応できます。
このガイドでは、メガバイト単位の「100 万ページビューあたり」の数値を掲載しません。あなたのトラフィックで測定した値ではないためです。自分で測定してください。サービス名とユーザー名は、使用している Compose ファイルに合わせて変更します。
du -h goatcounter-data/db.sqlite3
docker compose exec db psql -U umami -d umami -c "SELECT pg_size_pretty(pg_database_size('umami'));"
docker compose exec plausible_events_db clickhouse-client -q "SELECT formatReadableSize(sum(bytes_on_disk)) FROM system.parts WHERE active"数値を記録し、1 週間待ってからもう一度記録します。その差分を、その週にダッシュボードが報告したページビュー数で割ります。この値は、サイトとボットのフィルタリング状況を反映するため、公表されている平均値よりも有用です。数値がまだ小さいうちに、保持期間の上限も設定してください。ディスクが満杯になると、分析サービスだけでなく VPS 上のすべてのサービスが停止します。そのため、データベースのボリュームは df -h が警告できる場所に保持することが重要です。すでに容量の大きいデータを保持しているサーバーでは、このリスクにさらに注意が必要です。自己ホスト型の写真サーバーは、分析データベースが限界に近づくよりはるかに早くディスクを使い果たすためです。
サブドメイン上のリバースプロキシ配下での動作
コレクターは、計測対象サイトのサブドメインに配置します。たとえば stats.example.com です。これにより、コレクターへのリクエストは同一サイトからのファーストパーティリクエストになります。そのため、サードパーティリクエストをブロックするブラウザーのルールの影響を受けません。
コンテナのポートを公開するときは、アプリケーションをループバックにバインドしてください。Docker は ufw より先に独自のファイアウォールルールを適用するため、-p 3000:3000 として公開したコンテナは、ufw status でそのポートが拒否されていてもインターネットから到達できます。別のマシンから curl http://SERVER_IP:3000 でテストすると、ダッシュボードが表示されます。-p 127.0.0.1:3000:3000 として公開した場合、同じテストの結果は Connection refused となり、プロキシからのみ到達できます。この習慣はダッシュボードを隠すだけではありません。同じホストで onion service を実行する場合の基本でもあります。公開インターフェースで応答し続けるサービスがあると、隠されたアドレスと IP アドレスが結び付いてしまいます。Collector のエンドポイントはオープンなインターネットから到達できる必要がありますが、ダッシュボードにはその必要がありません。2 つ目のサブドメインを公開する代わりにプライベートネットワーク経由で読みたい場合は、subnet router で VPS のネットワークを tailnet に広告することで、ポートを開かずにアクセスできます。
server {
listen 443 ssl;
server_name stats.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;
}
}ここでは転送ヘッダーが必須です。X-Forwarded-For がないと、すべてのアクセスが 127.0.0.1 から来たものとして扱われるため、国別レポートは空になり、ユニーク訪問者数は 1 に近づきます。信頼するヘッダーとその設定はプロジェクトごとに異なります。思い込みで設定せず、各プロジェクトのプロキシに関するドキュメントを一度確認してください。Caddy はこれらのヘッダーを自動的に設定します。同じ用途の Caddyfile は 2 行です。
stats.example.com {
reverse_proxy 127.0.0.1:3000
}まだプロキシを選んでいない場合は、nginx、Caddy、Traefikの比較で、いくつかのサブドメインを 1 台のサーバーで運用する構成に適した製品を確認できます。
セルフホストする場合でも Cookie バナーは必要ですか？
セルフホストにより、データを保有する主体は変わります。データに関する法的要件が変わるわけではありません。2 つの規則は分けて考えてください。ePrivacy の同意要件は、訪問者のデバイスに何かを保存または読み込むことに関するものです。そのため、Cookie を設定せず、local storage にも何も書き込まないツールは、この特定の要件の対象外です。GDPR は個人データの処理に関するもので、IP アドレスも個人データに該当します。そのため、依然として適法な根拠、保存期間の上限、保有する情報の開示を求められた場合の対応が必要です。
Plausible、Umami、GoatCounter、Medama は、デフォルトでは Cookie を設定しません。ただし、代わりに各ツールが導出する情報はプロジェクトごとに異なり、バージョン間でも変わります。要約ではなく、各プロジェクトのプライバシーに関するドキュメントを確認してください。Matomo には IP anonymisation と、管理画面で有効にする opt out endpoint が用意されています。
規制当局の判断は国によって異なります。例えばフランスの CNIL は、オーディエンス測定を同意なしで免除できる条件を公開しています。このセクションは事実の要約であり、法的助言ではありません。実際のユーザーが利用するサイトについては、管轄地域の弁護士に相談してください。
見落とされがちな点が 1 つあります。アクセスログも個人データです。GoAccess はページにスクリプトを追加しませんが、IP アドレスは処理します。そのため、ログベースのアナリティクスが自動的に規則の対象外になるわけではありません。サービスを自分のサーバーへ移しても、データの露出がなくなるのではなく、場所が変わるだけです。これは、セルフホストした SearXNG インスタンスが実際に隠すものの範囲が検索エンジンまでであり、クエリ自体は引き続き自分のログに記録される理由でもあります。
広告ブロッカーと、数値が減少する理由
フィルターリストは、ホスト名と URL パターンを照合します。ホスト型の分析製品は、すべてのユーザーが同じ既知のホスト名から読み込むため、簡単に照合できます。コレクターを独自のサブドメインに移すと、そのホスト名がリクエストからなくなります。また、スクリプトを選択したパスから配信すると、既知のファイル名がなくなります。どちらも、フィルターリストが照合対象とする内容を変えます。
この投稿では、測定していないため、ブロック率を示していません。特定の構成をブロックする訪問者の割合は、読者層によって異なります。開発者向けのサイトでは、一般向けのサイトよりもはるかに多くの訪問者がブロックします。代わりに、自分のサイトで差分を測定してください。同じ週について、GoAccess でアクセスログ内の HTML ページへのリクエスト数を数え、スクリプトベースのツールが報告する pageview 数と比較します。その差は、サイト上でブロックされた訪問と、キャッシュから配信されたページの合計です。
ホスト型の製品から切り替えた当日に、合計値が変動することを想定してください。その変動の一部は、ブロックとは無関係です。製品によって、pageview の定義、Single Page Application 内のルート変更を 1 回として数えるかどうか、セッションの終了時点が異なります。トラフィックが減少したと結論付ける前に、複数週にわたる傾向を比較してください。
どのサイトにどれを使うか
- 個人サイトや月間ページビューが概ね 50,000 未満のブログ: 1 GB VPS 上で GoatCounter または Medama を使用し、バックアップはファイルコピーにします。
- スクリプトを追加できないサイトや、スクリプトを強くブロックする閲覧者が多いサイト: 既存のログに対して GoAccess を定期的に実行します。
- 誰か別の担当者がダッシュボードを確認する小規模事業者のサイト: Postgres コンテナとともに Umami を使用します。
- ゴールやファネルが必要で、2 GB 以上の RAM を搭載したサーバーを使えるサイト: Plausible Community Edition を使用します。新しいダッシュボードを優先し、プロジェクトの成熟度が低いことを許容できるなら Rybbit も選択肢です。
- 多数のサイト、多数のユーザーアカウント、または生データを独自の保持ポリシーで管理する必要がある場合: 上記の公開ガイダンスに基づいてサイジングした Matomo を使用します。
実際の疑問に答えられる最小限のツールから始めてください。後から GoatCounter から Plausible へ移行する場合、必要なのはサブドメインの変更と一部の履歴の移行です。Matomo から別のツールへ移行する場合は、負担の大きい移行作業が必要になります。同じサーバーに何を追加するかまだ決めていない場合は、次に同居させられるサービスを扱った、より広範なセルフホスティング一覧を参照してください。訪問者数ではなく、アプリケーションのリクエスト単位のトレーシングが本当に必要な場合は、セルフホスト型のオブザーバビリティサービスが適しています。
FAQ
自前運用のアクセス解析を使えば、Cookie バナーは不要ですか？
いいえ。この2つは別の問題です。ePrivacy の同意要件は、訪問者の端末に何かを保存すること、または端末から何かを読み取ることを対象とします。そのため、Cookie を設定せず、local storage にも何も書き込まないツールは、この特定の要件の対象外です。GDPR は別の規則で、個人データの処理を対象とします。IP アドレスは個人データなので、Cookie を使わない場合でも、適法な根拠と保持期間の上限が必要です。自前運用にするとデータが自分のサーバー上に置かれ、そのデータについて責任を負う主体も自分になります。自国の規制当局の指針を確認し、自分のケースについては弁護士に相談してください。
VPS 上で自前運用するアクセス解析には、どの程度の RAM が必要ですか？
必要量を決めるのはダッシュボードではなく、データストアです。GoatCounter と Medama は、1つのファイルを使う単一プロセスとして動作します。Medama のドキュメントでは、小規模サイトは 256 MB のマシンで動作すると説明されています。Umami は Node アプリケーションとともに Postgres コンテナを追加します。Plausible Community Edition と Rybbit はどちらも ClickHouse を使用し、両プロジェクトは少なくとも 2 GB が必要だとしています。Matomo の公式ガイダンスでは、月間 100,000 pageviews までの場合、2 CPU cores と 2 GB の RAM が開始点です。
自前運用の数値が、置き換えたアクセス解析より少ないのはなぜですか？
原因は2つあり、どちらも実際に影響します。フィルターリストによって一部の collector リクエストがブロックされるため、スクリプトベースのツールでは訪問の一部が必ず失われます。また、製品によってカウント方法も異なります。何を pageview と数えるか、いつ session が終了するかが製品ごとに異なるためです。access log に記録された HTML ページリクエストを1週間分取り出し、同じ週のスクリプトベースの pageviews と比較してください。その差は、他者が公開した率ではなく、自分のサイトで測定した、ブロックされた訪問とキャッシュされたページの合計です。
Plausible または Rybbit を ARM VPS で実行できますか？
どちらも ClickHouse を実行し、ClickHouse は x86 では SSE 4.2、ARM では NEON を必要とします。Plausible の要件にはその旨が明記されており、Rybbit のドキュメントでは ARM システムに ARMv8.2-A 以降が必要だと説明されています。現在の ARM サーバーコアはこの条件を満たしますが、古いコアは満たしません。失敗時には、アプリケーションログに何かが出るのではなく、ClickHouse が instruction set error を表示して起動を拒否します。小規模な ARM マシンでは、単一ファイル型のツールを使えばこの問題を避けられます。これらのツールはいずれも ClickHouse を実行しないためです。
tracking script ではなく、サーバーログを解析すべきですか？
スクリプトを追加できない場合、訪問者が多数のアクセスをブロックする場合、または crawler を含む数値が必要な場合は、ログ解析を使用してください。GoAccess はサーバーがすでに書き込んでいるログを読み取るため、ページの重量もデータベースも増えません。その代わり、ブラウザー内で発生する処理はすべて把握できなくなります。また、CDN やブラウザーキャッシュから配信されたページも取得できません。そのリクエストはサーバーに到達しないためです。両方を実行し、別々の測定値として扱うサイトも多くあります。