The Pattern We Found
The site "worked." Pages loaded. Orders came in. The dev team said everything was fine. But mobile conversion was soft and nobody could explain why.
We were watching Clarity data weekly. Across four straight reporting periods, three signals kept moving together: JavaScript error rate sitting at 5 to 6%, dead clicks on the collection page at 4.6%, and quick backs at 15%. Most teams look at those as separate metrics. They're not. They're the same problem.
The JS errors were null reference failures in the product card initialization code: productelement.getattribute, addEventListener on null elements, "cannot read properties of null." On mobile, those errors were silently breaking interaction on the collection page. Users tapped products. Nothing happened. They tapped again. Nothing. They quick-backed to Instagram or Facebook and the session ended. From the dev team's desktop browser everything looked fine. On mobile, which is 88% of Axel's traffic, it wasn't.
The Fix
Targeted null check fixes on product card initialization. Guard the DOM access. Defer initialization until elements exist. Not a theme rebuild, not a re-platform. One dev cycle, scoped to the actual problem.
Then we deliberately waited a week before reporting. Clarity has a 4 to 5 day data lag, and we wanted to see whether dead clicks would fall in parallel with the JS error rate. If the two metrics moved together, that would confirm the causation we'd hypothesized. They did.
The Result · Technical (Apr 7 to 13 vs Mar 26 to Apr 2)
| Metric | Before | After | Change |
|---|---|---|---|
| JavaScript Error Rate | 5.19% (peak: 5.77%) | 1.74% | −66% (−70% from peak) |
| Dead Clicks | 4.63% | 2.42% | −48% |
| Quick Backs | 14.97% | 10.73% | −28% (lowest ever recorded) |
| Performance Score | 84/100 | 86/100 | +2 (best ever recorded) |
| CLS | 0.014 | 0.013 | Best ever recorded |
The Result · Revenue (Apr 1 to 13 vs Mar 1 to 13)
| Metric | Before (Mar 1 to 13) | After (Apr 1 to 13) | Change |
|---|---|---|---|
| Total Sales | $68,865 | $85,907 | +30% |
| Net Sales | $63,732 | $80,534 | +32% |
| Online Store Revenue (channel we manage) | $35,725 | $46,800 | +31% |
| Online Store, Week-over-Week (post-fix) | $19,900 | $24,300 | +22% in one week |
| Average Order Value | $204 | $237 | +16% |
| Returns | $5,162 | $2,270 | −56% |
Timeline: Four weekly reporting periods of pattern detection → one dev cycle of targeted JS fixes → one week of post-fix data validation. The fix was small. Knowing where to point it took the analysis.
What This Actually Means
The lesson here isn't "JavaScript errors hurt revenue." Most $1M+ Shopify stores have JS errors firing somewhere, and most of them don't materially affect conversion. What mattered at Axel was that the errors were specifically breaking mobile interaction on the collection page, on a store where 88% of traffic is mobile. That's the pattern we look for: not "what's broken," but "what's broken in a way that's actually costing you."
The dev team wasn't bad. They just weren't looking at this layer of data. Most aren't.
