Offen 介绍与选型指南

目标：说清 Offen Fair Web Analytics 是什么、凭什么"公平"、适合谁用，并用同赛道开源 Web 分析工具（Matomo、Plausible、Umami、Shynet）做一轮带数据的横向对比，帮助读者在一小时内完成"认知 + 选型"决策。本文为认知篇，全部信息来自官方渠道联网溯源（标注来源与查询日期 2026-10-30），不含本地实测；部署与命令细节见本专栏后续各篇。

一、环境信息

本篇是介绍与选型指南（A1 认知篇），不依赖本地环境，所有版本号、星数、发布时间均于 2026-10-30 通过以下官方渠道实查取得：

• 官方网站：https://www.offen.dev（项目主页）
• 官方文档：https://docs.offen.dev（版本页脚标注 "This doc refers to Offen at Version v1.4.2"）
• 代码仓库：https://github.com/offen/offen（Releases Atom 源 releases.atom）
• 发行渠道：https://get.offen.dev（二进制 tar.gz 与 deb 包跳转服务）、Docker Hub offen/offen
• 社区数据：shields.io 徽章接口（img.shields.io/github/stars/offen/offen.json，返回 982）

⚠️ 说明：GitHub API 直连与 api.github.com 在查询当日不可用，星数改由 shields.io 徽章接口取证（该接口返回 JSON {"label":"stars","message":"982",...}），版本列表由 GitHub Releases Atom 源取证，两者均为官方或对官方数据的直接镜像，可信度等同于仓库页。

二、软件概述

Offen（全称 Offen Fair Web Analytics，仓库 offen/offen）是一款自托管的**公平 Web 分析（Fair Web Analytics）**工具：站长用它统计站点流量，访客则可以随时查看"关于自己的数据"并自主决定是否允许被统计。项目由 Offen 团队维护，采用 Apache-2.0 许可证发行（官方文档每页页脚均标注 "Copyright © Offen. Distributed by an Apache 2.0 license"，查询日期 2026-10-30）。

它的技术形态在同类工具中非常轻：一个 Go 语言编译的单二进制文件（Linux/macOS/Windows，官方发行覆盖 amd64、arm64、arm/v7 三种架构，官方文档 "Downloads and distributions" 页），内嵌 Web 服务器、分析面板（Auditorium）与采集脚本，默认使用 SQLite 文件数据库（默认落盘路径 /var/opt/offen/offen.db），也可以切换 MySQL 或 PostgreSQL。部署到一台 Ubuntu 服务器上只需"下载 deb 包 → dpkg -i → 填一个配置文件 → systemctl start offen"四步（完整实测过程见本专栏《Ubuntu 22.04 安装 Offen 1.4.2 指南》篇）。

"公平"（Fair）二字是它区别于传统统计工具的核心主张，落在三个具体机制上：

1. 采集前先征得同意（opt-in）：嵌入官方采集脚本后，访客会看到一条 consent 横幅（实测按钮文案为 "I allow" / "I don't allow"），未同意就不采集任何数据；
2. 数据端到端加密：事件在浏览器端用访客专属密钥加密后才入库，服务端存储的事件载荷为密文（实测数据库 events 表仅有 event_id, sequence, account_id, secret_id, payload 五列，payload 为密文）；
3. 访客可见自己的数据：访客通过横幅入口进入 Auditorium 面板，能看到自己被记录了什么、并可以删除；站长看到的是聚合视图。

💡 技术拓展：Web 分析工具的"采集合规模型"不止 opt-in 一种，常见有三类——

模型	机制	代表工具	适用取舍
opt-in（明示同意）	先弹横幅征得同意再采集	Offen	合规最稳，但会损失部分样本量
cookieless 免提示采集	不用 cookie/不存个人标识，声称无需提示	Plausible、Umami	样本全，合规解释成本低
全量采集	默认全记，靠后期匿名化	Matomo（可配）	数据最全，需自行配置合规

Offen 实际采用 opt-in 模型：这是它"公平"主张的落地方式，也是最保守的一档——选它意味着接受"样本量换合规确定性"。

三、核心架构

Offen 的整体架构是一条"浏览器内加密 → 单服务端落库 → 双视角面板"的链路，以下机制均经官方文档与实测行为印证（查询/实测日期 2026-10-30）：

访客浏览器                                服务器（单个 offen 进程）
┌─────────────────────────────┐          ┌──────────────────────────────┐
│ 站点页面                      │          │  HTTP Server（Go，单进程）      │
│  └─ <script src=/script.js>  │──GET──▶  │   ├─ /script.js  采集脚本      │
│     └─ 隐藏 <iframe /vault>  │──GET──▶  │   ├─ /vault      加密代理页    │
│         ├─ IndexedDB 密钥     │          │   ├─ /event      事件上报      │
│         ├─ consent 横幅渲染   │──POST─▶  │   ├─ /auditorium/ 分析面板 SPA │
│         └─ 事件加密（密文）    │          │   ├─ /login/ /setup/ 账户      │
└─────────────────────────────┘          │   └─ /accounts/  账户接口      │
                                          │  存储：SQLite / MySQL / PG    │
                                          │  （默认 /var/opt/offen/offen.db）│
                                          └──────────────────────────────┘

• 采集脚本 /script.js：约 13 KB 的 JavaScript（实测 13137 字节），以 <script src=".../script.js?account_id=<账户ID>"> 形式嵌入站点；脚本不在页面里直接记账，而是向源站请求一个隐藏的 <iframe src="/vault"> 页面，并通过 window.postMessage 与其通信（实测 DOM 中注入的 iframe 形如 <iframe src="http://<host>/vault" ... id="offen-vault-xxxx" style="display: none;">）。
• Vault（金库页）：访客侧的"数据代理"。它在 iframe 源（即 Offen 服务器域）下保存访客密钥与同意状态，事件在浏览器侧完成加密后才发出——服务器拿到的是密文，无法自行解密出单条访客行为。这一设计同时解释了两个实测行为：一是同意状态未建立时事件不会被发送（实测 skipConsent 参数会被 vault 按"拒绝"处理）；二是横幅按钮由脚本动态渲染进宿主页面。
• HTTP Server：单二进制内的 Go HTTP 服务。默认监听 3000 端口（OFFEN_SERVER_PORT 可改，实测改为 8080 后 curl http://localhost:8080/ 返回 200 text/html）；配置 AutoTLS 后自动改听 80/443 并向 Let's Encrypt 申请续期证书（官方 "Configuring the application" 页）。
• Auditorium（分析面板）：单页应用，挂在 /auditorium/。同一个面板有两种视角——站长登录后看聚合统计；访客从横幅入口进入后看自己的明细并可删除。面板按账户（Account）组织，一个实例可建多个账户、每个账户有独立的 account_id 与嵌入脚本。
• 存储层：默认 SQLite 单文件；实测数据库包含 accounts、account_users、secrets、events、tombstones、migrations 等表，事件表只存密文。高流量场景可切 MySQL（连接串需追加 ?parseTime=true）或 PostgreSQL（本地连接需追加 ?sslmode=disable，官方配置文档原文）。
• 后台例行任务：单节点模式（默认）下进程内置 cron，自动执行数据库迁移与过期事件清理（默认保留 6 个月，实测启动日志输出 Cron successfully pruned expired events removed=0）；横向扩展多实例时改为手动跑 offen migrate / offen expire（官方 "Using the Offen command" 页）。

💡 技术拓展：嵌入式 Web 应用常见的"分析脚本 + 后端"数据通道实现不止 iframe 一条路——

方案	原理	取舍
隐藏 iframe + postMessage（Offen 采用）	脚本在源站域下开 iframe，密钥与加密都留在源站上下文	天然隔离宿主页面与密钥，跨站嵌入安全
同域 API 直调	脚本直接 fetch 后端接口	简单，但密钥暴露在站点上下文
Web Worker + IndexedDB	后台线程计算与存储	不阻塞主线程，但跨域密钥管理复杂

Offen 实际采用 iframe 方案，这是它能实现"端到端加密 + 访客自助管理"的架构前提。

四、功能特性

以下特性清单来自官方文档（docs.offen.dev，查询日期 2026-10-30），标注"实测"的条目在部署实验中验证过（详见部署篇）：

• 合规采集：consent 横幅（可自定义文案与样式，官方 "Customizing the consent banner" 页），opt-in 后才采集；实测横幅按钮文案为 "I allow" / "I don't allow"。
• 双视角面板：站长看聚合数据，访客看并管理自己的数据（官方 "Metrics explained" 页）。
• UTM 与来源标记：官方 "Tagging campaigns and sources (UTM)" 页，支持按 utm 参数与来源渠道拆分流量。
• 多账户与协作：一个实例多账户，每账户独立脚本与面板；支持邮件邀请新用户（需配置 SMTP）。
• AutoTLS：内置 Let's Encrypt 自动申请与续期（OFFEN_SERVER_AUTOTLS 配域名列表，需公网 80/443 可达）；也支持自带证书（OFFEN_SERVER_SSLCERTIFICATE / OFFEN_SERVER_SSLKEY）。
• 数据保留策略：默认 6 个月自动清理，可选 12weeks / 6weeks / 30days / 7days（OFFEN_APP_RETENTION）；缩短后重启即删旧数据，不可恢复（官方文档 Heads Up 原文）。
• 多语言界面：en / de / fr / es / pt / vi 六种（OFFEN_APP_LOCALE）。实测填 zh 直接 fatal 退出：unknown or unsupported locale zh——中文界面暂不支持。
• 零配置体验：offen demo 子命令一条命令起一个带模拟流量的一次性实例（实测 -users 120 生成 1313 条事件、自带 Demo Account，访问 http://localhost:<port>/intro/ 进入；命令参数与临时库生命周期实测见《Offen 1.4.2 常用 CLI 命令与工具详解》4.8 节）。
• 多发行渠道：单二进制 tar.gz（get.offen.dev）、deb 包（get.offen.dev/deb，Ubuntu/Debian 适用）、Docker 镜像（offen/offen）、Heroku 一键部署模板、YunoHost 应用包（官方 "Downloads and distributions" 页）；发行件带 GPG 签名可验证（keybase hioffen 公钥）。
• 运维友好：环境变量 + env 文件配置（/etc/offen/offen.env），offen debug 一键打印当前生效配置（实测输出完整 JSON，逐字段解读见《Offen 1.4.2 配置参数详解》），systemd 服务随 deb 包附带。

五、快速开始（最小可用示例）

最快体验路径是官方提供的零配置 demo 模式——下载二进制后一条命令即可看到带数据的完整面板。以下命令与回显为 Ubuntu 22.04 实测（2026-10-30，完整安装流程见本专栏《Ubuntu 22.04 安装 Offen 1.4.2 指南》篇）：

# 下载并解压单二进制（Linux amd64）
curl -sSL https://get.offen.dev -o offen.tar.gz
tar -xzf offen.tar.gz

# 启动一次性 demo 实例（模拟 120 个访客，随机空闲端口）
./offen-linux-amd64 demo -port 8131 -users 120

实测关键回显（进度条略）：

time="2026-10-30T01:22:46Z" level=info msg="Offen is generating some random usage data for your demo, this might take a little while."
time="2026-10-30T01:22:46Z" level=info msg="You can now start your Offen demo by visiting"
time="2026-10-30T01:22:46Z" level=info
time="2026-10-30T01:22:46Z" level=info msg="--> http://localhost:8131/intro/ <--"

浏览器打开 http://localhost:8131/intro/，demo 实例使用固定演示账号 demo@offen.dev（密码 demo，offen demo -h 原文）登录 Auditorium 即可看到模拟流量面板。demo 数据存于临时数据库（实测文件 /tmp/offen-demo-<uuid>.db，生成 1313 条事件、账户名 "Demo Account"），进程退出即删除，适合纯体验、不留任何生产痕迹。

要走生产路径，最小闭环是四步（每条命令的完整回显见《Ubuntu 22.04 安装 Offen 1.4.2 指南》，配置逐项含义见《Offen 1.4.2 配置参数详解》）：

# 1. 安装（Ubuntu/Debian）
curl -sSL https://get.offen.dev/deb -o offen.deb && sudo dpkg -i offen.deb

# 2. 生成签名密钥并写入 /etc/offen/offen.env
offen secret -quiet

# 3. 首次配置：创建账户
offen setup -email admin@example.com -name "Demo Site" -password q1w2e3r4

# 4. systemd 托管启动
sudo systemctl enable --now offen

步骤 3 实测回显（2026-10-30）：

time="2026-10-30T01:14:02Z" level=info msg="Successfully created account Demo Site with ID 5e00fe8d-cf71-4226-9c7e-37ccc5195145, you can use the given credentials to access it"

之后把面板里给出的嵌入代码加进站点页面（脚本地址与 account_id 取你的实例域名与上一步创建的账户 ID）：

<script src="https://offen.example.com/script.js?account_id=5e00fe8d-cf71-4226-9c7e-37ccc5195145"></script>

访客在横幅上点击 "I allow" 后，数据即开始入库。

六、适用场景与限制

适用场景（结合其架构与合规模型判断）：

• 个人博客、中小型企业站的合规统计：单二进制 + SQLite 的运维成本几乎为零，一台小规格服务器即可长期运行（实测 systemd 托管下进程常驻内存约 6.6 MB，systemctl status offen 回显 Memory: 6.6M）。
• 对隐私承诺有硬要求的站点：opt-in + 端到端加密 + 访客自助查看/删除，能直接向用户解释"数据怎么被处理"，比"我们承诺不滥用"更可验证。
• 多站点统一统计：单实例多账户模型，一个 offen 进程可同时服务多个站点，各站点独立脚本与面板。
• 内网/自托管环境：不依赖第三方 SaaS，数据全程不出自有机房。

限制与注意（官方文档明示或实测发现）：

• 必须 HTTPS：官方要求 Offen 实例以 SSL 提供（AutoTLS 或自带证书）；宿主站点若用 http，加密退化为 userland 实现，"heavy and slow and is not recommended"（官方安装要求页原文）。
• 中文界面缺失：OFFEN_APP_LOCALE 仅支持 en/de/fr/es/pt/vi，实测 zh 直接 fatal。
• 邮件功能依赖 SMTP：邀请用户、重置密码需要发信；不配 SMTP 时回退本机 sendmail 且"很可能永远发不出去"（官方原文），Docker 镜像中无 sendmail 回退。
• 不建议套反向代理：官方"actively advise against"——代理日志会留下访客 IP 等 Offen 本身刻意不采集的信息；直连暴露时用 AutoTLS。
• 更新节奏放缓：Releases Atom（查询 2026-10-30）显示最近一个正式版为 v1.4.2（2024-05-21 发布），其前为 2024-05 的 v1.4.1/v1.4.0 与 2022 年的 v1.2.x–v1.3.x 系列；选型时应把"上游活跃度"纳入评估。
• 无对外数据 API 文档：数据消费以 Auditorium 面板为主，官方未提供公开的 REST 统计 API（对比 Plausible 提供完整 API，见 《Plausible API 使用详解》）。
• 单节点为主：默认单机模式；虽可切 MySQL/Postgres 并关闭 OFFEN_APP_SINGLENODE 做多实例，但官方文档与发行形态均以单节点为第一形态。

七、同类选型对比

下表对比 2026-10-30 当日实查的开源 Web 分析工具（星数与版本号取自 shields.io 徽章接口当日返回值；Offen 版本另经 GitHub Releases Atom 复核）：

* Matomo 的 GitHub release 徽章当日返回 invalid、Releases Atom 直连失败，故不落具体版本号，选型时请以 matomo.org 官方发布页为准。

关键差异与选型解读：

• 要"最稳的合规故事"选 Offen：只有它把"访客同意 + 访客可见 + 端到端加密"做成默认行为，代价是 opt-in 横幅会损失样本、且面板能力（UTM、来源拆分）比 Plausible/Umami 精简。
• 要"功能最全的自托管统计"选 Matomo：生态与插件最成熟，但 PHP 套件 + 数据库的运维重量和合规配置成本都更高。
• 要"开箱即用的现代面板"选 Plausible 或 Umami：两者星数与活跃度都远超 Offen；Plausible 强在事件与 API（站内有完整四篇：《Plausible 介绍与选型指南》、《Plausible 配置参数详解》），Umami 轻量友好（站内：《Umami 介绍与选型指南》、《Umami 3.4 配置参数详解》），但它们都是"站长单视角"，访客无法看到或管理自己的数据。
• 要"从服务器日志做无侵入统计"选 GoAccess：完全不嵌脚本、不碰浏览器，适合已有访问日志的场景（站内：《GoAccess 介绍与选型指南》、《GoAccess 常用 CLI 命令与工具详解》），但拿不到 JS 级事件与设备明细。
• 社区活跃度提醒：Offen 星数与更新节奏在五者中垫底（982 星、最近正式版 2024-05），把它当作"小而美的合规方案"而非"长期重投入的平台"来评估更稳妥。

八、参考链接

• 官方网站：https://www.offen.dev
• 官方文档（本篇溯源主源）：https://docs.offen.dev
• 安装要求（SSL/存储/反代/邮件）：https://docs.offen.dev/running-offen/installation-requirements/
• 配置参考：https://docs.offen.dev/running-offen/configuring-the-application/
• 命令参考：https://docs.offen.dev/running-offen/using-the-command/
• 下载与发行渠道：https://docs.offen.dev/running-offen/downloads-distributions/
• 代码仓库：https://github.com/offen/offen
• 本站相关篇章：《Plausible 介绍与选型指南》、《Umami 介绍与选型指南》、《GoAccess 介绍与选型指南》；本专栏其余篇章：《Ubuntu 22.04 安装 Offen 1.4.2 指南》、《Offen 1.4.2 配置参数详解》、《Offen 1.4.2 常用 CLI 命令与工具详解》