Маркетинг и рост, завязанные на продуктовые метрики

1. Почему маркетинг ChatGPT App — это продуктовая аналитика, а не “шум”

В классическом вебе можно воткнуть Google Analytics, повесить UTM‑метки на все ссылки, поставить пару ретаргетинговых пикселей — и как‑то жить. В экосистеме ChatGPT всё иначе. Пользователь сидит в интерфейсе ChatGPT, а ваш App — это «гость» в этом диалоге. Куки, 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 (первый раз)

повторные workflow_completed / app_opened

checkout_started, checkout_success

referral_sent, referral_activated (опционально)

Важно, что эта воронка описывается не фронтенд‑кликами, а именно «событиями использования» на уровне MCP/App: пользователь открыл, прошёл сценарий, купил, вернулся. В отличие от веба, где вы иногда трекаете «каждое движение мышки», здесь аналитика должна быть компактной и осмысленной: меньше о «куда кликнул», больше о «что сделал в сценарии».

Для базовой версии 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;        // UUID сессии в ChatGPT
  timestamp: string;        // ISO-строка
  properties?: Record<string, unknown>;
}

Отдельно удобно завести маленький helper для отправки событий из 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 должен порождать такое событие.

Проблема источников трафика решается хуже, чем в вебе: рефереры и UTM‑метки ограничены. Обычно используют одну из двух стратегий. Первая — считать, что основной источник трафика — Store, и анализировать только "app_opened" по времени: если вы выкатили новый Store‑листинг, смотрите на всплеск "app_opened" и дальшие уровни воронки. Вторая — использовать явные параметры: если вы даёте пользователю ссылку вроде https://chat.openai.com/...&utm_source=blog2025, то при первом "app_opened" можно взять этот тег из контекста и положить в поле referral_source.

То есть acquisition‑метрики выглядят примерно так: «число "app_opened" в день», «число уникальных userId, которые запустили App в неделю», «распределение по referral_source, если оно есть».

4. Activation: находим “aha‑момент” внутри GiftGenius

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 и cost‑инструментации. Мы просто добавили в него продуктовый event.

Именно по "workflow_completed" вы будете считать activation‑rate: activation_rate = (количество уникальных userId с хотя бы одним "workflow_completed") / (количество уникальных userId с "app_opened" за период).

Можно смотреть и грубее: «доля сессий sessionId, в которых был "workflow_completed"». Важно, чтобы это была привычная вам метрика: чем выше activation, тем лучше старт у App.

5. Retention: возвращаются ли пользователи к вашему App

Retention для ChatGPT App чуть сложнее, чем для привычного веб‑продукта. С одной стороны, ChatGPT сам по себе — место, куда человек и так возвращается. С другой — он может возвращаться к куче других App, а не к вашему. Нам важно понимать, возвращается ли он к GiftGenius.

При наличии аутентификации (модуль 10) у вас есть стабильный userId или tenantId. В таком случае классическое определение простое: пользователь считается «удержанным» (retained), если спустя, скажем, 7 дней после первого "workflow_completed" у него есть новый "workflow_completed" или хотя бы "app_opened".

Если auth нет, можно использовать более слабую метрику на основе sessionId и эвристических userKey (например, hash по аккаунту 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: связываем воронку с деньгами

Revenue‑слой для GiftGenius закрепляет, зачем мы вообще всё это делаем. В модуле о 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(),
});

Когда приходит успешный webhook от PSP:

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 оплаты).

И одновременно эти же события соединяются с cost‑логами из предыдущего урока про контроль затрат и cost‑инструментацию: по requestId или sessionId вы знаете, какие tool‑вызовы и сколько токенов/денег стоили путь до этой покупки. Это даёт метрику вроде «средний cost_per_paid_workflow» и «доход‑минус‑себестоимость на один успешный заказ».

7. Referral: когда пользователи приводят других

Referral‑слой в ChatGPT App немного необычный. У вас нет своих push‑ов и рассылок, но у пользователей есть возможность делиться чатами, ссылками и просто рассказывать друг другу «загугли GiftGenius в Store».

Технически вы можете ввести события "referral_sent" и "referral_activated", если:

• даёте пользователям реферальный код или параметр в ссылке на App (?ref=friend123),
• или обрабатываете referral_source/campaign в контексте "app_opened".

В базовом 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. Именно такие таблички помогают отделить хороший маркетинг от просто громкого.

Поверх времени полезно смотреть и на когорты: пользователи, пришедшие в определённую неделю, и их retention через 7/30 дней. Но для начала достаточно научиться строить простые срезы по дням и неделям.

8. Маркетинг как серия экспериментов над событиями

Теперь переходим к самому «маркетинговому» моменту: как связать внешние активности (статьи, Store‑листинг, партнёрства) с тем, что мы видим в событиях App.

Ключевой принцип: любая маркетинговая идея формулируется как гипотеза о том, какие продуктовые метрики должны поменяться.

Например, для GiftGenius:

• «Если мы улучшим Store‑листинг (иконки, описание, демо‑видео), то должно вырасти количество "app_opened" от новых пользователей и, желательно, activation‑rate среди них».
• «Если мы напишем статью о выборе подарков к Новому году и дадим туда ссылку на GiftGenius, то в ближайшие 3 дня должны вырасти "app_opened" с referral_source = "blog_ny2025" и далее "workflow_completed" в этой когорте».

Технически это часто реализуется через дополнительное поле campaign или referral_source в событии "app_opened". Например, если при инициализации App вы получили из контекста ChatGPT некий тег:

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

Теперь вы можете строить отчёты «по кампаниям»: сколько "app_opened" и "workflow_completed" у тех, кто пришёл с referral_source = "blog_ny2025", и как это отличается от органики.

Важно, что мы не считаем маркетинг успешным только по «охватам», которые нам нарисовали где‑то ещё. Если блогер говорит, что его видео посмотрели миллион человек, это здорово, но для GiftGenius успехом будет «рост "app_opened" и "workflow_completed" у нас внутри».

9. Пример: маркетинговый эксперимент для GiftGenius

Соберём всё вместе на одном конкретном сценарии и заодно аккуратно привяжем внешнюю кампанию к продуктовым событиям внутри GiftGenius.

Представим, что вы хотите проверить гипотезу: статья в популярном блоге о подарках приведёт «правильных» пользователей. В статье вы даёте ссылку не прямо в ChatGPT, а на свой лендинг, например:

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

Пользователь попадает на короткий лендинг с описанием GiftGenius и кнопкой «Открыть в ChatGPT». На стороне бэкенда лендинга вы читаете utm_source и сохраняете его в профиле пользователя (или в отдельной таблице), например как acquisitionSource = "giftblog2025". Кнопка на лендинге уже ведёт в ваш ChatGPT App в Store, дальше пользователь подключает App и начинает им пользоваться.

Когда этот пользователь запускает GiftGenius в ChatGPT и ваш backend получает первый вызов от 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" против органики. Если у «блоговой» когорты выше доля завершённых сценариев и оплат при сопоставимом или лучшем доходе на пользователя, кампанию можно считать удачной; если растут только запуски приложения, а конверсия в "workflow_completed" и "checkout_success" проседает, значит, статья приводит в основном любопытных, а не покупателей.

Такой подход хорош тем, что вы один раз аккуратно «переводите» utm-метку из мира веба в своё внутреннее поле referral_source и дальше работаете только с продуктовой аналитикой App — без магии и без попыток прокинуть URL‑параметры напрямую внутрь ChatGPT.

При этом вы можете смотреть и на себестоимость, если где‑то фиксируете CAC (сколько стоило размещение) и cost_per_task. Тогда гипотеза превращается уже в более «финансовый» эксперимент: «Окупается ли этот канал?».

10. Privacy‑first аналитика: не ломаем политику и здравый смысл

Отдельный важный момент — как не стать немного Facebook’ом. В отличие от классического веба, OpenAI довольно жёстко относится к приватности в ChatGPT Apps: нельзя трекать личные данные, собирать лишнюю PII и отправлять полный текст диалогов куда попало.

Хороший тон для аналитики GiftGenius выглядит так:

1. В событиях не хранить голый текст сообщений пользователя. Вместо этого логировать только «факты сценария»: вид сценария, количество показанных идей, факт успешной оплаты.
2. Если нужно отличать пользователей, использовать псевдонимизирующие идентификаторы (userId, tenantId), а не email/имя. Любая PII хранится в базе с аутентификацией, а аналитика оперирует обезличенными ключами.
3. В логах и событиях избегать полей, которые могут прямо идентифицировать человека, если это не нужно для работы (например, полный адрес доставки в событии нам явно не нужен; его место — в защищённой базе commerce).
4. Максимально использовать агрегированную аналитику: вас интересуют activation‑rate и retention по сотням пользователей, а не жильцы поимённо.

И не забываем, что у нас уже был модуль про audit & lifecycle: если пользователь просит удалить свои данные, логика по retention должна это учитывать. Но это уже больше про модуль 15; здесь важно просто помнить, что аналитика не даёт индульгенцию на сбор любого мусора.

11. Связь с cost‑инструментацией и SLO: маркетинг, который считает всё

С технической точки зрения идеальная картина выглядит так: у вас есть единый поток структурированных событий, где каждой user‑сессии сопоставлены:

• продуктовые события ("app_opened", "workflow_completed", "checkout_success");
• cost‑данные (токены, cost_estimate, duration_ms по инструментам);
• SLO‑метрики (латентность и ошибки MCP/инструментов, доступность).

Тогда любые маркетинговые и продуктовые решения становятся по‑настоящему основанными на данных почти автоматически. Вы можете спрашивать:

• «Какой activation_rate у пользователей из кампании X и сколько стоит в среднем их успешный workflow?»
• «Не растёт ли error_rate или p95 latency по мере увеличения трафика из Store?»
• «Если мы удешевили модель в эксперименте «стоимость ↔ качество» из предыдущего урока, не просела ли конверсия в "checkout_success" и не снизился ли revenue на пользователя?»

И всё это уже не требует придумывать новые системы — вы просто используете те же логи и cost‑инструменты, которые внедрили ранее.

В итоге маркетинг ChatGPT App — это не про трафик сам по себе, а про улучшение конкретных продуктовых метрик внутри вашего приложения. Логируйте ключевые шаги сценария ("app_opened", "workflow_completed", "checkout_success"), связывайте их с cost‑инструментацией и SLO и формулируйте маркетинговые активности как гипотезы о том, какое именно звено воронки вы хотите улучшить. Если вы держите эту воронку и ограничения по приватности в голове, решения по продукту и росту почти автоматически становятся более осмысленными и устойчивыми.

12. Типичные ошибки при работе с продуктовыми метриками и маркетингом

Ошибка №1: маркетинг ради трафика, а не ради активации.
Часто команды радуются резкому росту "app_opened" после какой‑нибудь статьи или твита и считают эксперимент успешным, не глядя на activation и конверсию. В итоге получают кучу «туристов», которые поднимают нагрузку и cost, но не приносят денег и не становятся реальными пользователями. Правильный подход — всегда смотреть на воронку дальше первого шага: сколько из пришедших дошли до "workflow_completed" и "checkout_success".

Ошибка №2: отсутствие единого user‑идентификатора.
Иногда App начинает логировать события, но без стабильного userId или хотя бы tenantId. В таком режиме вы можете посчитать только что‑то вроде «количества событий в день», но не retention и не cost_per_user. Позже добавить корректный user‑tracking бывает сложно, особенно если уже есть сильные ограничения по приватности. Лучше продумать схему идентификации ещё на этапе аутентификации (модуль 10) и использовать её во всех событиях.

Ошибка №3: трекинг “каждого чиха” вместо ключевых событий.
Первая реакция на event‑аналитику — начать логировать абсолютно всё: наведение мышки, каждый фокус инпута, каждый ререндер. В ChatGPT‑контексте это особенно вредно: такие события плохо ложатся на модель использования, создают тонны шума и повышают риски по приватности. Гораздо полезнее ограничиться несколькими ключевыми событиями сценария и качественно их анализировать.

Ошибка №4: маркетинговые кампании без атрибуции.
Распространённый паттерн: команда запускает кампанию (статью, видео, партнёрство), но никак не помечает входящий трафик и потом гадает, «сработало или нет». В результате все изменения в метриках размываются. Гораздо лучше использовать явные поля referral_source или campaign в событиях "app_opened", даже если это делают через простые UTM‑подобные параметры, и затем сравнивать эти когорты с органикой.

Ошибка №5: игнорирование privacy‑ограничений ради “полной аналитики”.
Иногда в погоне за деталями в события начинают писать текст запросов, персональные данные получателя подарка, адреса и прочую PII. Это опасно сразу в двух плоскостях: с точки зрения политик OpenAI/Store и с точки зрения реального юридического риска (GDPR, CCPA и т.п.). Правильная аналитика строится на агрегированных признаках сценария и анонимных идентификаторах, а не на хранении всего разговора «на всякий случай».

Ошибка №6: оптимизация только по cost, без учёта качества и роста.
После модуля про cost легко уйти в экстремальное «режим экономии», когда вы пытаетесь снизить токены любой ценой. Если при этом падает activation‑rate, retention и "checkout_success", то экономия мнимо выгодна: вы просто убиваете ценность продукта. Всегда держите в голове треугольник «cost ↔ качество ↔ рост»: любые изменения в промптах, моделях и UX нужно смотреть через призму и себестоимости, и продуктовых метрик.

1

Задача

ChatGPT Apps, 19 уровень, 2 лекция

Недоступна

Минимальная продуктовая аналитика: /api/analytics + тестовая страница

Минимальная продуктовая аналитика: /api/analytics + тестовая страница

Открыть