Customer Journey Builder

事件发生的瞬间,旅程立即启动

海外用户在应用里做出真正重要的动作——加入购物车、支付失败、完成下单——旅程就在那一刻开始,不必等待下一次分群刷新。

Customer Journey Builder 中的触发式入口元素配置界面:入口名称为「购物车挽回」,事件为 add_to_cart,并设置了 cart_value 大于 50 的入口条件

事件发生就立即启动,不必等待

你希望旅程能在某件事发生的瞬间启动,而不是等到下一次分群刷新轮到它。这句承诺说起来容易,账号里只要同时跑着十几条自动化,就很难兑现——购物车挽回旅程混在一堆同样合理的自动化中间。「我们注意到你的购物车里还有商品」,如果是夜间批处理一小时后才发出,和用户还没放下手机就已经在跑的消息,是两种完全不同的体验。对触达欧美、东南亚等海外市场的团队来说,这种响应速度上的差距会被用户直接感知到。触发式入口(Trigger-based entry)补上的正是这道时间差。

触发式入口能做什么

选定一个事件,任何触发它的人都会立刻进入旅程,不必等待下一次分群扫描。

实时响应

事件触发的瞬间就进入旅程,而不是等下一次预定扫描。

按事件负载筛选

可选的条件基于事件自身的属性,让入口资格不只看事件名称。

同时运行多个会话

按 order_id 或 product_id 计算的并发规则,让同一用户可以同时持有多个并行会话。

控制重复触发

按元素分别设置:拦截重复触发,或让它重启会话。

设置可选项
事件来源SDK postEvent、REST API、默认 PW_* 事件、自定义事件、地理围栏进入或离开
入口条件可选:基于事件自身属性设置筛选条件(属性、运算符、值)
谁会进入触发事件的用户,或事件负载中指定的用户
重复触发默认不允许,或允许并重启会话
并发每个用户一个活跃会话,或按 order_id / product_id 等会话属性区分出多个
设置
1 / 5
事件来源
可选项
SDK postEvent、REST API、默认 PW_* 事件、自定义事件、地理围栏进入或离开
设置
2 / 5
入口条件
可选项
可选:基于事件自身属性设置筛选条件(属性、运算符、值)
设置
3 / 5
谁会进入
可选项
触发事件的用户,或事件负载中指定的用户
设置
4 / 5
重复触发
可选项
默认不允许,或允许并重启会话
设置
5 / 5
并发
可选项
每个用户一个活跃会话,或按 order_id / product_id 等会话属性区分出多个

定时与周期入口按计划周期性重新检查分群。触发式入口则在事件发生的同一瞬间做出反应,而按用户并发运行多个会话意味着 3 笔在途订单可以各自驱动自己的状态旅程,而不是挤在同一个会话里互相干扰。把后续事件路由回其中正确的那一个会话,是等待触发元素的会话级匹配在画布下游负责的工作。完整的元素功能——条件筛选和重复触发控制都包含在内——在免费版即可使用。

对 Customer Journey Builder 意味着什么

一个 Customer Journey Builder 的好坏,很大程度上取决于它的入口方式。按分群周期性刷新覆盖的是定时节奏:邮件通讯、召回扫描。而构建器真正需要补上的,是在支付失败或购物车被放弃的那一刻立即做出反应的能力——这正是触发式入口交给Customer Journey Builder的能力。它读取的是画布其他部分早已用于分群和分支判断的同一份事件目录,因此打开这扇门的信号,和之后驱动整条流程的信号是同一个。

它把什么交给了下一步

一个 add_to_cart 事件触发,购物车挽回旅程随之启动。接下来的等待触发元素会给这位海外买家最长 90 天完成购买,超时则分支进入召回序列。这两个元素都不会自己发送任何消息——它们都把工作交给渠道节点,而入口元素决定的,是一开始谁走进了这条流程。

启动会话的事件,还能携带后续分支区分不同订单所需要的那个键,全部发生在同一块Customer Journey Builder画布上。

事件与旅程数据留在可以指名道姓的基础设施上

触发式入口读取的每一个事件,都运行在与平台其余部分相同的基础设施上:Pushwoosh 已通过 SOC 2 Type I 和 ISO 27001:2022 认证,符合 GDPR 要求,并在美国和德国自有硬件上运行,遵循 BDSG(德国联邦数据保护法),为出海企业触达欧美用户提供可核实的合规基础。完整信息见数据安全页面。

ISO 27001:2022 CertifiedISO 27001 CertifiedGDPR CompliantData Privacy FrameworkHIPAA CompliantSOC 2 Type I CertifiedOWASP Compliant

使用方法

  1. 添加入口元素

    在画布上添加一个触发式入口元素,选定事件:可以是默认的 PW_* 事件,也可以是通过 SDK postEvent 或服务端调用发送的自定义事件。

  2. 设置入口条件与目标用户

    为事件属性添加条件来限定入口资格,例如 add_to_cart 且 cart_value 大于 50,并选择是触发事件的人进入,还是事件负载中指定的用户进入。

  3. 设置重复触发与并发规则

    决定已经在旅程内的用户能否再次触发它,以及同一用户能否按 order_id 等属性同时持有多个会话。

搭建之前,须知以下几点。

  • Pushwoosh 不对外公布从事件到入口的延迟 SLA。产品定位是”实时”,而非一个具体的数字承诺。
  • 重复触发是元素本身的一个二选一开关:拦截新的触发,或重启会话。分级限制(每天一次、每周一次、每月一次)在旅程层面设置,不在这个元素上。
  • 这个元素需要背后有真实的事件流:SDK postEvent,或携带硬件 ID / User ID 的服务端 / API 调用。没有事件流时,入口会退回按计划或按分群启动。
  • 按计划启动通过同一画布上的另一个独立入口元素实现。
  • 完整的触发式入口功能——条件筛选和重复触发都包含在内——在免费版即可使用,最多支持 1,000 名用户。事件与旅程运行在 Pushwoosh 自有硬件上(美国和德国),遵循 GDPR 和 BDSG。SOC 2 Type I 认证。

把一个事件变成一场实时旅程。