Mobil tətbiq analitikasının düzgün implementasiyası istifadəçi davranışını mümkün qədər çox event ilə izləmək deyil; məhsul qərarını dəstəkləyən davranışları aydın, ardıcıl və yoxlanıla bilən şəkildə ölçməkdir. Komanda “istifadəçilər harada prosesi yarımçıq qoyur?” sualını verirsə, analitika spesifikasiyası həmin sualı funnel addımlarına, event-lərə, property-lərə və qəbul qaydalarına çevirməlidir.

Bu iş sonradan əlavə edilən analitika SDK-sı kimi yox, məhsul dizaynı, mobil mühəndislik, backend və buraxılış prosesinin bir hissəsi kimi planlanmalıdır. Əks halda eyni davranış checkout_started, start_checkout və ya sadəcə button_clicked kimi fərqli adlarla daxil olur; dashboard isə dəqiq görünən, amma yanlış nəticə verir.

Əvvəl event-ləri deyil, məhsul suallarını yazın

Tracking plan-ın başlanğıc nöqtəsi ekran siyahısı və ya SDK sənədi deyil. Əvvəl məhsul, marketinq, əməliyyat və dəstək komandalarının hansı qərarları verməli olduğunu müəyyənləşdirin. Hər sual üçün qərarın sahibi, ölçmə vahidi və lazım olan segment də yazılmalıdır.

  • Yeni istifadəçi ilk dəyərli nəticəyə nə qədər tez çatır?
  • Qeydiyyatın hansı addımında və hansı səbəbdən tərk etmə baş verir?
  • Ödəniş cəhdi, uğurlu ödəniş və sifarişin təsdiqlənməsi arasındakı fərq nədir?
  • Push bildirişindən gələn istifadəçi hansı flow-u tamamlayır?
  • Yeni tətbiq versiyası aktivləşməyə, xətalara və ya retention-a mənfi təsir edibmi?

“Hər düymə klikini izləyək” yaxşı spesifikasiya deyil. Məsələn, checkout drop-off sualı üçün klik event-ləri yox, biznes baxımından mənalı vəziyyət dəyişiklikləri lazımdır: checkout_started, delivery_option_selected, payment_submitted, payment_authorized və order_confirmed. Son event yalnız backend sifarişi uğurla yaratdıqda göndərilməlidir; istifadəçinin “Ödə” düyməsinə toxunması sifarişin baş tutması demək deyil.

Event taxonomy-ni idarə olunan spesifikasiya kimi qurun

Product analytics event taxonomy hər event-in biznes mənasını, texniki mənbəyini və gözlənilən datasını izah edən vahid sənəddir. Bu sənəd dizayner, məhsul meneceri, iOS/Android mühəndisi, backend mühəndisi, analitik və QA üçün eyni istinaddır.

Hər event sətrində ən azı bunlar olmalıdır:

  • event adı və insan üçün qısa izahı;
  • nə vaxt baş verdiyi və nə vaxt baş vermədiyi;
  • mənbə: client, server və ya hər ikisi;
  • məcburi və opsional event property-lər, tip və icazəli dəyərlər;
  • istifadəçi, biznes və cihaz konteksti;
  • məsul şəxs, status və tətbiq versiyası;
  • event-in istifadə olunduğu funnel, metric və dashboard.

Adlandırma qaydaları: sadə, sabit və fəaliyyət yönümlü

Bir yazı formatını seçin və bütün platformalarda qoruyun. Məsələn, event-lər üçün snake_case, property-lər üçün də snake_case istifadə edin. Event adı adətən obyekt və tamamlanmış hərəkəti bildirməlidir: sign_up_completed, profile_saved, subscription_cancelled.

button_clicked, screen_opened kimi ümumi event-lər yalnız konkret məqsədlə və property konteksti ilə faydalıdır. Onları əsas biznes nəticəsi kimi istifadə etməyin. Həmçinin eyni anlayışı fərqli yazmayın: plan_type, planType və subscription_plan sonradan eyni segmentin üç yerə bölünməsinə səbəb olur.

Event, user və business property-lərini qarışdırmayın

Event property yalnız həmin əməliyyatın kontekstidir. Məsələn, payment_submitted event-i üçün payment_method, currency, amount_bucket, attempt_number və checkout_version məntiqli ola bilər. İstifadəçinin cari abunə planı isə user property-dir; çünki gələcək davranışları seqmentləşdirmək üçün istifadə olunur və zamanla dəyişə bilər.

Biznes entity-ləri üçün sabit, texniki identifikatorlardan istifadə edin: order_id, workspace_id, merchant_id. Email, telefon nömrəsi, tam ad, kart məlumatı, sərbəst mətn və ya həssas sənəd məzmununu analitika event-inə göndərməyin. Analitik vendor, data warehouse və hüquqi tələblərdən asılı olaraq, şəxsi məlumatların minimallaşdırılması məhsulun data siyasətinin bir hissəsi olmalıdır.

Hər property üçün tip və dəyər siyahısı göstərin. payment_method yalnız card, apple_pay, cash kimi nəzarət olunan enum dəyərləri qəbul edirsə, dashboard-da Card, card_payment və boş sətirlər yaranmaz. Pul məbləği üçün numeric tip, boolean vəziyyət üçün boolean tip, zaman üçün ISO formatı və ya vahid timestamp qaydası təyin edin.

İdentifikasiya və consent: funnel-lərin gizli asılılıqları

İstifadəçi ilk açılışda anonim ola, sonra qeydiyyatdan keçə və başqa cihazdan daxil ola bilər. Buna görə implementasiya anonim cihaz və ya sessiya identifikatorunun autentifikasiya olunmuş user_id ilə nə vaxt bağlanacağını açıq yazmalıdır. Login, logout, hesab dəyişməsi və hesab silinməsi halları ayrıca sınaqdan keçirilməlidir. Əks halda bir nəfər iki istifadəçi kimi, yaxud iki nəfər bir profil kimi görünə bilər.

Analitika razılıqdan ayrılıqda düşünülməməlidir. Tracking plan hansı kateqoriya məlumatın zəruri məhsul ölçümü, hansı kateqoriyanın isə analitika və ya marketinq üçün optional olduğunu göstərməlidir. Razılıq verilməzdən əvvəl hansı SDK-ların işə düşdüyünü, razılıq geri götürüldükdə hansı collection-un dayandığını və silinmə sorğularının necə idarə olunduğunu məhsulun hüquqi və məxfilik tələblərinə uyğunlaşdırın. Region, platforma və tətbiqin data axınından asılı qaydaları hüquq və privacy sahibləri təsdiqləməlidir.

Funnel tərifini dashboard-dan əvvəl sabitləyin

App funnel tracking implementation zamanı “checkout conversion” kimi ifadə yetərli deyil. Funnel specification aşağıdakı suallara yazılı cavab verməlidir:

  1. Başlanğıc event hansıdır və istifadəçi hansı anda funnel-ə daxil sayılır?
  2. Addımlar hansı sırada və hansı maksimum zaman pəncərəsində baş verməlidir?
  3. Hansı event uğurlu tamamlanma sayılır?
  4. Təkrar cəhdlər necə hesablanır?
  5. İstifadəçi offline olduqda event nə vaxt göndərilir?
  6. Cancelled, declined və technical_error hansı fərqli nəticələrdir?

Məsələn, ödəniş funnel-i üçün payment_submitted ilə payment_authorized fərqli mərhələlərdir. Bank imtinası, istifadəçinin geri qayıtması və şəbəkə timeout-u eyni “failed” səbəbi altında birləşdirilərsə, komanda yanlış problemi optimallaşdıracaq. failure_reason property-si yalnız əvvəlcədən təyin olunmuş dəyərləri qəbul etməlidir.

Client event-lərini server həqiqəti ilə uyğunlaşdırın

İstifadəçinin gördüyü UX addımlarını mobil client izləyə bilər. Lakin sifarişin yaranması, ödənişin təsdiqi, abunəliyin aktivləşməsi və referral bonusunun verilməsi kimi kritik nəticələr mümkün olduqda backend-dən gələn authoritative event ilə ölçülməlidir. Bu yanaşma tətbiqin bağlanması, retry, şəbəkə itməsi və manipulyasiya səbəbindən yaranan saxta uğurları azaldır.

Client və server eyni biznes hadisəsini göndərirsə, deduplication qaydası qurun. Məsələn, order_id və ya ayrıca event_id hər iki mənbədə eyni olmalıdır. Əks halda uğurlu sifarişlər iki dəfə sayılar. Mobil tətbiqin offline davranışı varsa, event-in başvermə vaxtı ilə serverə çatma vaxtını ayırın; gecikmiş upload retention və funnel analizini poza bilər.

Mobile analytics QA buraxılışın qəbul kriteriyası olmalıdır

Tracking plan yazmaq kifayət deyil. Hər release üçün QA aşağıdakı yoxlamaları etməlidir:

  • Event yalnız nəzərdə tutulan anda bir dəfə göndərilir.
  • Ad, property açarları, data tipləri və enum dəyərləri spesifikasiyaya uyğundur.
  • Məcburi property boş deyil; optional property isə səhv placeholder daşımır.
  • Login, logout, reinstall, account switch, offline retry və deep link ssenarilərində identity doğrudur.
  • iOS və Android event-ləri eyni semantikanı daşıyır.
  • Staging və production datası ayrıdır; test istifadəçiləri production KPI-larını çirkləndirmir.
  • Yeni app versiyası, feature flag və experiment variantı event kontekstində görünür.

QA yalnız analitika alətinin live event pəncərəsinə baxmaqla bitməməlidir. Ssenarini cihazda icra edin, xam event payload-u yoxlayın, backend nəticəsi ilə müqayisə edin və sonra dashboard metric-inin gözlənilən nəticəni verdiyini təsdiqləyin. Kritik flow-lar üçün avtomatlaşdırılmış contract test və release smoke test-ləri dəyərlidir.

Versiyalaşdırın, köhnə datasını səssizcə dəyişməyin

Event semantikası dəyişirsə, sadəcə property adını yenidən istifadə etməyin. Məsələn, subscription_started əvvəl trial başlanmasını, sonra isə yalnız pullu aktivləşməni ifadə edirsə, zaman seriyası müqayisə edilə bilməz. Ya yeni event yaradın, ya da schema_version və dəqiq keçid tarixi ilə fərqi sənədləşdirin. Köhnə event-ləri deprecate edin, owner təyin edin və dashboard-ları yeni tərifə köçürün.

Dashboard-lar da idarə olunan məhsul artefaktıdır. Hər dashboard-da metric tərifi, mənbə event-ləri, filtr və istisnalar görünməlidir. Vanity metric-ləri deyil, qərar tələb edən görünüşləri prioritetləşdirin: activation cohort-ları, onboarding addımları, payment failure reason-ları, release üzrə crash və conversion fərqi. Kifayət qədər həcm və kontekst olmadan kiçik faiz dəyişikliklərini məhsul nəticəsi kimi təqdim etməyin.

Implementasiya üçün praktik başlanğıc planı

  1. Ən vacib 5–10 məhsul sualını və qərar sahibini yazın.
  2. Hər sual üçün metric, funnel, segment və authoritative data mənbəyini seçin.
  3. Event/property lüğəti, naming rule və PII qadağalarını təsdiqləyin.
  4. UX flow-ları ilə tracking plan-ı birlikdə nəzərdən keçirin.
  5. Client, backend və data komandaları üçün implementasiya tapşırıqlarını ayırın.
  6. Staging-də payload, identity və funnel test-ləri aparın.
  7. Release-dən sonra gözlənilməyən event-ləri, boş property-ləri və dashboard uyğunsuzluğunu izləyin.

POLADO-da mobil tətbiqlərin hazırlanması işini UX flow-ları, backend nəticələri, release və ölçmə tələbləri ilə birlikdə planlayırıq. Mövcud tətbiqdə data keyfiyyəti və ya onboarding drop-off problemi varsa, UI/UX və məhsul dizaynı baxışı ilə event spesifikasiyasını birləşdirmək daha doğru qərarların alınmasına kömək edir. Buraxılışdan sonra taxonomy, QA və dashboard-ların davamlı idarəsi üçün texniki dəstək və konsaltinq üzrə konsultasiya sifariş edə bilərsiniz.