Marketinq və artım, məhsul metriklərinə bağlı

1. Niyə ChatGPT App marketinqi — «səs‑küy» deyil, məhsul analitikasıdır

Klassik vebdə Google Analytics qoşmaq, bütün keçidlərə UTM teqləri asmaq, bir‑iki retargeting pikseli yerləşdirmək olar — və nəsə alınar. ChatGPT ekosistemində hər şey fərqlidir. İstifadəçi ChatGPT interfeysindədir, sizin App isə bu dialoqda «qonaq»dır. Cookies, iframe və Facebook Pixel burada işləmir.

Bu, məhsul hadisələrini avtomatik olaraq böyümə haqqında əsas (və çox vaxt yeganə) həqiqət mənbəyinə çevirir. App nə qədər tez‑tez açılır? Açar ssenariyə çatırlar? Qayıdırlar? Bu, gəlirlə necə əlaqəlidir? Bu suallara xarici sayğac yox, sizin MCP‑hadisələriniz və server analitikanız cavab verir.

Burada çox məntiqli şəkildə product‑led growth (PLG) termini ortaya çıxır: artım aldığınız bannerlərin sayından yox, məhsulun istifadəçi ssenarisini nə dərəcədə yaxşı həll etməsindən və onu məlumatlara əsaslanaraq necə inkişaf etdirdiyinizdən asılıdır.

Ona görə də bu mühazirənin əsas qəhrəmanı — GiftGenius daxilindəki hadisə hunisidir, yoxsa xarici marketinq kanalı deyil. Kanallar olacaq, amma yalnız bu hadisələrə təsir edən hipotezlər kimi.

GiftGenius üçün AARRR: öz «pirat hunisi»

AARRR (Acquisition, Activation, Retention, Revenue, Referral) modeli ChatGPT App‑ə əla oturur, sadəcə onu tətbiqimizin hadisə dili ilə ifadə etmək lazımdır.

GiftGenius üçün onu belə təsvir etmək olar:

app_opened

workflow_completed (ilk dəfə)

təkrar workflow_completed / app_opened

checkout_started, checkout_success

referral_sent, referral_activated (opsional)

Vacibdir ki, bu huni frontend klikləri ilə yox, məhz MCP/App səviyyəsində «istifadə hadisələri» ilə təsvir olunur: istifadəçi açdı, ssenarini keçdi, aldı, qayıtdı. Vebdən fərqli olaraq, bəzən «hər siçan hərəkətini» izlədiyiniz yerdə burada analitika kompakt və mənalı olmalıdır: «hara kliklədi»dən çox «ssenaridə nə etdi».

GiftGenius‑un baza versiyası üçün ilk növbədə dörd səviyyəyə fokuslanırıq (Acquisition, Activation, Retention, Revenue). Referral vacib qalır, amma daha çox növbəti inkişaf mərhələsidir; onu məhsulun nüvəsi və ödənişlər sabitləşəndə qoşmaq olar.

2. Hadisə modelini layihələndiririk: loqlardan analitikaya

Observability modulu haqqında artıq qərara gəlmişdik ki, sərbəst formada «roman‑loqlar» yox, strukturlu JSON‑loqlar yazırıq. İndi onların üzərində məhsulun hadisə modelini qururuq.

Minimal ideya: App‑də hər vacib addım hadisə obyektini yaradır. MCP tərəfində onu həm loqa yaza, həm də xarici analitik sistemə (BI, ClickHouse, BigQuery — nə istəsəniz) göndərə bilərsiniz.

GiftGenius üçün hadisələrin ən sadə tərifi belə görünə bilər:

// Hadisənin ümumi forması
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-dan, əgər varsa
  sessionId: string;        // ChatGPT-də sessiyanın UUID-i
  timestamp: string;        // ISO formatlı sətir
  properties?: Record<string, unknown>;
}

Ayrıca, tətbiqin Next.js hissəsindən hadisələri göndərmək üçün kiçik bir helper saxlamaq rahatdır:

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

Serverdə /api/analytics artıq qərar verə bilərsiniz ki, bunlarla nə edəsiniz: bazaya yazmaq, loqgerə göndərmək və ya data‑pipeline‑a axınlatmaq. Əsas odur ki, bütün hadisələr vahid formatda olsun. Praktikada sizdə eyni məhsul hadisələri dəsti olacaq, amma onların yaranmasının bir neçə nöqtəsi: bəzi addımları MCP serverində birbaşa logger.info ilə fiksələmək rahatdır, bəzilərini isə vidjetdən AnalyticsEvent kimi /api/analytics‑ə göndərmək. Vacib olan «boruların» sayı deyil, hadisə tiplərinin ("app_opened", "workflow_completed" və s.) və onların sahələrinin vahid və uzlaşmış qalmasıdır.

3. Acquisition: istifadəçilərin haradan gəldiyini necə anlamaq

Marketinqin ilk vəzifəsi — kimlərin bizə gəldiyi və sayları barədə cavab verməkdir. ChatGPT App‑də bu «gəliş» çatda App‑in işə salınması ilə fiksələnir. Loqlaşdırmaq istədiyimiz hadisə "app_opened" adlanır.

GiftGenius üçün bunu həm vidjet tərəfində (komponent mount olduqda reaksiya verərək), həm də serverdə (məsələn, sessiyada ilk callTool zamanı) etmək olar. Render xüsusiyyətlərindən asılı olmamaq üçün serverdə etmək daha etibarlıdır, amma sadəlik üçün frontu nəzərdən keçirək.

İlk renderdə trackEvent çağırışı ilə GiftGenius vidjet komponentinin nümunəsi:

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>
      {/* ...vidjetin əsas UI-si... */}
    </main>
  );
}

Praktikada siz sessionId və userId‑ni artıq mövcud kontekstdən (məsələn, _meta və ya avtorizasiya tokenindən) almaq istərsiniz, onları müştəridə generasiya etmək yox. Amma məğz odur ki, GiftGenius‑un hər işə salınması belə bir hadisə yaratmalıdır.

Trafik mənbələri problemi vebdən daha çətindir: referer və UTM teqləri məhduddur. Adətən iki strategiyadan biri istifadə olunur. Birincisi — əsas trafik mənbəyinin Store olduğunu qəbul etmək və yalnız "app_opened" üzrə zamanla analiz etmək: yeni Store‑listinqini buraxmısınızsa, "app_opened" sıçrayışına və huninin növbəti səviyyələrinə baxın. İkincisi — açıq parametrlərdən istifadə etmək: istifadəçiyə https://chat.openai.com/...&utm_source=blog2025 kimi keçid verdiyiniz halda, ilk "app_opened" zamanı bu teqi kontekstdən götürüb referral_source sahəsinə qoya bilərsiniz.

Yəni acquisition metrikləri təxminən belə görünür: «gün üzrə "app_opened" sayı», «həftə ərzində App‑i işə salan unikal userId sayı», «əgər varsa, referral_source üzrə bölgü».

4. Activation: GiftGenius daxilində «aha anı»nı tapırıq

Acquisition özü‑özlüyündə heç nə demir, əgər insanlar dərhal App‑i bağlayırlarsa. Ona görə ikinci əsas qat — Activation‑dır. Bu, istifadəçi ilk dəfə App‑in həqiqətən faydalı bir şey etdiyini hiss etdiyi andır.

GiftGenius üçün belə anı workflow‑un tamamlanması ilə bağlamaq məntiqlidir: istifadəçi hədiyyə alan barədə məlumat daxil edir, filtrləri qurur və App ona, məsələn, 10 müvafiq ideya göstərir. Dəyər ilk dəfə məhz burada görünür.

Bunu "workflow_completed" hadisəsi ilə fiksələmək rahatdır. Bu addımı MCP serverində loqlaşdırmaq daha düzgün olar — artıq bütün hədiyyələri toplayıb nəticəni vidjetə göndərdiyiniz zaman:

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

Burada logger — SLO və cost‑instrumentasiya üçün əvvəlcədən əlavə etdiyiniz strukturlu loqgerinizdir. Sadəcə içina məhsul hadisəsini də əlavə etdik.

Məhz "workflow_completed" üzrə activation‑rate‑i hesablayacaqsınız: activation_rate = (ən azı bir "workflow_completed" olan unikal userId‑lərin sayı) / (period ərzində "app_opened" olan unikal userId‑lərin sayı).

Daha kobud baxış da mümkündür: «sessionId sesiyalarının hansı hissəsində "workflow_completed" var idi». Vacib olan odur ki, bu, sizin üçün tanış metrika olsun: activation nə qədər yüksəkdirsə, App‑in startı bir o qədər yaxşıdır.

5. Retention: istifadəçilər App‑inizə qayıdırmı

ChatGPT App üçün retention klasik veb məhsulundan bir qədər mürəkkəbdir. Bir tərəfdən, ChatGPT özü elə bir məkandır ki, insan onsuz da ora qayıdır. O biri tərəfdən — o, sizin App‑ə yox, başqa çoxlu App‑lərə qayıda bilər. Bizim üçün vacib olan, onun məhz GiftGenius‑a qayıdıb‑qayıtmamasıdır.

Autentifikasiya olduqda (modul 10) sizdə stabil userId və ya tenantId var. Bu halda klassik tərif sadədir: istifadəçi «udulan» (retained) sayılırsa, məsələn, ilk "workflow_completed"‑dən 7 gün sonra onda yeni "workflow_completed" və ya heç olmasa "app_opened" var.

Əgər auth yoxdursa, sessionId və evristik userKey (məsələn, əgər _meta daxilində əlçatandırsa, OpenAI hesabının hash‑ı) əsasında daha zəif metrikadan istifadə etmək olar, amma mühazirədə userId‑nin bizdə olduğunu qəbul edəcəyik.

SQL‑ə bənzər məntiqdə bu təxminən belə görünür (psevdo‑kod):

-- ilk aktivasiya
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;

Prodakşnda belə SQL «gözəlliyi» yazmaq vacib deyil, amma ideyanı başa düşmək lazımdır: retention — insanların App‑i yenidən istifadə etməyə qayıdıb‑qayıtmaması haqqındadır, təkcə bir dəfə ödənişə çatıb‑çatmadıqları yox.

6. Revenue: hunini pulla bağlayırıq

GiftGenius üçün revenue qatı ümumən niyə bunu etdiyimizi möhkəmləndirir. Commerce modulunda artıq ödəniş ətrafında hadisələr əlavə etdik: "checkout_started", "checkout_success", "checkout_failed". Eyni hadisələr gəlir metriklərinin açarıdır: konversiyalar və orta çek.

İstifadəçi «Hədiyyə al» düyməsini basanda və siz checkout sessiyası yaradırsınız (ACP/Stripe vasitəsilə), MCP tərəfində hadisəni loqlaşdırmağa dəyər:

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

PSP‑dən uğurlu webhook gələndə:

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

İndi konversiyanı asanlıqla hesablaya bilərsiniz:

• «"workflow_completed" → "checkout_started"» — insanlar ümumiyyətlə nə qədər tez‑tez ödənişə gedirlər;
• «"checkout_started" → "checkout_success"» — commerce axınınız nə dərəcədə yaxşı işləyir (kart xətaları, fırıldaqçılıq, ödəniş UX‑i).

Eyni zamanda bu hadisələr əvvəlki dərsdə xərclərə nəzarət və cost‑instrumentasiya haqqında loqlarla birləşir: requestId və ya sessionId üzrə bu alışa qədər hansı alət çağırışlarının nə qədər token/pul tutduğunu bilirsiniz. Bu, «orta cost_per_paid_workflow» və «bir uğurlu sifariş üçün gəlir‑minus‑öz maya dəyəri» kimi metriklər verir.

7. Referral: istifadəçilər başqalarını gətirəndə

ChatGPT App‑də referral qatı bir az qeyri‑adi görünür. Öz push və ya bülletenləriniz yoxdur, amma istifadəçilərin çatları, keçidləri paylaşmaq və bir‑birinə «Store‑da GiftGenius axtar» demək imkanı var.

Texniki olaraq, əgər:

• istifadəçilərə App‑ə keçiddə referral kodu və ya parametr (?ref=friend123) verirsinizsə,
• və ya "app_opened" kontekstində referral_source/campaign emal edirsinizsə,

o zaman "referral_sent" və "referral_activated" hadisələrini daxil edə bilərsiniz.

Baza MVP variantında GiftGenius üçün Referral‑ı gələcəyə saxlamaq olar — əvvəlcə Acquisition/Activation/Revenue‑nu düzəltmək və huninin nüvəsinin işlədiyinə əmin olmaq vacibdir. Amma eyni zamanda onu hara «birləşdirmək» lazım olduğunu anlamaq önəmlidir: ayrı promokod Excel‑i ilə yox, elə həmin hadisə loqları və metriklərlə.

GiftGenius üçün vizual huni

Ümumi mənzərəni yadda saxlamaq üçün kiçik bir diaqram çəkmək faydalıdır:

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

Buradakı hər bir kənar — ölçülə bilən bir konversiyadır. Marketinq, UX dəyişiklikləri, modellərlə eksperimentlər — sonda bunların hamısı bu konversiyalardan birini və ya bir neçəsini yüksəltməlidir. Nəsə edirsinizsə və hansı kənarın yaxşılaşmalı olduğunu deyə bilmirsinizsə, bu, şübhəlidir.

Böyümə daşbordları: ilkin olaraq hansı hesabatlar lazımdır

Gəlin GiftGenius üçün minimal böyümə daşbordunu təsəvvür edək. Burada kosmik BI sistemi qurmuruq, ən azı hər həftə baxa biləcəyimiz bir cədvəl istəyirik.

Günlər üzrə aqreqasiya olunmuş hesabat nümunəsi:

Dərhal görünür ki, 3‑də acquisition‑u «artırmışıq» ("app_opened" böyüyüb), amma activation və konversiya düşüb — ola bilər ki, uyğun olmayan trafik gəlib və ya UX‑də nəyisə sındırmısınız. Məhz belə cədvəllər yaxşı marketinqi sadəcə səs‑küy yaradan marketinqdən ayırmağa kömək edir.

Zamana əlavə olaraq koqortalara baxmaq da faydalıdır: müəyyən həftədə gələn istifadəçilər və onların 7/30 gün üzrə retention‑u. Amma başlanğıc üçün gün və həftə kəsimlərində sadə kəsikləri qurmağı bacarmaq kifayətdir.

8. Marketinq: hadisələr üzərində silsilə eksperimentlər kimi

İndi ən «marketinq» məqamına keçirik: xarici aktivlikləri (məqalələr, Store listinqi, tərəfdaşlıqlar) App daxilində gördüklərimizlə necə bağlamaq olar.

Açar prinsip: istənilən marketinq ideyası hansı məhsul metriklərinin dəyişməli olduğu barədə hipoteza kimi formalaşdırılır.

Məsələn, GiftGenius üçün:

• «Əgər Store listinqini (ikonlar, təsvir, demo‑video) yaxşılaşdırsak, yeni istifadəçilərdən gələn "app_opened" sayı və ideal olaraq onların arasında activation‑rate artmalıdır».
• «Əgər Yeni il üçün hədiyyə seçimi barədə məqalə yazsaq və ora GiftGenius‑a keçid versək, yaxın 3 gündə "app_opened" referral_source‑u = "blog_ny2025" olanlarda artmalı və daha sonra bu koqortada "workflow_completed" böyüməlidir».

Texniki olaraq bu, tez‑tez campaign və ya referral_source üçün əlavə sahə ilə "app_opened" hadisəsində reallaşdırılır. Məsələn, App işə düşərkən ChatGPT kontekstindən hər hansı bir teq almısınızsa:

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

İndi «kampaniyalar üzrə» hesabatlar qura bilərsiniz: "app_opened" və "workflow_completed" nə qədərdir və referral_source = "blog_ny2025" olanlarda bu göstəricilər orqanikadan necə fərqlənir.

Vacibdir ki, marketinqi yalnız «əhatələr»lə uğurlu saymırıq. Bloqer deyirsə ki, videosunu bir milyon adam izləyib — əladır, amma GiftGenius üçün uğur «bizdə daxildə "app_opened" və "workflow_completed" artımı»dır.

9. Nümunə: GiftGenius üçün marketinq eksperimenti

Hamısını bir konkret ssenaridə toplayaq və eyni zamanda xarici kampaniyanı GiftGenius daxilindəki məhsul hadisələrinə səliqəli şəkildə bağlayaq.

Tutaq ki, belə bir hipotezanı yoxlamaq istəyirsiniz: hədiyyələr haqqında populyar bir bloqdakı məqalə «düzgün» istifadəçiləri gətirəcək. Məqalədə keçidi birbaşa ChatGPT‑yə yox, öz landing səhifənizə verirsiniz, məsələn:

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

İstifadəçi GiftGenius haqqında qısa təsviri olan landing səhifəsinə düşür və «ChatGPT‑də aç» düyməsinə basır. Landing‑in backend tərəfində siz utm_source oxuyursunuz və onu istifadəçi profilində (və ya ayrıca cədvəldə) saxlayırsınız, məsələn acquisitionSource = "giftblog2025" kimi. Landingdəki düymə artıq sizi Store‑dakı ChatGPT App‑inizə aparır, sonra istifadəçi App‑i qoşur və istifadə etməyə başlayır.

Bu istifadəçi ChatGPT‑də GiftGenius‑u işə salanda və backend‑iniz Apps SDK / MCP‑dən ilk çağırışı alanda, saxlanmış acquisitionSource‑u götürür və onu məhsul hadisələrinə əlavə edirsiniz. "app_opened" üçün bu, belə görünə bilər:

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

Eyni qaydada "workflow_completed", "checkout_started", "checkout_success" hadisələrini də işarələyirsiniz. Sonra eksperiment koqortaların müqayisəsinə çevrilir: referral_source = "giftblog2025" olan istifadəçilər və orqanika. Əgər «bloq» koqortasında tamamlanmış ssenarilərin və ödənişlərin payı, istifadəçi başına gəlir oxşar və ya daha yaxşı olarkən, daha yüksəkdirsə, kampaniyanı uğurlu saymaq olar; əgər yalnız tətbiq işə salmaları artır, amma "workflow_completed" və "checkout_success" konversiyası düşürsə, deməli, məqalə əsasən maraqlananları, yox alıcıları gətirir.

Bu yanaşma ona görə yaxşıdır ki, UTM teqini bir dəfə səliqəli şəkildə veb dünyasından daxili referral_source sahənizə «çevirirsiniz» və sonra yalnız App‑in məhsul analitikası ilə işləyirsiniz — sehirsiz və URL parametrlərini birbaşa ChatGPT‑yə «itələməyə» cəhd etmədən.

Eyni zamanda, əgər haradasa CAC‑ı (neçə başa gəldiyini) və cost_per_task‑ı qeydə alırsınızsa, maya dəyərinə də baxa bilərsiniz. Onda hipoteza artıq daha «maliyyə» eksperimentinə çevrilir: «Bu kanal özünü doğruldurmu?».

10. Privacy‑first analitika: qaydaları və sağlam məntiqi pozmadan

Ayrı bir vacib məqam — heç olmasa bir az Facebook‑a çevrilməmək. Klassik vebdən fərqli olaraq, OpenAI ChatGPT Apps‑də məxfiliyə olduqca sərt yanaşır: şəxsi məlumatları izləmək, artıq PII toplamaq və dialoqların tam mətnini hər yerə göndərmək olmaz.

GiftGenius üçün yaxşı analitika praktikası belə görünür:

1. Hadisələrdə istifadəçinin mesaj mətnini saxlamayın. Onun əvəzinə yalnız «ssenarinin faktlarını» loqlaşdırın: ssenarinin növü, göstərilən ideyaların sayı, uğurlu ödəniş faktı.
2. İstifadəçiləri fərqləndirmək lazımdırsa, email/ad yox, psevdonimləşdirilmiş identifikatorlardan (userId, tenantId) istifadə edin. İstənilən PII autentifikasiya olan bazada saxlanılır, analitika isə anonim açarlarla işləyir.
3. İş üçün lazım olmadıqca insanı birbaşa identifikasiya edən sahələrdən loqlarda və hadisələrdə qaçın (məsələn, çatdırılma ünvanının tam mətni hadisə üçün aydın şəkildə lazım deyil; onun yeri commerce‑in qorunan bazasıdır).
4. Maksimum dərəcədə aqreqasiya olunmuş analitikadan istifadə edin: sizi yüzlərlə istifadəçi üzrə activation‑rate və retention maraqlandırır, yoxsa adam‑adam siyahı yox.

Və yadda saxlayaq ki, artıq audit & lifecycle haqqında modulumuz var idi: istifadəçi öz məlumatlarının silinməsini istəyirsə, retention üzrə məntiq bunu nəzərə almalıdır. Amma bu, daha çox 15‑ci modul barəsindədir; burada sadəcə xatırlamaq vacibdir ki, analitika hər cür «lazımsız məlumatı» toplamağa indulgensiya vermir.

11. cost‑instrumentasiya və SLO ilə əlaqə: hər şeyi hesablayan marketinq

Texniki nöqteyi‑nəzərdən ideal şəkil belədir: sizdə strukturlu hadisələrin vahid axını var və hər bir istifadəçi sessiyası üçün uyğunlaşdırılıb:

• məhsul hadisələri ("app_opened", "workflow_completed", "checkout_success");
• cost məlumatları (tokenlər, cost_estimate, alətlər üzrə duration_ms);
• SLO metrikləri (MCP/alətlər üzrə gecikmə və səhvlər, əlçatanlıq).

Onda istənilən marketinq və məhsul qərarları demək olar ki, avtomatik olaraq həqiqətən verilər‑əsaslı olur. Suala bilərsiniz:

• «Kampaniya X‑dən gələn istifadəçilərdə activation_rate nədir və onların uğurlu workflow‑unun orta dəyəri nə qədərdir?»
• «Store‑dan gələn trafik artdıqca error_rate və ya p95 latency böyümür ki?»
• «Əvvəlki dərsdə «dəyər ↔ keyfiyyət» eksperimentində modeli ucuzlaşdırdıqsa, "checkout_success" konversiyası düşməyib ki və istifadəçi başına revenue azalmayıb ki?»

Və bunların heç biri yeni sistemlər uydurmağı tələb etmir — sadəcə əvvəlcədən tətbiq etdiyiniz eyni loqlardan və cost alətlərindən istifadə edirsiniz.

Nəticədə ChatGPT App marketinqi təkcə trafikin özü haqqında deyil, tətbiqiniz daxilində konkret məhsul metriklərinin yaxşılaşdırılması haqqındadır. Açar ssenari addımlarını loqlaşdırın ("app_opened", "workflow_completed", "checkout_success"), onları cost‑instrumentasiya və SLO ilə bağlayın və marketinq aktivliklərini huninin hansı həlqəsini yaxşılaşdırmaq istədiyiniz barədə hipotezlər kimi formalaşdırın. Bu hunini və məxfilik məhdudiyyətlərini yadda saxlayırsınızsa, məhsul və böyümə üzrə qərarlar demək olar ki, avtomatik olaraq daha məntiqli və dayanıqlı olur.

12. Məhsul metrikləri və marketinqlə işləyərkən tipik səhvlər

Səhv №1: trafikin xatirinə marketinq, aktivləşmənin deyil.
Komandalar tez‑tez hansısa məqalə və ya tvitdən sonra "app_opened"in kəskin artımına sevinirlər və activation və konversiyaya baxmadan eksperimenti uğurlu sayırlar. Nəticədə «turistlər» çoxalır, yük və cost artır, amma nə pul gəlir, nə də real istifadəçilər yaranır. Düzgün yanaşma — həmişə huninin ilk addımından sonrasına baxmaqdır: gələnlərin nə qədəri "workflow_completed" və "checkout_success"‑a çatdı.

Səhv №2: vahid user identifikatorunun olmaması.
Bəzən App hadisələri loqlaşdırmağa başlayır, amma stabil userId və ya heç olmasa tenantId olmadan. Bu rejimdə yalnız «gün üzrə hadisələrin sayı» kimi nəsə saya bilərsiniz, amma nə retention, nə də cost_per_user alınar. Sonradan düzgün user‑tracking əlavə etmək çətin olur, xüsusilə artıq ciddi məxfilik məhdudiyyətləri varsa. Daha yaxşısı — identifikasiya sxemini autentifikasiya mərhələsində (modul 10) düşünmək və onu bütün hadisələrdə istifadə etməkdir.

Səhv №3: açar hadisələr əvəzinə «hər xırda şeyi» izləmək.
Event analitikaya ilk reaksiya — hər şeyi loqlaşdırmağa başlamaqdır: siçan hover‑i, hər input focus‑u, hər rerender. ChatGPT kontekstində bu xüsusilə zərərlidir: belə hadisələr istifadə modelinə zəif uyğun gəlir, tonlarla səs‑küy yaradır və məxfilik risklərini artırır. Daha faydalısı ssenarinin bir neçə açar hadisəsi ilə məhdudlaşmaq və onları keyfiyyətlə analiz etməkdir.

Səhv №4: atribusiyasız marketinq kampaniyaları.
Yayılmış nümunə: komanda kampaniya (məqalə, video, tərəfdaşlıq) buraxır, amma gələn trafiki heç cür işarələmir və sonra «işlədi, ya yox» deyə təxmin edir. Nəticədə metriklərdə bütün dəyişikliklər bulanıq qalır. Daha yaxşısı referral_source və ya campaign kimi açıq sahələrdən "app_opened" hadisələrində istifadə etməkdir — hətta bunu sadə UTM‑bənzər parametrlərlə etsəniz belə — və sonra bu koqortaları orqanika ilə müqayisə etməkdir.

Səhv №5: «tam analitika» naminə privacy məhdudiyyətlərini görməzdən gəlmək.
Bəzən detalları qovmaq eşqi ilə hadisələrə sorğuların mətni, hədiyyə alıcısının şəxsi məlumatları, ünvan və digər PII yazmağa başlayırlar. Bu, dərhal iki cəhətdən təhlükəlidir: OpenAI/Store siyasətləri baxımından və real hüquqi risk (GDPR, CCPA və s.) baxımından. Düzgün analitika ssenarinin aqreqasiya edilmiş əlamətləri və anonim identifikatorlar üzərində qurulur, «birdən lazım olar» deyə bütün söhbəti saxlamaq üzərində yox.

Səhv №6: keyfiyyət və böyüməni nəzərə almadan yalnız cost üzrə optimizasiya.
Cost barədə dərsdən sonra «yığım rejimi»nə həddindən artıq getmək asandır — tokenləri hər nə bahasına ucuzlaşdırmağa çalışırsınız. Əgər bunun fonunda activation‑rate, retention və "checkout_success" düşürsə, bu «qənaət» saxtadır: sadəcə məhsulun dəyərini öldürürsünüz. Həmişə «cost ↔ keyfiyyət ↔ böyümə» üçbucağını yadda saxlayın: promptlarda, modellərdə və UX‑də istənilən dəyişiklikləri həm maya dəyəri, həm də məhsul metrikləri prizmasından qiymətləndirmək lazımdır.