Testi atmadan önce beş dalda örnek oranı uyumsuzluğunu teşhis edin.

Microsoft'ta yapılan deneylerin yaklaşık %6'sında örnek oranı uyumsuzluğu tespit ediliyor; bu da yılda 10,000 deney yapan bir ürün için günde kabaca bir tespit anlamına geliyor.Fabijan ve ark., KDD 2019Çok daha az test yapan ekipler bu rakamı nadiren görür, çünkü platformlarının çalıştırdığı kontrol, trafik hacimlerinde anlamlı bir sonuca ulaşamaz. Test temiz görünür, %4'lük bir artış bildirir, ancak yine de yanlıştır.

Bu kılavuz, deney sonuçlarını okuyup sevkiyat yapıp yapmamaya karar vermesi gereken kişi içindir. Kılavuzun sonunda, testinizin uyumsuzluk kontrolünün bir anlam ifade etmesi için yeterince büyük olup olmadığını belirleyebilecek, nedeni en hızlı bulan sırayla beş farklı teşhis dalını çalıştırabilecek ve sonuçları geçersiz kılan bir dengesizliği, etrafından dolaşıp saklayabileceğiniz bir dengesizlikten ayırabileceksiniz.

SRM alarmı size aslında ne anlatıyor?

Örnek oranı uyuşmazlığı, yapılandırdığınız bölme ile gözlemlediğiniz bölme arasındaki farktır: 50/50 ayarladınız ve 50.8/49.2 elde ettiniz. Standart kontrol, iki kollu bir test için tek serbestlik derecesine sahip pozlama sayımları üzerinde Pearson'ın ki-kare uyum iyiliği testidir.

Bu önemli çünkü kullanıcı kaybına neden olan mekanizma, ölçümünüz açısından neredeyse hiçbir zaman tarafsız değildir. Eğer bir yönlendirme, varyanttan yavaş bağlantıları kaldırırsa, hayatta kalanlar daha iyi bağlantılara sahip olanlardır ve daha iyi dönüşüm sağlarlar. Verilerde artış gerçektir, ancak gerçekte yoktur.

Çoğu ekibin ilk olarak yanlış anladığı şey şu: Sektörde kabul edilebilir bir eşik yok. Platformlar arasında bir büyüklük mertebesinden daha fazla fark var.

İki sonuç ortaya çıkar. Bir platformda işaretlenen bir test, aynı verilerle başka bir platformda geçerse, "aracımız bizi uyarmadı" ifadesi temiz bir ayrımın kanıtı değildir. Ve 0.01 eşiği, yüz sağlıklı testten birini işaretler. Üç haftalık bir test boyunca p-değerine günlük olarak bakarsanız, yanlış alarm için basit bağımsız gözlem sınırı %19'dur; gerçek rakam daha düşüktür çünkü ardışık günler güçlü bir şekilde ilişkilidir, ancak %1 değildir. Bu nedenle AB Tasty sıralı bir prosedür uygular. Platformunuz sabit ufuklu bir ki-kare testi uyguluyorsa, kümülatif sayılara bir kez, sonunda bakın.

Testinizin herhangi bir dengesizliği tespit edip edemediğini kontrol edin.

50/50'lik bir dağılım için ki-kare istatistiği 4n(p̂−0.5)²'ye basitleşir; burada n toplam maruz kalma sayısıdır. Bunu tersine çevirirseniz, kontrolünüzün işaretleyebileceği en küçük dengesizliği elde edersiniz:

Bunu bir lisans değil, bir sınır olarak okuyun. 10,000 maruz kalma durumunda, 1.3 puandan daha küçük herhangi bir dengesizlik kontrol için görünmezdir ve 1.3 puanlık bir seçim etkisi, küçük bir dönüşüm artışı yaratmak için fazlasıyla yeterlidir. Bu, bölgenin çoğunda yapısal sorundur. Türkiye, 2025 yılında yaklaşık 634,000 işletmede yaklaşık 6 milyar e-ticaret işlemi kaydetti.Ticaret Bakanlığı, 12 Mayıs 2026(yılda ortalama 9,500'e yakın) ve bu ortalama, birkaç pazar yeri tarafından oldukça yukarı çekiliyor. Orta ölçekli bir mağaza, ödeme adımını test ederken milyonlarca değil, on binlerce etkileşimle çalışır; bu nedenle SRM kontrolü, büyük hataları yakalar, daha ince ayrıntıları değil.

Bu hacimde alarma güvenmeyin. Günlük ve segment bazında ham maruz kalma sayımlarını kendiniz çekin ve p-değeri önemsiz olsa bile, sürekli aynı yönde bir kaymayı şüpheli olarak değerlendirin. Platformunuzun bu sayımları nerede gösterdiğinden emin değilseniz, SRM Denetleyici dokümantasyonu Bunları her bir araç için haritalandırır.

Beş dal, nedeni en hızlı bulan sırayla.

KDD taksonomisi, SRM nedenlerini yaşam döngüsü aşamalarına göre sıralar: atama, yürütme, günlük işleme, analiz, müdahale. Bunları farklı bir sırayla, en ucuz ve en yaygın olanlardan başlayarak teşhis edin.

1. Analiz ve tetikleme. Belirti: Ham maruz kalma günlüğünde ayrım temiz, ancak puan kartında bozuk. Kontrol: Tetikleme koşulunuz, tarih filtresi ve metrik düzeyindeki birleştirmeler olmadan oranı yeniden hesaplayın. Oran beklentiye dönerse doğrulanır. Çözüm: Herhangi bir varyanta özgü davranış uygunluğu değiştirmeden önce, tetiklemeyi her iki kolda da aynı şekilde değerlendirin. En yaygın yanlış alarm, elemek için on dakika.
2. Günlük işleme. Belirti: İki işlem hattı arasında maruz kalma sayıları farklılık gösteriyor veya ETL adımından sonra bir boşluk oluşuyor. Kontrol: Aynı zaman dilimi için SDK tarafındaki sayıyı, veri ambarı sayısını ve raporlama sayısını karşılaştırın, ardından her bir kol için bot filtresi dışlama oranlarını karşılaştırın. Yukarı akışta kolların eşit, aşağı akışta ise eşit olmaması durumunda doğrulanır. Çözüm: Filtrelemeyi belirleyici ve özdeş şekilde yapın. Otomatik trafik, 2024'teki %51'den 2026'da web trafiğinin %53'üne ulaştı.Imperva Kötü Amaçlı Bot Raporu, 29 Nisan 2026Bu nedenle, yükleme zamanlamasına veya kullanıcı aracısı davranışına dayalı sezgisel bir filtre, her varyant için farklı oranlarda dışlama yapabilir. Onay odaklı kayıp da burada yer alıyor: ad_storage Reddedilirse, Google'ın etiket platformu reklam çerezlerini ayarlamayı durdurur (Google etiket platformu onay belgeleriDolayısıyla, bir testte coğrafi bölgeler arasında ret oranları farklılık gösteriyorsa, bu tanımlayıcılara dayanan herhangi bir atama, kullanıcıları dengesiz bir şekilde kaybetmeye yol açar.
3. Yürütme. Belirti: Dengesizlik sayfa ağırlığıyla birlikte artar, mobil cihazlarda daha kötüdür veya dağıtım anında başlar. Kontrol: Oranı cihaza, tarayıcıya, bağlantı türüne ve güne göre ayırın; kollar arasındaki maruz kalma süresini karşılaştırın. Açığın yavaş segmentlerde mi yoksa tek bir tarayıcıda mı yoğunlaştığını doğrular. Çözüm: Yönlendirme testleri burada başarısız olur. Bir yönlendirme yalnızca bir kola tam bir navigasyon ekler ve bu sırada ayrılan herkes seçici bir kayıptır. Her iki varyantı da tek bir URL'de sunucu tarafında işleyin veya kolların karşılaştırılabilir olmadığını kabul edin.
4. Görev. Belirti: Oran ilk saatten itibaren bozuk ve sabit bir faktörle bozuk kalıyor. Kontrol: Aynı tahsisat üzerinde bir A/A çalıştırın ve hash tuzunun bu popülasyon üzerinde daha önceki bir deneyden yeniden kullanılmadığını doğrulayın. A/A'nın da dengesizliği göstermesi bunu doğrular. Çözüm: Yeni bir tuzla yeniden atama yapın ve yeniden başlatın. Önceki bir testten kalan veriler bunun sessiz versiyonudur ve yalnızca A/A bunu ortaya çıkarır.
5. Girişim. Belirti: Dengesizlik, az sayıda yüksek aktiviteli tanımlayıcıda veya dahili IP aralıklarında yoğunlaşmıştır. Kontrol: Kullanıcı başına maruz kalma sayısı dağılımını ve olay hacmine göre en yüksek %1'lik tanımlayıcıları kontrol edin. Bunların kaldırılmasının oranı geri getirip getirmediğini doğrulayın. Çözüm: Dahili ve komut dosyasıyla çalışan trafiği elle değil, belgelenmiş bir kural kullanarak hariç tutun, böylece hariç tutma işlemi bir sonraki seferde de aynı olur.

Ayrıntılı bir inceleme

Aşağıdaki rakamlar örnek niteliğindedir, müşteri verileri değildir. Bir ödeme testi, 61,480 kontrol ve 58,520 varyant maruziyeti raporlamıştır: 120,000 kullanıcıda 51.2/48.8, ki-kare p değeri 0.001'in altında. Dal 1: Tetikleme koşulunun kaldırılması 60,020 / 59,980 sonucunu verir, bu nedenle atama doğrudur ve kayıp maruziyetten sonra gerçekleşir. Dal 2: İşlem hattı sayıları uyumludur, her iki kolda da bot dışlamaları %0.9'dur. Dal 3: Masaüstü 50.1/49.9, mobil 52.4/47.6'dadır ve varyantın ortalama maruz kalma süresi mobil cihazlarda 900 ms daha yüksektir. Teşhis: Varyant, fazladan bir render engelleme isteği gönderir, mobil kullanıcılar bu sırada terk eder, hayatta kalanların bağlantıları daha iyidir. Okuma geçersizdir. Düzeltme bir performans düzeltmesidir ve test yeniden yorumlanmaz, yeniden çalıştırılır.

Kurtarabileceğiniz ve kurtaramayacağınız şeyler

• Okuma işlemini geçersiz kılın Kayıp mekanizmasının ölçütle makul bir şekilde ilişkilendirilebileceği durumlarda. Her yürütme ve atama nedeni varsayılan olarak bu kategoriye girer.
• Segment bazında kurtarma Dengesizlik yalnızca net bir şekilde hariç tutabileceğiniz bir segmente sınırlı olduğunda, bu segment ölçüme bakmadan önce tanımlandığında ve geri kalan kısım kendi SRM kontrolünden geçtiğinde geçerlidir. Üçte ikisi yeterli değildir.
• Testi saklayın. Sorunun tamamen analizden kaynaklandığı ve düzeltilmiş puan tablosunun başarılı olduğu durumlarda, aynı verileri sabit bir filtreyle yeniden okuyorsunuz, veri avlama işlemi yapmıyorsunuz.
• Her iki şekilde de kaydedin. Deneyde hata kategorisini kaydedin. Taksonomi kümülatif olarak fayda sağlar: Son on testinizden üçü 3. dalda başarısız olduysa, sorununuz deney değil, ön uç teslimatıdır. [DAHİLİ VERİ GEREKLİ: Microsoft'un %6'lık kıyaslama ölçütünü bu pazardan bir rakamla değiştirmek için, son 24 ayda Switas tarafından yürütülen ve SRM kontrolünden geçemeyen deneylerin taksonomi dalına göre ayrılmış oranı]

Bu durumun bozulduğu nokta

Bu ağaç, sabit, bilinen bir tahsis ve kullanıcı düzeyinde rastgeleleştirme ile iki kollu bir testi varsayar. Tüm kollarda tam ki-kare değerine ve hangi çiftin hatalı olduğuna dair bir takip testine ihtiyaç duyan çok kollu testleri veya beklenen oranın test sırasında değiştiği ve kümülatif ki-kare testinin tamamen yanlış bir test olduğu kademeli tahsisleri kapsamaz. Birimin kullanıcı olmadığı ve önemli olan dengesizliğin küme özelliklerinde olduğu küme veya coğrafi rastgeleleştirilmiş tasarımlara uygulanmaz. Metrik tanımınızın doğru olup olmadığı hakkında hiçbir şey söylemez. Ve maruz kalmalar kaydedilmediğinde ve atamayı bir metrik olaydan çıkardığınızda (bu bir bölünmüş kontrol değil, bir tahmindir) yardımcı olamaz.

SSS

51/49'luk bir bölünme her zaman sorun mudur? Bu tamamen n değerine bağlıdır. 5,000 pozlamada sıradan bir gürültüdür; 500,000 pozlamada ise neredeyse kesin bir kusurdur. Oranı, sabit bir yüzde kuralına göre değil, tespit edilebilirlik tablosuna göre değerlendirin.

Koşuyu yeniden başlatmak yerine, kolların ağırlığını istatistiksel olarak yeniden ayarlayabilir miyim? Hayır. Yeniden ağırlıklandırma, sayımları düzeltir ve seçimi olduğu gibi bırakır. Kaybettiğiniz kullanıcılar artık yok ve bunlar rastgele seçilmiş bir örneklem değildi.

SRM p-değerine ne sıklıkla bakmalıyım? Platformunuz sıralı bir işlem yürütmediği sürece, sonuçlar en sonda, kümülatif sayılar üzerinden değerlendirilmelidir. Sabit ufuklu ki-kare değerine günlük olarak bakmak, yanlış alarmları önemli ölçüde artırır.

SRM, güvenlik önlemlerini de geçersiz kılıyor mu? Evet, aynı sebepten dolayı. Eğer kollar farklı nüfus gruplarını barındırıyorsa, düz bir korkuluk, hareketli birincil ölçüm noktasından daha güvenilir değildir.

Peki ya A/A testi de uyumsuzluk gösterirse? O halde sorun, sizin uyguladığınız yöntemde değil, atama veya kayıt işlem hattındadır. Başka bir şey çalıştırmadan önce bunu düzeltin, çünkü bu durum platformdaki her testi etkiliyor.

Yönlendirme testleri her zaman SRM'ye neden olur mu? Her zaman olmasa da, eklenen navigasyonun yalnızca bir kolda bulunması nedeniyle, başka hiçbir tasarımda olmayan yapısal bir risk taşırlar. Eğer mutlaka kullanmanız gerekiyorsa, herhangi bir ölçüm okumadan önce bağlantı hızı ve cihaza göre oranı kontrol edin.

Trafik sayım çok düşük, bu yüzden çekin hiçbir anlamı yok. O zaman ne olacak? Günlük ham pozlama sayımlarını sürekli sapma açısından izleyin, atama katmanında periyodik bir A/A işlemi gerçekleştirin ve daha uzun bir doğrulama kontrolleri listesini önceden kaydedin. İstatistiksel gücün yerine süreci koyuyorsunuz.

Bot filtrelemesi atamadan önce mi yoksa sonra mı yapılmalı? Maruz kalma kaydının ardından, analizden önce, her iki kola da aynı şekilde uygulanan deterministik kurallar kullanılır. SDK içindeki sezgisel filtreleme, filtrenin kendisinin nasıl uyumsuzluğa dönüştüğünü açıklar.

Kendi deney programınızda denetimi gerçekleştirin.

Şu anda çalıştırdığınız testlerin bölünmüş sağlık durumuna ikinci bir gözle bakmak veya bunların bağlı olduğu atama ve günlük kaydı katmanının incelenmesini istiyorsanız, işte tam olarak bunu sunuyoruz. CRO ve deney hizmeti yapar.

kaynaklar

• Fabijan, Gupchup, Gupta, Omhover, Vermeer, Dmitriev, "Çevrimiçi Kontrollü Deneylerde Örnek Oranı Uyumsuzluğunun Teşhisi: Uygulayıcılar İçin Bir Taksonomi ve Pratik Kurallar", KDD 2019
• AB Tasty dokümantasyonu, Örnek oranı uyuşmazlığı (sıralı S-SRM, eşik 0.01)
• Statsig, "Örneklem oranı uyumsuzluğuna hızlı bir rehber", 31 Ağustos 2023 (ki-kare, eşik 0.01)
• GrowthBook dokümantasyonu, Deneme (ki-kare, 0.001'in altında uyarı)
• Imperva, "Kötü Bot Raporu 2026: Ajan Çağında Botlar", 29 Nisan 2026
• Türkiye Cumhuriyeti Ticaret Bakanlığı, 2025 e-ticaret rakamları, 12 Mayıs 2026
• Google etiket platformu, Onay modu ve depolama davranışı
• SRM Denetleyicisi dokümantasyonu ve SSS, Lukas Vermeer