A product spec change checklist is not admin work — it is the gap between a 20 mm revision and a container of disputes. Change one dimension and you have changed a number that is already published in at least nine places. Most suppliers update two: the listing field they remember, and nothing else.
Everything else keeps broadcasting the old figure. The feed. The image. The PDF your sales rep emailed last week. The carton mark. The manual sealed inside the box. None of them will tell you they are wrong. The buyer will, usually after the container has sailed.
The 9 places one dimension lives
A product spec change checklist is a fixed list of every place a dimension, weight or material figure is published, used so that one revision reaches all of them before somebody downstream finds the mismatch. Here is the list, ordered by how fast each one hurts.
| # | Where the number lives | Field or artifact | Who reads it | What breaks when it is stale | Realistic lag to fix |
|---|---|---|---|---|---|
| 1 | Marketplace item attributes | Product / item dimensions shown on the detail page | The buyer, before clicking buy | Wrong-size returns, "not as described" claims | Minutes |
| 2 | Marketplace package attributes | Package or shipping dimensions | The carrier and the fee engine | Wrong shipping quotes, fee reconciliation gaps | Minutes |
| 3 | Shopping feed | product_length / product_width / product_height / product_weight |
Google Shopping, comparison engines, AI shopping agents | Item drops out of size-filtered queries; feed warnings | Next feed run |
| 4 | Structured data on your own site | schema.org width / height / depth |
Search engines and answer engines | Your own site contradicts your own listing | Next deploy |
| 5 | The product image or spec diagram | Pixels — the number is burned in | Every buyer, first, before any text | The loudest wrong number on the page | Days, if a designer is involved |
| 6 | Enhanced content and comparison charts | Module copy and module images | Buyers who scroll past the gallery | Silent contradiction inside your own listing | Days, often re-approval |
| 7 | Catalog, line sheet, quotation | The PDF your team pastes into email | B2B buyers, sourcing agents, distributors | You quoted the superseded number in writing | Whenever someone remembers |
| 8 | Shipping documents and carton marks | Carton dimensions, net and gross weight | Customs, forwarder, receiving team | Container plan wrong, cargo held or rejected | Per shipment |
| 9 | Manual, assembly sheet, packaging artwork | Printed and already in stock | The end user, after delivery | Support tickets and one-star reviews | Next print run |
Nine places, five different owners, lag times running from minutes to a print run. That asymmetry is the whole problem: the fields you can fix in seconds are the ones you remember, and the ones that take days are the ones buyers see first. Any product spec change checklist that does not name an owner per row is a wish list.
A stale dimension does not stay a data problem. It becomes a return, and returns have a price per unit that most sellers have never actually calculated — the return cost calculator turns a return rate into the figure a finance team reacts to.
Why the same product has more than one correct number
Before you audit nine places, accept an uncomfortable fact: two of those places can disagree and both still be right. The GS1 rules that govern shared product data force specific rounding, and they round in one direction only.
Per the GS1 GDSN Package Measurement Rules Standard (Release 2.5, ratified September 2016):
- Millimetres are always rounded up to a whole millimetre. 99.3 mm becomes 100 mm.
- Inches are always rounded up to the nearest 0.05 inch. 2.942 inches becomes 2.95 inches.
- When converting between systems, convert first and round second, using 1 inch = 25.4 mm.
- All three linear dimensions must use the same measuring system and the same unit.
- Always measure the maximum distance — projections, caps, lids and attached on-pack extras are included, not ignored.
Read those together and the consequence is obvious. A 99.3 mm part is published as 100 mm in a GDSN-fed system and as 3.95 inches in an imperial market — and your drawing still says 99.3. Three numbers, one part, no error.
The standard also publishes tolerances. For non-consumer trade items such as a case unit, the GS1 standard tolerance is 4.0% on each of depth, width and height, with a floor of 0.25 inch (7 mm), and 4.0% on gross weight with a floor of 0.2 lb (0.1 kg). A revision smaller than that may not need to move the case data at all. A revision larger than that means every system holding the old figure is out of tolerance, not merely out of date.
One more source of legitimate disagreement: axis naming. GS1 determines height, width and depth from the item's default front — the surface the brand owner uses to promote the product. Your factory drawing almost certainly uses length, width and height from a different reference entirely. Which axis is which, and why buyers misread the order, is its own trap — see length, width, height order before assuming the buyer reads your triplet the way you wrote it.
Product dimensions and shipping dimensions are not the same field
This is the single most common failure in the whole checklist, because both fields accept a number and neither complains.
Google Merchant Center keeps them completely separate, and the two sets do not even share a valid range:
| Product measurement attributes | Shipping dimension attributes | |
|---|---|---|
| Attributes | product_length, product_width, product_height, product_weight |
shipping_length, shipping_width, shipping_height |
| What it describes | The product itself | The package the product ships in |
| Units accepted | cm, in (weight: lb, oz, g, kg) | cm, in |
| Value range | 1–3000 for cm and in | 1–400 cm, 1–150 in |
| What it is used for | Product discovery and accuracy of results | Carrier-calculated shipping rates |
| Hard rule | Use the same unit across all three, or the information will not be displayed | Include all dimension attributes if you include any of them |
The range difference is the tell. A field that tops out at 400 cm was never meant to hold a product dimension, and a field that accepts 3000 cm was never meant to price a carton. If someone on your team has been pasting the same triplet into both, one of them is wrong right now.
Structured data adds a third vocabulary. On schema.org a Product has width, height and depth — no length property exists — each expressed as a QuantitativeValue with a unitCode. One revision, three naming conventions, three systems, three people who never see each other's screens. If nobody has filled these in on your own site, product dimensions structured data is the cheapest of the nine to fix.
Marketplaces add one more wrinkle: Amazon publishes each product type's attributes as a JSON schema through its Product Type Definitions API, so a dimension field that exists for one product type is not guaranteed to exist for another. "Update the dimensions everywhere" is not one action. It is one action per schema.
The place that never gets updated is the image
Look back at the table. Rows 1 through 4 are text fields — an operations person changes them before lunch. Rows 7 through 9 are documents, and everyone accepts that documents need a revision.
Row 5 is the one that stays wrong for years, because the number lives in pixels. Changing it means finding the source file, finding whoever made it, briefing the change, waiting, checking, re-uploading to every channel. So the honest answer inside most companies is: we will fix the image next time we reshoot. There is no next time.
That is expensive, because the image is the first thing the buyer reads and the last thing anyone audits. A spec table gets skimmed. A dimension printed on the photo gets believed.
The practical fix is to stop treating a spec diagram as artwork and start treating it as a view of your data: measure once against the real edges of the product, keep the annotation layer live and editable rather than flattened into a JPEG, and re-export at each channel's image spec when a number changes. Done that way, row 5 collapses from a design job to a two-minute edit — the only reason it will actually get done.
The tooling choice decides whether that is realistic. Software that measures — snapping a dimension line to the real edge of the object and keeping the number bound to that geometry — updates correctly when you change the input. An image generator that produces a plausible-looking annotated photo measures nothing; it invents a figure that reads as reasonable and cannot be checked. For a marketing background that is a fair trade. For the number a buyer will hold you to in a claim, it is not. Same logic for the spec sheet attached to a quotation: the value is not that it looks designed, it is that every figure on it traces to a measurement.
The product spec change checklist
Copy this product spec change checklist into your change ticket. One pass, four groups, nobody guessing who owns what.
Source of truth
- The revised figure is recorded once, with a revision number and date, in the file everything else copies from
- The unit and measuring system are stated explicitly (mm or inch — not "1180")
- The measurement includes projections, handles, caps and lids, per GS1 maximum-distance rule
- You have checked whether the change exceeds the 4% / 7 mm case tolerance, which decides how far downstream it must travel
Fields the buyer sees
- Marketplace item / product dimensions updated on every marketplace, not just the biggest one
- Package or shipping dimensions updated separately, and confirmed to be the package figure
- Shopping feed product attributes updated; feed re-fetched and warnings checked
- Structured data on your own product page updated
Artifacts
- Spec diagram or annotated photo re-exported and re-uploaded to every channel that hosts it
- Enhanced content, comparison charts and any image containing the old number replaced
- Catalog, line sheet and quotation template regenerated; old PDF removed from shared drives and email templates
Paper and print
- Packing list, commercial invoice and carton marking templates updated for the next shipment
- Manual, assembly sheet and packaging artwork flagged for the next print run, with existing stock counted
- Open quotations issued with the superseded number identified, and the affected buyers told before they find out
Order of operations
Sequence matters more than speed, because some of these steps cache and some of them are read by machines.
- Freeze the source of truth first. If two people are still editing the number, everything below inherits the disagreement.
- Update the buyer-facing marketplace fields. Fastest to change, fastest to hurt.
- Re-export the image before you touch the feed. Feeds and caches pick up the new image URL on the same cycle as the new numbers, so a mismatch window never opens.
- Push the feed and re-fetch. Confirm the item is not sitting in warnings; a rejected item is worse than a stale one.
- Regenerate documents. Catalog, line sheet, quotation template — and delete the old file rather than renaming it.
- Print last. Print runs are the only irreversible step in the list.
Then do the one thing almost nobody does: search your own product name and read your own listing as a buyer, on a phone, without logging in. The contradiction you missed will be visible in about eight seconds.
FAQ
How do I update product dimensions on a listing without losing the ranking?
Edit the attribute in place. Changing a data field is not republishing the item, so the listing's history survives. What does cause damage is deleting and recreating the listing to "start clean," which discards reviews, sales history and the identifier buyers have bookmarked.
What is the difference between item dimensions and package dimensions?
Item or product dimensions describe the product itself, and buyers use them to decide whether it fits. Package or shipping dimensions describe the box it travels in, and carriers use them to price the shipment. Google Merchant Center enforces the split at the schema level: product_length and its siblings accept values up to 3000 cm or inches, while shipping_length and its siblings top out at 400 cm or 150 inches.
Do I have to change the product image when a dimension changes?
Yes, and it is the highest-priority artifact in the list, not the lowest. A number printed on an image is read before the spec table and carries more weight in a dispute, because a buyer can point at it. If your annotation is flattened into a JPEG with no editable source, this is the moment to rebuild it as a live layer over the photo so the next revision takes minutes.
How much can a dimension change before I have to tell the buyer?
Commercially, tell them for any change that affects fit, clearance or stacking — that is a judgement call, not a threshold. For shared product data there is a published reference point: the GS1 standard tolerance for a case unit is 4.0% per dimension with a 7 mm floor. A change inside that band is data noise. A change outside it means every system holding the old figure is out of tolerance.
Which unit should I publish, millimetres or inches?
Publish the system your target market requires, and publish all three axes in that same unit — GS1 requires the three linear dimensions to share one measuring system and one unit. When you convert, convert first and round second, using 1 inch = 25.4 mm, then apply the round-up rule for that unit. Converting a pre-rounded number is how a 3 mm error becomes a 6 mm error.
Sources & References
- Google Merchant Center Help — Product length, product width, product height, product weight: units, formats and value ranges
- Google Merchant Center Help — Shipping length, shipping width, shipping height: accepted units and value limits
- GS1 — Package and Product Measurement Standard (current standard)
- GS1 — GDSN Package Measurement Rules Standard, Release 2.5 (ratified September 2016): rounding rules, default front, and standard tolerances
- schema.org — Product: width, height, depth and QuantitativeValue properties
- Amazon Selling Partner API — Product Type Definitions meta-schema (attributes are defined per product type)