On this page
Merchants evaluating a size recommendation engine almost always ask the wrong first question: "how accurate is it?" The right question is "what data does it need to be accurate?" A fit engine is only as good as the inputs you feed it, and most stores underestimate how much groundwork is required before the first useful recommendation ever appears on a product page.
The Three Data Layers Every Fit Engine Needs
Size recommendation data breaks down into three layers, and a merchant needs at least a minimal version of all three to launch something useful.
Layer 1: Garment Measurement Data
This is the non-negotiable layer. The engine needs actual flat measurements for every SKU — chest, waist, hip, inseam, shoulder width, sleeve length, depending on category — not just the size label on the tag. A "Medium" from one supplier can differ by two full centimeters from a "Medium" from another. Without garment-level measurement data, a fit engine is guessing from size labels alone, which is exactly the problem it's supposed to solve.
Merchants often assume this data already exists in their PIM. In practice, most catalogs have size charts (a table per size) but not necessarily per-SKU or per-batch measurements, and fabric stretch/shrink notes are frequently missing entirely.
Layer 2: Body Input Data
This is what the shopper provides — height, weight, sometimes age or body shape, and increasingly a photo or a few guided measurements. The quality bar here matters less than coverage: an engine that can accept a rough height/weight pair and still produce a usable recommendation will convert far more shoppers than one that demands a full tape-measure session, because most shoppers abandon multi-step measurement forms.
Layer 3: Behavioral and Return Signal Data
This is the layer that turns a static rules engine into a learning system. Return reason codes (too small, too big, didn't like), exchange patterns, and post-purchase reviews mentioning fit are gold — they are ground truth about whether a recommendation was actually right. This layer is also why fit engines get dramatically better over time even when the first two layers stay the same.
The Cold-Start Problem: Launching Without History
New merchants and engines without accumulated return data face what recommender-systems researchers call the cold-start problem — a system has no historical signal to learn from, so early recommendations rely entirely on garment specs and generic body-shape heuristics rather than learned patterns. Research on recommender systems consistently shows a measurable accuracy gap between cold-start and data-rich states, and that gap only closes as behavioral data accumulates — see McKinsey's analysis of personalization and data maturity, which documents how data density drives recommendation precision across retail systems.
Practically, that means a merchant should not expect launch-day accuracy to match six-month accuracy. What it should expect instead is a system architecture where every early recommendation, override, and return is captured as training signal, so the gap closes on a predictable timeline rather than requiring a slow manual audit later.
How to Bridge the Cold-Start Gap Fast
A few tactics compress the cold-start window meaningfully:
- Import supplier tech-pack measurements before launch, even if incomplete for some SKUs
- Ask a minimal but forced body-input step at first use, not an optional one
- Prioritize instrumenting return-reason capture from day one, even manually, before volume is high
- Borrow category-level fit patterns from similar SKUs already measured, rather than treating every new SKU as an unknown
Data Quality Beats Data Volume
A common mistake is chasing volume — more reviews, more returns — before quality. A garment measurement that's wrong by three centimeters will actively degrade recommendations no matter how much behavioral data sits on top of it, because the engine is reasoning from a false baseline. The table below summarizes what "good enough to launch" looks like versus what "mature" looks like for each data layer.
| Data Layer | Minimum to Launch | Mature State |
|---|---|---|
| Garment measurements | Size-chart ranges per size, per category | Per-SKU flat measurements + fabric stretch notes |
| Body input | Height + weight, forced at first use | Height, weight, body shape, optional photo |
| Return/behavior signal | Manual return-reason tagging | Automated reason capture + review-text fit mining |
| Update cadence | Quarterly re-check of size charts | Continuous ingestion from every order and return |
Merchants deciding between vendors should ask each one exactly how they handle the cold-start period, because that answer reveals whether the vendor actually understands the data pipeline or is selling a black box. This is one of the core evaluation criteria covered in how to choose a size recommendation solution, which walks through vendor questions merchants should be asking before signing a contract.
Where This Data Comes From in Practice
Most merchants source the three layers from different systems, which is itself a data-integration problem:
- PIM/ERP: garment measurements, size charts, supplier tech packs
- Storefront widget or quiz: body input, style preferences
- Order management/returns platform: return reason codes, exchange history
- Review platform: fit-related text mentioned in customer reviews
Stitching these together correctly is where most in-house builds stall — not the recommendation algorithm itself. It's also why return-signal data has value well beyond the fit engine: the same feed that improves recommendations also improves demand forecasting, as covered in how fit data improves inventory planning, since knowing which sizes are systematically over-ordered relative to actual body distribution changes purchasing decisions upstream.
Frequently Asked Questions
Do I need historical return data before launching a size recommendation engine?
No, but you should expect lower initial accuracy without it. A well-designed engine can launch on garment measurements and body inputs alone, then improve measurably as return and exchange data accumulates over the following weeks and months.
How much garment measurement detail is actually required per SKU?
At minimum you need chest/waist/hip or equivalent category-specific measurements per size, not just the size label. Per-SKU flat measurements and fabric behavior notes (stretch, shrink) meaningfully improve accuracy beyond generic size-chart ranges.
What's the single highest-leverage data source to add first?
Return reason codes. They are the only data layer that tells you definitively whether a past recommendation was correct, and they compound in value the longer you collect them, unlike garment measurements which are largely static once entered.
Can I use customer reviews as size recommendation data?
Yes, review text that mentions fit ("runs small," "true to size") is a valuable secondary signal, especially for merchants without formal return-reason tracking. It's noisier than structured return data but still meaningfully better than no behavioral signal at all.