Numune Oranı Uyuşmazlığı (SRM): Müşteri Vakalarına Çözümler İçeren Eksiksiz Bir Kılavuz

Başarısız bir testten daha kötü olan nedir?

Test sonuçlarını güvenilmez hale getiren test veri kalitesi sorunları.

Ancak kötü verilerden nasıl uzak durabilirsiniz?

Numune Oranı Uyuşmazlığını (SRM) kontrol etmek, olası sorunları erkenden yakalamanın basit bir yoludur. Bir şey şüpheliyse, ne kadar erken öğrenirseniz o kadar iyi.

Numune Oranı Uyuşmazlığı, nasıl tespit edileceği, testlerinizi nasıl etkilediği ve hangi A/B test platformlarının yerleşik SRM kontrolleriyle birlikte geldiği hakkında daha fazla bilgi edinmek için okumaya devam edin (böylece bir elektronik tabloyu yan tarafta tutmanıza gerek kalmaz) .

Numune Oranı Uyuşmazlığı (SRM) Nedir?

Numune Oranı Uyuşmazlığı veya SRM, gerçek numune sayısı (veya bir tedavi grubundaki ziyaretçiler) beklenenle eşleşmediğinde A/B testinde meydana gelir.

Bunu bir örnekle açıklayalım.

Bir web sitesinin haftada yaklaşık 15 bin ziyaretçi aldığını varsayalım. Orijinal (değişmeyen sayfa olan) ve 2 varyasyon olmak üzere 3 varyasyonumuz var. Trafik eşit olarak dağıtılırsa her birinin ne kadar trafik almasını bekliyorsunuz? İdeal bir dünyada cevap, her varyasyonun 15.000 / 3 = 5000 ziyaretçi alması gerektiğidir.

Şimdi, her varyasyonun 5000 ziyaretçi alması pek olası değildir, ancak buna çok yakın bir sayı, 4982 veya 5021 gibi. Bu küçük değişiklik normaldir ve basit rastgelelikten kaynaklanır! Ancak varyasyonlardan biri 3500, diğerleri 5000 civarında ziyaretçi alacaksa, o zaman bunda bir sorun olabilir!

Bu sorunları tespit etmek için kendi sezgimize güvenmek yerine, bunun yerine SRM testine gidebiliriz. Örneğin, alınan diğer ziyaretçi sayısına kıyasla 4850 veya 4750 ziyaretçinin “normal” olup olmadığını bize söylemek için Ki-kare uyum iyiliği testini kullanır!

İstatistiksel olarak, Ki-kare uyum iyiliği testi, gözlemlenen örnek sayısını beklenen örneklerle karşılaştırır. Ve gerçek bir fark varsa, p-değeri, %99 güvene karşılık gelen 0,01'lik ayarlanan anlamlılık düzeyinden daha düşük olacaktır.

A/B Testinizin SRM'si Var mı? Numune Oranı Uyuşmazlığı Nasıl Hesaplanır?

A/B testinde, SRM gerçek bir öcü olabilir ve yanlış sonuçlara ve yanlış yönlendirilmiş sonuçlara neden olabilir. İyi haber şu ki, baş ağrısından kaçınmanıza yardımcı olabilecek araçlar var.

E-tabloları Kullanma

E-tablolar, Microsoft Excel ve/veya Google Ürünlerinin yaygın olarak bulunması nedeniyle SRM'yi hesaplamanın en basit yöntemidir.

Size başka bir örnek gösterelim.

Orijinal ve Varyasyon için sırasıyla 50/50 trafik dağılımı ve gözlemlenen ziyaretçi sayısı 214.598 ve 241.156 olan bir A/B testi için SRM'yi hesaplayacağız.

Gözlemlenen trafik bölünmesinin beklenen trafik bölünmesiyle eşleşip eşleşmediğini görmek için Ki-kare testini kullanacağız. Aksi takdirde, gözlemlenen değerlerin beklenen değerlerden endişe yaratacak kadar farklı olup olmadığını bilmek ve sonuçların iptal edilmesini sağlamak isteyeceksiniz.

Aşağıdaki e-tabloda gösterildiği gibi, p-değerini hesaplamak için e-tablonuzdaki CHISQ.TEST işlevini kullanmanız gerekir.

Örneğimizde, p değeri 0'dır. 0,05'in altında bir p değeriyle, elinizde bir SRM ve çoğu durumda test bulgularını reddetmek için yeterli kanıt vardır.

Çevrimiçi Numune Oranı Uyuşmazlığı Hesaplayıcılarını Kullanma

1. Convert'in hesaplayıcısı, örnek oran uyumsuzluğunun teşhisine yardımcı olabilir ve ayrıca denemenizin tamamlanması için ne kadar beklemeniz gerektiğini de söyler!
   

   

2. SRM'ye özel başka bir çevrimiçi hesap makinesi, Lukas Vermeer tarafından tasarlanan hesaptır. Bu yöntem, SRM'yi önceki teknikle aynı şekilde hesaplar, bu nedenle süreci takip ettiyseniz ve anladıysanız, bu çevrimiçi SRM hesaplayıcısını kullanabilmelisiniz. Numuneleriniz için sayıları doldurun ve sonuç böyle görünecek
   

   

SRM, A/B Testlerini Nasıl Etkiler?

Bir deneme sırasında varyantlar arasındaki trafik dağılımına bakmış ve bunun ne kadar doğru olduğunu sorgulamış olabilirsiniz.

Belki biri aşağıdaki rapora benziyor. Bakabilir ve Orijinal'in 1330 ziyaretçisi varken Varyasyon 1713'ün normal olup olmadığını merak edebilirsiniz.

SRM oranının kısa bir istatistiksel hesaplaması (yukarıdaki iki yöntemden birini kullanarak) size varyasyon oranının kabul edilebilir olup olmadığını söyleyecektir.

İki varyasyon (Orijinal ve Varyasyon 1) arasındaki gerçek ayrım, beklenen değerlere karşılık geliyor mu? Durum böyle değilse, sorunu çözdüğünüzde verileri reddetmeli ve testi yeniden başlatmalısınız.

SRM, hem Frequentist hem de Bayesian İstatistik Modellerini Etkiler mi?

Evet.

Veriler Bayesian (Google Optimize, Optimizely, VWO, A/B Tasty) veya Frequentist (Deneyimleri Dönüştür, Dinamik Verim) yaklaşımlarıyla analiz edilsin, SRM'nin nedenleri, bir deneyin sonuçlarının geçerliliği üzerinde aynı etkiye sahiptir.

Dolayısıyla, yukarıdaki SRM hesaplayıcıları, Bayes istatistiklerini kullanan platformlarda SRM'yi kontrol etmek için de kullanılabilir.

SRM'yi Ne Zaman Dikkate Almalısınız?

Testlerinizde Numune Oranı Uyuşmazlığı bulmanız, sonuçları iptal etmeniz gerektiği anlamına gelmez.

Peki SRM hesaplamasını ciddiye almak ne zaman gerçekten gerekli?

Birkaç örnekle öğrenelim.

Örnek 1

Orijinalin ve Varyasyonun her birine kullanıcıların %50'sinin atandığı bir deneme çalıştırıyorsunuz. Bu nedenle, her birinde yaklaşık olarak eşit sayıda kullanıcı görmeyi beklersiniz.

Sonuçlar olarak geri geliyor

• Kontrol: 21.588 kullanıcı
• Tedavi: 15,482 kullanıcı

Bunları SRM Denetleyicisinden geçirelim:

Bu endişe nedeni mi?

Yukarıdaki örnek oranı için p değeri <0,0001'dir, bu nedenle, eşit oranlar gerektiren bir tasarım altında bu oranın veya daha uç bir oranın görülme olasılığı <0,0001'dir!

Son derece olası olmayan bir olayı gözlemlediğiniz için, bir şeylerin yanlış olduğundan kesinlikle endişelenmelisiniz . Bu nedenle, deneyin uygulanmasında bazı hatalar olması daha olasıdır ve sonuçların hiçbirine güvenmemelisiniz.

Örnek #2

Orijinal ve Varyasyona eşit kullanıcı yüzdesinin atandığı başka bir deneme çalıştırırsınız. P-değerini hesaplarsınız ve bu <0,002, yani pek olası olmayan bir olaydır.

Metrikler ne kadar kapalı olabilir? Gerçekten sonuçları atmak zorunda mısınız?

Deneyimleri Dönüştür gibi bir deneme platformu kullanarak, sonuçlara bazı test sonrası segmentasyon uygulayabilir ve Internet Explorer kullanıcılarını hariç tutarsanız SRM'nin gittiğini öğrenebilirsiniz.

Bu durumda, dışlanan kullanıcılar büyük olasılıkla SRM'nin nedeni olan eski bir IE tarayıcısı kullanırlar; Bir bot, Varyasyondaki bazı değişiklikler nedeniyle doğru şekilde sınıflandırılmadı ve oran uyumsuzluğuna neden oldu.

Segment olmadan, kalan kullanıcı yüzdesi uygun şekilde dengelenir ve metrikler normal görünür.

SRM keşfedilmemiş olsaydı, tüm deney büyük bir başarısızlık olarak kabul edilecekti.

Ancak SRM bir kez tespit edildiğinde, küçük bir parça çıkarılabilir ve deney uygun analiz için kullanılabilir.

Benzer bir senaryoda, hariç tutulan kullanıcıları güvenle yok sayabilir ve deneme kullanılabilir .

Örnek 3

Bir deney yaparsınız ve testinizde etiketlenmiş SRM olduğunu öğrenirsiniz.

Ancak grafiklerinize dikkat ederseniz, dönüşüm oranı eğrilerinin paralel kaldığını ve hesaplanan güvenin %99,99 olduğunu fark edeceksiniz. Bu model, testlerin geçerli olduğu konusunda size yeterince kesinlik sağlamalıdır.

Bu durumda, SRM'yi güvenle yok sayabilir ve verilerinize güvenmeye devam edebilirsiniz .

SRM'nin Var Olup Olmadığını Nerede Kontrol Etmelisiniz?

SRM'nin oluşabileceği birkaç alan vardır. Lukas Vermeer'in nedenler sınıflandırmasına bir göz atalım:

1. Deneme Ataması – Yanlış kovalama (kullanıcıların yanlış kümelere yerleştirilmesi), hatalı bir rastgeleleştirme işlevi veya bozuk kullanıcı kimlikleri olabilir.
2. Deneme Yürütme – Varyasyonlar farklı zamanlarda başlamış olabilir (tutarsızlıklara neden olur) veya filtre yürütme gecikmeleri olabilir (hangi grupların deneye tabi tutulacağını belirleme).
3. Deney Günlüğü İşleme – Gerçek kullanıcıları kaldıran otomatik botlar, günlüklere gelen bilgide gecikme.
4. Deney Analizi – Varyasyonun yanlış tetiklenmesi veya yanlış başlatılması.
5. Deney Müdahalesi – Deney, saldırılara ve bilgisayar korsanlarına maruz kalabilir veya devam eden başka bir deneyin etkileri mevcut deneyi engelliyor olabilir.

Bir SRM'niz varsa ve cevabı nerede arayacağınızdan emin değilseniz, yukarıdaki sınıflandırma başlamak için değerli bir yerdir.

İşleri daha açık hale getirmek için, şimdi size bu vakaların her biri için gerçek hayattan bir örnek vereceğiz.

Deney Ataması

Burada dikkat etmeniz gereken en ilginç şeylerden biri, A/B test platformunuzun kullandığı rastgeleleştirme işlevidir.

Aşağıdaki örnekte, Wish'teki veri bilimcileri, bir A/A testinde SRM sorunlarını keşfettiler ve uzun bir araştırmadan sonra, SRM'nin, rastgeleleştirmelerinin tamamen rastgele olmadığı için ortaya çıktığı sonucuna vardılar.

Geçerli deney bulguları elde etmek için randomizasyon prosedürü çok önemlidir.

A/B testinde kullanılan istatistiksel testlerin önemli bir varsayımı, rastgele örneklerin kullanılmasıdır. Deneme grupları arasında, rastgeleleştirme, hem gözlemlenen hem de gözlemlenmeyen kullanıcı özelliklerini dengeler ve test edilen ürün özelliği ile deneme bulgularındaki herhangi bir sonuç farkı arasında nedensel bir ilişki kurar.

Deneme Yürütme

Deney yürütme söz konusu olduğunda, deneyimlerinizde SRM'ye neden olabilecek iki ana neden vardır.

1. Komut dosyası, Varyasyonlardan birine doğru yüklenmemiş

A/B test platformunuzun komut dosyasının Orijinal ve Varyasyonlara doğru yüklenip yüklenmediğini her zaman kontrol edin.

Müşteri destek ekibimiz yakın zamanda, Dönüştürme komut dosyasının varyasyonlardan birine eklenmediği ve testte bir SRM'ye neden olduğu bir durumu çözdü.

Komut dosyasını, aşağıda gösterildiği gibi, deneyimin çalışmasını istediğiniz tüm sayfalara eklediğinizden emin olun:

2. Sayfa hedefleme yanlış yapılandırılmış

Bu durumda, SRM uyumsuzluğu, testin hedeflemesinin yanlış ayarlanmasından kaynaklanır.

Yanlış kurulumda, bazı ziyaretçiler varyasyona yönlendirilmek üzere seçilir, ancak büyük olasılıkla orijinal URL ifadesi, testte gruplandırılan ve yönlendirilen tüm ziyaretçilerin her URL'siyle eşleşmediğinden yeniden yönlendirme başarısız olur.

Bunu önlemek için, deneme varyasyonu URL'leri ifadelerini yeniden yapılandırın ve testi yeniden çalıştırın.

Bölünmüş URL testlerinde SRM'den kaçınmak için Deneyimleri Dönüştür ile sayfa hedeflemenizi nasıl ayarlayacağınızı gösteren iki senaryo daha.

Senaryo 1: Yalnızca Bölünmüş URL ile ana sayfayı (https://www.convert.com) hedefleyin ve ziyaretçilerin sahip olabileceği tüm sorgu parametrelerini iletin

Burada, Site Alanında, Sayfa URL'sinin https://www.convert.com ile tam olarak eşleşmesi gerekir. Dışlama bölümünde, Sorgu Dizesi, herhangi bir yeniden yönlendirmeyi önlemek için v1=true içermelidir (çünkü, https://www.convert.com ?v1=true ve trafik ile sonuçlanırsanız denemenin koşulları yine de eşleşecektir). dağıtım düzensiz sonuçlanabilir).

Ardından, varyasyonlarınızı tanımlarken bunu şu şekilde tutun:

Senaryo 2: Bölünmüş URL ile yalnızca ana sayfayı (https://www.convert.com) değil tüm sayfaları hedefleyin ve sorgu parametrelerini iletin

Burada Site Alanınızı https://www.convert.com içeren bir “Sayfa URL'si” ile tanımlamanız gerekir. Dışlama bölümünde, sorgu v1=true içermelidir.

Varyasyonları tanımlarken, tüm sayfaları yakalamak için aşağıdaki normal ifade tarifini kullanın:

Deney Günlüğü İşleme

Burada, SRM'lerin ana nedeni olarak, deneyiminizi hedefleyebilecek botları belirliyoruz. Kullanıcı aracıları üzerinde herhangi bir olağandışı kalıp bulabilirsek, tuttuğumuz ek günlükleri kontrol etmek için bizimle iletişime geçebilirsiniz.

Örneğin, destek ekibimiz, testinde SRM olan bir müşteriye yardım etti.

Onların durumunda, raporu Browser=Other ile filtrelediğimizde, düzensiz bir bölünme ve SRM gördük. Ancak aynı raporu Browser=Chrome+Safari'ye göre filtrelediğimizde, hiçbir SRM algılanmadı ve eşit olmayan bir dağılım olmadı.

Bu nedenle, Tarayıcıyı Diğer olarak ayarlayan birkaç olayı kontrol ettik ve hepsinde "site24x7" Kullanıcı Aracısı gösterildi. Bunun bir tür izleme yazılımı olduğunu hemen anladık; bu, reklam yaptığı ve ayrı bir kullanıcı aracısı kullandığı için şanslı. Bu, normal bir Kullanıcı Aracısının arkasına gizlenmiş olsaydı, onu bulmak imkansız olurdu.

Sorunu çözmek için devam ettik ve bu Kullanıcı Aracısını trafikten hariç tuttuğumuz botlar listesine ekledik. Ne yazık ki bu değişikliğin, botu listeye eklediğimiz andan itibaren gelecekteki veriler üzerinde bir etkisi olabilir, ancak en azından bulundu ve düzeltildi.

Deney Analizi

Bu kategori esas olarak manuel tetikleme ile ayarlanan deneyimleri etkiler.

Bu, örneğin, tetiklemeyi kendiniz halletmeniz gereken Tek Sayfa Uygulamalarında olur.

Bu nedenle, aşağıdakine benzer bir kod kullanarak bunu manuel olarak yapmanız gerektiğinde, testinizdeki potansiyel SRM'lere çok dikkat edin.

 window._conv_q = _conv_q || [];
window._conv_q.push(["run","true"]);

Deneme Girişimi

Bu, deneyim sırasında varyasyonlardan birinin duraklatıldığı bir kullanıcı müdahalesini ifade eder. Birkaç haftadır devam eden bir Bölünmüş URL testiniz olduğunu ve yanlışlıkla veya bilerek Varyasyonu duraklattığınızı ve yalnızca Orijinal'i çalışır durumda bıraktığınızı düşünün.

Hemen ardından ve web sitenizin trafiğine bağlı olarak, testiniz için hesaplanan SRM'yi göreceksiniz.

Bu durumda, varyasyonun duraklatıldığı tarih aralığını hariç tutabilir veya deneyim verilerini sıfırlayabilirsiniz.

Deneme Dışı Nedenler

Yukarıdaki kategorilerden hiçbiri SRM'nizin temel nedenini ortaya çıkarmıyorsa, sitenizle ilgili daha derin sorunları belirlemek için web sitenize (Sentry gibi) bir hata izleme yazılımı eklemenizi öneririz.

SRM Uyarılarını Destekleyen A/B Test Platformları

Hangi A/B test platformlarının bu SRM işlevini desteklediğini ve kendiniz hesaplamanıza gerek kalmadan size uyarı verdiğini merak ediyor olabilirsiniz.

Araştırmayı bitirdik ve bir araç listesi derledik.

Deneyimleri Dönüştür

Aralık 2021 itibariyle kendi SRM yöntemimizi uygulamaya koyduk.

Bir kullanıcıysanız, Proje Yapılandırması > Diğer Ayarlar'dan SRM kontrollerini etkinleştirebilirsiniz.

Ardından, raporlarda SRM etiketlerini görebileceksiniz:

en iyi şekilde

Eylül 2021'de, herkesin SRM'yi algılamak için uygulayabileceği bir sıralı test çözümünü açık kaynaklı olarak optimize edin.

Optimizely, ssrm testini, aynı anda çalışan tüm deneylerde çalışabilen, üretime hazır bir arka uç mikro hizmetine dönüştürdü.

Optimizely'nin sonuçlar sayfasında, uyarılar ayarlayabilir ve ssrm-testinden gerçek zamanlı sonuçlar alabilirsiniz:

Optimizely Staff İstatistikçisi Michael Lindon, SRM'nin testler kötü yapıldığında ortaya çıkan tipik bir sorun olduğunu söylüyor.

Bir ürün denemesi çalıştırmak için önemli miktarda altyapı gereklidir, bu nedenle hatalar olabilir. Örneğin, web sitesi ziyaretçileri tutarlı bir şekilde bir deneme varyasyonuna dahil edilmez ve hem orijinal hem de varyasyon koşullarında dönüşüm yapmazsa, bu kullanıcı için elde edilen veriler, denemenin etkisini değerlendirmek için geçerli değildir.

Asıl endişe, SRM'nin ölçümlerinizi etkileyebilecek ve tespit edilemeyecek yanlış veriler üretmesidir.

MiaProva aracılığıyla Adobe Target

Nisan 2021'de Adobe Target, A/B etkinlikleriyle ilgili SRM uyarıları sağlamak için MiaProva ile ortaklık kurdu.

Bu uyarılar, bir uyumsuzluk algılandığında Adobe Target kullanan MiaProva müşterilerini bilgilendirir. Bu yaklaşım, her canlı A/B testine otomatik olarak bir Ki-Kare testi uygular.

BüyümeKitabı

GrowthBook, Bayes istatistik motoruna ve her deney için otomatik SRM kontrollerine sahip açık kaynaklı bir A/B test platformudur.

Her deney, bir SRM arar ve tanımlandığında kullanıcıları uyarır.

Belirli bir trafik dağılımını tahmin ettiğinizde (örneğin 50/50), ancak bunun yerine çok farklı bir şey gördüğünüzde (örneğin 40/60), bir uyarı alırsınız. Bu, yalnızca p değeri 0,001'den küçükse görüntülenir ve bunun tesadüfen meydana gelme olasılığının çok düşük olduğunu gösterir.

Böyle bir testin sonuçlarına, potansiyel olarak aldatıcı oldukları için güvenilmemelidir, bu nedenle uyarı. Bunun yerine, kullanıcılar deneyi yeniden başlatmadan önce hatanın kaynağını bulmalı ve düzeltmelidir.

Split.io

Split, özellik bayrak yönetimine, yazılım denemelerine ve sürekli teslimata güç veren bir özellik dağıtım platformudur.

Her hesaplama güncellemesiyle, Split platformu, hedeflenen ve mevcut örnek oranları arasında önemli bir fark olup olmadığını görmek için örnek oranını kontrol eder. Bu örnek oran kontrolü, süre ve son güncelleme gibi diğer önemli ayrıntılarla birlikte, anahtar ve organizasyon metriklerinin özetinin altında bulunabilir.

Örnek Boyutu Oran Uyuşmazlığı Demystified

Bir SRM görmenin ne sıklıkla “normal” olduğunu sorabilirsiniz.

Lukas Vermeer en iyisini söyledi. Büyük teknoloji firmaları bile çevrimiçi kontrollü deneylerinde %6 ila %10 arasında doğal bir SRM frekansı gözlemliyor.

Şimdi, SRM daha sık tekrar ederse, bu, deney tasarımı veya web sitesi hakkında daha derin bir araştırmayı garanti eder.

Yukarıdakilere benzer sorunlar yaşıyorsanız, ekibimiz her zaman size yardımcı olmaya hazırdır! Ekibimize ulaşmak için buraya tıklayın.