The first time I looked at a fashion brand's returns data organized by SKU × size band, the pattern was immediate: one style had zero returns in 3XL and a wall of returns in medium and large. Nobody at the brand had looked at it this way before. They'd been running fit quiz A/B tests for months trying to reduce returns on that exact style. The problem wasn't what consumers selected. The problem was the brand's own size grading — the medium-to-large grade jump in that style was off by enough to produce systematic misfit.
No AI sizing vendor in the world could have fixed it by recommending better sizes. The product data was wrong.
That's the case I keep coming back to when I think about what AI fit prediction actually requires in fashion e-commerce. The vendor ecosystem — True Fit, Bold Metrics, 3DLOOK, WAIR, Perfitly, and others — can deliver real returns reductions. The AI-driven fit prediction market grew to $1.3B in 2025 (en route to $2.95B by 2029, per GlobeNewsWire), and the outcome data when these tools work is real: Bold Metrics claimed a 34% average return reduction in their Gap Inc. partnership, WAIR's 264 Shopify store deployments show 19.4% fewer returns, Perfitly took one partner brand (Otero Menswear) from 28% to approximately 10%. But I've seen enough failed deployments now to know that the tool rarely determined the outcome. What determined the outcome was whether the brand's sizing data was ready when the vendor arrived.
The Heatmap the Vendor Didn't Ask For
I started keeping a mental note of this pattern after seeing it repeated: a brand deep into a vendor evaluation — RFP matrix built, calls scheduled — without anyone having looked at the brand's own returns heatmap first.
The returns-disposition spreadsheet from a 3PL warehouse management system tells a different story than a size guide or a return-reason survey. I've pulled that view on brands' own data and seen the same pattern more than once: a specific style returns in the same two size bands across multiple fulfillment periods, while larger and smaller sizes come back at normal rates. That's not a measurement problem. That's a grading problem. The consumer bought what the size chart said was their size. It didn't fit because the pattern piece and the grade were off. A sizing API that tells shoppers their measurements correspond to a medium in that brand is not wrong; the medium itself is the problem.
The reason this matters for how I think about vendor selection: True Fit's 20-year training corpus — built on $616B in transactions and 91,000+ brand relationships — and Snap's 18,000+ retailer network (built through the $124.4M 2021 acquisition of Fit Analytics) both work by learning what a brand's size means across its historical order and return data. If the brand's own sizing is internally inconsistent, the model learns that inconsistency. It doesn't correct it. The cold-start problem for new brands gets all the attention, but the harder problem is a warm-start on bad data. I haven't heard a single vendor address this in a sales call.
What the API Schema Told Me About Build-vs-Buy
The conversation that changed how I think about build-vs-buy in fit prediction wasn't about which vendor's model was more accurate. It was an API schema review.
I was looking at the interface between a measurement vendor's output and a brand's Shopify product catalog — and the catalog's product-variant mapping was using a static size guide URL as the size field, not a structured data object. The vendor's API had nowhere to send the recommendation because the product's size data wasn't structured in a way the API could write to. That integration gap was a substantial engineering project the vendor's timeline hadn't accounted for, and it wasn't something the RFP process had surfaced.
The brands making agentic sizing work have built the same underlying thing: product size data structured as a graph, not a table. The vendor is the query layer on top of it. Building the graph is the real engineering investment.
Gap's checkout-within-Google-Gemini integration with Bold Metrics and True Fit's Agentic AI shopping agent built on Model Context Protocol (MCP) — launched in March 2026 — both depend on that graph structure: styles, cuts, fabrics, and fits as nodes; size recommendations as weighted edges built from return and exchange history. The Shopify-native approach — WAIR, with 12.5% higher conversion and 19.4% fewer returns across 264 stores — works partly because it sidesteps this complexity by operating within Shopify's existing data model. The tradeoff is scope: it covers what Shopify's schema can express, which isn't always the full fit complexity a brand needs once they start building a proprietary sizing graph.
The Compliance Question Nobody Asked in the Demo
My privacy counsel stopped a vendor evaluation with a question nobody had raised during the review: where the photos were stored, and on what server infrastructure.
We were evaluating a measurement tool that extracts 86 measurement points from two consumer photos. Data residency hadn't come up in the demo. When my privacy counsel raised it, the vendor confirmed processing happened on US-region servers. The brand had EU customers. Under GDPR, 3D body scan data is classified as "special category" biometric data — the same regulatory tier as health records — which means explicit consent, purpose limitation, strict data minimization, and data residency requirements that US servers don't satisfy by default. In Illinois, BIPA imposes collection and disclosure obligations with per-violation statutory damages for the same category of data.
The fix exists: the vendors that handle biometric data carefully offer on-device processing — inference running on the user's device, measurements generated locally, nothing transmitted externally. 3DLOOK's YourFit and Sizekick's video-based scanning offer on-device paths. Perfitly builds from five consumer-provided measurements without photo data transmission. Zalando's virtual try-on pilot with Levi's (claiming up to 40% return reduction, in testing across 14 European markets) and CLO3D's consumer-facing fit visualization — in the 2026.0 roadmap after 860+ companies adopted CLO3D on the design side — are both architected with data residency as a design constraint, not an afterthought.
On-device is not the default. It's an architecture choice to ask about and confirm contractually before the deployment conversation starts. My evaluation framework now opens with that question.
The Right First Question
The question I get asked most by brands starting fit prediction evaluations is which vendor to call first. My honest answer is that the vendor call is the second step.
The first step is building the returns heatmap. Organize SKU-level returns by size band across fulfillment periods. Look for clustering. If a specific style returns at high rates in two adjacent size bands and not in others, that's a grading problem — fix the product data first, because no vendor can help you otherwise. If returns distribute proportionally across size bands relative to sales volume, that's a measurement problem — exactly what the fit prediction vendors are built to solve.
The brands I've seen achieve 25-47% return rate reductions started there. They went into vendor conversations knowing which SKUs were broken and what category of problem they were solving. The ones that skipped the diagnostic got vendor solutions applied to data problems.
The AI fit prediction work we do at Veriprajna starts with the same diagnostic: the pre-vendor heatmap, the data graph architecture review, the compliance question checklist. What does your returns data show when you look at it by SKU × size band? That answer shapes every vendor conversation that follows.