默认简化 + 高级保留 + 场景化引导
新建分群时只默认展示标签、联系方式、联系人组、邮件/短信行为等核心能力；交易、商品、历史字段、自定义字段和复杂事件收进高级入口；历史分群继续可回显、可复制、可重新计算。
Customer operations · segmentation
DMTX 用户分群功能优化方案
基于 3000 条分群定义、旅程执行记录和条件字典，判断分群条件长尾是否明显，并给出“默认入口简化、高级条件保留、邮件/短信行为场景化”的产品与技术落地方案。
Executive decision
结论不是删除，而是入口治理
低频长尾真实存在，但很多条件是客户自定义字段或历史兼容字段；直接删除会破坏历史分群、旅程分支和客户个性化能力。
Data evidence
本次分析的数据依据
本次只使用脱敏 MySQL 导出数据，不需要联系人邮箱、手机号、OpenID 等 PII 明细。
3000分群定义记录
2985有条件 JSON 的分群
4740解析出的条件规则
1455非空旅程条件分支
| 导出文件 | 行数 | 分析用途 |
|---|---|---|
contact_filter.xlsx | 3000 | 分群定义与 condition_json，是低频条件统计主来源。 |
condition_json.xlsx | 105 | 条件与 operator 字典，用于解释操作符。 |
swarm_contact_statistic.xlsx | 3000 | 分群计算结果、最近计算时间、人数规模。 |
task_instantiation.xlsx | 3000 | 旅程任务实例，解析旅程条件分支。 |
journey_task_filter_data_record.xlsx | 3000 | 旅程筛选执行耗时与结果。 |
journey_controller_union_data_record.xlsx | 3000 | 控件 union 执行耗时，用于观察成本与慢任务。 |
Condition governance
条件分层与保留策略
将“条件是否存在”与“条件默认是否展示”拆开治理，避免用删除解决复杂度问题。
| 分层 | 判断口径 | 条件数量 | 产品动作 |
|---|---|---|---|
| 核心条件 | 90 天内使用、客户数 ≥ 10、使用次数 ≥ 10 | 3 | 默认展示，作为场景入口基础。 |
| 观察条件 | 命中 1 项低频标准 | 7 | 保留，可放在常用条件下半区或更多条件。 |
| 疑似低频 | 命中 2 项低频标准 | 41 | 默认收起，进入更多条件/高级条件。 |
| 强低频 | 90 天未使用 + 客户数 < 10 + 使用次数 < 10 | 234 | 默认隐藏，仅高级入口或历史兼容展示。 |
默认展示
- 标签：属于、不属于、等于标签。
- 联系方式：邮箱、手机号是否存在或匹配。
- 联系人组：属于或不属于联系人组。
- 邮件/短信行为：打开、点击、发送、退订相关场景。
高级保留
- 交易与商品条件：整体使用低，移出默认入口。
- 客户自定义字段：按客户内使用频率排序，而不是全局删除。
- 历史 unknown 字段：作为历史字段兜底回显。
- 复杂事件：保留给实施、客服和高级运营人员。
Behavior scenarios
邮件/短信行为不能砍，应场景化
核心业务方向是“分群下发后，根据历史邮件/短信行为判断是否继续触发”。行为条件低频不代表不重要。
邮件行为建议场景
- 最近 N 天打开过邮件。
- 最近 N 天未打开邮件。
- 最近 N 天点击过邮件。
- 最近 N 天发送后未打开。
- 排除退订、硬退、软退联系人。
短信行为建议场景
- 最近 N 天发送过短信。
- 最近 N 天未发送短信。
- 最近 N 天点击过短信链接。
- 最近 N 天未点击短信链接。
- 排除短信退订联系人。
Guided segmentation
第一期固化 5 个运营场景
用场景入口覆盖 80% 日常需求，把自由拼条件留给高级用户。
标签人群触达
选择标签、包含/排除、联系方式要求，预估人数后保存或进入旅程。
邮件未响应二次触达
选择历史邮件任务，筛选未打开、未点击、已打开未点击人群。
短信触达后跟进
按短信发送、点击、未点击行为生成继续触达人群。
旅程参与状态筛选
筛选已参与/未参与某旅程或活动的人群，并叠加标签。
高级自定义筛选
给实施、客服和高级运营使用自定义字段、交易、商品和复杂事件。
Cost & performance
成本优化要看慢任务，而不只是条件数量
当前样本里大部分任务中位数耗时较低，但 P95/P99 和极端慢任务仍值得治理。
| 执行类型 | 平均 | 中位数 | P90 | P95 | P99 | 最大 |
|---|---|---|---|---|---|---|
| 旅程筛选 | 16.18 秒 | 2 秒 | 44 秒 | 73 秒 | 185 秒 | 4717 秒 |
| 控件 union | 9.08 秒 | 2 秒 | 15 秒 | 43 秒 | 141 秒 | 430 秒 |
如果目标是降本，第一优先级不是删除条件字典，而是识别 emailController、contactController、decisionController 中的 P95/P99 慢任务，并结合条件复杂度、数据量、索引命中和重复计算做专项优化。
Execution roadmap
分阶段落地
先用 UI 治理降低复杂度，再用数据治理长期闭环。
0
数据补全（1 周）：补全全量或近 180 天分群、非空旅程模板条件、邮件/短信行为表，生成更可靠的条件分层表。
1
默认入口简化（1-2 周）：上线常用条件、更多条件、高级条件分层，不删除底层能力。
2
场景化 MVP（2-3 周）：先实现标签人群、邮件未响应、短信跟进三个向导。
3
性能治理（2-4 周）：分析慢任务、增加条件成本提示、优化重复计算和索引命中。
4
后台治理（后续）：沉淀条件使用统计、展示策略配置、自动低频提醒和历史字段治理。
Final recommendation
最终建议
本方案的核心是“能简化，但不删除底层能力”。
归一后的 285 类条件中，234 类符合强低频标准，说明条件长尾明显。但其中大量属于客户自定义字段和历史兼容字段，不建议直接删除。建议采用「默认简化 + 高级保留 + 场景化引导」方案，先降低新建分群的操作复杂度，再结合 P95/P99 慢任务做计算成本优化。