Error Sessions Analysis (JavaScript Errors)
Imagine: a user adds a product to the cart, clicks "Checkout" — and nothing happens. The console is full of Cannot read property 'X' of undefined, the checkout freezes. You lose money, and the user goes to a competitor. We help identify such errors and eliminate them before they zero out your metrics.
Error Sessions are sessions where one or more JavaScript errors occurred. Our experience shows: without systematic analysis, you miss 60–80% of critical bugs that directly cut conversion. We filter, analyze, and prioritize these sessions using Sentry and GA4. Sentry with Replay speeds up debugging by 5–10 times compared to simple logging.
Setting Up JavaScript Error Interception
We intercept all unhandled errors, Promise rejections, and failed fetch/XHR requests. The key element is proper source maps configuration: Sentry automatically deobfuscates the stack, showing the original source code rather than minified strings. Integration example:
// Intercept unhandled errors
window.addEventListener('error', function(event) {
const errorInfo = {
message: event.message,
source: event.filename?.split('/').pop(),
line: event.lineno,
col: event.colno,
stack: event.error?.stack?.slice(0, 500),
page: window.location.pathname,
user_agent: navigator.userAgent.slice(0, 100)
}
// Send to GA4
gtag('event', 'js_error', errorInfo)
// Send to Sentry/Bugsnag
Sentry.captureException(event.error, {
extra: errorInfo
})
})
// Intercept unhandled Promise rejections
window.addEventListener('unhandledrejection', function(event) {
gtag('event', 'promise_rejection', {
message: event.reason?.message || String(event.reason),
page: window.location.pathname
})
})
// Intercept errors in fetch/XHR
const originalFetch = window.fetch
window.fetch = async function(...args) {
try {
const response = await originalFetch(...args)
if (!response.ok) {
gtag('event', 'fetch_error', {
url: args[0].toString().split('?')[0],
status: response.status,
page: window.location.pathname
})
}
return response
} catch (err) {
gtag('event', 'fetch_exception', {
url: args[0].toString().split('?')[0],
message: err.message
})
throw err
}
}
For more details on window.onerror, see the MDN documentation. According to Sentry documentation, integration with source maps and Replay speeds up debugging by 5–10 times compared to regular logging.
Integrating Sentry with Replay and Tracing
For in-depth analysis, we integrate Sentry with Replay and Tracing. Replay records the session up to the error moment, allowing you to see user actions. Example configuration:
// sentry.init.js
import * as Sentry from '@sentry/browser'
import { BrowserTracing } from '@sentry/tracing'
Sentry.init({
dsn: 'https://[email protected]/yyy',
integrations: [
new BrowserTracing(),
new Sentry.Replay({
maskAllText: false,
blockAllMedia: false
})
],
tracesSampleRate: 0.1, // 10% for performance
replaysSessionSampleRate: 0.05, // 5% of sessions to record
replaysOnErrorSampleRate: 1.0, // 100% on error
beforeSend(event) {
// Add user context
event.user = {
id: currentUser?.id,
segment: currentUser?.plan
}
return event
}
})
How Errors Affect Conversion
We build SQL queries comparing CVR of sessions with and without errors. Typical result: sessions with errors convert 3+ times worse. Example code:
def analyze_error_impact(analytics_db):
# Compare conversion of sessions with errors vs without
result = analytics_db.query("""
WITH session_errors AS (
SELECT
session_id,
COUNT(*) as error_count,
MAX(CASE WHEN event_name = 'purchase' THEN 1 ELSE 0 END) as converted
FROM events
WHERE date >= CURRENT_DATE - INTERVAL '7 days'
AND event_name IN ('js_error', 'purchase')
GROUP BY session_id
),
all_sessions AS (
SELECT session_id,
MAX(CASE WHEN event_name = 'purchase' THEN 1 ELSE 0 END) as converted
FROM events
WHERE date >= CURRENT_DATE - INTERVAL '7 days'
GROUP BY session_id
)
SELECT
'with_errors' AS segment,
COUNT(*) AS sessions,
SUM(converted) AS conversions,
ROUND(AVG(converted::float) * 100, 2) AS cvr
FROM session_errors WHERE error_count > 0
UNION ALL
SELECT
'without_errors',
COUNT(*),
SUM(a.converted),
ROUND(AVG(a.converted::float) * 100, 2)
FROM all_sessions a
LEFT JOIN session_errors se ON a.session_id = se.session_id
WHERE se.session_id IS NULL
""")
return result
# Typical result:
# with_errors: 1.2% CVR
# without_errors: 3.8% CVR
# Errors reduce conversion by 3+ times
| Segment | Sessions | Conversions | CVR |
|---|---|---|---|
| With errors | 12450 | 149 | 1.2% |
| Without errors | 112050 | 4258 | 3.8% |
Difference — 3.2x. If your average order value is $100, weekly losses exceed $12,000.
Monitoring Tools Comparison
| Tool | Source maps | Replay | GA4 Integration | Price |
|---|---|---|---|---|
| Sentry | Yes | Yes | Via API | Free up to 5k events/month |
| Bugsnag | Yes | No | Via API | From $29/month |
| LogRocket | Yes | Yes | No | From $39/month |
| GA4 | No | No | Built-in | Free |
Sentry is the optimal choice for deep analysis: it combines source maps, Replay, and flexible GA4 integration. Compared to GA4, Sentry is better suited for debugging because it provides a full stack and Replay, reducing time to find the root cause by 5–10 times.
How to Prioritize Error Fixing?
We use the metric affected_users × conversion_impact. Errors in checkout/payment modules get weight 3, others 1. Example:
def prioritize_errors(sentry_api, project_slug):
"""Priority = affected_users × conversion_impact"""
issues = sentry_api.get_issues(project_slug, limit=50)
for issue in issues:
affected_users = issue['userCount']
# Errors in checkout/payment — high priority
is_critical = any(p in issue['culprit'] for p in
['checkout', 'payment', 'cart', 'form'])
issue['priority_score'] = affected_users * (3 if is_critical else 1)
return sorted(issues, key=lambda x: x['priority_score'], reverse=True)
Typical Critical Errors
-
Cannot read property 'X' of undefined— race condition during async loading -
Network Errorin fetch — API unavailable, no retry logic -
PaymentRequestUpdateEvent— Payment Request API errors on iOS Safari -
ChunkLoadError— outdated cache after deployment (solution:window.location.reload())
Case study: how we improved CVR by 25%
In one project (an electronics e-commerce store), after deploying a new version of the checkout module, conversion dropped from 3.5% to 1.1%. It turned out that 40% of sessions had an error Cannot read property 'price' of undefined due to a changed API response format. Sentry showed that the error affected 15k users per day. After the fix and redeployment, CVR returned to 3.5% within 2 days. Losses over 3 days amounted to ~900 orders.
What's Included in the Service
- Setting up interception of all JS errors (including source maps)
- Integration of Sentry with Replay and Tracing
- Creating events in GA4 for conversion analysis
- Dashboards for error impact on CVR and revenue
- Prioritized list of bugs with recommendations
- Integration documentation and dashboard access
- One month of support after implementation
Work Process
- Audit of current monitoring: check which errors are already being intercepted.
- Tool setup: install Sentry, refine GA4 events.
- Data collection: 7 days of accumulating Error Sessions statistics.
- Analysis and prioritization: build SQL reports, calculate conversion impact.
- Report and fixes: provide you with a list of bugs indicating criticality, assist with corrections.
- Verification: after fixes, repeat analysis to ensure CVR growth.
Timelines and Results
First results within 2 business days: you see a dashboard with Error Sessions and their impact. Full analysis and prioritization cycle takes 5 to 7 days. Specific cost depends on project scope (number of pages, integrations), so we calculate it individually. Contact us — we'll evaluate your project for free.
Why Choose Us
Our experience: over 10 years in frontend development and monitoring. We've worked on projects where CVR increased by 25% solely by eliminating JS errors. We use only proven tools: Sentry, GA4, Grafana. We guarantee correct integration operation. Order an audit — get a consultation with a detailed breakdown of your Error Sessions. Contact us — we'll prepare a custom proposal.