Монетизация, pricing и эксперименты «стоимость ↔ качество»

1. Зачем вообще думать о монетизации именно сейчас

До этого модуля главный вопрос звучал как «работает ли это вообще?». Теперь мы добавляем следующий уровень сложности: «а окупается ли это?».

Для LLM‑приложений это особенно больно: переменные расходы (LLM‑токены, rerank‑модели, эмбеддинги) легко выносят вам мозг вместо ваших привычных «сервер за $20 и Postgres за $15». Игнорировать это — значит получить в конце месяца счёт от OpenAI, сравнимый с ипотекой.

Поэтому сегодня три большие темы:

1. Какие есть модели монетизации для ChatGPT App и конкретно нашего GiftGenius.
2. Как связать pricing ↔ cost_per_task и не продавать «100 подборов подарков за $1», если один подбор уже стоит $0.15.
3. Как ставить A/B‑эксперименты «стоимость ↔ качество»: менять модель, промпты, UX и логировать это так, чтобы через пару недель принимать решения по данным, а не по ощущениям.

При этом мы мягко подводим почву к следующему модулю про LLM‑evals и quality_score, но не ныряем туда кодом.

2. Модели монетизации ChatGPT App: B2C, B2B, фримиум и upsell

Если отбросить LLM‑магию, модели монетизации здесь очень похожи на те, что используются в обычных SaaS‑ и мобильных приложениях. Но у conversational‑интерфейса есть нюансы: пользователь часто не чувствует «где бесплатное, а где платное», и это нужно аккуратно проектировать в UX.

Разберём основные варианты на примере GiftGenius.

B2C: обычные пользователи и подарки

Здесь ваши клиенты — обычные люди, которые приходят в ChatGPT и просят: «подбери подарок для фаната космоса за 50 долларов». Вы можете продавать не свои товары, а только подбирать подарки для пользователя.

Типичные B2C‑модели:

1. Разовая покупка.
   Пользователь платит за конкретный сценарий. Например: бесплатные 3 идеи, дальше — платный «пакет» ещё из 10 идей для одного получателя.
2. Подписка.
   Ежемесячная плата за доступ. У GiftGenius это может быть «до 100 подборов в месяц» или «неограниченные подборы для частого дарителя».
3. Фримиум (free vs paid tiers).
   Базовый сценарий бесплатный (до N подборов в месяц, урезанный функционал), а платный даёт больше лимитов, мощную модель, дополнительные форматы подборов и историю. Это самая типичная модель для ChatGPT App: «внутри ChatGPT — базово бесплатно, а премиум‑возможности — за деньги».
4. Upsell внутри App.
   Пользователь делает бесплатный базовый подбор, видит нормальный результат, и вы мягко предлагаете: «хочешь, за $X я сделаю глубокий подбор с учётом вишлиста, соцсетей и т.п.?» или «оформи сразу подарочный сертификат».

B2B: команды, компании и корпоративные подарки

Тут в дело вступают HR, отделы маркетинга и «люди, отвечающие за подарки сотрудникам/клиентам».

Традиционный набор:

• Лицензия за пользователя (per seat).
  Например, план «HR‑Team» на 10 человек, у каждого доступ к GiftGenius, отчёты по подаркам и бюджетам.
• Лицензия за компанию (per company).
  «До 500 сотрудников, фиксированная цена в месяц, внутри — сколько угодно подборов».
• Дополнительные enterprise‑фичи.
  Отдельная админка, интеграции с HRIS/CRM, кастомные отчёты, SLA.

В обоих случаях вы считаете не «сколько стоит один подбор», а cost_per_user_per_month или cost_per_tenant_per_month и сравниваете с ценой лицензии.

Как выбрать модель для GiftGenius

Чтобы не закапываться в теорию, можно взять простой стартовый вариант:

• B2C: фримиум.
  3 подбора в месяц бесплатно, дальше — подписка за $5/месяц с неограниченными подборами и премиальной моделью.
• B2B: за компанию.
  Тариф «HR‑команда» за $99/месяц, включающий до 500 подборов для сотрудников, интеграцию с HR‑системой и отчётность.

Потом, когда появятся реальные данные по cost_per_task и конверсии, можно всё это крутить. Фактически эти цифры пока взяты «с потолка»: они кажутся разумными, но мы ещё не проверили, во сколько нам обходится один завершённый сценарий. В следующем разделе будем связывать такие тарифы с реальной себестоимостью — cost_per_task.

3. Связь цены и себестоимости: что такое cost_per_task

Теперь переходим к самому важному: как не устроить себе благотворительный фонд имени GPT‑5.

Интуиция: цена ≥ cost_per_task × маржа

В прошлой теме вы уже видели понятие cost_per_task — это суммарные затраты на один успешный сценарий: от «пользователь начал подбор» до «получил результат» (и, возможно, оплатил что‑то).

В него входят:

• расходы на LLM (tokens * price_per_token по входу/выходу, включая, возможно, rerank‑модели, эмбеддинги и т.п.);
• доля инфраструктурных расходов на один task (серверы, БД, очереди, MCP‑гейтвей) — часто считается по агрегированным данным;
• по желанию — транзакционные расходы (Stripe fee, фрод‑проверки), если вы считаете cost_per_task до «денег на руки».

Идея проста: цена сценария или подписки должна быть выше средней себестоимости одного сценария, умноженной на «запас по марже».

Если очень упростить:

price_per_task >= cost_per_task * ( 1 + margin )

Мы не будем захламлять лекцию цифрами и маржинальностью в процентах, важно именно интуитивное правило.

Пример для GiftGenius

Предположим, вы уже внедрили cost‑логирование из прошлой лекции, и у вас есть агрегированный отчёт:

• средний cost_per_task (один завершённый подбор подарка) = 0.15 USD;
• сюда уже включены LLM‑токены (несколько вызовов suggest_gifts, rerank и финальный summary) и доля инфраструктуры.

Дальше вы смотрите на сценарий:

• бесплатный пользователь делает подбор, иногда покупает сертификат на $50;
• конверсия в покупку среди завершённых подборов, скажем, 5%.

Пока мы не лезем в полную юнит‑экономику, но можно уже прикинуть: если из 100 подборов:

• вы тратите 100 × $0.15 = $15;
• из них 5 заканчиваются чек‑аутом по $50;
• выручка 5 × $50 = $250.

Выглядит хорошо: грубо ($250 – $15) и плюс комиссии Stripe, налоги и прочая боль. Но важно понимать, что при слишком щедрой подписке (скажем, 100 подборов за $1) вы легко уйдёте в минус.

Мини‑пример кода: сохранение cost_per_task в TypeScript

Предположим, у вас есть MCP‑tool, который завершает workflow подбора и знает его общий cost:

// Тип для финальных метрик сценария
type TaskMetrics = {
  taskId: string;
  userId: string;
  costPerTaskUsd: number;
  modelName: string;
  completedAt: string;
};

// Условная функция логирования метрик
async function logTaskMetrics(metrics: TaskMetrics) {
  console.log(JSON.stringify({ 
    level: "info",
    event: "workflow_completed",
    ...metrics,
  }));
}

// Где-то в коде обработчика завершения подбора:
await logTaskMetrics({
  taskId: context.taskId,
  userId: context.userId,
  costPerTaskUsd: context.costEstimateUsd, // посчитан из токенов
  modelName: context.modelName,
  completedAt: new Date().toISOString(),
});

Такой лог потом легко агрегировать в дашборде, чтобы видеть распределение cost_per_task по моделям, пользователям, сценариям.

4. Pricing: как переводить cost_per_task в реальные цены

Теперь, когда cost_per_task у нас есть, надо решить, за что и сколько брать с пользователя.

Простое правило для B2C

Для B2C можно выбрать эмпирическое правило:

«Мы готовы тратить на LLM+infra не больше X% от выручки».

Например, вы решаете, что не хотите тратить больше 20% оборота на LLM‑затраты. Тогда:

• если cost_per_task = $0.15, то минимальная цена за один платный сценарий должна быть ≈ $0.75, чтобы 0.15 было примерно 20% от 0.75;
• если вы продаёте подписку, то оцениваете, сколько усреднённых сценариев придётся на одного подписчика в месяц, и умножаете.

Совершенно нормально начать «на глазок», а потом корректировать цены, когда появятся реальные данные (спойлер: появятся не сразу).

Простое правило для B2B

В B2B обычно смотрят на:

• cost_per_user_per_month или cost_per_tenant_per_month;
• готовность бизнеса платить (величина проблемы, которую вы решаете).

Например, если HR‑команда через GiftGenius распределяет подарки на десятки тысяч долларов в год, подписка за $99/месяц выглядит скромно, даже если ваши LLM‑затраты на эту команду всего $10/месяц. Главное — понимать, что вы не хотите оказаться в ситуации, где cost_per_tenant = $80, а подписка — $50.

И да, такое случается, если «мы же AI, давайте пока всё бесплатно, а там разберёмся».

Небольшая функция‑«охранник» на сервере

Можно прямо в коде иметь простой «guard», который будет подсказывать вам, не ушла ли стоимость за разумные рамки при выборе цены:

function checkPricingSafety(params: {
  avgCostPerTaskUsd: number;
  plannedPricePerTaskUsd: number;
  maxCostShare: number; // например, 0.3 = 30%
}): boolean {
  const share = params.avgCostPerTaskUsd / params.plannedPricePerTaskUsd;
  return share <= params.maxCostShare;
}

// Пример:
checkPricingSafety({
  avgCostPerTaskUsd: 0.15,
  plannedPricePerTaskUsd: 0.75,
  maxCostShare: 0.3,
}); // true — окей, 20% < 30%

Это не заменяет финансовую модель, но даёт быструю sanity‑проверку (проверку «на здравый смысл»), особенно когда вы экспериментируете с ценами.

5. Эксперименты «модель / агент vs cost и конверсия»

Теперь переходим к самому интересному: A/B‑эксперименты.

Интуиция здесь простая:

• Вариант A — дорогая модель / более сложный workflow;
• Вариант B — дешёвая модель / упрощённый workflow;
• мы хотим понять, как это влияет одновременно на:
  • cost_per_task,
  • качество результата (по ощущениям пользователя и по будущим LLM‑оценкам),
  • бизнес‑метрики (конверсия, выручка).

С чем именно экспериментировать

Есть три основных оси экспериментов:

1. Модель.
   Например, GPT‑5 vs GPT‑5‑mini или вообще другая линейка. Обычно дорогая модель даёт лучшее качество и выше cost_per_task, дешёвая — наоборот.
2. Агентная логика / промпты.
   Более подробные шаги, длинные промпты, сложный reasoning — качественнее, но дороже; минималистичная логика — дешевле и иногда почти такая же по качеству.
3. UX‑формат.
   Длинный мастер с кучей полей и подсказок vs быстрый inline‑режим. Даже если модель та же, количество токенов и шагов может отличаться в разы.

Все эти вариации вы уже можете внедрять, важно только обернуть их в эксперименты с логированием.

Какие поля логировать для экспериментов

Поверх полей, которые вы логируете для cost (tokens, model, cost_estimate, user_id, request_id и т.д.), добавляются экспериментальные поля:

• experiment_id — уникальный идентификатор эксперимента (например, "gift_model_ab_2025_11").
• variant — какая ветка у конкретного пользователя: "A", "B", "control", "treatment" и т.п.
• model_name или agent_version — чтобы потом не вспоминать, что за конфигурация стояла.
• результат сценария:
  • был ли workflow_completed;
  • был ли checkout_success;
  • итоговый cost_per_task.
• опционально — quality_score (про него чуть позже, это мостик в модуль про LLM‑evals).

Пример JSON‑лога события эксперимента

Типичный лог‑ивент может выглядеть так:

{
  "level": "info",
  "timestamp": "2025-11-21T20:15:03.123Z",
  "event": "experiment_task_result",
  "experiment_id": "gift_model_ab_2025_11",
  "variant": "A",
  "user_id": "user_123",
  "task_id": "task_456",
  "model_name": "gpt-5.2",
  "workflow_completed": true,
  "checkout_success": false,
  "cost_per_task_usd": 0.18,
  "quality_score": null,
  "request_id": "req_abc",
  "trace_id": "trace_xyz"
}

Такие записи отлично агрегируются в любой аналитике: можно строить таблицы вида «variant A vs B по cost/конверсии/доходу».

Пример кода: логирование эксперимента в MCP‑tool

Представим, что ваш MCP‑сервер уже посчитал стоимость сценария (cost_per_task) и знает, в какой ветке эксперимента находится пользователь:

type ExperimentContext = {
  experimentId: string;
  variant: "A" | "B";
};

async function logExperimentResult(params: {
  ctx: ExperimentContext;
  userId: string;
  taskId: string;
  modelName: string;
  costPerTaskUsd: number;
  workflowCompleted: boolean;
  checkoutSuccess: boolean;
}) {
  const event = {
    level: "info" as const,
    event: "experiment_task_result",
    timestamp: new Date().toISOString(),
    experiment_id: params.ctx.experimentId,
    variant: params.ctx.variant,
    user_id: params.userId,
    task_id: params.taskId,
    model_name: params.modelName,
    cost_per_task_usd: params.costPerTaskUsd,
    workflow_completed: params.workflowCompleted,
    checkout_success: params.checkoutSuccess,
  };

  console.log(JSON.stringify(event));
}

Где‑то выше вы решаете, к какому варианту относится пользователь (по user_id, tenant_id или случайно), и передаёте ExperimentContext в обработчик workflow. На этом уровне мы зафиксировали, что и как логировать для экспериментов: какие поля нужны и где их писать. Дальше поговорим о том, как превращать такие эксперименты в понятные продуктовые гипотезы и решения по pricing, а не просто в набор логов.

6. Теперь немного о quality_score и LLM‑evals

Более подробно я расскажу эту тему в 20-м модуле, а сейчас просто поделюсь идеей: quality_score — это оценка качества ответа/решения по шкале, например, от 0 до 10, часто от отдельной LLM‑модели‑«судьи». Подробнее про LLM‑as‑judge я расскажу в 20-м модуле.

Сейчас нам не нужны детали реализации — это тема следующего модуля — но важно понять концепцию:

• помимо денег мы хотим измерять ещё и качество;
• мы можем попросить либо человека, либо вторую модель оценить: «насколько хорошо GiftGenius подобрал подарок по 10‑балльной шкале?»;
• дальше мы можем смотреть, как quality_score коррелирует с:
  • конверсией в покупку;
  • удержанием пользователей;
  • willingness‑to‑pay (готовностью платить).

С точки зрения логов это просто ещё одно поле:

type ExperimentResultEvent = {
  experiment_id: string;
  variant: string;
  user_id: string;
  task_id: string;
  cost_per_task_usd: number;
  quality_score?: number; // 0-10, может быть undefined
};

На этом в рамках сегодняшней лекции мы остановимся: детали LLM‑evals, golden‑кейсов и «LLM‑as‑judge» будут дальше по курсу, сейчас достаточно понимать, куда этот score потом воткнуть в эксперименты. Именно quality_score спасает от классической ошибки оптимизации «только под стоимость»: он позволяет численно увидеть, где мы уже слишком удешевили сценарий, начали терять качество и вместе с ним — конверсию и выручку.

7. Как использовать эксперименты для pricing и монетизации

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

Пример гипотезы: дорогая модель vs дешёвая

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

• Вариант A — дорогая модель (GPT‑5), богатый reasoning, длинный мастер.
• Вариант B — дешёвая модель (GPT‑5‑mini), чуть более простой промпт и короче conversation.

Гипотеза: замена модели на дешёвую уменьшит cost_per_task минимум на 50%. При этом качество по пользователю и LLM‑оценке (наш quality_score) упадёт не более чем на 5–10%, а конверсия в покупку не просядет.

Технически для каждого task вы логируете те же поля, что и в разделе 5.2:

• experiment_id = "gift_model_ab_2025_11";
• variant = "A" или "B";
• model_name;
• cost_per_task_usd;
• workflow_completed;
• checkout_success;
• quality_score (когда появится LLM‑evals).

Через неделю‑две вы можете:

• построить средний cost_per_task по A и B;
• сравнить checkout‑rate (долю сценариев с успешной оплатой);
• сравнить средний quality_score, если он есть.

Если B почти не проигрывает в качестве, но в два раза дешевле, вы можете либо:

• перейти на B и повысить маржу;
• или сохранить цену, но снизить стоимость подписки для пользователя (и таким образом усиливать рост).

Пример гипотезы: качественный upsell

Другая гипотеза: если после бесплатных 3 идей показывать премиальный upsell «полный отчёт по подаркам + рекомендации по тексту открытки» за $4.99, конверсия в покупку вырастет хотя бы на 2 процентных пункта (2 п.п.). При этом cost_per_task увеличится не более чем на $0.05.

Здесь эксперимент уже не столько про модель, сколько про UX и product‑логику. Но технически всё то же самое:

• разные варианты UX по variant;
• логирование cost и revenue на сценарий;
• анализ uplift (насколько новая логика дала больше денег и не взорвала расходы).

Пример кода: запись простой выручки по задаче

Иногда удобно рядом с cost писать и выручку по сценарию:

type RevenueEvent = {
  taskId: string;
  userId: string;
  experimentId?: string;
  variant?: string;
  revenueUsd: number;
  checkoutSuccess: boolean;
};

async function logRevenue(event: RevenueEvent) {
  console.log(JSON.stringify({
    level: "info",
    event: "task_revenue",
    timestamp: new Date().toISOString(),
    ...event,
  }));
}

Связав потом task_revenue и experiment_task_result по taskId, можно считать для каждой ветки:

• средний revenue_per_task;
• средний cost_per_task;
• и строить простейший ROI.

8. Практическое упражнение: A/B‑эксперимент для GiftGenius

Чтобы было на что опираться и привязать теорию к практике, давайте прямо проговорим, как выглядел бы эксперимент «дорогая vs дешёвая модель» для GiftGenius — шаг за шагом, в формате практического упражнения.

Что мы меняем

• Вариант A:
  • модель gpt-5;
  • более детальный system‑prompt и шаги агента;
  • возможно, больше intermediate reasoning‑вызовов.
• Вариант B:
  • модель gpt-5-mini;
  • чуть более компактный промпт;
  • меньше вспомогательных tool‑вызовов, упрощённый флоу.

Как мы раскидываем пользователей по веткам

Самый простой способ — по hash от user_id:

function assignVariant(userId: string): "A" | "B" {
  const hash = Array.from(userId).reduce((acc, ch) => acc + ch.charCodeAt(0), 0);
  return hash % 2 === 0 ? "A" : "B";
}

Так мы гарантируем более‑менее равномерное распределение, и один user всегда попадает в одну и ту же ветку.

Что логируем

При завершении workflow подбора вы логируете тот же набор полей, что и в предыдущих разделах (5.2 и 7.1), и добавляете выручку:

• experiment_id = "gift_model_ab_2025_11";
• variant из функции выше;
• model_name, фактически использованная модель;
• cost_per_task_usd, суммарная стоимость токенов и инфраструктуры;
• workflow_completed (true/false);
• checkout_success (true/false);
• revenue_usd (0 или сумма покупки).

Опционально (чуть позже в курсе) добавится quality_score.

И эти данные попадают в ваш лог/аналитику, где их можно разложить по таблицам:

Из такой таблицы видно, что B даёт почти столько же денег при вдвое меньшей стоимости, и это сильный аргумент в его пользу.

9. Визуальная схема: как выглядит контур «стоимость ↔ качество ↔ монетизация»

Чтобы собрать всё в голове, нарисуем небольшую схему в духе «данные идут туда‑сюда»:

flowchart TD
    U[Пользователь в ChatGPT] --> A["ChatGPT App (GiftGenius)"]
    A --> E[Модуль эксперимента
назначает variant A/B]
    E --> AG[Агент / MCP tools
с разными моделями]
    AG -->|LLM вызовы| L[Логи usage & cost]
    AG -->|Результаты подбора| UI[Виджет / чат-ответ]
    UI -->|поведение: клики, покупки| BE[Commerce backend]

    L --> M[Метрики: cost_per_task,
cost_per_user]
    BE --> M
    M --> D[Дашборд pricing & экспериментов]

    subgraph "Будущий модуль 20"
      J[LLM-судья
quality_score]
      J --> M
    end

Сейчас вы находитесь ровно посередине этой схемы: умеете логировать cost и выручку, и добавляете поверх этого эксперименты и pricing. В следующем модуле прилетит тема Судья Дредд (LLM‑судья).

10. Типичные ошибки при работе с монетизацией и экспериментами

Когда в голове есть общая схема, легче увидеть, где обычно всё ломается. Ниже — набор типичных ошибок, которые удобно держать под рукой как чек‑лист при работе с монетизацией и cost‑экспериментами.

Ошибка №1: оптимизировать только под стоимость, забывая о качестве.
Распространённый сценарий: вы переходите на более дешёвую модель, видите, что счёт от OpenAI приятнее, и объявляете победу. А потом через месяц замечаете, что пользователи реже покупают подарочные сертификаты, хуже возвращаются, растёт поддержка «мне предложили какую‑то ерунду». Если не логировать ни quality_score, ни хотя бы прокси‑метрики (клики по идеям, сохранения, конверсии), легко уйти в «дешёвый, но бесполезный» режим.

Ошибка №2: считать cost_per_task только по LLM, игнорируя инфраструктуру и платежи.
Иногда разработчики аккуратно считают токены, но забывают о Redis, очередях, сторонних API, Stripe fee и прочем. В результате cost_per_task получается сильно заниженным, и цены кажутся более комфортными, чем есть на самом деле. Инфраструктура обычно считается по агрегированным данным, но её долю всё равно нужно закладывать в себестоимость сценария.

Ошибка №3: менять модели/UX без явных experiment_id и variant.
«Мы тут чуть переписали промпт, вроде стало лучше» — через месяц никто не помнит, когда именно поменяли, на каких данных это основано и к чему привело. Без явной маркировки экспериментов в логах (experiment_id, variant) и привязки к конкретным релизам сложно анализировать ретроспективу и доказывать, что улучшения не случайны.

Ошибка №4: принимать решения по слишком маленьким данным или слишком рано.
Если эксперимент работает два дня и вы на основании десяти оплат решаете, что модель B «гораздо выгоднее», это классический пример статистического шумового вывода. Нужен хотя бы минимальный горизонт — неделя, лучше больше — и достаточное количество сценариев, чтобы сравнивать средние значения и конверсии. В лекции мы не уходим в статистику, но правило «не делайте выводы по 5 событиям» стоит держать в голове.

Ошибка №5: использовать сложное ценообразование без простого ментального правила.
Можно нарисовать трёхуровневый тарифный план, цены в разных валютах и скидки по реферальным кодам, но при этом не иметь простого продукта правила вида «на LLM‑cost мы готовы тратить не больше X% выручки» или «цена сценария не должна опускаться ниже 3× средний cost_per_task». Без таких ограничителей легко потерять маржу и не заметить этого до конца месяца.

Ошибка №6: забывать о связи монетизации с маркетингом и ростом.
Монетизация и pricing живут не в вакууме: чем дороже подписка, тем выше отток и ниже конверсия; чем ниже цена, тем выше требования к cost‑оптимизации. Ошибка — смотреть только на «сколько мы сейчас зарабатываем» и не связывать это с acquisition/activation/retention‑метриками, о которых будет речь в следующей теме модуля. Эксперименты по pricing лучше сразу логировать в том же ключе, что и эксперименты по качеству и cost, чтобы видеть полную картину.