Advanced Segmentation in Data 360 | 高级细分与受众收窄

一、将细分类型匹配到您的用例

为什么细分类型很重要

认识 Northern Trail Outfitters（NTO），一家拥有忠诚度计划和庞大客户群的户外零售公司。NTO 已经在 Data 360 中构建细分，现在正筹划一场春季活动，提供三种优惠：25% 折扣、15% 折扣和 10% 折扣。目标：每位客户只收到一个优惠——他们符合条件的最佳优惠，没有重复、没有混淆。

但仅靠标准细分并不能保证这一点。一个客户可能同时符合多个细分条件，从而收到多封邮件。为了实现「每位客户一个优惠」，NTO 的技术营销人员 Michele Hansley 需要选择正确的细分类型。

细分类型控制着细分如何运行、多久发布一次、以及能做什么；激活目标（activation target）则是细分成员的去向。并非每种类型都适合每个用例，也并非每种类型都能发布到每个目标。前期把这些选择做对，可以避免日后返工。

细分类型

Data 360 提供四种细分类型，分别满足不同的业务需求：

标准（Standard）——默认类型；按计划批量细分；支持全部精细化杠杆；可发布到所有激活目标；
瀑布（Waterfall）——从现有细分（最多 20 个）构建互斥的优先级分组；从上到下评估，匹配即停止；要求相同的 Segment On；不支持快速发布；
动态（Dynamic）——按需、API 驱动的受众；过滤值以参数形式存储；无持久化成员；无法从 UI 排程；
实时（Real-Time）——在实时数据图谱上毫秒级评估；无排除条件、无嵌套细分、无细分计数；无手动发布。

四种类型构成了从批量到实时的光谱。下面逐一详细说明。

标准（Standard）

标准细分是默认类型。您在一个数据模型对象（DMO）上构建它，设置回顾窗口，定义包含/排除条件。标准细分可以按计划发布（如每 12 或 24 小时一次）或手动发布，支持全套精细化杠杆，并能发布到所有支持的激活目标类型。

NTO 从这里开始：Michele 的团队为春季活动构建了三个标准细分——高价值客户（25% 折扣）、新客户（15% 折扣）、全部活跃客户（10% 折扣）。

但问题在于：一个客户可能符合多个细分条件，最终收到多封优惠邮件。标准细分本身不强制互斥——这正是瀑布细分要解决的问题。

瀑布（Waterfall）

把瀑布细分想象成演唱会上的优先级队伍。您给它一份现有细分列表（最多 20 个），按优先级顺序排列。Data 360 从上到下评估每个客户，一旦匹配就停止——每个客户最终落入恰好一个桶中。

NTO 把「高价值客户」放第一、「新客户」第二、「全部活跃客户」第三。一个高价值的新客户在第一步就匹配，只获得 25% 的优惠，跳过第二、三步。

约束：瀑布中的所有细分必须共享相同的 Segment On 实体且都处于活跃状态；不能包含嵌套细分；也不支持快速发布（Rapid Publish）。

瀑布 = 让互斥变得简单。

动态（Dynamic）

当过滤值每次都变化时，用动态细分。动态细分使用与标准细分相同的过滤器，但把过滤值存储为参数（parameters，即变量）。

例如，NTO 的应用团队想包含「这个地区的徒步者」或「购买了这个品类的客户」，而地区或品类每次都不同。与其编辑细分把「Region equals West」改成「Region equals East」，不如让外部服务调用 API 并传入参数值。

关键特征：

细分定义保持不变，受众随每次 API 调用而变化；
无持久化成员——每次运行相互独立；
无法从 UI 排程——按 API 需求运行。

动态细分非常适合「上下文随每个用户而变化」的个性化应用体验。

实时（Real-Time）

实时细分按需评估，并在毫秒级内完成。它构建在实时数据图谱上，而非批量 DMO。

NTO 用例：网站上的次优行动（next-best action）——当客户访问某个产品页面时，实时评估应展示哪个促销，依据其当前行为。

约束：

无排除条件；
无嵌套批量细分；
无细分计数；
无手动发布——评估在实时数据图谱中按需进行。

当决策必须在当下做出时（网站个性化、应用内优惠、呼叫中心次优行动），使用实时细分。

回顾：何时使用哪种细分

快速参考：

标准（Standard）：计划批量受众、全套精细化、支持所有激活目标；
瀑布（Waterfall）：来自现有细分的互斥优先级分组、要求相同 Segment On；
动态（Dynamic）：按需、API 驱动的受众、无持久化成员、参数化过滤值；
实时（Real-Time）：实时数据图谱上的毫秒级评估、无批量发布。

有了正确的细分类型，NTO 的春季活动就不再冒着发送重复优惠的风险：高价值客户只收到一封邮件而非三封，应用团队也能提供个性化内容而无需每次都修改细分定义。

激活目标类型

把激活目标想象成一个目的地（如家庭住址）。但有了地址并不代表包裹会自动送达。要让数据动起来，需要一次激活（activation，即您的配送订单）来告诉 Data 360 包含哪些属性；而发布（publishing）是最后一步，即包裹真正发货。

Data 360 支持这些目标类型：

Data 360（Audience DMO）；
Marketing Cloud Engagement（MCE）；
B2C Commerce；
云文件存储（Amazon S3、SFTP、Google Cloud Storage、Microsoft Azure）；
Marketing Cloud Personalization；
外部激活平台（Google Ads、Meta 或 AgentExchange 合作伙伴）；
Data 360 Loyalty。

发布兼容性：标准细分可发布到所有目标类型；快速发布（1 小时或 4 小时）仅支持 MCE 和云文件存储；瀑布细分只用标准发布但支持所有目标类型；动态细分通过 API 运行；实时细分在实时数据图谱中按需评估。

Segment On：选择正确的基础对象

Segment On 是您构建细分所基于的 DMO。它控制着哪些属性出现、以及细分在哪个层级运作。

Unified Individual（统一个人）：配置了身份解析、希望跨来源识别同一个人时使用。NTO 春季活动用它；
Individual（个人）：不配置身份解析时使用，可能导致重复或遗漏实体；
Unified Household（统一家庭）：把统一个人归组到家庭。NTO 的 Family Adventure 促销用它；
Account（账户）：B2B 场景，按收入、行业或相关数据定位账户；
Unified Account（统一账户）：B2B 配身份解析，跨来源识别同一账户；
其他 Profile/Engagement DMO：取决于数据模型，可基于其他标记为 Profile 或 Engagement 类型的对象细分。

把这三项选对——细分类型、激活目标、Segment On——其余细分就建立在一个稳固的基础之上。

接下来是什么

NTO 的计划已就位：

为春季活动优惠（25%、15%、10%）构建三个标准细分；
一个瀑布细分实现互斥，让每位客户只得到一个优惠；
一个动态细分供应用团队做参数化受众；
MCE 和 S3 作为邮件与分析用的激活目标；
Unified Individual 作为 Segment On。

除了 Family Adventure 促销，Michele 还想为 NTO 最活跃的客户规划一个 Surprise and Delight 礼品计划。但有 50,000 人符合春季活动条件，而 NTO 只能给 2,000 人送礼。NTO 该如何收窄？这将在下一单元讲解。

二、用容器和 Group、Rank、Limit 收窄受众

为什么精细化很重要

Michele 已经设置好了细分类型、激活目标和 Segment On。现在 NTO 面临新挑战：春季活动符合条件的有 50,000 人，但 Surprise and Delight 礼品只能发给 2,000 人。团队该选谁？又如何把这 2,000 人分散到各地区，避免某个城市独占全部名额？

过滤条件告诉您哪些记录满足条件；容器和聚合用相关数据进一步收窄；但有时还需要一步：在所有符合条件的记录中，每组有多少人能进入？这就是 Group、Rank、Limit（GRL） 的用武之地。

把它想成两个阶段：先决定谁符合条件，再决定谁入选、每桶多少名额。

容器和聚合作为精细化杠杆

您用容器（containers）把条件作用域限定到相关数据——例如 Sales Order 对象——并在该对象上设置条件。容器上的聚合（aggregation）（count、sum、average、max、min）基于汇总来判定记录是否符合条件。

NTO 从一个 Include 过滤开始：「过去 90 天内购买过」。团队又在 Sales Order 上加了一个订单数大于等于 1 的容器，把范围收窄到在该窗口内至少买过一次的每个人。

仅靠 Sales Order 上的这一个容器，NTO 就过滤掉了近期没有购买的人——这一步切掉噪声，让活动聚焦于活跃客户。没有 GRL，全部 50,000 人都会进入细分；有了 GRL 收窄范围，Michele 就能选出正确的 2,000 人并把他们分散到各个地域。

什么是 Group、Rank 和 Limit？

GRL 在 Include 和 Exclude 条件之后运行。它不改变哪些记录符合条件，只作用于已经通过那些条件的记录。您在 Rank and Limit 标签页中分三步配置 GRL：

Group（分组）：选择一个属性来捆绑记录，例如 City 或 Region。同一组中的所有记录共享该值。NTO 按 region 分组，把礼品分散到各地域，而非只从某个地区取前 2,000；
Rank（排序）：在每个组内，按另一个属性（如 engagement score）降序排列记录，设定优先级——谁在该地区最先获得礼品。NTO 按忠诚度互动分数排名，让每地区最活跃的客户排到前面；
Limit（限制）：设定每组有多少记录入选，例如每地区前 5 名。400 个地区乘以 5 就是最多 2,000 条记录（若某些地区不足 5 名，总数会相应减少）。Limit 就是上限。

GRL 只作用于符合条件的群体。先把「符合条件」这一步做对，Michele 再用它进一步精挑 NTO 的 Surprise and Delight 人选。

在哪里配置 Group、Rank 和 Limit

打开细分画布上的 Rank and Limit 标签页。Data 360 会自动创建第一个容器并将其锁定到您的主实体。拖动属性并设置 Group By、Sort By 或 Maximum Records。

您可以添加更多规则集来构建多层，例如「每位负责人名下前 10 个账户，再在每个账户下前 2 个联系人」。每个规则集最多可有三个分组规则和三个排序规则，且每个规则集都必须包含一个 limit 规则。

先构建并保存 Include 和 Exclude 条件，再打开 Rank and Limit 添加规则。若之后修改了「符合条件」的逻辑，GRL 会自动在新符合条件的集合上运行。

何时使用 Group、Rank 和 Limit

当您需要一个有限的、按优先级排序的每组人选时，使用 GRL。NTO 用它做 Surprise and Delight：该计划面向每地区前 5 名客户，按互动度排名，从而把 2,000 份礼品分散到各城市，而不是全发到一个地方。

其他 B2B 用例包括：定位每个账户前 2 个联系人（避免给公司的每个人都发邮件），或用 limit 1 为每位客户个性化定制一份优惠。

如果不需要上限或优先级，就跳过 GRL，让所有符合条件的人都进入细分。

需要注意的约束：

GRL 仅适用于 profile DMO 上的细分；
只能用直接属性和可聚合的计算洞察来做分组、排序和限制；
GRL 不支持实时、快速或动态细分；
对瀑布细分，只在子细分上使用 GRL。

通过按地区分组、按互动度排序、每地区限制 5 名，NTO 把 50,000 人的名单变成了 2,000 人的礼品计划，在每座城市都显得贴心——没有地区被遗漏，预算也守得住。

如何协同工作

把这当成一整套工具箱。NTO 用 Include 过滤和「订单数至少 1」的 Sales Order 容器来定义谁符合条件；再加 GRL：按地区分组、按互动度排序、每地区限 5 名。这样就创建了一个相关且可控的、大约 2,000 名 Surprise and Delight 收件人的细分，遍布全国。

但 Michele 的工作才刚刚开始。在下一单元，您将帮 NTO 在没有精确关键词的情况下找到对「远足和露营」感兴趣的客户、优先忠诚度会员，并确保每个细分都尊重邮件同意偏好。

三、用高级杠杆精细化细分

层级聚合（B2B）

企业对企业（B2B）客户在 Data 360 中使用层级聚合。当您在 Account 或 Unified Account 上构建细分并添加一个支持聚合的相关属性时，Data 360 会在容器上显示一个 Hierarchical Aggregation 选项。

启用后，Data 360 会把子账户的数据汇总到父账户——不再是「这个账户的收入」，而是「这个账户加上它所有子公司的收入」。

用它来定位「合并商机价值达到阈值」的父账户，或在「层级中任一实体有高优先级未结案例」时排除整个层级。再加一个「父账户无值」的过滤器，可只限制到顶层父账户。

NTO 是 B2C 企业，本活动不用层级；但如果您的 org 做基于账户的营销（ABM），这就是跨父/子账户看清全貌的方式。

基于统一家庭的细分（B2C）

NTO 正在构建 Family Adventure 促销。团队创建了一个 Segment On 设为 Unified Household 的细分，并添加以下条件：

至少两名家庭成员；
过去一年家庭总消费超过 $500。

结果针对家庭而非个人。如果需要，还可以结合 GRL 来限制每个地区的家庭数量。

当活动目标是家庭层级时，选择 Unified Household 作为 Segment On。这与账户层级同理：您是在用家庭级数据（而非单一记录）来收窄。

向量过滤器（Beta）

Michelle 想为春季目录找到对「远足和露营」感兴趣的客户。问题在于：客户兴趣数据很乱——有的记录写「越野跑鞋」，有的写「露营装备」，精确关键词过滤会漏掉这些变体。Michelle 知道可以用向量过滤器来找到这些相似受众。

“Is Similar To” 操作符使用自然语言处理，找出内容与参考值语义相似的记录。Michelle 在产品兴趣上加一个向量过滤器：Is Similar To「远足和露营」。关于越野跑鞋或露营装备的记录即使客户没用到这些精确词也会符合条件。

向量过滤器可加到 Include 或 Exclude 标签页（每个标签页最多 50 个过滤器），作用于直接属性和相关属性，还能查看返回的相似值数量及其预览。

细分中的计算洞察

NTO 的 org 里有一个 Engagement Score 计算洞察，由过去 12 个月的邮件打开、点击和购买频率构建。NTO 想把 Surprise and Delight 礼品给到最活跃的忠诚度会员，让这份心意落在最值得的地方。

团队把 Engagement Score 加到 Include 标签页（例如 Engagement Score 高于 75），并在 Rank and Limit 标签页里用这个分数做地区内的排序。大部分计算在细分之外完成，细分只消费其结果。

请检查属性库中已处理好的计算洞察——当数据模型支持时它们会显示出来。

细分中的同意（Consent）

在 NTO 发送任何东西之前，都必须尊重邮件偏好。NTO 添加一个 Include 过滤「Email Opt-In 等于 true」，让春季活动和 Surprise and Delight 细分只触达同意接收邮件的人；再添加一个 Exclude 过滤「Promotions Opt-Out 等于 true」。

同意属性可以来自您的 CRM、偏好中心或隐私数据模型。把它们像其他属性一样加到 Include 或 Exclude。把同意过滤想成门口的门卫：无论一个人多符合条件，没有正确的通行证就进不来。

有了 opt-in 和 opt-out 过滤，NTO 知道发出的每一封邮件都到达了想要它的人手中——既保护品牌，又保持高送达率。

嵌套细分

NTO 在单元一为瀑布构建了一个 High-Value Customers 细分。现在团队需要为春季活动邮件用同样的受众，但还要加上同意过滤。与其从头重建同样的过滤逻辑，团队嵌套了现有细分。

他们创建一个父细分 Spring Campaign Email，只包含 High-Value 子细分中的记录，并加上上面的同意过滤。这样父细分把 High-Value 成员资格与同意结合在一处，日后对 High-Value 定义的任何改动都会自动延续。

嵌套细分时，父和子必须使用相同的 Segment On。选择以下发布行为之一：

Last Published Membership：复用子细分上次发布的快照，性能更好；
Segment Criteria：把子的过滤器复制到父，适合子频繁变化时。NTO 用 Segment Criteria，这样 High-Value 定义的任何更新都会在下一次运行时流入父细分。

约束：不能嵌套动态细分或处于错误/非活跃状态的细分；每个嵌套细分每个标签页最多 50 个过滤器（用 Segment Criteria 时，子的过滤器计入该上限）。

通过把 High-Value 嵌套进春季活动父细分，NTO 省下数小时手工劳动，并确保所有全局活动的过滤器保持一致。

接下来是什么

您已帮 NTO 细化了细分：容器和 GRL 收窄了 Surprise and Delight 礼品；向量过滤器找到远足兴趣客户；互动分数优先最活跃的忠诚度会员；同意让一切都合规；嵌套细分复用了 High-Value 定义。

在下一单元，您将帮 NTO 设置回顾窗口和发布计划，让这些细分正式上线。

四、管理细分的回顾窗口、计划和发布

为什么回顾窗口和计划很重要

NTO 构建好了春季活动细分，并用 GRL、向量过滤器、同意和嵌套逻辑做了精细化。现在是时候上线了。有两个设置控制细分何时及如何运行：回顾窗口（lookback window）和发布计划（publish schedule）。

回顾窗口定义 Data 360 在评估条件时回溯多远的数据；发布计划定义细分多久运行一次并把成员发送到激活目标。两者都会影响消耗（consumption）：更宽的回顾窗口意味着更多数据要处理，更频繁的计划意味着每天更多计算周期。选得太宽或太频繁会推高成本；选得太窄或太稀疏，细分会漏掉相关行为或在下次活动前就过时了。

把回顾窗口想象成报表上的日期过滤——它控制数据回溯多远；发布计划则是那份报表多久用新数字重跑一次。