Монетизація, ціноутворення (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 усередині застосунку.
   Користувач робить безплатний базовий підбір, бачить нормальний результат — і ви м’яко пропонуєте: «хочете, за $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, який завершує робочий процес підбору й знає його загальний 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 та інфраструктуру не більше 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%

Це не замінює фінансову модель, але дає швидку перевірку на здоровий глузд. Особливо корисно, коли ви експериментуєте з цінами.

5. Експерименти «модель / агент: вплив на cost і конверсію»

Тепер переходимо до найцікавішого: A/B‑експериментів.

Інтуїція проста:

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

З чим саме експериментувати

Є три основні осі експериментів:

1. Модель.
   Наприклад, GPT‑5 проти GPT‑5‑mini або взагалі інша лінійка. Зазвичай дорога модель дає кращу якість і вищий cost_per_task, дешева — навпаки.
2. Агентна логіка / промпти.
   Детальніші кроки, довші промпти, складніше міркування (reasoning) — якісніше, але дорожче. Мінімалістична логіка — дешевше й іноді майже без втрати якості.
3. UX‑формат.
   Довгий «майстер» із купою полів і підказок проти швидкого 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 недостатньо. Важливо описувати зміни продукту як гіпотези з чіткою метрикою успіху.

Приклад гіпотези: дорога модель проти дешевої

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

• Варіант A — дорога модель (GPT‑5), потужний reasoning, довгий «майстер».
• Варіант B — дешева модель (GPT‑5‑mini), трохи простіший промпт і коротша взаємодія.

Гіпотеза: заміна моделі на дешевшу зменшить 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 і продуктову логіку. Але технічно все те саме:

• різні варіанти 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

Щоб було на що спиратися й прив’язати теорію до практики, давайте розберімо, як виглядав би експеримент «дорога проти дешевої моделі» для GiftGenius — крок за кроком, у форматі практичної вправи.

Що ми змінюємо

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

Як ми розподіляємо користувачів по гілках

Найпростіший спосіб — за хешем від 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";
}

Так ви гарантуєте приблизно рівномірний розподіл, і один користувач завжди потрапляє в одну й ту саму гілку.

Що логуємо

Під час завершення 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, щоб бачити повну картину.