プライバシーファースト分析：セルフホスティング Plausible と Google Search Console の設定

GDPR が 2018 年に発効して以来、アナリティクストラッキングの状況は大きく変化しました。現実には、ほとんどの組織はまだ Web サイトで Google Analytics 4 を使用しています — 最も優れたツールだからではなく、移行にコストがかかると見られ、代替手段がニッチに見えるからです。私たちは 2024 年半ばに Google Analytics からセルフホスティングの Plausible CE に移行しました。その結果は詳しく記録する価値があります。

Google Analytics をやめた理由

Google Analytics 4 は有能なプラットフォームです。しかし、コンプライアンスのオーバーヘッドは相当なものです。真に GDPR 準拠した設定で GA4 を運用するには、Cookie 同意バナー、同意管理プラットフォーム、データ処理契約、および IP アドレスやユーザー識別子が EU 外に出ないようにするための慎重な地域ルーティングが必要です。同意バナー自体はデータに体系的なギャップをもたらします：独立した調査では 30〜50% の訪問者が同意を完全に拒否するとされており、収集するすべての指標に盲点が生まれます。

問題は、これが実行不可能なトレードオフを生むことです。同意したセグメントからの不完全なデータを受け入れるか、同意なしに GA4 を運用して法的リスクを受け入れるか。データ品質とコンプライアンスの両方を真剣に考える組織にとって、どちらもクリーンな答えではありません。

Plausible CE は異なる前提のもとに設計されています。トラッキングスクリプトはデフォルトで Cookie なしで、個人を特定できる情報を収集せず、GDPR の下で同意バナーを必要としません。これはマーケティング用語ではなく、具体的な技術的主張です。Plausible は Cookie を設定せず、セッション間で永続的なユーザー識別子を生成せず、セルフホスティング時にはサードパーティサーバーにデータを送信しません。PECR に関する ICO のガイダンスと第 29 条作業部会のアナリティクスに関する意見は、いずれも Cookie なし・フィンガープリントなしのアナリティクスは ePrivacy 指令の同意要件をトリガーしないと確認しています。

アーキテクチャ：分析エンジンとしての ClickHouse

Plausible CE には 2 つのデータベースが付属しています：イベントストレージ用の ClickHouse と設定用の PostgreSQL です。ClickHouse は分析ワークロード向けに構築された列指向データベースです — Yandex が大規模な分析インフラのために構築したエンジンと同じです。月に数万ページビューを受けるサイトにとって、行ベースのデータベースに対するパフォーマンス上の優位性は感知できません。しかしこのアーキテクチャにより、Plausible はスキーマ変更やインフラ再設計なしに数億イベントのサイトを処理できます。成長を見込む場合、これは重要です。

Docker Compose のセットアップは簡単です。Plausible は必要なすべてのサービスを含む公式設定を提供します。私たちのデプロイはヘルシンキの Hetzner CX21 インスタンス（2 vCPU、4 GB RAM）で Traefik と並んで実行されます：

services:
  plausible_db:
    image: postgres:16-alpine
    restart: always
    volumes:
      - db-data:/var/lib/postgresql/data
    environment:
      - POSTGRES_PASSWORD=${POSTGRES_PASSWORD}

  plausible_events_db:
    image: clickhouse/clickhouse-server:24.3.3.102-alpine
    restart: always
    volumes:
      - event-data:/var/lib/clickhouse
      - ./clickhouse/clickhouse-config.xml:/etc/clickhouse-server/config.d/logging.xml:ro
      - ./clickhouse/clickhouse-user-config.xml:/etc/clickhouse-server/users.d/logging.xml:ro
    ulimits:
      nofile:
        soft: 262144
        hard: 262144

  plausible:
    image: ghcr.io/plausible/community-edition:v2.1.4
    restart: always
    command: sh -c "sleep 10 && /entrypoint.sh db createdb && /entrypoint.sh db migrate && /entrypoint.sh run"
    depends_on:
      - plausible_db
      - plausible_events_db
    environment:
      - BASE_URL=https://plausible.yourdomain.com
      - SECRET_KEY_BASE=${SECRET_KEY_BASE}
      - DATABASE_URL=postgres://postgres:${POSTGRES_PASSWORD}@plausible_db:5432/plausible_db
      - CLICKHOUSE_DATABASE_URL=http://plausible_events_db:8123/plausible_events_db
      - DISABLE_REGISTRATION=true
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.plausible.rule=Host(`plausible.yourdomain.com`)"
      - "traefik.http.routers.plausible.entrypoints=websecure"
      - "traefik.http.routers.plausible.tls.certresolver=letsencrypt"
      - "traefik.http.services.plausible.loadbalancer.server.port=8000"

volumes:
  db-data:
  event-data:

DISABLE_REGISTRATION=true フラグはオプションではありません。初期アカウントを作成した後、このフラグのない公開インスタンスは URL を見つけた誰でも登録できる状態になります。openssl rand -base64 64 で SECRET_KEY_BASE を生成し、バージョン管理外の .env ファイルに保管します。

ボリュームセクションで参照される 2 つの ClickHouse XML 設定ファイルはログの詳細度を制御します。これらがなければ、ClickHouse は小さなインスタンスのディスクを数日以内に満杯にするレベルでログを記録します。Plausible のリポジトリにはこれらのファイルが含まれています；スタックを起動する前に docker-compose.yml の隣の clickhouse/ サブディレクトリにコピーします。

トラッキングスクリプトのデプロイ

スタックが実行されたら、任意のサイトへのトラッキング追加は HTML <head> 内の 1 つのタグです：

<script defer data-domain="yourdomain.com"
  src="https://plausible.yourdomain.com/js/script.js"></script>

Plausible は単一リクエストにバンドルされるオプションのスクリプト拡張を提供しています。私たちはファイルダウンロードトラッキング、シングルページアプリケーション向けのハッシュベースルーティングサポート、アウトバウンドリンクトラッキング、カスタムページビュープロパティ、収益トラッキング、タグ付きイベントを含むバリアントを使用しています：

<script defer data-domain="yourdomain.com"
  src="https://plausible.yourdomain.com/js/script.file-downloads.hash.outbound-links.pageview-props.revenue.tagged-events.js"></script>

結合スクリプトの非圧縮サイズは約 2.4 KB です。Google Analytics 4 スクリプトは約 45 KB です。これは限界的な違いではありません — すべてのページロードで 20 倍少ない JavaScript 解析であり、低スペックデバイスや低速接続での Core Web Vitals スコアに測定可能な影響を与えます。

Google Search Console との統合

GA4 を維持する最も強力な議論は、オーガニック検索クエリデータとサイト内動作を関連付けることができる Google Search Console との接続です。Plausible はこの統合をネイティブにサポートしており、コンテンツ主導のサイトでの切り替えを実行可能にする機能です。

設定には Search Console プロパティの確認と Plausible のサイト設定での OAuth 認証が必要です。接続されると、GSC データはトラフィックソースセクション内の個別の内訳として表示され、標準のページビューとセッションデータと並んで検索クエリ、インプレッション、クリック率、平均掲載順位が示されます。

一貫して問題を引き起こす設定の詳細：Plausible のドメインは GSC プロパティタイプと完全に一致する必要があります。URL プレフィックスメソッドを使用して https://www.yourdomain.com として確認された GSC プロパティは、サブドメインなしで yourdomain.com をトラッキングする Plausible サイトに接続しません。GSC では可能な限りドメインプロパティタイプを使用してください — すべてのサブドメインとプロトコルをカバーし、Plausible との接続を簡単にします。

Plausible の GSC データには、Search Console API と同じ 48 時間の遅延があります。これは Google の制約であり、Plausible の制限ではありません。運用上のアナリティクスレビューにとって、これは実際の障害になることはほとんどありません。

Cookie バナーなしの GDPR コンプライアンス

コンプライアンスの立場は正確に述べる価値があります。GDPR と ePrivacy 指令の下では、ユーザーのデバイスに情報を保存またはアクセスする場合に同意が必要です。Cookie と localStorage はどちらもこの要件をトリガーします。Plausible はユーザーのデバイスに何も保存しません：Cookie なし、localStorage エントリなし、IndexedDB 書き込みなし。

Plausible はセッション間の永続的なユーザー識別子も生成しません。各ページビューは独立して処理されます。ユーザー識別子に最も近いものは、訪問者の IP アドレス、ユーザーエージェント文字列、ローテーションするサーバーサイドソルトの組み合わせから導出される日次ハッシュです — 24 時間ごとに変化し、元の IP アドレスを復元するために逆引きできない値です。この設計により、Plausible は GDPR 第 4 条 (1) の個人データ処理の定義の外に置かれます。

実際の結果：同意バナーなし、同意管理プラットフォームなし、同意率の最適化なし、同意拒否によるデータのギャップなし。表示されるアナリティクスデータは、トラッキングを受け入れる意向のサブセットではなく、実際のオーディエンスを反映しています。

私たちのプライバシーポリシーは今やアナリティクスに関する 1 つの簡潔なパラグラフのみを必要とし、Plausible が何を収集しデータがどこに存在するかを正確に説明しています。同等の GA4 セクションは以前は複数のパラグラフにわたり、Google の標準契約条項とデータ処理条件への具体的な参照が必要でした。法的オーバーヘッドの削減は小規模組織にとって実質的です。

インフラのオーバーヘッドとパフォーマンス比較

GA4 カットオーバーの前に 60 日間両方のツールを並行して実行することで、直接比較が可能になりました。ページビュー数は 3% 未満しか異なりませんでした — Cookie なしのデプロイと同意済み GA4 を比較した Plausible 自身が公開している精度数値と一致しています。

より示唆に富む違いはユニーク訪問者数でした。Plausible は同期間で同意済み GA4 より約 12% 多いユニーク訪問者を記録しました。これは予想通りです：GA4 の同意を受け入れたサブセットは、広告ブロッカーやプライバシー重視のブラウザを使用する可能性が低い、より関与度の高い訪問者に偏っています。Plausible は同意の摩擦なしにすべての訪問者をトラッキングすることで、総リーチのより正確な像を提供します。同意モードの GA4 は最も関与度の高いユーザーの行動ポートレートを提供します。どちらも間違っていません — 若干異なる質問に答えているのです。

インフラのフットプリントは控えめです。ClickHouse は安定状態で約 400 MB の RAM を消費します。PostgreSQL はさらに約 80 MB を追加します。CPU 使用率は通常操作では無視できるほどで、大量の履歴データインポート時にのみ一時的に上昇します。空き容量のある Hetzner サーバーをすでに運用している組織にとって、既存スタックへの Plausible 追加の限界コストは事実上ゼロです。

しかし現実には、切り替えの決定は主にインフラコストや機能の同等性についてではありません。どのようなデータの上に意思決定を構築するかについてです。同意を必要とするアナリティクスは体系的に偏ったサンプルを生成します。同意なしの Cookie レスアナリティクスは、訪問者ごとの詳細が少ない完全な像を生成します。「どのページとソースが問い合わせを促進するか」が主要な質問であるマーケティング Web サイトにとって、完全な像は自己選択されたサブセットの詳細なポートレートよりも有用です。