E-commerce
June 28, 2026
The customer opens the size guide, closes the tab, and returns to the S/M/L selector. They are still hesitating. A static table doesn't recommend anything: it displays numbers without saying "take the M".
An AI size recommendation chatbot transforms your product data (measurements, fit notes, reviews, stock) into personalized advice before the cart. Zalando estimates that fit accounts for up to half of fashion returns in Europe (Zalando, sizing 2025).
This guide #199 covers AI-based size recommendation: required data, mapping logic, limitations, and quality measurement. Distinct from size guide chatbot (#5) (display and return reduction) and human support sizing (#128): here, we focus on the recommendation architecture + data limits.
Summary
Why switch from the size guide to AI recommendation?
The size guide informs. The size recommendation decides. This difference changes the conversion and the wrong-size return rate.
What the customer expects in 2026
A specific size: "Take M", not "consult the chart"
A short explanation: slim fit, stretch fabric, customer reviews
An alternative: between two sizes, which one to prefer
A plan B: free exchange, return if mismatched
McKinsey estimates that about 70% of apparel returns are due to fit or style (Vircab, apparel returns 2026). The NRF places the e-commerce return rate around 19.3% in 2025 (NRF, Retail Returns 2025).
A well-calibrated sizing bot does not replace trying on clothes. It reduces bracketing (ordering two sizes "just in case") by converting uncertainty into a traceable recommendation.
How does it differ from the chatbot guide (#5) and human support (#128)?
Three neighboring pieces of content, three levels of depth.
Chatbot Size Guide (#5)
Chatbot size guide (#5) covers fit notes, measurements, bracketing, and reducing wrong-size returns. #199 delves deeper into the recommendation logic and the data limitations that prevent a bot from "guessing".
Human Sizing Support (#128)
Sizing support (#128) structures agent macros, PDP UX, and ticket workflows. #199 automates the recommendation; #128 handles escalation when the bot reaches its limits.
General Guided Selling (#150)
Guided selling (#150) guides towards a product. Here: a size variant on a SKU that is already open.
Promise #199
Data schema, question flow, mapping rules, edge cases, recommendation quality governance, bot fit KPIs.
What is the minimum data required to recommend a reliable size?
An AI recommendation without clean product data produces silent errors. The bot must never extrapolate beyond what you provide.
Product layer (mandatory per pilot SKU)
size_chart: min/max measurements per variant (cm)
fit_note: runs small, normal, runs large
cut_type: slim, regular, relaxed, oversize
fabric_stretch: rigid, low stretch, high stretch
model_size: size worn + model measurements
stock_by_variant: real-time availability
Customer layer (zero-party data)
usual_size: usual size in this category
reference_brand: "I wear M at [brand X]"
measurements: chest, waist, hips (optional)
fit_preference: fitted vs comfortable
On Shopify, structure via product and variant metafields (Shopify, metafields). Without structured fit_note and size_chart, the bot simply reformats the PDF table: zero recommendation value.
Feedback layer (continuous enrichment)
Reviews filtered for "runs small/large", Loop sizing return reasons, prod_size_fit tagged tickets. Feeds into the product support data flow (#198).
How can you structure the question flow without driving the client away?
The size recommendation flow must take less than 90 seconds on mobile, on an already opened PDP.
Minimal tree (4 branches)
Product context: bot knows the SKU, cut, fit note (no useless questions)
Usual size: "What size do you wear in [jeans/dress]?"
Fit preference: fitted or comfortable (skip if explicit fit note)
Between two sizes: yes/no → tie-break rule section 6
Early stop rule
If usual_size + product fit_note are enough to map a variant with confidence > 85%, recommend immediately. Ask for chest/waist/hips only if usual_size is missing or for technical products (sports, suit).
Recommendation formulation
Template: "For this [product], cut [X], we recommend size M. Reason: [fit note + customer reviews]. If you prefer a looser fit, take L. Free size exchange within 30 days: [link]." One recommendation, one plan B, one policy.
PDP opening trigger
Nudge after 25 s on the size selector without click, or click "Size guide" without add-to-cart. Avoid immediate popup: allow 10 s of product sheet reading.
What is the mapping logic from measurements to SKU variant?
The SKU size mapping is not an LLM intuition. It is a deterministic rule powered by your data, which the bot explains in natural language.
Standard algorithm (deterministic first)
Convert standard reference usual_size into a measurement range (internal brand table)
Apply fit_note offset: +1 if "runs small", -1 if "runs large"
Apply fit_preference offset: +1 if comfortable on a slim fit
Match variant whose measurement interval contains the customer
Check stock; otherwise suggest adjacent size available
Numerical example for slim jeans
Slim jeans SKU, fit_note "true to size", slight stretch. Customer: standard M, fitted preference, waist circumference 82 cm. Table: M = 80-84 cm, L = 84-88 cm. Mapping → M. If fit_note "runs small": offset +1 → L. The bot quotes the rule, not an hallucination.
Role of the LLM
The model reformulates, asks the right questions, and manages the brand tone. The recommended size comes from the rules engine. 2026 Pattern: LLM + deterministic fit engine, not LLM alone.
How do you handle edge cases without over-promising?
Sizing edge cases generate 80% of human escalations. Anticipate them in the bot flow.
Between two sizes
Default rule: if hesitating between S/M, recommend M for slim + stretch fit, S for oversize. Always explain: "Customers between two sizes take M for this model" (if review data confirms it). Explicitly offer free exchange.
External brand reference
"I wear a 38 at Zara": without a cross-brand table, the bot asks for measurements or usual_size in your brand. Never map Zara → your grid without a validated table.
Atypical morphology, pregnancy, technical sport
Confidence threshold < 70%: human handoff with context (measurements, SKU, questions asked). See bot → human context transfer.
Multi-category
Dress size ≠ jeans size. The bot must ask for the category or read the Shopify product_type before recommending.
What are the data and legal limits that should not be exceeded?
An AI size recommendation commits your brand. Limits must be hardcoded, not left to the model's discretion.
Data limits
No size_chart: bot displays guide + handoff, no invented size
Out of stock: only recommend available sizes or stock return alert
New product without reviews: mention uncertainty, fit note mandatory
Confidence < threshold: "I cannot recommend with certainty" + agent
Legal and ethical limits
Do not ask for weight/body height if not necessary for the product. Avoid comments on body shape ("for your build"). GDPR: measurements = sensitive data if linked to identity; minimize storage, clear consent, short retention period. See privacy support e-commerce.
Useful disclaimers
"Indicative recommendation based on your answers and our size guide. Free exchange if the size does not fit." Reduces litigation burden and aligns customer expectations.
Bot responses audit
Monthly review of 50 sizing conversations: recommended size traceable, no SKU invention. Chatbot responses audit.
How to measure the quality of size bot recommendations?
Without fit KPIs, you won't know if the bot is helping or worsening returns.
Primary KPIs (30-90 days)
Post-purchase CSAT Fit: Day+7 survey "does the size fit?"
Wrong-size return rate: sizing bot sessions vs. control
Add-to-cart conversion: PDP with recommendation vs. without
Bracketing rate: multi-size orders of the same SKU
Handoff rate: % of conversations escalated to a human
Simple A/B Method
50% PDP traffic in pilot category with sizing bot, 50% without. Duration 4 weeks, minimum 2,000 sessions/arm. Zalando observed up to a 40% reduction in sizing-related returns on virtual fitting room pilots (Zalando, virtual fitting).
Data Feedback Loop
Each return with the reason "too small/too large" + bot conversation_id → adjust SKU fit_note offset. Goal: wrong-size return rate with bot-engaged -15% vs. baseline at Week+12.
How to integrate stock, exchange, and PDP experience?
The size recommendation lives on the PDP, not in a chatbot silo.
Real-time stock sync
Shopify variant inventory API before each recommendation. If M is out of stock: "M unavailable, L available with slightly looser fit" or back-in-stock alert. Never recommend a sold-out variant.
Exchange policy in the flow
After recommendation, reminder: "Free size exchange within 30 days" with return portal link. Reduces anxiety and bracketing. Align with bot return prequalification.
Post-recommendation UX
Variant pre-selection: bot clicks size M in the selector
Sticky recap: "You chose M based on assistant's advice"
Re-open flow: "Change my size" without losing context
Multi-channel consistency
Same sizing logic on site chat, Instagram DM and WhatsApp support. Single mapping table, multiple surfaces.
What errors are still causing wrong-size returns?
Even with a bot, these bot sizing errors keep happening without governance.
Error 1: LLM alone without a rules engine
The model "guesses" M because the customer mentioned M elsewhere, without reading the fit_note "runs small". Fix: recommendation = rules output, LLM = interface.
Error 2: Obsolete size guide
Spring collection with a new cut, winter chart still in the database. Quarterly audit of size_chart vs actual product sheet.
Error 3: Ignoring return reviews
80% of reviews say "runs small" on the SKU, yet the bot still recommends S by default. Inject review aggregate into offset mapping.
Error 4: No handoff
Complex customer, bot loops 6 questions, abandonment. Threshold of 3 rounds without confidence → agent with transcript.
Error 5: Zero post-launch measurement
Bot deployed, never compared to the Y-1 sizing return rate. Without section 8 KPIs, it is impossible to iterate fit_note and offsets.
How does Qstomy recommend a size on Shopify?
Qstomy combines PDP conversation and a fit engine plugged into your Shopify catalog.
Size recommendation features
Metafields reading: fit_note, size_chart, model_size by SKU
Contextual sizing flow: questions tailored to the product_type
Traceable recommendation: size + reason + pre-selected variant
Human handoff: transcript + measurements if confidence is low
Fit analytics export: volume, conversion, returns by SKU
Quantified DTC Scenario
Women's ready-to-wear brand, 850 orders/month, sizing return rate 31%, rarely consulted PDF guide. Deployment of Qstomy sizing on 40 jeans/dresses SKUs, fit metafields + 4-question flow + stock sync. After 10 weeks (A/B 50/50): pilot PDP conversion +12%, wrong-size returns from bot sessions -19%, bracketing of the same SKU -24%, human handoff 11% of sizing flows.
Explore Shopify integration, AI customer support, request a demo.
Which operational playbooks should be launched in 30 days?
Playbook 1: audit data sizing (1 day)
Select 20 fit-sensitive top-selling SKUs. Verify the presence of fit_note, size_chart, model_size, and stock API. Complete missing fields in Shopify Admin.
Playbook 2: table mapping (half-day)
Sheets: usual_size × fit_note × fit_preference → variant. Validate on 10 real-world cases with a stylist or e-commerce lead.
Playbook 3: 4-question bot flow (2 days)
Draft questions, recommendation templates, disclaimers, and manual handoff thresholds. Test 15 scenarios: slim, oversize, in-between sizes, out of stock.
Playbook 4: 4-week A/B pilot
Activate bot on pilot collection. Track conversion, sizing returns, and bracketing. Weekly review of the top 5 wrong-size SKUs post-bot.
Playbook 5: 30-day feedback loop
Merge Loop returns + prod_size_fit tickets. Adjust fit_note offset for problematic SKUs. Document in Notion sizing changelog.
Useful links
Recommending a size is not about guessing. It is about transforming your product data into customer confidence, with clear limits and continuous measurement.
Enzo
June 28, 2026
