Firebase A/B Testing — bu nədir, eksperiment növləri və necə qurulur

Mobil tətbiqlər kontekstində A/B testi nədir

A/B testi (split-test) — iki istifadəçi qrupunun (nəzarət və eksperimental) tətbiqin bir elementinin müxtəlif versiyalarını gördüyü, sonra hər versiyanın seçilmiş metrikaya təsirinin ölçüldüyü müqayisəli analiz metodudur. Mobil tətbiq inkişafında A/B testləri UI dəyişiklikləri, onbordinq, monetizasiya mexanikaları, push bildirişləri və tövsiyə alqoritmləri haqqında fərziyyələri yoxlamaq üçün istifadə olunur.

A/B testini sadə müşahidədən fərqləndirən əsas şey — səbəb-nəticə əlaqəsi (causality). Əgər sifariş vermə ekranını dəyişdikdən sonra konversiya 15% artıbsa, A/B testi sübut edir ki, məhz bu dəyişiklik artıma səbəb olub, xarici amil (bayram, reklam kampaniyası, mövsümilik) yox. A/B testi olmadan səbəb-nəticə əlaqəsini — yalnız korrelyasiyanı təsdiq etmək olar. Optimizely (2025) məlumatlarına görə, müntəzəm olaraq A/B testləri aparan şirkətlər ildə orta hesabla 30% konversiya artımı əldə edirlər.

Keyfiyyətli A/B testi aparmaq üçün dörd komponent lazımdır: fərziyyə (nəyi və niyə dəyişirik), metrika (effekti necə ölçürük), seçmə ölçüsü (etibarlı nəticə üçün nə qədər istifadəçi lazımdır) və müddət (nə qədər məlumat toplamaq). Firebase A/B Testing dörd komponenti də avtomatik əhatə edir, lakin nəticələrin düzgün interpretasiyası üçün hər birini başa düşmək lazımdır.

Niyə A/B testləri mobil tətbiqlər üçün vacibdir

Mobil tətbiqlər A/B testini xüsusilə dəyərli edən spesifik xüsusiyyətlərə malikdir. Birincisi, yüksək rəqabət: Google Play-də 3 milyondan çox tətbiq var və hər UI qərarı retention və konversiyaya təsir edir. İkincisi, uzun buraxılış dövrü: app store vasitəsilə dəyişikliyi dərc etmək rəy üçün 1–7 gün çəkə bilər. A/B testi fərziyyəni buraxılış olmadan (Remote Config vasitəsilə) yoxlamağa və dəyişikliyi yalnız effektivlik təsdiqləndikdə tətbiq etməyə imkan verir.

Auditoriyanın seqmentasiyası — A/B testlərinin daha bir üstünlüyü. Yeni istifadəçilər üçün işləyən dəyişiklik köhnələr üçün zərərli ola bilər. Firebase A/B Testing auditoriyanı tətbiq versiyası, ölkə, dil, qeydiyyat müddəti və istifadəçi xassələrinə görə seqmentləşdirməyə imkan verir. Bu, qlobal yayımlamadan əvvəl dəyişikliyi konkret alt qrupda test etmək imkanı yaradır.

A/B testi və feature flag (Remote Config) arasındakı fərq

Feature flag (funksiya bayrağı) — funksiyanın bütün istifadəçilər və ya onların faizi üçün sadəcə aktivləşdirilməsi və ya söndürülməsidir. A/B testi — metrikaların ölçülməsi və statistik əhəmiyyətliliyin hesablanması ilə strukturlaşdırılmış eksperimentdir. Feature flag suala cavab vermir „dəyişiklik metrikalara təsir etdi?", o yalnız funksiyanın əlçatanlığını idarə edir. Firebase A/B Testing Remote Config-dən dəyər çatdırılması mexanizmi kimi istifadə edir, lakin analitika və statistika qatını əlavə edir.

Praktikada: əgər sadəcə yeni funksiyanı tədricən istifadəçilərin 20%-nə yayımlamaq və onun çökmədiyinə əmin olmaq istəyirsinizsə — random_percent şərti ilə Remote Config-dən istifadə edin. Əgər yeni funksiyanın konversiya dərəcəsini 10% artırdığını sübut etmək istəyirsinizsə — metrikaları avtomatik ölçəcək və p-value göstərəcək Firebase A/B Testing-dən istifadə edin.

Firebase A/B Testing necə işləyir

Firebase A/B Testing — Remote Config və Cloud Messaging üzərində qurulmuş, eksperimentlərin yaradılması və monitorinqi üçün vahid interfeys təmin edən əlavədir. Memarlıq baxımından xidmət üç komponentdən ibarətdir: idarəetmə konsolu (Firebase Console-da A/B Testing bölməsi), paylama mexanizmi (istifadəçiləri verilən faiz əsasında qruplara ayırır) və statistik mühərrik (qruplar arasında metrikaların fərqini təhlil edir).

Eksperimentin yaradıcısı dəyişiklikləri dərc etdikdə, Firebase Remote Config şablonunun yeni versiyasını saxlayır, lakin müxtəlif istifadəçi qrupları üçün parametrlərin fərqli dəyərlərini tətbiq edir. Müştəri tətbiqi fetchAndActivate yerinə yetirərək öz qrupuna uyğun dəyəri alır. Firebase Analytics bütün qruplardan hadisələri toplayır və onları gündəlik p-value və etibarlılıq intervalları ilə hesabatı yeniləyən statistik mühərrikə ötürür.

Statistik model Firebase A/B Testing metrikaların orta dəyərlərini müqayisə etmək üçün t-testi ilə frequentist yanaşmasından istifadə edir. Binar metrikalar üçün (konversiya, retention) — iki seçməli nisbətlər z-testi. Əhəmiyyətlilik səviyyəsi (alpha) standart olaraq — 0.05. Bir neçə əsas metrika seçildikdə Firebase Bonferroni korreksiyası ilə çoxlu müqayisələri düzəldir. Vacibdir: statistik əhəmiyyətlilik praktiki əhəmiyyətliliyə zəmanət vermir — hətta p-value < 0.05 olduqda belə mütləq artım iqtisadi cəhətdən məqsədəuyğun olmaya bilər.

İstifadəçilərin qruplara bölünməsi

Firebase A/B Testing istifadəçi identifikatoru (Analytics App Instance ID) əsasında deterministik bölgüdən istifadə edir. Bu o deməkdir ki, eyni istifadəçi, eksperimentin konfiqurasiyası dəyişməyibsə, təkrar işə salmalarda həmişə eyni qrupa düşür. Deterministiklik istifadəçi təcrübəsinin ardıcıllığı üçün vacibdir: istifadəçi tətbiqi hər açdıqda interfeysin fərqli versiyalarını görməməlidir.

Faiz bölgüsü eksperiment yaradılarkən təyin edilir: məsələn, 50% nəzarət qrupu, 50% eksperimental qrup. Firebase istifadəçiləri təsadüfi seed nəzərə alınmaqla bərabər şəkildə paylayır, ölçüyə görə balanslaşdırılmış qrupları təmin edir. Bir neçə eksperimental qrupdan istifadə edildikdə (A/B/n) faiz onlar arasında bərabər bölünür. Vacibdir: paylama faizi eksperiment başladıqdan sonra dəyişdirilə bilməz — faizi dəyişmək üçün eksperimenti dayandırıb yenisini yaratmaq lazımdır.

Remote Config və Cloud Messaging ilə inteqrasiya

Remote Config eksperimentdə dəyişdirilən parametrlər üçün dəyər mənbəyi kimi xidmət edir. A/B testi yaradarkən Remote Config parametrini seçir və onun dəyərini hər qrup üçün təyin edirsiniz. Firebase avtomatik olaraq eksperimental dəyərlərlə Remote Config şablonunun müvəqqəti qolunu yaradır. Eksperiment qruplardan birinin xeyrinə dayandırıldıqdan sonra onun dəyəri Firebase konsolu vasitəsilə production dəyəri kimi tətbiq oluna bilər.

Cloud Messaging eksperimentin bir hissəsi olan push bildirişlərini göndərmək üçün istifadə olunur. Firebase A/B Testing müxtəlif mətnlər, şəkillər və vaxtlama ilə push bildiriş eksperimentlərinin yaradılmasını dəstəkləyir. Xidmət avtomatik olaraq bildirişləri qruplara paylayır və metrikalara təsirini ölçür: open rate, klikdən sonra konversiya, uninstall rate. Bu, əl ilə A/B göndəriş testi olmadan istifadəçilərlə ünsiyyətin optimal mexanikalarını tapmağa imkan verir.

Eksperimentin yaradılması və qurulması

A/B testinin yaradılması Firebase Console-da A/B Testing bölməsində „Create experiment" düyməsi ilə həyata keçirilir. Yaratma köməkçisi bir neçə addımı əhatə edir: eksperiment tipinin seçilməsi (Remote Config və ya Notification), parametrin və onun nəzarət və test qrupları üçün dəyərlərinin göstərilməsi, hədəf auditoriyanın (atributlar üzrə) müəyyən edilməsi və ölçmə üçün metrikaların seçilməsi. Quraşdırma tamamlandıqdan sonra eksperiment dərc olunur və məlumat toplamağa başlayır.

Eksperiment tipinin seçilməsi: Remote Config eksperimenti — tətbiqin istənilən parametrini dəyişmək üçün (UI, məzmun, logika); Notification eksperimenti — müxtəlif push bildirişlərinin effektivliyini müqayisə etmək üçün. Remote Config eksperimentləri əvvəlcədən Remote Config-də yaradılmış parametr tələb edir. Notification eksperimentləri müstəqil yaradılır — Firebase müştəri tərəfində kod yazmadan hər qrup üçün push bildirişləri avtomatik hazırlayacaq və göndərəcək.

Auditoriyanın müəyyən edilməsi — kritik dərəcədə vacib addım. Standart olaraq eksperiment tətbiqin bütün istifadəçilərində işə salınır. Auditoriyanı daraltmaq üçün filtrlərdən istifadə edin: tətbiq versiyası, ölkə, dil, OS versiyası, Analytics istifadəçi xassələri. Məsələn, onbordinq dəyişikliyini yalnız yeni istifadəçilərdə (7 gün ərzində first_open) test etmək məntiqlidir. Uyğun olmayan auditoriyada test etmək dəyişikliyin real effektini gizlədən „bulanıq" nəticə verir.

Eksperimentin müddəti və seçmə ölçüsü

Minimal müddət Firebase A/B Testing-də eksperimentin — 3 gün (tam həftə sonu daxil olmaqla, çünki istifadəçilərin iş günləri və həftə sonları davranışı fərqlənir). Firebase trafik və verilmiş minimal aşkar edilə bilən effekt (Minimum Detectable Effect, MDE) əsasında tövsiyə olunan müddəti avtomatik hesablayır. MDE standart olaraq — metrikada 5% nisbi dəyişiklik. Cari trafik 4 həftə ərzində 5% effekti aşkar etmək üçün kifayət deyilsə, Firebase bu barədə xəbərdarlıq edəcək.

Seçmə ölçüsü əsasında hesablanır: baza metrikası (cari dəyər), MDE, əhəmiyyətlilik səviyyəsi (alpha = 0.05) və statistik güc (power = 0.8). 50 000 MAU və baza konversiya dərəcəsi 10% olan tipik tətbiq üçün 5% nisbi dəyişikliyi aşkar etmək hər qrupda təxminən 30 000 istifadəçi (cəmi 60 000) tələb edəcək. Seçmə ölçüsü kifayət deyilsə, dəyişiklik effektiv olsa belə, nəticə statistik əhəmiyyətliliyə çatmaya bilər (II növ səhv).

Çox variantlı iş (A/B/n)

Çoxvariantlı eksperimentlər (A/B/n) bir parametrin 3 və daha çox versiyasını müqayisə etməyə imkan verir. Firebase bir eksperimentdə 10 varianta qədər dəstəkləyir. Nə qədər çox variant, statistik əhəmiyyətliliyə çatmaq üçün bir o qədər çox istifadəçi tələb olunur. Qayda: hər əlavə variant üçün seçmə ölçüsü iki variantlı testə nisbətən 20–30% artır. Trafik məhduddursa, bir çoxvariantlı testdən daha çox ardıcıl iki variantlı testlər üstünlük təşkil edir.

Bonferroni korreksiyası — Firebase bir neçə variant və ya metrika olduqda çoxlu müqayisələrə düzəlişi avtomatik tətbiq edir. Mahiyyət: alpha = 0.05 ilə 5 fərziyyəni test edirsinizsə, ən azı bir yalançı müsbət nəticə ehtimalı 1 — (0.95)^5 ≈ 22.6% təşkil edir. Bonferroni korreksiyası alpha-nı müqayisələrin sayına bölür: 5 fərziyyə üçün alpha = 0.01. Bu, effektin aşkarlanmasını daha mühafizəkar edir, lakin false positive riskini azaldır.

Metrikalar, nəticələrin təhlili və qərarların qəbulu

Metrikaların seçilməsi — eksperimentin keyfiyyətini təyin edən ən vacib mərhələdir. Firebase A/B Testing bir neçə metrika kateqoriyası təklif edir: cəlbetmə (daily active users, session duration, screens per session), monetizasiya (revenue, purchases, subscriptions), retention (Day 1, Day 7, Day 28), konversiya (seçilmiş hadisə üzrə conversion rate). Firebase Analytics-in istənilən hadisələri əsasında fərdi metrikalar da mövcuddur.

Əsas metrika (primary metric) — eksperimentin uğuru haqqında qərar qəbul edilən yeganə metrikadır. Əsas metrikanın seçimi fərziyyə əsasında eksperiment başlamazdan əvvəl edilməlidir. Əgər fərziyyə „Yeni onbordinq qeydiyyat konversiyasını artıracaq" olarsa, əsas metrika sign_up_completed hadisəsinin conversion rate-idir. İkinci dərəcəli metrikalar (secondary metrics) — yan təsirlərin təhlili üçün əlavə göstəricilər: retention azalıbmı, revenue düşübmü.

Nəticələrin interpretasiyası: Firebase hər qrup üçün metrikaların dəyərləri, nəzarət qrupundan faiz fərqi, p-value və 95% etibarlılıq intervalı olan cədvəl göstərir. p-value < 0.05 və etibarlılıq intervalı 0-ı əhatə etmirsə — fərq statistik əhəmiyyətlidir. p-value > 0.05 olarsa — nəticə qeyri-müəyyəndir (inconclusive) və eksperiment uzadılmalı və ya qeyri-müəyyən olaraq dayandırılmalıdır.

Nəticələr əsasında qərar qəbulu

Firebase A/B Testing eksperiment bitdikdən sonra üç hərəkət variantı təklif edir: qalib variantı bütün istifadəçilər üçün tətbiq etmək, eksperimenti davam etdirmək (məlumat azdırsa) və ya eksperimenti tətbiq etmədən dayandırmaq (bütün variantlar nəzarətdən pisdirsə və ya nəticə qeyri-müəyyəndirsə). Qalibin tətbiqi Remote Config şablonunu avtomatik olaraq qalib variantın production dəyəri ilə yeniləyir.

Diqqət: bəzən statistik əhəmiyyətli nəticənin praktiki mənası olmur. Məsələn, test konversiya dərəcəsində 0.5% artım göstərdi (p = 0.03), lakin UI-nin yeni versiyası 2 həftəlik inkişaf tələb edir. Xərc və fayda nisbəti məqsədəuyğun olmaya bilər. Qərarları yalnız statistik əhəmiyyətliliyə deyil, biznes təsirinə əsaslanaraq qəbul edin. Firebase təkcə p-value deyil, həm də metrikada mütləq dəyişikliyi göstərir ki, bu da praktiki əhəmiyyəti qiymətləndirməyə kömək edir.

Qabaqcıl metrikalar: retention və LTV

Retention — mobil tətbiqlər üçün ən vacib metrikalardan biridir, çünki birbaşa istifadəçinin uzunmüddətli dəyəri (LTV) ilə əlaqəlidir. Firebase A/B Testing hər qrup üçün avtomatik olaraq Day 1, Day 7 və Day 28 retention hesablayır. Lakin etibarlı retention ölçümü üçün vaxt lazımdır: Day 7 retention-i eksperiment başladıqdan 7 gün sonra, Day 28 retention-i isə 28 gün sonra qiymətləndirmək olar. Eksperimentin müddətini retention məlumatlarını toplamaq üçün lazım olan vaxtı nəzərə alaraq planlaşdırın.

LTV (Lifetime Value) — Firebase-in Google Analytics for Firebase və lazım olduqda atribusiya platforması (Adjust, AppsFlyer) ilə inteqrasiyasını tələb edən daha mürəkkəb metrikadır. Firebase A/B Testing LTV-dən metrika kimi istifadə etməyə imkan verir, lakin onun hesablanması üçün satınalmalar və istifadəçi cəlb etmə xərcləri haqqında məlumatların idxalını konfiqurasiya etmək lazımdır. Atribusiya olmadan LTV qeyri-dəqiq ola bilər, çünki Firebase reklam mənbələrindən quraşdırma dəyərini görmür.

Remote Config vasitəsilə A/B testinin qurulması

Firebase A/B Testing vasitəsilə A/B testi aparmaq üçün müştəri tərəfində xüsusi kod tələb olunmur — bütün eksperiment Firebase konsolunda qurulur. Lakin müştəri kodu Remote Config parametrlərindən düzgün istifadə etməlidir ki, eksperiment tərəfindən təyin edilmiş dəyərlər düzgün tətbiq olunsun. Nümunəyə baxaq: nəzarət qrupunun köhnə qiyməti (9.99 $), eksperimental qrupun isə yeni qiyməti (7.99 $) gördüyü yeni abunə qiymətinin A/B testi.

Firebase konsolunda standart dəyəri „9.99" olan Remote Config parametri subscription_price yaradırıq. Sonra A/B testi yaradırıq, burada qalib variant kimi istifadəçilərin 50%-i üçün „7.99" dəyərini göstəririk. Firebase avtomatik olaraq hər istifadəçini qrupa təyin edir və Remote Config vasitəsilə müvafiq dəyəri çatdırır. Müştəri kodu qiyməti əldə etmək üçün standart getString-dən istifadə edir.

A/B testini tətbiq etmək üçün müştəri kodu

Müştəri kodu eksperimentin mövcudluğundan xəbərsizdir — o sadəcə Remote Config-dən parametr dəyərini alır. Firebase SDK qruplaşdırmanı server tərəfində idarə edir. Bu, Firebase A/B Testing-in əsas üstünlüyüdür: tərtibatçı qruplara bölünmə üçün şərti loqika yazmalı deyil. Yeganə tələb — tətbiq aktual dəyərləri əldə etmək üçün müntəzəm olaraq fetchAndActivate çağırmalıdır.

class SubscriptionFragment : Fragment() {

    private fun loadPrice() {
        val remoteConfig = Firebase.remoteConfig
        val priceStr = remoteConfig
            .getString("subscription_price")
        val price = priceStr.toDoubleOrNull() ?: 9.99
        priceView.text = "$$price/month"
    }

    override fun onViewCreated(...) {
        super.onViewCreated(...)
        loadPrice()
    }
}

Nümunədə loadPrice Remote Config vasitəsilə subscription_price parametrinin dəyərini alır. Firebase SDK avtomatik olaraq aktiv A/B testi çərçivəsində istifadəçinin qrupuna uyğun dəyəri qaytarır. Eksperiment aktiv deyilsə və ya istifadəçi qrupa düşməyibsə — standart dəyər qaytarılır. Bu, kodu eksperimentlərin mövcudluğundan və ya olmamasından tamamilə müstəqil edir.

Metrikalar üçün analitik hadisələrin qeydə alınması

Firebase A/B Testing-in düzgün işləməsi üçün tətbiq eksperimentin metrikaları kimi seçilmiş hadisələri qeydə almalıdır. Firebase Analytics SDK standart hadisələri (first_open, session_start, in_app_purchase və s.) avtomatik toplayır, lakin fərdi metrikalar üçün qeydə alma əlavə etmək lazımdır. Aşağıdakı nümunədə istifadəçi abunəni rəsmiləşdirməyə cəhd etdikdə subscription_started hadisəsi qeydə alınır.

private fun onSubscribeClick() {
    // A/B testi üçün hadisəni qeyd edirik
    val bundle = Bundle().apply {
        putString(
            FirebaseAnalytics.Param.PRICE,
            remoteConfig.getString("subscription_price")
        )
    }
    FirebaseAnalytics.getInstance(requireContext())
        .logEvent("subscription_started", bundle)

    // Ödəniş flow-unun başladılması
    startBillingFlow()
}

Vacibdir: subscription_started hadisəsi Firebase Analytics-də fərdi hadisə kimi qeydiyyatdan keçməlidir (hesabatlar üçün) və ya Firebase A/B Testing tərəfindən istifadə olunan standart hadisə olmalıdır. Firebase hadisəni Analytics App Instance ID vasitəsilə avtomatik olaraq eksperiment qrupu ilə əlaqələndirir. Heç bir əlavə işarələmə tələb olunmur — bütün sehr Firebase server tərəfində baş verir.

A/B testlərinin aparılmasında tipik səhvlər

Peek-effekt səhvi — planlaşdırılmış müddəti nəzərə almadan statistik əhəmiyyətliliyin ilk görünüşündə eksperimenti dayandırmaq. Hər gün p-value yoxlayıb p < 0.05 olan kimi dayandırarsa, yalançı müsbət nəticə ehtimalı 5%-dən 30–40%-ə yüksəlir. Firebase A/B Testing sabit eksperiment müddətini tövsiyə edir. Hesablanmış müddət bitməmiş nəticələrə baxmayın.

Nəzərə alınmayan xarici amillər — mövsümilik, reklam kampaniyaları, OS yeniləmələri, rəqiblərin çıxışı. A/B testi zamanı trafikin tərkibini dəyişən reklam kampaniyası başlatmısınızsa, testin nəticəsi təhrif oluna bilər. A/B testlərini böyük marketinq fəaliyyətləri ilə eyni vaxtda aparmamaq tövsiyə olunur. Bu qaçılmazdırsa — reklam trafikinin qruplar arasında bərabər paylandığına əmin olun.

Seqmentar effekt (Simpson paradoksu) — ümumi nəticənin effekt olmadığını göstərdiyi, lakin ayrı-ayrı seqmentlər daxilində effekt olduğu və əks olduğu vəziyyət. Məsələn, test yeni sifariş dizaynının orta hesabla konversiyanı dəyişmədiyini göstərdi, lakin iOS və Android-ə bölündükdə məlum oldu: iOS-da konversiya 20% artdı, Android-də isə 15% azaldı. Həmişə nəticələri əsas seqmentlər üzrə yoxlayın (platforma, ölkə, tətbiq versiyası).

Çoxsaylı metrikalar problemi

Çoxsaylı müqayisə problemi eksperimentdə çox metrikadan istifadə edildikdə yaranır. alpha = 0.05 ilə 20 metrikanı yoxlayırsınızsa, ən azı bir yalançı əhəmiyyətli fərq (false positive) tapma ehtimalı 1 — (0.95)^20 ≈ 64% təşkil edir. Firebase bir neçə əsas metrika üçün Bonferroni korreksiyasından istifadə edir, lakin ikinci dərəcəli metrikalar üçün yox. Nəticə: eksperiment başlamazdan əvvəl bir əsas metrika seçin və qərar qəbul edərkən ikinci dərəcəli metrikaların p-value-nə fikir verməyin.

Yenilik effekti (Novelty effect) — istifadəçilər yeni dəyişikliyə onun daha yaxşı olduğuna görə deyil, sadəcə yeni olduğuna görə fərqli reaksiya verə bilərlər. Eksperimentin ilk günləri yalançı artım göstərə bilər (istifadəçilər maraqdan yeni düyməni sıxır), zamanla azalır. 3 günlük minimal eksperiment müddəti bu problemi qismən həll edir, lakin UI dəyişiklikləri üçün yenilik effektinin sabitləşməsi üçün 7–14 gün müddət tövsiyə olunur.

Eksperimentlər arasında interferensiya

Şəbəkə effekti (network effect) — bir qrupdakı istifadəçinin davranışının digər qrupdakı istifadəçilərə təsir etdiyi problem. Məsələn, xəbər lentinin alqoritminin dəyişdirilməsinin A/B testi: əgər eksperimental qrup daha yaxşı tövsiyələr alırsa, onlar nəzarət qrupunun istifadəçilərinin də gördüyü daha çox məzmun yaradır, nəticələri təhrif edir. Belə hallarda sosial qrafik üzrə izolyasiyadan istifadə edin və ya testi ölkə/region səviyyəsində aparın.

Eyni vaxtda aparılan eksperimentlər eyni Remote Config parametrində — interferensiyanın başqa bir mənbəyidir. Firebase A/B Testing artıq işğal olunmuş parametrdə ikinci eksperimenti işə salmağa icazə vermir, lakin eksperimentlər müxtəlif parametrlərə aid olub eyni metrikaya təsir edərsə, çarpaz effekt mümkündür. Eyni vaxtda 2–3-dən çox aktiv A/B testi aparmamaq və onların eyni istifadəçi ssenarilərinə təsir etməməsinə nəzarət etmək tövsiyə olunur.