Dolap’ta A/B testleri nasıl yapıyoruz?
Dolap’ta ve genel olarak Trendyol’da karar alma sürecinde en büyük etken veridir. Kişiselleştirilmiş deneyim sunmak için algoritmalarımızda sürekli devam eden A/B testlerimiz var. Bunlar haricinde ön yüzde yaptığımız değişikliklerin etkilerini de en güzel A/B testlerle ölçebiliyoruz.
Yeni başlayanlar ya da sadece terim olarak A/B testi duyanlarda çok karmaşık gibi gözüken bu konuyu gerçek hayattan örneklerle destekleyerek mümkün olduğunca basit şekilde inceleyeceğiz.
Derinlemesine A/B test nedirden ziyade biz mobil uygulamalarda nasıl uyguluyoruz, aynı altyapıyı Feature Toggle olarak nasıl ve neden kullandığımıza değineceğiz.
- Kısaca A/B test nedir?
- A/B test yapılacak geliştirmelere nasıl yaklaşıyoruz?
- Akış ve Örneklerle A/B test
- Feature toggle olarak değişkenleri kullanmak
Kısaca A/B test nedir?
A/B test aynı amaca hizmet eden iki ya da daha fazla özelliğin, tasarımın ya da varyantının kullanıcı kitlesi rastgele bölünerek karşılaştırmadır. Örnek vermek gerekirse 2 farklı “Takip et” buton tasarımımız var. Birinci gruba ilk tasarımı ikinci gruba ikinci tasarımı göstererek hangisinin daha iyi sonuç verdiğini deneyip ölçümleyebiliyoruz.
A/B test yapılacak geliştirmelere nasıl yaklaşıyoruz?
A/B test yapmak istediğimiz geliştirmelerde mümkün olduğunca olaya basit yaklaşıp minimum eforla çıkmaya çalışıyoruz. Eğer mümkünse tek Client’da(iOS veya Andorid) test yapıyoruz. Backend geliştirmesi gerektiren durumlarda testin sonucunu görene kadar statik kod parçaları eklemeyi göze alıyoruz. Çünkü ölçümler geliştirmenin ürüne etkisinin olumsuz olduğunu gösterirse, yaptığımız geliştirmeleri geri aldığımız durumlar da yaşanabiliyor. Efor kaybını minimumda tutmak ileride yapacağımız geliştirmelerde A/B test yapabilmemizin önünü açıyor.
Akış ve Örneklerle A/B test
Dolap’ta A/B test için Leanplum kullanıyoruz. Burada A/B testin uygulanması açısından hangi aracı kullandığınızın çok da bir önemi olmuyor. Çünkü özünde bu araçlar size belirli keyler için değerler döner. Araçların önemi daha çok sonuçların incelenmesi ve raporlanması kısmında ortaya çıkıyor.
Biz de uygulama açılışında Leanplum iOS SDK ile Değişken listesini değerleriyle birlikte alıyoruz. Örneğin yukarıdaki takip et butonu A/B testimiz için belirlediğimiz değişken adı followButton olsun. Bu değişkenin değeri olarak da bizim belirlediğimiz değerler A ve B olsun. Kullanıcı hangi gruba düştüyse ona göre followButton = A ya da B gibi bir değer geliyor. Buna göre de hangi tasarımı göreceğine karar veriyoruz.
Burada değer olarak herhangi bir şey belirleyebiliriz ama biz genel pratik olarak A, B, C.. veriyoruz.
Bu değerler kullanıcı kitlesi bölünerek dağıtılıyor. Örneğin başka bir testimizde searchMyBrands değişkenine aşağıdaki örnek için kullanıcılarımızın %33'ü için A, %33'ü için B, %34 için C değerini dönüyor.
Biz burada yeni geliştirdiğimiz Sana Özel Markalar özelliğimizin;
- Olmama durumu A (as is) — Control
- Sadece label koyduğumuz bir varyantını — B
- Sadece görsel koyduğumuz 2. bir varyantını — C
Karşılaştırarak hangisinin daha iyi çalıştığını görüp, hangisiyle yola devam edeceğimize karar vermek için test yapacağız.
B grubuna düşen kullanıcılar arama ekranına bastığında Sana Özel Markalar kısmını sol taraftaki gibi, C grubundakiler sağ taraftaki gibi görecekler. A grubundakiler ise hiç görmeyecek.
Geliştirmesini yapalım
Yukarıdaki testimizi yapmaya karar verdik ve açılışta searchMyBrands için dönen değerimizi aldık. Burada bu değer A gelen kullanıcılarımız her şeyi eskisi gibi(as is) görmeye devam edecek. Öncelikle kullanıcının grubuna bakıp A değilse sana özel markaları göster gibi bir kontrol koyuyoruz.
B grubu gelen kullanıcılarımıza Text olan versiyonunu C grubu gelenlere Görsel olan versiyonunu gösterelim. Bunun için iki ayrı cell hazırlayıp birine ImageView diğerine bir Label koyduk. Yukarıdaki B, aşağıdaki C grubundaki kullanıcılarımız için. A grubu kullanıcı için bu view hiç bir zaman gözükmeyeceği için burada A durumunu düşünmemize gerek kalmıyor.
Ne zaman A/B test için yeni bir UI çalışıyoruz
Yukarıdaki testimiz için iki ayrı cell yaratarak devam ettik. Genelde test eforunu azaltmak için tek UI üzerinde StackView kullanıp kolayca göster, gizle, yer değiştir yaparak A/B testlerimizin içinden çıkabiliyoruz. Çıkamadığımız ya da durumu çok daha karmaşık bir hale getireceğini düşünüyorsak farklı UI hazırlıyoruz.
Örneğin ücretsiz kargo bilgisini göstermek için, Text olarak göstermek ve badge olarak göstermek arasında bir test yapmak istiyoruz.
A grubundaki kullanıcılarımız sol taraftaki gibi Kargo Bedava textini görürken, B grubundaki kullanıcılarımız görseller üzerinde Kargo Bedava bilgisini badge olarak görüyor.
Aşağıda ürün bilgilerini gösterdiğimiz kısımda her şey StackView içerisinde olduğu için, ilgili StackView gizlendiği anda UI’da herhangi bir şey bozulmadan göster gizle yapabiliyoruz. Aşağıda gözüktüğü gibi Shipment Stack View A grubu için gizlenecek.
Kullanıcı A grubundaysa view içerisindeki prepareShipment çağırılıp shipmentStackView.isHidden = false yapıyoruz ve ilgili değerlerini setliyoruz. Kullanıcı text olarak görüyor.
A, B, C yerine direkt guruplarına göre değerlerini aldığımız bir testimize bakalım. Burada kullanıcıları bedenlerini girmeye yönlendirdiğimiz alanda hangi cümle ile beden bilgilerini istersek daha iyi bir dönüş olur bunu test ediyoruz.
mySizeRequestSearch için kullanıcının grubuna göre yukarıdaki text değerleri dönüyor ve ilgili alana direkt onları setliyoruz.
Bu şekilde dinamik değerlerle yapılan testlerde yeni bir güncelleme çıkmadan sınırsız seçeneği test edebiliyoruz. Hatta biz değeri güncellediğimizde kullanıcı hiç uygulamayı kapatıp açmasa bile arka tarafta yeni değeri alıyoruz. Yukarıdaki 3 varyantın kazananıyla birlikte yeni cümleler ekleyerek sürekli sonucu iyileştirmeye gidebiliriz.
Feature toggle olarak değişkenleri kullanmak
Bu kısımda Dolap mobil ekibi olarak son zamanlarda uygulamaya başladığımız ve faydasını gördüğümüz bu yöntemden bahsetmek istiyorum. Yukarıda da bahsettiğimiz gibi A/B testleri yapabilmek için bir değişken listesi alıp değerlerine göre o kullanıcıya hangi varyantı göstereceğimize karar veriyoruz. Aslında feature toggle da bir değişken listesiyle çalışıyor. Biz de A/B test başlatmadan sadece değişken ekleyerek feature togglelar oluşturmaya başladık.
Yeni çıktığımız işlerde canlıda oluşabilecek veya sonradan fark edeceğimiz bir sorunda, ilgili özelliği parçalı olarak kapatabilmek için A/B test altyapısıyla(değişken listesine) bir Feature toggle ekliyoruz. Genelde bu toggleları özelliğin stabil çalıştığına emin olduktan sonra(~2 hafta) kaldırıyoruz.
Bu altyapıyı kullanmanın en büyük faydası çok detaylı bir şekilde toggle yönetebilmemiz sadece on/off değil parçalı olarak özelliği kapatabiliyoruz. Ayrıca Feature toggle kullanmak için ekstra bir geliştirme yapmamıza gerek olmaması.
Örneğin; Ürün yükleme adımında yeni eklediğimiz bir özellik belirli bir sürümümüzde, iOS 14 kullanan, iPhone 8 cihazlarda crashe ya da bir soruna sebep oluyor. Direkt bu koşulları sağlayan kitleyi hedefleyip ilgili özelliğimizi onlar için kapatabiliyoruz. Bu sayede fixlediğimiz sürüm yaygınlaşana kadar minimum kayıpla yola devam edebiliyoruz.
Kapanış
Bu yazıda A/B test terimini duyup bilip tam olarak nasıl uygulanırı kafasında oturtamayanları düşünerek gerçek hayattan örneklerle ilerledik. Biz Trendyol’da ve Dolap’ta A/B testi çok fazla kullanıyoruz ve faydalarını her gün görüyoruz. Nice güvendiğimiz özellikler kullanıcıdan kabul görmedi ve kaldırdık :) Bunları her gördüğümüzde iyi ki test etmişiz diyoruz.
Okuduğunuz için teşekkürler. Geribildirimlerinizi ve eğer varsa uyguladığınız güzel pratikleri yorumlara bekliyoruz.
Trendyol teknoloji ekibimize, birlikte güzel işler çıkartacağımız takım arkadaşları arıyoruz. Buradan iletişime geçebilirsiniz.
