Break the all-or-nothing — a reduced registration beats a failure, but record what you dropped

Symptom

Products with a two-axis option structure (color × plug type) kept being rejected. The platform's option model cannot express that shape. It isn't a conversion, it's a loss, so there was nothing to fix.

Fix

On failure, retry with only the representative option (items[:1]). Measured: 5 failures → 0.

★★ An earlier entry handled the same situation as "after three failures, record the reason and skip." There was a better move — skipping yields 0 records, reducing yields 1. ★ Before settling for failure, look for whether an intermediate outcome exists between "failed" and "fully succeeded."

⚠️ ★★★ But a reducing fallback discards information, and the loss lands on the user

The representative option was named default. That name tells a buyer nothing. Register a two-axis product as one item and the customer does not know what they are getting — a wrong plug type is a return.

★★★ Technical success is not product success. "5 successful registrations" is perfect on the dashboard and is in fact 5 items with undisclosed specifications.

★ So a fallback needs two things attached.

1. Restore the dropped information somewhere a human reads — state the representative option's actual specs in the title and description
2. Mark the fallback records — fallback:single_option. Counting them only as "success" severs the trail

★★ Never fold a lossy fallback straight into the success counter. Without a separate tally you lose any way to know when to put it right — if the platform later supports multiple axes, you won't know which records to fix.

---

---