Marketing i wzrost oparte na metrykach produktowych

1. Dlaczego marketing ChatGPT App — to analityka produktowa, a nie „szum”

W klasycznym Webie można podpiąć Google Analytics, dodać tagi UTM do wszystkich linków, wstawić parę pikseli retargetingowych — i jakoś żyć. W ekosystemie ChatGPT jest inaczej. Użytkownik siedzi w interfejsie ChatGPT, a wasz App — to „gość” w tej rozmowie. Ciasteczka, iframe i Facebook Pixel tu nie mają racji bytu.

To automatycznie sprawia, że zdarzenia produktowe stają się głównym (i często jedynym) źródłem prawdy o wzroście. Jak często otwierają App? Czy dochodzą do kluczowego scenariusza? Czy wracają? Jak to się wiąże z przychodem? Na wszystkie te pytania odpowiada nie zewnętrzny licznik, lecz wasze zdarzenia MCP i analityka po stronie serwera.

Tutaj bardzo logicznie pojawia się termin product‑led growth (PLG): wzrost wynika nie z tego, ile banerów kupiliście, ale z tego, jak dobrze produkt zamyka scenariusz użytkownika i jak go rozwijacie na podstawie danych.

Dlatego głównym bohaterem tego wykładu jest lejek zdarzeń wewnątrz GiftGenius, a nie zewnętrzny kanał marketingowy. Kanały będą, ale tylko jako hipotezy wpływające na te zdarzenia.

AARRR dla GiftGenius: nasz piracki lejek

Model AARRR (Acquisition, Activation, Retention, Revenue, Referral) doskonale pasuje do ChatGPT App — trzeba go tylko przetłumaczyć na język zdarzeń naszej aplikacji.

Dla GiftGenius można opisać go tak:

app_opened

workflow_completed (pierwszy raz)

ponowne workflow_completed / app_opened

checkout_started, checkout_success

referral_sent, referral_activated (opcjonalnie)

Ważne jest, że ten lejek opisujemy nie klikami frontendu, lecz właśnie „zdarzeniami użycia” na poziomie MCP/App: użytkownik otworzył, przeszedł scenariusz, kupił, wrócił. W przeciwieństwie do Webu, gdzie czasem śledzicie „każdy ruch myszką”, tutaj analityka powinna być zwarta i sensowna: mniej o „gdzie kliknął”, więcej o „co zrobił w scenariuszu”.

Dla bazowej wersji GiftGenius w pierwszej kolejności skupiamy się na czterech pierwszych poziomach (Acquisition, Activation, Retention, Revenue). Referral pozostaje ważny, ale raczej jako kolejny etap rozwoju, który można włączyć, gdy jądro produktu i płatności się ustabilizuje.

2. Projektujemy model zdarzeń: od logów do analityki

W module o observability już uzgodniliśmy, że zapisujemy ustrukturyzowane logi JSON, a nie „logi‑powieści” w wolnej formie. Teraz na ich bazie budujemy model zdarzeń produktu.

Minimalny pomysł: każdy ważny krok w App tworzy obiekt zdarzenia. Po stronie MCP można go zarówno logować, jak i wysyłać do zewnętrznego systemu analitycznego (BI, ClickHouse, BigQuery — co tylko chcecie).

Najprostsza definicja zdarzeń dla GiftGenius może wyglądać tak:

// Ogólna forma zdarzenia
type GiftGeniusEventType =
  | 'app_opened'
  | 'workflow_started'
  | 'workflow_completed'
  | 'ideas_shown'
  | 'idea_clicked'
  | 'checkout_started'
  | 'checkout_success'
  | 'checkout_failed';

interface AnalyticsEvent {
  type: GiftGeniusEventType;
  userId?: string;          // z auth, jeśli jest
  sessionId: string;        // UUID sesji w ChatGPT
  timestamp: string;        // ciąg w formacie ISO
  properties?: Record<string, unknown>;
}

Wygodnie jest dodać małego helpera do wysyłania zdarzeń z części Next.js aplikacji:

async function trackEvent(event: AnalyticsEvent) {
  await fetch('/api/analytics', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify(event),
  });
}

Na serwerze /api/analytics możecie już zdecydować, co z tym zrobić: zapisać do bazy, wysłać do loggera albo streamować do data‑pipeline. Najważniejsze — aby wszystkie zdarzenia miały jednolity format. W praktyce będziecie mieć ten sam zestaw zdarzeń produktowych, ale kilka miejsc ich powstawania: część kroków wygodniej rejestrować bezpośrednio na serwerze MCP przez logger.info, część — wysyłać z widżetu jako AnalyticsEvent na /api/analytics. Ważne nie ile macie technicznych „rur”, ale to, że typy zdarzeń ("app_opened", "workflow_completed" itp.) i ich pola pozostają jednolite i spójne.

3. Acquisition: jak zrozumieć, skąd w ogóle biorą się użytkownicy

Pierwsze zadanie marketingu — odpowiedzieć na pytanie, kto do nas przychodzi i ilu ich jest. W ChatGPT App ten „przychód” rejestrowany jest uruchomieniem App w czacie. To, co chcemy logować, to "app_opened".

Dla GiftGenius można to zrobić zarówno po stronie widżetu (reagując na montowanie komponentu), jak i po stronie serwera (np. przy pierwszym callTool w sesji). Bardziej niezawodnie — po stronie serwera, żeby nie zależeć od specyfiki renderowania, ale dla prostoty rozważmy front.

Przykład komponentu widżetu GiftGenius z wywołaniem trackEvent przy pierwszym renderze:

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>
      {/* ...główny interfejs widżetu... */}
    </main>
  );
}

W praktyce zechcecie uzyskać sessionId i userId z już istniejącego kontekstu (np. z _meta lub tokena autoryzacyjnego), a nie generować je po stronie klienta. Sedno jednak w tym, że każde uruchomienie GiftGenius powinno generować takie zdarzenie.

Problem źródeł ruchu rozwiązuje się gorzej niż w Webie: referrery i tagi UTM są ograniczone. Zwykle używa się jednej z dwóch strategii. Pierwsza — uznać, że główne źródło ruchu to Store, i analizować tylko "app_opened" w czasie: jeśli wdrożycie nowy listing w Store, patrzycie na skok "app_opened" i dalsze poziomy lejka. Druga — używać jawnych parametrów: jeśli dajecie użytkownikowi link w rodzaju https://chat.openai.com/...&utm_source=blog2025, to przy pierwszym "app_opened" można pobrać ten tag z kontekstu i włożyć do pola referral_source.

Czyli metryki acquisition wyglądają mniej więcej tak: „liczba "app_opened" na dzień”, „liczba unikalnych userId, które uruchomiły App w tygodniu”, „rozkład po referral_source, jeśli jest dostępny”.

4. Activation: szukamy „aha‑momentu” wewnątrz GiftGenius

Samo acquisition nic nie znaczy, jeśli ludzie natychmiast zamykają App. Dlatego drugi kluczowy poziom — Activation. To moment, kiedy użytkownik po raz pierwszy poczuł, że App robi coś realnie użytecznego.

Dla GiftGenius logiczne jest powiązać ten moment z zakończeniem workflow: użytkownik wprowadził informacje o obdarowywanym, ustawił filtry, a App pokazała mu, powiedzmy, 10 trafnych pomysłów. Właśnie wtedy użytkownik po raz pierwszy widzi wartość.

Rejestrować to wygodnie zdarzeniem "workflow_completed". Taki krok najlepiej logować na serwerze MCP, kiedy zebraliście już wszystkie prezenty i wysyłacie wynik do widżetu:

logger.info('event.workflow_completed', {
  type: 'workflow_completed',
  userId,
  sessionId,
  requestId,
  ideasCount: giftIdeas.length,
  timestamp: new Date().toISOString(),
});

Tutaj logger — wasz ustrukturyzowany logger, który dodawaliście już dla SLO i instrumentacji kosztowej. Po prostu dodaliśmy do niego zdarzenie produktowe.

Właśnie na "workflow_completed" będziecie liczyć activation‑rate: activation_rate = (liczba unikalnych userId z co najmniej jednym "workflow_completed") / (liczba unikalnych userId z "app_opened" w danym okresie).

Można patrzeć też bardziej zgrubnie: „udział sesji sessionId, w których wystąpiło "workflow_completed"”. Ważne, by to była metryka, którą macie w nawyku: im wyższa aktywacja, tym lepszy start App.

5. Retention: czy użytkownicy wracają do waszego App

Retention dla ChatGPT App jest nieco bardziej złożone niż dla typowego produktu webowego. Z jednej strony ChatGPT samo w sobie to miejsce, do którego człowiek i tak wraca. Z drugiej — może wracać do wielu innych App, a nie do waszego. Musimy rozumieć, czy wraca do GiftGenius.

Przy uwierzytelnianiu (moduł 10) macie stabilny userId lub tenantId. W takim przypadku klasyczna definicja jest prosta: użytkownik uważa się za „utrzymanego” (retained), jeśli po, powiedzmy, 7 dniach od pierwszego "workflow_completed" ma nowe "workflow_completed" lub przynajmniej "app_opened".

Jeśli nie ma auth, można użyć słabszej metryki opartej na sessionId i heurystycznym userKey (np. hash konta OpenAI, jeśli dostępny w _meta), ale w tym wykładzie załóżmy, że userId jednak mamy.

W formie logiki podobnej do SQL wygląda to mniej więcej tak (pseudokod):

-- pierwsza aktywacja
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;

Nie musicie pisać takiej SQL‑urody na produkcji, ale ważne jest zrozumienie idei: retention to to, czy ludzie wracają, by ponownie używać App, a nie tylko czy raz doszli do płatności.

6. Revenue: łączymy lejek z pieniędzmi

Warstwa Revenue dla GiftGenius przypomina, po co to wszystko robimy. W module o commerce dodaliśmy już zdarzenia wokół płatności: "checkout_started", "checkout_success", "checkout_failed". Te same zdarzenia stają się kluczem do metryk przychodu: konwersji i średniego koszyka.

W momencie, gdy użytkownik naciska „Kup prezent” i tworzycie sesję checkout (przez ACP/Stripe), po stronie MCP warto zalogować zdarzenie:

logger.info('event.checkout_started', {
  type: 'checkout_started',
  userId,
  sessionId,
  requestId,
  amount: checkout.amount,
  currency: checkout.currency,
  timestamp: new Date().toISOString(),
});

Gdy przychodzi pomyślny webhook od PSP:

logger.info('event.checkout_success', {
  type: 'checkout_success',
  userId,
  sessionId,
  orderId,
  amount: payment.amount,
  currency: payment.currency,
  timestamp: new Date().toISOString(),
});

Teraz łatwo policzycie konwersję:

• „z "workflow_completed" do "checkout_started"” — jak często ludzie w ogóle przechodzą do płatności;
• „z "checkout_started" do "checkout_success"” — jak dobrze działa wasz przepływ commerce (błędy kart, fraud, UX płatności).

Jednocześnie te same zdarzenia łączą się z logami kosztów z poprzedniej lekcji o kontroli wydatków i instrumentacji kosztowej: po requestId lub sessionId wiecie, jakie wywołania narzędzi i ile tokenów/pieniędzy kosztowała droga do tego zakupu. To daje metryki w rodzaju „średni cost_per_paid_workflow” i „przychód minus koszt własny na jedno udane zamówienie”.

7. Referral: gdy użytkownicy przyprowadzają innych

Warstwa Referral w ChatGPT App jest trochę nietypowa. Nie macie własnych pushy i mailingów, ale użytkownicy mogą dzielić się czatami, linkami i po prostu mówić sobie nawzajem „wpisz GiftGenius w Store”.

Technicznie możecie wprowadzić zdarzenia "referral_sent" i "referral_activated", jeśli:

• dajecie użytkownikom kod polecający lub parametr w linku do App (?ref=friend123),
• albo przetwarzacie referral_source/campaign w kontekście "app_opened".

W podstawowym wariancie MVP GiftGenius Referral można zostawić na przyszłość — najpierw ważne jest zbudować Acquisition/Activation/Revenue i upewnić się, że jądro lejka działa. Trzeba jednak rozumieć, gdzie go „podpiąć”: do tych samych logów zdarzeń i metryk, a nie do oddzielnego Excela z kodami promocyjnymi.

Wizualny lejek GiftGenius

Aby łatwiej mieć obraz w głowie, warto narysować mały diagram:

flowchart LR
  A[app_opened] --> B[workflow_started]
  B --> C[workflow_completed]
  C --> D[checkout_started]
  D --> E[checkout_success]

Każda krawędź tutaj to konwersja, którą można mierzyć. Marketing, zmiany UX, eksperymenty z modelami — wszystko ostatecznie powinno przesuwać w górę jedną lub kilka z tych konwersji. Jeśli robicie coś i nie potraficie powiedzieć, która dokładnie krawędź ma się poprawić, to podejrzane.

Dashboardy wzrostu: jakie raporty są potrzebne w pierwszej kolejności

Wyobraźmy sobie minimalny dashboard wzrostu GiftGenius. Nie budujemy tutaj kosmicznego systemu BI — chcemy choćby tabelę, na którą można patrzeć co tydzień.

Przykład zagregowanego raportu dziennego:

Od razu widać, że 3. dnia „dowieziono” acquisition (wzrosło "app_opened"), ale activation i konwersja spadły — być może przyszedł nie ten ruch albo coś zepsuliście w UX. Właśnie takie tabelki pomagają oddzielić dobry marketing od po prostu głośnego.

Ponad przekrojami czasowymi warto patrzeć na kohorty: użytkownicy, którzy przyszli w danym tygodniu, i ich retention po 7/30 dniach. Na początek jednak wystarczy nauczyć się budować proste przekroje po dniach i tygodniach.

8. Marketing jako seria eksperymentów na zdarzeniach

Przechodzimy do najbardziej „marketingowego” momentu: jak spiąć aktywności zewnętrzne (artykuły, listing w Store, partnerstwa) z tym, co widzimy w zdarzeniach App.

Kluczowa zasada: każdą ideę marketingową formułujemy jako hipotezę o tym, które metryki produktowe powinny się zmienić.

Na przykład dla GiftGenius:

• „Jeśli poprawimy listing w Store (ikony, opis, wideo demo), to powinno wzrosnąć liczbowo "app_opened" od nowych użytkowników i, najlepiej, activation‑rate wśród nich”.
• „Jeśli napiszemy artykuł o wyborze prezentów na Nowy Rok i damy tam link do GiftGenius, to w najbliższe 3 dni powinny wzrosnąć "app_opened" z referral_source = "blog_ny2025", a następnie "workflow_completed" w tej kohorcie”.

Technicznie często realizuje się to poprzez dodatkowe pole campaign lub referral_source w zdarzeniu "app_opened". Na przykład, jeśli przy inicjalizacji App otrzymaliście z kontekstu ChatGPT pewien tag:

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

Teraz możecie tworzyć raporty „po kampaniach”: ile "app_opened" i "workflow_completed" mają ci, którzy przyszli z referral_source = "blog_ny2025", i jak to się różni od „organiki”.

Ważne, że nie uznajemy marketingu za sukces tylko na podstawie „zasięgów”, które ktoś narysował gdzie indziej. Jeśli bloger mówi, że jego wideo obejrzało milion osób — świetnie, ale dla GiftGenius sukcesem będzie „wzrost "app_opened" i "workflow_completed" u nas wewnątrz”.

9. Przykład: eksperyment marketingowy dla GiftGenius

Zbierzmy wszystko razem w jednym konkretnym scenariuszu i przy okazji starannie powiążmy kampanię zewnętrzną ze zdarzeniami produktowymi wewnątrz GiftGenius.

Załóżmy, że chcecie sprawdzić hipotezę: artykuł w popularnym blogu o prezentach przyprowadzi „właściwych” użytkowników. W artykule dajecie link nie bezpośrednio do ChatGPT, ale na własny landing, na przykład:

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

Użytkownik trafia na krótki landing z opisem GiftGenius i przyciskiem „Otwórz w ChatGPT”. Po stronie backendu landingu odczytujecie utm_source i zapisujecie go w profilu użytkownika (albo w osobnej tabeli), na przykład jako acquisitionSource = "giftblog2025". Przycisk na landingu prowadzi już do waszego ChatGPT App w Store, dalej użytkownik podłącza App i zaczyna z niego korzystać.

Kiedy ten użytkownik uruchamia GiftGenius w ChatGPT, a wasz backend dostaje pierwsze wywołanie z Apps SDK / MCP, podciągacie zapisany acquisitionSource i dodajecie go do zdarzeń produktowych. Dla "app_opened" może to wyglądać tak:

logger.info('event.app_opened', {
  type: 'app_opened',
  userId,
  sessionId,
  referral_source: user.acquisitionSource ?? 'organic',
  timestamp: new Date().toISOString(),
});

Dokładnie tak samo oznaczacie zdarzenia "workflow_completed", "checkout_started", "checkout_success". Dalej eksperyment sprowadza się do porównania kohort: użytkownicy z referral_source = "giftblog2025" kontra „organika”. Jeśli kohorta „blogowa” ma wyższy udział ukończonych scenariuszy i płatności przy porównywalnym lub lepszym przychodzie na użytkownika, kampanię można uznać za udaną; jeśli rosną tylko uruchomienia aplikacji, a konwersja w "workflow_completed" i "checkout_success" spada, to znaczy, że artykuł przyprowadza głównie ciekawskich, a nie kupujących.

Taki sposób jest dobry, bo raz starannie „tłumaczycie” parametr UTM ze świata Webu na własne wewnętrzne pole referral_source i dalej pracujecie tylko z analityką produktową App — bez magii i bez prób przepychania parametrów URL bezpośrednio do ChatGPT.

Przy tym możecie patrzeć także na koszty własne, jeśli gdzieś rejestrujecie CAC (ile kosztowała publikacja) i cost_per_task. Wtedy hipoteza staje się już bardziej „finansowym” eksperymentem: „Czy ten kanał się zwraca?”.

10. Analityka w duchu privacy‑first: nie łamiemy polityk ani zdrowego rozsądku

Oddzielnie ważne — jak nie stać się trochę Facebookiem. W przeciwieństwie do klasycznego Webu, OpenAI dość twardo podchodzi do prywatności w ChatGPT Apps: nie wolno śledzić danych osobowych, zbierać zbędnej PII i wysyłać pełnych treści dialogów gdzie popadnie.

Dobre praktyki dla analityki GiftGenius wyglądają tak:

1. W zdarzeniach nie przechowywać surowego tekstu wiadomości użytkownika. Zamiast tego logować tylko „fakty scenariusza”: rodzaj scenariusza, liczbę pokazanych pomysłów, fakt udanej płatności.
2. Jeśli trzeba odróżniać użytkowników, używać pseudonimizujących identyfikatorów (userId, tenantId), a nie emaila/imienia. Wszelka PII trzymana jest w bazie z uwierzytelnianiem, a analityka operuje zanonimizowanymi kluczami.
3. W logach i zdarzeniach unikać pól, które mogą bezpośrednio identyfikować osobę, jeśli nie są potrzebne do działania (np. pełny adres dostawy w zdarzeniu jest nam ewidentnie niepotrzebny; jego miejsce jest w zabezpieczonej bazie commerce).
4. Maksymalnie używać analityki zagregowanej: interesuje was activation‑rate i retention dla setek użytkowników, a nie lokatorzy z imienia i nazwiska.

I nie zapominajmy, że mieliśmy już moduł o audit & lifecycle: jeśli użytkownik prosi o usunięcie swoich danych, logika dotycząca retention musi to uwzględniać. Ale to już bardziej temat modułu 15; tutaj ważne jest po prostu pamiętać, że analityka nie daje indulgencji na zbieranie dowolnych śmieci.

11. Powiązanie z instrumentacją kosztów i SLO: marketing, który liczy wszystko

Z technicznego punktu widzenia idealny obraz wygląda tak: macie jeden strumień ustrukturyzowanych zdarzeń, w którym każdej sesji użytkownika są przypisane:

• zdarzenia produktowe ("app_opened", "workflow_completed", "checkout_success");
• dane kosztowe (tokeny, cost_estimate, duration_ms dla narzędzi);
• metryki SLO (latencja i błędy MCP/narzędzi, dostępność).

Wtedy wszelkie decyzje marketingowe i produktowe stają się naprawdę oparte na danych niemal automatycznie. Możecie pytać:

• „Jaki jest activation_rate użytkowników z kampanii X i ile średnio kosztuje ich udany workflow?”
• „Czy nie rośnie error_rate albo p95 latency wraz ze wzrostem ruchu ze Store?”
• „Jeśli potaniliśmy model w eksperymencie «koszt ↔ jakość» z poprzedniej lekcji, czy nie spadła konwersja do "checkout_success" i czy nie zmniejszył się revenue na użytkownika?”

I to wszystko nie wymaga już wymyślania nowych systemów — po prostu używacie tych samych logów i narzędzi kosztowych, które wdrożyliście wcześniej.

W rezultacie marketing ChatGPT App to nie ruch sam w sobie, ale poprawa konkretnych metryk produktowych wewnątrz waszej aplikacji. Logujcie kluczowe kroki scenariusza ("app_opened", "workflow_completed", "checkout_success"), łączcie je z instrumentacją kosztów i SLO i formułujcie aktywności marketingowe jako hipotezy o tym, które dokładnie ogniwo lejka chcecie poprawić. Jeśli macie w głowie ten lejek i ograniczenia prywatności, decyzje dotyczące produktu i wzrostu niemal automatycznie stają się bardziej sensowne i trwałe.

12. Typowe błędy przy pracy z metrykami produktowymi i marketingiem

Błąd nr 1: marketing dla ruchu, a nie dla aktywacji.
Często zespoły cieszą się nagłym wzrostem "app_opened" po jakimś artykule lub tweecie i uznają eksperyment za udany, nie patrząc na activation i konwersję. W efekcie dostają masę „turystów”, którzy podnoszą obciążenie i koszty, ale nie przynoszą pieniędzy i nie stają się realnymi użytkownikami. Właściwe podejście — zawsze patrzeć na lejek dalej niż pierwszy krok: ilu z przychodzących doszło do "workflow_completed" i "checkout_success".

Błąd nr 2: brak jednolitego identyfikatora użytkownika.
Zdarza się, że App zaczyna logować zdarzenia, ale bez stabilnego userId albo chociaż tenantId. W takim trybie możecie policzyć tylko coś w rodzaju „liczby zdarzeń na dzień”, ale nie retention i nie cost_per_user. Późniejsze dodanie poprawnego user‑trackingu bywa trudne, zwłaszcza jeśli istnieją już silne ograniczenia prywatności. Lepiej przemyśleć schemat identyfikacji jeszcze na etapie uwierzytelniania (moduł 10) i używać go we wszystkich zdarzeniach.

Błąd nr 3: śledzenie „każdego kichnięcia” zamiast kluczowych zdarzeń.
Pierwsza reakcja na analitykę zdarzeń — zacząć logować absolutnie wszystko: najechania myszką, każdy fokus inputu, każdy rerender. W kontekście ChatGPT jest to szczególnie szkodliwe: takie zdarzenia słabo pasują do modelu użycia, tworzą tony szumu i zwiększają ryzyka prywatnościowe. Znacznie bardziej użyteczne jest ograniczenie się do kilku kluczowych zdarzeń scenariusza i ich jakościowa analiza.

Błąd nr 4: kampanie marketingowe bez atrybucji.
Częsty wzorzec: zespół uruchamia kampanię (artykuł, wideo, partnerstwo), ale w żaden sposób nie oznacza ruchu przychodzącego i potem zgaduje, „czy zadziałało”. W rezultacie wszystkie zmiany w metrykach się rozmywają. Znacznie lepiej używać jawnych pól referral_source lub campaign w zdarzeniach "app_opened", nawet jeśli robi się to przez proste parametry podobne do UTM, a następnie porównywać te kohorty z „organiką”.

Błąd nr 5: ignorowanie ograniczeń prywatności w imię „pełnej analityki”.
Czasem w pogoni za detalami do zdarzeń zaczyna się pisać tekst zapytań, dane osobowe obdarowywanego, adresy i inne PII. To niebezpieczne na dwóch płaszczyznach: z punktu widzenia polityk OpenAI/Store i z punktu widzenia realnego ryzyka prawnego (GDPR, CCPA itd.). Właściwa analityka opiera się na zagregowanych cechach scenariusza i anonimowych identyfikatorach, a nie na przechowywaniu całej rozmowy „na wszelki wypadek”.

Błąd nr 6: optymalizacja tylko pod koszty, bez uwzględnienia jakości i wzrostu.
Po module o kosztach łatwo popaść w skrajny „tryb oszczędności”, kiedy próbujecie obniżyć liczbę tokenów za wszelką cenę. Jeśli przy tym spada activation‑rate, retention i "checkout_success", to oszczędność jest pozorna: po prostu zabijacie wartość produktu. Zawsze miejcie w głowie trójkąt „koszt ↔ jakość ↔ wzrost”: wszelkie zmiany w promptach, modelach i UX należy oglądać zarówno przez pryzmat kosztu własnego, jak i metryk produktowych.