Mobil tətbiqlərdə A/B testi — bu nədir, test növləri və necə aparılır
A/B testi — məhsulun iki versiyasının (nəzarət A və eksperimental B) eyni anda fərqli istifadəçi qruplarına göstərilərək ən təsirli variantın müyyən edilməsi üçün istifadə olunan nisbi eksperiment metodudur. Mobil tətbiq inkişafında A/B testləri interfeysin optimallaşdırılması, konversiya və istifadəçi təcrübəsi üçün tətbiq edilir. Harvard Business Review (2024)-yə görə, sistematik olaraq A/B testindən istifadə edən şirkətlər konversiyanı orta hesabla 20% artırır. A/B testi intuisiya deyil, məlumatlara əsaslanaraq qərarlar qəbul etməyə imkan verir.
Əsas Məqamlar
- A/B testi — ən yaxşı variantı müyyən etmək üçün məhsulun iki versiyasının real istifadəçilər üzərində müqayisəsi
- Proses fərziyyənin formalaşdırılması, trafikin bölüşdürülməsi, məlumat toplanması və statistik analizi əhatə edir
- Çoxfaktorlu test eyni anda bir neçə dəyişəni yoxlamağa imkan verir
- Alətlər mobil A/B testi üçün Firebase Remote Config, Amplitude və Leanplum daxildir
- Tipik səhvlər — testin vaxtından əvvəl dayandırılması, çoxlu müqayisə və qeyri-kafi nümunə ölçüsü
A/B testi nədir
A/B testi (split-test) — iki istifadəçi qrupunun məhsulun müxtəlif versiyalarını gördüyü randomizə edilmiş nəzarətli eksperiment metodudur. A qrupu (control) cari versiyanı, B qrupu (treatment) isə dəyişdirilmiş versiyanı alır. Qruplar arasında metrikaların müqayisəsi hansı versiyanın müəyyən meyara görə daha təsirli olduğunu müyyən etməyə imkan verir: konversiya, tətbiqdə qalma müddəti, gəlir və ya retensiya.
Tərif və məqsəd
A/B testinin əsas məqsədi məlumatlara əsaslanan qərarlar qəbul etməkdir. „Hansı dümə rəngi daha yaxşıdır” müküməsi əvəzinə komanda eksperiment işə salır və obyektiv cavab alır. Mobil tətbiq inkişafında A/B testləri onbording prosesinin, ödəniş ekranının, push bildirişlərinin, interfeys elementlərinin yerləşdirilməsinin və tövsiyə alqoritmlərinin optimallaşdırılması üçün tətbiq edilir. Hər bir eksperiment „Əgər X etsək, Y metriki Z% dəyişəcək” formatında formalaşdırılmış bir fərziyyəni test etməlidir.
Statistik əhəmiyyətlilik
A/B testinin nəticələri yalnız statistik əhəmiyyətliliyə çatdıqda etibarlı sayılır — adətən p-value < 0.05 (95% etibar intervalı). Bu o deməkdir ki, fərqi təsadüfən müşahidə etmə ehtimalı 5%-dən azdır. Tələb olunan nümunə ölçüsünün düzgün hesablanması üçün power analysis istifadə olunur: gözlənilən effekt nə qədər kiçikdirsə, bir o qədər çox istifadəçi eksperimentə daxil edilməlidir. Milyonlarla istifadəçisi olan mobil tətbiqlər üçün A/B testi bir neçɖ saat ərzində başa çata bilər, kiçik layihələr üçün isə 1–2 həftə çəkə bilər.
A/B testi necə işləyir
A/B testi prosesi altı mərhələdən ibarətdir: fərziyyənin formalaşdırılması, eksperimentin dizaynı, implementasiya, işə salma, məlumat toplanması və analiz. Hər bir mərhələ kritik əhəmiyyət daşıyır: hər hansı bir mərhələdəki səhv test nəticələrini etibarsız edir. Firebase Remote Config nümunəsi üzərində mobil tətbiqdə A/B testinin tipik implementasiyasını nəzərdən keçirək.
Eksperiment prosesi
Fərziyyə formalaşdırıldıqdan sonra proqramçı komponentin hər iki versiyasını implementasiya edir və onları eksperiment sisteminə qoşur. Firebase Remote Config yeni versiya dərc etmədən tətbiq parametrlərini uzaqdan idarə etməyə imkan verir. İstifadəçilər eksperiment başladıqdan sonra ilk açılışda təsadüfi olaraq A və ya B qrupuna təyin edilir. Önəmli: təyinat sabit olmalıdır — bir istifadəçi eksperiment boyu həmişə eyni versiyanı görməlidir. Sistem seçilmiş metrikalar üzrə avtomatik olaraq analitika toplayır və real vaxt rejimində ilkin nəticələri göstərir.
kotlin
class ExperimentManager {
private val remoteConfig = Firebase.remoteConfig
fun getCheckoutVariant(): CheckoutVariant {
val variantName = remoteConfig
.getString("checkout_experiment")
return when (variantName) {
"control" -> CheckoutVariant.Control
"new_layout" -> CheckoutVariant.NewLayout
else -> CheckoutVariant.Control
}
}
fun trackConversion(userId: String, variant: CheckoutVariant) {
Firebase.analytics.logEvent("checkout_completed") {
param("experiment", "checkout_layout")
param("variant", variant.name)
}
}
}Nəticələrin analizi
Kifayət qədər məlumat toplandıqdan sonra (əvvəlcədən hesablanmış nümunə ölçüsü) statistik analiz aparılır. Əsas müqayisə metriki — qruplar arasında 95% etibar intervalı ilə nisbi fərqdir. Etibar intervalı sıfırı keçmirsə, nəticə əhəmiyyətli sayılır. Əlavə olaraq guardrail metrikaları yoxlanılır — pisləşməməli olan göstəricilər (məsələn, ekran yüklənmə müddəti). Guardrail metrikaları pisləşərsə, əsas metrikada yaxşılaşma olsa belə, eksperiment dayandırılır.
A/B testlərinin növləri
Hər biri müxtəlif ssenarilər və mürəkkəblik səviyyələri üçün uyğun olan bir neçə eksperimental dizayn növü var. Yanlış test növünün seçilməsi etibarsız nəticələrə və ya əsassız vaxt və resurs xərclərinə səbəb ola bilər. Mobil tətbiq inkişafında tətbiq edilən A/B testlərinin əsas növlərini nəzərdən keçirək.
Çoxfaktorlu test
MVT (Multivariate Testing) eyni anda bir neçə dəyişəni test etməyə imkan verir — məsələn, dümə rəngi və başlıq mətni. İki variant (A/B) əvəzinə, MVT 4 kombinasiya (2×2) yaradır. Üstünlük — dəyişənlər arasında qarşılıqlı təsiri aşkar etmək imkanıdır. Çatışmazlıq — hər bir kombinasiya statistik əhəmiyyətliliyə çatmalı olduğu üçün əhəmiyyətli dərəcədə daha böyük nümunə tələb olunur. MVT yalnız yüksək trafikli tətbiqlər üçün tövsiyə olunur (milyonlarla DAU).
Bandid alqoritmləri
Sabit 50/50 bölgüsü olan klassik A/B testindən fərqli olaraq, multi-armed bandit məlumatlar daxil olduqca trafiki dinamik olaraq daha yaxşı variantın lehinə yenidən bölüşdürür. Bu, eksperimentin „xərci” baxımından daha səmərəlidir — daha az istifadəçi aşkar şəkildə pis variantı alır. Bununla belə, bandid alqoritmləri analizdə daha mürəkkəbdir və qeyri-bərabər trafikdə qeyri-optimal varianta vaxtından əvvəl yaxınlaşa bilər. Mobil tətbiqlər üçün bandid yanaşması push bildirişlərinin və tövsiyələrin optimallaşdırılması üçün yaxşı uyğyn gəlir.
| Test növü | Dəyişənlər | Nümunə ölçüsü | Nə vaxt istifadə etməli |
|---|---|---|---|
| A/B | 1 | Aşağı | Sadə fərziyyə, 2 variant |
| A/B/n | 1 (n variant) | Orta | Bir dəyişikliyin bir neçə alternativi |
| MVT | 2+ | Yüksək | Bir neçə dəyişikliyin qarşılıqlı təsiri |
| Bandit | 1+ | Dinamik | Real vaxt optimallaşdırması |
A/B testi üçün alətlər
A/B testi alətlərinin ekosistemi həm ixtisaslaşmış platformaları, həm də mobil SDK-ların daxili imkanlarını əhatə edir. Konkret həllin seçimi texnoloji stekdən, trafik həcmindən və tələb olunan eksperiment konfiqurasiya çevikliyindən asılıdır.
Mobil testlər üçün platformalar
Firebase Remote Config — mobil tətbiqlərdə A/B testi üçün ən məşhur həll. Remote Config yeni versiya dərc etmədən tətbiq parametrlərini dəyişməyə imkan verir, daxili A/B Testing SDK isə istifadəçiləri avtomatik qruplara ayırır və analitika toplayır. Google Analytics for Firebase konversiyaları və hadisələri izləmək üçün inteqrasiya təmin edir. Alternativlər: bandid alqoritmləri dəstəyi ilə Amplitude Experiment, marketinq eksperimentləri üçün Leanplum və server tərəfi testi üçün Split.io.
Server tərəfi A/B testi
Mobil tətbiqlərin backend xidmətləri üçün A/B testi feature flag sistemləri (LaunchDarkly, Unleash) vasitəsilə həyata keçirilir. Server user ID və ya device ID əsasında variant haqqında qərar verir və nəticəni müştəriyə qaytarır. Üstünlük — bölgü üzərində tam nəzarət və müştərini yeniləmədən variantları dəyişmək imkanıdır. Server tərəfi testlər üçün ardıcıllığı təmin etmək vacibdir: bir istifadəçi həmişə eyni variantı almalıdır, əks halda test nəticələri etibarsız olacaq. Hash-əsaslı bölgü (məsələn, user ID üzrə consistent hashing) məlumat bazasında xəritələmə saxlamaq ehtiyacı olmadan variant təyinatının sabitliyini təmin edir, bu da miqyaslamağı asanlaşdırır və tək uğursuzluq nöqtəsini aradan qaldırır.
A/B testlərində səhvlər
Hətta A/B testinin düzgün implementasiyası ilə belə, statistik tələlər səbəbindən yanlış nəticələr əldə etmək olar. Microsoft Research (2024) məlumatlarına görə, kommersiya məhsullarında A/B testlərinin 70%-i ən azı bir metodoloji səhv ehtiva edir. Ən tez-tez rast gəlinən problemləri və onların qarşısının alınması yollarını nəzərdən keçirək.
Vaxtından əvvəl dayandırma
Ən geniş yayılmış səhv — statistik əhəmiyyətlilik ilk dəfə göründükdə testi dayandırmaqdır. Əhəmiyyətliliyi hər saat yoxlamaq, yanlış müsbət nəticə (type I error) ehtimalını dəfələrlə artırır — buna peeking problem deyilir. Həll: testin sabit müddətini və nümunə ölçüsünü (power analysis) əvvəlcədən müyyənləşdirmək, eksperiment bitənə qədər nəticələrə baxmamaq və ya çoxlu yoxlamalarda əhəmiyyətlilik həddini tənzimləyən sequential testing metodlarından istifadə etmək.
Çoxlu müqayisə
Bir eksperimentdə eyni anda 10 metrika analiz edilərsə, ən azı bir metrikada yanlış müsbət nəticə ehtimalı 40% təşkil edir (real effekt olmasa belə). Bu çoxlu müqayisə problemidir (multiple comparison problem). Həll: qərar qəbul etmək üçün bir primary metrika müyyənləşdirmək, qalanlarını secondary (kəşfiyyat) hesab etmək. Bir neçə metrikanı analiz etmək lazım olduqda Bonferroni düzəlişini və ya FDR (False Discovery Rate) nəzarətini tətbiq etmək.
Tez-tez verilən suallar
A/B testi üçün nə qədər istifadəçi lazımdır?
Tələb olunan nümunə ölçüsü gözlənilən effektdən və metrikaların dəyişkənliyindən asılıdır. Cari konversiya 10% olduğunda 5% konversiya dəyişikliyini aşkar etmək üçün hər qrup üçün təxminən 25 000 istifadəçi tələb olunur. 1% dəyişikliyi aşkar etmək üçün isə artıq 500 000+ istifadəçi lazımdır. Testə başlamazdan əvvəl minimum nümunə ölçüsünü hesablamaq üçün power analysis kalkulyatorundan istifadə edin.
A/B testi nə qədər davam etməlidir?
İstifadəçi davranışının həftəlik dövriliyini nəzərə almaq üçün minimum müddət 7 gün olmalıdır. Aşağı trafikli B2B və ya niş tətbiqlər üçün müddət 2–4 həftə ola bilər. Nəticə açıq görünsə belə, testi planlaşdırılmış müddətdən əvvəl dayandırmayın — bu, yanlış müsbət nəticələrin əsas mənbəyidir.
Eyni anda bir neçə A/B testi işə salmaq olarmı?
Bəli, amma ehtiyatlı şəkildə. Hər bir test müstəqil istifadəçi seqmentlərindən istifadə etməlidir, əks halda nəticələr interferensiya edə bilər. Məsələn, eyni auditoriyada dümə rəngi testi və həmin dümənin yerləşməsi testi yanlış nəticələr verəcəkdir. Eksperiment laylarından (layers) istifadə edin — hər bir lay müstəqil istifadəçi seçməsi alır. Əksər A/B platformaları layered experimentation-ı dəstəkləyir.
A/B testi canary release-dən nə ilə fərqlənir?
A/B testi — iki variantın səmərəliliyini müqayisə edən və „hansı variant biznes üçün daha yaxşıdır” sualına cavab verən eksperimentdir. Canary Release — yeni versiyanın sabitliyini yoxlamaq üçün yerləşdirmə strategiyasıdır, „xidmət sınacaqmı” sualına cavab verir. Canary tədricən auditoriyanı genişləndirir, A/B isə sabit 50/50 (və ya başqa) bölgü istifadə edir. Bəzən canary infrastrukturu A/B testləri üçün əsas kimi istifadə olunur.
Hansı p-value kifayət sayılır?
Standart hədd — p-value < 0.05, bu da 95% etibarlılıq ehtimalına uyğUN gəlir. Yüksək riskli qərarlar (ödəniş axınının dəyişdirilməsi) üçün p-value < 0.01 (99%) tövsiyə olunur. Tədqiqat testləri üçün p-value < 0.1 məqbul sayılır. Önəmli: p-value yalnız statistik əhəmiyyətliliyi göstərir, praktiki deyil — hətta p < 0.001 olsa belə, effekt tətbiq etmək üçün çox kiçik ola bilər.
Xülasə
- A/B testi — məhsulun iki versiyasını real istifadəçilər üzərində müqayisə etmək üçün randomizə edilmiş eksperiment metodu
- Proses fərziyyənin formalaşdırılması, eksperiment dizaynı, implementasiya, məlumat toplanması və statistik analizi əhatə edir
- Çoxfaktorlu test (MVT) eyni anda bir neçə dəyişəni yoxlamağa imkan verir, lakin daha böyük nümunə tələb edir
- Firebase Remote Config — mobil tətbiqlərdə A/B testi üçün əsas alət
- Əsas səhvlər: testin vaxtından əvvəl dayandırılması, çoxlu müqayisə və qeyri-kafi nümunə ölçüsü
- Minimum test müddəti — 7 gün, nümunə ölçüsü power analysis vasitəsilə hesablanır
- Statistik əhəmiyyətlilik (p < 0.05) — zəruri, lakin kifayət deyil: praktiki əhəmiyyətlilik daha vacibdir
Açar təslim mobil tətbiq hazırlayacağıq
IT Sectr 2017-ci ildən startaplar və bizneslər üçün iOS və Android tətbiqləri yaradır. Sizə məsləhət verəcəyik və ən yaxşı həlli təklif edəcəyik.
Həm də oxuyun