Monetizasiya, pricing və eksperimentlər «xərc ↔ keyfiyyət»

1. Niyə məhz indi monetizasiya barədə düşünmək lazımdır

Buna qədər əsas sual belə səslənirdi: «bu ümumiyyətlə işləyir?» İndi isə növbəti çətinlik səviyyəsini əlavə edirik: «bəs özünü geri qaytarır?».

LLM‑tətbiqləri üçün bu xüsusilə ağrılıdır: dəyişən xərclər (LLM tokenləri, rerank modelləri, embeddinglər) sizin «$20‑lıq server və $15‑lik Postgres» kimi vərdiş etdiyiniz şeyləri asanlıqla kölgədə qoyur. Bunu ignor etmək — ayın sonunda ipoteka həcmində OpenAI hesabı almaq deməkdir.

Ona görə bu gün üç böyük mövzu var:

1. ChatGPT App və konkret olaraq GiftGenius üçün monetizasiya modelləri hansılardır.
2. pricing ↔ cost_per_task necə bağlanır və bir seçimin artıq $0.15 olduğu halda «100 hədiyyə seçimi $1‑a» satmamaq.
3. A/B‑eksperimentləri «xərc ↔ keyfiyyət» necə qurulur: modeli, promptları, UX‑i dəyişmək və bunu elə loglaşdırmaq ki, bir neçə həftə sonra qərarları hisslərlə deyil, verilənlərlə verəsiniz.

Eyni zamanda növbəti modulda LLM‑evals və quality_score mövzusuna zəmin hazırlayırıq, amma koda girmirik.

2. ChatGPT App üçün monetizasiya modelləri: B2C, B2B, freemium və upsell

LLM sehrini kənara qoysaq, buradakı monetizasiya modelləri adi SaaS və mobil tətbiqlərdə istifadə edilənlərə çox bənzəyir. Amma conversational‑interfeysin özəllikləri var: istifadəçi tez‑tez «harada pulsuz, harada pullu»nu hiss etmir və bunu UX‑də diqqətlə dizayn etmək lazımdır.

GiftGenius üzərindən əsas variantlara baxaq.

B2C: adi istifadəçilər və hədiyyələr

Burada müştəriləriniz — ChatGPT‑yə gəlib «kosmos fanatı üçün 50 dolları keçməyən hədiyyə seç» deyən adi insanlardır. Siz öz mallarınızı satmaya da bilərsiniz, yalnız istifadəçi üçün seçim edə bilərsiniz.

Tipik B2C‑modellər:

1. Birdəfəlik alış.
   İstifadəçi konkret ssenari üçün ödəniş edir. Məsələn: 3 ideya pulsuz, sonra — bir alıcı üçün əlavə 10 ideyadan ibarət pullu «paket».
2. Abunə.
   Giriş üçün aylıq ödəniş. GiftGenius üçün bu «ayda 100‑ə qədər seçim» və ya «tez‑tez hədiyyə verənlər üçün limitsiz seçim» ola bilər.
3. Freemium (pulsuz və pullu səviyyələr).
   Baza ssenari pulsuzdur (ayda N seçmə, məhdud funksionallıq), pullu isə daha çox limit, güclü model, əlavə seçim formatları və tarixçəni verir. Bu, ChatGPT App üçün ən tipik modeldir: «ChatGPT daxilində — əsasən pulsuz, premium imkanlar — ödənişlidir».
4. Tətbiq daxilində upsell.
   İstifadəçi pulsuz baza seçimi edir, normal nəticə görür və siz yumşaq şəkildə təklif edirsiniz: «istəsən, $X qarşılığında wishlist, sosial şəbəkələr və s. nəzərə alınmaqla dərin seçim edim?» və ya «dərhal hədiyyə sertifikatı rəsmiləşdir».

B2B: komandalar, şirkətlər və korporativ hədiyyələr

Burada HR, marketinq şöbələri və «əməkdaşlara/müştərilərə hədiyyələrə cavabdeh insanlar» işə qoşulur.

Ənənəvi paket:

• İstifadəçi görə lisenziya (per seat).
  Məsələn, «HR‑Team» planı 10 nəfər üçün: hər kəsin GiftGenius‑a girişi, hədiyyələr və büdcələr üzrə hesabatlar.
• Şirkətə görə lisenziya (per company).
  «500 əməkdaşa qədər, aylıq sabit qiymət, daxilində istədiyiniz qədər seçim».
• Əlavə enterprise‑funksiyalar.
  Ayrı admin paneli, HRIS/CRM inteqrasiyaları, xüsusi hesabatlar, SLA.

Hər iki halda siz «bir seçimin qiyməti»ni deyil, cost_per_user_per_month və ya cost_per_tenant_per_month hesablayır və lisenziya qiyməti ilə müqayisə edirsiniz.

GiftGenius üçün modeli necə seçmək olar

Teoriyada itib‑batmamaq üçün sadə start variantı götürmək olar:

• B2C: freemium.
  Aylıq 3 seçim pulsuz, sonra — $5/ay abunə limitsiz seçim və premium model ilə.
• B2B: şirkət üzrə.
  «HR‑komanda» tarifi $99/ay: işçilər üçün 500‑ə qədər seçim, HR‑sistemlə inteqrasiya və hesabatlılıq.

Sonra isə cost_per_task və konversiyalar üzrə real məlumatlar gələndə hər şeyi tənzimləmək olar. Faktiki olaraq bu rəqəmlər hələ «təxmini» götürülüb: məntiqli görünürlər, amma bir uğurlu ssenarinin bizə nə qədər başa gəldiyini hələ yoxlamamışıq. Növbəti bölmədə bu cür tarifləri real maya dəyəri — cost_per_task ilə bağlayacağıq.

3. Qiymət və maya dəyərinin əlaqəsi: cost_per_task nədir

İndi ən vacib olana keçək: GPT‑5 adına özünüz üçün xeyriyyə fondu yaratmamaq üçün nə etməli.

İntuisiya: qiymət ≥ cost_per_task × marja

Keçən mövzuda siz artıq cost_per_task anlayışını gördünüz — bu, bir uğurlu ssenari üçün ümumi xərclərdir: «istifadəçi seçimi başladı»dan «nəticəni aldı»ya (və bəlkə də nəyisə ödədiyinə) qədər.

Bura daxildir:

• LLM xərcləri (giriş/çıxış üzrə tokens * price_per_token, bura bəzən rerank modelləri, embeddinglər və s. də daxildir);
• bir task üçün infrastruktur xərclərinin payı (serverlər, DB, növbələr, MCP gateway) — tez‑tez aqreqasiya olunmuş məlumatlara əsasən hesablanır;
• istəyə bağlı — tranzaksiya xərcləri (Stripe fee, fırıldaqçılıq yoxlamaları), əgər siz cost_per_taskı «əldə qalan pula» qədər hesablayırsınızsa.

Fikir sadədir: ssenari və ya abunənin qiyməti, bir ssenarinin orta maya dəyərindən «marja ehtiyatı» ilə vurulmuş halda yüksək olmalıdır.

Çox sadələşdirsək:

price_per_task >= cost_per_task * ( 1 + margin )

Mühazirəni faizlərlə doldurmayacağıq, əsas intuitiv qaydadır.

GiftGenius üçün nümunə

Tutaq ki, siz keçən mühazirədən cost‑loglaşdırmanı tətbiq etmisiniz və aqreqasiya olunmuş hesabatınız var:

• orta cost_per_task (bir tamamlanmış hədiyyə seçimi) = 0.15 USD;
• bura artıq LLM tokenləri (bir neçə suggest_gifts çağırışı, rerank və yekun summary) və infrastruktur payı daxildir.

Sonra ssenariyə baxırsınız:

• pulsuz istifadəçi seçim edir, bəzən $50‑lıq sertifikat alır;
• tamamlanmış seçimlər arasında alışa konversiya, tutalım, 5%.

Hələ tam unit‑iqtisadiyyata girmirik, amma artıq təxmini hesablamaq olar: əgər 100 seçimdən:

• siz 100 × $0.15 = $15 xərcləyirsiniz;
• onlardan 5‑i $50 ilə checkout edir;
• gəlir 5 × $50 = $250.

Yaxşı görünür: kobud hesabla ($250 – $15) və üstəlik Stripe komissiyaları, vergilər və digər ağrılar. Amma başa düşmək vacibdir ki, çox səxavətli abunə (məsələn, 100 seçim $1‑a) sizi asanlıqla zərərə salar.

Mini kod nümunəsi: cost_per_task‑in TypeScript‑də saxlanması

Tutaq ki, sizdə seçim workflow‑unu tamamlayan və ümumi xərci bilən MCP‑tool var:

// Ssenarinin yekun metrikləri üçün tip
type TaskMetrics = {
  taskId: string;
  userId: string;
  costPerTaskUsd: number;
  modelName: string;
  completedAt: string;
};

// Metrikləri jurnallaşdırmaq üçün şərti funksiya
async function logTaskMetrics(metrics: TaskMetrics) {
  console.log(JSON.stringify({ 
    level: "info",
    event: "workflow_completed",
    ...metrics,
  }));
}

// Seçimin tamamlanması handler-ində haradasa:
await logTaskMetrics({
  taskId: context.taskId,
  userId: context.userId,
  costPerTaskUsd: context.costEstimateUsd, // tokenlərdən hesablanıb
  modelName: context.modelName,
  completedAt: new Date().toISOString(),
});

Belə logu sonra dashboardda asanlıqla aqreqasiya etmək olar ki, cost_per_task paylanmasını modellər, istifadəçilər, ssenarilər üzrə görəsiniz.

4. Pricing: cost_per_task‑i real qiymətlərə necə çevirmək

İndi cost_per_task bizdə olduğuna görə, istifadəçidən nə üçün və nə qədər almağı müəyyənləşdirmək lazımdır.

B2C üçün sadə qayda

B2C üçün empirik qayda seçmək olar:

«LLM+infra üçün gəlirin X%-indən çox xərcləməyə hazır deyilik».

Məsələn, qərar verirsiniz ki, LLM xərclərinə dövriyyənin 20%‑dən çox sərf etmək istəmirsiniz. O zaman:

• əgər cost_per_task = $0.15‑dirsə, bir pullu ssenari üçün minimal qiymət təqribən $0.75 olmalıdır ki, 0.15, 0.75‑in təxminən 20%‑i olsun;
• əgər abunə satırsınızsa, bir abunəçiyə ayda nə qədər orta ssenari düşəcəyini qiymətləndirir və vurursunuz.

«Təxmini» başlamaq tam normaldır, real məlumatlar gələndə (spoiler: dərhal gəlməyəcək) qiymətləri korreksiya edəcəksiniz.

B2B üçün sadə qayda

B2B‑də adətən baxılanlar:

• cost_per_user_per_month və ya cost_per_tenant_per_month;
• biznesin ödəməyə hazır olması (sizin həll etdiyiniz problemin böyüklüyü).

Məsələn, HR komanda GiftGenius vasitəsilə ildə on minlərlə dollar dəyərində hədiyyələr paylayırsa, $99/ay abunə çox mülayim görünür, hətta bu komanda üçün LLM xərcləriniz ayda cəmi $10 olsa belə. Əsas odur ki, istəmirsiniz cost_per_tenant = $80, abunə isə $50 olan vəziyyətdə qalasınız.

Və bəli, belə olur, əgər «biz AI‑yıq, hələlik hər şeyi pulsuz edək, sonra baxarıq» deyirsinizsə.

Serverdə kiçik «mühafizəçi» funksiyası

Elə kodun özündə sadə bir «guard» saxlamaq olar ki, qiyməti seçərkən xərcin ağlabatan həddi aşmamasını sizə xatırlatsın:

function checkPricingSafety(params: {
  avgCostPerTaskUsd: number;
  plannedPricePerTaskUsd: number;
  maxCostShare: number; // məsələn, 0.3 = 30%
}): boolean {
  const share = params.avgCostPerTaskUsd / params.plannedPricePerTaskUsd;
  return share <= params.maxCostShare;
}

// Nümunə:
checkPricingSafety({
  avgCostPerTaskUsd: 0.15,
  plannedPricePerTaskUsd: 0.75,
  maxCostShare: 0.3,
}); // true — ok, 20% < 30%

Bu, maliyyə modelini əvəz etmir, amma sürətli sanity‑yoxlama verir, xüsusilə qiymətlərlə eksperiment aparanda.

5. «Model / agent vs cost və konversiya» eksperimentləri

İndi ən maraqlı hissəyə keçirik: A/B‑eksperimentlər.

İntuisiya sadədir:

• Variant A — bahalı model / daha mürəkkəb workflow;
• Variant B — ucuz model / sadələşdirilmiş workflow;
• biz başa düşmək istəyirik ki, bunlar eyni vaxtda nəyə necə təsir edir:
  • cost_per_task,
  • nəticənin keyfiyyəti (istifadəçi hissiyyatına və gələcək LLM‑qiymətləndirmələrinə görə),
  • biznes metrikləri (konversiya, gəlir).

Nə ilə eksperiment aparmaq olar

Eksperimentlərin üç əsas oxu var:

1. Model.
   Məsələn, GPT‑5 vs GPT‑5‑mini və ya ümumiyyətlə başqa xətt. Adətən bahalı model daha yaxşı keyfiyyət və daha yüksək cost_per_task verir, ucuz model isə əksinə.
2. Agent məntiqi / promptlar.
   Daha detallı addımlar, uzun promptlar, mürəkkəb reasoning — daha keyfiyyətli, amma bahalı; minimalist məntiq — daha ucuz və bəzən demək olar ki, eyni keyfiyyət.
3. UX formatı.
   Çox sahəli uzun wizard vs sürətli inline rejim. Hətta model eyni olsa da, token və addım sayı dəfələrlə fərqlənə bilər.

Bütün bunları artıq tətbiq edə bilərsiniz, vacib olan isə onları eksperimentlərlə birlikdə loglaşdırmaqdır.

Eksperimentlər üçün hansı sahələri loglaşdırmaq

Cost üçün loglaşdırdığınız sahələrə (tokens, model, cost_estimate, user_id, request_id və s.) əlavə olaraq eksperimental sahələr gəlir:

• experiment_id — eksperiment üçün unikallıq identifikatoru (məsələn, "gift_model_ab_2025_11").
• variant — konkret istifadəçinin düşdüyü qol: "A", "B", "control", "treatment" və s.
• model_name və ya agent_version — sonra «hansı konfiqurasiya idi»ni yada salmamaq üçün.
• ssenarinin nəticəsi:
  • workflow_completed olubmu;
  • checkout_success olubmu;
  • son cost_per_task.
• opsional — quality_score (bu barədə bir az sonra, LLM‑evals moduluna keçid).

Eksperiment hadisəsinin JSON log nümunəsi

Tipik log event belə görünə bilər:

{
  "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"
}

Belə qeydlər istənilən analitik sistemdə əla aqreqasiya olunur: «variant A vs B cost/konversiya/gəlir üzrə» cədvəllərini qura bilərsiniz.

Kod nümunəsi: MCP‑tool‑da eksperimentin loglaşdırılması

Təsəvvür edək ki, MCP serveriniz artıq ssenarinin xərcini (cost_per_task) hesablayıb və istifadəçinin hansı eksperiment qolunda olduğunu bilir:

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));
}

Yuxarıda haradasa istifadəçinin hansı varianta düşdüyünü ( user_id, tenant_id və ya təsadüfi bölgü ilə) müəyyən edir və ExperimentContexti workflow işləyicisinə ötürürsünüz. Bu səviyyədə eksperimentlər üçün nə və necə loglaşdıracağımızı sabitlədik: hansı sahələr lazımdır və onları harada yazmaq. İndi isə belə eksperimentləri sadəcə log dəsti deyil, monetizasiya və pricing üzrə anlaşılan məhsul hipotezlərinə və qərarlara necə çevirməkdən danışacağıq.

6. İndi bir az quality_score və LLM‑evals barədə

Bu mövzunu 20‑ci modulda daha ətraflı danışacağam, indi isə fikri paylaşım: quality_score — cavabın/qərarın keyfiyyətinin, məsələn, 0‑dan 10‑a qədər şkala üzrə, çox vaxt ayrıca «hakim» rolunda olan LLM modeli tərəfindən qiymətləndirilməsidir. LLM‑as‑judge haqqında daha çox 20‑ci modulda danışacağam.

Hazırda reallaşdırma detalları lazım deyil — bu, növbəti modulun mövzusudur — amma konsepsiyanı anlamaq vacibdir:

• puldan əlavə keyfiyyəti də ölçmək istəyirik;
• insandan və ya ikinci modeldən soruşa bilərik: «GiftGenius 10‑ballıq şkala üzrə hədiyyəni nə dərəcədə yaxşı seçdi?»;
• sonra quality_scoreun aşağıdakılarla necə korrelyasiya etdiyinə baxa bilərik:
  • alışa konversiya;
  • istifadəçilərin saxlanması (retention);
  • willingness‑to‑pay (ödəməyə hazır olma).

Loglar baxımından bu, sadəcə daha bir sahədir:

type ExperimentResultEvent = {
  experiment_id: string;
  variant: string;
  user_id: string;
  task_id: string;
  cost_per_task_usd: number;
  quality_score?: number; // 0-10, undefined ola bilər
};

Bugünkü mühazirə çərçivəsində burada dayanırıq: LLM‑evals, golden case‑lər və «LLM‑as‑judge» detalları kursun irəlidəki hissəsində olacaq, indi isə bu score‑u eksperimentlərə hara qoşacağınızı anlamaq kifayətdir. Məhz quality_score «yalnız xərci optimallaşdırmaq» klassik səhvindən xilas edir: o, ssenarini həddindən artıq ucuzlaşdırdığımız, keyfiyyəti və bununla birlikdə konversiya və gəliri itirdiyimiz nöqtəni rəqəmlərlə görməyə imkan verir.

7. Eksperimentləri pricing və monetizasiya üçün necə istifadə etməli

İndi sadəcə eksperimentləri loglaşdırmırıq, onları monetizasiyaya təsiri olan, aydın uğur metrikli biznes hipotezləri kimi rəsmiləşdiririk. Təkcə experiment_id loglaşdırmaq kifayət deyil: məhsul dəyişikliklərini uğur metrikləri açıq olan hipotezlər kimi formalaşdırmaq vacibdir.

Hipoteza nümunəsi: bahalı model vs ucuz

GiftGenius üçün belə bir eksperiment təsəvvür edək:

• Variant A — bahalı model (GPT‑5), zəngin reasoning, uzun wizard.
• Variant B — ucuz model (GPT‑5‑mini), bir az daha sadə prompt və daha qısa conversation.

Hipoteza: modeli ucuzla əvəz etmək cost_per_taskı minimum 50% azaldacaq. Bu halda istifadəçi və LLM qiymətləndirilməsinə (bizim quality_score) görə keyfiyyət 5–10%‑dən çox düşməyəcək və alışa konversiya enməyəcək.

Texniki olaraq hər task üçün 5.2 bölməsindəki ilə eyni sahələri loglaşdırırsınız:

• experiment_id = "gift_model_ab_2025_11";
• variant = "A" və ya "B";
• model_name;
• cost_per_task_usd;
• workflow_completed;
• checkout_success;
• quality_score (LLM‑evals gələndə).

Bir‑iki həftə sonra siz:

• A və B üçün orta cost_per_taskı qurursunuz;
• checkout‑rate‑i (uğurlu ödənişli ssenarilərin payı) müqayisə edirsiniz;
• orta quality_scoreu müqayisə edirsinizsə, əgər varsa.

Əgər B keyfiyyətdə demək olar uduzmursa, amma iki dəfə ucuzdursa, siz ya:

• B‑yə keçib marjanı artırırsınız;
• ya da qiyməti saxlayıb istifadəçi üçün abunə dəyərini azaldırsınız (və beləliklə artımı gücləndirirsiniz).

Hipoteza nümunəsi: keyfiyyətli upsell

Başqa hipoteza: pulsuz 3 ideyadan sonra «tam hədiyyə hesabatı + açıqca mətni üçün tövsiyələr» adlı premium upsell‑i $4.99‑a göstərsək, alışa konversiya ən azı 2 faiz bəndi artacaq. Bu zaman cost_per_task $0.05‑dən çox artmayacaq.

Burada eksperiment daha çox UX və məhsul məntiqi haqqındadır. Amma texniki olaraq yenə eynidir:

• variant üzrə fərqli UX;
• ssenariyə görə cost və revenue loglaşdırması;
• uplift analizi (yeni məntiq nə qədər pul gətirdi və xərcləri partlatmadımı).

Kod nümunəsi: ssenari üzrə sadə gəlirin yazılması

Bəzən cost ilə yanaşı ssenari üzrə gəliri də yazmaq rahat olur:

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,
  }));
}

Sonra task_revenue ilə experiment_task_resultu taskId üzrə bağlayaraq hər qol üçün hesablamaq olar:

• orta revenue_per_task;
• orta cost_per_task;
• və ən sadə ROI.

8. Praktiki məşq: GiftGenius üçün A/B‑eksperiment

Teoriyanı praktikaya bağlamaq üçün, gəlin «bahalı vs ucuz model» eksperimentinin GiftGenius üçün necə görünəcəyini addım‑addım, praktiki məşq formatında danışaq.

Nəyi dəyişirik

• Variant A:
  • model gpt-5;
  • daha detallı system‑prompt və agent addımları;
  • ola bilsin, daha çox intermediate reasoning çağırışı.
• Variant B:
  • model gpt-5-mini;
  • bir az daha kompakt prompt;
  • daha az köməkçi tool çağırışı, sadələşdirilmiş flow.

İstifadəçiləri qollara necə bölürük

Ən sadə üsul — user_id‑nin hash‑inə görə:

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";
}

Beləliklə, daha‑az bərabər bölgü təmin edirik və bir user həmişə eyni qola düşür.

Nələri loglaşdırırıq

Seçim workflow‑u tamamlananda əvvəlki bölmələrdə (5.2 və 7.1) olduğu kimi eyni sahələri loglaşdırır və gəliri əlavə edirsiniz:

• experiment_id = "gift_model_ab_2025_11";
• yuxarıdakı funksiyadan variant;
• faktiki istifadə olunan model — model_name;
• tokenlər və infrastrukturun cəmi — cost_per_task_usd;
• workflow_completed (true/false);
• checkout_success (true/false);
• revenue_usd (0 və ya alış məbləği).

Opsional olaraq (kursun bir az sonra) quality_score əlavə olunacaq.

Və bu məlumatlar log/analitikanıza düşəcək, orada onları cədvəllərə sala bilərsiniz:

Belə cədvəl göstərir ki, B iki dəfə ucuz olsa da demək olar eyni pulu gətirir və bu, onun xeyrinə ciddi arqumentdir.

9. Vizual sxem: «xərc ↔ keyfiyyət ↔ monetizasiya» konturu necə görünür

Hər şeyi beyninizdə toplamaq üçün «məlumatlar ora‑bura gedir» ruhunda kiçik bir sxem çəkək:

flowchart TD
    U[İstifadəçi ChatGPT-də] --> A["ChatGPT App (GiftGenius)"]
    A --> E[Eksperiment modulu
variant A/B təyin edir]
    E --> AG[Aqent / MCP tools
fərqli modellərlə]
    AG -->|LLM çağırışları| L[Usage & cost logları]
    AG -->|Seçim nəticələri| UI[Widget / çat cavabı]
    UI -->|davranış: kliklər, alışlar| BE[Commerce backend]

    L --> M[Metriklər: cost_per_task,
cost_per_user]
    BE --> M
    M --> D[Pricing və eksperimentlər üzrə dashboard]

    subgraph "Gələcək modul 20"
      J[LLM-hakim
quality_score]
      J --> M
    end

Hazırda siz məhz bu sxemin ortasındasınız: cost və gəliri loglaşdırmağı bacarırsınız və bunun üzərinə eksperimentlər və pricing əlavə edirsiniz. Növbəti modulda isə Hakim Dredd mövzusu (LLM‑hakim) gələcək.

10. Monetizasiya və eksperimentlərlə işləyərkən tipik səhvlər

Başınızda ümumi sxem olanda, adətən nəyin harada qırıldığını görmək daha asandır. Aşağıda — monetizasiya və cost eksperimentləri ilə işləyərkən əl altında saxlamaq üçün uyğun olan tipik səhvlərdən ibarət bir yoxlama siyahısı var.

Səhv №1: yalnız xərci optimallaşdırmaq, keyfiyyəti yaddan çıxarmaq.
Yayğın ssenari: daha ucuz modelə keçirsiniz, OpenAI hesabı daha xoş görünür və qələbə elan edirsiniz. Bir aydan sonra görürsünüz ki, istifadəçilər hədiyyə sertifikatlarını daha az alır, daha pis qayıdır, dəstək mesajları artır: «mənə nəsə cəfəngiyyat təklif edildi». Nə quality_scoreu, nə də heç olmasa proksi metrikləri (ideyalara kliklər, saxlamalar, konversiyalar) loglaşdırmasanız, asanlıqla «ucuz, amma faydasız» rejimə düşmək olar.

Səhv №2: cost_per_task‑ı yalnız LLM üzrə hesablayıb, infrastruktur və ödənişləri ignor etmək.
Bəzən tərtibatçılar tokenləri dəqiq sayır, amma Redis, növbələr, üçüncü tərəf API‑ləri, Stripe fee və s.‑ni unudurlar. Nəticədə cost_per_task xeyli aşağı görünür və qiymətlər realdan daha rahat təsir bağışlayır. İnfrastruktur adətən aqreqasiya olunmuş məlumatlarla hesablanır, amma onun payını da ssenarinin maya dəyərinə daxil etmək lazımdır.

Səhv №3: model/UX‑i açıq experiment_id və variant olmadan dəyişmək.
«Burada promtu bir az yeniləmişik, elə bil daha yaxşı oldu» — bir ay sonra heç kim nə vaxt dəyişildiyini, bunun hansı məlumatlara əsaslandığını və nəyə gətirdiyini xatırlamır. Loglarda açıq eksperiment markalanması (experiment_id, variant) və konkret relizlərlə bağlanma olmadan retrospektiv analitika aparmaq və yaxşılaşmanın təsadüfi olmadığını sübut etmək çətindir.

Səhv №4: çox az məlumatla və ya çox tez qərar vermək.
Eksperiment iki gün işləyir və siz on ödənişə əsasən B modelinin «çox daha sərfəli» olduğuna qərar verirsiniz — bu, statistik səs‑küy nəticəsidir. Ən azı minimal üfüq lazımdır — bir həftə, daha yaxşısı daha çox — və kifayət qədər ssenari, ki, orta dəyərləri və konversiyaları müqayisə edəsiniz. Mühazirədə statistikaya girmirik, amma «5 hadisəyə görə nəticə çıxarmayın» qaydasını yadda saxlamaq dəyərlidir.

Səhv №5: sadə mental qayda olmadan mürəkkəb qiymətqoyma istifadə etmək.
Üç pilləli tarif planı, müxtəlif valyutalarda qiymətlər və referal endirimləri çəkə bilərsiniz, amma eyni zamanda «LLM‑xərclərə gəlirin X%‑indən çox xərcləmirik» və ya «ssenarinin qiyməti orta cost_per_taskın 3×‑indən aşağı düşməməlidir» kimi sadə məhsul qaydası olmaya bilər. Belə məhdudlaşdırıcılar olmadan marjanı itirmək və bunu ayın sonuna qədər görməmək asandır.

Səhv №6: monetizasiyanı marketinq və artımla əlaqələndirməməyi unutmaq.
Monetizasiya və pricing vakuumda yaşamır: abunə nə qədər bahadırsa, churn o qədər yüksək və konversiya aşağıdır; qiymət nə qədər aşağıdırsa, cost optimizasiyasına tələblər bir o qədər yüksəkdir. Səhv — yalnız «indi nə qədər qazanırıq»a baxmaq və bunu modulun növbəti hissəsində danışacağımız acquisition/activation/retention metrikləri ilə bağlamamaqdır. Pricing üzrə eksperimentləri keyfiyyət və cost üzrə eksperimentlərlə eyni açarla loglaşdırmaq daha yaxşıdır ki, tam mənzərəni görəsiniz.