發布指標
本技能涵蓋如何衡量產品發布——發布日前該設定什麼、發布期間該追蹤什麼、以及發布後該如何評估結果。沒有一致的衡量標準，發布就像在瞎猜。有了它，每次發布都能為下一次提供參考。
發布前設定
衡量應從發布日前就開始。在發布當天才設定追蹤，會錯過流量最高峰時的第一波數據。
需要設定的事項
- UTM 參數 — 為每個分發渠道的每個連結加上標籤
- 分析事件 — 端到端地檢測轉換漏斗
- 基準數據擷取 — 在發布前記錄當前指標，以便衡量增長幅度
- 儀表板或檢視畫面 — 在發布日能一處監看所有關鍵指標
UTM 命名慣例
UTM 參數用來追蹤流量來源。在所有發布中採用一致的命名方案，以便日後進行比較。
utm_source = 平台 (twitter, linkedin, email, producthunt, hackernews)
utm_medium = 渠道類型 (social, email, paid, referral)
utm_campaign = 發布名稱 (feature-name-launch, v2-launch, 等)
utm_content = 特定素材 (tweet-thread, announcement-email, blog-post)
範例網址：
- Twitter 公告：
?utm_source=twitter&utm_medium=social&utm_campaign=realtime-api-launch&utm_content=launch-tweet - 發布郵件：
?utm_source=email&utm_medium=email&utm_campaign=realtime-api-launch&utm_content=announcement-email - Product Hunt：
?utm_source=producthunt&utm_medium=referral&utm_campaign=realtime-api-launch&utm_content=ph-listing
規則：
- 一律小寫
- 數值中使用連字號，不要用底線或空格
- 同一發布的活動名稱在所有渠道中應保持一致
- 在發布日前用試算表建立所有 UTM，確保沒有任何遺漏
已檢測的事件
發布前，請確認以下分析事件存在且正確觸發：
| 事件 | 說明 |
|---|---|
landing_page_view | 到達頁面載入，並擷取 UTM 參數 |
signup_started | 使用者開始註冊 |
signup_completed | 帳戶建立成功 |
first_action | 首次有意義的產品操作（因產品而異） |
cta_click | 每個 CTA 按鈕點擊（附帶標籤） |
blog_post_view | 發布部落格文章載入 |
email_open | 發布郵件被打開（來自郵件平台） |
email_click | 發布郵件中的連結被點擊 |
如果這些事件不存在，且發布前沒有時間新增，至少使用 UTM 來衡量目前分析平台已有的流量和註冊數。
按層級劃分的 KPI
「成功」的定義取決於發布層級。不要把第三層的更新記錄推文和第一層的產品發布相提並論。
第一層 KPI（完整產品發布）
| 指標 | 衡量什麼 | 在哪裡追蹤 |
|---|---|---|
| 新註冊數（第1天、第1週） | 直接獲取影響 | 產品分析 |
| 到達頁面訪客數 | 公告的觸及範圍 | 網站分析 |
| 到達頁面 → 註冊轉換率 | 頁面效果 | 網站分析 |
| 郵件開啟率 | 郵件名單參與度 | 郵件平台 |
| 郵件點擊率 | 郵件文案效果 | 郵件平台 |
| 社群曝光 + 互動次數 | 知名度 | 原生平台分析 |
| 媒體報導次數 | 公關觸及 | 手動 + Google 快訊 |
| 產生的反向連結數 | SEO 影響 | Ahrefs, Search Console |
| Product Hunt 排名（如適用） | PH 特定觸及 | Product Hunt |
第二層 KPI（主要功能）
| 指標 | 衡量什麼 |
|---|---|
| 來自發布流量的新註冊數 | 獲取 |
| 功能採用率（現有用戶） | 啟動 |
| 部落格文章瀏覽次數 | 內容觸及 |
| 社群互動率 | 共鳴度 |
| 郵件開啟 + 點擊率 | 郵件名單參與度 |
第三層 KPI（小型改善）
| 指標 | 衡量什麼 |
|---|---|
| 更新記錄瀏覽次數 | 現有用戶的認知度 |
| 社群貼文互動次數 | 觸及 |
基準期望
以下是針對擁有穩定受眾的 B2B/開發者工具的大致基準，可用來校準期望，而非絕對目標。
| 指標 | 弱 | 穩健 | 強 |
|---|---|---|---|
| 郵件開啟率（現有名單） | < 20% | 30-40% | > 50% |
| 郵件點擊率 | < 2% | 4-8% | > 10% |
| 到達頁面 → 註冊轉換率 | < 2% | 5-10% | > 15% |
| Twitter 發布推文曝光數（1萬粉絲） | < 5K | 10-30K | > 50K |
| Hacker News 首頁（若達成） | — | 200-500 次訪問 | 2,000+ 次訪問 |
| Product Hunt（精選） | < 100 讚 | 200-500 | 500+ |
| 第一層發布：第1週註冊數 | < 100 | 200-1,000 | 1,000+ |
這些數字會因受眾規模、產品類別和發布品質而有很大差異。請將其視為方向性參考。
發布日監控
在發布日的前 4-6 小時內，以接近即時的方式監控指標。此時仍可進行調整（重新分享貼文、發送追蹤推文、延長限時優惠）。
需要監控的項目：
- 每小時註冊數（若顯著低於預期則發出警報）
- 按註冊轉換率排序的頂尖流量來源（不僅是流量量）
- 郵件傳遞問題（跳出率、垃圾郵件投訴）
- 前 2 小時的社群互動速度（可預測最終觸及範圍）
不應該做的事：
- 過度頻繁地重新整理指標，而忽略了與社群留言互動
- 根據早期數據在發布中途進行重大訊息調整
- 因特定渠道表現不佳而驚慌——等待 24 小時的數據
發布後回顧
在發布後 5-7 天內進行回顧，此時數據仍很新鮮。對於第一層發布，請在發布準備階段就排定回顧時間。對於第二層發布，非同步的 Slack 討論串即可。
回顧所需數據
在回顧前，請收集以下資料：
- 按來源劃分的流量（UTM 分類）
- 按來源劃分的註冊數
- 按來源劃分的轉換率（註冊數 ÷ 訪客數）
- 郵件指標（開啟率、點擊率、取消訂閱率）
- 各平台社群指標
- 與上次類似發布的比較（若有）
需要回答的問題
- 表現最佳的渠道是什麼？（依轉換率，而非僅看流量量）
- 表現最差的渠道是什麼？（相對於投入的努力）
- 有什麼令人驚訝的發現？（表現超出或低於預期的渠道）
- 訊息傳遞是否到位？（質性回饋：留言、回覆、郵件回覆）
- 漏斗在哪裡漏了？（高流量、低註冊數 → 到達頁面問題；低流量 → 分發問題）
- 你會做什麼不同的事？
回顧產出
回顧應產出剛好兩件事：
- 更新的分發優先順序 — 下次哪些渠道應投入更多/更少資源
- 檢查清單更新 — 根據學到的經驗，新增或移除發布檢查清單中的項目
將其記錄在共享空間（Notion、Linear、Confluence）中，以便在多次發布中累積。其價值會隨時間複利：經過 10 次發布後，你就擁有一個量化模型，知道什麼對你的產品和受眾有效。
建立發布歷史記錄
在單一試算表或資料庫中追蹤每次發布：
| 發布名稱 | 日期 | 層級 | 最佳渠道 | 註冊數（第1天） | 註冊數（第1週） | 郵件開啟率 | 備註 |
|---|
經過 5 次以上的發布，模式就會浮現：
- 哪些渠道對你的受眾持續有效轉換
- 什麼層級的發布能帶來多大量的註冊數
- 你的基準隨著時間的趨勢（郵件名單規模、社群追蹤數成長）
這份歷史記錄是你最有價值的發布資產。它能讓未來的發布規劃比任何外部基準都更快、更準確。
相關技能
- launch-strategy — 定義發布層級和決定追蹤內容的檢查清單
- launch-distribution — 每個渠道的 UTM 在發布日前設定完成
- launch-email — 郵件開啟/點擊指標回饋到回顧中
- launch-blog-post — 部落格文章 UTM 和長期自然搜尋表現