Customer Journey Builder

按每位海外用户自己的日期,暂停旅程直到时机成熟

Time Delay 是 Customer Journey 画布上的等待步骤。可以让用户停留固定时长、直到某个时钟时间、直到某个日期、在每周固定时段,或者从用户画像中已有的日期开始计算偏移。之后每位出海用户都会按照自己的节奏进入下一步——不论他们身处哪个时区。

Customer Journey 画布,一个 Time Delay 元素被放置在入口节点和消息节点之间

等待步骤能为出海团队做什么

固定时长

两步之间等待若干分钟、小时或天,最长 30 天。

指定时间

按用户本地时区,等待到某个时钟时间。

单次日期

等待到设定的某个日期和时间,然后放行用户。

每周固定时段

按你选择的星期几和时间,形成每周循环的等待。

基于用户数据

从标签、事件属性或 Webhook 返回值中读取日期,据此计算等待时长。

过去日期分支

让日期已经过去的用户,走一条专属于他们的独立路径。

五种等待方式

将该元素拖放到画布上任意两步之间,选择一种模式。每种模式都会独立完成等待,并将用户放行到下一步。

模式等待如何结束典型场景
固定时长设定一段分钟、小时或天的时长,最长 30 天两条消息之间的冷却间隔
指定时间按用户本地时区的某个时钟时间。若当天该时间已过,则顺延到次日同一时间早间摘要、非工作时间静默
日期未来的某一个日期和时间,按用户时区解析锚定上线日或大促日的活动
每周固定时段按选定的星期几和时间循环出现的每周等待每周课程、每周报告
基于用户或事件数据从标签、事件属性或 Webhook 响应中读取的日期,叠加 Before / After / On 偏移续费、行程、预约、补货等倒计时场景
模式
1 / 5
固定时长
等待如何结束
设定一段分钟、小时或天的时长,最长 30 天
典型场景
两条消息之间的冷却间隔
模式
2 / 5
指定时间
等待如何结束
按用户本地时区的某个时钟时间。若当天该时间已过,则顺延到次日同一时间
典型场景
早间摘要、非工作时间静默
模式
3 / 5
日期
等待如何结束
未来的某一个日期和时间,按用户时区解析
典型场景
锚定上线日或大促日的活动
模式
4 / 5
每周固定时段
等待如何结束
按选定的星期几和时间循环出现的每周等待
典型场景
每周课程、每周报告
模式
5 / 5
基于用户或事件数据
等待如何结束
从标签、事件属性或 Webhook 响应中读取的日期,叠加 Before / After / On 偏移
典型场景
续费、行程、预约、补货等倒计时场景

前四种模式是为所有用户统一设置一次的时间规则。第五种则为每位用户单独读取不同的日期——这正是一条旅程能够替代一整套人工排期活动的关键所在。

从用户画像已有的日期开始倒计时

将该元素指向用户画像上的任意日期:一个 renewal_date 标签、某个事件的属性,或从 Webhook 响应映射来的字段。将偏移设为提前 3 天(Before)、延后 1 天(After)或当天(On),Pushwoosh 会在每位用户到达该节点的那一刻,为他单独计算等待时长。

一条旅程就能覆盖你的整个海外用户群,每个人按自己的时钟走。这些日期来自与其他活动共享的同一份用户画像与细分数据。

对跨境电商团队来说,同一个逻辑也适用于大促倒计时:把日期指向双十一或黑五的开售时间,让全球不同时区的用户在同一个当地时刻收到提醒。

决定日期已经过去时该怎么办

用户到达该节点时,目标日期可能已经过去,默认情况下该用户会离开旅程。打开分支开关后,元素会分出两条路径:未来(In the future)和过去(In the past)。

这样一来,因时区差异或延迟触发而”迟到”的海外用户也能获得自己的路径:一条更简短的消息,或转入另一条旅程。你可以把他们留在旅程中,自己决定他们最终落到哪里。

等待步骤最适合哪些场景

按日期锚定的提醒

续费、行程、预约、补货和服务日期,均按该用户画像上的日期计时。

序列内的冷却间隔

购物车提醒前等一小时,试用跟进前等一天,引导流程步骤之间等一周。

先等待,再兜底

给一个渠道留出触达时间,若用户未响应,再升级到另一个渠道。

只要一条旅程跑过两个节点以上,这个元素就能发挥作用;而当用户画像上带着真实、值得倒计时的日期时,它的价值最大。对出海团队而言,这类场景常见于:

  • 跨境电商
  • 出海游戏
  • 金融科技出海
  • 出行与旅游出海应用
  • 订阅制出海应用
  • 保险出海服务
  • 电信出海服务
  • 医疗健康出海应用

一个等待元素,任意入口,任意渠道

同一个元素在事件触发之后和定时进入之后表现完全一致,并且可以放在任意渠道节点之前:移动 Push、Web Push、应用内消息、邮件、短信、WhatsApp。

搭配可达性检查,等待就变成了一个兜底窗口:先等待 4 小时,再把没有收到 Push 的海外用户转入短信,全部在同一个全渠道编排中完成——无需为不同市场分别搭建流程。

用户画像数据留在我们自己的硬件上

动态等待需要从用户画像上读取日期,因此它读取的正是平台其他部分共用的同一份数据。Pushwoosh 在美国和德国运行在自有硬件上,遵循 GDPR 和 BDSG(德国联邦数据保护法),为出海企业触达欧美用户提供合规基础设施。完整信息见数据安全页面。

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

使用方法

  1. 在画布上放置元素

    Customer Journey Builder 中打开一条旅程,将 Time Delay 放置在需要分隔的两个节点之间。

  2. 选择模式

    设定固定时长、时钟时间、日期、星期几,或将元素指向标签、事件属性、Webhook 字段,并选择 Before、After 或 On 偏移。

  3. 处理迟到的用户

    打开过去/未来分支开关,让目标日期已经过去的用户走你为他们设计的分支,而不是直接离开旅程。

须知:等待步骤能做什么,不能做什么。

  • 固定时长最长 30 天。更长的周期需要使用日期模式或每周固定时段模式。
  • 如果目标日期已经过去,用户默认会退出旅程。过去/未来分支开关正是用来把他们留住的。
  • 动态延迟需要该日期真实存在于用户画像上。从未设置过的标签或属性,元素将无从计算。
  • 该元素只控制下一步何时执行,它不是限速器,也不是投递时间窗口。
  • 时钟时间和日期均按用户本地时区解析。我们不承诺精确到秒的投递时间。

常见问题