Müşteri Geçirmez A/B Test Çerçevesi: Her Hesapta İşe Yarayan 7 Adım

Özet

Ajanslar, tek ürün ekiplerine kıyasla daha zorlu koşullar altında A/B testleri yürütür: birden fazla müşteri, sıkı teslim tarihleri ve dağınık metrikler. Bu makale, tek bir gerçek dönüşüm hedefi tanımlamaktan başlayarak her hesapta işe yarayan tekrarlanabilir bir çerçeve sunuyor. Paydaş görüşlerinin peşinde koşmak yerine sürtünme noktalarını nasıl bulacağınızı, öngörücü hipotezler yazmayı ve tek değişkenli, çok değişkenli ve yapay zeka destekli deneyler arasında seçim yapmayı öğreneceksiniz. Pragmatik örneklem boyutu planlamasını, müşterilerin bir testi erken öldürmesini nasıl önleyeceğinizi ve belirsiz sonuçları bir danışman gibi nasıl okuyacağınızı kapsar. Son adım, her kazancı ve başarısızlığı, bir sonraki müşterinin test döngüsünü hızlandıran bir oyun kitabında paketlemektir. Bu yapıyı kullanarak boşa harcanan haftaları kesin ve testi ajansınız için rekabet avantajına dönüştürün. Testi bir dizi tek seferlik istek yerine bir sistem olarak ele aldığınızda, her hesapta tekerleği yeniden icat etmeyi bırakırsınız.

Pazartesi, 09:47. Bir müşteri, fiyatlandırma sayfalarında “hızlı bir A/B testi” isteyen bir e-posta gönderiyor. Üç başka hesabınız daha havada; her birinin farklı bir analitik kurulumu, farklı bir onay zinciri ve farklı bir “kazanma” tanımı var. Hızlı testin istatistiksel anlamlılığa ulaşması üç hafta sürecek. Bunu zaten biliyorsunuz. Bu yüzden zaman çizelgesini uzatıyor, beklentileri belirliyor ve testi çalıştırıyorsunuz. Sonra haftanızın yarısını onu savunmakla geçiriyorsunuz.

Bu bir test sorunu değil. Bu bir sistem sorunu. Her müşteri için nasıl test edeceğinizi yeniden icat etmek zorundaysanız, bir optimizasyon ortağı değilsiniz — bir test uygulayıcısısınız. Aşağıda, her müşteride, her araçta ve her trafik seviyesinde çalışan yedi adımlık bir çerçeve var. Bunu kullanarak, hesaptan hesaba birleşen daha hızlı ve daha akıllı test döngüleri elde edin.

1. Bir değişkene dokunmadan önce başarı metriği belirleyin

Optimizely sözlüğünde tanımlandığı gibi A/B testi, hedef kitlenizi rastgele böler ve her gruba bir sayfanın farklı bir sürümünü gösterir. Bu rastgele bölme veri üretir. Ancak veri, yalnızca neyi ölçtüğünüzü biliyorsanız anlam ifade eder. Çoğu müşteri “daha fazla dönüşüm” istediğini söyler — ancak dönüşümler kayıt, satın alma, demo talebi ve hatta alt bilgiye kaydırma olabilir. Tek bir metrik belirlemezseniz, getirdiğiniz her sonuç yeniden yorumlanmaya açık olacaktır.

Her etkileşime 15 dakikalık bir hedef denetimiyle başlayın. Müşteriye sorun: “Hangi tek eylem, ikiye katlanırsa bu çeyreği başarılı kılar?” Sonra bu yanıtı birincil metriğe dönüştürün. Bunu testin başarı kriteri olarak kullanın. Diğer her şey — hemen çıkma oranı, sayfada geçirilen süre, ikincil tıklamalar — izlediğiniz ancak optimize etmediğiniz bir emniyet metriği haline gelir.

Acımasızca spesifik olun. Müşteri “müşteri adayı” derse, müşteri adayının ne olduğunu tanımlayın. Bir müşteri adayı form gönderimi olabilir, ancak telefon görüşmesi, canlı sohbet veya indirme de olabilir. Her tanım, hangi sayfa öğesini test etmeniz gerektiğini değiştirir. Form gönderimi hedefi sizi form uzunluğuna ve sürtünmeye yönlendirir. Telefon görüşmesi hedefi, optimizasyonunuzu tıkla-ara yerleşimine ve güven sinyallerine odaklar. Başlangıçta bu konuda anlaşmazsanız, yanlış sayfayı optimize edersiniz.

Çalışılmış örnek: Bir B2B müşterisi “daha fazla müşteri adayı” istiyor. Müşteri adayının ne olduğunu soruyorsunuz. “Kalifiye potansiyel müşteriler” diyorlar. Bu izlenemez. Bunu “iş e-posta adresine sahip form gönderimleri” olarak daraltıyorsunuz. Artık birincil bir metrik var. Daha sonra yeni bir kahraman başlığı test ettiğinizde, bunu yalnızca bu metriğe göre değerlendireceksiniz. Ayrıca daha iyi bir hemen çıkma oranına dayanarak zafer ilan etme girişimlerini de yakalayacaksınız. Bu netlik sizi saatlerce süren tartışmalardan kurtarır.

Birincil metriğiniz olduğunda, bunu test özetine yazın. Özet tek cümleyle “Bu test [metrik] ile değerlendirilecektir” demelidir. Bunu her paydaşla paylaşın. Bir yönetici daha sonra “ama etkileşim arttı” derse, özeti işaret edersiniz. Kaleyi taşımadınız. Onlar üzerinde anlaştınız.

Ayrıca sinyali gürültüden ayırdığınız yer burasıdır. Hangi testlerin en önemli olduğunu bilmek savaşın yarısıdır. Bütçenizi geliri hareket ettirme olasılığı en yüksek testlere harcamak, bir ajansı verimli kılan şeydir.

2. Tercihleri değil, sürtünmeyi avlayın

Müşteriler size “çalıştırmak istediğimiz testler” listesi verecek ve bunlar aslında görüşlerdir. “Buton yeşil olmalı.” “Başlık ödülümüzden bahsetmeli.” Bunları çalıştırmazsınız. Sürtünmeyi azaltan veya güveni artıran testleri çalıştırırsınız. CRO oyun kitaplarının tümü aynı kaldıraçlara işaret eder: harekete geçirici mesaj netliği, form uzunluğu, düzen netliği, sosyal kanıt ve güven sinyalleri.

Bu kaldıraçları, müşterinizin kullanıcılarının nerede bıraktığına bakarak bulun. Zaten yoksa oturum kayıtları veya temel olay takibi kurun. Müşteri başına en az beş gerçek kullanıcı oturumu izleyin. Müşterinin “kullanıcıların ne seveceği” hakkındaki görüşüne güvenmeyin. Veri görüşten üstündür.

Denetlenecek yaygın sürtünme kaynakları:

• Çok fazla veya çok az bilgi isteyen formlar
• Sonraki eylemi açıkça belirtmeyen CTA’lar (ör. “Daha Fazla Bilgi” vs. “Ücretsiz Denemeye Başla”)
• Taahhüt noktası yakınında eksik güven ipuçları (referanslar, garantiler, para iade teklifleri)
• Mobilde yavaş yüklenen sayfalar
• Sürpriz ekstra adım içeren yolculuklar (ör. uyarı vermeden “kayıt” ardından “e-postayı doğrula”)

Çalışılmış örnek: Bir e-ticaret müşterisinin ödeme sayfasında 6 alanlı bir form ve isteğe bağlı bir “hesap oluştur” onay kutusu var. Bir oturum kaydı kuruyor ve beş kullanıcı izliyorsunuz. İkisi, indirim uygulayacağını düşündükleri için önceden doldurulmuş kupon kodunu silmeye çalışıyor. Biri telefon numarası alanında vazgeçiyor. Sürtünme formun uzunluğu değil; kafa karıştıran kupon alanı. Testiniz butonu büyütmüyor. Kupon alanını son inceleme adımına taşıyor. Bu, görüşten değil gözlemden doğan bir test.

Bunu birden fazla müşteri arasında yapmak için paylaşılan bir sürtünme günlüğü oluşturun. Bir kullanıcı bir müşterinin sitesinde takıldığında, deseni not edin. Aynı sürtünmenin üç hafta sonra farklı bir müşterinin sitesinde ortaya çıktığını göreceksiniz. Bu, ajansınızın özel araştırma kütüphanesidir. Aynı zamanda yeni bir müşteriye güçlü bir satış konuşmasıdır: “Bu sorunu tam olarak sizin pazar segmentinizde gördük.”

Sadece site içi davranışla yetinmeyin. Çıkış yollarına, ısı haritalarına ve form alanı analitiğine bakın. Amaç, kullanıcıların düştüğü tek net bir nokta bulmaktır. Bu nokta sizin test değişkeninizdir. Net bir düşüş bulamazsanız, tanısal bir test çalıştırın: kökten farklı bir CTA, çok daha kısa bir form veya radikal biçimde farklı bir değer önerisi deneyin. Sonuç, boş bile olsa, kitlenin gerçek direncinin nerede olduğunu söyler.

Sürtünme günlüğünü güncel tutun. Yinelenen bir desen fark ettiğinizde, bir ekran görüntüsü ve tek satırlık bir açıklamayla günlüğe not edin. Birkaç ay sonra, hizmet verdiğiniz her müşteriye uygulanabilecek bir kullanıcı itirazları kataloğuna sahip olacaksınız. Bu katalog bir satış noktasıdır: “Bu itirazı zaten sizin sektörünüzde test ettik. İşte öğrendiklerimiz.”

3. Ne değil, neden öngören bir hipotez yazın

İyi bir test bir soruyu yanıtlar: “X yaparsak, Y olur, çünkü Z.” “Çünkü Z” hipotezdir ve sonucu taşınabilir yapan şeydir. Bir “neden” olmadan kazanan bir test, bir sonraki müşteri hakkında size hiçbir şey söylemez.

Her testi “Eğer... ise... çünkü...” yapısıyla formüle edin. Bu sizi mekanizma hakkında düşünmeye zorlar. “Formu 5 alandan 3 alana kısaltın” ifadesi, “Formu kısaltırsak, tamamlanma oranı artar, çünkü kullanıcılar daha az çaba algılar” haline gelir. Artık nedenini biliyorsunuz. Bu kuralı uzun formu olan herhangi bir müşteriye aktarabilirsiniz.

Şimdi uyarı. Yaygın en iyi uygulama, aynı anda tek bir değişkeni test etmenizi söyler. Bu kural iyi bir nedenden dolayı vardır: izole değişkenler temiz nedensel açıklamalar sağlar. Ancak ajanslar nadiren yirmi ayrı tek değişkenli testi çalıştıracak trafiğe veya aylara sahiptir. Düşük trafikli hesaplar için bir takas gerekir. Üç seçeneğiniz var.

Yaklaşım	En iyi olduğu durum	Takas
Tek değişkenli test	Yüksek trafikli sayfa, tek hipotez, zaman mevcut	En temiz nedensel hikaye, yavaş
Çok değişkenli test	Orta trafik, birkaç bağımsız değişken	Daha hızlı, ancak karıştırılmış etkileşimler
Yapay zeka destekli deney	Düşük trafik, sıkı teslim tarihi, makinenin uyum sağlamasını istiyorsunuz	Daha yeni araçlar, varyantlar üzerinde daha az kontrol

Üçüncü seçenek ciddiye alınmayı hak ediyor. Optimizely’nin yapay zeka deneyleri açıklayıcısı, trafiği dinamik olarak dağıtan ve sizin için varyantlar üreten makine öğrenimi sistemlerini anlatıyor. Sabit bir bölünme ayarlayıp beklemek yerine, sistem hangi varyantın kazandığını öğrenir ve trafiği gerçek zamanlı olarak ona kaydırır. Bu, iki haftalık bir testi birkaç güne sıkıştırabilir — bazı metodolojik saflık pahasına. Son teslim tarihi olan bir ajans için genellikle ödenmesi gereken doğru bedeldir.

Müşterinize hangi yolun uyduğundan emin değil misiniz? Klasik ve yapay zeka destekli testler arasındaki takasları taahhüt etmeden önce anlamak faydalıdır.

İşte nasıl karar vereceğiniz: müşterinin bol trafiği ve açık bir zaman çizelgesi varsa, tek değişkenli bir test kullanın. Orta trafiği ve birkaç aday değişikliği varsa, en umut verici kombinasyonlarla çok değişkenli bir test çalıştırın. Düşük trafiği ve kesin bir teslim tarihi varsa, uçuş sırasında uyum sağlayabilen yapay zeka destekli bir deney seçin. “Gerçek bilim” tercihinizin müşterinin iş kısıtlarını görmenizi engellemesine izin vermeyin. Doğru test, bütçe buharlaşmadan önce harekete geçebileceğiniz bir karar üreten testtir. Müşterinin kampanyası bittikten sonra biten mükemmel güçlü bir test değersizdir.

Çalışılmış örnek: Yerel bir hizmet müşterisi mütevazı günlük trafik alıyor. Kendi başınıza tek değişkenli bir test çalıştırmak, anlamlı bir farkı tespit etmek için aylar alırdı. Bir hipotez yazıyor, ardından trafiği dinamik olarak dağıtan bir yapay zeka deneyi kullanıyorsunuz. Birkaç gün sonra sistem bir varyantın öne geçtiğini gösteriyor ve ona daha fazla trafik yönlendiriyor. Müşterinin kampanya penceresi içinde bir cevap alıyorsunuz. Sonucun, altı haftalık klasik bir testten istatistiksel olarak daha az saf olduğunu kabul ediyorsunuz. Bu rasyonel bir takas, bir uzlaşma değil.

Ayrıca, tek bir düğme yerine radikal yeni bir sayfa bölümü test ediyorsanız “aynı anda tek değişken” kuralının gevşetilebileceğini unutmayın. Tam sayfa yeniden tasarım testi birden çok öğeyi değiştirebilir, ancak hipotez yine de tutarlıdır: “Faydalara öncelik veren metin etrafında oluşturulmuş bir düzen, mevcut özellik listesi düzeninden daha iyi performans gösterir, çünkü kullanıcılar sonuçlara göre seçim yapar.” Hipotez mekanizmayı adlandırdığı sürece, bir değişiklik grubunu test edebilirsiniz. Sadece müşteriye hangi öğenin artışa neden olduğunu bilemeyeceğinizi dürüstçe söyleyin.

4. Testi istatistik ders kitabınıza göre değil, müşterinin takvimine göre boyutlandırın

İstatistiksel anlamlılık 21. günde açtığınız sihirli bir sayı değildir. Temel dönüşüm oranınıza, görmeniz gereken minimum artışa ve teste yönlendirebileceğiniz trafik miktarına bağlıdır. Bu alandaki her test rehberi aynı uyarıyı tekrarlar: yeterli örneklem boyutu ve süreye ulaşana kadar testi çalıştırın, aksi takdirde sonucunuz gürültüdür.

Testi planlamadan önce matematiği sade dille yapın. Müşterinin mevcut dönüşüm oranını ve önemsediğiniz en küçük iyileştirmeyi tahmin edin. Ardından makul bir güven düzeyi için kaç ziyaretçiye ihtiyacınız olacağını tahmin edin. Bu sayı, müşterinin üç aylık değerlendirmesinden önce ulaşılamayacaksa, üç seçeneğiniz var: trafik bölünmesini genişleterek teste daha fazla kişi gönderin, trafiğinizin destekleyebileceği daha büyük bir minimum tespit edilebilir etkiyi kabul edin veya testi “kazanan” vaat edilmeyen bir öğrenme deneyine çevirin.

Bunu yapmak için doktoraya ihtiyacınız yok. Bir örneklem boyutu hesaplayıcısı kullanın. Temel oranı, tespit etmek istediğiniz etkiyi ve istediğiniz güveni girin. Araç, varyant başına kaç ziyaretçiye ihtiyacınız olduğunu söyler. Ardından gereken çalışma süresini elde etmek için müşterinin beklenen günlük test trafiğine bölün. Bu çalışma süresi müşterinin teslim tarihine uymuyorsa, testi başlatmadan önce girdilerden birini ayarlayın. Bu konuşma, boşa harcanmış üç haftalık bir döngüden çok daha ucuzdur.

Çalışılmış örnek: Bir SaaS müşterisinin deneme kayıt sayfası mütevazı ama istikrarlı bir ziyaretçi akışı alıyor. Anlamlı bir iyileştirme tespit etmek istiyorsunuz ve örneklem boyutu tahmininiz, testin müşterinin trafiğinin mevcut sürede teslim edebileceğinden çok daha fazla ziyaretçiye ihtiyaç duyacağını söylüyor. Müşterinin yönetim kurulu toplantısı için altı hafta içinde bir cevaba ihtiyacı var. Bu yüzden bölünmeyi 50/50’den 90/10’a genişletiyorsunuz — ancak bu yine de yeterli olmayacak. Bunun yerine, yalnızca büyük kazanımları yakalamak için minimum tespit edilebilir etkiyi düşürüyorsunuz. Artık test zaman dilimi içinde uygulanabilir ve müşteriye testin neyi yakalayıp neyi yakalayamayacağını tam olarak söylediniz. Profesyonel hamle budur.

Ayrıca bir durdurma kuralına ihtiyacınız var. Testin ne kadar süreceğine ve hangi anlamlılık eşiğini kullanacağınıza önceden karar verin. Takvim tarihinin tek durma nedeniniz olmasına asla izin vermeyin. Ne zaman erken durdurulacağını veya uzatılacağını bilin — bu atışı keyfi bir Cuma değil, sizin yargınız yapmalıdır.

5. Müşterinin testi erken öldürmesini önleyin

Burada yaşadığınız bir sahne var: Salı günü ve müşteri “Test bu sabah başladı. Hadi kazananı hemen yayınlayalım” diye mesaj atıyor. Önde olan bir varyantınız var, ancak yalnızca gereken örneklem boyutuna ulaştınız. Müşteriniz bir kazanç görüyor. Siz gürültü görüyorsunuz. Ajans testlerinin başarısız olmasının en yaygın nedeni budur — kötü matematik değil, kötü paydaş yönetimi.

Test başlamadan önce temel kuralları belirleyin. Birincil metriği, planlanan örneklem boyutunu, sonuçlara bakacağınız en erken tarihi ve çalışma sırasında değiştirmenize izin verilenleri belirten tek sayfalık bir test özeti gönderin. Müşterinin onayını alın. Baktıklarında, bu bir beklenti ihlali olur ve işaret edebilirsiniz; kişisel bir reddetme değil. Bu, düşmanca olmakla ilgili değil; deneyin bütünlüğünü korumakla ilgilidir.

Ayrıca, test ortamını koruyun. Müşteriye test çalışırken başka hiçbir site değişikliğinin yayınlanmaması gerektiğini söyleyin. Test sayfasında bir kesinti duyuran bir banner, başka bir satıcıdan son dakika tasarım değişikliği veya hatta bir sosyal medya artışı verilerinizi kirletebilir. Testinizin dışında bir şey değiştiği anda, sonuç şüphelidir.

Çalışılmış örnek: Bir müşterinin geliştiricisi, testin ortasında yeni bir favicon yayınlar. Önemli olmamalı, ama olmamalı da. Bunu günlüğe kaydediyor, zaman damgasını not ediyor ve sonuçların bu noktadan sonra değişip değişmediğini kontrol ediyorsunuz. Değişirlerse, testi yeniden başlatırsınız. Müşteriler genellikle bunun ne kadar kırılgan olduğunu anlamaz. Sizin işiniz, bunu test özetinde açıkça belirtmek, böylece ciddiye almalarını sağlamaktır.

Bir diğer yaygın müşteri hamlesi, “kampanyayı Cuma günü başlatmamız gerekiyor, testi erken bitirebilir misin?” olur. Kampanya testin kendisine müdahale etmedikçe direnin. Erken bitirirseniz, yanlış karar verme riskiniz olur. Bunun yerine, kampanyanın biraz ertelenip ertelenemeyeceğini veya testin kampanyadan etkilenmeyen bir sayfaya taşınıp taşınamayacağını görün. Test özetiniz müzakere aracınızdır. Kibarca ama kararlı bir şekilde reddetmek için kullanın.

Bir alışkanlık daha: teknik bir başarısızlık aramıyorsanız, test sırasında sonuçları asla kontrol etmeyin. İnsan beyni olasılık konusunda berbattır. Bir dizi iyi gün kanıt gibi hissettirir, ancak genellikle sadece gürültüdür. Bakmak isterseniz, bunun yerine örneklem boyutu hesaplayıcısını açın. Hâlâ ne kadar verinin eksik olduğunu kendinize hatırlatın.

6. Sonucu bir karar değil, bir hikaye olarak okuyun

Test biter. Varyant yine kazanır. Ancak “hangi buton kazandı” öğrendiğiniz en az yararlı şeydir. Yararlı sorular şunlardır: Neden kazandı? Bu açıklama diğer sayfalara uygulanıyor mu? Bu kitle hakkında daha önce bilmediğimiz ne keşfettik?

Çoğu ajansın durduğu nokta burasıdır. Kazanan varyantı yayınlarlar, müşteriye PDF gönderirler ve yollarına devam ederler. Bu kaçırılmış bir fırsattır. Boş bir sonuç — varyantın kontrolü geçemediği durum — yine de bir sonuçtur. Kitlenin bu değişkeni umursamadığını veya orijinalin zaten yeterince iyi olduğunu söyler. Bu öğrenmeyi belgeleyin ve bir sonraki teste uygulayın. En iyi uygulama kılavuzları, her deneyden sonra öğrenimlerin belgelenmesini tutarlı bir şekilde vurgular; testi bir dizi tek seferlik deneyden birleşik bir varlığa dönüştüren şey budur.

Çalışılmış örnek: Fotoğraflı bir referansı düz bir alıntıya karşı test ediyorsunuz. Düz alıntı kazanıyor. Nedenini araştırıyorsunuz. Görüntü sahte görünüyor; müşterinin kitlesi şüpheci. Ders “referanslar işe yaramaz” değil. “Bu kitle otantik, atıfsız kanıt ister, cilalı kareler değil.” Gelecek ay farklı bir müşteri sosyal kanıt hakkında soruyor. Onlara ne göstermeyeceğinizi zaten biliyorsunuz. Sonuçları hikaye gibi okumanın ROI’si budur.

Bir sonucu yorumlamak yalnızca p-değerini kontrol etmek değildir. Yöne, büyüklüğe ve segment farklılıklarına bakmaktır. Gördüğünüze güvenip güvenemeyeceğinizden emin değilseniz, temellere geri dönün. A/B test sonuçlarını gürültüye kanmadan doğru yorumlama kılavuzu sizi dürüst tutacaktır.

Ayrıca “ne olmuş yani” testini de düşünün. Metriği müşterinin diline çevirin. Küçük bir tabandaki büyük bir göreli artış neredeyse hiç gelire dönüşmeyebilirken, yüksek trafikli bir sayfadaki küçük bir artış büyük kazançlar anlamına gelebilir. Göreli değişimin mutlak değeri görmenizi engellemesine izin vermeyin. Müşteri güven aralığını değil, alttaki sayıyı önemser.

Boş bir sonuç sunduğunuzda özür dilemeyin. Bunu bir veri noktası olarak çerçeveleyin. “Başlık uzunluğunun bu kitle için dönüşümü değiştirmediğini öğrendik. Bu, bu testi tekrar çalıştırmaktan bizi kurtarır.” Boş bir sonuç, bir soruya verilen temiz bir yanıttır. Bu bir başarısızlık değil.

7. Her sonucu tekrarlanabilir bir kurala dönüştürün

Şimdi son adım ve test yapan bir ajansı ona bahis oynayan bir ajansdan ayıran adım. Her testten sonra tek sayfalık bir oyun kitabı girişi yazın. Tutarlı biçimlendirin: müşteri türü, hipotez, sonuç, öneri. Herkesin arayabileceği bir yerde saklayın. Ardından, herhangi bir yeni testi çalıştırmadan önce, benzer bir durum için oyun kitabını arayın. Genellikle, yeniden öğrenmek üzere olduğunuz şeyi zaten öğrendiğinizi göreceksiniz.

Test, bir ajans için rekabet avantajı haline gelir böylece. Müşteri A’nın “kupon alanı kafa karıştırıcı” bulgusu, Müşteri B’nin ödeme sayfası için aynı hatalı testi tasarlamaktan sizi kurtarır. Müşteri C’nin “referanslar göstergeyi değiştirmiyor” bulgusu, başka bir şeyi test etmenizi sağlar. Oyun kitabı gerçekte sattığınız varlıktır, raporlar değil.

Oyun kitabı girişi için kontrol listesi:

• Müşteri sektörü ve site türü
• Test sayfası ve test edilen değişken
• “Eğer... ise... çünkü...” biçimindeki hipotez
• Birincil metrik sonucu: kazanç, kayıp veya boş
• Üzerinde anlaştığınız “neden” açıklaması
• Yeni bir müşteride tekrarlayacağınız bir eylem
• Bir daha asla denemeyeceğiniz bir eylem

Çalışılmış örnek: Bir fitness uygulaması müşterisi, tek e-posta alanlı bir ücretsiz deneme formunu, ad-ve-e-posta formuna karşı test ediyor. Tek alanlı sürüm küçük ama tutarlı bir kazanç sağlıyor. Oyun kitabı girişini yazıyorsunuz: “Dürtü odaklı kitleler (fitness, yiyecek) için gerekli alanları erken aşamada en aza indirin; kişisel ayrıntıları daha sonra toplayın.” Altı hafta sonra, bir yemek kutusu müşterisi uzun kayıt formlarını soruyor. Oyun kitabı girişini çıkarıyor, aynı azaltmayı öneriyor ve olası sonucu zaten bildiğiniz için testi güvenle çalıştırıyorsunuz. Birleşik etki budur.

Son olarak, ekibinizle aylık bir “öğrenme incelemesi” yapın. Tüm müşterilerde öğrendiklerinizi gözden geçirin. Aynı temel ilkeye işaret eden girişleri birleştirin. Bu ilkeleri gelecekteki testler için yönergelere dönüştürün. Örneğin, iki farklı müşteri tek alanlı bir formla daha yüksek dönüşüm gördüyse, “taahhüde kadar minimum bilgi isteyin” ilkesi muhtemelen segmentleri arasında doğrudur. Bu ilke artık her yeni müşterinin açılış sayfası önerisini, test çalıştırmadan önce bile bilgilendirir.

Çerçeve çalışıyor. Ama yalnızca sistemi gerçekten kurarsanız çalışır. Bir müşteriyle başlayın. Yedi adımın tümünü uygulayın. Sonra bunları bir sonraki müşteriye uygulayın ve oyun kitabının işin giderek daha fazlasını yapmasına izin verin. “Ne test etmeliyiz?” diye sormayı bırakıp “Burada hangi bilinen kural geçerli?” diye sormaya başlayacaksınız. Test yapan bir ajans ile daha iyi sonuçlar ortaya koyan bir ajans arasındaki fark budur.