Odoo 网站短链接为什么不是“缩个网址”而已：追踪入口、统计页与自定义代码治理讲透

先说结论

Odoo 的 website_links 不只是“把长网址变短”。

它真正提供的是一套网站追踪入口层：

• 给页面生成带短码的访问入口；
• 用 /r/<code> 作为统一跳转入口；
• 用 /r/<code>+ 提供统计查看页；
• 允许用户创建最近使用链接；
• 甚至支持对短码本身做二次编辑和治理。

所以它更像：

一个轻量级、面向运营和营销分析的链接治理模块。

如果只把它看成“站内自带短链器”，会低估它在归因和日常内容运营里的价值。

一、为什么短链接在 Odoo 里首先是“追踪对象”

从 __manifest__.py 的说明就能看出，Odoo 设计 website_links 的出发点不是美化 URL，而是：

• 在 Google Analytics 中追踪点击和访客；
• 在 Odoo 自己的报表里分析 lead generation、销售收入、招聘效果等。

这意味着链接在这里不是静态文本，而是业务事件入口。

也就是说，用户点下去的不是一串缩短后的地址，而是一次可统计、可归因、可回看的访问动作。

这和很多只提供“短一点、好复制一点”的短链工具，思路完全不同。

二、为什么 /r/<code> 和 /r/<code>+ 是两个不同层级

controller/main.py 有一个很关键的设计：

• /r/<code> 是访问入口；
• /r/<code>+ 是统计页入口。

action_visit_page_statistics() 甚至直接把统计页地址拼成 short_url + '+'。

这说明 Odoo 从一开始就把“点击入口”和“统计查看”分成了两个层级：

1. 对外，给访客一个尽量短、干净的访问地址；
2. 对内，给运营或编辑一个能回看效果的管理地址。

这种设计很聪明，因为它保留了短链的易传播性，同时又不牺牲数据分析入口。

对于内容团队来说，这意味着一条链接不仅能发出去，还能被持续复盘。

三、为什么 short_url_host 要按当前站点动态计算

_compute_short_url_host() 不是简单取系统全局 base URL，而是优先看当前 website。

如果当前网站就是公司主网站，它会取当前网站的 base URL； 否则再回到公司的 base URL。

这个细节很重要，尤其是在多站点部署里。

因为短链如果挂错域名，会带来几类问题：

• 用户看到的链接域名和当前站点不一致，信任感下降；
• 归因口径被不同站点域名打散；
• 同一公司多品牌站点会出现传播口径混乱。

所以 Odoo 在这里不是只拼一个链接前缀，而是在保护：

短链入口与当前网站上下文的一致性。

这对多网站、多品牌、分国家站点尤其关键。

四、为什么 recent links 不是小功能，而是运营工作流

控制器里有 /website_links/recent_links，前端交互里也围绕 recent links 做了排序、通知、复制、再次访问等动作。

这其实揭示出一个产品判断：

短链接不是一次性生成后就遗忘的对象，而是会被反复复用、对比和再传播的运营资产。

例如你在这些场景里都会重复使用：

• 官网活动页在不同社群轮流投放；
• 招聘页被 HR 多次发到不同渠道；
• 某个 landing page 在邮件、私域、客服回复里持续引用；
• 内容团队要比较近期几个链接的表现。

如果系统没有“最近使用”层，运营只能靠 Excel 或聊天记录翻旧链接。

Odoo 把 recent links 做进模块里，本质是在承认：

内容分发不是一次点击，而是一条重复运营链路。

五、为什么允许编辑 code，背后其实是治理需求

/website_links/add_code 允许在已有 link 上新增或修改 code，前端还专门做了 code editor。

这不是花哨功能，而是对现实传播场景的妥协和支持。

很多团队会遇到这些需求：

• 想把自动生成的 code 改成更好记的语义词；
• 需要和线下海报、二维码上的简短口令保持一致；
• 想让链接更适合客服口播或视频里展示；
• 需要统一品牌活动的命名规范。

但允许改 code 也意味着治理问题会跟着出现：

• 新 code 是否已被占用；
• 历史 code 与当前 link 的关系怎么保持；
• 谁可以改、改完后传播口径是否统一。

源码里至少已经处理了一部分基础约束，比如重复 code 校验。

所以这个模块传达出的思路是：

短码不是随便的一串字符，而是值得管理的传播标识。

六、为什么创建短链接走的是 search_or_create

创建接口 /website_links/new 并不是盲目 create，而是调用 search_or_create([post])。

这通常意味着系统不希望为完全相同的目标和参数无限制造重复对象。

从运营视角看，这很合理：

• 同一页面、同一追踪参数如果每点一次“生成”就新建一条，会很快失控；
• 数据分析也会碎片化；
• 团队成员更难判断到底该继续复用哪一条链接。

所以 search_or_create 背后的产品立场是：

短链接应该尽量沉淀为可复用资产，而不是一次性垃圾对象。

七、为什么统计页本身也是一种内容对象

从模板和前端交互可以看出，统计页不是只给出一个枯燥数字，而是围绕 link 构建了可浏览、可复制、可查看趋势的界面。

也就是说，Odoo 不把 link tracker 当作底层埋点，而是把它提升成用户可操作对象：

• 能看；
• 能复用；
• 能编辑；
• 能排序；
• 能再传播。

这让运营工作不必总回到报表中心，而可以直接围绕“这条链接”做动作。

这也是 Odoo 一贯的产品风格：

把业务对象前移到日常界面，而不是藏在分析后台。

八、实施时最值得注意的点

1. 多站点一定要确认域名口径

如果你做多 website，短链 host 用哪个域名不是小事，直接影响品牌一致性和统计口径。

2. 短码编辑要有命名规范

虽然系统支持改 code，但团队最好提前约定规则，比如活动缩写、渠道后缀、地区前缀，不然很快就会混乱。

3. 不要把短链和归因分开管理

既然 Odoo 的设计本来就是追踪入口，就别再把效果复盘放到另一个完全脱节的表格里。

4. recent links 值得纳入运营 SOP

如果内容团队经常重复发链接，recent links 可以大幅减少“找旧链接”的时间浪费。

最后总结

website_links 真正讲的不是“网址缩短”，而是：

• 网站链接如何成为可追踪入口；
• 统计入口如何和传播入口并存；
• 多站点下域名如何保持一致；
• 短码如何从随机字符串变成可治理的运营标识；
• 一条链接如何在团队内被反复复用、回看和优化。

所以更准确地说，Odoo 的短链接模块不是一个小插件，而是：

官网运营里“链接资产化”的基础设施。

当你这么理解它，就会发现 /r/ 这条看起来很短的路径，背后其实连着传播、统计、命名规范和团队协作整条链路。