如何更新 Klaviyo 流程之后添加访客 ID

实施Visitor Identification（访客识别，Visitor ID）或身份解析解决方案，能够从根本上改变电商店铺识别站内购物者的方式。标准的客户端追踪脚本，如标准的klaviyo.js，通常只能识别每日网站流量的10%至15%，主要是那些在特定浏览器点击邮件链接的回访联系人。通过引入服务器端身份解析，品牌可以将匿名访客的识别率提升至50%甚至更高。

然而，将这些新识别的联系人和高意向会话事件直接导入Klaviyo，会带来操作上的摩擦。如果部署身份解析后不调整现有的生命周期工作流，可能会导致发送重复的放弃购物车邮件、破坏邮件模板中的动态产品推荐，或损害发件人声誉。学习如何在添加Visitor ID后更新Klaviyo流程，确保您的自动化消息准确、及时且合规。

为何添加Visitor ID需要调整流程

标准的Klaviyo放弃购物车流程依赖浏览器端的cookie，如__kla_id cookie或_kx URL参数，来触发Viewed Product或Added to Cart等事件。服务器端身份解析工具则不同：它们匹配第一方设备信号和网络数据来识别购物者，通过API将高保真事件数据推送回Klaviyo。

关于cookie参数如何与身份解析交互的详细说明，请参阅Klaviyo身份解析指南。

当这些服务器端数据与原生客户端追踪同时进入您的账户时，会出现三大主要挑战：

1. 事件冲突与重复发送：单个用户会话可能同时触发客户端的Viewed Product事件和服务器端的Visitor ID事件。若无去重逻辑，购物者将收到两套浏览放弃序列邮件。

2. 数据结构差异：原生Klaviyo事件使用特定键名传递产品变量。服务器端事件载荷通常将购物车商品或目录元数据结构化为嵌套的JSON数组，邮件模板中的Liquid语法需相应更新。

3. 同意与投递敏感性：去匿名化的用户档案需谨慎管理。若对新识别的联系人发送过于激进的促销邮件，可能导致垃圾邮件投诉率升高，影响投递率。

步骤1：审查当前流程触发策略

在修改Klaviyo流程构建器中的具体设置之前，您必须决定是更新现有的原生流程，还是为服务器端事件构建专门的并行流程。

选项A：更新现有原生流程

此方案保留当前流程结构，但调整主要触发器或通过自定义指标实现双触发逻辑。此方法保持流程库整洁，并将报告集中在一个位置。

选项B：构建并行服务器端流程

专门为服务器端身份事件（例如通过自定义集成或工具如Attribuly导入的事件）创建独立流程，能让您对消息发送时机、文案和受众细分拥有更细致的控制。您可以独立测试性能，然后再逐步淘汰原生流程。

若选择并行流程，必须严格设置跨流程抑制过滤器，以防止跨渠道冲突。

步骤2：重新配置关键放弃序列的流程触发器

更新您的恢复系列，需重新映射主要放弃工作流中的事件指标：浏览放弃、购物车放弃和开始结账。

1. 浏览放弃流程

进入Klaviyo管理后台 > 流程，选择您的浏览放弃流程。

• 触发指标：将流程触发器从标准的Viewed Product指标更改为您的服务器端身份事件（例如Attribuly SS Viewed Product或自定义的Visitor Identified事件）。

• 触发过滤器：如果您的Visitor ID提供商传递身份置信度分数，请设置触发过滤器，如Confidence Level equals High，确保只有经过验证的档案匹配进入流程。

2. 购物车放弃流程

购物车放弃工作流捕捉那些表现出明确购买意向但未进入结账的购物者。

• 触发指标：将触发器更新为您的服务器端Added to Cart事件数据。

• 交接过滤器：添加档案过滤条件，规定Started Checkout 0 times since starting this flow。确保进入结账阶段的购物者立即退出购物车流程。

如需查看未认证购物车恢复的基础配置，请阅读如何为匿名用户构建Klaviyo放弃购物车流程。

3. 开始结账流程

结账启动代表您最高意向的自动化流程。连接您的服务器端结账触发器，并应用严格的排除过滤器，确保完成交易的购物者通过标准的Placed Order 0 times since starting this flow档案过滤器立即被排除。

步骤3：配置跨流程过滤器与去重逻辑

为维护投递健康并防止订阅者疲劳，请在每个更新后的流程中实施明确的档案过滤器。档案过滤器在发送每封邮件前评估联系人的状态。

必备档案过滤器方案

请将以下标准组合的档案过滤器应用于您的服务器端放弃流程：

• Has placed order 0 times since starting this flow

• Has not been in this flow in the last 7 days

• Has not received email in the last 24 hours（去重规则）

[流程触发器：服务器端事件]
       │
       ▼
[档案过滤检查]
  ├── 过去无订单？ ──► 是
  ├── 过去7天未进入流程？ ──► 是
  └── 过去24小时未收邮件？ ──► 是
       │
       ▼
[发送邮件步骤1（智能发送开启）]

智能发送与频率限制

请务必在恢复流程的每个初始动作步骤中开启Klaviyo的智能发送开关。将账户级智能发送窗口设置为16至24小时。若购物者在两小时内触发了浏览放弃和购物车放弃序列，智能发送会自动抑制意向较低的浏览邮件，优先发送意向更高的购物车恢复邮件。

步骤4：映射服务器端事件载荷的动态Liquid变量

当将流程触发器从客户端脚本事件切换到服务器端数据时，渲染产品图片、标题和结账链接的模板标签必须更新。服务器端载荷中商品数组的结构与标准网页脚本不同。

要更新邮件模板，请打开邮件编辑器，选择动态文本或图片模块，并映射Liquid变量以匹配您的新事件结构：

要在Klaviyo中验证变量，请点击邮件模板编辑器中的预览与测试，选择事件作为预览数据源，选择您的服务器端指标，并直接从载荷树中选择目标属性。

步骤5：合规、同意及端到端质量保证测试

身份解析使您能够识别之前的匿名访客，但并不替代明确的营销同意。确保所有服务器端恢复流程在邮件设置标签中开启“不发送给被抑制的档案”。将广泛的促销新闻邮件保留给通过注册表单或结账同意框明确选择加入的订阅者。

在将流程状态从草稿或手动更改为上线之前，请完成以下四步质量保证验证：

1. 隐身模式测试：打开新的隐身浏览器窗口。浏览产品，添加商品到购物车，并使用指定测试邮箱进行结账。

2. 开发者工具检查：打开浏览器开发者工具（F12），切换到网络标签，筛选track或events。确认服务器端载荷生成稳定的unique_id并正确触发。有关事件数据传递详情，请参阅ReCapture集成指南。

3. 档案活动流验证：在Klaviyo > 受众 > 档案中找到测试档案。确认服务器端事件出现在活动流中，且未与原生事件重复触发。

4. 流程预览：在流程构建器中，点击预览触发设置，使用测试档案。确保档案通过所有档案过滤器，顺利进入步骤1，且无触发冲突。

通过审查指标、应用严格的跨流程过滤器及更新模板变量，您可以安全地利用访客识别扩大恢复收入，同时保障收件箱投递率和客户体验。