业务模块

功能概述

模块分析 — 让"业务场景"成为你的监控对象

基调听云支持把任意已嵌码的 Web 站点或 MP（小程序）中，与业务强相关的 N 个页面一键聚合成一个「业务模块」。从此以后，监控不再按"技术堆栈"拆分，而是按"业务故事"展开：一个支付链路、一场营销活动、一套会员体系，都能被独立、完整地看见。

全景看板：一页讲清业务健康度

• 场景级指标：把"支付流程""618主会场""会员中心"等业务场景打包成模块，实时呈现 FCP、LCP、完全加载、慢页面占比、JS/接口错误率、UV/PV 等关键体验指标。
• 多维下钻：模块 → 子模块 → 单页 → 单次会话，4 级下钻，秒级定位是哪一步拖了后腿。

场景告警：不再被"单页噪音"淹没

• 阈值自定义：给每个业务模块单独设阈值，例如"支付场景 JS 错误率 > 2% 且持续 5 分钟""会员任务 慢页面占比 > 1%"即触发告警。
• 智能降噪：同类告警聚合到业务模块维度，避免单页级"告警风暴"。
• 通知到人：告警直接推送给对应业务 owner（飞书/钉钉/邮件/Webhook），并附带模块快照链接，一键直达问题现场。

核心价值

• 业务视角监控：从业务场景而非技术应用的角度看用户体验
• 跨应用分析：聚合多个应用的数据，统一监控完整业务体验
• 灵活组合：自定义规则，快速组合任意页面为业务模块

什么是业务模块

业务模块是按照业务逻辑从一个或多个同触点应用中选取相关页面组合而成的监控单元。

示例说明

业务场景	涉及应用	组合规则	业务价值
房产-新房	主站 Web + 移动站 Web	包含 /new-house/ 的所有页面	统一监控新房业务的用户体验
电商-支付流程	PC 站 Web + 移动站 Web	包含 /checkout/, /payment/ 的页面	了解支付流程的用户体验
金融-开户流程	微信小程序 + 支付宝小程序	匹配 /account/open/ 的所有步骤	优化开户流程的用户体验
教育-课程学习	主站 Web + 课程子站 Web	包含 /course/, /learn/	提升课程学习体验

技术要求

• 支持范围：RUM - Web 应用、MP（小程序）应用
• 嵌码要求：应用需已嵌入 MP JS 或 Web JS
• 数据聚合：支持单个触点内的多个应用数据聚合

重要限制：业务模块只能在单一触点内创建，例如只能选择 Web 触点下的多个应用，或只能选择 MP 触点下的多个应用，无法跨触点聚合（Web + MP 混合不支持）。

核心功能

1. 模块概览

模块概览展示所有业务模块的核心性能指标，支持快速对比和问题发现。

应用场景

1. 快速对比

• 横向对比各业务模块的性能表现
• 识别评分低或异常多的业务模块
• 评估不同业务线的用户体验差异

2. 问题预警

• 支持告警，快速发现异常模块
• 慢页面占比高的模块需优化
• JS 错误率高影响用户体验

3. 业务决策

• PV/UV 数据支撑流量分析
• 用户体验评分支撑资源分配
• 性能对比支撑业务优先级决策

2. 创建业务模块

业务模块创建支持灵活的规则配置，满足各种业务场景需求。

步骤一：添加模块名称

访问路径：轻应用 → 业务模块 → 右上角【添加模块】

命名建议

• 使用业务语言而非技术术语（如："新房业务" 而非 "new-house-app"）
• 清晰表达业务含义（如："支付流程"、"搜索功能"）
• 规范命名便于管理（如："电商-购物车"、"金融-开户"）

步骤二：选择数据集

功能说明

选择要聚合的应用数据源，支持：

• 数据类型（单选）：Web 应用、MP（小程序）应用
• 数据源（多选）：可选择一个或多个应用
• 跨应用聚合：实现完整业务链路的数据汇总

选择策略

场景	选择策略	示例
单应用业务	选择单个应用	仅在主站 Web 上的某个功能模块
多应用业务（Web触点）	选择同触点的多个 Web 应用	PC 主站 + 移动站 + 专题站（均为 Web）
多应用业务（MP触点）	选择同触点的多个小程序应用	微信小程序 + 支付宝小程序 + 百度小程序

重要限制

• 只能选择同一触点类型的应用
• Web 触点和 MP 触点不能混合选择

注意事项

• 仅显示已嵌码且有数据上报的应用
• 应用需要是 Web 或 MP 类型，不能同时选择 Web 应用和小程序应用
• 保存后即可配置聚合规则

步骤三：添加聚合规则

规则类型

业务模块支持三种 URL 匹配规则：

1. 包含规则

• 说明：URL 中包含指定字符串
• 示例：包含 /product/ 匹配所有商品相关页面
• 适用：简单场景，固定路径匹配

2. 正则表达式规则

使用 Java 正则表达式进行灵活匹配。

规则	说明	匹配示例
^/user/get.*	匹配以 /user/get 开头的路径	/user/getInfo/uid_1001 /user/getCard/cid_01
^/user/(get|set).*	匹配 get 或 set 操作	/user/getInfo/uid_1001 /user/setInfo/uid_1001
.*/product/[0-9]+$	匹配商品详情（数字ID）	/shop/product/12345 /mall/product/67890
^/(order|pay)/.*	匹配订单或支付相关页面	/order/detail/123 /pay/confirm/456

3. 通配符规则

使用通配符快速定义匹配模式。

通配符说明

通配符	描述	示例
?	匹配任何单字符	p?ttern 匹配 pattern、pXttern
*	匹配 0 或任意数量的字符	*.jsp 匹配所有 JSP 文件
**	匹配 0 或更多的目录	**/example 匹配任意路径下的 example

匹配示例

规则	匹配结果
mall.tingyun.com/app/*.x	匹配 mall.tingyun.com 域名下 app 路径的所有 .x 文件
127.0.0.1:8080/app/p?ttern	匹配 127.0.0.1:8080/app/pattern 和 127.0.0.1:8080/app/pXttern 不匹配 /app/pttern
*/**/example	匹配 mall.tingyun.com/app/example 127.0.0.1:8080/app/foo/example 127.0.0.1:8080/example
mall.tingyun.com/app/**/dir/file.*	匹配 mall.tingyun.com/app/dir/file.jsp mall.tingyun.com/app/foo/dir/file.html mall.tingyun.com/app/foo/bar/dir/file.pdf
**/*.jsp	匹配任何路径下的所有 .jsp 文件

步骤四：保存配置

保存成功后，系统开始采集和聚合数据：

• 打开嵌码应用，访问配置的业务场景
• 等待 5 分钟左右
• 业务模块开始展示数据

提示：规则配置后立即生效，但需要等待一定时间积累数据。

规则配置最佳实践

1. 规则设计原则

业务完整性

• 包含业务流程的所有关键页面
• 不遗漏核心转化路径
• 覆盖用户的完整体验路径

规则准确性

• 避免规则过于宽泛，匹配无关页面
• 避免规则过于严格，遗漏关键页面
• 测试验证规则的匹配效果

可维护性

• 使用清晰的规则注释
• 规则简洁易懂
• 便于后续调整和扩展

2. 常见业务场景配置

场景一：功能模块监控（Web 触点）

需求：监控搜索功能的体验（PC Web + 移动 Web，包含搜索框、搜索结果、筛选等页面）

配置示例

数据集：选择 Web 触点下的多个应用（PC站、移动站）
规则类型：正则表达式
规则：^/search/.*
说明：匹配所有搜索相关页面

场景二：业务流程监控（Web 触点）

需求：监控完整的下单流程（PC Web + 移动 Web，从购物车到支付成功）

配置示例

数据集：选择 Web 触点下的应用（PC站、移动站）
规则类型：正则表达式
规则：^/(cart|checkout|payment|order)/.*
说明：匹配购物车、结算、支付、订单页面

场景三：活动页面监控（MP 触点）

需求：监控双11活动的所有小程序活动页面

配置示例

数据集：选择 MP 触点下的小程序应用（微信、支付宝）
规则类型：正则表达式
规则：^/(activity|event)/2025-double-11/.*
说明：匹配2025双11活动页面

3. 规则调试技巧

验证规则正确性

1. 先小范围测试

• 配置规则后访问预期页面
• 检查是否正确匹配
• 确认后再扩大范围

2. 检查匹配数量

• 查看模块的 PV 数量
• 对比预期的流量
• 过多或过少都需调整

3. 排查遗漏页面

• 对比业务流程，逐一检查
• 查看原始应用的页面列表
• 补充遗漏的页面规则

常见问题处理

问题	原因	解决方案
规则不生效	语法错误、路径不匹配	检查正则表达式语法，确认 URL 格式
匹配页面过多	规则过于宽泛	收紧规则，增加限定条件
遗漏关键页面	规则过于严格	放宽规则，使用或条件组合
数据不准确	多个规则冲突	梳理规则，避免重复匹配

模块分析

功能说明

模块分析的分析功能与「终端应用」中的 Web 应用和 MP 应用一致

与应用分析的区别

数据范围

• 应用分析：单个应用的所有数据
• 模块分析：按规则筛选的业务数据（可跨多个应用）

分析视角

• 应用分析：技术视角，以应用为单位
• 模块分析：业务视角，以业务流程为单位

应用价值

• 应用分析：适合研发团队进行技术优化
• 模块分析：适合业务团队进行业务优化

分析方法

1. 业务健康度评估

• 查看模块评分，评估业务整体质量
• 对比不同业务模块的评分
• 识别需要优化的业务

2. 业务流程优化

• 按业务流程顺序查看各页面性能
• 识别流程中的性能瓶颈
• 优化转化率关键节点

3. 跨端体验对比

• 对比同业务不同端的性能
• 评估多端体验一致性
• 针对性优化体验差的端

对比流程

1. 为同业务创建不同触点的模块
   ↓ 如：搜索功能-Web（PC + 移动 Web）
   ↓ 搜索功能-MP（微信小程序 + 支付宝小程序）
   
2. 分别查看各触点性能指标
   ↓ 识别体验差的触点
   
3. 分析差异原因
   ↓ 技术实现、网络环境、平台特性
   
4. 制定一致性标准
   ↓ 各触点达到统一的性能标准

最佳实践

业务模块规划

规划原则

• 核心业务优先：优先创建核心转化流程的模块
• 合理粒度：不宜过粗（整个网站）或过细（单个按钮）
• 持续迭代：根据业务变化调整模块

推荐模块

业务类型	推荐页面	说明
电商	首页、搜索、商品详情、购物车、支付流程	覆盖用户购买全流程
金融	首页、开户、充值、交易、提现	覆盖资金流转全流程
内容	首页、分类、详情、播放、评论	覆盖内容消费全流程
本地生活	首页、搜索、店铺、下单、评价	覆盖服务消费全流程
企业服务	首页、产品、注册、试用、购买	覆盖客户转化全流程

常见问题 FAQ

Q1：一个页面可以属于多个业务模块吗？

A：可以。同一个页面可以被多个业务模块的规则匹配。

示例场景

• 页面：/product/12345
• 匹配模块1："商品详情"（规则：^/product/.*）
• 匹配模块2："双11活动"（规则：/product/.*\?activity=1111）

注意事项

• 数据不会重复计算，每个模块独立统计
• 合理设计规则，避免非预期的匹配
• 过多重复可能影响数据查询性能

Q2：业务模块和应用分析有什么区别？

A：两者的区别主要体现在分析视角和数据范围。

对比说明

维度	应用分析	业务模块分析
视角	技术视角	业务视角
范围	单个应用的全部数据	按规则筛选的业务数据
粒度	应用级	业务功能级
跨应用	不支持	支持跨多个应用聚合
使用者	研发、运维团队	业务、产品、运营团队
关注点	技术指标、代码问题	业务指标、用户体验

使用建议

• 研发团队：使用应用分析定位技术问题
• 业务团队：使用模块分析评估业务表现
• 协同优化：结合两者进行全面分析

Q3：如何验证规则配置是否正确？

A：通过以下方法验证：

1. 测试访问

• 配置规则后，访问预期匹配的页面
• 等待 5 分钟
• 查看模块是否有数据上报

2. 检查 PV 数量

• 对比模块 PV 与预期流量
• PV 过多：规则过于宽泛
• PV 过少：规则遗漏页面或过于严格

3. 查看页面列表

• 进入模块的页面分析
• 查看实际匹配的页面列表
• 确认是否符合业务预期

4. 逐步调试

• 先配置简单规则，验证基本功能
• 再逐步增加复杂规则
• 每次调整后都要验证

Q4：业务模块可以修改规则吗？

A：可以修改，但需注意数据连续性。

修改方法

1. 进入业务模块列表
2. 找到要修改的模块
3. 编辑规则配置
4. 保存生效

注意事项

• 规则修改后，新数据按新规则采集
• 历史数据仍按旧规则统计
• 规则变更会导致数据趋势出现断点

建议做法

• 重大规则调整：创建新模块，保留旧模块一段时间
• 小幅调整：直接修改，并记录变更时间
• 对比分析时：注意规则变更的时间节点

Q5：业务模块数据与应用数据不一致？

A：这是正常现象，原因如下：

数据范围不同

• 应用数据：包含应用的所有页面
• 模块数据：只包含规则匹配的页面
• 模块数据 ≤ 应用数据

聚合规则不同

• 应用数据：按应用聚合
• 模块数据：按业务规则聚合（可跨同触点的多个应用）
• 同一页面可能属于不同分析维度

触点限制

• 模块只能聚合同一触点的应用数据
• Web 触点和 MP 触点无法在同一模块中混合

验证方法

1. 检查规则配置是否正确
2. 确认时间范围是否一致
3. 对比具体页面的数据
4. 联系技术支持确认