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

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‑логи, а не «логи‑романи» у вільній формі. Тепер поверх них будуємо подієву модель продукту.

Мінімальна ідея проста: кожен важливий крок у застосунку породжує обʼєкт події. На 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‑інструментації. Ми просто додали до нього продуктову подію.

Саме за "workflow_completed" ви рахуватимете activation‑rate: activation_rate = (кількість унікальних userId із щонайменше одним "workflow_completed") / (кількість унікальних userId з "app_opened" за період).

Можна дивитися й простіше: «частка сесій sessionId, у яких був "workflow_completed"». Важливо, щоб це була зрозуміла для вас метрика: що вищий activation, то кращий старт у застосунку.

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 — це про те, чи приходять люди знову користуватися застосунком, а не лише про те, чи дійшли вони до оплати один раз.

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‑лістинг, партнерства) з тим, що ми бачимо в подіях застосунку.

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

Наприклад, для GiftGenius:

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

Технічно це часто реалізується через додаткове поле campaign або referral_source у події "app_opened". Наприклад, якщо під час ініціалізації застосунку ви отримали з контексту 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", така економія лише здається вигідною: ви просто вбиваєте цінність продукту. Завжди тримайте в голові трикутник «вартість ↔ якість ↔ зростання»: будь‑які зміни у промптах, моделях і UX потрібно оцінювати крізь призму і собівартості, і продуктових метрик.