Umami 每周流量由 AI 总结并存进 Baserow

Umami 每周流量由 AI 总结并存进 Baserow

一个把一周的网站流量变成文字报告的 n8n 工作流。它每周从 Umami 读取你网站的数据，并请 OpenRouter 上的 AI 模型写出一张小结表。接着它读取这周和上周的热门页面，请模型比较它们，并提出五条修改建议。两份回答作为一行存进 Baserow 表格。

包里有什么

• workflow.json：n8n 导出的工作流，13 个节点和六张便签。里面没有任何凭据。
• README.md：这份设置说明，压缩包里的是英文版。

我们相对原来的副本改了什么

• Get view stats from Umami 原来调用的是 event-data/stats，这是自定义事件的路由，而后面的代码却在它的回答里找页面浏览量和访客数。现在节点调用 stats，它给出页面浏览量、访客数、访问次数、跳出次数和总时长。
• 两个页面节点原来要的是 type=url，还发了一个 tz 设置。Umami 的源码（2026 年 11 月 12 日查阅）在指标类型里列出了 path，没有 url，所以两个节点现在都用 type=path。它们也只要一份简短的页面列表。Umami 自己的默认值是 500，那样问题会很长。时区设置用不上，已经去掉。
• Parse Umami data 把每个数据当成一对 value 和 prev 来读。Umami 现在的回答里，每个数据是一个数字，之前 7 天的数据放在一个 comparison 对象里。现在代码两种形式都能读。
• 三个代码节点都把数据过了一遍 encodeURIComponent，所以模型收到的是百分号编码。现在代码节点写的是纯文本行，每个 AI 请求体用 JSON.stringify 生成。
• 两个 AI 节点原来要的都是 meta-llama/llama-3.1-70b-instruct:free。OpenRouter 的公开模型列表（2026 年 11 月 12 日查阅）没有这个名字。列表里有 meta-llama/llama-3.1-70b-instruct，所以这份副本用它。
• 每个页面节点现在都开了 Always Output Data，所以一周没有页面浏览数据时，流程仍会到达比较那一步。
• 新增一个节点 Site to check，把 Umami 地址、网站 ID 和网站名称只写一次。原来的副本把作者自己的主机和网站 ID 写在各个节点里，提示词里还写着作者的网站名。它们都去掉了。
• 新增一个节点 Row for Baserow，给四个值起名 Date、Summary、Pages 和 Site，Save data to Baserow 按名称把它们对应到表的字段。原来的副本是按编号选字段，而那些编号属于作者自己的表。
• 六张便签重写过，里面没有外部链接。原来的副本里有指向作者自己页面的链接。
• 所有凭据引用都去掉了，所以由你自己选。

开始之前

• 一个 n8n 实例，n8n Cloud 或你自己的服务器。
• 一个你能读取的 Umami 站点，它的 API 地址、网站 ID 和一个令牌。在 Umami Cloud 上，地址是 https://api.umami.is/v1，令牌是一个 API 密钥。
• 一个 OpenRouter API 密钥。
• 一个 Baserow 账号，Baserow Cloud 或你自己的服务器都行，和一个有 Date、Summary、Pages、Site 字段的表格。把 Summary 和 Pages 设成长文本字段，因为回答很长。

设置

1. 在 n8n 里新建一个工作流，打开它的菜单，选 Import from File。选中 workflow.json。
2. 在 Umami 里，从你站点的设置中找到网站 ID。
3. 获取令牌。向你的 Umami 服务器上的 /api/auth/login 发一个 POST 请求，JSON 请求体里放你的 username 和 password。返回的内容里有一个 token。
4. 在 Site to check 里，把 YOUR_UMAMI_HOST 换成你的 Umami 服务器地址，末尾保留 /api。把 YOUR_WEBSITE_ID 换成网站 ID，把 YOUR_SITE_NAME 换成你给网站起的名字。
5. 在 Get view stats from Umami 里，添加一个 Header Auth 凭据，名称是 Authorization，值是 Bearer、一个空格和你的令牌。在 Get page data from Umami 和 Get page view data from Umami 里选同一个凭据。
6. 在 Send data to A.I. 里，再添加一个 Header Auth 凭据，名称是 Authorization，值是 Bearer、一个空格和你的 OpenRouter API 密钥。在 Send data to A.I.1 里也选它。
7. 在 Save data to Baserow 里，添加一个 Baserow 凭据，填你的 Baserow 地址、邮箱和密码。然后选你的数据库和你的表。
8. 点 Test workflow。表里会多出新的一行。
9. 打开这个工作流，这样 Schedule Trigger 就会每周运行它。

一次运行是怎样的

1. Schedule Trigger 自己开始运行。它的规则是每周星期四，小时和分钟保持 n8n 的默认值，所以是星期四 00:00，用你的 n8n 的时区。When clicking ‘Test workflow’ 则是手动开始。
2. Site to check 把三个值传下去。
3. Get view stats from Umami 读取最近 7 天的数据。
4. Parse Umami data 把它们变成文本行，每行有最近 7 天的数据和之前 7 天的数据。
5. Send data to A.I. 请 OpenRouter 给出一张小结表和两三条观察。
6. Get page data from Umami 读取最近 7 天的前 20 个页面，Parse Umami data1 把它们变成文本行。
7. Get page view data from Umami 读取之前 7 天的热门页面，Parse Umami 把它们变成文本行。
8. Send data to A.I.1 把两份列表都发出去，要求给出一张对比表和五条建议。
9. Row for Baserow 取日期、第一份回答、第二份回答和网站名称。
10. Save data to Baserow 把它们加成新的一行。

改变风格

• 网站：Site to check 里的三个值。
• 星期几和几点：Schedule Trigger 里的规则。
• 统计周期的长度：三个 Umami 节点地址里的天数。
• 页面数量：两个页面节点里的 limit=20。
• 问题：两个 AI 节点里的文字。
• 模型：两个 AI 节点的 JSON 请求体里的 model 名称。OpenRouter 列表里的任何模型都行。
• 列：Row for Baserow 里的四个值。它们的名称必须和表的字段一致。
• 好几个网站：为每个网站复制一份工作流。

注意事项

• 这份副本写明的模型 meta-llama/llama-3.1-70b-instruct，在那个列表里提示词和回答每个 token 都是 0.00000072 美元，也就是每百万个 token 约 0.72 美元。每周两次调用，花费很小。想不花钱，就从同一个列表里选一个免费模型，比如 google/gemma-4-31b-it:free。免费模型有使用限制，免费的名字以后也可能从列表里消失。
• Umami 的文档说，登录路由给出的令牌要作为 Bearer 请求头发送。如果某次运行以授权错误结束，就用同样的办法生成新令牌，并更新凭据。
• 每个页面旁边的数字，是 Umami 对这个页面统计的不同会话数。
• 你的数据：页面路径、访客数和这些数据会发给 OpenRouter 和模型的提供方。两份说明存在 Baserow。
• 每周的规则只在工作流打开时才运行。你手动开始的运行随时都能用。