SQL'de Artış, Anlamlılık ve Güvenlik Kontrolleri
Dönüşüm artışının ve bozuk bir deneyi işaretleyen veri kontrollerinin hesaplanması.
SQL'de Artış, Anlamlılık ve Güvenlik Kontrolleri, CoddyKit'te ücretsiz bir Coding Interview Prep dersidir. Bu, 4 dersinin 4. dersidir. Aşağıdan dersin tamamını ücretsiz okuyabilir, sonra tarayıcıda yerleşik kod editörü ve 7/24 yapay zeka koçu ile uygulamalı olarak pratik yapabilirsin. Bu, Coding Interview Prep öğrenme yolunun bir parçasıdır ve ilerlemeniz web ve CoddyKit uygulaması arasında senkronize olur. Coding Interview Prep kursu toplamda 4 dersten oluşur.
Metriklerden Karara
Varyant başına dönüşüm yalnızca başlangıçtır. Mülakat sorusu şudur: uygulama gerçekten daha iyi sonuç verdi mi? Bunun için artışı hesaplamanız, farkın gerçek mi yoksa rastlantısal dalgalanma mı olduğunu değerlendirmeniz ve bozulmuş bir deneyi ortaya çıkaran koruyucu metrikleri kontrol etmeniz gerekir.
SQL içinde kapsamlı bir istatistik paketi çalıştırmayacaksınız; ancak mülakat yapanların görmek istediği girdileri ve yaklaşık bir anlamlılık göstergesini hesaplayabilirsiniz.
Varyant Başına Özet CTE'si
Bundan sonraki her şey düzenli bir özetin üzerine kurulur: varyant başına kullanıcı sayısı n, dönüşüm gerçekleştiren kullanıcı sayısı c ve dönüşüm oranı p. Bunu bir kez CTE içinde hesaplayıp yeniden kullanın.
WITH summary AS (
SELECT
variant,
COUNT(DISTINCT user_id) AS n,
COUNT(DISTINCT converted_user) AS c
FROM experiment_flat
GROUP BY variant
)
SELECT
variant, n, c,
1.0 * c / n AS p
FROM summary;Mutlak ve Göreli Artış
Artışın iki tanımı vardır ve mülakat yapanlar varsayılan olarak göreli olanı bekler:
- Mutlak artış = p_uygulama - p_kontrol (yüzde puanı).
- Göreli artış = (p_uygulama - p_kontrol) / p_kontrol (yüzdesel iyileşme).
"2 puanlık artış" ile "%20 göreli artış" aynı sonucu ifade edebilir. Hangisini kullandığınızı açıkça belirtin.
Kendi Kendine Döndürmeyle Artışı Hesaplama
İki varyantı tek satırda karşılaştırmak için koşullu toplulaştırmayla kontrol ve uygulama değerlerini yan yana alın, ardından aritmetiği yapın.
Bu yaklaşım, kırılgan bir kendi kendine birleştirmeyi önler ve artış formülünün okunabilir kalmasını sağlar.
WITH s AS (
SELECT variant,
COUNT(DISTINCT user_id) AS n,
COUNT(DISTINCT converted_user) AS c
FROM experiment_flat GROUP BY variant
),
rates AS (
SELECT
MAX(CASE WHEN variant='control' THEN 1.0*c/n END) AS p_ctrl,
MAX(CASE WHEN variant='treatment' THEN 1.0*c/n END) AS p_trt
FROM s
)
SELECT
p_ctrl, p_trt,
p_trt - p_ctrl AS abs_lift,
ROUND(100.0 * (p_trt - p_ctrl) / p_ctrl, 2) AS rel_lift_pct
FROM rates;Fark Neden Rastlantısal Dalgalanma Olabilir
Uygulama grubundaki daha yüksek oran, rastgele örnekleme şansından kaynaklanabilir. Anlamlılık şu soruyu sorar: varyantlar gerçekten özdeş olsaydı bu kadar büyük bir farkın ortaya çıkma olasılığı ne olurdu?
Temel unsur, her oranın standart hatasıdır; örneklem büyüklüğü arttıkça bu hata küçülür. Büyük örneklemler küçük artışları güvenilir kılar; küçük örneklemler ise büyük artışları bile şüpheli hale getirir.
Bir Oranın Standart Hatası
n kullanıcı üzerindeki p dönüşüm oranı için standart hata sqrt(p * (1 - p) / n) şeklindedir. Bunu doğrudan SQL içinde her varyant için hesaplayın.
Bu, oranları karşılaştırmadan önce her orandaki dalgalanmayı nicelendirir.
WITH s AS (
SELECT variant,
COUNT(DISTINCT user_id) AS n,
COUNT(DISTINCT converted_user) AS c
FROM experiment_flat GROUP BY variant
)
SELECT
variant, n,
1.0 * c / n AS p,
SQRT( (1.0*c/n) * (1 - 1.0*c/n) / n ) AS std_err
FROM s;İki Oran İçin Z Puanı
Yaklaşık bir anlamlılık göstergesi, iki oran için z puanıdır: oranlar arasındaki farkın, bu farkın standart hatasına bölümü. Mutlak değerin yaklaşık 1.96'nın üzerinde olması, yaygın %95 eşiğine karşılık gelir.
Bunun bir yaklaşık hesap olduğunu ve uygun bir istatistiksel sınamanın yerine geçmediğini açıkça belirtin; yine de SQL içinde "bu fark makul ölçüde gerçek mi?" sorusunu yanıtlar.
WITH r AS (
SELECT
MAX(CASE WHEN variant='control' THEN 1.0*c/n END) AS p1,
MAX(CASE WHEN variant='control' THEN n END) AS n1,
MAX(CASE WHEN variant='treatment' THEN 1.0*c/n END) AS p2,
MAX(CASE WHEN variant='treatment' THEN n END) AS n2
FROM (
SELECT variant, COUNT(DISTINCT user_id) n,
COUNT(DISTINCT converted_user) c
FROM experiment_flat GROUP BY variant
) s
)
SELECT
p2 - p1 AS abs_lift,
(p2 - p1) / SQRT( p1*(1-p1)/n1 + p2*(1-p2)/n2 ) AS z_score
FROM r;Z Puanını Yorumlama
Mülakat yapan kişinin yalnızca matematiği değil, iş açısından anlamlı bir değerlendirmeyi de duyması için sayıyı bir sonuca dönüştürün:
|z| >= 1.96: fark, yaklaşık %95 güven düzeyinde anlamlıdır.|z| < 1.96: yeterli kanıt yoktur; artış rastlantısal dalgalanma olabilir.
Okunabilir bir etiket üretmek için bunu bir CASE içine alın ve anlamlılığı her zaman artışın pratik büyüklüğüyle birlikte değerlendirin.
SELECT
z_score,
CASE WHEN ABS(z_score) >= 1.96
THEN 'significant at 95%'
ELSE 'not significant' END AS verdict
FROM (
SELECT 2.3 AS z_score
) t;Örneklem Oranı Uyumsuzluğu (SRM)
Mülakat yapanların incelediği ilk koruyucu nokta şudur: kullanıcılar gerçekten tasarlandığı gibi mi bölündü? Milyonlarca kullanıcısı olan 50/50'lik bir deneyin 53/47 sonuçlanması ciddi bir uyarıdır; rastgeleleştirme veya kayıt tutma bozulmuştur.
Gözlemlenen sayıları beklenen dağılımla karşılaştırın. Büyük bir sapma, metriğe bakmadan önce deneyin tamamını geçersiz kılar.
WITH cnt AS (
SELECT variant, COUNT(DISTINCT user_id) AS n
FROM experiment_flat GROUP BY variant
),
tot AS (SELECT SUM(n) AS total FROM cnt)
SELECT
c.variant, c.n,
ROUND(100.0 * c.n / t.total, 2) AS observed_pct,
50.0 AS expected_pct
FROM cnt c CROSS JOIN tot t;Koruyucu Metrikler
Koruyucu metrik, birincil metrik iyileşse bile kötüleşmemesi gereken bir metriktir. Klasik koruyucu metrikler şunlardır: sayfa gecikmesi, iade oranı, abonelikten çıkma oranı ve hata oranı.
Bunları başarı metriğinin yanında varyant başına raporlayın. Dönüşümü artırırken iadeleri iki katına çıkaran bir uygulama başarı sayılmaz. Koruyucu metrikleri istenmeden hesaplamanız, ürün muhakemesine sahip olduğunuzu gösterir.
SELECT
variant,
AVG(load_ms) AS avg_latency_ms,
ROUND(100.0 * SUM(refunded) / COUNT(*), 2) AS refund_rate_pct,
ROUND(100.0 * SUM(errored) / COUNT(*), 2) AS error_rate_pct
FROM experiment_flat
GROUP BY variant;Eksiksiz Sonuç Sunumu
Mülakat yapanların beğeneceği eksiksiz bir deney sonuç sunumu, tek bir sonuçta dört şeyi birleştirir: varyant başına oranlar, göreli artış, anlamlılık sonucu ve SRM kontrolü. CTE'leri katmanlayıp bunları karar vermeye hazır tek bir tablo olarak sunun.
Son olarak şunları belirtin: fark anlamlı, artışın büyüklüğü kabul edilebilir, koruyucu metrikler sağlıklı, dağılım dengeli; dolayısıyla kullanıma sunun veya bekletin.
WITH s AS (
SELECT variant, COUNT(DISTINCT user_id) n,
COUNT(DISTINCT converted_user) c
FROM experiment_flat GROUP BY variant
),
r AS (
SELECT
MAX(CASE WHEN variant='control' THEN 1.0*c/n END) p1,
MAX(CASE WHEN variant='control' THEN n END) n1,
MAX(CASE WHEN variant='treatment' THEN 1.0*c/n END) p2,
MAX(CASE WHEN variant='treatment' THEN n END) n2
FROM s
)
SELECT
ROUND(100.0*(p2-p1)/p1, 2) AS rel_lift_pct,
CASE WHEN ABS((p2-p1)/SQRT(p1*(1-p1)/n1 + p2*(1-p2)/n2)) >= 1.96
THEN 'significant' ELSE 'not significant' END AS verdict,
CASE WHEN ABS(1.0*n2/(n1+n2) - 0.5) > 0.02
THEN 'SRM warning' ELSE 'split ok' END AS srm_check
FROM r;Hızlı Kontrol
Uygulama grubu dönüşümde %25 göreli artış gösteriyor, ancak her varyantta yalnızca 40 kullanıcı var. Doğru sonuç ne olmalıdır?
Özet: Artış, Anlamlılık ve Koruyucu Metrikler
Artık ham varyant metriklerini bir karara dönüştürebilirsiniz:
- Mutlak (puan cinsinden) artışı, göreli (yüzde cinsinden) artıştan ayırt edin.
- Her oranın standart hatasını ve yaklaşık bir anlamlılık göstergesi olarak iki oran için z puanını hesaplayın (|z| >= 1.96 ~ %95).
- Dağılımın tasarımla eşleştiğini doğrulamak için SRM kontrolünü yapın.
- Bir başarının gerilemeyi gizlememesi için koruyucu metrikleri raporlayın.
- Karar vermeye hazır tek bir sonuç sunumu hazırlayın ve anlamlılığı her zaman artışın pratik büyüklüğüyle birlikte değerlendirin.
SQL'de huni ve A/B deneyi analizini tamamladınız.
Sıkça Sorulan Sorular
“SQL'de Artış, Anlamlılık ve Güvenlik Kontrolleri” dersi ücretsiz mi?
Evet — “SQL'de Artış, Anlamlılık ve Güvenlik Kontrolleri” dersin tüm metni burada web'de ücretsiz olarak okunabilir. Etkileşimli olarak pratik yapmak (yerleşik kod editörü ve 7/24 yapay zeka koçu) ve Coding Interview Prep kursunun geri kalanını açmak için CoddyKit PRO'ya yükselt. Coding Interview Prep kursu toplamda 4 dersten oluşur.
“SQL'de Artış, Anlamlılık ve Güvenlik Kontrolleri” dersinde ne öğreneceğim?
Dönüşüm artışının ve bozuk bir deneyi işaretleyen veri kontrollerinin hesaplanması. Coding Interview Prep ile uygulamalı kodu tarayıcıda doğrudan çalıştırarak pratik yaparsın ve 7/24 yapay zeka koçu dersi çalışırken sorularını yanıtlar.
Coding Interview Prep öğrenmeye başlamak için deneyim gerekli mi?
Önceden deneyim gerekmez. CoddyKit'te Coding Interview Prep, başlangıçtan ileri seviyeye kadar yapılandırıldığı için buradan başlayabilir veya başından başlayıp kendi hızında ilerleme yapabilirsin. Bu, 4 dersinin 4. dersidir.
“SQL'de Artış, Anlamlılık ve Güvenlik Kontrolleri” dersi ne kadar sürer?
Çoğu CoddyKit dersi yaklaşık 5–10 dakika sürer. Her biri kısa ve etkileşimli olduğu için sabit ilerleme yaparsın ve web ile uygulama arasında tam olarak bıraktığın yerden devam edebilirsin.
Bu Coding Interview Prep dersinde kod yazıp çalıştırabilir miyim?
Evet. Her Coding Interview Prep dersi yerleşik bir kod editörü içerir, bu sayede tarayıcıda gerçek kod yazıp çalıştırabilir ve anlık yapay zeka geri bildirimi alırsın — yerel kurulum gerekli değildir.
Bu kursun tüm dersleri
- Çok Adımlı Dönüşüm Hunisi Oluşturma
- Sıralı Etkinlikler ve Zaman Pencereleri
- A/B Testi Ataması ve Ölçümleri
- SQL'de Artış, Anlamlılık ve Güvenlik Kontrolleri