TOGAF 营销系统实践：从活动烟囱到可度量的增长能力

一家拥有 1200 家门店、商城、App 和小程序的零售企业，在年度会员节结束后拿到了一组看似漂亮的数字：活动页面访问量增长 86%，领券人数增长 63%，活动期间成交额同比增长 27%。营销负责人准备把这套打法复制到更多区域，财务团队却给出了完全不同的结论。

活动商品毛利额只增长了 3.8%，部分品类扣除券成本、渠道费用和履约补贴后已经亏损；优惠券平台显示发放 420 万张，短信平台记录了 510 万次领券链接点击，订单系统却关联出 468 万张券；同一客户在 App、短信和企业微信分别收到相似活动，投诉与退订明显增加；三个分析团队对“营销带来的收入”给出了 1800 万、3100 万和 4700 万三个答案。

技术团队最初把问题归结为营销系统老旧，计划建设统一活动中心、规则引擎和实时数据平台。但这仍然先给出了解法，没有回答真正的架构问题：企业如何定义增长，谁有权承诺一笔优惠，客户是否可以被触达，活动对订单的贡献如何被证明，多个系统如何从各算各的逐步迁移到共同事实，以及营销结果如何反过来改变下一轮投资。

营销系统的复杂性不主要来自页面数量或规则数量，而来自它同时跨越客户、商品、价格、权益、渠道、交易、财务和分析多个责任域。局部系统都可能运行正常，组合结果却仍然失控。TOGAF 在这里提供的不是一套活动模板，而是一条从业务驱动到运行证据的可追踪决策链。

横向滚动查看完整流程 · 点击打开高清原图

读图：先从业务结果向下追到能力、事实责任和运行证据，再沿反馈线回到下一轮策略；任一层断裂，增长结论都无法被证明。

本文用一条营销业务线完整推演架构决策。需要回查单项方法时，可以进入对应专题：

案例中的决策	方法专题
增长、财务、法务和技术如何形成共同关注点	干系人与架构原则
结果树、价值流和能力热力如何改变投资顺序	业务架构
身份、Consent、人群、权益和转化由谁裁决	数据架构
活动、决策、账本、渠道和测量怎样划分责任	应用架构
业务损失怎样转成一致性、容量、降级和观测	技术架构
现状与目标怎样形成可交付的营销 Gap	Baseline、Target 与 Gap
新旧系统如何影子运行、灰度接管和退出	过渡架构与迁移规划
规则、例外、ADR 和运行证据如何进入治理	架构治理

案例边界与工程尺度

本文继续使用 TOGAF 深度实践中的同一家虚构零售企业，但把观察中心从订单与库存转向营销。企业的营销触点包括门店收银、导购企业微信、商城、App、小程序、短信、Push 和外部广告渠道。本轮架构工作不处理实时竞价、广告拍卖与素材生成算法，外部广告只作为触点和转化来源进入统一测量链路。

当前规模和约束如下：

项目	当前规模或约束	对架构的影响
客户身份	1800 万个注册身份，存在手机号、会员号、设备和渠道账号重复	不能把一个渠道账号直接当成企业客户
活跃客户	月活约 600 万	人群快照、频控和在线决策必须具备明确时效
活动数量	日常约 300 个并行活动，大促时更多	规则冲突和优先级不能靠运营人员手工排查
行为事件	峰值约 8 万条/秒	采集、清洗、去重和迟到处理需要独立容量模型
在线决策	峰值约 1.2 万次/秒	决策链不能同步依赖完整分析仓库
权益	优惠券、积分、赠品、免邮、会员价和渠道补贴并存	不同权益具有不同稀缺性和一致性要求
遗留应用	CRM、会员、CDP、券平台、促销引擎和多个渠道工具均在运行	无法一次替换，必须设计过渡责任和退出路径
合规要求	客户授权目的、渠道、有效期和撤回需要可追踪	“有手机号”不等于“可以营销触达”

这些数字是用于推演的工程参数。重点不在于数值本身，而在于每个目标架构结论都必须能回到业务损失、流量假设、数据时效和组织约束。没有规模和失败后果的“高性能营销平台”，无法形成可验证的技术架构。

事故为什么不是单个系统故障

活动复盘发现了六条彼此关联的断点。

第一，CRM 按最近一次消费日期圈选“沉睡客户”，CDP 按最近 90 天无浏览行为圈选，短信供应商又按本地导入名单发送。同一个“召回人群”实际上存在三种定义，名单之间无法逐条解释。

第二，会员平台保存等级，促销引擎复制一份等级快照，活动系统为了临时规则又维护“活动会员等级”。客户升级后，三个系统在数小时内给出不同优惠资格。

第三，券平台只控制券模板总量，活动平台还配置了活动预算，财务系统按最终核销金额确认费用。发券成功、预算占用和订单核销之间没有共同业务凭证，任何一个数字都无法独立解释资金承诺。

第四，渠道只记录“消息已发送”和“页面已打开”，没有统一曝光定义。短信点击、小程序打开和 App 卡片展示被同时计为三次触达，频控只能在各渠道内部生效。

第五，订单系统知道订单、商品、实付和退款，却不知道客户当时看到哪个 Offer、为什么获得资格、权益是否来自本次活动。分析平台只能用时间和客户 ID 事后拼接，得到的是统计相关，不是可靠因果证据。

第六，各团队分别优化自己的指标：渠道追求发送成功率，活动平台追求领券率，券平台追求发放吞吐，电商团队追求成交额，财务关心毛利和费用。没有人对“增量毛利是否覆盖营销成本且没有透支客户关系”这一端到端结果负责。

因此，建设一个新的活动中心不会自动解决问题。它可能只是把散落的活动配置集中起来，继续读取不一致的客户事实、调用没有共同凭证的权益接口，并把更多无法解释的结果送进数据仓库。

把“建设营销中台”还原成架构问题

“营销中台”是候选解法，不是业务驱动。Phase A 首先应把方案语言还原为驱动、结果、约束和验证方式。

编号	类型	架构要求	验证证据
DRV-MKT-01	增长驱动	提升可证明的增量毛利，而不是只提升活动期成交额	实验增量、毛利和营销成本
DRV-MKT-02	客户驱动	跨渠道触达可协调，避免重复打扰和授权越界	频控命中、退订、投诉和 Consent 审计
DRV-MKT-03	运营驱动	新活动复用客户、人群、权益和测量能力	活动准备周期、人工导数次数、规则复用率
DRV-MKT-04	治理驱动	每笔优惠承诺能够回到活动、预算和责任人	权益账本、预算占用和订单核销对账
CON-MKT-01	迁移约束	主要渠道和遗留促销引擎不能在一个版本内替换	过渡架构、灰度范围和退出证据
CON-MKT-02	时效约束	在线决策不能等待 T+1 标签和离线仓库	数据新鲜度、决策延迟和降级策略
CON-MKT-03	合规约束	触达和画像使用必须符合客户授权目的	授权版本、用途、渠道和撤回传播时间

架构愿景可以据此表述为：在不停止现有渠道运营的条件下，建立可解释的人群、可裁决的 Offer、可核对的权益和可验证的测量闭环，使活动投入能够追踪到增量业务结果，并让遗留规则和写入口按阶段退出。

这个表述没有预设必须购买 CDP、引入某种规则引擎或把所有模块拆成微服务。它先固定企业希望具备的状态，再允许数据、应用和技术方案围绕约束作取舍。

干系人的关注点决定架构视角

营销项目常被运营和技术团队主导，但真实决策权分布在更多角色中。

干系人	主要关注点	有权决定什么	不能独自决定什么
增长负责人	增量收入、客户活跃和活动节奏	增长目标与活动组合	牺牲毛利或突破合规边界
品类与商品运营	毛利、价格形象和库存周转	商品范围与品类补贴策略	修改企业客户或权益事实
会员运营	等级、生命周期和客户关系	会员策略与客户价值分层	绕过 Consent 进行渠道触达
财务	预算、费用确认和利润	预算授权与核销口径	决定客户是否满足活动资格
法务与安全	授权用途、最小化和审计	数据使用和触达红线	决定营销优先级和 Offer 排序
渠道团队	展示、发送和渠道体验	渠道适配与投递策略	各自定义企业级曝光和频控
交易团队	价格快照、订单和退款事实	交易状态与金额裁决	把分析归因结果写回订单事实
营销平台团队	活动、决策、权益协作和运行质量	平台契约与技术实现	代替业务 Owner 决定增长结果

这张矩阵会直接改变架构视图。财务需要看预算承诺到费用核销，法务需要看 Consent 到触达，运营需要看策略到客户响应，后端团队需要看同步决策、状态机和故障语义。试图用一张系统拓扑图同时回答所有问题，结果通常是谁都看到了组件，却没人能完成决策。

结果树必须同时包含增长和护栏

只写“提升转化率”会诱导系统无限增加优惠和触达。业务架构需要把目标拆成结果树，并明确优化目标不能突破的护栏。

业务结果：提高可持续的客户增量毛利
  ├─ O1 提升目标客户的增量购买
  │    ├─ 客户识别与生命周期判断
  │    ├─ 人群定义与快照
  │    └─ 实验与增量测量
  ├─ O2 在利润约束内生成合适 Offer
  │    ├─ 活动与规则管理
  │    ├─ 实时决策与冲突裁决
  │    └─ 权益与预算承诺
  ├─ O3 跨渠道协调客户接触
  │    ├─ Consent 与偏好管理
  │    ├─ 企业级频控
  │    └─ 渠道编排与投递反馈
  └─ O4 让运行结果进入下一轮决策
       ├─ 曝光与转化事实
       ├─ 归因、实验和成本核算
       └─ 策略复盘与架构变更

护栏：毛利率、预算上限、退订率、投诉率、频控、敏感人群保护、价格一致性

指标之间必须建立关系。成交额增长不等于增量收入，增量收入也不等于增量毛利。可以用下面的简化表达检查活动是否真正创造价值：

活动增量毛利
= 实验组毛利 - 对照组基准毛利
- 优惠与赠品成本
- 渠道发送和广告成本
- 额外履约与客服成本
- 退款和撤销回冲

真实计算会处理客户结构、实验偏差和时间窗口，但这个表达已经说明：活动页面 PV、领券率和活动期 GMV 都只是过程信号，不能独立成为企业收益证据。

从价值流识别能力断点

营销价值不是“创建活动后发送消息”，而是从策略假设到证据学习的完整流动。

横向滚动查看完整流程 · 点击打开高清原图

读图：横向是营销价值产生的顺序，纵向是每一步必须留下的事实和支撑能力；红色断点说明上游缺失会怎样污染后续决策。

价值阶段	需要回答的问题	关键能力	当前断点
制定策略	要改变谁的什么行为，为什么值得投资	目标管理、预算组合、客户洞察	先有渠道排期，后补业务假设
识别人群	此刻哪些客户满足定义，证据是什么	身份解析、标签、人群、Consent	同名人群定义不同，快照无法重现
生成决策	当前场景应提供哪个 Offer	活动编排、资格、冲突裁决、频控	多套规则分别返回“最高优先级”
承诺权益	企业是否真的承诺这笔优惠	权益账本、预算、库存类权益	发券成功与预算占用没有共同凭证
渠道触达	内容是否送达并被客户真实看到	渠道协调、投递、曝光	发送、到达、展示和点击混为一谈
观察转化	客户之后发生了什么业务事实	订单、支付、退款、成本事件	只按客户和时间事后拼接
归因学习	结果是否由策略带来，下一轮改什么	实验、归因、增量分析、复盘	三套口径同时宣称营销收入

价值流暴露的关键问题是：任意一个阶段缺少责任或证据，后续阶段都只能用猜测补齐。人群不可重现，决策就无法复盘；权益没有账本，财务就无法解释成本；曝光不可信，归因模型再复杂也没有可靠输入。

能力热力分析改变投资顺序

企业已有很多营销功能，但“有系统”不等于“能力成熟”。可以从结果、流程、数据、应用和组织五个维度判断能力是否稳定。

能力	当前表现	业务重要性	变化强度	目标成熟度	投资判断
客户身份解析	渠道账号和会员号重复	高	高	可度量	首批基础能力
Consent 与偏好	各渠道保存局部退订	高	高	可度量	合规前置能力
标签与人群	定义、计算和导出分散	高	高	可度量	先统一语义与快照
活动组合管理	以渠道任务为中心	高	中高	已定义	与预算和结果树对齐
实时 Offer 决策	规则分散且无冲突裁决	高	高	可度量	核心变化能力
权益与预算	券、积分、赠品分别管理	高	高	可度量	建立共同凭证和账本
渠道协调	渠道内部发送与频控	中高	中	可度量	在决策能力后接入
实验与增量测量	事后归因替代实验	高	高	可优化	与活动设计同步建设
内容与素材	已有成熟工具	中	低	可重复	本轮保持接口复用

如果先建设实时规则引擎，却没有客户身份、Consent、人群快照和权益账本，它只会更快地产生不可解释的决策。合理顺序通常是先建立事实、责任和证据，再让在线决策逐步接管流量。

统一语言避免把不同对象塞进“活动”

营销系统最常见的模型问题，是所有内容都叫活动。活动表逐渐包含人群 SQL、渠道、文案、优惠券、预算、定时任务、实验组和报表字段，最后没有任何团队敢修改其生命周期。

概念	精确定义	不应混淆为
Campaign	为一个业务假设组织目标、时间、预算和策略的管理对象	一次短信发送任务
Journey	客户在事件和条件驱动下经过的多阶段互动路径	Campaign 的状态字段集合
Segment Definition	可版本化的人群条件定义	某次计算出的客户名单
Audience Snapshot	在指定 asOf 时间按某版本定义得到的成员集合	永远实时变化的“人群表”
Offer	企业准备向特定客户和场景提出的价值主张	只有优惠金额的券模板
Promotion	对商品、价格或订单金额的计算规则	已经属于客户的权益资产
Coupon	可被领取、发放、占用、核销和返还的凭证	活动预算本身
Benefit	企业向客户承诺的优惠、积分、赠品或服务权益	仅限优惠券
Exposure	Offer 在满足可见条件后真实展示给客户的事实	消息提交给供应商
Conversion	由交易域确认的购买、支付、注册等业务结果	营销平台自行推断的成功标记
Attribution	按明确模型把转化贡献分配给接触点的分析结果	对订单事实的修改

这些对象的生命周期不同。Segment Definition 可以持续演进，Audience Snapshot 必须冻结版本和计算时间；Promotion 在订单定价时参与计算，Coupon 则需要独立防止重复使用；Exposure 是已发生事实，Attribution 是可重算的分析结果。把它们拆开后，接口、数据库和团队责任才有清晰位置。

数据架构先规定谁有权裁决事实

CDP 经常被描述成“统一客户数据中心”，但统一视图不等于统一写入权。客户姓名来自会员资料，支付结果来自支付域，订单金额来自订单域，退订来自 Consent 或渠道反馈。CDP 可以组合这些事实形成画像，却不能因为保存了副本就成为所有对象的最终裁决者。

横向滚动查看完整流程 · 点击打开高清原图

读图：上层系统裁决业务事实，中层应用围绕事实完成决策，底层平台只消费并解释；读取关系不等于拥有反向修改权。

核心对象	业务 Owner	权威修改方	可建立的副本	关键规则
企业客户身份	会员运营	身份与会员平台	CDP、渠道客户视图	合并、拆分和来源映射可审计
Consent 与偏好	法务和会员运营	Consent 服务	决策缓存、渠道只读副本	用途、渠道、有效期和撤回均参与判断
客户行为事件	数字运营	事件采集平台保留原始事实	实时特征、分析仓库	事件时间、接收时间和来源不能丢失
标签定义	客户洞察团队	标签与人群平台	决策特征缓存	定义、Owner、版本、时效和血缘完整
人群定义与快照	增长运营	标签与人群平台	渠道投递名单	定义版本和 asOf 决定可重现性
Campaign 与策略	增长负责人	活动中心	渠道执行视图	目标、预算、实验和有效期共同版本化
Offer 决策	营销决策 Owner	实时决策服务	决策日志	输入快照、规则版本和拒绝原因可追踪
权益与预算承诺	财务与营销运营	权益/预算账本	客户权益视图、财务读模型	占用、发放、核销、释放守恒
订单与支付	交易与财务	订单、支付域	营销转化视图	营销系统不能改写交易状态和金额
曝光与转化关联	增长分析	测量平台	报表和模型特征	原始事实与模型结果分层保存
归因结果	增长分析	实验与归因平台	经营报表	模型、窗口和计算批次可重算

一个权威方不等于一个数据库。权益账本可以分片，行为事件可以按来源写入多个日志，只要同一责任范围内的最终裁决规则明确。真正危险的是活动平台、券平台和渠道都认为自己可以最终确认“客户已经获得权益”。

时间语义决定画像是否可信

营销判断至少涉及三种时间：

• occurredAt：业务行为真实发生的时间。
• receivedAt：平台接收到事件的时间。
• computedAt：标签、人群或归因结果计算完成的时间。

客户在 10:00 完成购买，事件因网络问题在 10:08 到达，沉睡标签在 10:05 被计算。如果系统只保存处理时间，就无法判断 10:06 的召回决策使用了什么事实。决策日志需要记录使用的特征版本和 asOf，归因计算则要允许迟到事件在窗口内触发重算。

人群也必须区分动态定义和活动快照。运营人员在周一发布“最近 30 天未购买”的人群，周三查看同一页面时成员已经变化。如果活动审批、预算估算和实验分组基于周一名单，就必须保存 Segment Definition 版本、数据截止时间、快照 ID 和成员数量，而不是重新执行一段 SQL 假装得到原结果。

身份解析不能依赖一个万能 customer_id

同一自然人可能拥有会员号、手机号、设备 ID、微信 OpenID、外部广告 ID 和多个历史账号。身份平台需要记录“哪些标识在什么时间、基于什么证据被关联”，还要支持错误合并后的拆分。

身份合并规则必须分级：实名认证或客户主动绑定可以作为强证据；同一设备、同一地址或相似行为只能作为弱关联，不应直接合并权益账户。营销分析可以在声明置信度的情况下使用弱关联，权益发放和 Consent 判断则必须使用满足业务风险要求的强身份。

因此，决策请求中的 customerId 不是全知对象。它只是企业身份解析后的稳定引用，调用方仍需提供触点、渠道身份和场景；决策服务再依据用途选择可以使用的客户特征。

Consent 是决策输入而不是发送前过滤器

如果渠道在真正发送前才检查退订，活动平台仍然会把被禁止触达的客户计入人群、预算和实验组，造成统计污染。Consent 应在生成决策和形成渠道任务时共同生效。

一条可执行的授权记录至少包含：

字段	含义
subjectId	被授权主体，必须关联可解释的身份证据
purpose	数据使用目的，例如个性化推荐或营销触达
channel	短信、Push、企业微信等适用渠道
status	已授权、已拒绝、已撤回或已过期
capturedAt	授权形成时间
effectiveFrom / To	生效区间
source	授权页面、门店表单或渠道回执
policyVersion	客户同意的政策版本

撤回需要定义传播 SLA。例如客户在 App 撤回短信营销授权后，5 分钟内所有新决策不得再产生短信任务，已生成但未发送的任务也要被取消。仅更新主库而不处理队列和渠道缓存，不算完成撤回。

从能力和事实推导应用边界

应用边界不应按采购产品名称划分。一个商业 CDP 可能同时提供事件采集、标签、人群和旅程功能，但企业仍需明确每项责任及其事实边界。

应用能力	负责内容	明确不负责
身份与会员平台	企业客户身份、账号、等级和会员生命周期	营销归因和渠道发送
Consent 服务	授权、偏好、撤回和用途判断	决定活动优先级
事件采集平台	原始行为接收、标准化、去重和质量标记	把点击推断成订单成功
客户画像/CDP	汇聚可授权使用的客户视图和特征	成为订单、支付、会员的最终写入方
标签与人群平台	标签定义、计算、版本、快照和成员解释	发券和修改客户权益
活动中心	Campaign、目标、预算、策略、实验和生命周期	直接修改交易价格或客户账户
实时决策服务	资格、优先级、互斥、频控和 Offer 选择	保存完整客户档案和最终交易事实
促销定价平台	商品、订单和会员价规则计算	管理已发放到客户的券资产
权益与预算账本	预算占用、券和权益的承诺、核销、释放与对账	判断客户属于哪个营销人群
渠道网关	渠道适配、发送、撤销、回执和供应商切换	各自定义企业级曝光和归因口径
实验与归因平台	分组、曝光关联、转化观察、模型计算和重算	修改订单、支付或权益状态

这些边界不要求每项能力立即成为独立微服务。早期可以在模块化单体中实现活动、决策和权益编排，但数据库表、写权限、事件和代码模块必须体现责任分离。当权益账本需要独立一致性、容量和审计时，再把它拆成部署单元，比先按名词拆十几个服务更稳妥。

实时决策是一条带业务承诺的链路

营销决策不是“从候选列表随机返回一条广告”。当结果包含专属价格、优惠券或赠品时，系统实际上正在代表企业作出有限期承诺。决策链需要同时处理客户授权、数据新鲜度、活动状态、人群资格、商品范围、渠道能力、互斥优先级、频控、预算和权益可用性。

横向滚动查看完整流程 · 点击打开高清原图

读图：黑色实线是 100ms 内的同步承诺链，红色和橙色分别表示拒绝与降级，青色虚线表示渠道展示后的异步曝光事实。

一次 App 商品详情页决策可以按下面的责任顺序执行：

1. 渠道提交客户、场景、商品、触点和请求幂等标识。
2. 决策入口完成身份解析，校验此用途和渠道的 Consent。
3. 特征服务返回带版本与新鲜度的客户、商品和上下文特征。
4. 活动索引根据场景、时间和渠道召回候选 Campaign。
5. 资格与人群规则剔除不满足条件的候选。
6. 冲突裁决按互斥组、客户频控、利润护栏和优先级选择 Offer。
7. 如果 Offer 包含稀缺权益，向权益账本请求有限期预留。
8. 决策服务保存输入摘要、规则版本、选择与拒绝原因，返回渠道。
9. 渠道真正展示后上报 Exposure；没有展示不能记为曝光。
10. 订单、支付和退款事实进入测量链路，实验与归因平台在明确窗口内计算结果。

顺序不是实现细节。先选 Offer 再检查 Consent，会泄露不应使用的客户特征；先返回渠道再预留限量券，会出现客户看到优惠却无法领取；把曝光记录放在决策返回时，会把网络失败和页面未渲染都计算成触达。

决策接口必须返回理由和版本

接口只返回 offerId 无法支持客服解释、故障排查和策略复盘。一个简化请求可以是：

POST /marketing-decisions
{
  "requestId": "req-01J2MKT8N7D3",
  "customerId": "cus-18002341",
  "channelIdentity": {
    "type": "mini_program_open_id",
    "value": "oid-7f12..."
  },
  "scenario": "product_detail",
  "touchpoint": "mini_program",
  "occurredAt": "2026-08-18T20:01:12+08:00",
  "context": {
    "skuId": "sku-1024",
    "storeId": "store-0312",
    "region": "south"
  },
  "consentContext": {
    "purpose": "personalized_marketing",
    "policyVersion": "2026-06"
  }
}

响应要区分“没有候选”“被规则拒绝”和“系统降级”，并记录可追踪版本：

{
  "decisionId": "dec-01J2MKT9F4PK",
  "requestId": "req-01J2MKT8N7D3",
  "result": "OFFER_SELECTED",
  "campaignId": "cmp-member-day-202608",
  "offerId": "off-sku1024-20",
  "policyVersion": "policy-184",
  "audienceSnapshotId": "aud-20260818-1930-v7",
  "featureViewAsOf": "2026-08-18T20:00:30+08:00",
  "benefitReservationId": "res-908172",
  "expiresAt": "2026-08-18T20:16:12+08:00",
  "reasonCodes": ["LOYAL_CUSTOMER", "MARGIN_GUARD_PASSED"],
  "traceId": "trc-44d20..."
}

对于未选择 Offer 的请求，reasonCodes 可能是 CONSENT_DENIED、FREQUENCY_LIMITED、NO_ELIGIBLE_CAMPAIGN、BUDGET_EXHAUSTED 或 FEATURE_TOO_STALE。理由码属于业务契约，需要版本化和统计，不能只写进日志字符串。

决策响应还要声明有效期。客户在页面停留 30 分钟后才下单，原优惠可能已过期、预算可能已耗尽。订单不能仅凭前端传来的优惠金额结算，应携带 decisionId 或价格凭证回到定价与权益责任方验证。

规则引擎不负责替企业作价值判断

规则引擎擅长执行条件，但“哪个活动优先”“能否叠加”“利润低于多少需要拒绝”属于业务政策。把这些关系隐藏在规则脚本执行顺序里，会让结果随发布顺序偶然变化。

每个候选 Offer 至少应带有以下决策属性：

属性	用途
objective	对应的业务结果，例如召回、复购或清库存
priority	同一决策域内的显式优先级
exclusiveGroup	互斥组，例如同一商品只能展示一个价格型 Offer
stackPolicy	与会员价、券、积分和渠道补贴的叠加关系
marginFloor	折后毛利或贡献毛利护栏
frequencyPolicy	客户、活动、触点和时间窗口的频控
budgetPolicy	预算账户、单客上限和超额处理
eligibilityVersion	人群与资格规则版本
fallback	权益不足或依赖故障时允许的替代方案

冲突裁决可以采用确定性顺序：先排除违反 Consent 和硬资格的候选，再应用互斥与叠加政策，之后检查利润和预算，最后在剩余候选中按目标优先级和实验分组选择。机器学习排序可以参与最后一步，但不能绕过硬约束。

确定性很重要。同样的输入和版本应得到相同结果，使影子运行、回放测试和客服解释成为可能。涉及随机探索时，随机种子也要由稳定的客户或实验单元产生并记录，而不是每次请求重新随机。

人群资格与在线特征承担不同职责

大规模人群条件适合离线或流式预计算，例如“近 90 天购买两次以上且近 30 天未购买”。请求时再扫描历史事件既昂贵又不稳定。在线决策应读取已经版本化的资格结果和少量实时上下文，例如当前商品、门店、最近一次曝光、实时购物车金额。

但预计算不是无限缓存。每个特征要声明：

• 来源事实和计算逻辑版本。
• asOf 和最大允许陈旧时间。
• 缺失时是拒绝、使用默认值还是进入降级策略。
• 是否包含敏感数据，当前用途是否允许读取。
• 回放历史决策时能否取到当时版本。

例如会员等级允许 5 分钟内缓存，Consent 撤回却要求 5 分钟内全链路生效；“近 30 天消费金额”可以容忍数分钟延迟，限量券剩余量不能依赖相同缓存。技术架构必须由业务损失区分时效，而不是给所有 Redis Key 设置同一个 TTL。

权益与预算需要共同业务凭证

优惠券总量、活动预算和财务费用是三个不同对象。券模板可以剩余，但活动预算可能已经耗尽；预算已占用，客户却可能没有最终领取；券已核销，订单退款后又需要返还或回冲费用。

横向滚动查看完整流程 · 点击打开高清原图

读图：主干描述权益从可用到结算，向下分支处理超时、失败和退款；每次转换都必须同时保持客户权益、预算和限量额度一致。

可以把一次营销承诺拆成以下对象：

• BudgetAccount：某活动或成本中心可使用的营销资金。
• BenefitDefinition：优惠券、积分、赠品或免邮权益的规则定义。
• BenefitReservation：为一次决策暂时占用预算和稀缺额度。
• BenefitGrant：企业已经向客户发放的权益资产。
• Redemption：权益在订单或其他业务中被核销的事实。
• SettlementEntry：用于财务确认、退款回冲和对账的账务记录。

关键不变量可以写成：

预算账户：可用金额 + 已预留金额 + 已确认费用 = 授权预算 + 已回冲金额

限量权益：可发数量 + 已预留数量 + 已发放数量 = 配置总量 + 已返还数量

客户权益：同一 grantId 在任一时刻只能处于一个有效状态

这些公式比“发券接口成功率”更接近业务正确性。系统即使所有接口都返回 200，只要预留长期不释放、重复发放或退款未回冲，企业状态仍然错误。

权益生命周期

一笔 Benefit 可以经历：

不存在
  -> RESERVED      决策已暂时占用额度
  -> GRANTED       权益已属于客户
  -> REDEEMING     交易正在尝试核销
  -> REDEEMED      核销成功并形成费用凭证

RESERVED -> RELEASED   决策过期或渠道未展示
GRANTED  -> EXPIRED    客户未在有效期内使用
REDEEMING -> GRANTED   交易失败，恢复可用
REDEEMED -> RETURNED   退款政策允许返还
REDEEMED -> REVERSED   费用回冲但权益不再可用

状态变化必须由明确命令触发，并保留 decisionId、campaignId、customerId、预算账户、订单和策略版本。直接更新 status 字段而不校验前置状态，会让重复回调、乱序事件和人工补偿破坏不变量。

预留事务与幂等

预留请求需要业务幂等键，例如 decisionId + benefitDefinitionId + customerId。数据库可以用唯一约束阻止同一次决策重复占用：

create unique index uk_benefit_reservation_request
on benefit_reservation(decision_id, benefit_definition_id, customer_id);

在同一事务内，服务先创建或读取已有 Reservation，再以条件更新扣减预算和权益额度，最后写入待发布事件。条件更新失败表示预算或库存不足，不应先返回成功再异步补救。

begin transaction
  assert request idempotency key is unique
  update budget_account
     set available = available - :amount,
         reserved = reserved + :amount
   where account_id = :accountId
     and available >= :amount

  update benefit_quota
     set available = available - 1,
         reserved = reserved + 1
   where definition_id = :definitionId
     and available > 0

  insert benefit_reservation(..., status = 'RESERVED')
  insert outbox_event(..., type = 'BenefitReserved')
commit

如果预算与权益由不同服务负责，就无法依靠一个本地事务同时提交。此时需要明确哪一个是流程协调者，以及失败如何补偿。可以先预留预算，再预留权益；权益失败后释放预算。流程中每一步都要幂等，并由超时扫描和对账发现长期停留状态。把两个 RPC 放进一个方法并不能获得分布式原子性。

热点账户和分片

大促活动可能让所有请求竞争同一个预算账户或券模板行。盲目增加应用实例只会把竞争推向数据库。可选策略包括：

• 按活动和区域拆分预算子账户，父账户负责授权，子账户负责在线消耗。
• 预先把额度分配到分片令牌桶，定期归还未使用额度。
• 对极限量权益按一致性要求使用单分区串行化处理。
• 将“资格判断”和“额度承诺”分开，只有最终候选进入账本写路径。
• 保留全局对账，验证子账户之和没有突破父账户授权。

分片提升吞吐的代价是额度利用率和回收复杂度。方案选择应依据权益是否允许少量保守拒绝、是否允许短时超额以及财务损失上限，而不是只看 QPS。

事件表达事实，不伪装跨系统命令

营销链路需要传播事实，但事件总线不能替代责任边界。SendCoupon 是命令，表示期望某个服务执行动作；BenefitGranted 是事实，表示权益已经形成。把命令命名为事件，会隐藏失败时谁负责重试和裁决。

一条权益预留事件可以是：

{
  "eventId": "evt-01J2MM12A8X6",
  "eventType": "BenefitReserved",
  "occurredAt": "2026-08-18T20:01:12.381+08:00",
  "producer": "benefit-ledger",
  "schemaVersion": 2,
  "traceId": "trc-44d20...",
  "reservationId": "res-908172",
  "decisionId": "dec-01J2MKT9F4PK",
  "campaignId": "cmp-member-day-202608",
  "customerId": "cus-18002341",
  "benefitDefinitionId": "ben-sku1024-20",
  "budgetAccountId": "budget-cmp-member-day",
  "amount": { "value": "20.00", "currency": "CNY" },
  "expiresAt": "2026-08-18T20:16:12+08:00"
}

跨边界事件至少要定义唯一性、顺序范围、重复消费、迟到处理、敏感字段、兼容策略和保留时间。消费者使用 eventId 或业务键去重，但不能因此宣称全链路 exactly-once。生产者可能重试，Broker 可能重投，消费者也可能在提交业务事务后、提交消费位点前崩溃。正确目标是“重复到达时业务结果仍然正确”。

曝光事件还要避免过度采集。它应记录 decisionId、Offer、触点、展示时间和必要的实验信息，不应复制完整客户画像和规则输入。需要复盘的输入摘要由决策日志按权限保存，事件总线不是无限数据仓库。

质量属性从业务损失推导

营销链路并非所有步骤都要求同一可用性。在线商品页决策超时会直接影响页面体验，短信发送延迟可以重试，归因批次延迟数小时通常不影响交易。技术架构需要按业务场景分别定义。

场景	目标要求	业务损失	技术含义
在线 Offer 决策	峰值 1.2 万 QPS，p99 不高于 80ms	页面延迟或无法展示优惠	本地候选索引、特征缓存、硬超时和无优惠降级
Consent 判断	新撤回 5 分钟内生效	合规风险和客户投诉	主动失效、短缓存、队列任务撤销
权益预留	不突破预算和限量，重复请求不重复占用	直接财务损失	条件写、幂等键、账本和对账
渠道投递	供应商故障可切换，重复消息受频控	重复打扰或活动延迟	任务幂等、供应商路由、回执状态机
行为采集	峰值 8 万事件/秒，允许可控迟到	测量延迟或数据缺口	分区扩展、背压、原始日志和质量标记
归因计算	支持迟到、退款和模型重算	经营判断失真	批次版本、窗口、可重放和结果快照

“决策服务 99.99% 可用”仍不足以证明营销能力可用。如果权益账本拒绝了所有请求、特征停留在昨天或 Consent 数据无法更新，HTTP 仍可能健康。业务可用性要同时观察决策成功、有效候选、权益承诺、真实曝光和合规拒绝。

容量模型保留放大系数

行为事件峰值 8 万/秒，不等于每个下游都需要处理 8 万/秒。需要继续拆解：

原始事件流量
  × 有效事件比例
  × 需要实时特征的事件比例
  × 每个事件更新的特征数量
  × 身份关联放大
  × 重试和迟到修正系数
= 实时特征写入压力

在线决策也有放大：一次请求可能召回几十个候选，读取多个特征，执行数百条条件，但最终只对一个权益进行预留。应分别测量候选召回、规则评估、特征读取和账本写入，而不是用一个接口 QPS 掩盖内部热点。

容量评审至少保留以下假设：

• 每种场景平均和最大候选 Campaign 数量。
• 单次规则评估读取多少本地和远程特征。
• 客户、活动、商品和预算账户的热点分布。
• 缓存失效时回源比例和回源容量。
• 行为事件最大积压时间及恢复速度。
• 渠道供应商故障后的任务堆积和补发窗口。
• 归因窗口内需要重算的数据量。

压测要覆盖缓存冷启动、规则版本切换、热点活动、Budget 即将耗尽、Broker 积压和依赖超时。只在全缓存命中且候选很少的情况下得到 p99，没有生产意义。

降级顺序需要业务授权

依赖故障时不能由开发人员临时决定“返回一个默认券”。默认优惠同样是企业承诺。每个场景应预先声明降级政策。

故障	可选降级	禁止行为
个性化特征过期	返回非个性化公开 Offer，记录 FEATURE_STALE	使用超出授权或过旧的敏感特征
Consent 服务不可用	对营销触达采取保守拒绝	假设所有客户都已授权
规则服务异常	使用已验证的上一个规则快照或无优惠	绕过利润与互斥护栏
权益账本超时	返回不含稀缺权益的 Offer 或明确无结果	先向客户展示再补发权益
渠道供应商故障	暂停、切换供应商或延迟发送	无频控地跨渠道重复补发
行为事件积压	标记数据新鲜度，暂停依赖实时行为的策略	把旧画像当作实时结果

降级触发、持续时间、影响活动和恢复条件要进入决策日志与运营看板。否则活动结果下降时，业务只会看到转化变化，却不知道平台曾经在降级模式运行。

可观测性围绕业务主键建立

组件指标用于判断服务是否健康，业务追踪用于解释企业状态。营销链路至少需要贯通：

customerId
  -> audienceSnapshotId
  -> decisionId
  -> campaignId / policyVersion
  -> reservationId / grantId
  -> exposureId
  -> orderId / paymentId / refundId
  -> attributionId / experimentAssignmentId

日志不能只记录整段请求 JSON。应输出结构化字段、理由码、阶段耗时和版本，敏感字段按分类脱敏。指标则按活动、场景、渠道和策略版本聚合，防止一个故障被总平均掩盖。

业务状态监控可以包括：

• 决策请求中 Consent 拒绝、频控拒绝、预算不足和无候选的比例。
• 每个规则版本的选择率、权益预留率和曝光转化漏斗。
• Reservation 长时间停留、Grant 重复、核销与退款回冲差异。
• 曝光事件缺失、重复、迟到和无法关联决策的比例。
• 订单转化无法关联实验分组或关联多个冲突分组的比例。
• 遗留渠道仍直接发券、直接圈人和绕过频控的流量。

优惠消耗异常的排查闭环

某晚监控发现活动预算消耗速度是预测的 2.4 倍，但订单量只增长 18%。排查不能从数据库 CPU 开始，而应先验证业务状态。

第一步：确认预算变化是否真实

按 budgetAccountId 检查可用、预留、确认和回冲是否守恒，区分预算真实消耗、预留未释放和指标重复聚合。如果账本守恒但预算消耗快，问题在上游决策或业务策略；如果不守恒，先冻结活动并进入账本修复流程。

第二步：从异常 Reservation 回到决策

抽样 reservationId，关联 decisionId、customerId、campaignId 和 policyVersion。检查同一客户、活动和权益是否因不同 requestId 重复预留，渠道重试是否正确复用幂等键。

第三步：比较规则版本和人群快照

异常从 20:10 开始，而 policy-184 在 20:08 发布。回放相同输入发现新规则把“最近 30 天未购买”误写成“最近 30 天购买”，候选人群扩大。此时服务性能完全正常，根因是策略语义和发布验证失效。

第四步：检查曝光和订单关联

部分 Reservation 没有 Exposure，说明渠道未展示或曝光回传缺失；部分 Exposure 没有订单，属于正常未转化；少量订单关联了多个 Exposure，需要按实验与归因规则去重。不同情况不能统一标记为“发券浪费”。

第五步：形成修复和治理证据

立即回滚规则版本，释放没有形成 Grant 的过期 Reservation；对已发权益按承诺继续履约，不能偷偷删除客户资产；重算受影响的人群和实验指标；补充规则静态检查、样本人群差异阈值和发布前预算模拟。事故结果进入 ADR、策略审核和 Phase H 变更，而不是只修一条表达式。

这条排查链说明营销可观测性的价值：从财务异常回到业务状态、架构版本和具体输入，而不是在几十个服务日志中猜测。

相关性、归因和增量效果是三个层次

客户看到活动后下单，只能证明接触和购买存在时间关联。归因模型按照规则分配贡献，但仍不必然证明活动造成购买。只有合理实验或准实验设计，才能估计“如果没有活动，客户是否仍会购买”。

横向滚动查看完整流程 · 点击打开高清原图

读图：上轨只记录发生过的交易事实，下轨分别回答过程转化、触点解释和因果增量；分析结论通过策略反馈生效，不能改写订单事实。

层次	回答的问题	典型方法	不能证明什么
漏斗分析	从触达到购买在哪一步流失	曝光、点击、领券、下单、支付漏斗	购买是否由营销造成
归因分析	按模型把转化贡献分给哪些接触点	首次、末次、线性、时间衰减	模型分配是否等于因果贡献
增量测量	有活动比没有活动多产生了多少结果	随机对照、Holdout、准实验	结果是否能无条件推广到其他人群和时期

末次触点归因适合回答“转化前最后一次可识别接触是什么”，不适合直接决定全部预算。品牌触达可能影响早期认知，搜索广告常靠近转化；末次模型会系统性高估后者。多触点模型可以改变分配，但如果输入曝光和身份关联不可信，只会更复杂地计算错误数据。

实验设计必须进入活动创建阶段

活动结束后再找一个相似人群作为对照，容易受到选择偏差。Campaign 创建时就应声明实验单元、分流算法、实验组、对照组、主要指标、护栏、最小检测效应和停止条件。

实验单元

如果按设备随机，同一客户在手机和小程序可能进入不同组，造成污染；如果按客户随机，家庭共享账号仍可能相互影响；门店活动可能需要按门店或区域随机。实验单元由业务干预范围决定，不是固定使用 customerId。

分组稳定性

分组通常使用稳定哈希：

bucket = hash(experimentId + unitId + salt) mod 10000

实验版本和 Salt 必须固定。发布中途调整流量时要保持已入组单元不跳组，或者明确创建新实验阶段。否则实验组差异可能来自样本重排，而不是策略效果。

人群漂移

动态人群每天变化会改变样本构成。需要明确采用入组时冻结资格，还是持续重新判断。前者更利于解释，后者更贴近持续运营，但分析必须处理进入和退出。无论选择哪种，都要保存 Audience Snapshot 或资格时间线。

对照组保护

对照组可能被其他活动触达。企业级互斥和 Holdout 需要在实时决策层执行，而不是只在某个 Campaign 内排除。测量平台要记录污染：客户是否从其他渠道获得同类 Offer、是否使用自然会员价、是否被门店人工发券。

转化与归因必须处理迟到和撤销

一次支付可能在曝光后几分钟完成，也可能在数天后完成；订单还可能部分退款。归因平台需要同时保存原始业务事实和计算结果。

ConversionObserved：订单或支付域确认发生了转化
AttributionCalculated：某模型、窗口和批次对转化作出贡献分配
AttributionAdjusted：迟到事件、退款或身份修正导致结果变化

AttributionCalculated 不能覆盖原事件，也不能修改订单金额。它需要包含 modelVersion、window、calculationBatchId 和输入截止时间。经营报表引用具体批次，历史复盘才能解释数字为什么变化。

跨渠道去重不能只靠 URL 参数。优先使用企业客户身份和 decisionId、exposureId 形成强关联；没有强关联时，可以使用时间、设备和商品等弱证据，但结果必须标注置信度，不能与确定关联混在同一口径中。

三层证据看板防止局部成功

营销架构运行后，需要同时观察三层证据：

层次	代表指标	回答的问题
业务结果	增量毛利、客户留存、营销成本、退款、投诉	投资是否创造可持续价值
能力运行	决策成功率、权益承诺率、真实曝光率、频控和降级占比	端到端能力是否稳定工作
数据质量	身份未解析、特征陈旧、事件迟到、关联失败、对账差异	结果是否建立在可信事实之上

如果业务结果下降但能力和数据稳定，可能是策略假设错误；能力指标异常说明运行链路需要处理；数据质量异常则意味着结果本身不可信。三层分开，才能判断应该调整 Campaign、修复平台还是暂停结论。

Baseline、Target 和 Gap 使用相同维度比较

Baseline 不能只列 CRM、CDP 和券平台，Target 也不能只画一个“营销中台”。两者需要按相同责任维度描述。

维度	Baseline	Target	可执行 Gap
业务	渠道活动分别追求发送和成交	以增量毛利和客户护栏管理活动组合	结果树、Capability Owner、预算和复盘机制
数据	身份、人群、曝光和转化口径分散	权威事实、版本快照、Consent 和测量输入可追踪	身份映射、数据契约、质量阈值和 Owner
应用	CRM、CDP、券和渠道各自决策	活动、决策、权益、渠道和测量责任清晰	接口改造、写权限收敛、旧任务退出
技术	离线名单导出、同步脚本和渠道本地重试	实时决策、权益账本、事件链路和可回放测量	容量、幂等、状态机、降级、观测和恢复
组织	各团队只负责系统和渠道指标	跨域 Owner 对增长结果与事实负责	决策权、评审、例外、值班和运营流程

一个 Gap 需要写出证据、目标责任、依赖、Owner 和退出条件：

id: GAP-MKT-BENEFIT-03
problem: 活动预算、券额度和订单核销缺少共同业务凭证
evidence:
  - 三个平台对同一活动发券量相差 11%
  - 预算预留无法关联到具体 decisionId
target: 权益账本成为营销权益承诺和状态变化的权威方
depends_on:
  - DATA-CUSTOMER-ID-MAPPING
  - CONTRACT-ORDER-BENEFIT-REDEMPTION
owner: 营销权益 Capability Owner
exit_criteria:
  - 新活动 100% 使用 reservationId 关联预算和权益
  - 连续四周账本守恒且不可解释差异低于阈值
  - 遗留券平台不再接受新活动直接写入

过渡架构用七个阶段转移责任

企业不能停掉 300 个活动后重建。迁移路线需要让每个阶段都能运行、对账和回退，并明确谁在当前范围内拥有最终裁决权。

横向滚动查看完整流程 · 点击打开高清原图

读图：迁移不是七次系统上线，而是七次责任接管；只有进入条件、对账结果、回退点和退出证据齐备，写入口才能继续向新平台移动。

阶段一：语义和 Owner 对齐

先定义 Campaign、Offer、Audience、Exposure、Benefit 和 Conversion，建立业务 Owner、数据 Owner 和应用 Owner。盘点所有活动、名单导出、规则、券写入口、渠道任务和报表口径。

退出证据不是词汇表完成，而是核心团队在需求、接口和报表中使用相同对象，新增活动必须声明目标、预算、Offer 和测量设计。

阶段二：统一采集、身份和 Consent

保留现有活动执行，先接入标准行为事件、身份映射和 Consent。原始事件与标准事件分层保存，建立迟到、重复、身份未解析和撤回传播指标。

此阶段不让 CDP 回写订单或会员，只形成可信读模型。退出条件包括主要触点事件覆盖、Consent 撤回达到 SLA、关键人群能够按版本重现。

阶段三：影子决策

新决策服务读取真实流量并产生结果，但不影响客户。把新旧结果按客户、场景和时间对比，分类差异：数据新鲜度、规则语义、优先级、频控、权益不足或实现缺陷。

影子运行的目标是获得接管证据，不是长期维护两套规则。每类差异都要有 Owner 和预期收敛时间。

阶段四：低风险活动接管

先选择无稀缺权益、允许无结果降级、渠道范围小的活动，由新平台负责决策和频控。旧系统在该范围内停止决策，只保留快速回切入口。

以活动或客户分桶灰度，不能让同一范围同时接受新旧系统最终决策。对比真实曝光、转化、延迟、降级和投诉后再扩大。

阶段五：权益与预算账本接管

接入券、积分和赠品，先迁移低金额、规则简单的 Benefit。新账本成为已迁移活动的唯一承诺方，遗留平台只能执行或查询，不得继续直接发放。

进入条件包括幂等、状态机、对账、退款回冲和故障演练通过；退出证据包括共同凭证覆盖率、账本守恒、遗留写流量归零和权限收回。

阶段六：渠道编排和测量统一

渠道网关统一频控、发送、撤销和回执，实验分组与 Exposure 进入统一契约。渠道仍可保留展示和供应商适配，但不能自行改变人群、Offer 和企业级触达政策。

归因报表按模型和批次迁移，旧报表保留一段对照期。数字不一致要解释口径、窗口和数据源，不能为了“对齐历史”而复制错误算法。

阶段七：旧写入口和报表退出

下线遗留规则任务、名单导出、直接发券、渠道本地频控和旧归因作业。检查流量、数据库权限、定时任务、消息消费者、手工 SOP 和应急脚本，避免系统页面下线但责任仍然存在。

最后以运行证据确认收益：活动准备周期缩短、不可解释权益差异下降、重复触达减少、Consent 违规为零、增量结果可测。没有收益验证的系统退役，只证明完成了技术迁移。

双写不是长期过渡架构

营销迁移常提出“新旧平台同时发券，之后对账”。这把一次业务承诺扩展成两个独立成功或失败的写入，客户可能收到两份权益，也可能两边都失败。事后对账可以发现差异，却无法撤销客户已经看到的承诺。

更稳妥的方式是按互斥范围迁移最终责任：活动 A 由新平台裁决，活动 B 仍由旧平台；或客户桶 0-9 由新平台，其他由旧平台。影子系统只读输入并比较结果，不作外部承诺。确实需要短期双写时，必须有唯一裁决方、补偿策略、每日差异看板和到期日。

架构治理进入规则和数据流水线

营销规则变化频繁，不能每次都召开架构委员会。治理应按风险分层：普通文案和时间调整由活动 Owner 审批；影响预算、价格叠加、敏感人群或跨域事实的变化进入更高层评审。

可以自动化的护栏包括：

原则	自动检查
Consent 优先于营销目标	规则必须声明 purpose 和 channel，禁止空值发布
预算和权益不得超额承诺	发布前预算模拟、账本条件写和守恒对账
同一事实只有一个权威修改方	数据库权限、API 写入口和事件 Producer 检查
人群和规则必须可重现	定义版本、数据截止时间、样本 Diff 和回放测试
实验组必须稳定	分组算法、Salt、流量变更和污染检测
临时例外必须退出	范围、补偿、Owner、到期日和退出证据

一次大促前，会员平台无法满足批量等级查询时，可以批准营销平台读取只读快照，但例外要限制活动、渠道和有效期，每日与会员平台对账，不允许回写等级，并在正式查询能力上线后删除字段、任务和权限。例外不是“先上线再说”，而是带补偿和退出条件的风险决策。

ADR 保留营销架构中的取舍

营销平台容易把选型记录当作 ADR，例如“使用某规则引擎”。真正需要保留的是责任与后果。

# ADR-MKT-017：在线决策不直接查询分析仓库

## 背景
分析仓库拥有完整标签，但刷新和查询延迟无法满足商品页 80ms 的决策预算。

## 决策
标签与人群平台把获准用于在线决策的特征发布到版本化特征视图；决策服务只读取声明新鲜度的在线副本。

## 取舍
增加特征发布、缓存一致性和回放存储成本；换取可控延迟、用途隔离和稳定降级。

## 迁移影响
先覆盖公开 Offer，涉及稀缺权益的策略在特征新鲜度和对账达标后接入。

## 复审条件
在线特征无法满足业务时效，或新的低延迟分析能力能够同时提供版本和用途控制。

这种 ADR 可以被后续团队重新判断。只写产品名，无法解释为什么当前约束下选择了这一责任边界。

把案例映射回 ADM 控制回路

本文没有机械按 Phase A 到 H 排列，但整条链仍然遵循 ADM 的推理闭环：

ADM 阶段	营销案例中的关键决策
Preliminary	明确增长、财务、Consent、数据和平台的决策权与原则
Phase A	把营销中台要求还原成增量毛利、客户护栏和可解释证据
Phase B	建立结果树、价值流、能力热力和 Capability Owner
Phase C	定义客户、人群、权益、曝光、转化的数据权威与应用边界
Phase D	推导在线决策、事件采集、账本、降级、安全和容量要求
Phase E	把身份、Consent、决策、账本、渠道和测量 Gap 组合成工作包
Phase F	按责任依赖形成七阶段迁移，而不是按系统排发布日期
Phase G	用契约、影子对比、账本对账、灰度和退出证据治理实施
Phase H	用增量结果、投诉、数据质量和运行偏差触发策略及架构变化

ADM 在这里是控制不确定性的循环。影子决策可能证明目标规则并不优于旧规则，实验可能推翻增长假设，运行数据可能暴露 Consent SLA 不够。这些证据应该改变目标和路线，而不是为了维护原图而被忽略。

一套可交付的营销架构包

营销架构工作不应以一张目标系统图结束。最小交付物可以包括：

• 业务驱动、结果树、护栏指标和收益验证模型。
• 干系人关注点、Capability/Data/Application Owner 与决策权矩阵。
• 营销价值流、能力地图、成熟度和优先级。
• Campaign、Audience、Offer、Benefit、Exposure、Conversion 与 Attribution 词汇和生命周期。
• 数据权威矩阵、身份映射、Consent、时间语义、质量和血缘。
• 应用责任地图、同步 API、事件契约、状态机和失败语义。
• 在线决策的延迟预算、容量模型、缓存新鲜度、降级和恢复手册。
• 权益与预算账本不变量、幂等、对账和财务核销链路。
• 实验设计、归因模型、窗口、批次、污染和退款回冲规则。
• Baseline、Target、Gap、七阶段过渡架构和遗留退出清单。
• ADR、规则评审、例外、架构债务和三层证据看板。

交付物之间要有追踪关系：DRV-MKT-01 推导能力和指标，能力差距形成 Work Package，工作包改变接口和事实责任，发布证据证明责任接管，运行结果再验证驱动是否成立。文档数量不是完成标准，决策链是否能被追踪才是。

常见失效方式

• 把 CDP 当成所有客户相关数据的最终权威，复制交易和会员事实。
• 把 Campaign、渠道任务、人群快照和 Offer 塞进一个活动表。
• 先建设规则引擎，后补规则优先级、利润护栏和冲突裁决。
• 用缓存的 Consent 或会员等级无限期支撑在线决策。
• 把发券成功当作预算费用，缺少预留、核销和退款回冲。
• 决策返回就记录曝光，把网络失败和未渲染页面计入归因。
• 用末次触点归因宣称增量收入，不保留对照组和污染信息。
• 所有依赖故障都返回默认优惠，让降级突破业务护栏。
• 迁移期间新旧系统同时最终写入，再依赖事后对账收拾状态。
• 新平台上线后只看 QPS 和延迟，不检查旧任务、权限和写入口是否退出。

能力验证

• 能把“建设营销中台”还原为增量业务结果、客户护栏和可验证架构要求。
• 能区分 Campaign、Journey、Segment Definition、Audience Snapshot、Offer、Promotion、Coupon 和 Benefit。
• 能解释 CDP 为什么是组合视图，而不是订单、会员和 Consent 的共同写入方。
• 能设计带规则版本、人群快照、理由码和有效期的营销决策契约。
• 能用状态机、幂等键、条件写、Outbox 和对账保护权益与预算不变量。
• 能按业务损失设计在线决策、Consent、事件采集和归因的不同 SLO 与降级策略。
• 能区分漏斗、归因和增量实验，并处理分组稳定、人群漂移、污染、迟到和退款回冲。
• 能从预算异常沿 decisionId、reservationId、exposureId 和订单事实完成排查闭环。
• 能使用影子运行、互斥灰度和退出证据逐步转移事实责任，而不是长期双写。
• 能把规则评审、例外、ADR、数据质量和三层证据嵌入营销架构治理。

总结

营销系统的核心不是更快地创建活动，而是让企业能够在明确客户授权、利润和预算约束下，向正确的人作出可履约的价值承诺，并用可信事实判断这个承诺是否创造了增量结果。

TOGAF 把这件事从单个系统建设扩展成企业变化：业务架构定义结果、价值流和能力；数据架构确定身份、人群、权益、曝光和转化的权威；应用架构划分活动、决策、账本、渠道和测量责任；技术架构从业务损失推导一致性、容量、降级和可观测性；Gap 与过渡架构安排责任接管顺序；治理再用实验、对账、投诉和运行偏差把真实结果带回下一轮决策。

当每个 Offer 都能回到目标和规则版本，每笔权益都能回到预算和业务凭证，每次曝光都能回到真实展示，每个转化结论都能说明模型与证据，营销平台才不再是活动功能的集合，而成为企业可持续学习和增长的能力。