自托管网站统计 Umami个人博客接入实时数据后用 cpolar 临时给运营/客户查看访问面板个人博客上线以后最容易被忽略的一件事不是页面是否够漂亮而是有没有人真的打开过。文章发出去后站长会关心访问量、访问来源、热门页面运营同事会关心活动链接有没有流量客户验收落地页时也经常会问一句现在能不能看一下实时访问数据如果只是做个人站、活动页、小型官网完全可以把网站统计系统放在自己机器或 NAS 上跑。Umami 是一个轻量的开源网站统计工具支持实时访客、页面浏览、来源、设备、地域等常用指标。本文演示用 Docker 在本地部署 Umami把统计脚本接入一个简单 HTML 页面再用 cpolar 临时开放一个 HTTPS 地址让运营或客户远程查看访问面板。验收结束后关闭隧道数据仍然留在本地。本文只使用演示数据。后台账号请设置强密码cpolar 只在验收窗口短时开放数据库端口不暴露不要公开 Docker socket演示结束后关闭隧道并修改演示账号密码。一、准备环境与目录本文使用一台已经安装 Docker 和 Docker Compose 的本地机器。Umami 面板只监听本机地址避免直接暴露到局域网或公网。目录结构如下mkdir -p ~/umami-demo cd ~/umami-demo新建.env文件用来放数据库密码和应用密钥。这里写占位值实际部署时请替换成随机强密码和随机字符串不要复用截图、教程或团队聊天里出现过的内容。cat .env EOF POSTGRES_PASSWORDreplace_with_a_strong_database_password DATABASE_URLpostgresql://umami:replace_with_a_strong_database_passworddb:5432/umami APP_SECRETreplace_with_a_long_random_app_secret EOF接着创建docker-compose.yml。注意umami服务的端口绑定是127.0.0.1:3000:3000数据库服务没有ports字段因此 PostgreSQL 只在 Docker 内部网络中供 Umami 访问不会被直接暴露出来。services: db: image: postgres:15-alpine container_name: umami-db restart: unless-stopped environment: POSTGRES_DB: umami POSTGRES_USER: umami POSTGRES_PASSWORD: ${POSTGRES_PASSWORD} volumes: - umami-db-data:/var/lib/postgresql/data healthcheck: test: [CMD-SHELL, pg_isready -U umami -d umami] interval: 10s timeout: 5s retries: 5 umami: image: ghcr.io/umami-software/umami:postgresql-latest container_name: umami-web restart: unless-stopped depends_on: db: condition: service_healthy environment: DATABASE_URL: ${DATABASE_URL} DATABASE_TYPE: postgresql APP_SECRET: ${APP_SECRET} ports: - 127.0.0.1:3000:3000 volumes: umami-db-data:启动服务docker compose up -d查看容器状态docker compose ps浏览器打开http://127.0.0.1:3000进入后台后第一件事是完成管理员账号初始化或修改初始密码。不要把后台账号写进脚本也不要把账号密码发给无关人员。后面给运营或客户看面板时建议创建一个临时演示账号只授予查看所需站点数据的权限。二、在 Umami 中添加个人博客站点登录 Umami 后进入设置页面添加一个 Website。这里以个人博客为例NameMy Blog DemoDomainblog.example.localTimezone选择站点主要受众所在时区保存后Umami 会生成一段 tracking script。脚本形式类似下面这样其中data-website-id是每个站点独有的 ID请以后台实际生成的值为准。script defer srchttp://127.0.0.1:3000/script.js>三、创建一个简单 HTML 页面并接入统计脚本为了让流程更直观我们用一个简单页面模拟个人博客文章页。新建site目录mkdir -p site cat site/index.html EOF !doctype html html langzh-CN head meta charsetutf-8 meta nameviewport contentwidthdevice-width, initial-scale1 title我的博客演示页/title script defer srchttp://127.0.0.1:3000/script.js>cd site python3 -m http.server 8080 --bind 127.0.0.1浏览器访问http://127.0.0.1:8080/index.html多刷新几次首页再打开关于页。回到 Umami 面板可以看到页面浏览数据开始出现。实时页面里会显示当前访问统计页里能看到页面路径、Referrer、浏览器、操作系统、设备类型、国家和地区等信息。对于个人博客这些指标已经足够判断一篇文章有没有被打开、用户从哪里来、哪些页面更受关注。如果你想演示来源统计可以从另一个本地页面放一个链接跳转到博客页或在浏览器地址栏追加 UTM 参数例如http://127.0.0.1:8080/index.html?utm_sourcedemoutm_mediumreviewutm_campaignumami这样在 Umami 中查看来源和活动参数时运营同事能直接看到演示访问是从哪个渠道进入的。演示时建议使用清晰的测试命名例如demo、review、client_check不要混入真实客户名称、真实投放渠道或生产数据。四、用 cpolar 临时开放 Umami 面板本地部署完成后运营或客户如果不在同一台机器上就无法直接打开127.0.0.1:3000。这时可以用 cpolar 建一个临时 HTTPS 隧道只把 Umami Web 面板转发出去。数据库仍然不暴露Docker socket 也不暴露。先确认本机 Umami 正常curl -I http://127.0.0.1:3000启动 cpolar 隧道cpolar http 3000cpolar 会生成一个临时公网 HTTPS 地址。把这个地址发给运营或客户前先用无痕窗口打开确认进入的是 Umami 登录页而不是其他本地服务。然后提供临时演示账号让对方只查看本次演示站点的数据。验收时可以按这个顺序讲解打开实时页面现场刷新博客页观察实时访客变化。打开页面统计查看/index.html与/about.html的浏览量。查看来源、设备、浏览器、地域分布说明这些都是演示访问数据。打开时间范围筛选切换今天、最近 24 小时或自定义时间段。如果客户只关心结果不需要进入设置页就不要展示站点配置和账号管理页面。这里要特别注意cpolar 开放的是 Umami 面板不是数据库端口也不是 Docker 管理端口。不要把5432、Docker API、SSH、NAS 管理后台一起暴露出去。隧道只服务于一次验收讲解结束后立即关闭。五、运营/客户验收时怎么讲得清楚很多站长在演示统计系统时会陷入技术细节脚本怎么加载、容器怎么编排、数据库怎么存储。对运营或客户来说更重要的是数据能回答什么问题。可以围绕下面几个点演示实时访问现在是否有人打开页面刷新后数据是否更新。页面浏览哪篇文章、哪个落地页被访问得更多。访问来源用户从直接访问、外部链接、活动参数中的哪个入口进入。地域与设备访问者大致来自哪些地区主要使用桌面端还是移动端。时间筛选今天、最近几天、活动期间的数据是否能分开查看。如果对方只需要验收截图可以在本地生成截图后发送如果对方需要自己点开筛选就使用临时账号加 cpolar 短时开放。不要为了方便把管理员账号长期共享出去也不要把隧道地址贴到公开群、文章评论区或工单附件里。六、正式使用前的落地建议演示跑通以后如果准备把 Umami 用在长期博客或小型官网上建议把“演示环境”和“正式环境”分开处理。演示环境只用于给运营、客户看流程数据命名保持简单正式环境则需要配置稳定域名、HTTPS、备份策略和账号权限。这样做的好处是边界清楚演示时产生的刷新、测试点击、验收访问不会污染正式报表正式报表也不会因为一次远程讲解而暴露给无关人员。对于个人博客最实用的做法是把 tracking script 放到主题模板的公共头部或底部例如head.html、footer.html、layout.html这类文件。这样新增文章时不需要每篇手工粘贴脚本后续如果要停用统计也只需要从模板里删除一次。对于临时活动页则可以单独建一个 Website活动结束后保留报表截图和导出数据再停用页面脚本。数据解读也要克制。Umami 能帮助你看到访问趋势、热门页面和来源分布但不要把一次短时间演示里的刷新量当成正式效果。给客户验收时可以明确说明当前面板展示的是演示访问用来确认统计链路已经打通正式上线后的效果评估以真实投放周期和生产页面数据为准。七、常见问题处理1. 页面刷新了但 Umami 没有数据先检查 HTML 里的data-website-id是否替换成后台生成的站点 ID再打开浏览器开发者工具看script.js是否加载成功。演示环境中博客页面和 Umami 都跑在本机脚本地址应保持为http://127.0.0.1:3000/script.js。2. cpolar 地址打开后访问不到面板确认 Umami 容器正在运行并且本机可以打开http://127.0.0.1:3000。如果本机都打不开先处理 Docker 服务如果本机能打开再重启 cpolar 隧道并复制新的 HTTPS 地址。3. 不想让客户看到管理设置创建临时演示账号只给需要查看的站点权限。演示结束后改密码或删除账号。客户只需要看统计结果时不要使用管理员账号进行远程演示。4. 演示页面后续不用统计了从 HTML 或博客模板中移除 tracking script重新部署页面。Umami 中保留历史演示数据即可后续页面不会继续上报访问。临时开放后的收尾清单关闭 cpolar 隧道确认临时 HTTPS 地址已经无法访问 Umami 面板。修改临时演示账号密码或直接删除演示账号。确认 Umami 后台管理员账号使用强密码并且没有共享给外部人员。确认 PostgreSQL 没有ports暴露配置数据库端口没有对外开放。确认没有公开 Docker socket、SSH 或 NAS 管理后台。确认统计脚本可移除如果演示页面不再需要统计从 HTML 或博客模板删除 tracking script。清理演示数据命名避免把真实客户名称、真实渠道和生产访问混在演示站点里。用 Umami 做个人博客统计的价值在于部署轻、数据在自己手里、面板足够直观。再配合 cpolar 的短时访问能力远程验收不需要临时搭公网服务器也不需要把数据库或后台管理口暴露出去。流程跑通以后个人站长可以用它观察文章访问小团队也可以用它给运营和客户做清晰、可控的流量说明。
自托管网站统计 Umami：个人博客接入实时数据后，用 cpolar 临时给运营/客户查看访问面板
自托管网站统计 Umami个人博客接入实时数据后用 cpolar 临时给运营/客户查看访问面板个人博客上线以后最容易被忽略的一件事不是页面是否够漂亮而是有没有人真的打开过。文章发出去后站长会关心访问量、访问来源、热门页面运营同事会关心活动链接有没有流量客户验收落地页时也经常会问一句现在能不能看一下实时访问数据如果只是做个人站、活动页、小型官网完全可以把网站统计系统放在自己机器或 NAS 上跑。Umami 是一个轻量的开源网站统计工具支持实时访客、页面浏览、来源、设备、地域等常用指标。本文演示用 Docker 在本地部署 Umami把统计脚本接入一个简单 HTML 页面再用 cpolar 临时开放一个 HTTPS 地址让运营或客户远程查看访问面板。验收结束后关闭隧道数据仍然留在本地。本文只使用演示数据。后台账号请设置强密码cpolar 只在验收窗口短时开放数据库端口不暴露不要公开 Docker socket演示结束后关闭隧道并修改演示账号密码。一、准备环境与目录本文使用一台已经安装 Docker 和 Docker Compose 的本地机器。Umami 面板只监听本机地址避免直接暴露到局域网或公网。目录结构如下mkdir -p ~/umami-demo cd ~/umami-demo新建.env文件用来放数据库密码和应用密钥。这里写占位值实际部署时请替换成随机强密码和随机字符串不要复用截图、教程或团队聊天里出现过的内容。cat .env EOF POSTGRES_PASSWORDreplace_with_a_strong_database_password DATABASE_URLpostgresql://umami:replace_with_a_strong_database_passworddb:5432/umami APP_SECRETreplace_with_a_long_random_app_secret EOF接着创建docker-compose.yml。注意umami服务的端口绑定是127.0.0.1:3000:3000数据库服务没有ports字段因此 PostgreSQL 只在 Docker 内部网络中供 Umami 访问不会被直接暴露出来。services: db: image: postgres:15-alpine container_name: umami-db restart: unless-stopped environment: POSTGRES_DB: umami POSTGRES_USER: umami POSTGRES_PASSWORD: ${POSTGRES_PASSWORD} volumes: - umami-db-data:/var/lib/postgresql/data healthcheck: test: [CMD-SHELL, pg_isready -U umami -d umami] interval: 10s timeout: 5s retries: 5 umami: image: ghcr.io/umami-software/umami:postgresql-latest container_name: umami-web restart: unless-stopped depends_on: db: condition: service_healthy environment: DATABASE_URL: ${DATABASE_URL} DATABASE_TYPE: postgresql APP_SECRET: ${APP_SECRET} ports: - 127.0.0.1:3000:3000 volumes: umami-db-data:启动服务docker compose up -d查看容器状态docker compose ps浏览器打开http://127.0.0.1:3000进入后台后第一件事是完成管理员账号初始化或修改初始密码。不要把后台账号写进脚本也不要把账号密码发给无关人员。后面给运营或客户看面板时建议创建一个临时演示账号只授予查看所需站点数据的权限。二、在 Umami 中添加个人博客站点登录 Umami 后进入设置页面添加一个 Website。这里以个人博客为例NameMy Blog DemoDomainblog.example.localTimezone选择站点主要受众所在时区保存后Umami 会生成一段 tracking script。脚本形式类似下面这样其中data-website-id是每个站点独有的 ID请以后台实际生成的值为准。script defer srchttp://127.0.0.1:3000/script.js>三、创建一个简单 HTML 页面并接入统计脚本为了让流程更直观我们用一个简单页面模拟个人博客文章页。新建site目录mkdir -p site cat site/index.html EOF !doctype html html langzh-CN head meta charsetutf-8 meta nameviewport contentwidthdevice-width, initial-scale1 title我的博客演示页/title script defer srchttp://127.0.0.1:3000/script.js>cd site python3 -m http.server 8080 --bind 127.0.0.1浏览器访问http://127.0.0.1:8080/index.html多刷新几次首页再打开关于页。回到 Umami 面板可以看到页面浏览数据开始出现。实时页面里会显示当前访问统计页里能看到页面路径、Referrer、浏览器、操作系统、设备类型、国家和地区等信息。对于个人博客这些指标已经足够判断一篇文章有没有被打开、用户从哪里来、哪些页面更受关注。如果你想演示来源统计可以从另一个本地页面放一个链接跳转到博客页或在浏览器地址栏追加 UTM 参数例如http://127.0.0.1:8080/index.html?utm_sourcedemoutm_mediumreviewutm_campaignumami这样在 Umami 中查看来源和活动参数时运营同事能直接看到演示访问是从哪个渠道进入的。演示时建议使用清晰的测试命名例如demo、review、client_check不要混入真实客户名称、真实投放渠道或生产数据。四、用 cpolar 临时开放 Umami 面板本地部署完成后运营或客户如果不在同一台机器上就无法直接打开127.0.0.1:3000。这时可以用 cpolar 建一个临时 HTTPS 隧道只把 Umami Web 面板转发出去。数据库仍然不暴露Docker socket 也不暴露。先确认本机 Umami 正常curl -I http://127.0.0.1:3000启动 cpolar 隧道cpolar http 3000cpolar 会生成一个临时公网 HTTPS 地址。把这个地址发给运营或客户前先用无痕窗口打开确认进入的是 Umami 登录页而不是其他本地服务。然后提供临时演示账号让对方只查看本次演示站点的数据。验收时可以按这个顺序讲解打开实时页面现场刷新博客页观察实时访客变化。打开页面统计查看/index.html与/about.html的浏览量。查看来源、设备、浏览器、地域分布说明这些都是演示访问数据。打开时间范围筛选切换今天、最近 24 小时或自定义时间段。如果客户只关心结果不需要进入设置页就不要展示站点配置和账号管理页面。这里要特别注意cpolar 开放的是 Umami 面板不是数据库端口也不是 Docker 管理端口。不要把5432、Docker API、SSH、NAS 管理后台一起暴露出去。隧道只服务于一次验收讲解结束后立即关闭。五、运营/客户验收时怎么讲得清楚很多站长在演示统计系统时会陷入技术细节脚本怎么加载、容器怎么编排、数据库怎么存储。对运营或客户来说更重要的是数据能回答什么问题。可以围绕下面几个点演示实时访问现在是否有人打开页面刷新后数据是否更新。页面浏览哪篇文章、哪个落地页被访问得更多。访问来源用户从直接访问、外部链接、活动参数中的哪个入口进入。地域与设备访问者大致来自哪些地区主要使用桌面端还是移动端。时间筛选今天、最近几天、活动期间的数据是否能分开查看。如果对方只需要验收截图可以在本地生成截图后发送如果对方需要自己点开筛选就使用临时账号加 cpolar 短时开放。不要为了方便把管理员账号长期共享出去也不要把隧道地址贴到公开群、文章评论区或工单附件里。六、正式使用前的落地建议演示跑通以后如果准备把 Umami 用在长期博客或小型官网上建议把“演示环境”和“正式环境”分开处理。演示环境只用于给运营、客户看流程数据命名保持简单正式环境则需要配置稳定域名、HTTPS、备份策略和账号权限。这样做的好处是边界清楚演示时产生的刷新、测试点击、验收访问不会污染正式报表正式报表也不会因为一次远程讲解而暴露给无关人员。对于个人博客最实用的做法是把 tracking script 放到主题模板的公共头部或底部例如head.html、footer.html、layout.html这类文件。这样新增文章时不需要每篇手工粘贴脚本后续如果要停用统计也只需要从模板里删除一次。对于临时活动页则可以单独建一个 Website活动结束后保留报表截图和导出数据再停用页面脚本。数据解读也要克制。Umami 能帮助你看到访问趋势、热门页面和来源分布但不要把一次短时间演示里的刷新量当成正式效果。给客户验收时可以明确说明当前面板展示的是演示访问用来确认统计链路已经打通正式上线后的效果评估以真实投放周期和生产页面数据为准。七、常见问题处理1. 页面刷新了但 Umami 没有数据先检查 HTML 里的data-website-id是否替换成后台生成的站点 ID再打开浏览器开发者工具看script.js是否加载成功。演示环境中博客页面和 Umami 都跑在本机脚本地址应保持为http://127.0.0.1:3000/script.js。2. cpolar 地址打开后访问不到面板确认 Umami 容器正在运行并且本机可以打开http://127.0.0.1:3000。如果本机都打不开先处理 Docker 服务如果本机能打开再重启 cpolar 隧道并复制新的 HTTPS 地址。3. 不想让客户看到管理设置创建临时演示账号只给需要查看的站点权限。演示结束后改密码或删除账号。客户只需要看统计结果时不要使用管理员账号进行远程演示。4. 演示页面后续不用统计了从 HTML 或博客模板中移除 tracking script重新部署页面。Umami 中保留历史演示数据即可后续页面不会继续上报访问。临时开放后的收尾清单关闭 cpolar 隧道确认临时 HTTPS 地址已经无法访问 Umami 面板。修改临时演示账号密码或直接删除演示账号。确认 Umami 后台管理员账号使用强密码并且没有共享给外部人员。确认 PostgreSQL 没有ports暴露配置数据库端口没有对外开放。确认没有公开 Docker socket、SSH 或 NAS 管理后台。确认统计脚本可移除如果演示页面不再需要统计从 HTML 或博客模板删除 tracking script。清理演示数据命名避免把真实客户名称、真实渠道和生产访问混在演示站点里。用 Umami 做个人博客统计的价值在于部署轻、数据在自己手里、面板足够直观。再配合 cpolar 的短时访问能力远程验收不需要临时搭公网服务器也不需要把数据库或后台管理口暴露出去。流程跑通以后个人站长可以用它观察文章访问小团队也可以用它给运营和客户做清晰、可控的流量说明。
