# DMTX 用户分群功能优化方案

> 版本：评审版  
> 日期：2026-06-02  
> 需求来源：内部产品与成本优化讨论  
> 适用系统：DMTX 客户分群、旅程自动化、邮件/短信行为触发  
> 目标用户：客户运营人员、实施/客服、产品与研发团队

## 1. 背景与目标

本次优化并非来自明确客户投诉，而是来自内部对「用户分群功能是否过于复杂、是否可以降低计算和维护成本」的判断。当前 DMTX 用户分群能力较强，条件类型多、自由度高，但客户运营人员未必充分使用所有条件。本方案重点判断：

1. 哪些分群条件使用频率极低，后续是否可以不再默认开放。
2. 是否能把高自由度分群逐步固化为几个运营场景，通过分步引导降低操作复杂度。
3. 是否可以借此减少复杂条件带来的计算成本和系统维护成本。

本方案基于后端源码、前端源码和 `sql_data` 中导出的 MySQL 数据进行分析，给出产品分层、低频条件处理、场景化引导和后续数据补充建议。

## 2. 核心结论

### 2.1 不建议直接删除条件

虽然导出数据中确实存在大量低频条件，但不建议直接删除底层能力。原因如下：

- 历史分群的 `condition_json` 仍需要回显、复制、编辑和重新计算。
- 很多低频字段是客户自定义字段，全局使用次数低不代表对该客户没有价值。
- 邮件/短信行为条件虽然在样本中整体不高频，但正好匹配「根据历史行为判断是否继续触发」的未来方向。
- 直接删除会影响旅程、历史分群、复制分群和子分群兼容。

推荐策略是：

> 默认入口简化，底层能力保留；高频/通用/场景条件默认展示，低频/历史/自定义条件收进「更多条件」或「高级条件」。

### 2.2 数据支持低频长尾判断

从 `contact_filter.condition_json` 中解析：

| 指标 | 数值 |
|---|---:|
| 分群记录数 | 3000 |
| 有 `condition_json` 的记录 | 2985 |
| JSON 解析失败 | 0 |
| 解析出的条件规则 | 4740 |
| 归一后的条件类型 | 285 |

按「最近 90 天未使用 / 使用客户数少于 10 / 使用次数少于 10」三项口径打分：

| 分层 | 条件数量 | 含义 |
|---|---:|---|
| 0 分 | 3 | 核心活跃条件 |
| 1 分 | 7 | 有一定使用价值，继续观察 |
| 2 分 | 41 | 疑似低频，需要产品判断 |
| 3 分 | 234 | 强低频候选 |

即：归一后的 285 类条件中，234 类同时满足三项低频标准，占比约 82%。这说明分群条件存在明显长尾，但不能把长尾等同于可删除。

## 3. 数据来源与分析方法

### 3.1 已分析导出表

| 文件 | 行数 | 用途 |
|---|---:|---|
| `contact_filter.xlsx` | 3000 | 分群定义，核心来源 |
| `condition_json.xlsx` | 105 | 条件/operator 字典 |
| `swarm_contact_statistic.xlsx` | 3000 | 分群计算结果与最近计算时间 |
| `task_instantiation.xlsx` | 3000 | 旅程任务实例，含部分条件分支 |
| `task_template.xlsx` | 3000 | 旅程任务模板，本批导出无条件分支内容 |
| `journey_task_filter_data_record.xlsx` | 3000 | 旅程筛选执行记录 |
| `journey_instantiation_controller_info.xlsx` | 3000 | 旅程控件执行信息 |
| `journey_controller_union_data_record.xlsx` | 3000 | 旅程控件 union 执行记录 |

### 3.2 条件归一方式

分析时将条件按以下维度归一：

```text
条件族 family + 字段 field + 操作符 operation
```

示例：

- `contact + label_ids + eq`
- `contact + email + exists`
- `event + dmd_open + gte`
- `sales + sale_create_date + absoluteTime`
- `goods + primary_category + in`

由于大量客户自定义字段带有客户/字段编号，例如 `company_1_780`、`research_direction_2_780`，这类字段在全局维度天然客户数少，需要在产品处理时单独判断。

### 3.3 低频判断规则

以 2026-06-02 为基准，最近 90 天 cutoff 为 2026-03-04。

| 规则 | 判断口径 |
|---|---|
| 最近 90 天无人使用 | 条件最新分群更新时间早于 2026-03-04 |
| 使用客户数少于 10 | 使用该条件的 `company_id` 数量 < 10 |
| 使用次数少于 10 | 条件规则出现次数 < 10 |

分层建议：

| 分层 | 标准 | 建议动作 |
|---|---|---|
| 核心条件 | 0 项命中 | 默认展示 |
| 观察条件 | 1 项命中 | 默认保留或放在常用条件下半区 |
| 疑似低频 | 2 项命中 | 收进更多条件/高级条件 |
| 强低频 | 3 项命中 | 默认隐藏，仅高级入口或历史兼容展示 |

## 4. 分群条件使用现状

### 4.1 按条件族统计

| 条件族 | 条件类型数 | 使用次数 | 强低频数 | 疑似低频数 | 判断 |
|---|---:|---:|---:|---:|---|
| contact | 164 | 4331 | 122 | 32 | 主力，但自定义字段长尾明显 |
| event | 28 | 167 | 25 | 3 | 行为条件低频，但业务方向重要 |
| unknown | 68 | 157 | 65 | 3 | 多为历史结构或旧字段 |
| sales | 14 | 58 | 11 | 3 | 整体低频 |
| goods | 11 | 27 | 11 | 0 | 整体低频 |

结论：

1. `contact` 条件是绝对主力。
2. `sales` / `goods` 条件使用量很低，可从默认入口移除。
3. `event` 条件虽然低频，但邮件/短信/旅程行为类条件具备场景化价值，不建议删除。
4. `unknown` 条件应优先进入历史兼容/高级入口。

### 4.2 核心高频条件

| 条件 | 操作符 | 使用次数 | 分群数 | 客户数 | 最近使用 | 建议 |
|---|---|---:|---:|---:|---|---|
| `label_ids` | `eq` | 1600 | 1427 | 31 | 2026-06-02 | 默认展示 |
| `email` | `eq` | 107 | 80 | 16 | 2026-04-20 | 默认展示 |
| `mobile` | `eq` | 48 | 27 | 10 | 2026-04-16 | 默认展示 |

这些条件满足高频、近期使用、客户覆盖相对较广，建议作为新建分群默认入口的核心能力。

### 4.3 建议保留的基础条件

这些条件虽然部分最近 90 天不活跃，但客户覆盖较广或属于基础分群能力：

| 条件 | 操作符 | 使用次数 | 客户数 | 建议 |
|---|---|---:|---:|---|
| `group_ids` | `eq` | 176 | 75 | 保留，基础联系人组能力 |
| `email` | `in` | 115 | 20 | 保留，批量名单匹配常用 |
| `email` | `exists` | 47 | 20 | 保留，基础联系方式判断 |
| `mobile` | `exists` | 45 | 13 | 保留，基础联系方式判断 |
| `email` | `eq` | 107 | 16 | 保留 |
| `mobile` | `eq` | 48 | 10 | 保留 |

## 5. 强低频条件处理建议

### 5.1 sales / goods 条件

典型低频项：

- `sale_create_date`
- `sale_total`
- `sale_id`
- `sale_status`
- `sale_client`
- `sale_sources`
- `good_id`
- `good_name`
- `primary_category`
- `secondary_category`

处理建议：

- 从默认条件面板移除。
- 放入「高级条件 > 历史交易/商品条件」。
- 新建分群时不主动推荐。
- 历史分群继续可回显、可计算。

### 5.2 客户自定义字段

典型低频项：

- `industry_471`
- `uploadid_710`
- `region1_652`
- `points_balance_780`
- `businessform2_780`
- `company_1_780`
- `research1_780`
- `purchasing_brand_780`
- `rfm_780`

处理建议：

- 不进入全局默认条件。
- 在该客户自己的「客户字段」分类下继续可选。
- 可以按客户内使用频率排序，而不是按全局使用频率排序。
- 对 180 天未使用的自定义字段，在 UI 中折叠到「更多客户字段」。

### 5.3 unknown 历史结构字段

典型低频项：

- `name_2`
- `age1_2`
- `shopcode_64`
- `brith_64`
- `PRICE_64`
- `date_2`
- `mobile_debook_date`
- `wen_ben1_0_2`
- `auth_person_id1_53`

处理建议：

- 默认不在新建入口展示。
- 历史分群详情中按原始字段名回显。
- 复制历史分群时允许继续使用。
- 如果字段字典已不存在，前端显示为「历史字段」，避免空白或报错。

## 6. 邮件 / 短信行为条件

用户描述的核心业务场景是：

> 通过分群下发，然后根据历史邮件行为、短信行为判断是否继续触发。

因此，邮件/短信条件即使低频，也不应简单砍掉，应改造成场景化入口。

### 6.1 邮件行为条件

| 条件 | 操作符 | 使用次数 | 客户数 | 最近使用 | 判断 |
|---|---|---:|---:|---|---|
| `dmd_open` | `gte` | 126 | 2 | 2024-07-03 | 使用次数高，客户数少，近期不活跃 |
| `dmd_open` | `belong` | 6 | 2 | 2022-06-27 | 强低频 |
| `dmd_click` | `gte` | 3 | 2 | 2024-08-26 | 强低频 |
| `dmd_sent` | `belong` | 3 | 1 | 2020-09-08 | 强低频 |

建议将邮件行为从「自由条件」升级为固定场景：

1. 最近 N 天打开过邮件。
2. 最近 N 天未打开邮件。
3. 最近 N 天点击过邮件。
4. 最近 N 天发送后未打开。
5. 最近 N 天发送后未点击。
6. 排除退订、硬退、软退联系人。

### 6.2 短信行为条件

| 条件 | 操作符 | 使用次数 | 最近使用 | 判断 |
|---|---|---:|---|---|
| `sms_send` | `eq` | 1 | 2026-05-29 | 近期有使用，但次数极低 |
| `sms_send` | `belong` | 2 | 2024-04-23 | 强低频 |

建议将短信行为做成场景化条件：

1. 最近 N 天发送过短信。
2. 最近 N 天未发送短信。
3. 最近 N 天点击过短信链接。
4. 最近 N 天未点击短信链接。
5. 排除短信退订联系人。

## 7. 旅程条件分支分析

`task_instantiation.condition_branch_base64` 中有 1455 条非空记录，解析出 865 条规则。旅程分支中最常见条件如下：

| 条件 | 使用次数 | 说明 |
|---|---:|---|
| `label_ids eq` | 171 | 标签判断 |
| `not_participation eq` | 150 | 未参与某旅程/活动 |
| `label_ids belong` | 142 | 标签归属 |
| `subscribe_follow_wx84700b1022c2cb3c eq` | 116 | 微信关注/订阅类 |
| `label_ids nbelong` | 73 | 不属于标签 |
| `Xiaomei_enter eq` | 35 | 小美进入事件 |
| `form_submit exists` | 35 | 表单提交 |
| `wx_click_menu exists` | 35 | 微信点击菜单 |
| `wx_reply_message exists` | 35 | 微信回复 |
| `wx_scan exists` | 35 | 微信扫码 |

旅程中真正突出的能力是：

1. 标签判断。
2. 是否参与/未参与。
3. 微信/表单类事件。
4. 少量自定义事件。

因此用户分群场景化时，可以和旅程条件保持一致，把「标签 + 参与状态 + 邮件/短信行为」作为主线。

## 8. 性能与成本观察

### 8.1 筛选执行耗时

`journey_task_filter_data_record`：

| 指标 | 秒 |
|---|---:|
| 平均 | 16.18 |
| 中位数 | 2 |
| P90 | 44 |
| P95 | 73 |
| P99 | 185 |
| 最大 | 4717 |

### 8.2 union 执行耗时

`journey_controller_union_data_record`：

| 指标 | 秒 |
|---|---:|
| 平均 | 9.08 |
| 中位数 | 2 |
| P90 | 15 |
| P95 | 43 |
| P99 | 141 |
| 最大 | 430 |

按控件类型：

| 控件类型 | 数量 | 平均秒 | 最大秒 |
|---|---:|---:|---:|
| `emailController` | 1049 | 13.79 | 430 |
| `decisionController` | 310 | 7.92 | 375 |
| `contactController` | 1157 | 7.40 | 348 |
| `mmsController` | 4 | 9.50 | 29 |
| `addTagController` | 212 | 5.36 | 68 |
| `smsController` | 174 | 2.57 | 17 |

结论：

- 当前导出范围内，大部分任务中位数耗时较低。
- 极端慢任务值得单独分析。
- 如果要从成本角度优化，不能只看条件数量，应重点关注 email/contact/decision 控件和 P95/P99 慢任务。

## 9. 推荐产品形态

### 9.1 新建分群默认入口

默认展示 4 组能力：

1. 标签人群。
2. 联系方式。
3. 联系人组。
4. 邮件/短信行为场景。

建议文案：

```text
选择你要圈选的人群
- 按标签圈选
- 按联系方式圈选
- 按联系人组圈选
- 按邮件/短信行为圈选
- 使用高级条件
```

### 9.2 条件面板分层

| 层级 | 展示内容 | 目标 |
|---|---|---|
| 常用条件 | 标签、联系方式、联系人组、邮件/短信行为 | 覆盖大多数运营场景 |
| 更多条件 | 基础资料、自定义字段、微信/表单事件 | 给有经验用户继续使用 |
| 高级条件 | sales/goods、历史字段、复杂事件 | 保留能力但降低默认干扰 |
| 历史兼容 | 已存在分群中的旧字段 | 避免历史数据不可用 |

### 9.3 场景化向导

建议第一期固化 5 个场景：

#### 场景一：标签人群触达

适用：按已有人群标签发送邮件/短信。

步骤：

1. 选择标签。
2. 选择包含/排除。
3. 选择联系方式要求。
4. 预估人数。
5. 保存分群或进入旅程。

#### 场景二：邮件未响应人群二次触达

适用：邮件发送后，对未打开/未点击用户继续短信或其他渠道触达。

步骤：

1. 选择历史邮件任务。
2. 选择行为：未打开、未点击、已打开未点击。
3. 设置时间范围。
4. 排除退订/退信联系人。
5. 生成分群并进入旅程。

#### 场景三：短信触达后继续跟进

适用：短信发送后，对点击/未点击用户分支处理。

步骤：

1. 选择短信任务。
2. 选择发送/点击/未点击行为。
3. 设置时间范围。
4. 排除短信退订联系人。
5. 保存为分群或作为旅程条件。

#### 场景四：旅程参与状态筛选

适用：筛选已参与/未参与某旅程或活动的人群。

步骤：

1. 选择旅程/活动。
2. 选择参与状态。
3. 可叠加标签或联系方式。
4. 预估人数。
5. 保存或继续触达。

#### 场景五：高级自定义筛选

适用：实施、客服或高级运营人员使用自定义字段、交易、商品、复杂事件组合。

步骤：

1. 进入高级条件。
2. 选择字段分类。
3. 配置条件组合。
4. 查看计算成本提示。
5. 保存并计算。

## 10. 研发实现建议

### 10.1 后端能力保持兼容

后端不应删除已有解析能力：

- `contact_filter.condition_json` 保持兼容。
- `contact_filter_operator` 字典保留历史 operator。
- 历史字段无法识别时，返回安全的占位展示信息。
- 复制分群、子分群、高级分群继续可用。

### 10.2 前端默认视图重构

前端可以逐步改造：

1. 在现有条件组件外层增加「场景选择」入口。
2. 默认只展示常用条件。
3. 增加「更多条件」折叠区。
4. 增加「高级条件」入口，需要用户主动展开。
5. 历史分群详情继续按原 JSON 回显。

### 10.3 条件配置增加展示策略

建议新增条件展示策略，而不是删除 operator：

| 字段 | 说明 |
|---|---|
| `visibility_level` | `default` / `more` / `advanced` / `history_only` |
| `scenario_tags` | `label` / `email_behavior` / `sms_behavior` / `journey` 等 |
| `last_used_at` | 最近使用时间 |
| `usage_count` | 使用次数 |
| `company_count` | 使用客户数 |
| `deprecated_reason` | 收起或不推荐原因 |

可以先离线生成配置，不必第一期做成完整后台。

## 11. 分阶段落地计划

| 阶段 | 周期 | 工作内容 | 产出 |
|---|---|---|---|
| 阶段 0：数据补全 | 1 周 | 补全全量 `contact_filter`、旅程模板条件、邮件/短信行为表 | 更可靠的条件分层表 |
| 阶段 1：默认入口简化 | 1-2 周 | 常用条件/更多条件/高级条件分层 | 操作复杂度下降 |
| 阶段 2：场景化 MVP | 2-3 周 | 标签、邮件未响应、短信跟进三个向导 | 运营人员按场景建分群 |
| 阶段 3：性能治理 | 2-4 周 | 慢任务分析、条件成本提示、计算优化 | 降低 P95/P99 成本 |
| 阶段 4：后台治理 | 后续 | 条件使用统计、展示策略配置、自动低频提醒 | 长期治理闭环 |

## 12. 风险与边界

| 风险 | 说明 | 应对 |
|---|---|---|
| 误删客户自定义字段 | 自定义字段全局低频但客户内重要 | 不删除，只收起 |
| 历史分群不可回显 | 旧字段字典缺失导致显示异常 | 增加历史字段兜底展示 |
| 邮件/短信行为被误判低频 | 当前样本不足且未来场景需要 | 保留并场景化 |
| 只简化 UI 不降成本 | 条件仍可被高级用户使用 | 同步做慢任务/P95 分析 |
| 运营人员找不到高级能力 | 默认收起后可发现性降低 | 明确「更多条件」「高级条件」入口和说明 |

## 13. 需要补充的数据

为了最终确认哪些条件可以从默认入口移除，建议补充：

1. 全量或近 180 天 `contact_filter`，不要只导 3000 条。
2. 非空的 `task_template.condition_branch`。
3. `dmd_journey_info_log` 邮件行为统计。
4. MySQL 中短信行为相关表，如包含：
   - `sms_send`
   - `sms_open`
   - `sms_click_link`
   - `sms_unsubscribe`
5. 公司维度脱敏映射：
   - `company_id`
   - 是否测试客户
   - 是否内部客户
   - 行业/客户类型，如有

## 14. 最终建议

本次分析足够支撑第一版产品策略：

> 用户分群不做能力删除，而做入口治理。默认只开放标签、联系方式、联系人组、邮件/短信行为等核心场景；交易、商品、历史字段、自定义字段和复杂事件收进高级入口；历史分群保持兼容。这样既能降低客户运营人员的操作复杂度，也能为后续计算成本治理留出空间。

正式结论如下：

> 归一后的 285 类条件中，234 类符合强低频标准，说明条件长尾明显。但其中大量属于客户自定义字段和历史兼容字段，不建议直接删除。建议采用「默认简化 + 高级保留 + 场景化引导」方案，先降低新建分群的操作复杂度，再结合 P95/P99 慢任务做计算成本优化。