Odoo 企业版 Social Push 为什么不是“给网站访客群发通知”而已：visitor domain、timezone 分批与 Firebase 边界讲透

网站 push 最容易被想成“写一条文案，然后发给所有订阅者”。但 /home/ubuntu/odoo-temp/enterprise/social_push_notifications 处理的是更复杂的运营现实：不是所有访客都该收到、也不是所有网站都能发、同一条消息还可能要按访客时区分批送达。

参考入口：

• enterprise/social_push_notifications/models/social_post.py
• enterprise/social_push_notifications/models/social_live_post.py
• enterprise/social_push_notifications/models/website_visitor_push_subscription.py
• enterprise/social_push_notifications/controllers/main.py
• enterprise/social_push_notifications/tests/test_social_push_notifications.py

一、为什么 push post 先变 ready，而不是立刻 posted

SocialLivePost._post() 对 push notifications 做了特别处理：不像普通社媒那样直接发，而是先写成 state = ready，后面再由 cron 收集并发布。

原因很现实：push 的目标对象可能按访客时区拆批，也可能受网站配置影响，所以“创建投放动作”和“真正发送”不能完全重叠。

二、受众不是订阅表全量，而是 visitor_domain 再叠网站开关

_post_push_notifications() 先从 post.visitor_domain 解析 Domain，再根据 account 绑定的网站检查 firebase_enable_push_notifications。如果网站没开 push，live post 直接标记 posted 并跳过发送。

这说明企业版默认把 push 看成网站级能力，不是 social 模块全局开关。你有 social 账号，不代表你就能给该网站的所有访客发通知。

三、为什么 use_visitor_timezone 会让同一条消息分批发送

如果启用了 use_visitor_timezone 且设置了 scheduled_date，系统会把计划时间换算成创建者时区的本地时间，再逐个比较访客所在时区的当前本地时间，只向“已经到了那个时间点”的访客发送。

这意味着一条消息不是在某个 UTC 秒点上广播完毕，而是会随着时区窗口渐次推进。为了避免重复发，系统还会记录 reached_visitor_ids。

四、target URL 不直接裸发，而是先包一层 UTM tracker

若设置 push_notification_target_url，系统会用 _get_utm_values() 构造 link.tracker，最终发的是短链。也就是说，push 不是单纯消息派发，还内建了归因链路，方便回看点击效果。

五、为什么 token 清理这么保守

源码里专门留了注释：即便 Firebase 返回 registration-token-not-registered，也不建议立刻删除 token，因为这个错误码并不总是可靠地代表 token 真失效。官方宁可暂时保守，也不想误删订阅。

这点很值得学：运营系统里“清理坏数据”听起来正确，但误删有效订阅的代价可能更大。

六、结论

social_push_notifications 不是“给访客群发一下”那么简单。它真正做的是把网站权限、访客筛选、时区分批、点击归因和 token 风险一起收进同一条推送链路。