# 【工程管理】某运营商无线数字化运营平台浏览器监控数据分析实践
# 一、数据集介绍
# 1.1 数据来源与规模
数据集来自某运营商无线数字化运营平台的移网问题洞察分析系统实际业务场景的浏览器监控特殊事件埋点数据，埋点规则根据业务需求对【面场景视图】、【线场景视图】、【栅格视图】的两侧面板点击事件做了特殊埋点，具体埋点包括：
- 面场景视图：场景分析、小区分析、场景评估、覆盖分析、用户分析、OTT分析、问题清单、小区多维分析、栅格分析、小区信息
- 线场景视图：道路分析、场景评估、覆盖分析、路段分析、小区信息
- 栅格视图：栅格分析、栅格评估、投诉分析、小区多维分析、小区信息
本次分析采用2026年4月、5月用户操作日志合并数据，文件为《2026年4月5月数据UTF.csv》，数据集整体规模如下：
- 总有效样本量：42039条，无重复、无截断的完整业务操作记录
- 总字段数量：14个，覆盖用户终端、地理位置、业务操作、页面性能四大核心维度
- 数据范围：完整覆盖2026年4月1日-5月31日的全量业务用户操作行为，具备完整的业务周期代表性。
# 1.2 字段说明
数据集14个字段可分为4大类，均具备明确的业务含义，具体如下：
| 字段类别 | 核心字段名称 | 业务含义 |
|---|---|---|
| 终端环境信息 | browser、engine、os、version、userAgent | 用户使用的浏览器类型、渲染引擎、操作系统、软件版本、终端代理信息，反映用户的设备使用特征 |
| 地理位置信息 | provinceName、cityName_gjy | 用户操作所在的省份、城市，反映业务的地域覆盖特征 |
| 业务操作信息 | innerText、scene、staffId、phone | 用户操作的功能名称、业务场景视图、操作员工ID、联系电话，反映用户的业务使用偏好 |
| 页面性能信息 | pageLoadTime、screenWidth、screenHeight | 页面加载时长、用户终端屏幕分辨率，反映产品的性能表现与用户终端适配特征 |
# 1.3 数据质量说明
- 完整性：42039条记录的14个字段均无缺失值、无空值，数据完整度100%，无无效截断记录
- 一致性：所有字段取值格式统一，类别型字段无乱码、无异常取值，数值型字段格式规范，无数据类型不一致问题
- 合理性：字段取值符合业务逻辑，操作系统、浏览器、省份、业务场景等字段的取值均在业务合理范围内，无明显异常值
- 代表性：数据覆盖全国31个省份、100+城市，包含主流的浏览器、操作系统、业务场景，能够全面反映业务的整体运行特征，具备充分的业务代表性。
# 1.4 核心数据分布特征
- 终端分布：操作系统以Windows为主，占比96.36%；浏览器以360EE、Edge、Chrome为核心，合计占比超70%，是业务的主流终端环境
- 地域分布：用户覆盖全国各省份，核心访问省份为河南省、河北省、辽宁省、山东省、山西省，合计占比超60%，是业务的核心服务区域
- 业务场景分布：业务视图以面场景视图为绝对主流，占比92.48%；栅格视图占比7.51%，线场景视图占比极低，业务使用场景高度集中
- 性能分布：页面加载时长分布在1ms-100000ms区间，核心集中在2000ms-10000ms，整体性能表现符合业务系统的常规运行特征。
# 二、分析流程描述
# 2.1 分析目标
本次分析基于WEKA软件的Apriori关联规则算法，对2026年4-5月业务数据开展无监督关联挖掘，核心目标为：
- 挖掘业务数据中，用户终端、地理位置、业务操作、页面性能四大维度属性之间的潜在关联关系，识别属性间的因果关联
- 提炼业务的核心用户画像，识别不同用户群体的业务使用偏好、终端使用习惯、地域分布特征
- 为产品功能优化、终端兼容性提升、地域化运营策略制定、业务场景迭代提供可落地的数据支撑，完成课程实验的关联规则分析要求。
# 2.2 核心分析方法
本次分析采用Apriori关联规则算法，该算法是数据挖掘领域的经典无监督学习算法，也是WEKA软件内置的核心关联规则挖掘算法，完全适配本次业务数据的分析需求。
# 2.2.1 算法核心原理
Apriori算法的核心思想为「频繁项集先验原理」，即：若一个项集是频繁的，则它的所有非空子集也一定是频繁的；反之，若一个项集的子集是非频繁的，则该集合一定是非频繁的。算法的核心执行步骤为：
- 频繁项集挖掘：通过逐层搜索的方式，扫描全量数据集，找出所有满足最小支持度要求的频繁项集（即同时出现的属性组合）
- 关联规则生成：基于挖掘出的频繁项集，通过置信度、提升度等指标筛选，生成满足要求的强关联规则，挖掘属性之间的因果关联关系
- 规则排序与输出：按置信度、提升度等核心指标对规则进行排序，输出符合要求的最终关联规则。
# 2.2.2 关联规则核心评价指标
本次分析采用3个行业通用的核心指标，对关联规则的质量进行评价，具体如下：
| 指标名称 | 业务含义 |
|---|---|
| 支持度（Support） | 项集{A,B}在总数据中出现的比例，反映该属性组合的普遍程度，值越高说明该组合在业务中越常见 |
| 置信度（Confidence） | 在属性A出现的情况下，属性B同时出现的概率，反映规则的因果关系可靠程度，值越高说明A与B的关联越强 |
| 提升度（Lift） | A出现时B出现的概率，与B单独出现的概率的比值，反映规则的关联强度；提升度>1说明A与B存在正向强关联，值越高关联效果越显著 |
# 2.3 数据预处理流程
WEKA的Apriori算法仅支持类别型数据的关联挖掘，因此需对原始数据进行标准化预处理，确保数据符合算法输入要求，具体步骤如下：
- 数据清洗：剔除原始数据中无业务分析价值的冗余字段，保留14个核心分析字段，确保数据精简，避免无效字段干扰分析结果
- 数据类型转换：将带千分位逗号的数值型字段（pageLoadTime、screenWidth、screenHeight）转换为标准数值类型，确保数据格式规范
- 数值离散化：对3个数值型字段采用等宽分箱的方式，离散化为「低、中、高」3个有序类别，将连续数值型数据转换为适合关联分析的类别型数据，解决Apriori算法无法处理连续数值的问题
- 编码处理：将原始数据转换为UTF-8编码格式，确保WEKA软件导入时，中文省份、城市、业务场景名称无乱码，避免数据读取异常
- 数据校验：最终校验预处理后的数据，确认所有字段均为类别型、无缺失值、无异常取值，完全符合WEKA软件的输入要求，生成最终分析文件
2026年4月5月数据UTF.csv。
# 2.4 WEKA软件操作流程
本次分析完全基于WEKA 3.8.6稳定版软件开展，核心操作流程如下：
- 软件启动与面板切换：打开WEKA软件，选择Explorer（资源管理器）模式，进入关联分析的核心操作环境
- 数据导入：切换至Preprocess（预处理）面板，点击「Open file...」按钮，导入预处理完成的UTF-8编码CSV文件，完成数据读取；导入后查看字段列表、取值分布，确认数据无乱码、无缺失值，导入成功
- 算法选择：切换至Associate（关联）面板，点击「Associator」下方的「Choose」按钮，在下拉列表中选择
weka.associations.Apriori算法，完成核心分析算法的选择 - 参数配置：点击「Choose」按钮右侧的文本框，打开Apriori算法参数配置窗口，按照本次分析的业务需求，完成所有参数的配置（详细参数配置见2.5节）
- 算法运行：参数配置完成后，点击「Start」按钮，启动Apriori算法；软件自动完成全量数据扫描、频繁项集挖掘、关联规则生成与筛选，最终输出符合要求的分析结果
- 结果保存与整理：算法运行完成后，在「Associator output」窗口查看完整的关联规则结果，点击「Save result」按钮将结果保存为文本文件，便于后续的整理、解读与报告撰写。
# 2.5 核心参数配置说明
本次分析的参数配置严格参考用户提供的参数要求，结合业务数据特征与课程实验要求，最终参数配置如下：
| 参数名称 | 配置值 | 配置说明与业务适配理由 |
|---|---|---|
| classIndex | -1 | 无指定预测标签，本次分析为无监督全维度关联挖掘，不单独预测某一字段，固定设置为-1 |
| lowerBoundMinSupport | 0.1 | 最小支持度下限为10%，确保挖掘出的频繁项集至少覆盖10%的总样本（4200+条记录），过滤极小众、无业务意义的属性组合，保证规则的业务代表性 |
| upperBoundMinSupport | 1.0 | 支持度上限为100%，无额外上限限制，确保所有符合要求的频繁项集均被挖掘 |
| delta | 0.05 | 最小支持度递减步长为0.05，当0.1支持度无法挖掘到足够规则时，自动每次降低0.05进行搜索，适配业务数据的样本特征 |
| metricType | Confidence | 规则评价指标选用置信度，为行业通用的关联规则核心评价指标，先以置信度筛选可靠规则，后续再通过提升度进行二次筛选 |
| minMetric | 0.9 | 最小置信度为90%，仅保留前项出现时后项发生概率≥90%的规则，剔除随机出现的弱关联规则，保证最终输出规则的因果关系具备极高的可靠性 |
| numRules | 10 | 最多输出10条符合要求的关联规则，符合课程实验的分析要求，避免规则过多导致的冗余问题，便于核心规则的整理与解读 |
| outputItemSets | False | 不输出原始频繁项集，仅输出最终可解释的关联规则，减少输出结果的冗余，提升可读性 |
| removeAllMissingCols | False | 不删除含缺失值的字段，本次分析数据无缺失值，开启会误删有效字段，因此保持关闭 |
| significanceLevel | -1.0 | 关闭统计学显著性检验，普通业务关联分析无需额外的显著性校验，保持默认值即可 |
| treatZeroAsMissing | False | 0值不视为缺失值，页面加载时长、屏幕分辨率中的0值为合法业务数据，不能当成空值剔除 |
| verbose | False | 关闭详细运行日志，输出界面仅展示精简的核心规则，提升结果的可读性 |
# 三、分析结果说明
# 3.1 核心规则总览
本次分析基于42039条有效业务数据，通过WEKA的Apriori算法挖掘，最终输出10条符合最小支持度10%、最小置信度90%要求的核心强关联规则，所有规则均具备明确的业务含义，核心规则总览如下：
| 规则ID | 关联规则内容 | 支持度 | 置信度 | 提升度 |
|---|---|---|---|---|
| 1 | {innerText=覆盖分析, os=Windows} → {scene=面场景视图} | 61.62% | 100% | 1.08 |
| 2 | {innerText=覆盖分析} → {scene=面场景视图} | 63.47% | 100% | 1.08 |
| 3 | {innerText=覆盖分析, scene=面场景视图} → {os=Windows} | 63.46% | 97.08% | 1.01 |
| 4 | {innerText=覆盖分析} → {os=Windows} | 63.47% | 97.08% | 1.01 |
| 5 | {innerText=覆盖分析} → {os=Windows, scene=面场景视图} | 63.47% | 97.08% | 1.09 |
| 6 | {scene=面场景视图} → {os=Windows} | 92.48% | 96.53% | 1.00 |
| 7 | {engine=Blink, scene=面场景视图} → {os=Windows} | 58.52% | 94.88% | 0.98 |
| 8 | {engine=Blink} → {os=Windows} | 64.11% | 94.68% | 0.98 |
| 9 | {os=Windows} → {scene=面场景视图} | 96.36% | 92.64% | 1.00 |
| 10 | {engine=Blink, os=Windows} → {scene=面场景视图} | 60.70% | 91.47% | 0.99 |
# 3.2 核心规则分维度解读
本次挖掘出的10条核心规则，可分为业务功能与场景关联、终端环境与业务场景关联、终端环境与功能关联三大维度，具体解读如下：
# 3.2.1 业务功能与场景维度核心规则（规则1-5）
该维度的规则揭示了用户操作的功能名称与业务场景视图之间的绝对强关联关系，是本次分析中置信度最高、覆盖范围最广的核心规则，具体如下：
- 规则1与规则2：覆盖分析功能与面场景视图的绝对绑定
规则内容：
{innerText=覆盖分析} → {scene=面场景视图}，置信度100%，支持度63.47% 业务解读：用户使用「覆盖分析」功能时，100%会使用「面场景视图」，该规则覆盖了63.47%的总用户，是本次分析中最核心的强关联规则。这说明「覆盖分析」是业务的绝对核心功能，面场景视图是该功能的唯一配套使用场景，用户对该功能的使用习惯高度统一，无其他场景的使用需求。 - 规则3-5：覆盖分析、面场景视图与Windows系统的强关联
规则内容：
{innerText=覆盖分析} → {os=Windows, scene=面场景视图}，置信度97.08%，支持度63.47% 业务解读：用户使用「覆盖分析」功能时，97.08%的概率会同时使用Windows操作系统和面场景视图，该规则覆盖了超60%的总用户。这说明业务的核心用户群体均使用Windows操作系统，核心业务场景高度集中在Windows环境下的覆盖分析+面场景视图，业务的核心使用特征高度明确。
# 3.2.2 终端环境与业务场景维度核心规则（规则6、9）
该维度的规则揭示了用户操作系统与业务场景视图之间的强关联关系，反映了业务的终端使用特征，具体如下：
- 规则6：面场景视图与Windows系统的强绑定
规则内容：
{scene=面场景视图} → {os=Windows}，置信度96.53%，支持度92.48% 业务解读：使用「面场景视图」的用户，96.53%的概率使用Windows操作系统，该规则覆盖了92.48%的总用户，几乎覆盖了所有业务用户。这说明业务的绝大多数用户均使用Windows操作系统，面场景视图是Windows用户的绝对主流使用场景，业务的终端适配核心应围绕Windows系统展开。 - 规则9：Windows系统与面场景视图的双向强关联
规则内容：
{os=Windows} → {scene=面场景视图}，置信度92.64%，支持度96.36% 业务解读：使用Windows操作系统的用户，92.64%的概率会使用「面场景视图」，该规则覆盖了96.36%的总用户，与规则6形成了双向强关联。这进一步验证了Windows系统与面场景视图的绝对绑定关系，业务的核心使用场景高度集中，无明显的多元化需求。
# 3.2.3 终端引擎与业务场景维度核心规则（规则7、8、10）
该维度的规则揭示了用户浏览器渲染引擎与操作系统、业务场景之间的关联关系，反映了业务的浏览器使用特征，具体如下：
- 规则8：Blink引擎与Windows系统的强关联
规则内容：
{engine=Blink} → {os=Windows}，置信度94.68%，支持度64.11% 业务解读：使用Blink渲染引擎的用户，94.68%的概率使用Windows操作系统，该规则覆盖了64.11%的总用户。Blink引擎是Chrome、360EE等主流浏览器的核心渲染引擎，这说明业务的主流浏览器用户均使用Windows操作系统，浏览器与系统的绑定关系极强。 - 规则7、10：Blink引擎、Windows系统与面场景视图的关联
规则内容：
{engine=Blink, os=Windows} → {scene=面场景视图}，置信度91.47%，支持度60.70% 业务解读：使用Blink渲染引擎+Windows操作系统的用户，91.47%的概率会使用「面场景视图」，该规则覆盖了60%以上的总用户。这进一步验证了业务的核心用户画像：Windows系统+Blink引擎浏览器+面场景视图+覆盖分析功能，该画像覆盖了超60%的总用户，是业务的绝对核心用户群体。
# 3.3 分析结果的业务价值总结
本次关联规则分析，从42039条业务数据中挖掘出了具备高可靠性、高业务价值的核心关联规则，为业务发展、产品优化、运营策略制定提供了明确的数据支撑，核心业务价值如下：
- 精准核心用户画像构建 通过多维度关联规则，明确了业务的绝对核心用户画像：Windows操作系统+Blink引擎浏览器+覆盖分析功能+面场景视图，该画像覆盖了超60%的总用户，解决了业务用户群体特征模糊的问题，为产品设计、终端适配、运营推广提供了精准的目标群体。
- 产品功能优化方向明确 挖掘出了覆盖分析功能与面场景视图的100%绑定关系，说明该功能是业务的核心生命线，产品优化应优先围绕覆盖分析功能+面场景视图展开，重点提升该功能的稳定性、易用性、性能表现；同时，栅格视图、线场景视图等小众功能的使用占比极低，可根据业务需求进行精简或优化，避免无效的研发投入。
- 终端兼容性优化策略清晰 明确了业务96%以上的用户均使用Windows操作系统，64%以上的用户使用Blink引擎浏览器，因此产品的终端兼容性优化应优先围绕Windows系统+Chrome/360EE等Blink引擎浏览器展开，重点保障该环境下的产品稳定性、渲染效果、性能表现；对于Linux、Mac OS等小众系统，可进行基础适配，无需投入过多研发资源。
- 地域化运营策略支撑 结合数据的地域分布特征与关联规则，业务的核心用户集中在河南省、河北省、辽宁省、山东省、山西省等北方省份，核心功能为覆盖分析+面场景视图，因此运营推广应重点围绕北方核心省份展开，定向推广覆盖分析功能的核心价值，提升核心区域的用户活跃度；对于南方新增区域，可进行基础的功能引导，逐步拓展业务覆盖范围。
基于2026年4-5月的实际业务数据，通过WEKA软件的Apriori关联规则算法，完成了全流程的无监督关联挖掘分析。实验结果表明，业务的核心使用特征高度集中，核心用户群体、核心功能、核心场景、核心终端环境均具备极强的关联绑定关系，挖掘出的10条核心规则均具备明确的业务含义，能够为业务的产品优化、终端适配、运营推广提供可落地的数据支撑。