Goal-Signal-Metric
一句話定義
產品指標的**「由大到小」三層拆解框架**：先想商業目標（Goal / 樹幹）→ 從目標推導出需要觀察的訊號（Signal / 樹枝）→ 把訊號落地成可量測的指標（Metric / 樹葉），再讓 RD 進行事件埋點。
核心要點
三層結構
| 層 | 比喻 | 內容 | 範例（提升任務完成感） |
|---|---|---|---|
| Goal（目標） | 樹幹 | 該功能要達成的商業目標 | 「降低用戶執行任務的心智負荷」 |
| Signal（訊號） | 樹枝 | 從目標推導出來、能反映目標達成的觀察點 | 「用戶在每個 step 之間的停留時間 / 詢問次數 / 中途離開率」 |
| Metric（指標） | 樹葉 | 訊號的可量測形式，工程上能埋點 | 「step 平均完成時間（秒）/ 點擊『不懂』按鈕次數 / task abandon rate」 |
為什麼要由大到小
- 避免亂埋點：直接列指標容易陷入「能埋什麼就埋什麼」的數據過剩，但無從判讀
- 避免錯方向：先確認 Goal 才能挑對 Signal——若 Goal 是「長駐意願」，光看「任務完成速度」是不夠的
- 與 RD 對接：指標 → Event 埋點是 RD 工作；先有 Goal-Signal 兩層，工程才有依據判斷該埋什麼
商業指標 vs 體驗指標
隨產品屬性不同會有不同的側重方向。
- 商業指標：營收、留存、回購、付費轉換等
- 體驗指標：認知負荷、任務完成時間、滿意度、信任感等
- 兩者可能衝突——優化任務速度（體驗指標）未必等於增加長駐意願（商業指標）；定指標時需三思
量表類工具（無法埋點時的質性測試）
當「心智負荷」這類抽象體驗無法用埋點測量時，可在發版前做質性測試，借用：
- NASA-TLX（NASA 任務負荷指數）— 心智、體力、時間、努力、表現、挫折六維度
- QUIS（Questionnaire for User Interaction Satisfaction）— 互動滿意度量表
- 抽取適合的「認知學習」構面進行小樣本評估
資料科學中的量化轉換
2026-05-06-程式猿吃香蕉-資料科學我想說的是上 提供一個與 G-S-M 同構的資料科學案例：當使用者說「常常聽音樂」「喜歡的歌一直聽」「聽得很廣」時，不能直接把這些語句丟進推薦系統，而要先轉成可度量訊號：
| 軟性描述 | 可量化訊號 / 指標 |
|---|---|
| 常常、每天聽 | 頻率 |
| 喜歡的歌會一直聽 | 深度，例如播放次數 / 歌曲數目 |
| 聽的音樂很廣 | 廣度，例如歌曲數目 / 天數 |
這個例子補強 G-S-M 的資料科學語境：願望和經驗要先變成座標，模型和埋點才有評估方向。
B2B SaaS 的客戶價值指標排序
2026-05-06-Trenton-Chen-B2B-SaaS長期競爭優勢 提供一個 B2B SaaS Goal 層校準：若站在客戶利潤角度，產品價值通常可由三類結果排序：
| Goal 層 | 可觀察 Signal | Metric 例子 |
|---|---|---|
| 提升客戶營收 | 客戶能追蹤、放大或新增收入來源 | 客戶新增 ARR / 成交率 / 廣告 ROI / pipeline 轉換率 |
| 降低客戶支出 | 客戶原本的人力、採購、工具或營運成本被替代 | 每單成本 / 工時成本 / 客服成本 / 錯誤返工成本 |
| 提高客戶工作效率 | 同樣工作以更少時間、步驟或錯誤完成 | 任務完成時間 / 每人處理量 / 錯誤率 / cycle time |
→ 這組排序提醒：G-S-M 的 Goal 不該只從產品團隊自己的 feature 成功率出發，而要回到客戶自己如何判斷價值。
Prioritization 維度也需要指標化
2026-05-06-Samuel-B2B產品優先級 補入相鄰場景：產品優先級 會把候選需求放在商業價值、使用者產品價值、策略影響、信心與複雜度等維度比較。這些維度若只靠主觀印象，分數會看似客觀但實際不可追溯；G-S-M 可用來把每個維度拆成可觀察 signal。
| 優先級維度 | 可拆的 Goal / Signal |
|---|---|
| 商業價值 | 續約風險、新客成交阻力、客戶權重、ARR 影響 |
| 使用者產品價值 | 受影響角色、任務頻率、痛點強度、Kano 類別 |
| 策略影響 | 是否支持長期產品方向、是否降低未來擴展成本 |
| 信心 | 研究證據、數據訊號、多客戶共通性、內部一致性 |
| 複雜度 | 工程量、系統風險、跨部門導入與教育成本 |
→ 產品優先級提供橫向比較，G-S-M 提供每個比較維度的縱向拆解。
與其他概念的關係
- 與 PRD：在 PRD 第 5 部「產品指標」段中作為標準工具——撰寫 PRD 時用 G-S-M 拆解每個功能對應的評量方式
- 與 數據流：是 UX-三刀流 數據流「量化用戶與系統狀態」能力的具體 sub-工具——回答「該量什麼、怎麼量」
- 與 商業流：Goal 層由商業流提供（戰略決定要追什麼）；Signal / Metric 層由數據流落地（驗證決定是否奏效）
- 與 Test（設計思考）/ Feedback-Capture-Grid：G-S-M 是量化驗證的工具線；Feedback Capture Grid / I-Like-I-Wish 是質性驗證的工具線——兩線在 PRD 指標規劃中互補
- 與 行銷漏斗：漏斗各階段的轉換率本身就是一組 G-S-M 落地——Goal「擴大客群」→ Signal「漏斗中段流失」→ Metric「step N → step N+1 流失率」
- 與 資料科學：資料科學專案同樣要先判斷問題是否可量化，再把使用者經驗或商業願望轉成可觀察座標；G-S-M 是產品指標語境的結構化版本。
- 與 產品洞察：洞察指出「哪個客戶問題值得解」，G-S-M 把它轉成 Goal / Signal / Metric，避免洞察停在故事層。
- 與 產品優先級：產品優先級橫向比較多個候選需求；G-S-M 幫每個評分維度拆出可觀察 signal，避免「分數」變成包裝過的主觀偏好。
- 與 INVEST原則 對位（vault 結構化驗收清單家族）：兩者都是 Tom-Liou PRD 七部曲 / 盈秀 Discovery 流程中的結構化驗收工具——
- G-S-M = 指標的「由大到小」三層拆解（為了量化某個目標該量什麼）
- INVEST = User Story 的「6 條品質標準」（拆完後檢查是否拆得好）
- 維度不同但角色相通：G-S-M 是縱向拆指標 / INVEST 是橫向驗收顆粒
相關來源
- 2026-05-01-Tom-Liou-PRD指南
- 2026-05-06-程式猿吃香蕉-資料科學我想說的是上 — Sobi / 程式猿吃香蕉：用音樂使用者行為例子展示「軟性經驗 → 頻率 / 深度 / 廣度指標」的量化轉換
- 2026-05-06-Trenton-Chen-B2B-SaaS長期競爭優勢 — 補入 B2B SaaS 客戶價值的三類 Goal：提升營收、降低支出、提高效率
- 2026-05-06-Samuel-B2B產品優先級 — 補入 B2B prioritization 評分維度與 G-S-M 的關係：商業價值 / 使用者價值 / 策略影響 / 信心 / 複雜度都需要可觀察 signal 支撐。
備註
此框架最早由 Google 內部 推廣（與 HEART 框架同一系列；Google Research 的 Kerry Rodden 等人 2010 整理）。本頁先以 Tom-Liou PRD 來源中的引用為起點建頁；後續若 ingest Google HEART 原始文獻或更深入的 G-S-M 案例，可擴充至完整工具鏈。
未來累積方向：
- (a) 與 HEART 框架（Happiness / Engagement / Adoption / Retention / Task success）的關係
- (b) Pirate Metrics（AARRR）/ Northstar Metric / OKR 等其他指標框架的對位
- (c) Event 埋點實作層（Mixpanel / Amplitude / GA4 / 自建 BI）
- (d) A/B 測試與 G-S-M 的整合