Veriye Dayalı Ürün Geliştirme İçin Deney Ortamı Nasıl Kurulur?

Bir ürün sahibi olarak, A seçeneğine mi yoksa B seçeneğine mi devam edilmesi gerektiği sorusuyla sık sık karşılaşılır. Veya daha iyi sonuçlar elde etmek için ekranın hangi sürümü uygulanmalıdır? Bu tür kararları vermek, özellikle sınırlı kaynaklara sahip, son teslim tarihlerinin kısıtlı olduğu durumlarda zorlayıcı olabilir. Ayrıca, bu tür kararlar kişisel değerlendirmeye veya bir rakibin yaklaşımını kopyalamaya dayalı olarak alınır ve bu da optimal olmayan sonuçlara yol açabilir.

İyi haber şu ki, nispeten az çaba gerektiren basit bir deney ortamı kurarak bu tür tuzaklardan kaçınılabilir. Bu yazımızda bunu nasıl başarabileceğinizi anlatacağız.

İçindekiler

• Bir deneme ortamı oluşturmak neden önemlidir?
• Mitler
• Deneme ortamınızı ayarlama
  • Gelecekteki denemenizin amacını tanımlama
  • Deney ortamınızın mimarisini tasarlama
  • Sonuçların analiz edilmesi ve yorumlanması
  • Tercih edilen seçeneğin ölçeğini büyütme.
• Çözüm.

Deney Ortamı Kurmak Neden Önemlidir?

Bir deneme ortamı oluşturmak iki nedenden dolayı önemlidir:

• İlk olarak, yeni işlevleri uyguladıktan sonra veri odaklı bir yaklaşıma dayalı olarak en iyi seçeneği seçtiğinizden emin olmanızı sağlar.

  
  

• İkinci olarak, 'olduğu gibi' ile varsayımsal 'olacak' seçenekleri karşılaştırarak ve bir 'ya şöyle olursa' analizi yaparak ürününüzün mevcut işlevselliğini sürekli olarak geliştirmenize olanak tanır.

Mitler

Yaklaşıma geçmeden önce, ürün sahiplerini genellikle yanlış yönlendiren bazı efsaneleri çürütelim:

Denemeler ve A/B testleri yapmaya olanak tanıyan karmaşık bir ortam oluşturmak için çok fazla kaynağa ihtiyacım var

Yanlış : Tanımlanan yaklaşım, yazılım mühendisinizin kaynaklarının bir haftadan daha azını alıyor.

İyi kurulmuş bir veri toplama sürecine ve ayrıntılı olay takibine ihtiyacım var

Yanlış : Ürününüzün ana varlığının yaşam döngüsüne ilişkin bilgileri saklayan mevcut bir veritabanına güvenebilirsiniz. Örneğin, teslimat hizmeti veriyorsanız sipariş durumları.

Taleplerimi günlük olarak yerine getirecek özel bir analist ekibine ihtiyacım var

Yanlış : Denemenizin yaklaşımını ve metriklerini anladıktan sonra, basit bir SQL sorgusu kullanarak verileri kendiniz düzenli olarak çekebilirsiniz.

Yaklaşmak

Deneme ortamınızı ayarlamak için şu adımları izlemeniz önerilir:

1. Gelecekteki denemenizin hedefini tanımlayın, seçenekleri anlayın ve metrikleri seçin

Ürün tasarımcınıza ulaşmadan önce denemenizin bir parçası olarak ölçülecek hedefleri ve metrikleri tanımlayın. Klasik 'A Seçeneği veya B Seçeneği' sorusu durumunda, bir değişikliği uygulayarak neyi başarmak istediğiniz genellikle basittir. Örneğin, dönüşüm hunisinin belirli bir bölümüne hitap ediyor olabilirsiniz.

Örnek olması açısından bir teslimat şirketinde çalıştığınızı ve şu anda sipariş oluşturma formuna odaklandığınızı varsayalım. Gönderim adresini sağlayan ve ardından bir gönderim yöntemi seçen kullanıcıların nispeten düşük bir yüzdesine hitap etmek istiyorsunuz. Ayrıca yolculuğun iki yeni versiyonunun olduğunu hayal edin:

1. Mevcut sürüm : Bir ekran, adreslerin girilmesini ve verilen adrese göre haritanın bir pin ile gösterilmesini gerektirir. Bir sonraki ekran, sağlanan adrese göre bir gönderim yöntemi seçmenize olanak tanır.

   
   

2. Yeni sürüm : Tek ekran, adresin girilmesini ve burada nakliye yöntemini seçmeyi gerektirir.

Amaç, adreslerini sağlayan ve gönderim yöntemini seçen seçeneklerden hangisinin daha yüksek bir kullanıcı payına yol açtığını belirlemektir. Ölçümler oldukça basittir: Adresini veren ve bir gönderim yöntemi seçen kullanıcıların yüzdesi.

Aslında bu tür verileri ölçmenin 2 yolu vardır :

1. Arka ucunuzun tasarımında halihazırda mevcut olan verilere dayanmaktadır. Örneğin, siparişin yaşam döngüsü hakkında bilgi içeren bir veritabanı düşünün. Siparişiniz aşağıdaki gibi durumlara veya durumlara sahip olabilir:

   
   

   1. Taslak oluşturuldu

   2. Gönderim yöntemlerini bulmaya çalışın

   3. Gönderim seçenekleri bulundu/ Gönderim seçenekleri bulunamadı

      
      

2. Olay izleme - Bu, kutudan çıktığı gibi çalışacak bir şey değildir ve dolayısıyla uygulanması ekstra çaba gerektirir. Ancak olay izleme sizin için daha ayrıntılı analiz yapılmasına olanak sağlar; örneğin cihaz türü ve tarayıcı adı, etkinliklerinizin parametresi olarak iletilebilir.

Bu makalenin sonraki bölümlerinde olay izlemenin olmadığı ilk yaklaşıma, yani mevcut veri mimarisine odaklanacağız.

2. Deney ortamınızın mimarisini tasarlayın

Deney akışında 2 ana adımın tamamlanması gerekir:

• Seçilen parametrelerle bir deneme oluşturun
• Kullanıcının her iki gruba da atanması gerektiğinde kullanıcı yolculuğunun bir aşamasını tanımlayın ve sonuç olarak ilgili kullanıcı arayüzünün görüntülendiğinden emin olun

Bir deneme oluşturma:

Buradaki fikir, mümkün olduğu kadar basit olması gereken ve aşağıdaki parametrelerle denemeler oluşturmanıza izin vermesi gereken hafif bir A/B testi çerçevesi oluşturmaktır:

• Deneme Kimliği
• Maksimum örnek
• Her grubun numarası ve adları
• Her gruba düşme olasılığı

Bu parametreleri yapılandırabilmek, bir numune limiti belirlemenize ve istenen numune boyutuna ulaşılana kadar deney için adayları rastgele seçmenize olanak tanır.

Bunun için hem istemcinin hem de sunucunun değişikliklere ihtiyacı vardır: Sunucu, deneme başına aday sayısını izlemeli ve arka uç, mevcut kullanıcının bir denemenin parçası olup olmayacağına karar verecektir. Arka uç, kimliği doğrulanmış kullanıcının deneyin parçası olup olmayacağına mevcut örnek boyutuna ve sabit olasılığa göre karar verecektir. Ayrıca arka uç, kullanıcılara tutarlı deneyimler sağlamak ve deney sonuçlarını doğru bir şekilde hesaplamak için belirli bir denemenin parçası olan bir kullanıcı koleksiyonunu korumalıdır.

Denemenin yapılandırmasının uç noktası şu şekilde görünebilir:

POST /api/your-service/experiment-create

Rica etmek:

 { experiment_id: "f380739f-62f3-4316-8acf-93ed5744cb9e", maximum_sample_size: 250, groups: { { group_name: "old_journey", probability_of_falling_in: 0.5 }, { group_name: "new_journey", probability_of_falling_in: 0.5 },}

Cevap:

{

200,

experiment_id: "f380739f-62f3-4316-8acf-93ed5744cb9e"

}

Kullanıcının deneme gruplarına ne zaman ve nasıl atanacağına karar verme:

Belirli bir kullanıcıyı denemeye ve ilgili gruba atamaktan sorumlu olacak ayrı bir uç noktaya ihtiyacınız olacaktır. Buna experiment-enrollments adını verelim.

Tüm ortamı tasarlarken, kullanıcı yolculuğu experiment-enrollments uç noktasının hangi aşamasında çağrılması gerektiğini net bir şekilde anlamalısınız. Ayrıca denemeye tüm kullanıcıların katılmaması da söz konusu olabilir. Bu nedenle uç noktaya bir kullanıcı kimlik doğrulama belirtecinin sağlanması da yararlı olacaktır.

Örneğimizde, yalnızca ilk siparişini veren yeni kullanıcılara odaklanmak istiyorsak user-auth, bunun ne tür bir kullanıcı olduğunu ve denemeye birinin kaydedilmesi gerekip gerekmediğini belirlememize olanak tanır. Ayrıca, uç nokta çağrıldığında gerekli tüm bilgilerin mevcut olduğundan ve yolculuğunuzun ve yaşam döngünüze ilişkin ayrıntıların dikkate alındığından emin olun.

experiment-enrollments uç noktası aşağıda açıklanmıştır. Belirli kullanıcı türleri için (örneğin, yalnızca adresi henüz vermemiş yeni kullanıcılar) yolculuğun belirli bir aşamasında (örneğin teslimat adresi gerektiren ekrana gelmeden önce) çağrılabilir ve mevcut kullanıcının katılıp katılmayacağını hesaplar. belirli bir deneyde olsun ya da olmasın:

POST /api/your-service/experiment-enrollments , kullanıcı kimlik doğrulama jetonu gerekli

Rica etmek:

\ {

experiment_id: "f380739f-62f3-4316-8acf-93ed5744cb9e"

}

Cevap:

 {200, enrolled: true/false, group_name: group_1,}

Teorik veri akışının nasıl görüneceğini göstermek için teslimat şirketindeki sipariş oluşturma akışına ilişkin aynı örneği varsayalım. Sipariş oluşturma ekranında 2 seçenekten birini seçiyorsunuz.

Aşağıdaki şemada aşağıdaki uç noktalar belirtilmektedir, yani:

• /create-order-taslak (3. adım)

• /find-shipping-method (adım 16)

• /submit-order (adım 20)

  
  

açıklayıcı örneği desteklemek amacıyla verilmiştir ve deney ortamının gerekli parçaları değildir

Ayrıca veritabanlarının açıklayıcı ve basitleştirilmiş mimarisi aşağıda verilmiştir.

3 ana tablo vardır:

1. Experiments set - daha önce oluşturduğunuz tüm deneyleri içerir. Veritabanı /experiment-create bitiş noktasını her çağırdığınızda güncellenir.

   
   

2. Experiments database - belirli bir kullanıcının her kaydıyla ilişkili tüm kayıtları içerir. experiment-enrollments uç noktasını her çağırdığınızda veritabanı güncellenir

   
   

3. Order lifecycle database - deneyle ilgili verilerin nasıl saklanabileceğine dair resimli örneği desteklemek için sağlanmıştır. Buradaki önemli nokta, bu tablonun (veya ürününüzün özelliklerine karşılık gelen herhangi bir benzer tablonun), oluşturduğunuz deneysel gruplardan birine kayıtlı belirli bir kullanıcı için girişin (örn. sipariş oluşturma) başarılı olup olmadığını görmenize olanak sağlamasıdır. ayarladık. Örneğimizde, kullanıcının gönderim ayrıntılarını başarıyla sağladığı ve ardından önerilen gönderim yöntemlerinden birini seçtiği sonucuna varılmasına olanak tanıyan Gönderim yöntemi seçili durumuna güvenebiliriz.

   
   

   
   

Tasarım ve uygulama yaklaşımına genel bakış

Artıları:

1. Ortaya çıkan örnek heterojendir
2. Örneklem büyüklüğü önceden bilinmektedir
3. Sabit örnekleme olasılığına bağlı olarak sonuçlar hızlı bir şekilde hesaplanabilir

Eksileri:

1. Hem ön uç hem de arka uçta değişiklik gerektirir
2. Sonuçların hesaplanması, bazıları başlangıçta analitik amaçlar için tasarlanamayan çeşitli veri tabanlarına dayanacaktır.

Görevler ve gösterge niteliğindeki tahminler:

• [ ] un tanımsız [Arka uç] Bir model oluşturun ve getirme sayacı uç noktasını gösterin: ~2 hikaye noktası
• [ ] tanımsız [Arka uç] Artış sayacı bitiş noktasını açığa çıkarma: ~2 hikaye noktası
• [ ] un tanımsız [Arka uç] Getirme ve artırma sayacı için uç noktaları gösterin: ~1 hikaye noktası
• [ ] un tanımsız [Ön uç] Kayıt akışları arasında geçiş yapmak için sayaç uç noktalarını çağırın: ~3 hikaye noktası

Arka ucunuzu tasarladıktan sonra ön uç ekibinizle bilgiyi almanın en iyi yolu ve akışın hangi aşamasında olduğu konusunda anlaşın.

Ana bağımlılıkları aklınızda bulundurun ve azaltın:

• Ön uç kısmının arka uçla paralel olarak uygulanabilmesi için ekiplerinizin önceden bir sözleşme üzerinde anlaştığından emin olun.
• Tüm arka uç tamamlanana kadar ön uçunuzun engellenmesini önlemeye çalışın
• Deneme ortamından bağımsız olarak tüm kullanıcı arayüzü seçenekleri yine de uygulanmalıdır

3. Sonuçların analiz edilmesi ve yorumlanması

Denemeniz yeterli bir süre boyunca çalıştırıldıktan sonra, anlamlı sonuçlara varmak için sonuçları analiz etmek ve yorumlamak önemlidir.

Daha önce odaklanmaya karar verdiğiniz metrikler üzerindeki etkiyi hesaplamak için ihtiyaç duyduğunuz alanların listesini tanımlayın.

Yukarıdaki açıklayıcı örnekte veri kaynakları 2 tablo olacaktır:

• Experiments database :

  • Giriş : sonuçlarını aradığınız deneme kimliği

  • Çıktı : belirli bir deneyin katılımcıları olan tüm kullanıcı kimliklerinin listesi, her kullanıcının atandığı grup ve kullanıcının atandığı zaman damgası

    
    

• Order lifecycle database
  • Giriş : denemenizin kapsamındaki kullanıcıların listesi ve denemeye kaydoldukları zaman damgası
  • Çıktı : bu kullanıcılarla ilişkili olan ve kullanıcı denemeye kaydolduktan sonra işlenen tüm siparişlerin son durumları

Bu verilere dayanarak, deneme gruplarının her biri için başarıyla oluşturulan siparişlerin yüzdesini hesaplayabilirsiniz.

Sonuçlarınızı analiz ederken yalnızca ham sayıların ötesine bakmanız önemlidir. Ayrıca test gruplarınız arasında gözlemlediğiniz farklılıkların yalnızca rastgele şansa bağlı olmadığından emin olmak için istatistiksel anlamlılığa da bakmak isteyeceksiniz. Zaten bu konuyla ilgili birçok makaleyi bu ve diğer çevrimiçi kaynaklarda gördüğüm için bu kısma çok fazla odaklanmayacağım. Neyse, burada aşırı bilgiye gerek yok: 2 grup arasındaki farkın anlamlılığını kontrol etmek için Z-Test veya T-Test'i uygulayabilmek bence yeterli olacaktır.

Ancak sonuçlarınızın istatistiksel olarak anlamlı olduğunu belirledikten sonra ürününüzün hangi seçeneğinin daha iyi performans gösterdiğine dair sonuçlara varmaya başlayabilirsiniz.

4. Tercih edilen seçeneğin ölçeğini büyütmek

Bir denemeyi başarılı bir şekilde yürüttükten ve en iyi seçeneğe ilişkin yeterli derecede güven kazandıktan sonra, bir sonraki adım ürününüz genelinde değişikliklerinizi ölçeklendirmektir. Birkaç yaklaşım olabilir:

• En kolayı, denemenizin yapılandırmasını , kullanıcıların %100'ünün daha iyi sonuçlar veren gruba gireceği şekilde ayarlamaktır. Kullanıcı arayüzünün bu belirli bölümünün görüntülenmesinin deneme ortamından bağımsız olması için gelecekte kodu temizlemek üzere biraz zaman ayırmanız gerekecektir.

  
  

• Daha az basit olanı, ürününüzün birden fazla platformda mevcut olmasıdır. Web akışındaki denemelerin sonuçlarının mobil uygulama akışına (veya tam tersi) uygulanacağını varsayarken ekstra dikkatli olun . Bazen üzgün olmaktansa tedbirli olmak ve benzer şekilde ama başka bir platformda ayrı bir deney yapmak daha iyidir.

Sonuçlandırmak için

Kendi deneme ortamınıza sahip olmak, her ürün yöneticisi için çok kullanışlı bir araçtır. Mevcut ürününüz hangi olgunluk aşamasında olursa olsun deneme ortamı oluşturmak çok fazla zaman almamalıdır. Çalıştırmak için tek seferlik oldukça düşük bir maliyet ödemek, yatırımın geri dönüşünü oldukça hızlı bir şekilde size gösterecektir.

Son olarak, deney sonuçlarının anlamlı olmasını sağlayacak birkaç ipucu:

• Öncelikle, düşündüğünüz değişikliği uygulayarak hangi metriklerin etkileneceğini (varsa) anlayın.
• Denemenize başlamadan önce hedeflerinizi ve ölçümlerinizi net bir şekilde tanımlayın
• Her seferinde tek bir önemli değişikliğe odaklanarak denemenizi mümkün olduğunca basit tutun
• Denemenizin sonuçlarının diğer platformlarda veya diğer benzer hizmetlerde değerlendirilmesini değerlendirirken dikkatli olun
  

Bu en iyi uygulamaları takip ederek, verilere dayalı kararlar almanıza ve zaman içinde dönüşüm oranlarınızı artırmanıza yardımcı olabilecek etkili bir deneme ortamı oluşturabilirsiniz.