プロダクト指標に紐づくマーケティングと成長

1. なぜ ChatGPT App のマーケティングは「ノイズ」ではなくプロダクト分析なのか

従来のウェブでは、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 レベルの「利用イベント」で表現されることです。ユーザーが開いた、シナリオを完了した、購入した、戻ってきた。ウェブのように「マウスの動きのすべて」を追跡するのではなく、ここではコンパクトで意味のある分析が求められます。「どこをクリックしたか」ではなく「シナリオで何をしたか」を重視しましょう。

GiftGenius のベースバージョンでは、まず最初の 4 層（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 では、その後どう扱うか（DB に保存、ログ出力、データパイプラインへストリームなど）を決められます。重要なのは、すべてのイベントが同一フォーマットであること。実務では同じプロダクトイベントのセットが複数の発火地点を持ちます。あるステップは MCP サーバーで logger.info し、別のステップはウィジェットから AnalyticsEvent として /api/analytics に送ります。技術的な「パイプ」の数ではなく、イベントタイプ（"app_opened"、"workflow_completed" など）とそのフィールドが一貫して整合していることが肝心です。

3. Acquisition：ユーザーがどこから来るのかを理解する

マーケティングの最初の仕事は「誰が、どれくらい来ているか」に答えることです。ChatGPT App では、この「来訪」はチャットで App が起動されたことで記録されます。私たちが記録したいのは "app_opened" です。

GiftGenius では、これはウィジェット側（コンポーネントのマウントに反応）でも、サーバー側（たとえばセッションの最初の callTool）でも可能です。レンダリングの癖に依存しないサーバー側の方が堅牢ですが、簡単のためにフロントで考えてみます。

trackEvent を初回レンダー時に呼ぶ GiftGenius ウィジェットのコンポーネント例：

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 の起動ごとにこのイベントが生まれることです。

トラフィックソースの問題はウェブほど簡単ではありません。リファラや UTM パラメータには制限があります。一般的には 2 つの戦略が使われます。1 つ目は、主なトラフィックソースを Store と見なして、時間別の "app_opened" のみを分析する方法です。新しい Store リスティングをリリースしたら、"app_opened" のスパイクとファネルの後続レベルを見ます。2 つ目は、明示的なパラメータを使う方法です。たとえば https://chat.openai.com/...&utm_source=blog2025 のようなリンクを配布した場合、最初の "app_opened" でコンテキストからそのタグを取り、referral_source フィールドへ格納します。

つまり acquisition メトリクスは「1 日あたりの "app_opened" の数」「1 週間で App を起動したユニークな userId の数」「referral_source の分布（もしあれば）」のようになります。

4. Activation：GiftGenius の「アハ・モーメント」を見つける

Acquisition だけでは意味がありません。すぐに App を閉じられてしまうかもしれないからです。2 つ目の層である Activation は、ユーザーが初めて「この App は本当に役に立つ」と感じた瞬間です。

GiftGenius では、この瞬間はワークフローの完了と結びつけるのが自然です。受け手の情報を入力し、フィルタを設定し、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 と cost 計測のために既に導入した構造化ロガーです。そこへプロダクトイベントを追加しているだけです。

"workflow_completed" を基準に activation‑rate を計測します。 activation_rate = (少なくとも 1 件の "workflow_completed" を持つ一意の userId の数) / (期間内に "app_opened" を持つ一意の userId の数)。

もっと荒く、「sessionId ベースで "workflow_completed" があったセッションの割合」を見ることもできます。重要なのは、自分たちにとって馴染みのあるメトリクスであること。activation が高いほど App の出足が良いことを示します。

5. Retention：ユーザーは App に戻ってくるか

ChatGPT App の Retention は、一般的なウェブプロダクトより少し難しいです。一方で、ChatGPT 自体は人が戻ってくる場所です。他方で、戻ってくる先が自分たちの App とは限りません。私たちはユーザーがGiftGenius に戻ってくるかを理解する必要があります。

認証（モジュール 10）があれば、安定した userId や tenantId を持てます。この場合の古典的な定義は簡単です。最初の "workflow_completed" からたとえば 7 日後に、新しい "workflow_completed" か、少なくとも "app_opened" があれば、そのユーザーは「維持（retained）」されたと見なします。

認証がない場合は、sessionId とヒューリスティックな userKey（たとえば _meta に OpenAI アカウントがあればそのハッシュ）に基づく弱いメトリクスを使えますが、この講義では 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"）を追加しました。これらが収益のプロダクトメトリクス（コンバージョンと平均注文額）の鍵になります。

ユーザーが「ギフトを購入」ボタンを押し、（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" へ」—— コマースのフローがどれくらいうまく機能しているか（カードエラー、不正対策、決済 UX）。

同時に、これらのイベントは前回のコスト管理と cost 計測のレッスンで得た cost ログと結び付けられます。requestId や sessionId から、その購入に至るまでの tool 呼び出しとトークン/費用が分かります。これにより「平均 cost_per_paid_workflow」や「1 件の成功注文あたりの収益−原価」といったメトリクスが得られます。

7. Referral：ユーザーが他のユーザーを連れてくるとき

ChatGPT App の Referral 層は少し独特です。自前のプッシュ通知やメルマガはありませんが、ユーザーはチャットやリンクを共有したり、「Store で GiftGenius を検索して」と紹介できます。

技術的には、次のような場合に "referral_sent" と "referral_activated" を導入できます。

• App へのリンクにリファラルコードやパラメータ（?ref=friend123）を付与する
• "app_opened" のコンテキストで referral_source/campaign を処理する

MVP の基本では、GiftGenius の 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" が増えた）のに、activation とコンバージョンが落ちています——来たトラフィックの質が違ったか、UX を壊した可能性があります。こうした表が、良いマーケティングと単なる騒がしさを切り分けるのに役立ちます。

時間軸だけでなくコホートも有用です。ある週に来たユーザーの 7/30 日後の retention。とはいえ、最初は日次・週次のシンプルな切り口が作れれば十分です。

8. マーケティングを「イベント上の一連の実験」として運用する

ここからがいちばん「マーケティングらしい」部分です。外部の取り組み（記事、Store リスティング、パートナーシップ）を、App 内で見えているイベントとどう結び付けるか。

鍵となる原則は、どんなマーケティングアイデアも「どのプロダクトメトリクスを変えるべきか」という仮説として定義することです。

GiftGenius の例：

• 「Store リスティング（アイコン、説明、デモ動画）を改善すれば、新規ユーザーの "app_opened" が増え、できれば彼らのアクティベーション率も上がるはず」
• 「年末のギフトの選び方に関する記事を書き、そこに GiftGenius へのリンクを置けば、今後 3 日間で "app_opened"（referral_source = "blog_ny2025"）が増え、そのコホートで "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" がどれくらいか、そしてオーガニックとどう違うか。

重要なのは、私たちはどこか別の場所で描かれた「リーチ」だけでマーケティングの成功を判定しないことです。ブロガーの動画が 100 万再生であっても、それは素晴らしいですが、GiftGenius にとっての成功は「内部の "app_opened" と "workflow_completed" の伸び」です。

9. 例：GiftGenius のマーケティング実験

ここまでを 1 つのシナリオにまとめ、外部キャンペーンを 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" のユーザーとオーガニックのユーザー。もし「ブログ」コホートの方が、完了シナリオや決済の割合が高く、1 ユーザーあたりの収益が同等以上なら、そのキャンペーンは成功とみなせます。アプリの起動だけが伸び、"workflow_completed" と "checkout_success" へのコンバージョンが落ちるなら、その記事は主に冷やかしを連れてきている可能性があります。

このやり方の利点は、UTM をウェブの世界から内部の referral_source へ一度だけ丁寧に「翻訳」し、その後は ChatGPT 内の URL パラメータの手品をせず、App のプロダクト分析だけで運用できる点です。

同時に、どこかで CAC（掲載にかかった費用）や cost_per_task を記録していれば、原価も見られます。すると仮説はより「財務的な」実験に変わります。「このチャネルは採算が合うか？」です。

10. Privacy‑first な分析：ポリシーと常識を壊さない

もう 1 つ重要なのは、「ちょっとした Facebook」にならないことです。従来のウェブと違い、OpenAI は ChatGPT Apps におけるプライバシーに厳格です。個人データの追跡や不要な PII の収集、対話全文の無差別送信は NG です。

GiftGenius の良い分析作法は次のとおりです。

1. イベントにユーザーの生テキストを保存しない。代わりに「シナリオの事実」だけを記録する（シナリオの種類、表示したアイデアの件数、決済成功の事実など）。
2. ユーザーを区別する必要があるときは、email/氏名ではなく、疑名化された識別子（userId、tenantId）を使う。PII は認証つきの DB に置き、分析は匿名キーで扱う。
3. イベントやログでは、業務に不要な場合は個人を直接特定できるフィールドを避ける（たとえば配送先住所の全文は明らかにイベントには不要。置き場所は保護された commerce の DB）。
4. 可能な限り集計分析を使う。関心があるのは何百人単位の activation‑rate や retention であって、個々の住人名簿ではない。

また audit & lifecycle のモジュールで触れたように、ユーザーがデータ削除を求める場合は、retention のロジックがそれを考慮すべきです。ただしこれはモジュール 15 の範疇です。ここでは、分析が「何でも集めていい」免罪符にはならないことを覚えておきましょう。

11. cost 計測と SLO との接続：すべてを数えるマーケティング

技術的な理想像はこうです。構造化されたイベントの単一のストリームがあり、各ユーザーセッションに次が対応付けられています。

• プロダクトイベント（"app_opened"、"workflow_completed"、"checkout_success"）
• cost データ（トークン、cost_estimate、ツールごとの duration_ms）
• SLO メトリクス（MCP/ツールのレイテンシやエラー、可用性）

するとマーケティングやプロダクトの意思決定は、ほとんど自動的にデータドリブンになります。例えば、次のように問えます。

• 「キャンペーン X のユーザーの activation_rate はどれくらいで、彼らの成功したワークフローの平均コストはいくらか？」
• 「Store からのトラフィック増加に伴って、error_rate や p95 レイテンシは悪化していないか？」
• 「前回の『コスト↔品質』実験でモデルを安くしたとき、"checkout_success" へのコンバージョンは落ちていないか、そしてユーザーあたりの revenue は下がっていないか？」

しかも新しい仕組みを考案する必要はありません。すでに導入したログと cost 計測をそのまま使うだけです。

結局のところ、ChatGPT App のマーケティングは単なるトラフィックではなく、アプリ内部の具体的なプロダクトメトリクスの改善です。シナリオの主要ステップ（"app_opened"、"workflow_completed"、"checkout_success"）をログに残し、cost 計測や SLO と結び付け、マーケ活動を「ファネルのどの輪を改善したいのか」という仮説として定義しましょう。ファネルとプライバシーの制約を念頭に置けば、プロダクトと成長の意思決定は自然とより筋の通った持続的なものになります。

12. プロダクト指標とマーケティングでありがちなミス

ミス No.1: トラフィックのためのマーケティングで、アクティベーションを見ない。
しばしばチームは、記事やツイートの後に "app_opened" が急増したことに喜び、activation やコンバージョンを見ずに実験を成功とみなします。結果として「観光客」を大量に集め、負荷と cost を上げるだけで、お金を生まず、実ユーザーにもなりません。正しいアプローチは、ファネルの最初のステップのさらに先を見ることです。来訪者のうちどれくらいが "workflow_completed" と "checkout_success" まで到達したか。

ミス No.2: 統一されたユーザー識別子がない。
App がイベントをログし始めたのに、安定した userId や少なくとも tenantId を持っていないケースがあります。この状態では「1 日のイベント数」のようなことしか数えられず、retention や cost_per_user は出せません。後から正しいユーザートラッキングを追加するのは難しく、特にプライバシーの強い制約があるときはなおさらです。認証の段階（モジュール 10）で識別スキーマを設計し、すべてのイベントで使いましょう。

ミス No.3: 主要イベントではなく「すべての微細動作」をトラッキングする。
イベント分析に触れると、つい何でもログしたくなります。ホバー、各インプットのフォーカス、各リレンダー…。ChatGPT の文脈では特に有害です。こうしたイベントは利用モデルに馴染まず、ノイズを大量に生み、プライバシーリスクも高めます。シナリオの主要イベントに絞り、質の高い分析を行う方がずっと有益です。

ミス No.4: アトリビューションのないマーケティングキャンペーン。
よくあるパターンは、記事・動画・提携などのキャンペーンを打つのに、入ってくるトラフィックに印を付けず、後から「効いたのかどうか」を推測することです。結果として指標の変化がぼやけます。"app_opened" のイベントに referral_source や campaign のような明示フィールドを使うのがずっと良いです。たとえシンプルな UTM 風パラメータであってもそうし、そのコホートをオーガニックと比較しましょう。

ミス No.5: 「完全な分析」の名の下にプライバシー制約を無視する。
詳細を求めるあまり、イベントにユーザーのリクエスト文やギフト受取人の個人情報、住所などの PII を書き込み始めることがあります。これは OpenAI/Store のポリシー上も、法律上（GDPR、CCPA 等）も危険です。正しい分析は、シナリオの集計特徴と匿名識別子に基づいて構築されるべきで、「念のため」会話全体を保存することではありません。

ミス No.6: 品質や成長を無視して cost だけで最適化する。
cost のモジュール後は「節約モード」に走り、トークンをとにかく減らしたくなります。しかしその結果、activation‑rate、retention、"checkout_success" が落ちるなら、その節約は見かけ倒しです。プロダクトの価値を損なっているだけです。「cost ↔ 品質 ↔ 成長」という三角形を常に意識してください。プロンプト、モデル、UX の変更は、原価とプロダクトメトリクスの両面から評価する必要があります。