Blog
Ajans A/B Testi Olgunluk Eğrisi: Sprintlerden Öğrenme Sistemine
Ajans A/B testi için pratik bir olgunluk modeli: hafif başlayın, test özetiyle standartlaştırın, karar değerine göre sıralayın ve bir öğrenme kütüphanesi oluşturun.
Özet
A/B testiyle ilgili tavsiyelerin çoğu herkese uyan tek bir süreç varsayar, ancak doğru deney titizliği ajansınız büyüdükçe değişir. Erken aşamada, süreç içinde boğulmadan müşteri güveni oluşturan hafif testlere ihtiyacınız var. Birden fazla hesabınız olduğunda, tek sayfalık basit bir test özeti ortak bir dil oluşturur ve 'daha iyi' kelimesinin ne anlama geldiği konusundaki tartışmaları önler. Portföy genişledikçe, kıt kaynak dikkat haline gelir, bu nedenle testleri karar değerine göre sıralamanız ve bir kararı değiştiremeyecek deneyleri sonlandırmaya istekli olmanız gerekir. Tam olgunlukta, gerçek varlık doğrulanmış desenlerden oluşan müşteriler arası bir öğrenme kütüphanesidir. Bu makale, her aşamayı pratik örneklerle ve aşama aşama bir karşılaştırmayla ele almaktadır.
Müşteriler için A/B testleri yürütmeyle ilgili tavsiyelerin çoğu, ister ilk deneyinizi gönderiyor olun ister yüzüncü deneyinizi, sürecinizin aynı görünmesi gerektiğini varsayar. Bu varsayım, herhangi bir istatistiksel hatadan daha fazla ajans CRO programını sessizce öldürür. Gerçek şu ki, olgun bir deney pratiği, geçici bir test sprint'ine pek benzemez; çünkü temeller değişmez, ancak etraflarındaki kısıtlamalar çarpıcı biçimde değişir. Tüm bunların merkezinde Wordstream'in tanımladığı dönüşüm hedefi vardır: istenen eylemi gerçekleştiren ziyaretçilerin yüzdesini artırmak. Değişen şey, ne kadar süreç, önceliklendirme ve kurumsal hafızayı taşımayı göze alabileceğinizdir. Aşağıda ajans testi için bir olgunluk eğrisi var: işiniz bunu yalnızca bir kez değil, tekrar tekrar çalıştırmak olduğunda neyi vurgulamanız gerektiğini gösteren dört aşama.
Birinci aşama: tek müşteri, tek test, birçok ders
Tek bir müşteriniz olduğunda ve geçmiş deney birikiminiz olmadığında yapabileceğiniz en kötü şey bir süreç oluşturmaktır. Bu aşamada şablon yoğunluklu bir iş akışı size geri döndüğünden daha fazla yük getirir. Tek gerçek işiniz görünür bir kazanım elde etmek ve neden olduğunu yazmaktır. İhtiyacınız olan ders "sürecimiz işe yarıyor" değil; "bu belirli desen, bu belirli davranışı etkiliyor gibi görünüyor" şeklindedir.
Somut bir örnek: ilk müşterinizin ev hizmetleri yüklenicisi olduğunu düşünün. Sitelerinde, neredeyse kimsenin ziyaret etmediği bir hakkında sayfasının altına gömülü tek bir iletişim formu var. Bir oturum kayıt aracı eklersiniz ve ziyaretçilerin geldiğini, hero görselinin yanından geçip gittiğini ve ayrıldığını görürsünüz. Basit bir hipotez oluşturursunuz: formu ana sayfanın üstüne, ne yaptıklarına dair tek cümlelik bir açıklamayla taşımak, tamamlanan iletişimleri artıracaktır. İki varyant oluşturur ve haftanın her günü her iki sürümde de temsil edilecek şekilde iki hafta boyunca yayınlarsınız. Görünür formun olduğu varyant kazanır. Neden işe yaradığını düşündüğünüze dair bir paragraf yazarsınız — yerleşim, tasarım değil — ve dosyalarsınız. Bu aşamadayken önemli olan disiplin kişisel triyajdır: bir ritüeli takip etmek yerine neyi test edeceğinizi bilmek. Bunu sınırlı zamanla yalnız başına yapmaya çalışıyorsanız, yalnız pazarlamacının triyaj listesi yararlı bir başlangıç noktasıdır.
İkinci aşama: iki müşteri, tek ortak dil
İkinci bir müşteri ekleyin ve örtük bilgi başarısız olmaya başlar. Artık bir yüklenicinin ana sayfasında ve bir e-ticaret ürün sayfasında testler yürütüyorsunuz. Deneyleri tanımlamanın ortak bir yolu olmadan, her kararı sıfırdan türetirsiniz ve dile getirilmemiş varsayımlar analizinize sızacaktır. Çözüm 14 sayfalık bir yönetişim belgesi değil; herhangi bir trafik harcamadan önce sizin ve müşterinin 'daha iyi'nin ne anlama geldiğini anlaşmanızı sağlayan tek sayfalık bir test özetidir.
İşte bu özetin küçük partili ürünler satan bir e-ticaret müşterisi için nasıl çalıştığı. Ürün sayfasında, "sepete ekle" düğmesinden önce birden çok ürün görseli ve uzun bir açıklama vardı. Özetinizin altı alanı var. Mevcut davranış: ziyaretçiler yaklaşık üç görsel aşağıda kaydırmayı bırakıyor; çok azı düğmeye ulaşıyor. Hipotez: bir hero görseli ve bir paket görseli göstermek seçim sürtünmesini ortadan kaldırır ve daha fazla ziyaretçiyi düğmeye yönlendirir. Birincil metrik: sepete ekleme oranı. Emniyet şeridi: oturum başına gelir düşmez. Minimum çalışma süresi: on dört gün. Karar kuralı: sepete ekleme artarsa ve gelir sabit kalırsa yayınla. Bunu doldurmak on beş dakika sürer ve bir testin "işe yarayıp yaramadığı" konusunda tartışarak geçireceğiniz bir haftadan tasarruf ettirir. Ne yapmadığınıza dikkat edin: henüz örneklem büyüklüğünü veya anlamlılık eşiklerini tartışmıyorsunuz. Düşük trafiğe sahip bir müşteri için tam bir istatistiksel çerçeve genellikle gereksizdir — düşük trafik oyun kitabı yönlü kanıtın ne zaman yeterli olduğunu gösterir.
Ölçeklendikçe odak değişir
| Olgunluk aşaması | Ana işiniz | Süreç ağırlığı | En büyük risk |
|---|---|---|---|
| Tek seferlik sprintler | Hızlı kazanımlarla müşteri güveni oluşturun | Olabildiğince hafif | Veriye sahip olmadan önce aşırı mühendislik |
| Standartlaştırılmış test | Ortak bir dil oluşturun | Test başına tek sayfalık özet | Öğrenme olmadan bürokrasi |
| Portföy yönetimi | Karar değerine göre sıralayın | Haftalık triyaj | Önemi olmayan testleri çalıştırmak |
| Öğrenme sistemi | Bulguları hesaplar arasında yeniden kullanın | Belgelenmiş desen kartları | Her müşteri için tekerleği yeniden icat etmek |
Üçüncü aşama: test kuyruğu bir iş kararıdır
Bu alandaki en yaygın tavsiye, her seferinde bir değişkeni test etmek ve her testin doğal seyrini tamamlamasına izin vermektir. Portföy ölçeğinde bu sadece yavaş değil; aktif olarak israflıdır. Artık işiniz mümkün olduğunca çok deney yürütmek değil. Yürüttüğünüz her deneyin bir kararı değiştirebilme kapasitesine sahip olduğundan emin olmak. Sonucu her iki şekilde de göz ardı edeceğiniz bir test, bir haftalık trafik tüketmeden önce durdurulmalıdır. Bu, yalnızca rapor üreten ajansları öğrenme üreten ajanslardan ayıran aykırı dönüştür.
Diyelim ki artık beş müşteriniz var. Biri fiyatlandırma sayfasında başlık değişimi istiyor; diğeri bir onboarding akışında daha kısa bir form istiyor; üçüncüsü bir ürün sayfasında güven rozetini taşımak istiyor. Üçünü de yürütürseniz, her Cuma panolara bakıp toplantı planlayarak geçirirsiniz. Bunun yerine, her fikri erişim (değişikliği kaç ziyaretçinin gördüğü), güven (kazanacağına dair önsel inancınız ne kadar güçlü) ve çaba (oluşturmak ve test etmek ne kadar sürer) üzerinden puanlarsınız. Güven rozetini seçersiniz: orta erişim, yüksek güven, iki dakikalık iş. Test çalışır, dönüşüm metriği doğru yönde hareket eder ve yayınlarsınız. Başlık değişimi hâlâ iş birikiminizde — bu hafta beklenen karar değerinin rozetinkinden daha düşük olduğunu fark ettiniz. Ayrıca, düşük trafikli bir sayfada anlamlılığa ulaşması sekiz hafta sürecek bir testi de emekliye ayırırsınız; yüklenicinin önceki testinden yerleşimin davranışı değiştirdiğini biliyorsunuz, bu yüzden değişikliği yayınlar ve bunun yerine izlersiniz. Bu bir titizlik kaybı değil; bir testi ne zaman durduracağınızı bilmektir.
Dördüncü aşama: öğrenme kütüphaneniz ürün hâline gelir
Hesaplar genelinde bir düzine veya daha fazla deneyi yönettiğinizde, bileşik büyüyen varlık testlerin kendisi değil — hangi müdahalelerin nerede ve hangi koşullar altında işe yaradığına dair biriktirdiğiniz nedensel bilgidir. Bu bilgiyi aktif olarak belgelemez ve yapılandırmazsanız, her yeni müşteri için aynı öğrenme maliyetini ödemeye devam edersiniz. Yapay zekâ destekli deneyciliğin gerçekten ilginç hâle geldiği yer de burasıdır; çünkü size kazananları bulmayı vaat etmez, hipotezler taslağı oluşturmanıza ve sonuçlardaki desenleri fark etmenize yardımcı olabilir — yeter ki siz muhakeme yapın.
Bir örnek: iç kütüphanenizde artık "Form alanı azaltma, form katlama çizgisinin altında olduğunda tamamlanmayı artırır; form zaten katlama çizgisinin üstündeyse gözlemlenebilir bir etkisi yoktur" yazan bir kart var. Kartın sınır koşulları, bu durumun hizmet sitelerinde ve bir SaaS onboarding akışında test edildiğini, ancak çok adımlı ödeme akışında test edilmediğini söylüyor. Sekiz alanlı bir iletişim formu olan yeni bir müşteri görüş istediğinde, sıfırdan değil, o karttan başlarsınız. Hipoteziniz şu: dört alana düşürün ve formu katlama çizgisinin üstüne taşıyın. Yerleşim testini yeniden çalıştırmayla uğraşmazsınız — bu desen zaten kütüphanenizde. Yalnızca alan azaltmayı yürütürsünüz ve müşteriye bu deneyin tam olarak hangi önceki kanıta dayandığını söyleyebilirsiniz. Uyarı: desenler aktarılır, ancak belirli metin ve tasarım nadiren aktarılır. Yüklenici için kazanan başlık, bir e-ticaret sitesinde yanlış hissettirebilir. Aktarılan şey mekanizmadır: eylem noktasındaki sürtünmeyi azaltmak. Kartınızda tam kelimeleri değil, mekanizmayı tutun.
Bu, tüm pratiğin mihenk taşıdır. Buraya geldiğinizde, dönüşüm sağlayan testlere öncelik vermek ikinci doğanız hâline gelir ve kütüphaneniz her yeni hesabın onboard'unu daha ucuz hâle getirir.
Eğer tek bir fikir çıkaracaksanız, şu olsun: sürecinizin portföyünüzle aynı oranda büyümesine izin verin. Muhakeme ve tek bir görünür kazanımla başlayın. İkinci müşteri ortaya çıktığında tek sayfalık bir özet ekleyin. Her şeyi yürütemediğinizde test kuyruğuna bir portföy kararı olarak yaklaşın. Ve kaybetmek acıtmadan önce bir öğrenme kütüphanesine yatırım yapın. CRO'da kazanan ajanslar nadiren en gelişmiş istatistiksel makinelere sahip olanlardır; onlar "ne öğrendik?" sorusuna en net cevapları verenlerdir. Bir A/B testi, yayınlanıp unutulacak bir çıktı değildir. Gerçekten yönetebildiğiniz koşullar altında bir kez sorduğunuz bir sorudur — ve sonra bir sonraki müşteriyle daha iyi sorarsınız.
