Customer Journey Builder

可达性检查 + 渠道自动切换

消息发出前,检测 Push、邮件、短信、WhatsApp 或 LINE 能否触达海外用户——渠道关闭时,自动路由到下一个可用渠道。把多个检查串联起来,一个关闭的渠道就不再是旅程的终点。

Customer Journey 画布展示一个带可达与不可达分支的可达性检查元素,不可达分支接入第二个针对邮件的可达性检查

让消息无论如何都能送达

出海团队常踩的一个坑:把”渠道开着”当成了”消息已送达”。用户关掉了 Push,或者取消订阅了邮件列表,你搭好的消息压根没有落地。发送报告里看不出任何异常——活动照常跑完,发送量照样增加,只有这一个人从来没看到过。一条只走 Push 的交易风险提醒,遇到关闭 Push 的海外用户,等于没有发出去。一条只走 Push 的物流状态更新,遇到东南亚一位静音了通知的骑手,同样会被错过。可达性检查在消息发出前先做这层判断,把用户路由到另一个渠道,而不必你自己为每个海外市场手写一套渠道回退逻辑。

可达性检查能为出海团队做什么

5 个渠道

Push、邮件、短信、WhatsApp 和 LINE,逐一对照各渠道自己的订阅 Tag 检查——覆盖国内推送平台原生不支持的东南亚、日本等海外本地渠道。

2 条分支

可达和不可达,用户到达该元素的瞬间就做出判断。

可链式串联的回退链路

把不可达分支接入另一个渠道的检查:先 Push,再邮件,再短信,直到 WhatsApp 或 LINE 收尾。

读取一个订阅 Tag

Push(Push Alerts Enabled)和邮件(Unsubscribed Email)已确认。这是一个订阅 Tag,不是实时送达信号。

应用内消息在检查范围之外

不属于这 5 个被检查的渠道。应用内消息通常用来收尾整条回退链路,因为它能触达任何打开 App 的人。

没有文档记录的链路上限

文档里没有对可以串联多少次检查设置上限。

什么情况算可达

5 个渠道中,只有 2 个公开了”不可达”的具体判定逻辑,其余的 Tag 判断逻辑尚未公开。

渠道检查的 Tag不可达的判定条件
PushPush Alerts EnabledTag 为 false
邮件Unsubscribed EmailTag 为 true
短信、WhatsApp、LINE未公开未公开
渠道
1 / 3
Push
检查的 Tag
Push Alerts Enabled
不可达的判定条件
Tag 为 false
渠道
2 / 3
邮件
检查的 Tag
Unsubscribed Email
不可达的判定条件
Tag 为 true
渠道
3 / 3
短信、WhatsApp、LINE
检查的 Tag
未公开
不可达的判定条件
未公开

这是一个订阅 Tag,不是正在发生的实时送达尝试。被判定为可达的用户,仍然可能在链路更靠后的位置错过消息——设备离线,或者到发送那一刻 App 已经被卸载。这个元素比通用条件节点多给你的,是分支本身:一个专门搭建好的可达/不可达分支,直接拖到画布上串联起来,而不必自己把通用条件或等待步骤手动接到订阅数据上。

把检查串成一条回退链路

把 Push 检查的不可达分支接入邮件检查,再把邮件检查的不可达分支接入短信或 WhatsApp 检查。每一步都把范围缩小到上一个渠道没能触达的人,直到消息送达,或者把能试的渠道——包括国内推送平台原生不覆盖的 WhatsApp 和 LINE——都试完为止。

用应用内消息收尾整条链路

应用内消息不属于这个元素检查的 5 个渠道,但它是最常见的最后一站。一条应用内消息能触达任何打开 App 的人,不论其在其他每个渠道上的订阅状态如何。

什么样的旅程才算全渠道

全渠道不只是在设置里列出 5 个渠道那么简单,而是旅程能不能逐人判断某个渠道什么时候关闭,在静默失败之前就做出反应。可达性检查正是用户旅程编排拥有这种能力的原因:绕开一个关闭的渠道,而不是仅仅罗列你拥有哪些渠道。

它在哪里最能发挥价值

关键预警类回退链路

欺诈预警、预约提醒、故障通知路由到当前开放的渠道——这类消息不能悄悄地不发出去,尤其是同时覆盖多个海外监管环境的金融科技出海场景。

时效性状态更新

跨境电商和出海本地生活应用中,订单和配送状态更新在 Push 关闭的瞬间自动回退到短信或 WhatsApp,覆盖东南亚、中东等 WhatsApp 使用率更高的市场。

交易类确认消息

订单确认回退到邮件,避免一条被错过的 Push 变成一张工单——对跨境电商大促(双十一、黑五)节点尤其关键。

  • 跨境电商 / 零售出海
  • 出海游戏
  • 金融科技出海
  • 出海本地生活 / 出行
  • 出海市场平台
  • 跨境医疗健康
  • 订阅制 / 创作者出海应用

被它保护的渠道之一

为它要回退的渠道量身搭建

一条回退链路的效果,取决于它背后的渠道:Push 通知作为首选,电子邮件作为回退,短信WhatsApp负责收尾——WhatsApp 和 LINE 恰好覆盖了东南亚、日本等海外用户真正在用、而国内推送生态原生不触达的渠道。

条件分支看起来相似:一个节点,两条或以上分支,评估一次。区别在于它读取什么:已经在用户画像上的 Segment、Tag 或 Event attribute 取值,而不是某个渠道是否开放。两者都在用户旅程编排内部,和其他所有流程控制元素共享同一块画布。

背后的数据留在可以指名道姓的基础设施上

可达性检查读取的订阅 Tag,运行在与平台其余部分相同的基础设施上:Pushwoosh 在美国和德国使用自有硬件,遵循 GDPR 和 BDSG(德国联邦数据保护法),为出海企业触达欧美用户提供可核实的合规基础。完整信息见数据安全页面。

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

使用方法

  1. 放在原本要选渠道的位置

    把可达性检查拖到画布上,消息即将通过某个特定渠道发出的那个节点。

  2. 选择要检查的渠道

    选择 Push、邮件、短信、WhatsApp 或 LINE。元素读取该渠道自己的订阅 Tag,拆分成 2 条分支:可达和不可达。

  3. 为两条分支分别接线

    可达分支直接接入该渠道的发送步骤。把不可达分支接入另一个渠道的可达性检查,或者接入应用内消息作为兜底。

有几点需要留意

围绕它搭建回退链路之前,须知以下几点。

  • 检查的是一个订阅 Tag,不是正在发生的实时送达尝试。可达只代表 Tag 是这么说的,不代表消息已经到达。
  • 具体的 Tag 只对 Push 和邮件公开。短信、WhatsApp 和 LINE 没有公开到同等细节。
  • 文档里没有对可以串联多少次检查设置上限。
  • 应用内消息不属于这 5 个被检查的渠道,它通常用来收尾一条链路,而不是嵌在链路中间。
  • 这个元素专门检查渠道是否开放。如果要基于用户画像上已有的 Segment、Tag 或 Event attribute 取值路由,请改用条件分支

常见问题

无论哪个渠道开放,都能触达用户

为消息可能用到的每个渠道串联一个可达性检查,别再把一个关闭的渠道当成死胡同。