Pareto analysis: how to find the 20% that drives 80% of results

Most problems and most results are concentrated in a few places; Pareto analysis measures exactly how concentrated. This guide gives the eight steps, works through 1,240 support tickets where four reasons produced 80% of the volume (and fixing them cut tickets 30%), shows a traffic example that is 68/20 rather than 80/20, and lists the mistakes to avoid.

What is Pareto analysis?

Pareto analysis is a technique for finding the few causes that account for most of an effect, so you can focus effort where it pays off most. It is based on the Pareto principle, often called the 80/20 rule: in many systems, roughly 80% of outcomes come from about 20% of causes. 80% of support tickets may come from 20% of issue types, 80% of revenue from 20% of customers, 80% of traffic from 20% of pages.

The principle is named after the economist Vilfredo Pareto, who observed in the 1890s that about 80% of land in Italy was owned by 20% of the population. Quality pioneer Joseph Juran generalized it as "the vital few and the trivial many" and made it a standard quality-management tool.

The 80/20 split is a rule of thumb, not a law. Real data might show 70/20, 90/10 or 60/40. The point is that effects are usually concentrated, and the analysis tells you how much.

How to do a Pareto analysis, step by step

1. Define the effect you want to reduce or grow: support tickets, checkout errors, churned accounts, revenue, sessions.
2. Choose the categories that might explain it: ticket reason, error type, churn reason, customer, page, channel.
3. Collect counts for a fixed period, using the same definition throughout.
4. Sort categories from largest to smallest.
5. Compute each category's share of the total and the cumulative share.
6. Draw a Pareto chart: bars for each category in descending order, plus a line for the cumulative percentage.
7. Find the cut-off where the cumulative line crosses about 80%. The categories to the left are your "vital few".
8. Act on the vital few, then repeat the analysis after the change.

Worked example: support tickets

A SaaS analytics team tagged 1,240 support tickets from one quarter by reason (sample data):

The vital few: four of ten reasons (40% of categories) produce 80.4% of tickets. Two alone, login problems and tracking code not firing, account for 56%.

What the team did:

• Login / password reset (412): added magic-link sign-in and clearer reset emails.
• Tracking code not firing (286): added an installation checker that tests the live page and explains the common causes (ad blockers, Content Security Policy, wrong site key).
• Billing (171) and GA4 mismatch (128): wrote two help articles and linked them from the billing page and the dashboard.

Next quarter, tickets fell to 870 (−30%) with the same customer base. The long tail (chart customization, widget style) did not change and did not need to.

A second example: traffic concentration

On a site with 40 landing pages and 50,000 monthly sessions (sample data), the top 8 pages (20%) bring 34,143 sessions, 68% of the total. That is not 80/20, and it does not need to be: it still says that improving conversion on 8 pages affects two-thirds of visitors, while rewriting the bottom 20 pages touches very few. It also flags risk: if the top page (27% of sessions alone) loses rankings, traffic drops sharply. See content performance metrics.

Where Pareto analysis works in analytics

Weight by revenue or cost when counts alone mislead.

Limitations and common mistakes

• Treating 80/20 as exact. Report the real split. A 60/40 distribution calls for broader action than a 90/10 one.
• Counting frequency, not impact. Ten "can't log in" tickets may matter less than one "charged twice". Weight categories by cost or revenue when you can.
• Poor categories. A big "Other" bar means the tagging is too coarse. If "Other" is in the top three, re-categorize first.
• Lumping different things together or splitting one cause across several labels changes the ranking.
• Static snapshots. Re-run after fixes. Once the top causes shrink, new ones move up.
• Ignoring the tail entirely. The trivial many can still hold a severe issue (a security report, a data loss bug).

Pareto analysis with TapCub data

Most TapCub reports already sort by volume: pages, sources, events, JavaScript errors and crawler 404s. Export or query them with SQL, add a cumulative-percentage column, and you have a Pareto table. For revenue concentration, run an RFM analysis; for error concentration, start with JavaScript errors sorted by occurrences; for the biggest funnel loss, use funnel drop-off.

See also: Analyze event distribution.

Sources

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