隐私优先的分析：配置自托管 Plausible 并集成 Google Search Console

自 2018 年 GDPR 生效以来，网站分析与追踪的环境已经发生了很大变化。实际上，多数组织仍在网站上使用 Google Analytics 4，往往不是因为它最适合需求，而是因为迁移看起来成本高，替代工具又显得小众。我们在 2024 年年中从 Google Analytics 迁移到自托管 Plausible CE，其结果值得详细记录。

为何离开 Google Analytics

Google Analytics 4 功能完善，但合规开销很大。要让 GA4 真正以符合 GDPR 的配置运行，需要 cookie 同意横幅、同意管理平台、数据处理协议，以及针对向美国 Google 传输任何分析数据的、已形成书面记录的法律依据。同意横幅本身还会造成系统性的数据缺口：每位拒绝同意的访客都会从数据中缺失，而根据横幅设计和受众的不同，这可能占相当大的比例，导致您收集的每项指标都存在盲区。

问题在于，这造成了一种难以两全的取舍：要么接受仅来自已同意用户的不完整数据，要么未经同意运行 GA4，承担法律风险。对于同时重视数据质量与合规的组织，两者都不是理想方案。

Plausible CE 的设计前提不同。追踪脚本默认不使用 cookie，不存储可识别个人身份的信息，并以无需同意横幅即可运行为设计目标。这种设计基于具体的技术选择。Plausible 不设置 cookie，不生成跨会话的持久用户标识符，自托管时也不会将数据传输到第三方服务器。《电子隐私指令》（英国对应法规为 PECR）要求在用户设备上存储或访问信息时取得同意，而无 cookie 脚本的设计正是为了避免触发这一规定。不过，EDPB 的《指南 2/2023》将这一规定解释为也涵盖某些无 cookie 技术，例如基于像素和 IP 地址的追踪，因此请确认针对您自身部署的评估。

架构：以 ClickHouse 为分析引擎

Plausible CE 随附两个数据库：ClickHouse 用于存储事件，PostgreSQL 用于保存配置。ClickHouse 是为分析工作负载构建的列式数据库，也是 Yandex 为其大规模分析基础设施开发的引擎。对于每月获得数万次页面浏览的网站，它相较于行式数据库的性能优势几乎无法察觉。但这种架构意味着，Plausible 可以处理拥有数亿条事件的网站，无须修改数据模式或重新设计基础设施。如果预计业务会增长，这一点就很重要。

Docker Compose 配置并不复杂。Plausible 提供了包含所有必需服务的官方配置。我们的部署与 Traefik 一起运行在赫尔辛基的 Hetzner CX21 实例上（2 vCPUs、4 GB RAM）：

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
      - GOOGLE_CLIENT_ID=${GOOGLE_CLIENT_ID}
      - GOOGLE_CLIENT_SECRET=${GOOGLE_CLIENT_SECRET}
    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 时，创建首个账户后将关闭注册；设为 false 时，任何发现公开实例 URL 的人都可以注册。Plausible CE 当前文档将 invite_only 列为默认值。使用 openssl rand -base64 64 生成 SECRET_KEY_BASE，并将其保存在不纳入版本控制的 .env 文件中。

卷配置中引用的两个 ClickHouse XML 配置文件用于控制日志详细程度。没有这些文件，ClickHouse 的日志量会在几天内填满小型实例的磁盘。Plausible 仓库包含这些文件；启动服务栈前，将其复制到 docker-compose.yml 旁的 clickhouse/ 子目录中。

部署追踪脚本

服务栈运行后，只需在网站 HTML 的 <head> 中添加一个标签，就能启用追踪：

<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。这不是微小差别：每次页面加载需要下载的 JavaScript 量约少了 20 倍，而需要解析和执行的脚本减少，可能改善性能较低设备和较慢网络连接下的 Core Web Vitals。

Google Search Console 集成

保留 GA4 最有力的理由，是它与 Google Search Console 的连接，可以将自然搜索查询数据与站内行为关联起来。Plausible 原生支持这一集成，对于依靠内容获取流量的网站，这项功能使迁移成为可行选择。

配置需要一个已验证的 Search Console 资源，并在 Plausible 的网站设置中完成 OAuth 授权。自托管实例还需要一个已启用 Search Console API 的 Google Cloud OAuth 客户端，通过 GOOGLE_CLIENT_ID 和 GOOGLE_CLIENT_SECRET 传入 Plausible（上面的 Compose 文件已包含这两项）。连接后，在 Sources 中选择 Google 即可查看搜索查询及点击次数，展开视图还会显示展示次数、点击率和平均排名。仅列出至少获得一次点击的查询。

一个经常引发问题的配置细节是：所选 GSC 资源必须实际涵盖 Plausible 追踪的域名。通过 URL 前缀方式验证为 https://www.yourdomain.com 的 GSC 资源，无法连接到追踪不带子域名的 yourdomain.com 的 Plausible 网站。条件允许时，使用 GSC 的 Domain 资源类型：它涵盖所有子域名和协议，使 Plausible 的连接更直接。

Plausible 中的 GSC 数据并非实时数据：Plausible 文档说明，数据约有 24–36 小时的延迟，与 Search Console 本身相同，并建议查看两天前的数据。这是 Google 的限制，而非 Plausible 的限制。对于日常运营中的分析审查，这通常不会造成实际障碍。

无需 cookie 横幅的 GDPR 合规

这里的合规依据需要精确说明。根据《电子隐私指令》，在用户设备上存储或访问信息时，需要取得同意。cookie 和 localStorage 都会触发这一要求。Plausible 不在用户设备上存储任何内容：没有 cookie，没有 localStorage 条目，也不写入 IndexedDB。

Plausible 也不生成跨会话的持久用户标识符。每次页面浏览都独立处理。最接近用户标识符的是一个每日哈希值，由访客的 IP 地址、user agent 字符串、网站域名，以及每 24 小时更换并删除的服务器端盐值共同生成。原始 IP 地址和 user agent 不会被存储。Plausible 表示，这意味着它不收集个人数据；但由于计算哈希值时仍会短暂处理 IP 地址，判断这是否不属于 GDPR 第 4(1) 条所指的个人数据，是一项法律评估，而非技术保证。这是我们针对 tva 自身部署的评估，并非法律建议；请与您的数据保护顾问确认。

基于这一评估，实际结果是：无须同意横幅、同意管理平台或同意率优化，也不会因访客拒绝同意而产生数据缺口。看到的分析数据比仅统计愿意接受追踪的那部分人更接近整体受众，但仍会遗漏拦截脚本的访客。

我们现在的隐私政策只需用一个简洁段落，准确说明 Plausible 收集什么，以及数据存储在哪里。此前对应的 GA4 部分有好几个段落，还需要明确引用 Google 的标准合同条款和数据处理条款。对于小型组织，这显著降低了法律事务的开销。

基础设施开销与性能对比

正式停用 GA4 前，我们让两种工具并行运行了 60 天，以便直接比较。页面浏览量的差异小于 3%。

更值得分析的是独立访客数的差异。同一期间，Plausible 记录的独立访客数比取得用户同意后运行的 GA4 多约 12%。这符合预期：同意 GA4 追踪的用户往往参与度更高，也较少使用广告拦截器或注重隐私的浏览器。Plausible 不需要用户经过同意流程就能追踪访客，因此更准确地反映总体触达情况，但仍会遗漏拦截其脚本的访客。以同意模式运行的 GA4，则呈现参与度最高用户的行为画像。两者都没有错，只是在回答略有不同的问题。

基础设施占用不大。ClickHouse 在稳态下约使用 400 MB RAM，PostgreSQL 另需约 80 MB。正常运行时 CPU 用量很低，只有批量导入历史数据时才会短暂升高。对于已经运行 Hetzner 服务器、且有闲置容量的组织，将 Plausible 加入现有服务栈的边际成本实际上为零。

但实际上，是否迁移主要不是基础设施成本或功能对等的问题，而是您愿意依据哪种数据来决策。需要取得同意的网站分析会产生系统性偏差的样本；无需同意的无 cookie 分析，则提供完整得多的图景，但每位访客的细节较少。对于主要关心“哪些页面和来源带来询盘”的营销网站，更完整的图景比自选用户子集的详细画像更有用。

相关洞察

• Traefik 反向代理：HTTPS 与 SSL 自动化自托管完整指南
• 在 Hetzner Cloud 上自托管 n8n：Docker 配置完整教程
• 将 React 应用部署到生产环境：使用 Traefik 反向代理的完整 Docker 配置
• 使用 Docker 构建多租户开发环境：可扩展客户部署的完整配置