以产品指标为核心的营销与增长

1. 为什么 ChatGPT App 的营销是产品分析，而不是“噪音”

在传统 Web 中，你可以接上 Google Analytics，把 UTM 参数挂到所有链接上，再放几个再营销像素——就这么过下去。但在 ChatGPT 生态里完全不同。用户坐在 ChatGPT 的界面里，而你的 App 是这段对话里的“客人”。Cookie、iframe 和 Facebook Pixel 在这里都派不上用场。

这会自动让产品事件成为增长的主要（且常常是唯一的）真实来源。App 打开有多频繁？是否到达关键场景？是否会回访？这与收入如何关联？这些问题不是由外部计数器回答，而是由你的 MCP 事件和服务端分析来回答。

这里很自然会提到一个术语：product‑led growth (PLG)。增长不是取决于你买了多少横幅，而是看产品对用户场景的满足度，以及你如何基于数据迭代产品。

因此本讲的主角是 GiftGenius 内部的事件漏斗，而不是外部营销渠道。渠道会有，但只是作为影响这些事件的假设。

GiftGenius 的 AARRR：自己的“海盗漏斗”

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;          // 来自认证（如果有）
  sessionId: string;        // ChatGPT 会话的 UUID
  timestamp: string;        // ISO 字符串
  properties?: Record<string, unknown>;
}

另外可以在 Next.js 的应用侧准备一个小工具来发送事件：

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

在服务器的 /api/analytics 端点，你可以决定该怎么处理：入库、发给日志系统，或流入 data‑pipeline。关键在于所有事件都保持统一格式。实践中，你会有同一组产品事件，但它们可能在多个位置产生：一部分更适合在 MCP 服务器通过 logger.info 固定下来，另一部分从小部件端以 AnalyticsEvent 发送到 /api/analytics。重要的不是技术“管道”数量，而是事件类型（"app_opened"、"workflow_completed" 等）及其字段保持统一一致。

3. Acquisition：如何理解用户来自哪里

营销的第一件事是回答谁来了以及有多少。在 ChatGPT App 中，这个“到达”体现在在聊天里启动 App。我们要记录的事件叫 "app_opened"。

对于 GiftGenius，这既可以在小部件侧完成（组件 mount 时触发），也可以在服务器侧（例如会话中的第一次 callTool 时）。为了不受渲染细节影响，更稳妥的是服务器侧，但为简单起见我们先看前端。

GiftGenius 小部件组件在首次渲染时调用 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>
      {/* ...小部件的主要 UI... */}
    </main>
  );
}

在实践中，你会希望从已有上下文中获取 sessionId 和 userId（例如来自 _meta 或授权令牌），而不是在客户端生成。但本质是：每一次启动 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 时刻”

光有 Acquisition 没有意义，如果用户马上就关掉 App。第二层关键就是 Activation，也就是用户第一次感到 App 真正有用的时刻。

对 GiftGenius 来说，这个时刻很自然地与 workflow 完成相关：用户输入收礼人信息、设置过滤条件，App 给出例如 10 个相关点子。此时用户第一次看到了价值。

把它记录为事件 "workflow_completed" 很方便。这个步骤最好在 MCP 服务器记录：当你已经收集好所有礼物并将结果返回给小部件时：

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

这里的 logger 是你的结构化日志器，你已经为 SLO 和成本埋点加入过。我们只是往里加了一个产品事件。

正是依据 "workflow_completed" 来计算 activation‑rate： activation_rate = (至少有一次 "workflow_completed" 的唯一 userId 数量) / (在统计期内出现 "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）。

如果没有认证，可以用基于 sessionId 和启发式 userKey 的更弱指标（例如基于 OpenAI 账号的 hash，如果能从 _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，但要理解要点：留存关注的是人们是否回来继续使用 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，你能知道到达这笔购买所调用了哪些工具、消耗了多少 tokens/费用。这样可以得到诸如“平均 cost_per_paid_workflow”以及“单个成功订单的收入减去成本”等指标。

7. Referral：当用户带来其他用户

在 ChatGPT App 中，Referral 层略显特殊。你没有自己的 push 和邮件，但用户可以分享聊天、链接，或只是告诉别人“去 Store 搜 GiftGenius”。

从技术上，你可以引入 "referral_sent" 和 "referral_activated"，前提是：

• 给用户提供推荐码或带参数的 App 链接（?ref=friend123），
• 或在 "app_opened" 的上下文里处理 referral_source/campaign。

在 GiftGenius 的基础 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，只是想有一张每周都能看的表。

按天聚合的示例报表：

可以一眼看出，第三天我们“加了” acquisition（"app_opened" 变多了），但 activation 和转化下降——可能是来的流量不匹配，或者你在 UX 上改坏了。正是这种表格能帮助区分“好营销”和“只是声量大”。

除了时间序列，也要看 cohort：在某一周到来的用户，以及他们在 7/30 天后的留存。但起步先学会按天、按周做简单切片就够了。

8. 把营销当作围绕事件的一系列实验

现在来到最“营销”的部分：如何把外部活动（文章、Store 列表页、合作）与 App 内看到的事件联系起来。

核心原则：任何营销想法都要被表述为一条关于哪些产品指标应当发生改变的假设。

以 GiftGenius 为例：

• “如果我们改进 Store 列表页（图标、描述、演示视频），新用户的 "app_opened" 数量应该上升，并且最好他们的 activation‑rate 也提高。”
• “如果我们写一篇关于新年送礼选择的文章，并给出 GiftGenius 的链接，那么接下来的 3 天，带有 referral_source = "blog_ny2025" 的 "app_opened" 应该增加，且该人群中的 "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 的直链，而是你的落地页，例如：

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

用户来到一个简短的落地页，上面有 GiftGenius 的介绍和“在 ChatGPT 中打开”的按钮。在落地页后端，你读取 utm_source，并把它保存到用户画像（或单独表）里，例如记为 acquisitionSource = "giftblog2025"。落地页按钮指向你在 Store 的 ChatGPT App，用户随后连接 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" 等事件。接下来实验就变成对比人群：referral_source = "giftblog2025" 的用户 vs 自然流量。如果“博客”人群完成场景与支付的占比更高，且人均收入相当或更好，则可认为活动成功；如果仅 App 启动数上涨而 "workflow_completed" 与 "checkout_success" 的转化下滑，则说明文章带来的主要是好奇者而非购买者。

这个方法的好处是：你只需一次性把 UTM 标记从 Web 世界“翻译”进你的内部字段 referral_source，之后就只和 App 的产品分析打交道——没有魔法，也不需要把 URL 参数硬塞进 ChatGPT。

同时，如果你在某处记录了 CAC（投放成本）和 cost_per_task，也可以看“成本端”。此时假设会升级成更“财务化”的实验：这个渠道是否回本？

10. Privacy‑first 的分析：不违背政策与常识

另一个关键问题是如何避免变成“迷你 Facebook”。与传统 Web 不同，OpenAI 对 ChatGPT Apps 的隐私要求很严格：不能跟踪个人数据，不能收集多余的 PII，也不能把聊天全文随意外发。

GiftGenius 的“良好实践”大致如下：

1. 事件中不要存用户消息的原文。只记录“场景事实”：场景类型、展示的点子数、支付是否成功等。
2. 如果需要区分用户，使用去标识化 ID（如 userId、tenantId），而不是邮箱/姓名。任何 PII 都只存放在有认证的数据库中，分析中只使用匿名键。
3. 避免在日志与事件里放能直接识别个人的字段，除非确实为业务所需（例如送货地址显然不该出现在事件里；它只应在受保护的 commerce 数据库中）。
4. 尽量做聚合分析：你关心的是成百上千用户的 activation‑rate 与留存，而不是逐个用户的名单。

别忘了我们已有审计与生命周期模块：如果用户要求删除数据，留存逻辑也要能处理。但那更偏向模块 15；这里只需记住，分析并不代表可以为所欲为地收集垃圾数据。

11. 与成本埋点和 SLO 的连接：会“算账”的营销

从技术角度看，理想状态是：你有一条统一的结构化事件流水，对每个用户会话都能对应上：

• 产品事件（"app_opened"、"workflow_completed"、"checkout_success"）；
• 成本数据（tokens、cost_estimate、各工具的 duration_ms）；
• SLO 指标（MCP/工具的时延与错误、可用性）。

这样，任何营销与产品决策都能自然地数据驱动。你可以问：

• “活动 X 的用户 activation_rate 如何？他们成功 workflow 的平均成本是多少？”
• “随着 Store 流量增加，error_rate 或 p95 时延是否在上升？”
• “如果我们在‘成本 ↔ 质量’实验中换成更便宜的模型，"checkout_success" 的转化有没有下降？人均 revenue 是否下滑？”

这一切都不需要再造新系统——你只是复用之前已经接入的日志与成本工具。

归根结底，ChatGPT App 的营销不是为了流量本身，而是为了提升你应用内部的具体产品指标。记录场景中的关键步骤（"app_opened"、"workflow_completed"、"checkout_success"），把它们与成本埋点和 SLO 关联起来，并把营销活动表述为你要改善漏斗中哪一环的假设。只要把这套漏斗与隐私边界放在心里，产品与增长决策就会更有意义、更稳健。

12. 使用产品指标与营销时的常见错误

错误 №1：为流量而营销，而不是为激活而营销。
团队常在某篇文章或一条推文之后看到 "app_opened" 暴增就欢呼，把实验判为成功，却不去看 activation 与转化。结果得到一堆“游客”，既增加负载与成本，又不带来收入，也不会成为真实用户。正确做法——永远把视线延伸到漏斗更深处：有多少人走到了 "workflow_completed" 和 "checkout_success"。

错误 №2：缺少统一的用户标识。
有时 App 开始记录事件，却没有稳定的 userId，哪怕是 tenantId 也没有。在这种情况下，你只能算“每天的事件数”之类，而算不了留存与 cost_per_user。后面再补正确的用户跟踪会很困难，尤其在隐私限制已经很强时。最好在认证阶段（模块 10）就设计好识别方案，并在所有事件中使用它。

错误 №3：跟踪“每一次响动”而不是关键事件。
接触事件分析的第一反应，往往是记录一切：鼠标悬停、每一次输入框 focus、每一次重渲染。在 ChatGPT 语境下这尤其有害：这些事件很难映射到使用模型上，制造海量噪音并提升隐私风险。更有价值的是聚焦于少数几个关键场景事件，并把它们分析到位。

错误 №4：没有归因的营销活动。
常见模式：团队发起活动（文章、视频、合作），却没有标注进入的流量，之后只能猜“到底有没有效”。结果指标变化被稀释。更好的做法是在 "app_opened" 事件中使用显式字段 referral_source 或 campaign，哪怕只是用简单的 UTM 类参数，然后把这些人群与自然流量对比。

错误 №5：为“完美分析”而忽视隐私限制。
有时为了细节，会把请求文本、收礼人的个人信息、地址等 PII 写进事件。这在两方面都有危险：不符合 OpenAI/Store 的政策，也有实实在在的法律风险（GDPR、CCPA 等）。正确的分析建立在场景的聚合特征和匿名标识之上，而不是把整段对话“以防万一”地保存起来。

错误 №6：只按成本优化，而忽视质量与增长。
在学完成本模块后，很容易进入“极致省钱”模式，试图不计代价地降低 tokens。如果同时 activation‑rate、留存与 "checkout_success" 下滑，这种节约是伪收益：你在杀死产品价值。时刻记住“三角形：成本 ↔ 质量 ↔ 增长”：对 prompts、模型与 UX 的任何改动，都要同时从成本和产品指标的角度观察。