规模化个性化主要是一个运营问题。五条规则一个人记得住，但由四个人在一年里写出的五十条规则就记不住了。如果没有一定的结构，最终就会出现没人负责的规则、两条规则争夺价格页上的同一个标题，以及因为没人记得某个变体存在，一个细分仍然看到旧价格。
本文介绍让不断增长的规则集保持可控的结构：命名、登记表、明确的冲突优先级顺序、基于内容位而非定制页面的模板、性能检查以及职责分工。这些都不复杂，只是必须在规则数量增长之前就建立起来，而不是之后。
您已经超出当前配置能力的迹象
- 没人能说清某位访客会看到什么。有人问“大型医疗企业访客在首页上看到的是什么？”，回答这个问题需要打开好几条规则，甚至可能跨越不止一个工具。
- 冲突靠偶然解决。两条规则针对重叠的细分人群修改同一个元素，哪条生效取决于加载顺序或创建日期，而不是某个人做出的决定。
- 内容修改变成了大搜查。价格或产品名称一变，就得翻遍每个变体，找出旧措辞藏在哪里。
- 随着规则增加，页面变慢或开始闪烁，却没人注意到是什么时候开始的。
- 测试停滞，因为维护现有规则占用了所有可用时间。
削减规则数量有时是正确的做法，尤其是当很多规则从未被衡量过时。但更常见的情况是，规则本身没问题，缺的是查看和管理它们的方式。
给规则命名，让名称本身说明规则
选定一种命名格式并在所有地方使用。一种可行的格式：层级、细分、页面、元素和版本，按此顺序用连字符连接：
tier-segment-page-element-version
T1-acme-corp-homepage-hero-v2T2-enterprise-healthcare-pricing-proof-v1T3-returning-visitor-blog-cta-v3
层级前缀与下文介绍的冲突处理顺序相关联。其余部分让任何人浏览规则列表时，无需打开就能知道每条规则的作用。按页面筛选，就能看到所有会影响该页面的规则；按细分人群筛选，就能看到该人群看到的全部内容。
建立登记台账
一张电子表格就够了。每条生效的规则一行，包含以下列：
| 列 | 为什么要放在这里 |
|---|---|
| 规则名称 | 与工具中的名称完全一致 |
| 用途 | 一句话：“向医疗行业访问者展示医疗行业案例研究，以提升演示请求量” |
| 负责人 | 可以咨询的人，以及负责更新的人 |
| 细分定义 | 具体条件，以便看出重叠之处 |
| 页面和元素 | 在哪里修改内容 |
| 包含的事实 | 价格、套餐名称、客户名称、产品名称；当其中任何一项变化时，就搜索这一列 |
| 对照组 / 测试状态 | 已衡量、正在衡量或从未衡量 |
| 上次审核 | 日期 |
围绕它养成两个习惯。新规则需向登记表负责人提交简短申请（发一条 Slack 消息即可），以便在上线前发现重复规则。每个季度过一遍清单：下线经过完整测试后仍无效果的规则，更新过时的内容，合并为重叠细分做同样事情的规则。如果您不想自己搭建，可以用我们的个性化实操手册模板作为登记表；它有一列专门用于重叠优先级。
提前决定冲突如何处理
一位来自目标客户名单上某大型医疗公司的回访者，可能同时符合一条客户规则、一条“行业 + 规模”规则、一条行业规则和一条回访者规则。如果它们都针对主视觉，就必须有个东西来做决定。请把它定为明确的顺序：
- 第 1 级：指定客户规则。任何为特定客户或客户名单打造的规则都优先。这些规则最具体，通常与正在进行的销售对话相关。
- 第2层级：复合细分。结合两个或更多属性的规则（大型企业 + 医疗）优先于单一属性规则，因为有人认定这个组合值得专门的信息。
- 第3层级：单一属性规则。“所有大型企业访客”、“所有来自美国的访客”。作为兜底规则。
- 默认页面。其他所有人看到的内容，也是爬虫看到的内容。
在同一层级内，不要让“最近更新”或加载顺序来决定。在规则登记表中为同层级的每条规则指定明确的排序号，或者更好的做法是，从一开始就避免在同一元素上为重叠的细分群体设置同层级规则。隐性的平局判定规则，正是访客最终看到一个谁也没打算展示的版本的原因。
也可以按元素来避免冲突。如果客户规则负责首屏、行业规则负责信任证明区块，那么同时符合两者的访客会两样都看到，不会产生冲突。这是最简单的解决办法，值得优先尝试。
用模板和插槽代替定制页面
让大型规则集保持可控的模式是：固定页面布局，并定义几个可个性化的位置。规则只负责填充位置，而不重新设计页面。
B2B 首页的示例版位：
- 首屏标题（设有字数限制，确保变体在手机上也能完整显示）
- 主视觉副标题
- 证明模块：一排 logo 和一条引言
- 主要 CTA 文案和目标页面
- 重点客户案例
这样一来，创建一个变体只需为五个字段撰写文案并选择一个案例研究，营销人员无需占用设计或开发资源就能完成。这也让变体登记表变得有用：您清楚地知道一条规则可以改变哪些字段。
这种取舍是实实在在的。您的医疗行业变体和金融科技变体看起来会很相似，因为它们共用一个布局。对于大多数 B2B 网站来说，这是可以接受的，因为各细分之间变化的是信息本身。只为少数交易规模足以支撑额外投入的指定账户保留完全定制的处理，并接受这些页面需要单独维护。
随着规则增加关注性能
一套规则对速度的影响取决于决策在哪里发生。服务器端或边缘决策会在页面发送前增加工作量；客户端脚本则在页面渲染后增加工作量，并可能导致闪烁。无论哪种，都要实际测量而不是凭空假设：
- 个性化页面上的最大内容绘制（LCP）和闪烁。在 PageSpeed Insights 或实验室测试中，使用限速的移动端配置，比较个性化变体与默认页面。如果个性化首屏是 LCP 元素，且出现时间比默认页面晚，说明决策发生得太迟了。
- 个性化工具的决策耗时。大多数工具会记录一次决策耗时多久。长期追踪这一数据，每当它突然上升时，查看发生了什么变化。
- 兜底率。规则失效、改为展示默认内容的频率。悄无声息的兜底比页面出错要好，但兜底率高说明访客并没有得到登记表上所写的体验。
每批新规则上线前都记录一个基准，这样出现性能退化时就能追溯到导致问题的改动。RUM 工具或 Search Console 中的 Core Web Vitals 监控会标记持续存在的问题，但只有在足够多的真实流量受到影响之后才会发现。
谁负责什么
| 角色 | 职责 | 通常由谁担任 |
|---|---|---|
| 个性化负责人 | 登记表、命名、冲突处理顺序、季度审查、新规则的最终决定权 | 营销运营或增长负责人 |
| 内容创作者 | 为每个细分人群撰写模块文案，保持事实信息最新 | 产品营销、内容团队 |
| 技术实施者 | 设置规则、排查冲突、性能检查 | Web 开发人员或懂技术的营销人员，视工具而定 |
| 分析师 | 对照组、规则级结果、标记需要淘汰的规则 | 营销分析师（关于该岗位的工作内容，请参阅营销分析职业） |
在小团队中，一两个人包揽全部四个角色，只要有登记台账就没问题，因为这样另一个人也能接手工作。负责人这个角色不能含糊地共享：如果人人都负责规则集，就没人会去停用任何规则。关于大型组织中的 RACI、推广阶段和治理，请参阅企业个性化推广实施手册。
衡量规则，而不只是衡量项目
项目级对照组能告诉您个性化整体是否值得保留，但无法告诉您五十条规则中是哪几条在起作用。在流量允许的情况下，为每条第 2 层和第 3 层规则单独设置对照组或 A/B 测试；对于无法获得可解读样本量的规则，在登记表中标记为“未衡量”，而不是想当然地认为它们有效。我们关于衡量个性化 ROI的文章介绍了对照组规模和指标层级。
规则数量增加前的检查清单
- 一套所有人都遵循的命名规则
- 一份登记表，记录每条规则的负责人、目的、细分人群、事实依据和测试状态
- 书面的冲突优先级顺序，以及按层级划分的元素归属
- 至少为首页和价格页准备内容位模板
- 性能基线，以及每批规则上线后的检查
- 一位指定负责人和下一次季度复盘的日期
一个务实的第一步：把工具中所有生效的规则导出为上述登记格式。任何填不全的规则（不知道负责人、没有说明目的、不知道是否有效）都列入首次审查清单。如果您在 Markettailor 中进行设置，它的细分功能把细分人群定义集中在一处，更容易发现规则之间的重叠。