Sql & Veritabanı İle Veri Odaklı A/b Testi Analizi Nasıl Yapılır?

Gereksinimler ve Ön Hazırlık

A/B testi analizi yapabilmek için öncelikle veritabanınızda kullanıcı etkileşimlerinin (tıklama, dönüşüm, oturum süresi) kayıt altına alındığı bir yapıya ihtiyacınız vardır. PostgreSQL veya MySQL gibi ilişkisel veritabanı yönetim sistemleri (RDBMS), bu analizler için en uygun ortamlardır.

• Veritabanı: PostgreSQL 16+ veya MySQL 8.4+ sürümü (Modern pencere fonksiyonlarını desteklemesi şarttır).
• Veri Seti: Kullanıcı kimliği (user_id), deney grubu (test_group) ve dönüşüm durumu (conversion) içeren bir tablo.
• Araçlar: SQL sorgularını çalıştırabileceğiniz bir arayüz (DBeaver, pgAdmin veya terminal).

Adım 1: A/B Testi İçin Veritabanı Şemasını Tasarlama

Testin sağlıklı işlemesi için kullanıcıların hangi gruba (A veya B) dahil edildiğini ve bu grubun sonucunu tutan bir yapı kurmalıyız. "Events" tablosu, her bir kullanıcı hareketini zaman damgasıyla birlikte saklamalıdır.

CREATE TABLE experiment_events (
    event_id SERIAL PRIMARY KEY,
    user_id INT NOT NULL,
    group_name VARCHAR(10) NOT NULL, -- 'control' veya 'variant'
    event_type VARCHAR(50) NOT NULL, -- 'view', 'click', 'purchase'
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

Bu tablo, her kullanıcı etkileşimini "group_name" sütunu ile etiketleyerek, daha sonra gruplar arası karşılaştırma yapmamıza olanak tanır. "group_name" sütununa indeks eklemek, büyük veri setlerinde sorgu performansını ciddi oranda artıracaktır.

Adım 2: Temel Metrikleri Hesaplama

Testin sonucunu görmek için her gruptaki toplam kullanıcı sayısını ve dönüşüm oranlarını hesaplamalıyız. Dönüşüm oranı, toplam kullanıcı sayısına oranla hedeflenen aksiyonu (örneğin satın alma) gerçekleştirenlerin yüzdesidir.

SELECT 
    group_name,
    COUNT(DISTINCT user_id) AS total_users,
    COUNT(DISTINCT CASE WHEN event_type = 'purchase' THEN user_id END) AS converted_users,
    ROUND(
        COUNT(DISTINCT CASE WHEN event_type = 'purchase' THEN user_id END)::numeric / 
        NULLIF(COUNT(DISTINCT user_id), 0), 4
    ) AS conversion_rate
FROM experiment_events
GROUP BY group_name;

Burada NULLIF fonksiyonu, sıfıra bölünme hatasını engellemek için kullanılır. COUNT(DISTINCT user_id) kullanımı, bir kullanıcının birden fazla işlem yapması durumunda verinin bozulmasını engeller.

Adım 3: İstatistiksel Anlamlılık (P-Value) Analizi

Sadece dönüşüm oranlarına bakmak yanıltıcı olabilir. İki grup arasındaki farkın tesadüfi olup olmadığını anlamak için istatistiksel bir test (örneğin Chi-Square veya Z-Test) gerekir. SQL üzerinde basit bir Z-skoru hesaplaması ile farkın anlamlılığını kontrol edebiliriz.

WITH stats AS (
    SELECT 
        group_name,
        COUNT(DISTINCT user_id) as n,
        COUNT(DISTINCT CASE WHEN event_type = 'purchase' THEN user_id END) as successes
    FROM experiment_events
    GROUP BY group_name
)
SELECT 
    (s2.successes::float/s2.n - s1.successes::float/s1.n) AS lift,
    -- Basitleştirilmiş Z-skoru mantığı
    (s2.successes::float/s2.n - s1.successes::float/s1.n) / 
    SQRT((s1.successes::float/s1.n * (1 - s1.successes::float/s1.n)) / s1.n) AS z_score
FROM stats s1, stats s2
WHERE s1.group_name = 'control' AND s2.group_name = 'variant';

Z-skoru 1.96'dan büyükse, %95 güven aralığında sonuçların istatistiksel olarak anlamlı olduğunu söyleyebiliriz. Bu hesaplama, iş birimlerine "bu fark şans eseri değil" diyebilmeniz için kritiktir.

Güvenlik Uyarısı: Veritabanı üzerinde analiz yaparken asla üretim (production) veritabanında doğrudan işlem yapmayın. Her zaman veritabanının bir "read-replica" kopyasını veya analiz için oluşturulmuş bir "data warehouse" (veri ambarı) yapısını kullanın. SQL Injection riskine karşı, kullanıcı girdilerini sorgulara doğrudan dahil etmeyin.

Adım 4: Kullanıcı Davranış Süreçlerini Karşılaştırma

Sadece dönüşüme değil, kullanıcıların site içinde geçirdiği süre veya etkileşim derinliğine de bakmalıyız. Bunun için pencere fonksiyonlarını (Window Functions) kullanarak grup bazlı ortalamalar alabiliriz.

SELECT 
    group_name,
    AVG(event_count) as avg_interactions_per_user
FROM (
    SELECT user_id, group_name, COUNT(*) as event_count
    FROM experiment_events
    GROUP BY user_id, group_name
) sub
GROUP BY group_name;

Bu sorgu, her bir kullanıcının kaç farklı etkileşimde bulunduğunu hesaplar ve ardından gruplar bazında ortalamayı verir. Bu, A/B testinizin sadece dönüşümü değil, kullanıcı bağlılığını nasıl etkilediğini anlamanızı sağlar.

Veri Analizi Yöntemleri Karşılaştırması

Adım 5: Hata Ayıklama ve Veri Doğrulama

A/B testlerinde en yaygın hata, "sample ratio mismatch" (örneklem oranı uyumsuzluğu) durumudur. Eğer A grubunda 1000 kişi varken B grubunda 200 kişi varsa, test kurulumunuz hatalıdır. Bunu şu sorgu ile kontrol edebilirsiniz:

SELECT 
    group_name, 
    COUNT(DISTINCT user_id) as user_count
FROM experiment_events
GROUP BY group_name;

Eğer gruplar arasında %5'ten fazla sapma varsa, veritabanı loglarını kontrol ederek atama (assignment) mekanizmasında bir hata olup olmadığını inceleyin.

Sıkça Sorulan Sorular

A/B testinin anlamlı olması için ne kadar veriye ihtiyacım var?

Bu, istatistiksel güç analizi ile belirlenir. Genellikle, dönüşüm oranınızdaki beklenen iyileşme miktarına bağlı olarak binlerce kullanıcıya ihtiyaç duyarsınız.

SQL sorgularım çok yavaş çalışıyor, ne yapmalıyım?

Sorgularınızda kullandığınız sütunlara (özellikle user_id ve group_name) indeks ekleyin. Ayrıca, büyük tabloları analiz ederken "partitioning" (bölümleme) yöntemini kullanmayı düşünün.

SQL ile her türlü A/B testi yapılabilir mi?

SQL, verilerin toplanması ve temel analizi için mükemmeldir. Ancak çok karmaşık çok değişkenli (multivariate) testler için Python veya R gibi dillerle desteklenen istatistiksel kütüphaneler gerekebilir.

Dönüşüm oranım neden her gün değişiyor?

Bu durum, testin henüz "istatistiksel olgunluğa" erişmediğini gösterir. Veri birikmeye devam ettikçe oranlar stabilize olacaktır.

Testi ne zaman durdurmalıyım?

Önceden belirlenen örneklem büyüklüğüne ulaşıldığında ve p-value değeri istatistiksel olarak anlamlı düzeye (genelde < 0.05) geldiğinde testi sonlandırabilirsiniz.

Yasal Sorumluluk Reddi: Bu rehberdeki SQL kodları ve analiz yöntemleri eğitim amaçlıdır. Veritabanı işlemleri sırasında oluşabilecek veri kaybı veya performans sorunlarından kullanıcı sorumludur. Kritik veriler üzerinde çalışmadan önce her zaman yedekleme yapınız.

İleri Seviye Segmentasyon: Kohort Analizi ile A/B Testi Derinleştirme

A/B testlerinde elde edilen genel dönüşüm oranları bazen yanıltıcı olabilir. "Simpson Paradoksu" olarak bilinen durum, genel sonuçların olumlu görünmesine rağmen, alt segmentlerde sonuçların farklı olabileceğini gösterir. Veritabanı üzerinde kohort analizi yaparak, test grubunun davranışını zaman dilimlerine veya kullanıcı niteliklerine göre parçalamak, testin başarısını daha net ortaya koyar.

Aşağıdaki sorgu, kullanıcıların kayıt oldukları haftaya göre dönüşüm oranlarını karşılaştırarak, testin uzun vadeli etkisini ölçmenizi sağlar:

SELECT 
    DATE_TRUNC('week', u.created_at) AS cohort_week,
    t.variant_name,
    COUNT(DISTINCT u.user_id) AS total_users,
    COUNT(DISTINCT c.conversion_id) AS total_conversions,
    ROUND(COUNT(DISTINCT c.conversion_id)::numeric / COUNT(DISTINCT u.user_id), 4) AS conversion_rate
FROM users u
JOIN test_assignments t ON u.user_id = t.user_id
LEFT JOIN conversions c ON u.user_id = c.user_id AND c.created_at >= t.assigned_at
GROUP BY 1, 2
ORDER BY 1 ASC, 2;

Veritabanı Performansını Optimize Etme ve İndeksleme Stratejileri

A/B testi verileri büyüdükçe, milyonlarca satır arasında yapılan JOIN ve GROUP BY işlemleri veritabanını yavaşlatabilir. Analiz sorgularınızın milisaniyeler içinde sonuç vermesi için doğru indeksleme stratejilerini uygulamak zorunludur. Özellikle test_assignments tablosu üzerinde sık kullanılan sütunlar için indeks oluşturmak, sorgu süresini ciddi oranda düşürür.

Performansı artırmak için şu indeksleme yaklaşımını izleyebilirsiniz:

• Composite Index (Bileşik İndeks): Hem test_id hem de variant_name sütunlarını içeren bir indeks, filtreleme hızını artırır.
• Covering Index: Sadece analizde kullandığınız sütunları içeren indeksler, veritabanının tabloya gitmeden sadece indeksten veri okumasını sağlar.

-- Test atamaları tablosu için performans optimizasyonu
CREATE INDEX idx_test_variant_lookup 
ON test_assignments (test_id, variant_name, assigned_at);

-- Dönüşüm tabloları için tarih bazlı indeksleme
CREATE INDEX idx_conversion_date 
ON conversions (created_at);

Büyük ölçekli verilerde, analiz sorgularınızı doğrudan ana üretim veritabanı yerine, bu verilerin replike edildiği bir "Read Replica" veya "Data Warehouse" üzerinde çalıştırmanız, canlı sistemin performansını korumak adına en iyi pratiktir.

Sonuç

SQL kullanarak A/B testi analizi yapmak, veriye dayalı bir ürün geliştirme kültürünün temelidir. Bu rehberde, veritabanı şemasını oluşturmaktan, istatistiksel anlamlılığı sorgulamaya kadar kritik adımları öğrendiniz. Bir sonraki adım olarak, bu SQL sorgularını bir BI (İş Zekası) aracına bağlayarak canlı dashboardlar oluşturabilir ve test süreçlerinizi otomatize edebilirsiniz. Veri odaklı kalmaya devam edin.