產品規格變更檢核清單：9 個永遠改不乾淨的地方

產品規格變更檢核清單不是行政作業，而是一次 20 mm 修改和一整櫃客訴之間的距離。改掉一個尺寸，你改動的是一個早就公開在至少九個地方的數字。多數供應商只更新兩處：一處是自己還記得的那個商品頁欄位，另一處不存在。

其餘每一處都還在對外播放舊數字。購物 feed、產品圖、業務上週寄出去的 PDF、外箱嘜頭、封在箱子裡的說明書。它們都不會主動告訴你自己是錯的。會告訴你的是買主，而且通常是在櫃子已經開船之後。

同一個尺寸會同時出現的 9 個地方

產品規格變更檢核清單，就是把尺寸、重量、材質這些數字對外公開過的每一個位置固定成一張表，讓一次修改在下游有人發現不一致之前，先跑完所有位置。下表按「多快會痛」排序。

#	數字所在位置	欄位或載體	誰會看到	沒更新會出什麼事	實務上的修正時程
1	平台商品屬性	商品頁上顯示的商品／產品尺寸	買主，在按下購買之前	尺寸不符退貨、「與描述不符」申訴	幾分鐘
2	平台包裝屬性	包裝尺寸或運送尺寸	貨運業者與運費計算引擎	運費報價錯誤、費用對帳對不起來	幾分鐘
3	購物 feed	`product_length` / `product_width` / `product_height` / `product_weight`	Google Shopping、比價引擎、AI 購物助理	商品從尺寸篩選的搜尋結果中掉出去；feed 出現警告	下一次 feed 抓取
4	自家網站的結構化資料	schema.org 的 `width` / `height` / `depth`	搜尋引擎與答案引擎	自家官網和自家商品頁互相打臉	下一次上版
5	產品圖或尺寸示意圖	像素——數字是燒進圖裡的	每一位買主，而且早於任何文字	頁面上最大聲的那個錯誤數字	幾天，如果還要美編處理
6	加強型內容與比較表	模組文案與模組圖片	滑過主圖區繼續往下看的買主	同一個商品頁內部的無聲矛盾	幾天，通常還要重新審核
7	型錄、Line Sheet、報價單	業務直接貼進信裡的那份 PDF	B2B 買主、採購代理、經銷商	你用白紙黑字報了一個已作廢的數字	等有人想起來
8	出貨文件與外箱嘜頭	外箱尺寸、淨重與毛重	海關、貨代、收貨端	裝櫃計畫算錯，貨被留置或退運	每一票出貨
9	說明書、組裝圖、包裝印刷稿	已經印好、還躺在倉庫	終端使用者，收到貨之後	客服工單與一星評價	下一批印製

九個位置、五種不同的負責人、修正時程從幾分鐘到一整批印刷。產品資料變更管理的難處全在這個不對稱：幾秒鐘就能改好的欄位，剛好是你記得的；要花好幾天的，剛好是買主最先看到的。一份沒有在每一列寫上負責人的產品規格變更檢核清單，只是一份願望清單。

過期的尺寸不會停在資料問題這一層。它會變成一筆退貨，而退貨的單件成本，多數賣家其實從來沒有真的算過——退貨成本計算器可以把退貨率換算成財務部門看得懂、也會有反應的那個數字。

為什麼同一件產品會有不只一個正確數字

在盤點這九個位置之前，先接受一個不太舒服的事實：其中兩個位置的數字可以彼此不一致，而且兩個都對。管理共享產品資料的 GS1 規則強制規定了進位方式，而且只往一個方向進。

依 GS1 GDSN 包裝量測規則標準（Release 2.5，2016 年 9 月通過）：

公釐一律無條件進位到整數公釐。99.3 mm 記成 100 mm。
英吋一律無條件進位到最接近的 0.05 英吋。2.942 英吋記成 2.95 英吋。
跨制式換算時，先換算再進位，用 1 英吋 = 25.4 mm。
三個線性尺寸必須使用同一套量測制式與同一個單位。
一律量最大距離——凸出物、瓶蓋、上蓋、隨包裝附掛的贈品都要算進去，不能略過。

把這幾條併著讀，結論很清楚。一個 99.3 mm 的零件，在走 GDSN 的系統裡公布成 100 mm，在英制市場公布成 3.95 英吋，而你的圖面上寫的還是 99.3。三個數字，一個零件，一個錯都沒有。

這套標準也公布了公差。像箱單位這種非消費性交易單位，GS1 的標準公差是深、寬、高各 4.0%，下限 0.25 英吋（7 mm），毛重公差 4.0%，下限 0.2 lb（0.1 kg）。小於這個幅度的修改，可能根本不必動箱規資料。大於這個幅度，就代表所有還存著舊數字的系統不只是「沒更新」，而是「超出公差」。

還有一個合理不一致的來源：軸向命名。GS1 是以產品的預設正面——也就是品牌方拿來推廣這件產品的那一面——來判定高、寬、深。你工廠的圖面幾乎可以確定是從另一個基準去標長、寬、高。哪個軸是哪個、買主為什麼會讀錯順序，本身就是個坑；在你假設買主會照你寫的順序讀那三個數字之前，先看長寬高順序。

產品尺寸和運送尺寸不是同一個欄位

這是整份清單裡最常見的失誤，因為兩個欄位都收數字，而且都不會抗議。

Google Merchant Center 把兩者完全分開，兩組欄位連有效範圍都不一樣：

	產品量測屬性	運送尺寸屬性
屬性	`product_length`、`product_width`、`product_height`、`product_weight`	`shipping_length`、`shipping_width`、`shipping_height`
描述什麼	產品本身	產品出貨時裝的那個包裝
可接受單位	cm、in（重量：lb、oz、g、kg）	cm、in
數值範圍	cm 與 in 皆為 1–3000	1–400 cm、1–150 in
用在哪裡	商品曝光與結果準確度	貨運業者即時計算的運費
硬性規定	三個值要用同一個單位，否則資訊不會顯示	只要填了任一個尺寸屬性，就必須把全部都填上

關鍵線索就在範圍差異。一個上限只有 400 cm 的欄位，本來就不是設計來放產品尺寸的；一個可以接受 3000 cm 的欄位，本來也不是設計來算紙箱運費的。如果你團隊裡有人一直把同一組數字貼進兩邊，那麼此刻其中一組一定是錯的。

結構化資料又帶進第三套詞彙。schema.org 的 Product 有 width、height 與 depth——沒有 length 這個屬性——每一個都用帶 unitCode 的 QuantitativeValue 表示。一次修改、三套命名慣例、三個系統、三個永遠看不到彼此螢幕的人。如果這些在你自己的網站上還是空的，產品尺寸結構化資料是九個位置裡最便宜的一處。

平台還會再加一層麻煩：Amazon 透過 Product Type Definitions API 把每個商品類型的屬性以 JSON schema 公開，所以某個商品類型有的尺寸欄位，另一個商品類型不一定有。「跨平台更新產品規格」不是一個動作，是每個 schema 一個動作。

永遠輪不到更新的那一處，是圖片

回頭看那張表。第 1 到第 4 列是文字欄位，營運人員一個上午就改完。第 7 到第 9 列是文件，而大家都接受文件本來就要改版。

第 5 列才是那個會錯上好幾年的位置，因為數字活在像素裡。要改它，得找到原始檔、找到當初做圖的人、把要改什麼講清楚、等、確認、再重新上傳到每一個通路。所以多數公司裡誠實的答案是：下次重拍的時候一起改。而下次永遠不會來。

這很貴，因為圖片是買主最先讀到、也是最後才有人去查核的東西。規格表會被隨手掃過，印在照片上的尺寸會被當真。

務實的做法，是不要再把尺寸示意圖當美編作品，而當成你資料的一個檢視畫面：對著產品真實的邊緣量一次，把標註層留成可編輯的活圖層、而不是壓平進 JPEG，數字一變就照各通路的圖片規格重新輸出。這樣一來，第 5 列就從一件設計案縮成兩分鐘的編修——這也是它唯一真的會被做完的理由。

工具選擇決定這件事可不可行。會量測的軟體——把尺寸線吸附到物件真實的邊，並讓數字綁在那段幾何上——在你改輸入時會跟著改對。而只會生成一張看起來煞有其事的標註照片的產生器，什麼都沒量；它編出一個讀起來合理、卻無從查核的數字。做行銷背景圖，這筆交易划算；做一個買主日後會拿來跟你求償的數字，就不划算。附在報價單後面的規格表也是同一個道理：它的價值不在於看起來有設計感，而在於上面每一個數字都能追回到一次實測。

產品規格變更檢核清單

把這份產品規格變更檢核清單直接貼進你的變更單。一輪跑完、四組、誰負責哪一塊不用猜。

單一資料來源

修改後的數字只記錄一次，附版次與日期，放在其他所有地方都從它複製的那份檔案裡
單位與量測制式明確寫出來（公釐還是英吋——不是只寫「1180」）
量測已包含凸出物、把手、瓶蓋與上蓋，符合 GS1 的最大距離規則
已確認這次修改有沒有超過 4% / 7 mm 的箱單位公差，這決定它必須往下游傳多遠

買主看得到的欄位

每一個平台的商品／產品尺寸都更新了，不是只更新最大的那一個
包裝尺寸或運送尺寸另外更新，並確認填的確實是包裝的數字
購物 feed 的產品屬性已更新；feed 重新抓取，警告逐條看過
自家產品頁的結構化資料已更新

圖檔與文件

尺寸示意圖或標註產品圖已重新輸出，並重新上傳到每一個放它的通路
加強型內容、比較表，以及任何含舊數字的圖片都已換掉
型錄、Line Sheet 與報價單範本已重新產出；舊 PDF 從共用雲端硬碟與信件範本裡刪除

紙本與印製

裝箱單、商業發票與外箱嘜頭範本已為下一票出貨更新
說明書、組裝圖與包裝印刷稿已標記到下一批印製，現有庫存已清點
已經寄出、帶著作廢數字的報價單被逐一找出來，並趕在買主自己發現之前先告知

執行順序

順序比速度更重要，因為這些步驟有些會被快取，有些是給機器讀的。

先凍結單一資料來源。 如果還有兩個人在改這個數字，下面每一步都會繼承這份不一致。
先更新買主看得到的平台欄位。 改起來最快，出事也最快。
動 feed 之前先把圖重新輸出。 feed 與快取會在同一個週期一起抓到新的圖片 URL 和新的數字，中間就不會出現一段不一致的空窗。
推送 feed 並重新抓取。 確認商品沒有卡在警告裡；被退掉比資料過期更糟。
重新產生文件。 型錄、Line Sheet、報價單範本——而且是刪掉舊檔，不是改個檔名。
印製放最後。 整份清單裡，只有印製是不可逆的。

然後做一件幾乎沒人做的事：搜自己的產品名，用手機、不登入，以買主的身分把自己的商品頁讀一遍。你漏掉的那處矛盾，大概八秒鐘就會自己跳出來。

常見問題

怎麼更新商品頁的產品尺寸又不掉排名？

就地編輯屬性。改一個資料欄位不等於重新上架，商品頁的歷史紀錄會保留。真正傷排名的，是把商品刪掉重建、想「從頭來過」——那會丟掉評價、銷售紀錄，以及買主已經收藏的那個識別碼。

商品尺寸和包裝尺寸差在哪？

商品尺寸（產品尺寸）描述產品本身，買主用它判斷放不放得下。包裝尺寸（運送尺寸）描述它裝在什麼箱子裡走，貨運業者用它算運費。Google Merchant Center 在 schema 層就把兩者切開：product_length 及同組欄位最多接受 3000 cm 或英吋，而 shipping_length 及同組欄位上限是 400 cm 或 150 英吋。

尺寸變了，產品圖一定要改嗎？

要，而且它是這份清單裡優先度最高的一項，不是最低。印在圖上的數字比規格表更早被讀到，在爭議裡份量也更重，因為買主可以直接指著它講。如果你的標註已經壓平進 JPEG、沒有可編輯的原始檔，現在就是把它重建成照片上一層活標註的時候，這樣下一次修改只要幾分鐘。

尺寸要變動到多大，才一定要通知買主？

從商務角度看，只要影響組裝、間隙或堆疊，就該通知——這是判斷，不是門檻。但共享產品資料裡有一個公開的參照點：GS1 對箱單位的標準公差是每個尺寸 4.0%，下限 7 mm。落在這個帶寬以內的變動屬於資料雜訊；超出這個帶寬，就代表所有還存著舊數字的系統全部超出公差。

該公布公釐還是英吋？

照目標市場要求的制式公布，而且三個軸要用同一個單位——GS1 要求三個線性尺寸共用一套量測制式與一個單位。換算時先換算再進位，用 1 英吋 = 25.4 mm，然後再對該單位套用無條件進位規則。拿一個已經進位過的數字去換算，就是 3 mm 誤差變成 6 mm 誤差的過程。