Cross-border Ecommerce Intelligence

電商數據 API 是什麼？商品、價格、評論資料完整指南

電商數據 API 將分散在不同市場與平台的商品、價格、排名、評論與問答，整理成可供分析系統持續使用的結構化資料。本文從資料範圍、欄位設計到導入流程，說明企業如何把網頁上的零散訊號轉成可比較、可追蹤的市場情報。

電商數據 API 通常包含哪些資料？

常見資料可分為四層。第一層是商品主檔，例如商品名稱、品牌、分類、規格與來源網址；第二層是交易前訊號，例如價格、促銷、排名、庫存或賣家資訊；第三層是消費者回饋，包括評分、評論、商品問答與公開討論；第四層是觀測資訊，例如蒐集時間、語言、國家與平台。

不同來源能提供的欄位並不一致，因此 API 設計不應假設所有平台都有相同資料。較穩健的做法，是先定義跨平台共通欄位，再保留來源專屬欄位，並清楚標示缺值與觀測時間。

• 商品層：名稱、品牌、分類、規格、圖片與商品網址。
• 市場層：價格、幣別、促銷、排名、賣家與可售狀態。
• 口碑層：評分、評論、問答、公開社群討論與互動訊號。
• 治理層：來源、觀測時間、語言、國家、欄位版本與使用限制。

API、資料匯出與儀表板該怎麼選？

API 適合要把資料接入 BI、資料倉儲、模型或內部產品的團隊；CSV 或 JSON 批次匯出適合一次性研究與歷史回溯；儀表板則適合需要快速查看趨勢、但暫時沒有工程資源的使用者。三者不是互斥選項，常見做法是先用樣本與批次檔確認欄位，再進入固定排程或 API 串接。

跨平台資料最常見的三個陷阱

第一是把不同規格或組合商品誤判成同一商品；第二是只看當前價格，忽略幣別、促銷條件與觀測時間；第三是把評論數或平台熱度直接當成市場占有率。這些指標能提供方向，但不能取代銷售、通路或財務資料。

因此，正式分析前要先建立商品對應規則、資料品質檢核與缺值處理方式，並保留來源網址與時間戳，讓分析結果可以追溯。

建議的五步導入流程

先寫出要回答的決策問題，再依序確認市場與來源、定義欄位、驗證樣本、設定更新方式，最後才進入正式串接。若一開始就要求全平台、全欄位與長期歷史資料，通常會同時放大成本、噪音與合規風險。

• 定義問題：例如價格追蹤、消費者需求、競品比較或供應商探索。
• 圈選範圍：國家、平台、品類、品牌、關鍵字與日期區間。
• 驗證樣本：檢查覆蓋率、欄位完整度、語言與重複資料。
• 確認交付：API、批次檔、雲端儲存或儀表板。
• 建立監控：追蹤來源中斷、欄位變動、延遲與資料品質。

資料品質與驗收：先定義「可用」，再談資料量

電商資料專案最容易被忽略的工作，是把品質要求寫成可以量測的驗收條件。除了 API 是否回傳成功，還要分別檢查來源覆蓋率、必要欄位完整率、重複率、價格與幣別合理性、商品版本誤配率，以及資料從平台出現到交付端可用的延遲。若只用總筆數驗收，很可能得到大量重複、過期或無法比較的紀錄。

建議以一組已知商品作為黃金樣本，人工核對來源頁、規格、價格與評論數，再用固定規則持續抽樣。平台改版或欄位消失時，系統應保留最後成功時間、錯誤原因與受影響範圍，讓使用者能區分「市場沒有資料」與「資料管線暫時失效」。

• 完整性：必要欄位缺值是否低於專案容許範圍。
• 正確性：價格、幣別、規格與來源頁是否一致。
• 新鮮度：觀測時間與交付時間是否符合決策週期。
• 可追溯性：每筆資料能否回到來源、批次與 schema 版本。

實務案例：從競品價格監測到可採取的行動

假設品牌要追蹤台灣、日本與美國三個市場的二十個競品系列，第一步不是直接建立每日爬取，而是先定義商品對應表：哪些容量、顏色與組合包可以互相比較，哪些必須拆開。接著統一幣別與含稅、運費、折扣口徑，保留原價與促銷價，才能避免把短期折價誤當成永久降價。

資料進入倉儲後，可設定「同規格價格差超過門檻」「頭部商品連續上升」「負評主題突然增加」等事件，再由品牌、採購或產品團隊決定是否調價、調整頁面、追查缺貨或啟動新品研究。這種從問題、資料、門檻到負責人的閉環，比單純展示更多圖表更能產生決策價值。

• 先用兩週樣本期確認商品配對與欄位品質。
• 為價格、排名與評論異常設定不同的觸發條件。
• 每個事件指定負責團隊、處置期限與回看指標。
• 每月檢討誤報、漏報與未採取行動的原因。

常見需求與建議資料組合

延伸閱讀

• 如何用電商評論做 Voice of Customer？
• 跨境電商選品與競品分析

常見問題