帕累托分析：找出带来 80% 结果的那 20%

大多数问题和大多数成果都集中在少数地方，帕累托分析量的就是集中到什么程度。本文给出八个步骤，分析 1,240 张客服工单：四个原因产生了 80% 的工单，修好它们后工单减少了 30%；再看一个是 68/20 而不是 80/20 的流量例子，并列出要避开的错误。

什么是帕累托分析？

帕累托分析（Pareto Analysis）是一种找出「少数原因造成大部分结果」的方法，让你把精力花在回报最高的地方。它基于帕累托法则，也常被叫作 80/20 法则：在很多系统里，大约 80% 的结果来自约 20% 的原因。80% 的客服工单可能来自 20% 的问题类型，80% 的收入来自 20% 的客户，80% 的流量来自 20% 的页面。

这个法则以经济学家维尔弗雷多·帕累托命名，他在 19 世纪 90 年代观察到意大利约 80% 的土地属于 20% 的人口。质量管理先驱约瑟夫·朱兰把它概括为「关键的少数和次要的多数」，并让它成为质量管理的标准工具。

80/20 是经验法则，不是定律。真实数据可能是 70/20、90/10 或 60/40。重点在于结果通常是集中的，而分析能告诉你集中到什么程度。

怎么一步步做帕累托分析

1. 定义要减少或增加的结果： 客服工单、结账报错、流失账号、收入、会话。
2. 选择可能解释它的类别： 工单原因、错误类型、流失原因、客户、页面、渠道。
3. 在固定时间段里统计数量，口径前后一致。
4. 按从大到小排序。
5. 算出每个类别的占比和累计占比。
6. 画帕累托图： 按降序排列的柱子，加一条累计百分比折线。
7. 找到分界点： 累计折线越过约 80% 的地方，左边的类别就是「关键的少数」。
8. 针对关键的少数采取行动，改动之后再做一次分析。

计算示例：客服工单

某 SaaS 分析产品团队把一个季度的 1,240 张客服工单按原因打了标签（示例数据）：

关键的少数： 10 个原因里的 4 个（占类别的 40%）产生了 80.4% 的工单。仅登录问题和统计代码不生效两项就占了 56%。

团队做了什么：

• 登录 / 重置密码（412）： 加了免密链接登录，改写了重置密码邮件。
• 统计代码不生效（286）： 加了一个安装检查工具，检测线上页面并解释常见原因（广告拦截、内容安全策略、站点密钥填错）。
• 账单（171）和 GA4 数据对不上（128）： 写了两篇帮助文章，从账单页和看板上链接过去。

下个季度，在客户数不变的情况下工单降到 870 张（−30%）。长尾部分（图表自定义、挂件样式）没有变化，也不需要变。

再举一例：流量集中度

某网站有 40 个落地页、每月 50,000 次会话（示例数据），排名前 8 的页面（20%）带来 34,143 次会话，占总数的 68%。这不是 80/20，也不需要是：它仍然说明优化 8 个页面的转化能影响三分之二的访客，而重写排名靠后的 20 个页面影响的人很少。它还提示了风险：排名头一位的页面一个就占 27% 的会话，它的排名一掉，流量会大幅下滑。见内容表现指标。

帕累托分析在数据分析里的用处

只看次数会误导时，按收入或成本加权。

局限和常见错误

• 把 80/20 当成精确比例。 报告真实的分布。60/40 的分布需要比 90/10 更广的行动。
• 只数次数，不看影响。 十张「登录不了」的工单，可能不如一张「被扣了两次钱」重要。能做到时，按成本或收入给类别加权。
• 类别分得不好。 「其他」那根柱子很高，说明标签太粗。「其他」排进前三，就先重新分类。
• 把不同的东西归在一起，或者把同一个原因拆成好几个标签，都会改变排序。
• 只看一次快照。 修复之后再跑一遍。排前面的原因变小后，新的原因会冒上来。
• 完全忽视长尾。 次要的多数里也可能藏着严重问题（安全漏洞报告、数据丢失的缺陷）。

用 TapCub 的数据做帕累托分析

TapCub 的大多数报表本来就按数量排序：页面、来源、事件、JavaScript 错误和爬虫 404。导出或用 SQL 查询，加一列累计百分比，就是一张帕累托表。看收入集中度，做 RFM 分析；看错误集中度，从按发生次数排序的 JavaScript 错误开始；找漏斗里最大的流失，看漏斗流失。

另见：分析事件分布。

参考资料

• ASQ. What is a Pareto chart?
• Juran, J. M. (1951). Quality Control Handbook. McGraw-Hill.
• Pareto, V. (1896). Cours d'économie politique. Lausanne.