Ciddi Deney Programları Yürütmek için Gereksinimler

Deney programları yürütmek bir sanat ve bilimdir. Her zaman söylüyorum. Programlar belirli bir düzeyde titizliğe sahip olmalıdır - yani sistemler, süreçler ve prosedürler. Hafife alınacak bir şey değil. Herkesin minimum hazırlık ve planlama ile yarın bir programa başlayabileceğine inanmak bir hatadır. Ne yazık ki, yine de, bu her zaman olur. Şaşırtıcı olmayan bir şekilde çok fazla para, zaman ve çabanın boşa gitmesine yol açar. Bu beni hazırlık konusuna götürüyor.

Deney yapma konusunda ciddi olmak ve pazarda ne kadar rekabetçi olduğunuzu yükseltmek istiyorsanız, bunu iyi yapıyor olsanız iyi olur. Rakiplerinizin bunu iyi yaptığını varsaymalısınız. Yani bu size hitap ediyorsa, okumaya devam edin ve hemen kullanmak üzere bir veya iki altın külçe alacağınızı garanti ederim.

Sizi başarılı ya da başarısız kılacak bir deney programı oluşturmanın kaçınılmaz habercisi: Ön test hesaplamaları

Ön test hesaplamaları. Onları hiç duydun mu? Onları yaptın mı? MDE veya minimum algılanabilir etki tanıdık geliyor mu? Süre tahminleri veya örneklem büyüklükleri hakkında ne düşünüyorsunuz? Umarım neden bahsettiğimi anlamışsınızdır, ancak büyük bir çoğunluğunuzun anlamadığına bahse girerim – sırf müşterilerle olan kendi kişisel deneyimlerim yüzünden.

Deneyle ilgili herhangi bir şey yapmadan önce, lütfen bunu yapmak için yeterli veri hacminiz olup olmadığına bakın. Test öncesi hesaplamalar yoluyla hiç test yapıp yapamayacağınıza bakın. Veri hacmi derken ziyaretçileri ve dönüşümleri kastediyorum. Ziyaretçiler, genellikle kullandığınız her şey olabilir (ör. oturumlar, kullanıcılar, MAU'lar vb.). Dönüşümler, testlerinizde kullanacağınız birincil metrikten alınır. Bunu bil:

1. Her işletme, herhangi bir kapasitede deney yapmak için yeterli veri hacmine sahip değildir.
2. Yapabiliyorsanız, istediğiniz hızı havadan seçmediğinizi bilin. Hesaplamalara dayalıdır.

Bu noktalardan birini veya her ikisini göz ardı etmenin 1 numaralı suçlusu: satış elemanları. Herhangi bir araç satın almayı düşünüyorsanız, bunun konuşmanın bir parçası olduğundan emin olun. Bir deney programına sahip olmak için minimum giriş engeli: bir kulvarda sekiz veya daha az hafta içinde bir test yapmak için yeterli veri hacmi.

Bu konuyu birkaç ay önce Deney Ulusu için ayrıntılı olarak ele aldım. Bilin ki, bu konuyu anlamazsanız ve ilk günden itibaren yaparsanız, bu sizi rahatsız edecek ve sonunda kesinlikle istenmeyen sonuçlara yol açacaktır. Çok önemli bir not daha: test aracınızın (veya kullanmayı planladığınız aracın) sabit ufuk testine mi yoksa sıralı teste mi dayalı olduğunu bilin. Bu, hesaplamaları ve programınızı nasıl çalıştırdığınızı etkiler.

1. Adım (Öncü sonrası): Ölçüm ve veri kalitesi

Test öncesi hesaplama engelini aştıysanız ve test etmek için yeterli veri hacminiz olduğunu onayladıysanız, ilerlemenin önündeki bir sonraki engel ölçüm ve veri kalitesidir. Bu işte neyi hedeflediğinizi bilmelisiniz ; aksi takdirde, nehir kıyısındaki bir balık gibi bocalarsınız. Çok fazla ekip, form gönderimleri, işlemler, gelir, YBD vb. gibi ne için çalıştıklarını bilmiyor.

Deneme ve bir bütün olarak işletme için birincil, ikincil ve üçüncül ölçümlerinizin ne olduğunu anlayın. Tam bir açıklıkla anlayın. Kalıcı kafa karışıklığına veya belirsizliğe izin vermeyin. Herkesin aynı sayfada olduğundan emin olun.

Ardından, bu kadar veriye sahip olduğunuzda, bu verileri doğru yerlerde topladığınızdan ve bunlara güvenebileceğinizden emin olun.

Ölçüm ve/veya veri kalitesi felaketse, durun. Her şeyi durdurun ve tüm çabanızı onu doğru yapmaya adayın. Deneyi bir piramit olarak düşünün. Bu iki şey piramidin temel katmanlarıdır. Herhangi bir zamanda çatlarsa, diğer her şey onun üzerine çökecek. Söz veriyorum.

Bunların zor olabileceğini bildiğimi söyleyeceğim. Bunları düzeltmek fazladan zaman alabilir. Belki bir veya iki aydan fazla. Yine de onları doğru yapmak buna değer. Bir programı başlattıktan altı ay veya daha uzun süre sonra sorunların ortaya çıktığını gördüm - yalnızca sonunda her şey aniden durdu. O noktada kimse mutlu değil.

Birincil ölçünün ne olması gerektiğine dair bir not…

Bu bazen uygulayıcılar arasında bölücü bir konudur. Özellikle pazarlama ekipleri ve web siteleri söz konusu olduğunda (mutlaka ürün ekipleri ve ürünler değil) bu konuda çok sağlam bir duruşum var.

Birincil metrikler her zaman dönüşüm hunisinin aşağısındaki metrikler olmalıdır. Emirler. Form gönderimleri. MQL'ler. Hasılat. LTV. SQL'ler. Kaptın bu işi. Bazı insanlar, her zaman yaptığınız değişikliğe veya katılım ölçütlerine en yakın eylem olmaları gerektiğini söylüyor. Yanlış. Hayır. Hayır. Yanlış. BS. Bunu size kim söylerse, programı altı ay veya bir yıl içinde şirketin CMO'suna veya CEO'suna gerekçelendirmesi gereken kişi olmalıdır. Sıcak koltukta olacaklar. Düğme tıklamalarına, tıklamalara, sayfa görüntülemelerine, ortalamaya odaklanan testlerle dolu bir programınız YOKTUR. oturum süresi, çıkış oranı, hemen çıkma oranı, video görüntülemeleri vb. Bu, bu işi yapmak için harcanan binlerce veya yüz binlerce doları haklı çıkarmayacak. Herkes yatırım getirisini ve çalışmanın kârlılığı nasıl etkilediğini bilmek ister. Düğme tıklamaları bunu yapmayacak.

Etkileşim metriklerini veya dönüşüm hunisinin üst kısmındaki metrikleri ölçmeyin demiyorum ama bunlar ikincil veya üçüncül metrikler olmalıdır. Birincil olanlar değil. Bir testin hikayesine bağlam eklerler. Karar verme zamanı geldiğinde dayanılacak testler bunlar değildir. Not, ayrıca hiçbir zaman istisna olmadığını söylemiyorum. Yine de testleri duruma göre değerlendirin.

Bir tavsiye: Bu konuyu kendi aranızda tartışanlara, her zaman takımlara seçenekleri tartışmalarını ve kendileri karar vermelerini söylüyorum. İlerleyerek herkesin uyduğu toplu bir sonuca vardığınızdan emin olun.

2. Adım: Kullanıcı araştırması ve fikir oluşturma

Bu noktada, (1) test etmek için yeterli veri hacmine sahip olduğunuzu ve (2) neyi ölçtüğünüzü ve güvenebileceğiniz uygun verileri topladığınızı bilmelisiniz. Sırada ne var? Neyin test edileceğini buluyor. Test fikirleriniz nelerdir? Onları nasıl üreteceksin?

Bilin bakalım çoğu takım ne yapıyor? İçgüdüsel duygulardan ve pek çok "düşünürüz", "hissediyoruz" ve "inanıyoruz" ifadelerinden yola çıkarlar. Bu çok öznel ve bir programı çalıştırmanın berbat bir yolu. Bu yaklaşım hiçbir şekilde veri destekli değildir. Uygulayıcıların "spagetti testi" dedikleri şey, yani duvara bir şeyler fırlatmak ve yapışmasını ummak. Veriye dayalı konuşmalar bu tür bir dili pek içermez ve gereken veriler kullanıcı araştırmasından gelir. Bana her zaman "araştırmanın" ne anlama geldiği sorulur.

Analitik, anketler, anketler, kullanıcı testi, mesaj testi, ısı haritaları, oturum kayıtları, kart sıralama, ağaç testi, müşteri yolculuğu haritalaması, kişiler ve daha pek çok şey dahil ancak bunlarla sınırlı olmamak üzere veri toplayan çeşitli metodolojiler vardır. Bunların her birini tamamlamamıza yardımcı olacak birkaç araç da vardır. Her zaman bir veya iki ile başlayıp oradan diğerlerine doğru ilerleyin derim. Bu kesinlikle hiç yoktan iyidir. Teknik olarak, artık analitiği gerçekten saymıyorum çünkü bugünlerde her şirketin analitik verileri var. Buna sahip değilseniz, muhtemelen kızartılacak daha büyük balıklarınız vardır. Yine de varsa, bunun da ötesinde bir veya iki tane için çabalayın (ve “aa iyiyiz o zaman” demeyin).

Sezgisel değerlendirme denen bir metodoloji var. Bu, birisinin bir deneyimi görsel olarak değerlendirdiği ve deneyim ve uzmanlıklarına dayalı içgörüler geliştirdiği zamandır. Bunun için bir zaman ve yer var ama çoğu zaman “somut verilerle” desteklenmiyor. Oldukça özneldir ve kimin tamamladığına bağlı olarak bir dereceye kadar farklı olacaktır. Programınızın bu tür içgörülere dayanmaması gerektiğini bilin.

Burada nasıl araştırma yapılacağını ayrıntılı olarak ele almayacağım, ancak CXL'in ResearchXL modeli hakkında daha fazla konuştuğum VWO Web Seminerlerimden birine buradan göz atabilirsiniz.

3. Adım: Önceliklendirme

Bir kez test fikirleri listeniz olduğunda, hepsini aynı anda yapamazsınız. Bir eylem planı oluşturmak için stratejik ve mantıklı bir yola ihtiyacınız var. Önceliklendirme çerçevelerinin devreye girdiği yer burasıdır. Birçoğu var. Özellikle birini beğendim: CXL'den PXL çerçevesi. Diğer yaygın olanlar arasında PIE, ICE veya PILL bulunur. PXL bence en objektif olanıdır. Özelleştirilebilir ve daha sağlamdır (iyi bir şekilde).

Diğer modeller iyidir ve hiç yoktan iyidir. Bir şeye sahipseniz ve sizin için çalışıyorsa, harika. Sadece bir tane al ve herkesin onu kullandığından emin ol! Sizi ekstra kaosla uğraşmaktan kurtarır.

4. Adım: Yol Haritası Oluşturma

Yol haritaları, herhangi bir zamanda neyin çalıştığını size görsel olarak gösterir. Önceliklendirme ve ön test hesaplamalarınızı birleştirin ve patlama yapın. Bir yol haritanız var. Bunlar en iyi Gantt çizelgelerinde yapılır. Tüm kulvarlarınızı ve testlerinizi tahmini süreler, cihazlar ve diğer yararlı meta verilerle ekleyin. İstenmeyen çakışmalardan ve istenmeyen etkileşim etkilerinden kaçınacaksınız. Herkesin çok daha etkili ve verimli bir şekilde plan yapmasına yardımcı olur. Bu sizi daha fazla kaostan kurtaracaktır.

5. Adım ve sonrası: Her zamanki gibi iş

Şimdi ele aldığımız her şey ortadan kalktığına göre, işler her zamanki gibi. Yapacağınız bir testiniz var. Normal deneme iş akışı aracılığıyla gönderirsiniz: model > tasarım > geliştirme > QA > başlat > izle > sonlandır > analiz > paylaş ve arşivle > tekrarla.

İlgili konular: Program yönetimi ve yönetişim

Bireysel testlerin dışında, bütün bir "program" ile ilgili olarak değerlendirilmesi gereken başka konular da vardır. Bunlar, program yönetimi ve yönetişimi içerir. İşte onlar hakkında çok kaynatılmış bir şekilde böyle düşünüyorum…

Program yönetimi: Tüm bu çalışmaları nasıl organize edecek ve takip edeceksiniz? Görevler, veri yönetimi ve iletişim için hangi araçları kullanacağınızı belirleyin. (Bu dökümü Speero'nun CEO'su Ben Labay'dan aldım.)

Yönetişim: Herkes hangi rollere ve sorumluluklara sahiptir? Bunu belirlemenin yararlı bir yolu, (1) bir yönetişim modeli seçmek ve (2) yönetişim modeliyle uyumlu bir RASCI şeması tamamlamaktır. Araştırılacak ve dikkate alınacak ortak yönetişim modelleri: Bireysel, merkezi, merkezi olmayan, mükemmellik merkezi, test konseyi ve melezler.

Bunların ikisini de diğer her şeyle birlikte çivilemezseniz, bu ek bir kaos olur ve her adımda bunun bedelini ödersiniz. Bunları çivileyin. Fazladan zaman alıyor ama buna değer. Bir süreliğine bir şeylerin üstesinden gelirseniz, sonuçlar eninde sonunda sizi yakalayacaktır. Söz veriyorum. (Görünüşe göre, burada epeyce söz verdim.)

Çözüm

Deneye başlamak için neler yapabileceğiniz veya halihazırda çalışmakta olan programınızın seviyesini yükseltmek için neler yapabileceğiniz konusunda kendinize biraz (veya çok) daha fazla güvenmelisiniz. Bunun çok zor veya çok kolay olduğunu düşünmeyin. Genellikle ortada bir yerdedir. Bahsettiğim her şey için geçerli olan en büyük tavsiyem: Bir oyun kurucunuz olsun. Tüm bu işlere liderlik eden birine sahip olun. Bu, onların tam zamanlı rolü olmak zorunda değildir, ancak birileri bu role sahip olmalıdır. Bu genellikle en çok başarıyı gördüğüm zamandır.

Sonuç olarak, umarım titizlikle, sonuçlarla ve biraz eğlenceyle dolu bir deney programınız vardır. Günün sonunda, bir işletme için büyük bir fark yaratabilecek eğlenceli ve heyecan verici bir iştir.

Deneyin inovasyonu ve büyümeyi nasıl yönlendirdiği ve tüm abartıya değdiği hakkında daha fazla bilgi edinmek istiyorsanız, VWO ile yaptığım son web seminerimi izleyin.