Prioritizing Errors by Revenue Impact
You installed error tracking. Now you have thousands of errors staring back at you. The default instinct is to sort by frequency — fix the most common errors first.
This is wrong.
An error that fires 10,000 times on your blog matters less than one that fires 50 times on your checkout page. Frequency tells you how loud a problem is. It doesn't tell you how expensive it is.
The prioritization framework
Instead of sorting by frequency, run every error through these four questions.
1. Where does it fire?
Not all pages are equal. Map errors to pages, then assign revenue proximity.
| Priority | Page types |
|---|---|
| Critical | Checkout, cart, payment pages |
| High | Pricing, signup, landing pages from paid traffic |
| Medium | Product pages, key conversion paths |
| Low | Blog posts, documentation, legal pages, admin panels |
An error on your terms of service page is not the same severity as an error on your checkout page. Treat them differently.
2. Who does it affect?
An error affecting 50 sessions from Google Ads traffic is more expensive than one affecting 500 sessions from organic blog readers — because those 50 sessions cost money to acquire.
Segment errors by:
- Traffic source — Paid traffic costs money to acquire
- Browser/device — Mobile-only errors affect different conversion rates
- New vs. returning — New visitors are harder to recover
3. What does it block?
Blocking errors prevent task completion — broken form submissions, failed payments, buttons that don't respond. These require immediate attention.
Non-blocking errors are visible in the console but invisible to users — tracking pixels that fail, third-party widgets that don't load. These can wait.
The difference matters. A blocking error on 50 sessions is worse than a non-blocking error on 5,000.
4. What's the conversion rate gap?
Compare conversion rates between sessions that encountered the error and sessions that didn't.
| Error sessions | Clean sessions | |
|---|---|---|
| Reached checkout | 47 | 1,240 |
| Completed purchase | 2 (4.3%) | 806 (65%) |
That's a 60-point gap. At $80 average order value with 47 affected sessions per week, this error costs roughly $2,300/week.
What to fix first (and what to skip)
Skip these entirely — filter them out before triaging:
- Browser extensions — Errors from
chrome-extension://aren't your code - Third-party scripts — Analytics, ad networks, chat widgets you don't control
- CORS "Script error." — No actionable details available
- Bot traffic — Automated scanners don't convert anyway
A good noise filter reduces error count by 90% while keeping errors you can actually fix.
Fix these immediately:
- Any error on checkout or payment pages
- Errors paired with rage clicks
- Your own API returning 500 errors
- Errors with high session counts but zero conversions
- Any error affecting paid traffic landing pages
The revenue impact formula
Weekly cost = affected sessions × conversion rate gap × average order value
Using the earlier example:
47 sessions × (65% - 4.3%) × $80 = $2,281/week
Now you're not asking engineering to "fix a JavaScript error." You're asking them to "recover $2,300/week."
This reframing changes conversations. Product managers understand revenue. Executives understand revenue. When you attach dollar amounts to errors, prioritization becomes obvious and resources follow.
Related pages
Parent: User Behavior Signals — Context that transforms errors into business priorities
Pillar: Error Monitoring — The complete guide to catching and fixing website errors
Sibling:
- Understanding Rage Clicks — Detecting silent failures that error tracking misses