个性化平台最容易在演示时显得“什么都能做”：用户一进站，页面立刻变化；推荐自动出现；邮件随后触发；仪表盘还能告诉你“提升了多少”。

真正决定项目成败的问题往往在演示结束以后才出现：

  • 这个用户身份到底怎么合并出来的？
  • 哪些数据被复制到供应商系统？
  • 谁能修改决策逻辑？
  • 用户撤回同意以后多久生效？
  • 实验有没有长期保留对照组？
  • 如果以后换平台，决策日志和画像能不能完整拿走？

所以采购个性化工具，不能只当作“买一个营销软件”，而应该同时评估数据架构、决策系统、内容生产、实验体系、隐私治理和供应商依赖。

先把最小可证明用例写出来

在见供应商之前，先写一个很窄的用例：

  • 目标人群/资格条件；
  • 触发条件；
  • 要做的决策；
  • 展示什么内容或优惠；
  • 哪个渠道；
  • 成功指标；
  • 对照组；
  • 停止条件。

例如：

已购买A类商品但没有购买B类商品的回访客户，在首页看到一个B类模块；保留固定对照组，六周后比较B类商品的增量购买率。

这种问题比“我们想全渠道AI个性化”更容易验收。

如果供应商连一个小用例的数据、决策、测量和权限都解释不清，范围扩大以后只会更难。

1. 身份怎么合并？错配怎么发现？

要求供应商把身份链路画出来。

匿名浏览器、登录ID、邮箱、手机号、设备ID、CRM客户号、仓库记录分别怎么关联？

然后继续问：

  • 哪些关联是确定性的？
  • 哪些是概率匹配？
  • 同一家庭两个人会不会被误合并？
  • 同一个人跨设备会不会被拆成多个人？
  • 身份纠正后，旧受众和旧决策多久刷新？
  • 低置信度匹配，营销人员能不能看到？
  • 能不能规定某些标识永远不允许合并？

Salesforce当前的Personalization架构明确把身份解析和实时画像放在决策流程中；Twilio Segment也强调统一客户画像和跨系统激活。这类能力有价值，但买方必须继续追问：在自己的部署里，具体用了哪些匹配规则？

红旗是：演示里每个人都是完美的“360度客户”，实施方案里却没有任何身份错误复核机制。

2. 哪些数据必须离开我们自己的系统？

“能连数据仓库”不是答案。

要一张完整数据流图，至少标出：

  • 哪些数据复制进供应商；
  • 哪些数据只是读取；
  • 哪些结果写回；
  • 供应商生成哪些衍生标签；
  • 保存多久；
  • 删除怎么传递；
  • 存储地区；
  • 子处理商；
  • 备份如何处理；
  • 导出格式是什么。

NIST Privacy Framework本来就是帮助组织管理复杂系统中的隐私风险。个性化场景尤其适合用这个思路，因为系统通常会不断要求“再多接一点数据”。

更多数据不自动等于更好。每一个字段都应该有用途、负责人、保留期限和明确决策场景。

3. “实时”到底是多快？

不要接受“实时个性化”四个字。

把延迟拆成：

事件采集 → 身份更新 → 分群更新 → 决策 → 页面渲染 → 下游渠道触达。

有的系统事件秒级进来，但受众几小时才刷新；有的决策实时，但内容缓存不是实时。

这不一定是问题。

网页下一步推荐可能需要秒级，周度召回邮件根本不需要。

为真正需要的延迟付钱，不要为宣传页上最快的架构付钱。

4. 能不能解释“为什么这个人看到了这个内容”？

无论规则还是机器学习，都应该留下可追溯信息：

  • 为什么符合资格；
  • 为什么被排除；
  • 使用了哪些数据；
  • 哪个模型/规则版本；
  • 哪个内容版本；
  • 决策时间；
  • 当时还有哪些候选；
  • 回退逻辑；
  • 如果有评分，分数是什么。

如果收入下降、客户投诉，或者法务追问某个价格/优惠为什么出现，“AI自己决定的”不是一个可以运营的答案。

这一点在2026年尤其值得重视。美国FTC在2026年8月就个性化定价发布拟议执法政策声明并征求意见，之后把评论截止延长到9月25日。FTC明确表示并非所有个性化定价都被一刀切禁止，但如果企业在如何使用个人数据制定价格方面误导消费者，可能引发FTC Act问题。

因此要把“内容个性化”和“按个人数据改变价格”分开管理，高风险用例必须进入法务/隐私审查。

5. 规则、模型和人工优先级怎么排？

真实项目几乎都是混合系统：

  • 硬性资格条件；
  • 同意/拒绝条件；
  • 库存限制；
  • 频次限制；
  • 分群；
  • 模型分数；
  • 商业优先级；
  • 人工活动；
  • 默认回退内容。

让供应商现场说明优先级。

如果模型推荐了断货商品，谁覆盖谁？

用户刚退出某渠道，排除多久生效？

运营团队手动置顶活动时，会不会把模型完全压掉？这个人工覆盖有没有日志？

成熟系统不是“规则越多越强”，而是冲突时谁赢写得清楚。

6. 内容团队供得上吗？

个性化系统很快会制造内容债务。

10个受众 × 4个渠道，可能意味着几十套文案、图片、优惠、语言版本。

如果公司只有一个设计师和一个运营，再强的决策引擎也可能没有内容可选。

要问：

  • 同一个组件能不能复用；
  • 多语言在哪里管理；
  • 法务批准的文案能不能锁定；
  • 模板有没有版本；
  • 生成式AI只是出草稿还是能自动发布；
  • AI内容谁审批；
  • 能不能查到一个内容块目前在哪些地方上线。

如果供应商默认“内容无限供应”，很容易买回一套用不满的系统。

7. 怎么证明是“增量”，而不是“本来就会买”？

要求演示实验能力：

  • 固定对照组；
  • 随机分配；
  • 互斥实验；
  • exposure日志；
  • 样本比例异常检查；
  • 延迟转化窗口；
  • 导入CRM/订单结果；
  • 实验级数据导出。

个性化人群往往本身就是高意向人群。

“看到个性化内容的人转化更高”并不能证明内容带来了增量。

真正的问题是：

如果这个人没看到这次个性化，结果会不会不同？

平台做不了干净对照，就要考虑把实验系统放在平台外。

8. 隐私和同意到底在哪一层执行？

让供应商说清楚：同意状态是在采集时检查、建画像时检查、做分群时检查、做决策时检查、发消息时检查，还是多层都检查？

然后继续问：

  • 用户撤回后多久传播；
  • 历史标签还保不保留；
  • 删除请求怎么执行；
  • 敏感类别能否禁用；
  • 未成年人或受监管数据需要什么额外配置；
  • 数据是否用于训练供应商模型；
  • 政策变化以后怎么批量重算。

“我们符合合规要求”不是系统设计。

不同法域、数据类型、合同和业务场景会改变答案。企业需要可配置控制，也需要自己的法务/隐私判断。

9. 数据缺失、延迟、冲突时会发生什么？

真实画像一定不干净。

要求供应商演示：

  • 身份未知；
  • 事件延迟；
  • 属性冲突；
  • 库存不可用；
  • 推荐服务超时；
  • 用户没有历史；
  • 内容资产缺失。

这种情况下到底显示默认内容、旧内容、空白，还是报错？

回退机制是产品的一部分，有时比再多一个AI功能更重要。

10. 以后换平台，能不能完整离开？

签合同前要求做一次“退出演示”。

能不能导出：

  • 原始事件；
  • 统一画像；
  • 受众定义；
  • 决策日志；
  • 实验分组；
  • 内容元数据；
  • 同意状态；
  • 模型输出；
  • 配置变更历史。

哪些东西是供应商专有格式？终止以后还能访问多久？一次完整导出需要几天？

真正危险的不只是价格锁定，而是组织把决策方法都忘在平台里。

11. 前90天究竟需要我们投入多少人？

不要看“4周上线”这类宣传时间。

要求按角色拆人力：

  • 数据工程；
  • 分析；
  • 营销运营；
  • 内容/设计；
  • Web/App工程；
  • 隐私/法务；
  • 电商/产品；
  • 供应商专业服务。

软件便宜、内部实施很重，也可能是更贵的方案。

12. 费用按什么增长？

常见计费单位可能包括：

  • 月活追踪用户；
  • 画像数；
  • 事件数；
  • 决策次数；
  • 渠道数；
  • 席位；
  • 模块；
  • API量；
  • 专业服务。

要求供应商分别算当前量、2倍量、5倍量。

还要问一个非常现实的问题：如果追踪错误导致事件量突然翻几倍，系统会限流、报警，还是直接出一张更大的账单？

一张必须让供应商“失分”的评分表

领域 示例权重 必须看到的证据
身份与数据质量 20% 匹配规则、纠错、血缘
决策透明度 15% 原因码、日志、优先级
实验能力 15% 对照组、曝光日志
隐私与同意 15% 删除、撤回、策略控制
内容运营 10% 审批、多语言、版本
集成能力 10% API、仓库、CRM、网站
经济性 10% 1x/2x/5x成本模型
可迁移性 5% 实际导出证明

权重必须按业务改。

电商网站推荐可能更看重延迟、商品目录和页面集成；受监管行业则应该明显提高审计、同意和日志的权重。

最后一关：让供应商跑通一个完整闭环

签长期合同前，只验一条链：

事件进入 → 身份解析 → 资格检查 → 做出决策 → 内容展示 → 记录曝光 → 结果回传 → 看见对照差异 → 可以删除个人数据 → 可以导出决策历史。

这条链真的能跑通，复杂功能才值得继续看。

如果连这条链都讲不清，多加几个AI模块不会解决底层运营问题。

Sources

Related Reading