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 : Tanımlanan yaklaşım, yazılım mühendisinizin kaynaklarının bir haftadan daha azını alıyor. Yanlış İyi kurulmuş bir veri toplama sürecine ve ayrıntılı olay takibine ihtiyacım var : Ü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ı. Yanlış Taleplerimi günlük olarak yerine getirecek özel bir analist ekibine ihtiyacım var : Denemenizin yaklaşımını ve metriklerini anladıktan sonra, basit bir Yanlış 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: : 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. Mevcut sürüm : Tek ekran, adresin girilmesini ve burada nakliye yöntemini seçmeyi gerektirir. Yeni sürüm 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 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: Arka ucunuzun tasarımında halihazırda mevcut olan verilere Taslak oluşturuldu Gönderim yöntemlerini bulmaya çalışın Gönderim seçenekleri bulundu/ Gönderim seçenekleri bulunamadı - 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. Olay izleme 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 oluşturmaktır: A/B testi çerçevesi 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 adını verelim. experiment-enrollments Tüm ortamı tasarlarken, kullanıcı yolculuğu 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. experiment-enrollments Ö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. 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: experiment-enrollments , 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: - daha önce oluşturduğunuz tüm deneyleri içerir. Veritabanı bitiş noktasını her çağırdığınızda güncellenir. Experiments set /experiment-create - belirli bir kullanıcının her kaydıyla ilişkili tüm kayıtları içerir. uç noktasını her çağırdığınızda veritabanı güncellenir Experiments database experiment-enrollments - 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 durumuna güvenebiliriz. Order lifecycle database Gönderim yöntemi seçili Tasarım ve uygulama yaklaşımına genel bakış Artıları: Ortaya çıkan örnek heterojendir Örneklem büyüklüğü önceden bilinmektedir Sabit örnekleme olasılığına bağlı olarak sonuçlar hızlı bir şekilde hesaplanabilir Eksileri: Hem ön uç hem de arka uçta değişiklik gerektirir 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 Bir model oluşturun ve getirme sayacı uç noktasını gösterin: ~2 hikaye noktası [ ] [Arka uç] tanımsız Artış sayacı bitiş noktasını açığa çıkarma: ~2 hikaye noktası [ ] [Arka uç] un tanımsız Getirme ve artırma sayacı için uç noktaları gösterin: ~1 hikaye noktası [ ] [Arka uç] un tanımsız Kayıt akışları arasında geçiş yapmak için sayaç uç noktalarını çağırın: ~3 hikaye noktası [ ] [Ön uç] 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. aklınızda bulundurun ve azaltın: Ana bağımlılıkları Ö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 : sonuçlarını aradığınız deneme kimliği Giriş : 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ı Çıktı Order lifecycle database : denemenizin kapsamındaki kullanıcıların listesi ve denemeye kaydoldukları zaman damgası Giriş : bu kullanıcılarla ilişkili olan ve kullanıcı denemeye kaydolduktan sonra işlenen tüm siparişlerin son durumları Çıktı 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 uygulayabilmek bence yeterli olacaktır. veya T-Test'i Z-Test 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ı ş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. , kullanıcıların %100'ünün daha iyi sonuçlar veren gruba gireceği Daha az basit olanı, ürününüzün birden fazla platformda mevcut olmasıdır. . Bazen üzgün olmaktansa tedbirli olmak ve benzer şekilde ama başka bir platformda ayrı bir deney yapmak daha iyidir. Web akışındaki denemelerin sonuçlarının mobil uygulama akışına (veya tam tersi) uygulanacağını varsayarken ekstra dikkatli olun 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.
