如果你已經在多個通路重複修改商品標題、規格與圖片，Make＋Plytix 值得評估；如果只有一間商店、少量商品，先整理好商店後台與欄位表，通常更省維護力氣。 這套工作流的重點是「一份核准資料，分別送到各通路」，不是所有資料一改就立刻無條件覆寫。
Make 團隊在 2026 年 9 月 17 日公告 Plytix 整合，可用商品變更帶動後續流程。這讓商品資料維護有了新的串接入口，但每個通路的欄位、權限與失敗處理，仍要另外設計。Make 官方社群公告
本文依官方文件整理，查證日為 2026 年 9 月 18 日。下方欄位、測試數量與審核規則是編輯建議，並非套用即可上線的官方範本，也沒有進行真實商店端到端實測。本文使用官方一般連結，未放聯盟追蹤連結。
先分清楚：Plytix 管商品內容，Make 負責串流程
Plytix 是商品資訊管理工具（PIM），用來集中商品與素材資料。Make 的 Plytix 文件列有 Watch Products、Search Products、Get a Product，以及建立、更新、刪除商品和管理素材等模組；Watch Products 的說明是商品新增或更新時觸發流程。Plytix 模組文件
這份模組清單證明你能讀寫 Plytix，不等於目標商店已經接好，也不代表能同步更新所有通路。商店端仍要有可用的 Make 連接器或 API、對應權限，以及正確的商品識別碼。觸發頻率與延遲須在實際帳戶確認，本文不把 Watch Products 寫成即時推播保證。
我會先用下面三種情況判斷要不要導入：
| 你的現況 | 建議起點 | 先解決什麼 |
|---|---|---|
| 一間商店，商品資料由一人維護 | 先用商店原生後台 | 統一欄位名稱與圖片命名 |
| 多通路共用規格、文案與素材，經常改漏 | 評估 Plytix 作商品內容主檔，再串 Make | 定義誰能改、哪一版可以外送 |
| 最大問題是即時庫存、訂單與促銷價格 | 先盤點 ERP、OMS 或商店原生整合 | 確認交易資料的權威來源 |
若你還不熟悉情境、模組與排程，先讀本站的 Make.com 中文教學。這篇直接處理商品資料流，不重走註冊入門。
接線前，先寫一張欄位所有權表
最容易出錯的地方不是連線失敗，而是兩套系統都以為自己可以改同一個欄位。以下以虛構的帆布袋商品為例，示範怎麼分工；這些是自訂欄位概念，不代表 Plytix 或商店內建同名欄位。
| 資料 | 建議由誰決定 | 外送規則 |
|---|---|---|
| SKU／通路商品 ID | 先建立並保存對照表 | 找不到唯一對應就暫停，不用標題猜 |
| 商品名稱、材質、尺寸 | 指定商品內容主檔 | 核准後才送出；尺寸保留單位 |
| 主圖、替代文字 | 素材負責人 | 確認可讀取、順序與使用權 |
| 售價、幣別、稅別、促銷期間 | 指定商店或 ERP 負責 | 初期排除自動覆寫，另設價格審核 |
| 庫存、訂單狀態 | 指定庫存／訂單系統 | 不從文案主檔反向覆蓋 |
| 外送版本、核准狀態 | 內容審核者與同步紀錄 | 只接受指定版本，保留每通路結果 |
尤其不要把空值一律理解成「清除」。某通路沒填材質，可能只是還沒完成，不代表要把既有材質刪掉。先定義「不更新」與「明確清空」兩種指令，再開始映射欄位。
AI 可以協助改寫商品描述，但規格、材質與尺寸應來自已確認資料。若要加入 AI 節點，把輸出放在草稿欄，通過人工核對後才成為可外送版本；不要讓新生成文案直接進入同步主線。
一條可維護的 Make＋Plytix 商品工作流
建議先做單向外送：商品變更 → 讀取完整資料 → 核准與欄位檢查 → 各通路轉換 → 更新指定商品 → 回讀與記錄。 這是依官方模組能力提出的設計方案；下列檢查及紀錄需要你自行組合，不是安裝 Plytix app 後自動具備。
1. 先取得正確的連線與權限
Make 文件要求 Plytix 帳戶、API key 與 API password。Plytix 官方說明只有 Owner／Admin 能建立與管理 API keys，並可為 key 指派角色。讓有權限的人建立連線，依帳戶可用角色限制存取範圍；不要把金鑰放進共用試算表、圖解或錯誤通知。Make 連線文件、Plytix API 權限說明
2. 讀取變更後，先擋住未核准資料
由 Watch Products 取得變更事件，必要時用 Get a Product 補齊紀錄。接著檢查 SKU、目標通路、必填欄位與核准版本。即使只是修正一個錯字，也要知道這筆事件對應哪一版商品資料。
自訂一個「已核准外送」旗標很直觀，但旗標若一直留在已核准，後續未審的新修改也可能被放行。比較穩妥的方式，是讓核准與內容版本綁定；內容再改，就必須重新核准。
3. 各通路各自轉換，不共用一包原始資料
同一個商品名稱，在商店、Marketplace 與型錄裡可能有不同長度與格式要求。為各通路分開處理分類、語言、圖片網址、變體和必填欄位。先確認通路端的規則，再決定如何截短或改寫，不能只因 API 接受資料就當成刊登品質合格。
例如商品主檔是「帆布袋／米白／大」，目標通路可能需要父商品 ID 加上顏色、尺寸的變體 ID。若只找到父商品，先進人工處理清單，不要自行把內容灌到所有變體。
4. 更新既有 ID，分開記每個通路的結果
保存「來源商品 ID＋通路＋目標商品 ID」的對照。初期可將新增商品排除在自動主線之外，只更新已人工確認的商品，降低重複建立的機會。
再加上一個由商品、通路與版本組成的處理識別碼。同一版本重送時，先查它是否已成功；A 通路成功、B 通路失敗，就保留兩個結果，只處理 B 的問題。這個避免重複寫入的紀錄需要自行建置，不能假設模組替你完成。
5. 回讀目標資料，再標記完成
收到成功回應後，用目標服務可用的讀取方式核對 ID、主要欄位與圖片。若該服務採背景處理，還要確認最後狀態；無法自動讀取時，把人工抽查列為完成條件。
建議紀錄至少包含來源版本、目標 ID、送出時間、結果與錯誤原因。記錄放在獨立同步台帳，可減少把狀態寫回商品本身、再次觸發 Watch Products 的循環；若必須回寫商品，另外排除只有同步狀態變動的事件。
價格、刪除與失敗重試，分開設規則
Make 雖然提供 Delete a Product 模組，但「Plytix 的商品被刪除」和「全部通路都應下架」是兩件事。第一版流程建議不串自動刪除：先標停用、產生待處理清單，確認各通路下架結果後再由負責人處理主檔。
價格也獨立處理。幣別或小數位錯一次，可能讓同一錯誤快速傳到多個通路。讓人工核對修改前後值、適用商品與生效時間，確認完成才外送；測試階段先只同步文案與規格。
遇到錯誤時，不要全部重跑：
| 問題 | 建議處理 |
|---|---|
| 暫時斷線、服務限流 | 保存失敗項目，依服務規則延後重試 |
| 必填欄位缺失、分類不接受 | 退回修資料；重試不會自動補對 |
| 逾時，不確定對方是否已寫入 | 先查目標 ID 與版本，再決定是否重送 |
| 同一欄位在商店端被人工改過 | 暫停覆寫，交給指定負責人裁決 |
Make 的 Retry error handler 可保存失敗資料，搭配 incomplete executions 處理；部分暫時錯誤支援自動重試，但須確認設定與適用錯誤類型。重試機制不會替你保證跨通路一致，也不能取代查重紀錄。 Retry 文件、自動重試說明
費用要算整條流程，不只看一個免費方案
截至查證日，Plytix 定價頁列出 Standard、Pro、Enterprise，並將 SKU、API 呼叫量及部分分發功能分開計算。Standard 頁面標示 500 SKUs、每小時 5,000 次 API calls；這只是該方案列出的額度，不代表目標通路接受相同速率。Plytix 定價頁
採購前分開確認四筆成本：Plytix 方案與加購、Make 使用量、目標通路／連接器，以及維護工時。官方定價頁會依地區呈現金額，本文不把未確認幣別的數字換算成台幣報價。若 Plytix 現有原生連接已能滿足需求，也應先比較，別為了串接而多養一套流程。
先拿少量商品驗收，再擴大通路
可以先挑 3 件測試商品、1 個通路 作為小規模驗收；這是測試建議，不是官方限制。至少準備一般商品、含變體商品，以及故意缺一個必填欄位的商品。優先在測試商店或未公開商品驗證。
驗收時逐項確認：未核准版本送不出去；缺欄位會停下；重送不會多建商品；斷線恢復後只補失敗項目；人工修改不被悄悄蓋掉；圖片與變體對應正確。保留目標修改前的內容，並演練停用情境與還原方式。
商品圖片整理仍是另一項前置工作，可搭配本站的 電商批次去背流程。如果團隊對誰核准仍沒有共識，先把責任寫成 SOP，再開自動排程。
常見問題
Make＋Plytix 能保證所有通路同時更新嗎？
不能這樣保證。各通路有自己的處理速度、權限與限制，也可能局部失敗。設計目標應是每個通路的更新狀態可追蹤、失敗可補送，而不是一次按鈕代表全部完成。
可以把庫存與商品文案放在同一條流程嗎？
技術上需看來源和目標模組，但初期建議拆開。庫存與文案的更新頻率、資料負責人和失敗代價不同，先確認各自權威來源，避免雙向循環覆寫。
還沒用 Plytix，應該為這個整合導入嗎？
先看你是否真的需要共用商品主檔。只有一個通路時，原生後台可能已足夠；當重複維護和版本錯誤已成為固定負擔，再拿真實商品做小規模測試。先把一條資料流做可靠，再增加通路，會比一次串滿更容易維護。