先说结论
Odoo 的网站公司识别能力，并不是“拿到访问 IP 就立即建一条 CRM 线索”。
website_crm_iap_reveal 做的事情更谨慎，也更像企业级系统：
- 只在公开访客访问成功页面时介入；
- 如果这个访客已经通过别的入口形成线索，就不重复做 reveal；
- 先生成待处理的
crm.reveal.view，而不是立即落 CRM； - 按规则分批调用外部识别服务；
- 信用不足、查无结果、已存在线索，都有不同处理路径；
- 真正创建线索时，还会补齐公司和联系人富化信息。
所以它的核心不是“神奇识别访客”，而是：
如何把匿名网站访问，尽量稳妥地转成可运营的 B2B 销售信号。
一、为什么页面访问成功后，Odoo 也不会立刻建线索
在 website_crm_iap_reveal/models/ir_http.py 里，这套逻辑挂在 _serve_page() 后面。
也就是说，前提是：
- 页面先成功返回；
- 状态码是 200；
- 当前用户还是 public user。
这一步很重要。
它说明 reveal 不是一个抢在页面前面的拦截器，而是一个 页面访问后的后台观察动作。
这样设计有两个好处：
- 不影响前台页面打开；
- 就算识别过程出错，也不会把网站访问搞挂。
源码里甚至直接把异常吞掉并记录日志，明确表达了一种优先级：
页面可用性高于访客识别。
这是非常成熟的取舍。
二、为什么已有线索的访客不会重复进入 reveal 链路
同一个文件里有个细节很关键：
如果当前 website.visitor 已经关联了 lead_ids，就不再创建 reveal view。
源码注释写得很直白：
这是为了避免像 website_form 这类模块已经创建了 lead 的情况下，再重复走识别逻辑。
也就是说，Odoo 很清楚官网线索入口不只有一个：
- 联系我们表单；
- 试用申请；
- 预约演示；
- 聊天；
- 现在再加上公司识别。
如果这些入口互相不让步，CRM 很快就会被重复线索淹没。
所以 reveal 的设计姿态很克制：
已经有更强的显式线索信号时，就不要再拿隐式识别结果添乱。
三、为什么先创建 crm.reveal.view，而不是直接打外部接口建 lead
Odoo 并没有在每次页面访问时直接调用外部识别服务。
它先做的是：
- 根据 website、URL、IP、国家、省州和排除规则，尝试创建
crm.reveal.view； - 这个 view 只是待处理记录，状态默认为
to_process； - 还带唯一索引
(reveal_rule_id, reveal_ip)，防止同一规则下同一 IP 重复堆积。
这套缓冲层很关键。
它把“访问事件”变成了“待处理业务对象”，于是系统就获得了几种能力：
- 可以批量处理，不必每次实时查外部服务；
- 可以去重，避免重复消耗额度；
- 可以保留失败和未命中的状态；
- 可以把规则优先级和后续线索创建解耦。
这是一种非常典型的企业系统写法：
先落中间态，再做昂贵处理。
四、为什么 reveal 规则比“识别公司”本身更重要
crm_reveal_rule.py 真正复杂的部分，不在 HTTP 入口，而在规则准备和 IAP payload 组装。
Odoo 会按规则整理出：
- 目标国家；
- 公司规模区间；
- 行业标签；
- 识别对象是 company 还是 people；
- 偏好角色、其他角色、seniority；
- 额外联系人数量。
这说明 reveal 从来不是“把访客公司名猜出来”这么简单。
它真正想做的是：
把网站访问先筛成“我们想要哪类潜在客户”，再决定值不值得消耗识别额度。
这很像广告投放里的 audience 策略，而不是单纯访客日志分析。
五、为什么批量处理和 credit 控制是这条链路的现实核心
源码里 _get_reveal_views_to_process() 会按 batch 取待处理 IP，再把规则整理成 payload，交给 IAP 服务。
之后 _perform_reveal_service() 会处理几种情况：
- 命中结果：创建 lead，并删除对应 reveal view；
- 未找到：把 reveal view 标记为
not_found； - credit 不足：发通知，不继续硬跑；
- IAP 返回异常结果：把没处理完的 IP 一并标为
not_found，避免死循环。
这套逻辑很现实。
因为“网站识别访客”如果不考虑外部服务成本，很容易变成一个持续烧钱又难解释 ROI 的黑洞。
Odoo 在这里的态度很明确：
- 要批量；
- 要限流；
- 要去重；
- 要有额度告警；
- 要避免坏结果无限重试。
这说明它不是把 reveal 当炫技功能，而是真把它当销售运营成本来管理。
六、为什么线索创建前还要按 clearbit_id 再做一层去重
即使外部服务识别到了公司，Odoo 也不会立刻安心创建 lead。
它还会检查：
clearbit_id是否存在；- CRM 里是否已有同一个
reveal_id的线索。
如果已有，就直接放弃重复创建。
这一步特别关键。
因为企业官网的回访、多人访问、跨页面浏览，本来就很容易把同一家公司反复识别出来。
如果没有这层去重，你得到的就不是“销售线索”，而是“销售噪音”。
Odoo 很清楚 CRM 最怕的是重复对象，而不是线索太少。
七、为什么这套机制最终价值在“富化”，不是“抓包”
真正创建 lead 时，Odoo 会把外部返回的公司和联系人信息交给 crm.iap.lead.helpers 生成标准 lead 值，补上：
- 团队；
- 标签；
- 负责人；
- 公司/联系人信息；
reveal_ip、reveal_rule_id、reveal_iap_credits；referred = Website Visitor。
还会追加一条内部 note，说明这是 Odoo Lead Generation 创建的机会。
这说明 reveal 不是为了“证明我们知道谁来过”，而是为了：
把一条原本没法运营的匿名访问，尽量变成 CRM 可分配、可跟进、可解释的对象。
这才是它的商业意义。
八、实战里最容易误解的地方
1. Reveal 不是实时弹 CRM 奇迹按钮
它是带中间态、带批处理、带额度约束的一条后台链路。
2. 有访问不代表就该建 lead
规则匹配、已存 lead 去重、未命中、额度不足，都会改变结果。
3. 隐式识别不该压过显式表单线索
已有表单 lead 时不再重复 reveal，这个设计非常值得保留。
九、给官网转线索团队的建议
如果你打算用 Odoo 做官网 B2B 识别，最好先想清楚三件事：
- 你想要哪类公司，而不是“识别到越多越好”；
- 你的销售团队是否吃得下这批 enriched leads；
- 你是否有足够严格的去重和评分策略。
否则 reveal 很容易从“线索富化”变成“CRM 污染源”。
最后的结论
website_crm_iap_reveal 真正串起来的是：
- 页面访问观察，
- 访客与规则去重，
- 批量外部识别，
- 额度控制，
- 结果筛选，
- 线索富化创建。
所以 Odoo 的网站公司识别绝不是“看到 IP 就建线索”。
它更像一套克制的 B2B 官网信号处理链路：
先判断值不值得认，再决定值不值得建。
DISCUSSION
评论区