On this page
Ask three teams at a fashion brand what a "fit issue" return means and you will likely get three different answers. Merchandising counts it one way, ops tags it another, and support logs whatever the customer typed into a free-text box. Without a shared fit data dictionary, every report becomes a negotiation instead of a fact.
What Is a Fit Data Dictionary?
A fit data dictionary is a single, versioned reference document that defines every metric, flag, and code your business uses to describe how a garment fits — return reason codes, fit scores, size-recommendation confidence levels, and customer-facing labels like "runs small" or "true to size." It is not a spreadsheet of raw data; it is the contract that says what each field means, who owns it, and how it is calculated.
Think of it as the rulebook that sits behind your fit and sizing reporting. Reporting tells you what happened. The dictionary tells you what the numbers actually mean, so two people looking at the same chart reach the same conclusion.
Why Merchants Need One
Fashion brands routinely lose weeks reconciling numbers that should already agree. A merchandiser pulls a "fit rate" from one dashboard, ops pulls a "return-for-size rate" from a warehouse system, and the two never match because nobody defined the denominator the same way. This is not a reporting-tool problem — it is a governance problem, and governance problems only get solved with definitions everyone signs off on.
Core Metrics Every Fit Data Dictionary Should Define
Start narrow. A dictionary that tries to define everything on day one never ships. Focus on the metrics that already show up in disputes.
| Metric | Definition needed | Common source of disagreement |
|---|---|---|
| Fit score | How size-recommendation confidence is calculated (0-100 or categorical) | Some teams round differently or exclude low-confidence sessions |
| Return reason: size | Which sub-codes count as "size" (too small, too big, wrong fit type) | Support bundles all size issues; ops splits them by SKU attribute |
| Fit rate | Numerator and denominator (orders vs. units, gross vs. net of exchanges) | Merchandising uses gross orders; finance uses net revenue |
| True-to-size flag | Threshold for what counts as "true to size" vs. "runs small/large" | Threshold set by category team without documentation |
| Exchange-for-size rate | Whether exchanges count as returns in aggregate reporting | Ops treats exchanges as neutral; merchandising treats them as failures |
| Size-recommendation acceptance | Whether "accepted" means added to cart or completed purchase | Product team and finance define conversion differently |
Return Reason Codes
Return reason codes are the single biggest source of cross-team confusion because they are entered by humans — warehouse staff, support agents, or customers themselves — under time pressure. A dictionary entry for each code should specify: the exact code string used in your systems, a one-sentence definition, an example customer complaint that maps to it, and the team responsible for auditing it quarterly. If you're also formalizing this into a returns dashboard for your fashion brand, the reason codes in the dictionary should be the literal field values that dashboard pulls from — not a looser approximation.
Fit Scores and Confidence Levels
If you use a size-recommendation engine, document exactly what the fit score represents: is it a probability the recommended size fits, or a similarity score against past purchases? Define the bands (e.g., high/medium/low confidence) and the business rule for what happens at each band — shown to customer, suppressed, or flagged for merchandising review.
How to Build the Dictionary: A Practical Process
Step 1: Inventory Existing Definitions
Pull every place a fit-related term is currently defined — dashboard tooltips, support macros, warehouse SOPs, engineering schemas. You will find contradictions immediately; that's the point. List them side by side before choosing a winner.
Step 2: Assign One Owner Per Metric
Every metric needs exactly one accountable owner, not a committee. The owner approves changes to the definition and is the tiebreaker when two teams disagree. Undefined metrics cause conflicting reports across teams precisely because no one has final say — a well-known failure mode in data governance, where ambiguous ownership is consistently cited as a root cause of inconsistent reporting across departments, as documented in enterprise data-governance research from firms like McKinsey.
Step 3: Write Definitions in Plain Language First
Before writing the technical formula, write one sentence a non-technical stakeholder could understand. Then write the calculation. Both versions live in the dictionary entry — the plain-language version prevents misinterpretation in meetings, and the formula prevents implementation drift across tools.
Step 4: Version and Publish
Treat the dictionary like code: version it, log every change with a date and reason, and publish it somewhere every team can reach without asking. A dictionary buried in one person's private notes is not a dictionary — it's a rumor.
Step 5: Make It the Source of Truth for Every New Report
Once published, any new dashboard, alert, or export must cite the dictionary entry for each metric it uses. This is how you move toward a single source of truth for fit data instead of a permanent patchwork of team-specific spreadsheets.
Common Mistakes That Undermine a Fit Data Dictionary
Brands that attempt this and fail usually make one of these errors:
- Defining metrics in isolation. A definition written by ops alone, without merchandising or support review, gets quietly ignored by the teams that weren't consulted.
- Skipping the audit cadence. Definitions drift as the business changes — new product categories, new markets, new return policies. A dictionary without a quarterly review becomes stale within two quarters.
- Conflating the dictionary with the dashboard. The dictionary defines meaning; the dashboard displays values. Merging them into one document makes both harder to maintain.
- No plain-language layer. Formulas alone exclude non-technical stakeholders from catching errors, which is often how bad definitions survive for years.
Frequently Asked Questions
What's the difference between a fit data dictionary and a data catalog?
A data catalog is a technical inventory of where data lives — tables, fields, schemas — typically maintained by engineering. A fit data dictionary is a business-facing glossary of what fit-related terms mean in plain language, maintained collaboratively by merchandising, ops, and support. Many brands eventually link the two, but they solve different problems.
How often should we update the dictionary?
Review it quarterly at minimum, and immediately whenever you launch a new product category, change your return policy, or adopt a new size-recommendation model. Waiting longer than two quarters almost always results in silent drift, where teams stop trusting shared reports because they no longer match reality.
Who should own the fit data dictionary overall?
Assign one overall steward — often someone in operations or data/analytics — to manage the publishing process and enforce the review cadence, even though individual metric definitions are owned by the relevant functional team. Without a single steward, the document tends to fragment back into team-specific versions within a year.
Does a fit data dictionary help reduce returns?
Indirectly, yes. It won't change a customer's size choice, but it ensures every team is optimizing against the same, correctly defined metrics — so fixes targeting "fit issue returns" actually move the number everyone agrees to track, instead of improving one team's private definition while the shared dashboard stays flat.