用户走到这一步的瞬间，按已有画像数据分支

条件分支元素能为出海团队做什么

3 种条件类型有何不同

每个条件分支元素只检查一种类型的条件，对照用户当前画像，把用户送入命中的分支。检查只在用户到达该元素的那一刻执行一次。

Tag 和 Event attribute 的分支上限取决于每条分支背后的运算符。equals、in、contains 这类取值匹配型运算符可以达到完整的 10 条上限。not-equal、大于等于、exists 这类比较型运算符上限更低，因为基于其中之一搭建的一条分支，本身已经覆盖了大部分取值范围。

同一个元素不能混用条件类型，Segment、Tag 或事件也必须已经存在于账户中——该元素本身不会创建任何一种。它位于 Customer Journey Builder 内部，读取的是画布其他部分已经在用的同一批 Segment、Tag 和事件。

每一种配置都留有出口

无论配置 Segment、Tag 还是 Event attribute，「其他所有用户」都会默认随每个版本的元素一起出现，没有开关可以关闭它，也没有办法删除它。

某个用户的 Tag 取值不匹配你搭建的任何一条分支时，仍然会落在一条你能掌控的路径上，而不是直接离开旅程——这一点对覆盖多个海外市场、用户画像天然更分散的出海业务尤其重要。

把条件叠加在条件之上

一个元素只读取一种条件类型。想要「高价值订阅用户 且 高消费」，先放置一个 Segment 条件为高价值订阅的条件分支，再在已经命中该 Segment 的分支上，接入第二个 Tag 条件为消费等级的条件分支。

每个元素在画布上都保持简单易读，复合逻辑交由这条链路承载，而不是塞进一条本就拥挤的规则里——出海团队用同一套结构就能覆盖不同市场各自的分层规则。

这个元素最适合用在哪里

同一画布上的多个元素之一

条件分支只按画像上已有的数据路由。同一画布上的两个邻居各自负责不同的工作。等待触发元素会暂停并等待一个新事件发生。等待步骤只暂停一段固定时长，完全不涉及分支。

把条件分支放在入口之后，能在用户看到第一条消息之前，就按「这个人已经是谁」来路由——这也是出海团队处理跨市场用户画像差异最常用的第一步。

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

条件分支元素读取的 Segment、Tag 和事件属性，运行在与平台其余部分相同的基础设施上：Pushwoosh 已通过 SOC 2 Type I 和 ISO 27001:2022 认证，符合 GDPR，在美国和德国运行在自有硬件上，遵循 BDSG（德国联邦数据保护法），为出海企业触达欧美用户提供可核实的合规基础。完整信息见数据安全页面。

使用方法

常见问题

探索相关产品