Summary

Business Challenge
Wrong-fit returns were cutting into margin through added shipping costs, restocking, support time, and lost sales. The problem was not the search box itself, but the fitment data behind it. A standard Year/Make/Model filter could match the right vehicle at a basic level while missing the details that actually decide compatibility. As a result, customers could choose parts that appeared compatible but failed once installed.
The merchandising team had to manage this complexity manually across fitment feeds, OEM and interchange numbers, electric-vehicle coverage, and new-model-year demand. As the catalog expanded, the workload grew with it. At the same time, “did not fit” return reasons stayed inside the support system instead of feeding back into search, catalog data, or fitment rules. That meant the same compatibility issues could keep causing new returns.
Solutions
1
Fitment Intelligence Layer
WiserBrand kept Magento Open Source as the order management layer and moved fitment logic into a dedicated Solr-backed pipeline.
The new layer connected product and order data, fitment feeds, OEM and interchange references, internal rules, and return codes. Kafka workers normalized incoming records, flagged conflicts, and kept the search index current.
2
Configuration-Level Matching
The system surfaced engine, drivetrain, trim, transmission, and body-style distinctions earlier in the search journey.
This helped customers narrow results before the product page or checkout, reducing the risk of ordering a part that matched only at the Year/Make/Model level.
3
Smarter Search Interpretation
The search layer translated how customers actually search into structured catalog logic.
It mapped slang, chassis codes, symptom-based queries, OEM references, interchange numbers, and part numbers to relevant results. A query like “my E46 is overheating” could point toward cooling-system parts for that chassis.
4
Validated AI-Assisted Enrichment
For electric vehicles and new model years, AI helped identify missing attributes, recognize new vehicle and part terms, and expand the catalog structure around emerging fitment data.
It helped classify and enrich product data, but it was not the source of truth for compatibility. Fitment-critical data passed through trusted feeds, OEM references, QA rules, and review workflows before reaching customer-facing search.
5
Return Feedback Loop
“Did not fit” return codes were routed back into fitment QA.
Recurring patterns could trigger catalog corrections, search-rule updates, fitment review queues, and attribute improvements. Returns became inputs for improving the next search.
Project Results
Six months after rollout, the retailer saw measurable improvement across return reduction, catalog operations, and search coverage.


