Odoo 企业版 Marketing Automation + WhatsApp 为什么不是“流程里多一个消息节点”而已：trigger 取消、trace 继承与点击统计讲透

把 WhatsApp 接进营销自动化，表面上像是“多一种触达渠道”。但 /home/ubuntu/odoo-temp/enterprise/marketing_automation_whatsapp 里真正有价值的，是它把即时通讯事件翻译成了营销编排能理解的 trace 语义。

参考入口：

• enterprise/marketing_automation_whatsapp/models/marketing_activity.py
• enterprise/marketing_automation_whatsapp/models/marketing_trace.py
• enterprise/marketing_automation_whatsapp/models/whatsapp_message.py
• enterprise/marketing_automation_whatsapp/tests/test_marketing_processing.py
• enterprise/marketing_automation_whatsapp/tests/test_marketing_statistics.py

一、WhatsApp 不是独立统计孤岛，而是 trace 的一部分

marketing.trace 扩展了 whatsapp_message_id，并在 _compute_links_click_datetime() 里把点击时间直接复用到 trace 上。这样做的意义是：营销自动化看的是“参与者在活动节点上的状态变化”，而不是某个渠道自己单独记一套结果。

二、process_event() 的重点不是记日志，而是取消失效分支

当父消息发生：

• whatsapp_read
• whatsapp_replied
• whatsapp_click
• whatsapp_bounced

系统会去找仍是 scheduled 的子 trace，并取消那些已经不成立的触发条件，例如 whatsapp_not_read、whatsapp_not_replied、whatsapp_not_click。

这一步特别关键，因为自动化流程不是事件时间线堆积，而是一个有条件分叉的图。父节点一旦发生真实事件，和它互斥的“未读/未回/未点”支线就必须主动关闭。

三、为什么 bounce 的处理最严格

对 whatsapp_bounced，系统会取消所有 trigger type 不等于 bounced 的已排程子节点。原因很简单：一旦主消息都没成功送达，后续基于阅读、回复、点击的推断都失去意义。

这也是营销自动化常见误区：把送达失败只当报表问题，而不是流程问题。Odoo 在这里明确把它当成流程分支终止条件。

四、统计聚合说明渠道数据最终仍要回到 campaign 维度

测试 test_statistics_aggregation 验证的，不是某一条消息详情页，而是活动统计如何汇总到 campaign/participant 维度。也就是说，WhatsApp 再即时，它最终仍要被纳入统一营销看板，而不是变成旁路聊天工具。

五、实战建议

• 设计自动化时，要把“未读/未回/未点”理解成可被父事件取消的临时分支，不是永恒条件。
• 如果统计看起来不对，先追 trace 与 whatsapp_message 的映射，再看 message 本身状态。
• bounce 应作为强中断信号处理，而不是简单拉低送达率。

六、结论

marketing_automation_whatsapp 的难点，不在于发出一条 WhatsApp，而在于把读取、回复、点击、退信这些即时事件翻译回营销自动化的条件图里。只有这样，流程编排才不会在真实用户行为发生后继续走错分支。