與產品指標綁定的行銷與成長

1. 為什麼 ChatGPT App 的行銷其實是產品分析，而不是「雜訊」

在傳統 Web 世界，你可以插上 Google Analytics，把 UTM 標籤掛在所有連結上，再放幾個再行銷像素 —— 也能勉強過日子。在 ChatGPT 生態就完全不同。使用者待在 ChatGPT 的介面裡，而你的 App 是這段對話中的「訪客」。Cookies、iframe 和 Facebook Pixel 在這裡幾乎派不上用場。

這讓產品事件自動成為主要（且往往是唯一）的真相來源。App 開啟得有多頻繁？是否能走到關鍵情境？會不會回來？與營收如何關聯？這些問題的答案不在外部計數器，而在你的 MCP 事件與伺服器端分析。

這裡很自然會浮現術語 product‑led growth（PLG，產品驅動成長）：成長不是靠你買了多少看板，而是看產品多大程度解決使用者的情境，以及你如何根據數據演進。

因此，本講座的主角是 GiftGenius 內部的事件漏斗，而不是外部行銷通路。通路會有，但只作為影響這些事件的假設。

AARRR 與 GiftGenius：我們的「海盜」漏斗

模型 AARRR（Acquisition、Activation、Retention、Revenue、Referral）非常適合套用在 ChatGPT App，只是要把它翻成我們應用程式的事件語言。

對 GiftGenius，可以這樣描述：

app_opened

workflow_completed (pervyy raz)

povtornye workflow_completed / app_opened

checkout_started, checkout_success

referral_sent, referral_activated (optsional’no)

重點是，這個漏斗不是用前端點擊來描述，而是 MCP/App 層級的「使用事件」：使用者開啟、走完情境、購買、回訪。不同於 Web 有時會追蹤「每一次滑鼠移動」，這裡的分析要精簡且有意義：少問「點了哪裡」，多看「在情境裡做了什麼」。

在 GiftGenius 的基礎版本，我們首先聚焦前四層（Acquisition、Activation、Retention、Revenue）。Referral 仍然重要，但更像下一階段的發展，等產品核心與付款流程穩定後再開啟。

2. 設計事件模型：從日誌到分析

在 observability 模組中，我們已經同意寫結構化的 JSON 日誌，而不是自由發揮的「小說式日誌」。現在在此基礎上構建 產品事件模型。

最低限度的想法：App 中每個重要步驟都會產生一個事件物件。在 MCP 端既可以記錄，也可以送到外部分析系統（BI、ClickHouse、BigQuery —— 隨你喜歡）。

GiftGenius 的最簡事件定義可以長這樣：

// 事件的通用結構
type GiftGeniusEventType =
  | 'app_opened'
  | 'workflow_started'
  | 'workflow_completed'
  | 'ideas_shown'
  | 'idea_clicked'
  | 'checkout_started'
  | 'checkout_success'
  | 'checkout_failed';

interface AnalyticsEvent {
  type: GiftGeniusEventType;
  userId?: string;          // 來自 auth（若有）
  sessionId: string;        // ChatGPT 會話的 UUID
  timestamp: string;        // ISO 字串
  properties?: Record<string, unknown>;
}

另外，為 Next.js 端寫個小小的 helper 來送事件也很方便：

async function trackEvent(event: AnalyticsEvent) {
  await fetch('/api/analytics', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify(event),
  });
}

在伺服器的 /api/analytics 端點，你就可以決定要怎麼處理：存到資料庫、丟到記錄器，或串到資料管線。重點是讓所有事件都用同一種格式。實務上，你會有同一組產品事件，但會在多個地方產生：有些步驟適合直接在 MCP 伺服器以 logger.info 記錄，有些則從 Widget 以 AnalyticsEvent 送到 /api/analytics。重要的不是你有多少技術「管子」，而是事件類型（"app_opened"、"workflow_completed" 等）及其欄位保持統一且一致。

3. Acquisition：如何了解使用者從哪裡來

行銷的第一個任務是回答誰來了、來了多少。在 ChatGPT App 中，這個「進來」表現在聊天裡啟動 App。也就是我們想記錄的 "app_opened"。

在 GiftGenius，可以在 Widget 端（元件掛載時）或在伺服器端（例如該會話第一次 callTool）記錄。為了不受渲染特性影響，伺服器端更可靠，但為了簡單起見，我們先看前端。

GiftGenius 的 Widget 元件，在第一次 render 時呼叫 trackEvent 的範例：

import { useEffect, useRef } from 'react';
import { trackEvent } from '../lib/analytics';

export default function GiftGeniusWidget() {
  const reported = useRef(false);

  useEffect(() => {
    if (reported.current) return;
    reported.current = true;

    trackEvent({
      type: 'app_opened',
      sessionId: crypto.randomUUID(),
      timestamp: new Date().toISOString(),
      properties: { source: 'chatgpt_app' },
    });
  }, []);

  return (
    <main>
      {/* ...主要的 Widget UI... */}
    </main>
  );
}

實務上，你會希望從既有的上下文（例如 _meta 或權杖）取得 sessionId 與 userId，而不是在客戶端產生。重點是：每一次啟動 GiftGenius 都應該觸發這個事件。

流量來源比 Web 難解：referrer 與 UTM 標籤受限。通常有兩種策略。第一，假設主要來源是 Store，只分析 "app_opened" 的時間序列：如果你上了新的 Store 列表頁，就觀察 "app_opened" 的尖峰與漏斗後續各層。第二，使用顯式參數：若你給使用者像 https://chat.openai.com/...&utm_source=blog2025 的連結，那在第一次 "app_opened" 時就可以從上下文取此標籤放入 referral_source 欄位。

也就是說，Acquisition 指標大致包括：「每日 "app_opened" 數量」、「每週啟動過 App 的唯一 userId 數量」、「依 referral_source 的分佈（若有）』。

4. Activation：在 GiftGenius 裡找到「aha‑moment」

光有 Acquisition 沒意義，如果人一開就關。所以第二層是 Activation：那是使用者第一次感受到 App 真正有用的時刻。

對 GiftGenius，這個時刻合理地對應到完成 workflow：使用者輸入收禮者資訊、設定篩選，App 顯示例如 10 個相關點子。就在此時，使用者第一次看到價值。

把它記錄成事件 "workflow_completed" 很方便。這一步最好在 MCP 伺服器記錄：當你已經彙整好所有禮物並把結果送回 Widget 時：

logger.info('event.workflow_completed', {
  type: 'workflow_completed',
  userId,
  sessionId,
  requestId,
  ideasCount: giftIdeas.length,
  timestamp: new Date().toISOString(),
});

這裡的 logger 是你的結構化記錄器，你已經用它來做 SLO 與成本工具化；我們只是加上了產品事件。

Activation‑rate 以 "workflow_completed" 來計算： activation_rate = (具有唯一 userId，且至少有一個 "workflow_completed" 的數量) / (在期間內有 "app_opened" 的唯一 userId 數量)。

也可以更粗略地看：「具有 "workflow_completed" 的 sessionId 佔所有會話的比例」。重點是這要成為你習慣的指標：Activation 越高，App 的起步越好。

5. Retention：使用者會不會回到你的 App

對 ChatGPT App 而言，Retention 比傳統 Web 產品更棘手。一方面，ChatGPT 本身就是使用者常回來的地方；另一方面，他可能回來用一堆別的 App，而不是你的。我們關心的是他是否回到 GiftGenius。

若有身份驗證（模組 10），你會有穩定的 userId 或 tenantId。此時定義很簡單：在首次 "workflow_completed" 之後的第 7 天起算，若使用者有新的 "workflow_completed"，或至少有 "app_opened"，就視為留存（retained）。

如果沒有 auth，可以用基於 sessionId 的較弱指標，加上一些啟發式的 userKey（例如基於 OpenAI 帳號的雜湊，若能在 _meta 中取得），但在本講座我們假定已經有 userId。

用接近 SQL 的邏輯，大致像這樣（偽代碼）：

-- 第一次啟用
WITH first_activation AS (
  SELECT user_id, MIN(timestamp) AS first_ts
  FROM events
  WHERE type = 'workflow_completed'
  GROUP BY user_id
),
retained_d7 AS (
  SELECT fa.user_id
  FROM first_activation fa
  JOIN events e
    ON e.user_id = fa.user_id
   AND e.timestamp >= fa.first_ts + INTERVAL '7 day'
   AND e.timestamp <  fa.first_ts + INTERVAL '14 day'
   AND e.type IN ('app_opened', 'workflow_completed')
)
SELECT COUNT(*) / (SELECT COUNT(*) FROM first_activation) AS d7_retention
FROM retained_d7;

你不一定要在生產環境寫出這種 SQL 華麗語法，但要理解其想法：Retention 看的是人會不會回來使用 App，而不只是一次走到付款。

6. Revenue：把漏斗與金流接起來

對 GiftGenius 而言，Revenue 層凸顯我們為什麼要做這一切。在 commerce 模組中，我們已加入付款事件："checkout_started"、"checkout_success"、"checkout_failed"。這些事件同時是產品營收指標的關鍵：轉換與客單價。

當使用者按下「購買禮物」並且你建立 checkout 會話（透過 ACP/Stripe）時，應在 MCP 端記錄事件：

logger.info('event.checkout_started', {
  type: 'checkout_started',
  userId,
  sessionId,
  requestId,
  amount: checkout.amount,
  currency: checkout.currency,
  timestamp: new Date().toISOString(),
});

當從 PSP 收到成功的 webhook 時：

logger.info('event.checkout_success', {
  type: 'checkout_success',
  userId,
  sessionId,
  orderId,
  amount: payment.amount,
  currency: payment.currency,
  timestamp: new Date().toISOString(),
});

現在你可以輕鬆計算轉換：

• 「從 "workflow_completed" 到 "checkout_started"」—— 人們到底有多常進入付款；
• 「從 "checkout_started" 到 "checkout_success"」—— 你的 commerce 流程表現如何（卡片錯誤、詐欺、付款 UX）。

同時，這些事件也能與上一課的成本控制與成本工具化日誌對接：透過 requestId 或 sessionId，你能知道到達這筆購買所花的工具呼叫、token 與金額。這能提供像「平均 cost_per_paid_workflow」與「單筆成功訂單的收入減掉成本」之類的指標。

7. Referral：當使用者帶來其他人

Referral 層在 ChatGPT App 有點特別。你沒有自己的 push 與 EDM，但使用者可以分享聊天、分享連結，或直接告訴彼此「到 Store 搜 GiftGenius」。

技術上，你可以引入事件 "referral_sent" 與 "referral_activated"，如果：

• 你提供推薦碼，或在 App 連結中帶參數（?ref=friend123），
• 或是在 "app_opened" 的上下文處理 referral_source/campaign。

在基礎 MVP 階段可以先把 Referral 留到未來 —— 先把 Acquisition/Activation/Revenue 打好，確保漏斗核心正常運作。不過要知道將來要把它「掛在哪裡」：照樣掛在事件日誌與指標上，而不是另外一份放促銷碼的 Excel。

GiftGenius 的視覺化漏斗

為了更容易腦中建模，畫個小圖：

flowchart LR
  A[app_opened] --> B[workflow_started]
  B --> C[workflow_completed]
  C --> D[checkout_started]
  D --> E[checkout_success]

每一條邊都是可量測的轉換。行銷、UX 調整、模型實驗 —— 最終都應讓其中一條或多條轉換上升。若你做了某件事，卻說不出要改善哪一條邊，那就值得懷疑。

成長儀表板：優先需要哪些報表

我們來想像 GiftGenius 的最小成長儀表板。並非要打造龐大的 BI 系統，而是至少能每週檢視的一張表。

按天彙總的報表示例：

立刻就能看出，我們在第 3 天「灌」了 acquisition（"app_opened" 成長），但啟用與轉換下滑 —— 可能是導進了不對的流量，或你在 UX 上弄壞了什麼。這樣的表能幫你分辨好的行銷與只是聲量大。

除了看時間序列，也很有用的是 cohort：某週進來的使用者，以及他們在 7/30 天的留存。不過先學會做每天與每週的簡單切片就夠用了。

8. 行銷作為一連串針對事件的實驗

接著談最「行銷」的一刻：如何把外部活動（文章、Store 列表頁、合作）與我們在 App 中看到的事件連結起來。

關鍵原則：任何行銷點子都要被表述為一個假設，說明 哪些產品指標應該會改變。

以 GiftGenius 為例：

• 「如果我們把 Store 列表頁（圖示、描述、示範影片）做好，新的使用者的 "app_opened" 應該會增加，最好連帶提升他們的啟用率。」
• 「如果我們寫一篇關於新年禮物挑選的文章並放上 GiftGenius 的連結，那麼接下來 3 天內，referral_source = "blog_ny2025" 的 "app_opened" 應該上升，接著該 cohort 的 "workflow_completed" 也會上升。」

技術上，這常透過在 "app_opened" 事件中加上 campaign 或 referral_source 欄位來實現。例如，如果在 App 初始化時，你從 ChatGPT 的上下文取得某個標籤：

trackEvent({
  type: 'app_opened',
  sessionId,
  timestamp: new Date().toISOString(),
  properties: {
    referral_source: openaiContext.referralSource ?? 'organic',
    app_version: '1.3.0',
  },
});

現在你可以建立「依活動」的報表：referral_source 為 "blog_ny2025" 的人有多少 "app_opened" 與 "workflow_completed"，並與自然流量比較。

重要的是，我們不會只看別處回報的「觸及」就斷定行銷成功。即便某位部落客說他的影片有百萬觀看，這固然不錯，但對 GiftGenius 而言，成功是「我們內部的 "app_opened" 與 "workflow_completed" 成長」。

9. 範例：GiftGenius 的行銷實驗

把一切放在同一個具體情境中，同時精準地把外部活動綁到 GiftGenius 內部的產品事件。

假設你要驗證一個假設：在熱門禮物部落格上的文章會帶來「對的人」。文章中的連結不是直接到 ChatGPT，而是先到你的 landing，例如：

https://giftgenius.app/landing?utm_source=giftblog2025

使用者先到一個簡短的 Landing，介紹 GiftGenius 並有「在 ChatGPT 開啟」按鈕。在 Landing 的後端，你讀取 utm_source 並把它保存到使用者檔案（或另一張表），例如 acquisitionSource = "giftblog2025"。Landing 上的按鈕再導到你在 Store 的 ChatGPT App，接著使用者安裝並開始使用。

當這位使用者在 ChatGPT 啟動 GiftGenius，而你的後端收到來自 Apps SDK / MCP 的第一次呼叫時，你把已保存的 acquisitionSource 帶入產品事件。對 "app_opened" 而言，可能像這樣：

logger.info('event.app_opened', {
  type: 'app_opened',
  userId,
  sessionId,
  referral_source: user.acquisitionSource ?? 'organic',
  timestamp: new Date().toISOString(),
});

同樣地，你也標記事件 "workflow_completed"、"checkout_started"、"checkout_success"。接著實驗就化成 cohort 比較：referral_source = "giftblog2025" 的使用者 vs. 自然流量。若「部落格」cohort 的流程完成與付款占比更高，且每位使用者的收入相當或更好，活動可算成功；若只有啟動增加，但 "workflow_completed" 與 "checkout_success" 的轉換下滑，表示這篇文章多半帶來的是好奇者，而非買家。

這種做法的好處是：你只需要把 UTM 參數從 Web 世界「翻譯」成你內部的 referral_source 欄位，之後就完全在 App 的產品分析內工作——沒有魔法，也不用嘗試把 URL 參數直接塞進 ChatGPT。

同時，如果你有記錄 CAC（投放成本）與 cost_per_task，也能看毛利。這樣一來，假設就變成更「財務」的實驗：這個通路回本嗎？

10. 以隱私為先的分析：不違反政策與常識

另一個重要面向——如何避免變得有點像 Facebook。與傳統 Web 不同，OpenAI 對 ChatGPT Apps 的隱私相當嚴格：不能追蹤個資、蒐集不必要的 PII，或把完整的對話內容隨意外送。

對 GiftGenius 的良好分析實務大致如下：

1. 事件中不要保存使用者訊息的原文。改而記錄「情境事實」：情境類型、顯示的點子數量、成功付款的事實。
2. 若需要區分使用者，使用假名化識別碼（userId、tenantId），而不是 email/姓名。所有 PII 存在有驗證的資料庫，分析只操作去識別化的鍵。
3. 在日誌與事件中避免不必要且能直接識別個人的欄位（例如完整收貨地址顯然不應出現在事件中；它的歸處是受保護的 commerce 資料庫）。
4. 盡量使用彙總分析：你關心的是成百位使用者的啟用率與留存，而不是逐一檢視名單。

別忘了我們已有關於 audit & lifecycle 的模組：如果使用者要求刪除其資料，留存邏輯應納入考量。不過這更屬於模組 15 的範疇；在這裡只要記得，分析不是你蒐集任何雜訊的免死金牌。

11. 與成本工具化與 SLO 的關聯：會「算帳」的行銷

從技術角度看，理想狀態是：你有一條統一的結構化事件流水，在其中每個 user 會話對齊以下資訊：

• 產品事件（"app_opened"、"workflow_completed"、"checkout_success"）；
• 成本數據（tokens、cost_estimate、duration_ms 等工具指標）；
• SLO 指標（MCP/工具的延遲與錯誤、可用性）。

如此一來，任何行銷與產品決策幾乎自動成為以數據為本。你可以提出：

• 「活動 X 的 activation_rate 是多少？他們完成一次成功流程的平均成本是多少？」
• 「隨著來自 Store 的流量上升，error_rate 或 p95 延遲是否變高？」
• 「如果我們在上一課的『成本 ↔ 品質』實驗中降低了模型成本，"checkout_success" 的轉換是否下滑，或每位使用者的 revenue 是否下降？」

而這些都不需要再創建新系統 —— 你只是在使用先前導入的日誌與成本工具。

總之，ChatGPT App 的行銷不是為了流量本身，而是為了改善你應用內部的具體產品指標。記錄情境的關鍵步驟（"app_opened"、"workflow_completed"、"checkout_success"），把它們與成本工具化與 SLO 串起來，並把行銷活動表述為你想改善漏斗哪一環的假設。只要你腦中記得這個漏斗與隱私限制，關於產品與成長的決策幾乎自動會更有意義、更穩健。

12. 處理產品指標與行銷時的典型錯誤

錯誤 #1：行銷只為了流量，而不是為了啟用。
團隊常因某篇文章或推文帶來 "app_opened" 暴增而高興，把實驗視為成功，卻不看啟用與轉換。結果得到一堆「觀光客」，提升負載與成本，卻不帶來金流，也不成為真正的使用者。正確作法 —— 永遠看漏斗在第一步之後：有多少人走到 "workflow_completed" 與 "checkout_success"。

錯誤 #2：沒有統一的 user 識別碼。
有時 App 開始記錄事件，但沒有穩定的 userId 或至少 tenantId。在此狀態下，你只能算「每日事件數」，卻不能算留存，也不能算 cost_per_user。之後再補正確的使用者追蹤往往困難，尤其當你已有嚴格的隱私限制。最好在身份驗證階段（模組 10）就規劃好識別方案，並在所有事件中使用它。

錯誤 #3：追蹤「每個小動作」，而不是關鍵事件。
面對事件分析的第一反應，往往是把所有事都記：滑鼠移過、每次輸入聚焦、每次重新渲染。在 ChatGPT 的情境下這尤其有害：這些事件很難對應到使用模型，製造大量雜訊，並提高隱私風險。更有用的是，只記幾個關鍵情境事件，並且好好分析。

錯誤 #4：沒有做行銷歸因。
常見模式：團隊發一個活動（文章、影片、合作），但沒有標記流量來源，事後才猜「到底有效沒」。結果所有指標變化被稀釋。更好的做法是，在 "app_opened" 事件中使用明確的 referral_source 或 campaign 欄位，即使只是簡單的 UTM 類參數，之後把這些 cohort 與自然流量比較。

錯誤 #5：為了「完整分析」而忽視隱私限制。
有時在追逐細節時，事件開始寫入查詢文字、收禮者個資、地址等 PII。這在兩個面向都很危險：一是 OpenAI/Store 的政策，二是實際法律風險（GDPR、CCPA 等）。正確的分析建立在情境的彙總特徵與匿名識別碼上，而不是把整段對話「以備不時之需」地保存。

錯誤 #6：只按成本優化，忽略品質與成長。
在成本模組之後，很容易進入「極端省錢模式」，想用任何方法降低 token。如果因此讓啟用率、留存與 "checkout_success" 下滑，這種節省是假的：你只是扼殺了產品價值。請永遠記住「成本 ↔ 品質 ↔ 成長」三角形：任何對 prompt、模型與 UX 的改動，都要同時從成本與產品指標的角度來看。