E-Bülten listemize abone olun.

ABONE OL

Hipotez Testi Nedir?

Şu ana kadar Not Defteri bölümümüzde yer verdiğimiz ve kurguladığımız sistematiğe göbekten bağlı olan DMMP ve AARRR odaklı yazılarımızı okuduğunuzu farz ederek, giriş cümlemi şöyle kuruyorum; ‘Hipotez, bu işin en can alıcı yeri!’

Yanlış anlaşılma olmasın, DMMP klavuzumuz olmasa, AARRR metriklerine bakmasak, growth takımı oluşturma takıntımız olmasa, hipotez testinin de başarılı olabileceğini iddia etmiyorum. Ama burası işin operasyon kısmı. İşte, hep o bahsedilen testin yapıldığı, verilerin edinilmesi için ateşleme tuşuna basıldığı ve aksiyon alınabilir sonuçların harmanlandığı yer… Burası, işin mutfağı. Peki biz bu noktaya nasıl geldik?

SHERPA Blog her hafta e-postanızda. Ücretsiz abone olmak için tıklayın.

Burada sanırım Brian Balfour‘un Hubspot growth takımında yaptıklarına hayran olduğumu itiraf etmem gerekir. Bu nedenledir ki onun yazdıklarını özellikle bloğundan yakından takip etmeye çalışıyorum. Bu takiplerden birinde aslında bizim de uzun zamandır kendi sistemimizde aradığımız o eksik parçayı bulduğumu fark edince, yazıdaki slaytlar arasında bir mehter takımı edasıyla dolaşmaya başladım. O an, “aha moment” dedikleri andı benim için. “Neydi seni böyle heyacanlandıran?” derseniz yanıtım şu olurdu: bulduğum çalışma, bütün hedef ve analizlerimizin ardından yapmamız gereken testlerin nasıl sistematize edileceğini gözlerimizin önüne sürüyordu. O çalışma Hipotez Testi (Hypothesis Testing) idi. Bu kadar girizgah yeter herhalde. Hadi, Hipotez Testi nedir, ne değildir; biraz detaylarından bahsedelim.

Hipotez Testi’ne bir dokümantasyon olarak bakarsanız, aynı DMMP örneğinde olduğunu gibi çirkin bir spreadsheet’ten oluştuğunu görürsünüz. Ancak içinde muhafaza ettiği yapı, bütün growth engine yapınızı çalıştıracak parçalara sahiptir. Şimdi söz verdiğim gibi detaylarına bakacağız ancak bilmeniz gereken bir şey var ki hemen her örnekte olduğu gibi hipotez backlog dokümanını da bulduğumuz gibi kullanmadık. Üzerinde çalışarak, evrilmesini sağladık. Öncelikle orjinalini anlatalım isterseniz. Orjinali aşağıdaki gibi bir dokümandır;

Screenshot 2015-03-31 16.53.15

(üzerine tıklayarak imajın yamulmamış  halini görebilirsiniz)

Şimdi kolonlarından anlatmaya başlayalım;

 1. Experiment Name (Deney Bilgileri)

Kısaca, “Neyi test edeceksiniz?” sorusu. Bu soruya genelde insanlar “Nereden bileyim?” veya “Onu siz söylemeyecek misiniz?” gibi sorularla karşılık veriyorlar. Bizim böyle bir her bedene uygun lastikli pantolon vari bir çözümümüz olsaydı zaten testin sonuçlarını da bilir, hatta öğle çayını Sean Ellis’le içerdik! Ki bilmenizi isterim ki bu durum bizimle sınırlı değil. Hizmet olarak bu gibi stratejik çözümleri sunan oluşumların sunabileceği tek ve yegane doğru çözüm, sizin için “yolu açmak”tır. Bir zahmet, sizler de yürüme kısmında yer alacaksınız. “Anladık geç bu ayarları…” diyenler için devam ediyorum.

1Sizin (yani aslında growth takımının) bu backlog’u doldurmanız gerekir” dememle birlikte size gökten inme ilham gelmeyeceğini biliyorum, merak etmeyin. Bunu mümkün kılmanın tabi ki bir yolu var. Burada Brian baba der ki “Siz bu bilgiye zaten erişebilecek noktadasınız. Sadece doğru şekilde sorgulamayı başarmalısınız. Bunun için de;

  • Etrafınızı gözlemleyerek “Diğerleri nasıl yapıyor?” diyebilmeli
  • “Ne?”, “Nasıl?”, “Neden?”, “Eğer şöyle olursa..?, “Şunu daha fazla nasıl yaparız?” gibi soruları sorabilmeli
  • “Aktivasyon mekanizmamız bir satışı kapatmak gibi olsaydı nasıl olurdu?” gibi direkt bağlantılı olmayan noktalar arasındaki boşlukları doldurabilmeli
  • İşletmeniz ve sizin etrafınızdaki network’ü kullanarak geribildirim alabilmelisiniz.

Bu maddelerin hepsini bir yana koyduğunuzda bile yaptığınız işi en iyi bilen kişi sizsiniz. Kaçış yok. Fikirlerinizi kanvasa oturtmaya çalışın.

 2. Status (Durumu)

Bu eldeki maddenin durumunu belirten kolondur. “Fikir aşamasında”, “Tanımlanıyor” ve “Tanımlandı” gibi dilimize çevirebiliriz. Kendini anlatıyor sanırım.

3. Category (Kategorisi)

Aha, işte bu! AARRR’ı hatırladınız mı? Hani metriklerin analizini yaparken kullanıdığımız framework. İşte burada, eldeki maddenin bu kategorilerden hangisine denk geldiğine göre atama yapıyoruz ki gün gelir de “Bizim daha fazla Acquisition (Edinim/Kazanım) sağlamaya ihtiyacımız var” dersek sadece bu kolonda bir sorting yaparak gerekli maddelere ulaşabilelim. Ayrıca burası, her eklediğimiz maddenin aynı kategorilerde olmadığına emin olabilmek, olabildiğince geniş dağılımlı bir listeye sahip olabilmek için de önemli bir kolondur. İstatistikler için candır.

4. Metric ( Metrik)

“Testi yapalım yapmasına da neyi ölçeceğiz?” sorusunun en direkt cevabıdır. Test başarı oranını belirlemek için kullanacağınız metriğin ismidir.

5. Prediction (Tahmini değişiklik)

Yüzde şu kadar artar, bu miktarda azalır gibi aslında ecnebilerin “educated guess” dedikleri tahminler. Bu sayılar ilk başta çok alakasız olabilirler. Ancak test yaptıkça ne kadar yakın tahminlerden bulunduğunuzu görüp sayısal loto bayiisine koşmaya başlarsanız karışmam.

6.Resources; Marketing, Engineering, Design (kaynaklar; pazarlama, yazılım geliştirme, dizayn)

Kaynak kullanımı; ne kadar olacak hangi departman/kaynak türünden ne kadar gidecek bunu bilmeniz önceliklendirme yaparken size çok yardımcı olacak. Bana güvenin.

Bu aslında Balfour’un paylaştığı dokümandaki kolonların sonuncusuydu. Bunlara biz de dokümanın anlatımının haricinde değinilen ve kendi müşterilerimizle çalışırken ihtiyaç duyduğumuz kolonları da ekledik;

Ek kolon 1: No.

Size komik gelebilir ama gerçekten de özellikle online olarak bir dokümanın üzerinden değerlendirme yaparken kim hangi maddeden bahsediyor, toplantı notlarında hangi madde hangi deneye ait diye kafayı yememenizi sağlıyor. Numaralandırma hayat kurtarır, demedi demeyin.

Ek Kolon 2: Sıralama

Dokümandaki işlemleri tamamladınız önceliklendirme verdiniz, e nerede yazıyor? Neden listede olmasın? Sıralama sizin deneylerinizin gerçekleştirilme kuyruğundaki yerini belirtir. Ha arzu ederseniz pozisyon olarak daha sağa veya sola alabilirsiniz (aşağıda bizim versiyondakine nazaran demek istiyorum)

Ek kolon 3: Test Süresi

Tam anlamıyla olmazsa olmaz. Farklı kaynaklar test süresinin farklı farklı olması gerektiğini belirtse de eldeki test maddesine göre yeterli doneye sahip olabilmeniz için 1 ila 4 hafta arasında bir süreyi seçmenizi öneririm. Bununla beraber çoğu örnek için 2 hafta gibi bir sürenin optimum olacağını öngörüyorum. Tabii test edip bulmak size kalmış.

Ek kolon 4: Gerçekleşme ihtimali

Bu Balfour’un önceliklendirme için kullanılmasını önerdiği bir yöntem. Ölçümleme için kullandığınız metrik verisini tahmini değişiklikle karşılaştırma sonucu ulaşacağınız değer. Başka bir değişle tahmini değişikliğin test sonucunda gerçekleşme ihtimali. Burada Balfour bir triage yöntemi olarak %20-%50-%80 değerlerinden birini seçmemizi önermiş. Bizde bu öneriye uyduk.

Ek Kolon 5: Etki Seviyesi

4. maddeyle aynı amaca hizmet eden bir madde daha. Sizce bu maddedeki önerme gerçekleşirse etkisi ne kadar önemli olacak? Örneğin gerçekleşme ihtimali çok yüksek ama etkisi az olan bir testi mi önceliklendirirsiniz, yoksa gerçekleşme ihtimali olan ve etkisi de büyük olan bir testi mi? Burada düşük-orta-yüksek seçenekleri yeterli olacaktır.

Bu belirtiğim ek kolonlar sayesinde daha detaylı ve tek bir bakışta size daha geniş açıdan tüm maddelerinizi görmenizi sağlayacak olan DAM Growth Hackers versiyonu ortaya çıkmaktadır;

damgh-hypothesis-testing

(üzerine tıklayarak imajın yamulmamış halini görebilirsiniz)

Ve makinayı çalıştırın…

Kullanıcı testleri mi yapmak istiyorsunuz? Bu A/B testi hesaplayıcıları size yardımcı olabilir.

Artık kanvas elinizde olduğuna göre neyi bekliyorsunuz? Artık bir hypothesis backlog’unuz var; başlayın doldurmaya! doldurdukça test edin ettikçe, daha fazla madde ekleyin. Unutmayın bu bitmeyen bir süreç…