72 lines
4.2 KiB
Markdown
72 lines
4.2 KiB
Markdown
# 外部專業做法 Benchmark
|
||
|
||
> 用途：定期把外部電商、商品資料與 UX 專業做法轉成 EwoooC / MOMO Pro 的可執行產品準則。
|
||
|
||
## 固定節奏
|
||
|
||
- 每週一 09:30 執行外部 benchmark，自動輸出可落地建議。
|
||
- 只採用能改善核心價值的做法：商品身份比對準確率、可用比價覆蓋率、價格新鮮度、人工覆核效率、競品情報決策品質。
|
||
- 外部資料必須保留來源、讀取日期、觀察結論與不採用原因。
|
||
|
||
## 2026-06-02 初始觀察
|
||
|
||
### 1. 商品 identity 必須優先吃結構化 identifiers
|
||
|
||
Google Merchant Center 的商品資料規格把 `id`、`brand`、`gtin`、`mpn`、`price`、`availability` 視為商品資料核心；Schema.org / Google Product structured data 也把 `Product`、`Offer`、`AggregateOffer`、`sku`、`gtin`、`brand`、`price`、`availability` 放在商品與報價語意中心。
|
||
|
||
落地到本產品：
|
||
|
||
- 比對引擎不能只靠商品名稱 token；應逐步建立 `identity_evidence` 欄位，分層保存品牌、SKU、GTIN/條碼、MPN/型號、容量、入數、色號、香味、款式。
|
||
- 若雙方有 GTIN / MPN / 明確型號，應優先作為 strong evidence。
|
||
- 若缺 GTIN / MPN，不得自動推定同款；要清楚標示 `identifier_missing` 或 `identifier_weak`。
|
||
|
||
### 2. 價格可用性必須和 freshness 綁在一起
|
||
|
||
Google Merchant Center 要求價格與庫存狀態要和 landing page / checkout 保持一致；Schema.org Offer 也有 `price`、`priceCurrency`、`availability` 等報價欄位。
|
||
|
||
落地到本產品：
|
||
|
||
- `decision_ready` 只能計入明確未過期價格，不應把未知 freshness 當可決策。
|
||
- Dashboard 必須拆開 identity coverage、fresh price coverage、pending identity、stale identity。
|
||
- 目前 V10.549-V10.565 的方向正確：未知新鮮度不得灌高覆蓋率，並要進刷新/救援流程。
|
||
|
||
### 3. 多 offer / 多平台比價應該呈現為 offer evidence，不只是單一低價
|
||
|
||
Schema.org `AggregateOffer` 用於同一商品對應多個商家 offer。這個概念適合我們把 MOMO / PChome 的同款證據與價格證據分開保存。
|
||
|
||
落地到本產品：
|
||
|
||
- `competitor_prices` 應逐步從單一 match row，演進成「identity pair + offer snapshot」兩層。
|
||
- PPT / AI 決策不只顯示價差，也要顯示 identity confidence、freshness、offer source、last crawled、manual review state。
|
||
|
||
### 4. Product comparison UX 要讓使用者比較規格差異
|
||
|
||
Baymard 的商品頁與比較 UX 研究強調：使用者需要清楚的 product comparison，尤其是規格驅動品類。
|
||
|
||
落地到本產品：
|
||
|
||
- 人工覆核頁不能只列 MOMO/PChome 名稱與價格；要突出「不一致欄位」：色號、香味、容量、入數、套組、任選、效期、航空版。
|
||
- 對 `identity_veto` / `true_low_confidence` 要顯示人可以理解的原因，不只顯示 `待審`。
|
||
- Dashboard 建議下一步要直接連到對應操作：刷新、補抓、重評、單位價覆核、人工覆核。
|
||
|
||
## 目前不採用
|
||
|
||
- 不採用「只靠低價/高相似度自動配對」：價格相近不是 identity evidence。
|
||
- 不採用「大量放寬 threshold 來拉覆蓋率」：會污染核心比價資料。
|
||
- 不採用「把外部網站 UI 風格直接照搬」：只吸收資訊架構、證據呈現與工作流做法。
|
||
|
||
## 下一步 TODO 候選
|
||
|
||
1. 建立 `identity_evidence` 正規化 payload，讓 matcher 回傳 identifier/spec/variant evidence。
|
||
2. 在覆核頁新增差異高亮：色號、香味、容量、入數、任選、效期、來源新鮮度。
|
||
3. 將 PPT / AI payload 的比價項目拆成 identity evidence 與 offer evidence。
|
||
4. 每週 benchmark 結果若命中上述 TODO，回寫 `TODO_NEXT_STEPS.txt` 或新增 ADR / memory。
|
||
|
||
## 參考來源
|
||
|
||
- Google Merchant Center Product data specification: https://support.google.com/merchants/answer/7052112
|
||
- Google Search Central Product structured data: https://developers.google.com/search/docs/appearance/structured-data/product
|
||
- Schema.org Product / Offer / AggregateOffer: https://schema.org/Product, https://schema.org/Offer, https://schema.org/AggregateOffer
|
||
- Baymard Product Page UX Best Practices: https://baymard.com/blog/current-state-ecommerce-product-page-ux
|
||
- Baymard Product Comparison UX: https://baymard.com/blog/provide-comparison-features
|