Checkout Conversion Drop After Adding a Required Custom Attribute
A mid-market retailer averages 1,800 orders/day with a 3.1% conversion rate. Two weeks ago the team added a required customer attribute ('company size') to the checkout shipping step to support a new B2B-lite segment, plus a third-party address-validation extension that calls an external API on blur. Since launch, checkout conversion fell to 2.4%, mobile abandonment at the shipping step rose sharply, and support tickets mention the page 'freezing' on mobile. Desktop conversion is essentially flat. The attribute is only relevant to roughly 15% of buyers. The extension vendor says its API averages 400ms but has occasional 8–10s timeouts. Leadership wants to know if the B2B-lite attribute should be scrapped.
1. Attribute the conversion drop. Which change is the more likely culprit, and what evidence would confirm it?
Read the worked answer
The symptoms localize the problem: mobile-only degradation, a specific step (shipping), and 'freezing' reports. A required attribute adds friction for 100% of buyers to serve 15%, which is a real but usually modest drag - it would tend to affect desktop too and wouldn't cause freezing. The address-validation extension's 8–10s timeouts on blur are the stronger suspect: on mobile networks a synchronous external call on a form field can block interaction and feel like a freeze, and the timing (on blur, repeatedly) multiplies exposure. Evidence to gather: funnel step conversion by device before/after, extension API latency/error rates from vendor logs or APM, session recordings or RUM on the shipping step showing long tasks/timeouts, and a quick A/B or feature-flag test disabling the extension for a slice of mobile traffic. If disabling the extension restores mobile conversion while the attribute stays, the extension is confirmed.
2. Recommend a remediation plan that preserves the B2B-lite goal, and state what you would tell leadership about scrapping the attribute.
Read the worked answer
Don't scrap the attribute yet - it's likely collateral. Remediation:
- Stabilize the extension: make address validation asynchronous/non-blocking, add a short client-side timeout with graceful fallback (never block submit on validation), debounce, and consider validating on submit rather than every blur. Set a hard latency budget.
- Soften the attribute: make 'company size' optional or conditional (show only when a B2B signal is present, or collect post-purchase/in account), so 85% of buyers aren't gated.
- Instrument: add RUM on the shipping step and alert on extension latency; monitor abandonment by device.
- Validate: run a controlled test to confirm recovery before declaring victory.
Tell leadership: the drop is most consistent with the third-party validation call timing out on mobile, not the attribute itself; scrapping the attribute would remove a strategic capability without fixing the freezing. Fix the blocking call and make the attribute conditional, then re-measure. Keep the attribute if post-fix data shows acceptable friction.