Triage before rebuild.
Most teams respond to flat conversion by planning a rebuild. Don't. The 80/20 says you have a few specific friction points eating most of your conversion. Find them, fix them in a sprint, and only then ask whether a rebuild is justified.
The five leaks that show up most.
| Leak | Frequency | Median Lift |
|---|---|---|
| Form > 7 fields | 61% | +38% |
| Auth latency > 500ms P95 | 44% | +22% |
| No social proof above the fold | 39% | +18% |
| CTA buries the value (e.g. 'Submit') | 33% | +15% |
| Mobile-broken CTA target (< 44px) | 27% | +12% |
The 48-hour triage.
Hour 0–2 · Pull funnel data
Get the last 30 days, segmented by device, region, traffic source. Identify the steepest drop.
Hour 2–6 · Watch session recordings
20 sessions of users who abandoned at the steepest drop. Patterns appear immediately.
Hour 6–10 · Pick three fixes
Use the table above as a starting filter. Pick three that match what the recordings showed.
Hour 10–24 · Ship the fixes
Behind a flag. Roll to 50%. Compare against the 50% control over 48 hours.
Hour 24–48 · Read the result
Either ship to 100% or roll back. Do not 'wait and see'.
What wins in triage.
✓DO
- Pull funnel data segmented by device + region first
- Watch 20 abandoned-session recordings before guessing
- Cap form length at 5 fields wherever legally possible
- A/B test the fix; ship the winner; document the loser
- Repeat the triage every quarter
✗DON'T
- Plan a rebuild before triaging
- Skip the recordings and rely on funnel charts alone
- Test more than three fixes simultaneously
- Roll out before stat-sig
- Treat this as a one-time exercise
Before you kick off a rebuild.
- 30-day funnel data pulled and segmented
- 20+ abandoned-session recordings reviewed
- Top 3 leaks identified with evidence
- Three fixes shipped behind a flag
- 48-hour A/B result reviewed
- Quarterly triage on the calendar