Xərclərə nəzarət və cost-instrumentasiya

1. Niyə “işləyir” ≠ “özünü ödəyir”

LLM tətbiqlərinin vacib bir xüsusiyyəti var: hostinq üçün sabit xərclərə əlavə olaraq tez-tez bəzi sorğuların icrası üçün dəyişən xərclər yaranır ki, bunlar modellərin çağırışları ilə bağlıdır.

İki dünyanı fərqləndirmək vacibdir:

• model ChatGPT tərəfində işləyəndə (istifadəçi sizin App ilə ChatGPT-də ünsiyyət qurur və o mcp-tools çağırır) — tokenlər üçün ödənişi istifadəçi öz ChatGPT abunəsi ilə edir;
• sizin backend/MCP server özünüz OpenAI API və ya digər LLM servislərini çağıranda — bu tokenlər üçün artıq siz ödəyirsiniz.

Məhz ikinci halda sizdə klassik dəyişən LLM‑xərcləri yaranır ki, bunlar sorğuların sayından və “ağırlığından” (tokens_in/tokens_out) asılıdır.

Klassik ssenari:

1. Siz sevinclə GiftGenius-u proda buraxırsınız, hər şey uçur, istifadəçilər xoşbəxtdir.
2. Bir aydan sonra OpenAI + bulud + Stripe komissiyaları üçün hesab gəlir və qəfil məlum olur ki, “uğurlu artım” əslində “hər hədiyyə üçün qazandığımızdan daha çox ödəyirik” deməkdir.

FinOps yanaşması (FinOps) deyir: dəyər — latency və error‑rate kimi eyni metrikadır. Onu loglamaq, aqreqasiya etmək və ona əsasən qərar vermək lazımdır, “Excel-də təxmin etmək” yox.

Bu mühazirənin məqsədi — belə suallara cavab verə bilməkdir:

• “İstifadəçi user42 üçün bu konkret hədiyyə seçimi nə qədər başa gəldi?”
• “Bu həftə suggest_gifts aləti nə qədər pul yandırdı və bunun müqabilində nə qədər sifariş gətirdi?”

Və cavablar havadan yox, loglar və metrikalardan alınsın.

2. ChatGPT App xərclərinin strukturu

Gəlin xərc xəritəsindən başlayaq. Onsuz qalan hər şey rəqəmlərin xaotik toplanmasıdır.

LLM‑xərcləri (dəyişən)

Bunlar sizin backend tərəfindən modellərin çağırılması ilə bağlı olan hər şeydir:

• MCP serverdən və ya agentlərdən OpenAI modellərinə çağırışlar: GPT-5.1 / GPT-5-mini / embeddings / rerank / vision / TTS/STT və s.
• Əlavə modellər: axtarış üçün reranking, tövsiyələr üçün embeddinglər, təsvir generasiyası.

Vacib incə məqam: interfeysi Apps SDK ilə qurub yalnız daxili ChatGPT modelindən istifadə edəndə tokenlər üçün siz yox, istifadəçi (öz ChatGPT abunəsi ilə) ödəyir. Amma elə ki, MCP serveriniz özü OpenAI API-ni (Agents, Responses API, embeddings və s.) çağırmağa başlayır, tokenlər artıq sizin hesabınıza gedir.

Baza ideya: belə çağırışların dəyəri tokens_in və tokens_out göstəricilərinə, onları token qiymətinə vurmağa proporsionaldır.

MCP‑tool çağırışı özü‑özlüyündə tokenlər baxımından developer üçün pulsuzdur; xərclər yalnız onun handlerində OpenAI API və ya başqa LLM çağırmağa qərar verdiyiniz yerdə yaranır.

İnfrastruktur

Bunlar ətrafdakı bütün dəmir və servislərdir:

• MCP serverlər: Vercel / AWS / GCP / bare metal.
• Agentlər (əgər ayrı servis kimi işləyirsə).
• Məlumat bazaları: Postgres/MySQL, vektor DB-lər, S3/obyekt saxlama.
• Keşlər: Redis/KeyDB.
• Növbələr və worker-lər: məsələn, fon generasiyası, feedlərin yenidən hesablanması və s. üçün.

Bu xərclər daha çox aylıq sabit (və ya pilləli sabit) olur, ona görə də adətən bulud xərclərinin aqreqasiya olunmuş məlumatlarına görə hesablanır, hər sorğuya görə yox.

Ödəniş və xarici servislər

GiftGenius-da ACP/Stripe var, deməli bunlar yaranır:

• Hər uğurlu ödəniş üçün komissiyalar (Stripe bir neçə faiz + sabit hissə).
• Fraud və chargeback itkiləri.
• Xarici API-lərin dəyəri: e‑mail / SMS / push bildirişləri, əlavə analitika və s.

Başlanğıcda qəpik-quruşdur, amma miqyas artdıqca hiss olunmağa başlayır, ona görə heç olmasa loglar və hesabatlar səviyyəsində onları ayrıca göstərmək faydalıdır.

Yadda saxlamaq üçün kiçik cədvəl

tokens_in/out × price_per_token

Məqsədimiz: bu kateqoriyaları sistemdə konkret hadisələrlə əlaqələndirmək (tool çağırışları, workflow, checkout), yalnız yekun aylıq məbləğlərə baxmamaqdır.

3. Usage‑məlumatları harada toplamaq: üç qat

Cost-u “ayda bir dəfə” yox, real vaxtda hesablamaq üçün koda instrumentasiya tikmək lazımdır. Cəmi üç yer var.

MCP server: hər alət çağırışı

MCP server — ChatGPT‑nin sizin alətləri çağırdığı təbii nöqtədir. Burada biz:

• Çağırışın başlanğıc/son anını tuta bilərik.
• duration_ms (və ya latency_ms) ölçə bilərik.
• OpenAI cavabından tokenləri toplaya (əgər MCP bizim modeli çağırırsa) və ya heç olmasa onları qiymətləndirə bilərik.
• Logların əlaqəsi üçün user_id, tenant_id, request_id/trace_id əlavə edə bilərik.

GiftGenius üçün tool_invocation log‑hadisəsi sxematik olaraq belə görünür:

{
  "timestamp": "2025-11-20T12:34:56Z",
  "level": "info",
  "event": "tool_invocation",
  "request_id": "abc123",
  "user_id": "user42",
  "service": "mcp-giftgenius",
  "tool_name": "suggest_gifts",
  "tokens_in": 120,
  "tokens_out": 350,
  "cost_estimate_usd": 0.045,
  "latency_ms": 320
}

İndi eyni şeyi TypeScript tipi və bir parça kod şəklində.

// types/telemetry.ts
export interface ToolInvocationLog {
  event: 'tool_invocation';
  requestId: string;
  userId?: string;
  toolName: string;
  tokensIn?: number;
  tokensOut?: number;
  costEstimateUsd?: number;
  latencyMs: number;
}

// mcp/logger.ts
export function logToolInvocation(payload: ToolInvocationLog) {
  console.log(JSON.stringify({
    timestamp: new Date().toISOString(),
    level: 'info',
    ...payload,
  }));
}

İndi MCP alət handleri üçün “wrapper” (şərti olaraq suggest_gifts).

// mcp/tools/suggestGifts.ts
export async function handleSuggestGifts(ctx: Context, input: Input) {
  const started = Date.now();

  const llmResult = await callGiftModel(input); // burada OpenAI‑ni çağırırıq

  const duration = Date.now() - started;
  const { prompt_tokens, completion_tokens } = llmResult.usage ?? {};
  const costEstimate = estimateCost(prompt_tokens, completion_tokens);

  logToolInvocation({
    event: 'tool_invocation',
    requestId: ctx.requestId,
    userId: ctx.userId,
    toolName: 'suggest_gifts',
    tokensIn: prompt_tokens,
    tokensOut: completion_tokens,
    costEstimateUsd: costEstimate,
    latencyMs: duration,
  });

  return llmResult.output;
}

Hətta tokenləri “təxmini” mətn uzunluğuna görə hesablasaq belə, bu heç nə etməməkdən üstündür.

Agent səviyyəsi (Agents SDK): workflow addımları

Əgər Agents SDK istifadə edirsinizsə, agent ard-arda bir neçə alət çağıra bilər. Burada addımın kontekstini loglamaq vacibdir: agent hansı tapşırığı həll etməyə çalışır.

Məsələn, hər alət çağırışında agent runner-ına workflow_name və step_name sahələrini əlavə etmək olar: “ideyaların axtarışı”, “büdcəyə görə filtr”, “checkout-a hazırlıq”.

Bu, sonradan yalnız alətlərə görə yox, həm də ssenarinin addımlarına görə hesabatlar qurmağa imkan verəcək: birdən xərclərin 80%-i mənasız “əlavə dəqiqləşdirici addım”a gedir.

Agent ətrafında kiçik bir “hook” nümunəsi:

// agents/logStep.ts
export function logAgentStep(data: {
  requestId: string;
  workflow: string;
  step: string;
  toolName: string;
}) {
  console.log(JSON.stringify({
    timestamp: new Date().toISOString(),
    level: 'info',
    event: 'agent_step',
    ...data,
  }));
}

Və bunu runner-dan istifadə etmək:

// agents/giftAgent.ts
logAgentStep({
  requestId: run.requestId,
  workflow: 'gift_selection',
  step: 'rank_candidates',
  toolName: 'rerank_gifts',
});

Commerce: checkout və pul

Commerce qatında bizi maraqlandıran hadisələr:

• checkout_started — alış başlamışdır.
• checkout_success — ödəniş uğurlu oldu.
• checkout_failed — kod/tiplə səhv.

Və onlara əlavə etmək lazımdır:

• amount, currency.
• Eyni sessiyanın request_id-si ki, tool_invocation ilə bağlaya bilək.

Beləliklə bu suala cavab verə biləcəyik: “Bu alış bizə LLM xərclərində N sentə başa gəldi və M dollar gəlir gətirdi”.

Sadə checkout hadisələri handler nümunəsi:

// api/commerce/logCheckout.ts
export function logCheckoutEvent(e: {
  type: 'checkout_started' | 'checkout_success' | 'checkout_failed';
  requestId: string;
  userId?: string;
  amountCents?: number;
  currency?: string;
  errorCode?: string;
}) {
  console.log(JSON.stringify({
    timestamp: new Date().toISOString(),
    level: 'info',
    service: 'commerce',
    ...e,
  }));
}

4. Cost üçün strukturlaşdırılmış loglar (M17 ilə əlaqə)

Açar məqam: heç bir “azad” mətn logu yoxdur console.log("Tool suggest_gifts used 123 tokens"). Hər şey JSON-da.

17-ci modulda artıq sorğuları JSON şəklində, request_id, user_id, tool_name kimi baza sahələrlə loglamağa razılaşmışdıq. İndi bunun üstünə cost sahələrini əlavə edək.

Xərclərlə bağlı loglarda mütləq olmalı sahələr:

• timestamp, level.
• event (tool_invocation, agent_step, checkout_success və s.).
• request_id, trace_id — eyni workflow-un hadisələr zəncirini bağlamaq üçün.
• user_id, tenant_id — sonradan istifadəçi/komandaya görə aqreqasiya etmək üçün.
• tool_name / service.
• tokens_in, tokens_out, cost_estimate_usd.
• latency_ms, success/error_code.

Nümunələrdə dəyər sahəsini cost_estimate_usd (ABŞ dollarında dəyər) adlandıracağıq və bu adı kodda və dashboardlarda qoruyacağıq.

Məhz bu struktur imkan verir:

• Aqreqasiyalar qurmaq: tool_name, user_id, workflow üzrə orta cost_estimate_usd.
• “Bahalı” sorğuları artmış gecikmə və ya səhvlərlə əlaqələndirmək və ilk nələri optimallaşdırmalı olduğunuzu anlamaq.

Əgər artıq M17-də baza logger.info({...}) qurmusunuzsa, cost sahələrini əlavə etmək — yeni framework deyil, obyektə bir neçə əlavə xassədir.

5. LLM cost-u kodda təxmini necə hesablamaq olar

Formullar heç də qorxulu deyil. Bizə yalnız təxmini böyüklük dərəcəsi lazımdır, son sentə qədər billinglə ideal üst-üstə düşmək yox.

Usage-u OpenAI cavabından götürürük

MCP serveriniz OpenAI Response API-ni çağıranda, adətən usage obyektini alır:

{
  "usage": {
    "prompt_tokens": 120,
    "completion_tokens": 350,
    "total_tokens": 470
  }
}

Buna əsasən dəyəri hesablamaq rahatdır. Müxtəlif modellər üçün giriş/çıxış tokenlərinin 1M‑i üçün qiymətlər fərqlidir.

TypeScript-də ən sadə qiymətləndirici funksiya:

// mcp/cost.ts
type Usage = { prompt_tokens?: number; completion_tokens?: number };

const PRICING = {
  inputPerMillion: 2.5,   // 1M daxil olan token üçün dollarla qiymət, nümunə
  outputPerMillion: 10.0, // çıxış tokenləri üçün də
};

export function estimateCost(
  promptTokens?: number,
  completionTokens?: number,
): number {
  const inTokens = promptTokens ?? 0;
  const outTokens = completionTokens ?? 0;

  const inputCost = (inTokens / 1_000_000) * PRICING.inputPerMillion;
  const outputCost = (outTokens / 1_000_000) * PRICING.outputPerMillion;
  return Number((inputCost + outputCost).toFixed(6)); // bir az yuvarlaqlaşdırırıq
}

Buradakı qiymətlər təxminidir; real qiymətləri OpenAI-in aktual qiymət cədvəlindən götürüb konfiqə qoyacaqsınız. Vacibdir ki, bu funksiya hər alət çağırışında çağırılsın və nəticə logda cost_estimate_usd sahəsinə düşsün.

Əgər usage əlçatan deyilsə

Bəzən usage göndərməyən üçüncü tərəf LLM istifadə edirsiniz, yaxud real çağırışdan əvvəl qabaqcadan nəzarət lazımdır. O zaman:

• tiktoken və ya uyğun model üçün analoqu kimi kitabxana ilə tokenləri qiymətləndirin.
• Tarixi loglara görə orta dəyərləri götürün (median_tokens_in/median_tokens_out alət üçün) və qiymətə vurun.

Uzunluğu qiymətləndirmək üçün stub kod:

// mcp/costEstimateFallback.ts
export function roughTokenEstimate(text: string): number {
  // Kobud təxmini: 1 token ≈ 4 latın simvolu
  return Math.ceil(text.length / 4);
}

Bu rocket science deyil, amma məsələn, ucuz tarifə 200000 tokenlik prompt buraxmamağa imkan verir.

6. Açar cost metrikaları

Toplanan loglar — xammaldır. İndi onlardan hansı aqreqasiyaların həyati vacib olduğuna baxaq.

cost_per_tool_call

Nədir: konkret alətin bir çağırışının orta dəyəri.

Nəyə görə:

• Hansının xüsusilə bahalı olduğu görünür.
• “Bahalı və faydasız” olanları tapmaq olar: avg_cost_per_call yüksək, ssenarinin uğura konversiyası aşağı.

Loglara görə necə hesablamaq:

• Period üçün event = "tool_invocation" olan logları götürün.
• tool_name üzrə qruplaşdırın.
• Hər biri üçün avg(cost_estimate_usd) və üstəlik p95 (dəyərin 95-ci faizili) hesablayın.

cost_per_successful_task (və ya cost_per_workflow)

Task/workflow — istifadəçi səviyyəsində tamamlanmış ssenaridir:

• GiftGenius-da bu “hədiyyə seçimi + kartların göstərilməsi + istifadəçi N ideyanı saxladı” və ya “seçim → checkout → uğurlu alış” ola bilər.

Nə edirik:

• Workflow tamamlananda workflow_completed hadisəsini request_id, workflow_name və uğurluluq bayrağı ilə yazırıq.
• request_id vasitəsilə həmin workflow-a aid bütün tool_invocation hadisələrini “gətirir” və onların cost_estimate_usd cəmini hesablayırıq.

Beləliklə “bir uğurlu tapşırıq nə qədər başa gəldi” sualını alırıq — ssenarinin maya dəyərini anlamağın açarı.

cost_per_user / cost_per_tenant

B2B ssenarilərində tez-tez vacib olan sual: “Bir istifadəçi/bir komanda bizə ayda nə qədər başa gəlir?”

Hesablayırıq:

• tool_invocation və digər cost hadisələrini user_id və ya tenant_id üzrə qruplaşdırırıq.
• Period üzrə (gün, ay) cost_estimate_usd cəmini hesablayırıq.

Sonra bunu abunə qiyməti ilə müqayisə edirik. Əgər cost_per_user tarif qiymətinə çox yaxınlaşırsa, ya qiyməti qaldırmağın, ya da usage‑ı optimallaşdırmağın vaxtıdır (bu barədə növbəti mühazirədə — pricing və “dəyər ↔ keyfiyyət” eksperimentlərində danışacağıq).

7. Nümunə: GiftGenius üçün tool_invocation formatı və dashboard

İndi plan çalışmasında olanı edək: log hadisəsini və alətlər üzrə minimal dashboardu layihələndirək.

GiftGenius üçün tool_invocation hadisəsinin formatı

Əvvəl MCP aləti üçün minimal loga baxmışdıq. İndi gəlin prod və dashboardlarda istifadə oluna biləcək daha detallı tool_invocation hadisəsini layihələndirək: ideya eynidir, sadəcə servislər, səhvlər və modellərlə əlaqə üçün sahələr əlavə olundu.

Əvvəlcə — TypeScript-də tip:

// telemetry/events.ts
export interface ToolInvocationEvent {
  timestamp: string;
  level: 'info' | 'error';
  event: 'tool_invocation';
  service: 'mcp-giftgenius';
  requestId: string;
  traceId?: string;
  userId?: string;
  tenantId?: string;
  toolName: string;
  modelId?: string;
  tokensIn?: number;
  tokensOut?: number;
  costEstimateUsd?: number;
  latencyMs: number;
  success: boolean;
  errorCode?: string;
}

Və rahat helper:

// telemetry/emitToolInvocation.ts
export function emitToolInvocation(e: ToolInvocationEvent) {
  console.log(JSON.stringify(e));
  // Real həyatda: Logtail/Datadog/ELK və s.-ə göndərərik
}

Hər alətə (məsələn, suggest_gifts, rerank_gifts, fetch_catalog) handler-in sonunda (və ya finally blokunda ki, səhvdə də log olsun) emitToolInvocation çağırışını əlavə edirik.

Alətlərlə bağlı ən sadə dashboard

Dashboard üçün minimal cədvəl (məsələn, Metabase / Grafana / istənilən BI):

tool_name

% trafik

avg_cost_per_call

error_rate

avg_latency_ms

avg_revenue_per_call

Vizual olaraq bu adətən belə görünür: yuxarıda cədvəl, aşağıda isə iki qrafik:

• Bar chart: X‑oxunda tool_name, Y‑oxunda avg_cost_per_call.
• Scatter plot: X = avg_cost_per_call, Y = error_rate və ya conversion_to_checkout.

Belə qrafiklər optimallaşdırma namizədlərini tez tapmağa kömək edir: bahalı, ləng və konversiya vermir — əvvəl ora baxın.

Cost-u revenue ilə bağlamağa kömək edən budur ki, biz checkout_*-ı request_id ilə birlikdə loglayırıq. Beləliklə avg_revenue_per_call-ı, checkout_success baş vermiş ssenarilərdə alət çağırışlarının sayına bölünmüş gəlir cəmi kimi hesablaya bilirik.

8. İnfrastruktur xərclərinin uçotu (fanatizm olmadan)

LLM xərcləri ilə hər şey gözəldir: hər çağırışda tokenlər var, dəyəri birbaşa loqda hesablamaq olar. İnfrastruktur belə asan deyil: sizdə Vercel, bazalar, Redis və s. üçün aylıq hesab var.

Başlanğıcda sadə yolla gedə bilərsiniz:

1. Ay üzrə infrastruktur üçün ümumi hesabı götürürsünüz (məsələn, 200$).
2. Bunu ay üzrə workflow sayına bölürsünüz (workflow_completed) — təxmini infra_cost_per_task alınır.
3. Yaxud aktiv istifadəçi sayına bölün — infra_cost_per_user.

Sonra bu rəqəmlər LLM cost ilə (loglara görə detallı hesablasaq) toplanır — təxmini tam maya dəyəri alınır (ssenari və ya istifadəçi üçün).

Tətbiq böyüyəndə daha incə edə bilərsiniz (xərcləri servislər və alətlər üzrə paylamaq), amma ilk versiyalar üçün bu, kor getməmək üçün tam kifayətdir.

9. GiftGenius üçün kiçik end‑to‑end nümunə

Hər şeyi mini hekayədə yığaq.

İstifadəçi hədiyyə alacaq şəxsi təsvir edir, ChatGPT GiftGenius-u qoşmağı təklif edir. Sonra:

1. Widget "gift_selection" workflow-unu işə salır.
2. Backendiniz hədiyyələri daha ağıllı seçmək üçün LLM agentindən istifadə etmək qərarı verir.
3. Agent 3 addım edir:

• analyze_recipient (LLM ilə təsvirin analizi).
• suggest_gifts (bizim MCP aləti).
• rerank_gifts (siyahını yaxşılaşdırmaq üçün əlavə model).

4. İstifadəçi hədiyyə kartlarını görür, bir neçə ideyanı saxlayır.
5. “Al” düyməsinə basır, ACP və checkout_create_session işə düşür.
6. Uğurlu checkout_success məbləğ 79.00 USD.

Loglarda bizdə nə qalır:

• Üç tool_invocation (hər birinin öz tokens_in/tokens_out, cost_estimate_usd, latencyMs ilə).
• Bir neçə agent_step workflow = "gift_selection", step_name ilə.
• checkout_started və checkout_success amount=7900, currency="USD" ilə.

request_id üzrə bunları bağlayırıq və belə deyə bilirik:

• LLM ssenari xərci: üç alətin cost_estimate_usd cəmi, tutalım 0.19$.
• İnfrastruktur payı (aqreqasiyalardan) bir workflow üçün təxminən 0.03$.
• Yekunda 0.22$ maya dəyəri.
• Transaksiya üzrə gəlir — 79$ minus Stripe komissiyası və s.

Bu artıq konkret unit‑iqtisadiyyatdır, “elə bil ki, GPT‑4 bahadır” yox.

10. Cost-instrumentasiya ilə iş zamanı tipik səhvlər

Səhv №1: yalnız aylıq hesabı hesablamaq və incəlik (granularity) olmaması.
Yalnız OpenAI/buluddan gələn ümumi hesaba baxmaq çox cazibədardır. Amma tool_name, user_id, workflow ilə əlaqə olmadan pulların harada xərcləndiyini bilmirsiniz. Nəticədə optimallaşdırma “modeli kor-koranə ucuzlaşdırma”ya çevrilir, hədəfli şəkildə bahalı ssenariləri yaxşılaşdırmaq əvəzinə.

Səhv №2: cost məlumatlarını struktursuz mətn loglarına yazmaq.
"Tool suggest_gifts used 123 tokens" tipli xəttləri keyfiyyətlə aqreqasiya və filtr etmək mümkün deyil. Bir məqamda JSON-a miqrasiya etmək lazım olduğunu anlayacaqsınız və bu köç ağrılı olacaq. Dərhal request_id, tool_name, tokens_in/tokens_out, cost_estimate_usd sahələri ilə strukturlaşdırılmış loglar yazın.

Səhv №3: cost ↔ commerce hadisələri əlaqəsini görməməzliyə vurmaq.
checkout_success-u request_id olmadan və alət çağırışları ilə əlaqələndirmədən loglamaq — hansı ssenarilərin mənfəət gətirdiyini, hansılarının yalnız token yediyini anlamaqdan könüllü imtina deməkdir. request_id-ni widgetdan ACP-yə qədər bütün yol boyu ötürməyə tənbəllik etməyin.

Səhv №4: praktik qiymətləndirmə əvəzinə “ideal” billing qurmağa çalışmaq.
Bəzi komandalar son tokenə qədər OpenAI billingini mükəmməl təkrarlamağa çalışmaqda ilişib qalırlar. Reallıqda böyüklük dərəcəsi kifayətdir: ssenari 0.02$ və ya 0.021$ dursa, bu prinsipial deyil. Vacib olan odur ki, 2$ deyil. usage ilə təxmini qiymətləndirmələrdən və ya kobud evristikalardan istifadə etməkdən qorxmayın.

Səhv №5: yalnız cost-a baxmaq və keyfiyyəti unutmaq.
Bəzən gözəl qənaət rəqəmlərini görüb hər yerdə ən ucuz mode-lə keçmək istəyirsiniz. Beləliklə tətbiqi istifadəçilərin artıq istifadə etməyəcəyi hala “optimize” etmək olar. Dəyər cavab keyfiyyəti və konversiya ilə birlikdə nəzərdən keçirilməlidir — bu əlaqə eyni modulun növbəti mühazirəsinin mövzusu olacaq — pricing və “dəyər ↔ keyfiyyət” eksperimentləri.