Unit conversion errors are some of the most expensive mistakes in product data. A weight field off by a factor of 1,000 breaks every shipping cost calculation downstream. Dimensions in centimeters when your channel expects millimeters means every product listing is wrong. And when customers receive items that don't match the listed specs, the returns start piling up.
The frustrating part is that unit conversion is conceptually simple — it's just multiplication. But in practice, supplier data makes it anything but straightforward. This guide walks through how to handle unit conversion systematically so it stops being a source of silent data errors.
Why Units Are Messy in Supplier Data
If every supplier sent data in the same units with the same formatting, this article wouldn't need to exist. Here's why they don't.
Local conventions vary
A German supplier sends dimensions in centimeters and weights in kilograms. A US supplier uses inches and pounds. A UK supplier might use a mix of both. Each is perfectly reasonable in their own context — and completely inconsistent with the others.
Units hide in different places
Sometimes the unit is in the column header: Weight (kg). Sometimes it's embedded in the cell value: 2.5 kg. Sometimes it's in a separate documentation PDF. And sometimes it's just assumed — everyone "knows" Supplier X sends dimensions in millimeters, until the day a new person on the team doesn't know that.
| Where the unit lives | Example | The problem |
|---|---|---|
| Column header | Weight (kg) → 8.5 | Easy to miss when mapping columns |
| Cell value | weight → 8.5 kg | Must parse and strip before converting |
| Separate documentation | "All dimensions in cm" | Documentation gets lost or outdated |
| Assumed / tribal knowledge | "Dave knows it's in grams" | Dave goes on holiday |
Mixed units within the same column
This is the worst case. Some rows have values in centimeters, others in millimeters — in the same column. This usually happens when a supplier merges data from multiple internal sources, or when someone manually edits a few rows without realizing they're using a different unit.
Decimal precision varies
One supplier sends 2.50 kg, another sends 2.5, another sends 2.500. When you're trying to detect units automatically or compare values across sources, inconsistent precision creates noise.
Common Unit Conversions in E-Commerce
Here are the conversion factors you'll use most often. Keep this table handy — you'll reference it more than you'd expect.
| Category | From | To | Multiply by |
|---|---|---|---|
| Length | mm | cm | 0.1 |
| cm | mm | 10 | |
| m | mm | 1,000 | |
| inches | mm | 25.4 | |
| Weight | g | kg | 0.001 |
| kg | g | 1,000 | |
| lb | kg | 0.4536 | |
| oz | kg | 0.02835 | |
| Volume | ml | L | 0.001 |
| fl oz | L | 0.02957 | |
| gallons (US) | L | 3.785 | |
| Temperature | °C | °F | ×1.8 + 32 |
| Area | cm² | m² | 0.0001 |
| sq ft | m² | 0.0929 |
Length and weight come up on almost every feed. Volume matters for beverages, cleaning products, cosmetics. Temperature is relevant for food storage and some electronics specs. Area shows up in textiles, flooring, and anything sold by coverage.
A Unit Conversion Checklist
Here's a step-by-step process that works whether you're doing this in a spreadsheet or an automated tool. Each step includes a before/after example using a real scenario: converting supplier weight data to your standard of kilograms with two decimal places.
Step 1: Define your target units per attribute
Before touching any supplier data, decide what your canonical units are. Document them. Make sure everyone on the team knows.
| Attribute | Target unit | Precision |
|---|---|---|
| weight | kg | 2 decimal places |
| width / height / depth | mm | integer |
| volume | L | 3 decimal places |
| area | m² | 2 decimal places |
This sounds obvious, but many teams skip it. Without an explicit standard, you'll end up with some products in mm and others in cm in the same catalog.
Step 2: Detect the source unit
For each supplier column that contains a measurement, figure out what unit the data is in. Check the column header, sample a few cell values, and read any supplier documentation.
Example: Supplier A has a column called Weight (kg) with values like 8.5. Supplier B has a column called weight with values like 8500 g. Supplier C has wt with values like 18.7 — and after checking their docs, it turns out that's in pounds.
Step 3: Strip unit suffixes from values
If the unit is embedded in the cell value, you need to extract the numeric part before you can do math on it.
| Raw value | After stripping | Detected unit |
|---|---|---|
8500 g | 8500 | g |
2.5kg | 2.5 | kg |
15.7 inches | 15.7 | inches |
40cm | 40 | cm |
Watch out for decimal separators here: 2,5 kg (European format) needs to become 2.5 before conversion, not 25.
Step 4: Apply the conversion factor
Now the actual math. Multiply the numeric value by the appropriate conversion factor.
| Source value | Source unit | Conversion | Result |
|---|---|---|---|
| 8500 | g | × 0.001 | 8.5 kg |
| 18.7 | lb | × 0.4536 | 8.48 kg |
| 40 | cm | × 10 | 400 mm |
| 15.7 | inches | × 25.4 | 399 mm |
Step 5: Round appropriately
Raw conversion results often have long decimal tails. 18.7 × 0.4536 = 8.48232. Your target precision should determine how you round.
Weight to 2 decimal places: 8.48232 → 8.48. Dimensions to integers: 398.78 → 399. Be consistent — don't round some products to 2 decimals and others to 4.
Step 6: Validate the result
This is the step most people skip, and it's the one that catches the biggest mistakes. After conversion, sanity-check the output against reasonable ranges for the product category.
| Product | Attribute | Converted value | Verdict |
|---|---|---|---|
| Dining chair | weight | 8.48 kg | Reasonable |
| Dining chair | weight | 0.0085 kg | Wrong — probably source was in grams, not kg |
| T-shirt | weight | 200 kg | Wrong — probably source was in grams, treated as kg |
| Bookshelf | width | 8 mm | Wrong — probably source was in cm, treated as mm |
A simple range check per product category catches most of these: chairs weigh 2–30 kg, not 0.008 or 8,000. Shelves are 300–2,000 mm wide, not 8. If a converted value falls outside a plausible range, flag it for review.
The Tricky Cases
The checklist above handles straightforward conversions. Here are the cases that require extra attention.
Dimensions packed into a single string
Suppliers frequently send all three dimensions in one cell: 60 x 40 x 30 cm. You need to split this into separate attributes and convert each value.
| Raw value | width | depth | height |
|---|---|---|---|
60 x 40 x 30 cm | 600 mm | 400 mm | 300 mm |
23.6" x 15.7" x 11.8" | 599 mm | 399 mm | 300 mm |
0.6 x 0.4 x 0.3 m | 600 mm | 400 mm | 300 mm |
The challenge isn't the math — it's knowing which number maps to which dimension. Does the supplier list width first, or length? Is the order consistent across all their products? You'll need to verify this against their documentation or spot-check against product images.
Compound units
Some attributes use compound units that don't convert with a single multiplication factor:
- Fabric weight:
g/m²(grams per square meter) — also known as GSM - Density:
kg/m³ - Flow rate:
L/min - Pressure:
PSIvsbar
Converting these requires converting the numerator and denominator units separately. 150 g/m² is already a standard unit in textiles, so often the right move is to just standardize on a single compound unit rather than trying to convert between them.
Currency: not a unit conversion, but often confused with one
Price "conversions" between currencies are fundamentally different from unit conversions because the rate changes daily. Treating EUR-to-USD like kg-to-lb (a fixed factor) will cause pricing errors. Currency conversion belongs in a separate process with live or regularly updated exchange rates — not in your unit conversion rules.
Ambiguous values
What does 12 mean in a weight column with no unit indicator? It could be 12 kg, 12 lb, 12 g, or 12 oz — and the correct interpretation changes the result dramatically. When you encounter truly ambiguous values, the safest approach is to flag them for manual review rather than guessing.
Automating Unit Conversion
Like most product data tasks, unit conversion is straightforward the first time and painful the fiftieth time. The conversion factors don't change. Your target units don't change. What changes is the supplier data arriving month after month, requiring the same detection, stripping, conversion, rounding, and validation steps.
FeedPrep lets you define unit conversion rules per supplier attribute — specify the source unit, the target unit, and the precision, and it handles the rest on every future feed import. When a value falls outside your expected range, it gets flagged in your review queue instead of silently flowing into your catalog.
But whether you use FeedPrep or build your own process, the principle is the same: define your target units once, document your source units per supplier, and automate the conversion so humans only need to handle the edge cases.