Size & fit recommendation to reduce fashion returns

Fashion e-commerce loses margin because shoppers cannot tell which size fits, order several sizes ("bracketing") and send most of them back. Size and fit engines combine garment measurements, brand sizing differences and purchase/return history to tell each shopper which size to pick, and tell merchandisers which items run small or large. Deployed as a product-page widget, an SMB plug-in or an in-house model at large marketplaces, they reduce size-related returns and the cost, CO2 and margin loss that go with them.

Problem & value

• Today: shoppers rely on static size charts that differ per brand; retailers absorb free returns, reverse logistics, repackaging and markdowns. "Wrong size" is typically the most common return reason in apparel and footwear. Fit complaints reach merchandising only as scattered reviews.
• AI value: per-shopper size advice, earlier detection of mis-sized styles (fix chart, add a fit note, adjust the cut with the supplier), and flags for likely-returned baskets so that the shop can show guidance at checkout.
• Evidence: Zalando has reported that its size advice prevented about 8% of size-related returns (company-reported; see Source 1). Vendor case studies (Snap Fit Analytics, True Fit, Bold Metrics) claim return and conversion improvements, but results are self-reported and vary by category, so measure them in an A/B test with your own data [2][3][4].
• Why distinct from REC-001: REC-001 decides which product to show; this decides which size of one product fits. It uses garment specs, return reasons and body measures, and has its own cold-start problem. It generates no content (unlike GEN-010 virtual try-on).

Variants

• Plug-in widget for SMB shops (Shopify, Shopware, WooCommerce, Magento): questionnaire plus vendor-held cross-retailer data.
• In-house model at large marketplaces/brands: uses first-party order, return and review data.
• Body-data variant: height/weight questionnaire, or a smartphone photo/video scan estimating measurements (biometric-adjacent; see Risks).
• Merchandising fit-intelligence: aggregated "runs small/large" signal per SKU for buyers, product development and size-chart correction.
• Likely-return basket flagging: classifier on bracketed baskets (same style in several sizes), feeding checkout nudges; links to PRED-020 and ANOM-033 (returns abuse).
• Footwear and bras/lingerie: foot-length and band/cup models; sizing is stricter and error cost higher.
• Private use: a personal "my measurements" profile that works across shops.

How it works

1. garment measurements + size charts + catalogue attributes shopper signals (questionnaire, past orders/returns, optional body estimate)
2. feature building (item-vs-user fit gap, brand/size offsets, return reasons: too small/large)
3. fit model (latent-fit / ordinal "too small - ok - too large" model)
4. size recommendation + confidence + "runs small" note
5. UI (product page, cart)
6. order
7. return outcome logged as new label
8. aggregation per SKU
9. merchandising dashboard (chart fixes, supplier feedback)

• Core model: most systems learn a latent "true size" per shopper and per item, then predict the ordinal outcome (too small / fits / too large) from the gap, so that a recommendation maximises probability of "fits". Academic work from Amazon and Zalando-linked research uses Bayesian and deep latent-factor models with return reasons as labels [5].
• Cold start: new shoppers (few orders), new items (no returns yet) and new brands are handled by priors from garment measurements, questionnaires and similar items; confidence is shown or the widget abstains.
• Data caveat: a kept item is not necessarily a fit; returns are noisy labels (gifts, quality, taste). Return-reason codes and post-purchase fit feedback improve labels.
• Human-in-the-loop: merchandisers review flagged styles and decide chart or product changes; shoppers always choose the final size.

Data preparation

The key data are order, return and return-reason history per shopper and SKU, garment measurement tables and size charts per style, and optional shopper questionnaire answers. In an SMB these live in the shop system, ERP or merchandise system and supplier PDFs or Excel size charts. Typical gaps are free-text or missing return reasons, size charts that differ from real garment measurements, inconsistent size labels across suppliers and brands, guest checkouts that cannot be linked to history, and too few orders per SKU.

Preparation steps: - Export orders and returns and unify size codes (PREP-005, PREP-011). - Standardise return reasons into a short list such as too small, too large, quality (PREP-019) and label past returns (PREP-020). - Digitise supplier size charts into a structured table, measured on real garments (PREP-007). - Add measurement fields at style level to the product master (PREP-010). - Pseudonymise body-related data (PREP-022).

Expect around 40 percent of the effort in size-chart and return-reason clean-up. Products that bring pooled fit data reduce the need for own history.

Implementation paths

Which path for whom

• SMB (A): Size-advisor plug-ins for common shop systems exist at SMB prices and bring pooled fit data that a small shop lacks itself.
• Enterprise (B): Own return and fit data is large enough for custom models integrated with the shop, ERP and merchandising.
• Developer (B): Cloud ML APIs with your own garment measurement data suit embedding a size advisor into your product.

Path A — Buy (recommended for most SMBs)

• Fit platforms: Snap Fit Analytics (Snap Inc.; EU roots), True Fit (US), Bold Metrics (US), plus size apps in the Shopify/Shopware app stores.
• Check: GDPR role (processor vs joint controller, since vendors pool cross-retailer data), EU hosting, API for the data feed, merchandising dashboard, A/B-test support, abstention behaviour.
• Choose A when: under a few million orders per year, no data-science team, fast time to value.

Path B — Build on cloud APIs

• Tabular/recommender stack: BigQuery, Snowflake or Databricks (EU regions) with gradient boosting or a small ordinal/latent model; managed ML (Vertex AI, SageMaker, Azure ML) for training and serving.
• Body estimation from photos: a cloud VLM or pose/measurement API is possible but raises privacy burden; prefer on-device processing.
• LLM use: natural-language fit explanations and review mining ("runs narrow in the shoulders") with a multilingual LLM (Mistral as EU provider, or Claude/Gemini/GPT in EU regions); structured extraction of fit statements from reviews and return comments.
• Choose B when: you own rich order/return data and want control without hosting GPUs.

Path C — Self-host (open source)

• Models: LightGBM/XGBoost/CatBoost, PyTorch or implicit/LightFM-style factor models; Pyro/Stan for Bayesian latent size. For review mining, a small open model (Qwen, Mistral, Llama class, ≤8B).
• Pose/body: MediaPipe Pose for on-device keypoints; check licences of any parametric body model.
• Hardware: HW1 (CPU server) is enough for tabular fit models; HW2 only for photo or LLM parts.

Path D — Custom training

Worth it above roughly millions of orders with return reasons: train per-category latent-fit models, calibrate probabilities, use a bandit/uplift layer to decide when to show advice (see causal-inference). Needs two or more years of order/return history and clean garment-measurement data.

State of the art (2026)

• Models: ordinal/latent-fit and deep metric-learning models, trained on purchase-return outcomes, remain the workhorse; LLMs add review/return-comment mining and explanations rather than the core prediction.
• Garment data matters most: accurate measurement tables per size and grading rules usually beat model sophistication. Many errors come from wrong size charts.
• Photo-based body measurement is improving on smartphones but adoption is limited by privacy concerns and accuracy for loose or stretch garments.
• Limits and failure modes: cold start; sparse data for small brands; returns as noisy labels; stretch fabrics and fit-preference (slim vs relaxed); bias toward majority body shapes and sizes (plus-size and petite under-served); shoppers who deliberately bracket; feedback loops (advice changes the data used to train the next model).

Shared resources & combinations

• Same data and stack as: REC-001 (product recommendations), PRED-020 (return prediction and return-rate reduction), ANOM-033 (returns fraud). One order/return data mart with return reasons serves all.
• Combine with: GEN-010 (virtual try-on, visual fit), VIS-037 (returned-item grading, resale), VIS-026 (measurement from images), REC-003 (next-best-action at checkout).
• Hardware: tabular models run on HW1; shares the feature store with other retail-ML cases.

Effort, cost & KPIs

• Path A: 2-8 weeks for catalogue feed, widget integration and test; SaaS pricing usually per order, per session or per SKU (get quotes).
• Path B/C: 3-6 months incl. data cleaning of size charts and A/B framework; small team (data scientist, engineer, merchandiser).
• KPIs: size-related return rate (by return reason), total return rate, conversion rate of users who use the widget vs control, share of bracketed orders, fit-advice acceptance rate, cost per return, CO2 from avoided returns, share of SKUs with corrected size charts. Use randomised holdouts; users who open a fit widget self-select and inflate naive comparisons.

People & change

Involve management for the return-cost goal, e-commerce and merchandising leads as process owners, and customer service, who see return reasons first. IT integrates the widget or API with the shop; suppliers deliver measurement data. The DPO is needed because shopper body data (height, weight) is personal data: legal basis or consent, AVV with the vendor, and a DPIA check if body scans or photos are used.

Works council: no, as the system advises customers; staff are not monitored. Inform it in time anyway if workflows in customer service or warehouse change (§90(1) no. 3 BetrVG).

AI literacy: support customer service with a short briefing on how recommendations arise, their confidence and limits (AI Act Art. 4 supports, no guaranteed level). Pilot with one category such as jeans or shoes, and an A/B test on return rate. Typical concerns are privacy and wrong advice; address them with optional input, clear explanations, show the confidence and keep a manual size chart and an easy size exchange. Customers always keep the final choice, and staff can override.

See GUIDE-005, GUIDE-009 and GUIDE-011.

Risks, regulation & compliance

• EU AI Act: minimal risk for a size recommender; AI literacy (Art. 4) applies. If the body-photo variant infers biometric categories or emotions it would leave this scope. Do not infer sensitive attributes. Plain body measurement for sizing is not biometric identification, but keep it separate from face recognition features [6].
• GDPR: purchase history, body measures and photos are personal data; body and weight data can approach health data (Art. 9) in some contexts. Use consent or contract basis with purpose limitation, data minimisation (store derived measures, delete photos immediately, prefer on-device), a DPA with the fit vendor, and clarity on pooled cross-retailer profiles [7]. A DPIA is advisable for photo scans.
• Consumer law: EU 14-day withdrawal right for distance sales (Directive 2011/83/EU) is why returns are costly; advice must not mislead (UCPD). Do not use fit data to penalise returners without transparency; "returns abuse" scoring (ANOM-033) needs separate review for fairness and Art. 22 GDPR if it leads to automated adverse decisions.
• Bias: test accuracy across sizes, genders, ages and regions; offer manual override and inclusive size ranges.
• Mitigations: show confidence, allow "I'm between sizes" answers, log recommendations vs outcome.

Getting started

1. Baseline the data: return rate by reason, share of "too small/large", bracketing rate, per category.
2. Audit garment measurement tables and size charts for your top 100 SKUs; fix errors first.
3. Pilot a Path A widget on one category with a 50/50 randomised A/B test over 8-12 weeks.
4. Send the fit-issue SKU list to merchandising and suppliers monthly; track chart corrections.
5. Decide data policy (consent, retention, DPA, no photo storage) before enabling body-scan features.

Sources

1. Zalando — company reporting on size advice and returns (about 8% of size-related returns prevented in 2025, company-reported, article of 22 Jun 2026) — https://corporate.zalando.com/en/node/11013
2. Snap Fit Analytics (Snap Inc.) — https://www.fitanalytics.com/
3. True Fit — https://www.truefit.com/
4. Bold Metrics — https://boldmetrics.com/
5. Sembium et al., "Recommending Product Sizes to Customers", RecSys 2017 — https://dl.acm.org/doi/10.1145/3109859.3109891
6. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
7. Regulation (EU) 2016/679 (GDPR) — https://eur-lex.europa.eu/eli/reg/2016/679/oj
8. Directive 2011/83/EU on consumer rights — https://eur-lex.europa.eu/eli/dir/2011/83/oj