交付后的三个盲区

一套系统卖出去、部署完，厂商通常会失去三类信息：

1. 谁真的上线了：签了合同但没部署、部署了但没用起来，这两种情况在商业上差别巨大；
2. 跑的是哪个版本：客户报 bug 时，第一个问题永远是"你是什么版本"；
3. 哪些模块在用：买了 12 个模块，实际只用了 3 个——这直接影响下一轮的销售与服务策略。

纯靠客服回访，信息既不及时也不准确。

beacon 与心跳的区别

两者都由客户侧定时上报，但定位不同：

分两张表、两套任务，好处是：授权链路不因为统计逻辑出问题而中断，反之亦然。

上报什么，不报什么

这是最容易引起客户反感的部分。我们的原则是三条：

上报用规模区间，不上报明细。 例如"订单量级 1k~10k"，而不是具体订单号、客户姓名、手机号。

上报功能启用状态，不上报内容。 "评论模块已启用"，而不是评论内容。

上报错误摘要，不上报请求体。 便于定位共性问题，不涉及业务数据。

这套边界要写进交付文档，客户运维有权知道系统往外发了什么。

落地形态：一张登记表 + 一个详情弹窗

厂商后台的「上线登记」页提供：

• 实例列表：客户、域名、版本、最近上报时间、规模区间；
• 详情：版本历史、模块启用变化、最近错误摘要；
• 状态标记：正常 / 长期未上报（可能是停机、也可能是网络隔离）。

"长期未上报"这个状态很有用：它把"客户不理你"和"系统挂了"区分开——前者靠销售跟进，后者靠技术支持。

网络隔离环境怎么办

很多客户的服务器不出网。这种情况下 beacon 不能成为部署阻塞项，处理方式是：

• 上报失败只记本地日志，不重试到阻塞业务；
• 提供手动导出：后台生成一份登记信息文件，客户通过邮件/工单发回；
• 授权链路同样要支持"离线模式"，不能因为无法联网就完全不可用。

这套降级设计是私有化交付的底线：任何依赖外部网络的机制，都必须有可用的本地兜底。

为什么值得做

beacon 的价值不在技术复杂度（它可能只是一个每天跑一次的 POST 请求），而在于它把"客户使用情况"从销售记忆变成可查数据：

• 发版通知能精准到版本；
• 客户成功团队知道谁需要跟进；
• 产品决策能回答"哪个模块真的有人用"。

对一套标准化 SaaS/私有化产品来说，这类基础观测能力的缺失，往往比功能缺失更致命——因为你不知道自己做得对不对。