实时个性化是指根据访问过程中可获得的信号来改变网页展示的内容：访客所在的公司、来源渠道、本次及之前会话中浏览过的内容。决策发生在页面加载时或访客在页面之间跳转时，而不是几天后的一封邮件序列里。
示例（示意）：一位来自目标客户名单中某大公司的访客来到首页。公司识别在第一次请求时就识别出该客户，于是标题讲的是安全和管理，而不是默认信息；证明模块展示同行业的客户；CTA 提供与客户团队沟通的机会，而不是“了解更多”。访客既没有登录，也没有填写任何内容。本文介绍这与较慢的个性化方式有何不同、可以使用哪些信号、B2B 示例、首次实施、技术组成，以及如何衡量其是否有效。
实时个性化与延迟个性化
大多数营销个性化都有延迟。访客下载了一份白皮书，CRM 工作流给他打上标签，几天后发出一封对应的邮件。这有用，但它回应的是对方上周做了什么。
实时个性化是一种基于实时信号的动态内容：每次请求时，系统查看它对访客的了解，执行细分规则并选择一个变体。这一点很重要，因为 B2B 旅程是不规则的。一个潜在客户可能参加了网络研讨会，沉寂三个月，然后通过一次搜索回来，一口气读了五个客户案例。每周运行的工作流发现这次回访时已经太晚；实时规则则能在第二个页面就做出响应。
| 延迟（批量） | 实时 | |
|---|---|---|
| 解答的问题 | 这个人最近做了什么？ | 这位访客现在在做什么，页面接下来应该展示什么？ |
| 典型渠道 | 邮件、广告、销售任务 | 网站页面、应用内消息 |
| 所需的数据新鲜度 | 数小时到数天 | 请求期间即可获得 |
| 主要技术风险 | 过时的细分 | 决策缓慢和页面闪烁 |
访问过程中可用的信号
- 企业属性。由访客识别服务根据访客 IP 解析出的公司、行业、规模和所在地。对于网络可解析到公司的访客，首次加载页面时即可获得，因此是最常见的 B2B 触发条件。覆盖并不完整：家庭和移动网络连接往往无法解析。
- 会话行为。浏览的页面、内容类别、滚动深度、站内搜索。先看价格页再看集成页的访客，是在向您传递一个很具体的信息。
- 历史。之前的访问、下载和网络研讨会参会记录，在访客通过第一方 Cookie、登录或可追踪的邮件链接被识别时可以获取。
- 引荐背景。UTM 参数、引荐域名和广告系列。来自面向财务负责人的 LinkedIn 广告的点击，不应该落在一条泛泛的信息上。
- CRM 状态。该账户是否为客户、是否有进行中的商机，或是否在 ABM 名单上。需要在 CRM 和个性化工具之间同步。
- 技术栈。来自第三方数据的公司所用工具。有助于优先展示合适的集成，但请核实准确性；这类数据容易过时。
B2B 案例
以下示例是示意性的模式，而非案例研究。
按客户层级定制的首页
第 1 层目标客户在标题中看到其行业的问题，配上相关客户案例和与其专属客户经理会面的 CTA。第 2 层客户看到行业信息和自助演示 CTA。其他所有人看到默认版本。这让基于客户的营销从外呼邮件延伸到了客户本来就会访问的网站上。
按行业展示社会认同
证明模块不再是固定的 logo 墙，而是展示与访客所在行业最接近的客户，以及一段来自相似公司的简短引言。前提是您在每个要个性化的行业都有真实客户；没有客户的行业就保留默认版本。
基于本次会话的内容推荐
读过三篇分析类文章的访客，侧边栏会显示分析相关的推荐，而不是默认的“最受欢迎”列表。上次看过产品演示的回访者，会看到客户故事，而不是又一次产品介绍。
按阶段划分的 CTA
来自未知公司的首次访客：“阅读指南”或“看看它如何运作”。来自目标客户、已阅读产品页面的回访者：“预约演示”。已经申请过演示的人：“为您的演示做准备”，附上议程和集成检查清单，而不是再给一个申请表单。我们关于数据驱动的个性化 CTA的文章介绍了如何测试这些。
按公司规模定制的价格页
一家50人的公司看到中档套餐被标为推荐；一家5,000人的公司看到企业版卡片被突出显示，并附有联系销售的 CTA。价格和套餐对所有人都一样，变化的只是侧重点。
五步完成首次实施
- 一个页面，一个细分人群。通常是首页或主落地页，再选一个能可靠识别的细分人群，例如规模超过某个阈值的公司或某一个行业。同时铺开多个页面和细分人群，正是这类项目停滞的原因。
- 先写好版本内容。标题、证明模块和 CTA。如果您说不出这个细分群体应该听到什么不同的内容，那就还没准备好配置任何东西。
- 将识别与细分连接起来。写好规则（“公司员工500人以上：显示企业版变体；否则显示默认版”），并在上线前用已知公司的访问进行测试。
- 交付时避免闪烁。在服务器或边缘节点决定变体，或者让客户端脚本只替换个性化区块，其余部分正常渲染。不应让访客看到默认标题一闪而过再变掉。
- 与对照组比较衡量。把细分在默认版本和变体之间分流，上线前确定样本量，只有变体胜出才扩大推广。
技术组成部分
数据层。访客档案的来源：识别服务、CDP，或有快速 API 的 CRM。如果查询速度慢，页面会在决策返回之前就渲染出默认内容。请在真实流量上测量查询的响应时间，而不是在办公室网络上测。
决策引擎。评估规则并选择版本。大多数 B2B 团队从明确的“如果/那么”规则开始，因为它们易于解释和调试。基于模型的版本选择所需的每个细分群体流量，远超大多数 B2B 网站的实际流量。
交付方式。客户端 JavaScript 设置最快，但有闪烁的风险。服务器端渲染能避免闪烁，但需要工程投入。边缘交付（在 CDN 层修改响应）两者都能避免，前提是您的 CDN 支持。
性能与缓存
在上线前后检查对 Core Web Vitals 的影响，尤其是最大内容绘制（LCP，主视觉通常就是 LCP 元素）和累积布局偏移（CLS，替换后尺寸变化的内容块会让页面跳动）。为个性化内容块预留空间，避免它们把内容往下推。
因访客而异的页面需要谨慎处理缓存。要么缓存共享的页面框架、只对特定模块做个性化，要么在边缘节点做决策，让每位访客得到自己的结果。把个性化响应缓存后提供给下一位访客是常见的 bug，而且它还可能被搜索引擎抓取；参见个性化如何影响 SEO。
衡量是否见效
主要指标是细分人群内部的转化率：个性化组 vs 同一细分人群中看到默认版本的对照组。将个性化访客与全站平均值比较是行不通的：已识别的目标客户本来就和匿名流量转化表现不同。
次要指标有助于解释结果：个性化元素的点击、每次会话页数和回访次数。如果互动上升而转化没有，说明变体吸引了注意力却没有改变决策；请在意向更高的页面上尝试。
不要用流量来评判个性化。它改变的是访客到达后的行为，而不是到达的人数。关于如何把测试结果转化为商业论证，请参阅我们的衡量个性化 ROI指南。
常见陷阱
- 基于错误数据做个性化。如果识别匹配到了错误的公司，或者 CRM 数据已经过时，页面就会显得莫名其妙。在基于这些匹配制定规则之前，先拿您熟悉的客户进行抽查。
- 一次改太多。根据访客数据改变每个元素会让人觉得被监视。每个页面改两三个元素就足够了：要让访客觉得页面与自己相关，而不是觉得页面对自己了如指掌。
- 跨团队没有负责人。营销编写变体，销售需要信任账户数据，还需要有技术人员负责数据管道。缺少任何一方，项目在第一次测试后就会停滞。
- 割裂的旅程。个性化广告却落到通用页面，等于违背了承诺。针对同一细分，让广告、邮件和页面保持一致；我们关于B2B 网站个性化如何运作的解读介绍了端到端的设置。
从哪里开始
选一个页面、一个数据可靠的细分群体，以及两三个要修改的元素，然后与保留组对比运行，直到达到计划的样本量。如果胜出，就增加下一个细分群体；如果没有，再次尝试之前先检查改动是否足够大、细分群体是否足够聚焦。如果您想在不自己搭建底层管道的情况下启动第一个测试，Markettailor 通过基于规则的定向，将访客识别与页面改动连接起来。
