Mobil Uygulamada A/B Testi: Ne Test Edilir, Nasıl Yorumlanır?

Bir müşteri geçen ay "buton rengini kırmızıdan turuncuya çevirdik, satışlar arttı" dedi, sevinerek. Sonra baktık ki test grubu 40 kullanıcıymış ve test sadece iki gün sürmüş. Bu bir A/B testi değil, tesadüf. Mobil uygulamada A/B testi, doğru kurulmadığında sizi yanlış kararlara sürükleyen bir araca dönüşebiliyor.

Neyi test etmeye değer, neyi etmez

Her değişikliği test etmek gerekmiyor. Buton renginin dönüşüm oranına etkisi genelde küçük — yüzde birkaç seviyesinde — ve bunu istatistiksel olarak anlamlı biçimde ölçmek için ciddi trafik gerekiyor. Buna karşılık akış sırası değişiklikleri — örneğin ödeme ekranında adres bilgisinin kart bilgisinden önce mi sonra mı istendiği, kayıt formunda telefon doğrulamanın ilk mi son adım mı olduğu — genelde çok daha büyük etkiler yaratıyor ve daha az trafikle bile anlamlı sonuç veriyor. Fiyat gösterimi (aylık mı yıllık mı vurgulanıyor), onboarding ekran sayısı (3 ekran mı 5 ekran mı), zorunlu kayıt ile misafir kullanım seçeneği gibi büyük yapısal kararlar test edilmeye en değer konular.

Örneklem büyüklüğü ciddiye alınmalı

İstatistiksel anlamlılığa ulaşmak için gereken kullanıcı sayısı, mevcut dönüşüm oranınıza ve beklediğiniz iyileşme miktarına göre değişiyor. Kabaca, mevcut dönüşüm oranınız %5 civarındaysa ve %1 puanlık bir artış bekliyorsanız, her varyant için birkaç bin kullanıcıya ihtiyacınız olabilir. Günlük 200 aktif kullanıcısı olan bir uygulamada bu testin anlamlı sonuç vermesi haftalar sürebilir. Bu hesaplamayı test başlamadan yapmak, "iki günde sonuç çıktı" yanılgısına düşmemek için şart. Online örneklem hesaplayıcıları bu konuda hızlı bir tahmin veriyor, ama en azından mantığını bilmeden kullanmamak gerekiyor.

Yanlış yorumlama nerede başlıyor

En sık yapılan hata, testi erken durdurmak. Sonuçlar bir varyant lehine görünmeye başladığı an testi kapatmak, aslında henüz gürültü seviyesindeki bir farkı gerçek sanmaya yol açıyor. İkinci yaygın hata, çok sayıda metriği aynı anda izleyip içlerinden birinde "anlamlı" fark bulunca onu öne çıkarmak — bu istatistikte çoklu karşılaştırma sorunu olarak biliniyor ve rastgele bile olsa bir metrikte fark bulma ihtimalini artırıyor. Üçüncü hata ise hafta içi ve hafta sonu kullanıcı davranışının farklı olduğunu göz ardı edip testi sadece birkaç güne sıkıştırmak; en az bir tam haftalık döngüyü kapsamak gerekiyor.

Teknik altyapı tarafı

Firebase Remote Config, mobil tarafta en yaygın kullanılan A/B test altyapısı; kullanıcıyı rastgele gruplara ayırıp farklı konfigürasyon değerleri gönderebiliyor, uygulama güncellemesi gerekmeden. Android uygulama geliştirme ve iOS uygulama geliştirme projelerinde bu altyapıyı en baştan kurmak, ileride her yeni test için ayrı bir sürüm yayınlama zorunluluğunu ortadan kaldırıyor. Test sonuçlarını Firebase Analytics event'leriyle eşleştirmek, hangi varyantın hangi davranışı tetiklediğini net görmeyi sağlıyor.

Sonuç değil, süreç

A/B testi tek seferlik bir karar aracı değil, sürekli işleyen bir öğrenme döngüsü olarak kurgulanmalı. Bir testten çıkan sonuç bir sonraki testin hipotezini besliyor. Küçük ekipler için ayda bir büyük test, sürekli beş test koşturmaktan daha sağlıklı bir tempo — her testi doğru örneklem ve doğru sürede tamamlamak, sayıca çok ama güvenilmez test yapmaktan çok daha değerli.

A/B Testi Kullanıcı Deneyimi Mobil Uygulama Ürün Geliştirme Veri Analizi