Dönüşüm Oranı Optimizasyonu (CRO) A/B Test Altyapıları

Bir A/B testi başlatmak kolay görünebilir. Asıl zor bölüm, kullanıcıyı doğru varyanta atayan, exposure verisini eksiksiz kaydeden, dönüşümü güvenilir biçimde ölçen ve sonucu istatistiksel açıdan doğru yorumlayan bir sistem kurmaktır. Dönüşüm Oranı Optimizasyonu (CRO) A/B Test Altyapıları konusunda yaklaşık on yıllık çalışma deneyimimde en sık gördüğüm sorun, ekiplerin test aracını experimentation sistemiyle aynı şey sanmasıdır. Oysa güçlü bir deney programı yalnızca iki tasarımı karşılaştırmaz; kimlik, randomization, event tracking, veri kalitesi, örneklem planlama, guardrail metrics, QA ve karar süreçlerini aynı mimari içinde yönetir. Bu rehberde dönüşüm oranı optimizasyonu için A/B test altyapısı nasıl kurulur sorusunu teknik mimariden istatistiksel karar kurallarına, server-side ve client-side testlerden kurumsal yönetişime kadar uygulamaya dönük biçimde ele alacağız.

Dönüşüm Oranı Optimizasyonu (CRO) Nedir?

Dönüşüm oranı optimizasyonu, mevcut trafik içindeki kullanıcıların hedeflenen aksiyonu tamamlama oranını sistematik biçimde geliştirme çalışmasıdır. Bu hedef satın alma, form gönderme, üyelik oluşturma, demo talebi veya aktivasyon gibi farklı iş sonuçları olabilir. CRO yalnızca arayüzde küçük değişiklikler yapıp dönüşüm oranına bakmak değildir. Sağlıklı bir CRO sistemi kullanıcı araştırması, analytics, funnel analizi, hipotez üretimi, kontrollü deney ve sonuç doğrulamasını birlikte kullanır. Benim deneyimimde en iyi sonuçlar, trafik kazanımı ile dönüşüm verimliliğini birbirine rakip değil birbirini tamamlayan iki büyüme katmanı olarak gören ekiplerde ortaya çıkar.

Conversion Rate Nedir?

Conversion rate, tanımlanan hedefi tamamlayan kullanıcıların veya oturumların ilgili toplam popülasyona oranıdır. Formül basit görünse de paydanın yanlış seçilmesi test sonucunu ciddi biçimde değiştirebilir. Kullanıcı bazlı, session bazlı veya event bazlı dönüşüm oranları aynı şeyi ölçmez. Örneğin bir kullanıcı aynı gün üç oturum açabiliyorsa session conversion ile user conversion farklı sonuç üretebilir. Bu nedenle deney başlamadan önce metric definition içinde numerator, denominator, population ve attribution window açık biçimde yazılmalıdır.

CRO'nun Temel Amacı

CRO'nun amacı yalnızca daha fazla tıklama üretmek değildir. Asıl hedef kullanıcı ve iş açısından anlamlı davranışların daha yüksek oranda gerçekleşmesini sağlamaktır. Bir CTA tıklaması artarken gerçek satın alma düşüyorsa test yüzeysel olarak başarılı görünebilir ama iş açısından zarar üretmiş olabilir. Bu nedenle primary metric yanında guardrail metric kullanımı önemlidir. Sağlıklı CRO programı kısa vadeli hareketliliği değil sürdürülebilir iş ve kullanıcı değerini optimize eder.

Dönüşüm Olarak Hangi Aksiyonlar Ölçülebilir?

Dönüşüm kavramı ürünün iş modeline göre değişir. E-ticarette satın alma ve sepete ekleme, SaaS ürününde signup ve trial-to-paid geçişi, B2B yapıda demo request veya qualified lead dönüşüm sayılabilir. İçerik tabanlı bir sitede üyelik, abonelik veya yüksek değerli içerik tüketimi önemli olabilir. Her mikro aksiyonu conversion olarak tanımlamak metrik gürültüsü oluşturur. Deney tasarımında hedef aksiyonun kullanıcı yolculuğundaki gerçek değeri açıkça belirlenmelidir.

CRO ile Trafik Kazanımı Arasındaki Fark

Trafik kazanımı siteye daha fazla nitelikli kullanıcı getirmeyi hedefler. CRO ise gelen kullanıcıların mevcut deneyim içinde hedef davranışı tamamlama olasılığını artırmaya çalışır. Bir site ziyaretçi sayısını iki katına çıkarabilir fakat kötü checkout akışı nedeniyle aynı geliri üretmeye devam edebilir. Tersine trafik sabitken dönüşüm oranındaki anlamlı artış aynı kullanıcı hacminden daha fazla değer sağlayabilir. En güçlü büyüme modeli acquisition ve conversion sistemlerini aynı ölçüm çerçevesinde değerlendirmektir.

CRO Neden Sürekli Bir Süreçtir?

Kullanıcı davranışı, ürün, trafik kaynağı ve rekabet koşulları zaman içinde değişir. Geçen yıl başarılı olan bir onboarding deneyimi bugün aynı etkiyi üretmeyebilir. Ayrıca bir testin kazanan varyantı yeni baseline haline geldiğinde sonraki hipotezler bu yeni deneyim üzerinden geliştirilir. Bu nedenle CRO tek bir optimizasyon projesi değildir. Sürekli araştırma, deney, öğrenme, rollout ve yeniden ölçüm döngüsü gerektirir.

CRO ile Experimentation Arasındaki Fark

CRO çoğu ekipte dönüşüm fırsatlarını bulma ve kullanıcı akışlarını geliştirme pratiği olarak başlar. Experimentation ise bu fikirleri kontrollü, ölçülebilir ve tekrarlanabilir deneylere dönüştüren daha geniş bir sistemdir. Taktik CRO birkaç landing page testinden oluşabilirken sistematik experimentation ürün, fiyatlandırma, onboarding, recommendation veya checkout kararlarını aynı metodolojiyle değerlendirebilir. Buradaki temel fark test sayısından çok karar kalitesidir. Kurumsal ekiplerde CRO programı experimentation altyapısıyla birleştiğinde hipotez üretimi, ölçüm, randomization ve karar verme aynı standart altında yürütülebilir.

Taktik CRO

Taktik CRO genellikle belirli bir sayfa veya funnel adımındaki problemi çözmeye odaklanır. Başlık, CTA, form uzunluğu veya sayfa düzeni üzerinde değişiklik yapılabilir. Bu çalışmalar faydalı olabilir fakat ortak metric standardı ve repository yoksa öğrenimler ekip içinde kaybolabilir. Aynı fikir farklı ekipler tarafından yeniden test edilebilir. Taktik çalışmaların sistematik bir experimentation programına bağlanması kurumsal hafıza oluşturur.

Sistematik Experimentation

Sistematik experimentation yalnız test çalıştırmayı değil testin neden ve nasıl çalıştırıldığını standardize eder. Hipotez şablonu, sample size planı, exposure logging, SRM kontrolü ve decision rule önceden tanımlanır. Sonuçlar merkezi experiment repository içinde saklanır. Kazanan, kaybeden ve inconclusive testlerin tamamı öğrenme olarak değerlendirilir. Böylece ürün geliştirme süreci kişisel fikirlere değil kontrollü kanıta daha fazla dayanır.

“Buton Rengi Testi” Yaklaşımının Sınırları

Buton rengi testi A/B testing kavramını anlatmak için kolay bir örnektir fakat olgun bir CRO programını temsil etmez. Küçük görsel değişikliklerin iş etkisi çoğu zaman sınırlı olabilir. Büyük öğrenmeler genellikle teklif yapısı, bilgi mimarisi, onboarding, checkout veya fiyatlandırma gibi temel kullanıcı problemlerinden gelir. Bununla birlikte yüksek riskli alanlar daha güçlü measurement ve governance gerektirir. CRO ekibinin amacı kolay test bulmak değil anlamlı hipotezleri güvenilir biçimde sınamaktır.

Hipotez ve Kanıt Temelli Ürün Geliştirme

Hipotez temelli geliştirme, değişikliği yapmadan önce neden etkili olacağını açıklamayı zorunlu kılar. Kullanıcı araştırması, funnel analizi veya davranış verisi hipotezin dayanağı olabilir. Ardından beklenen etki ve primary metric önceden tanımlanır. Test başarısız olsa bile hipotez hakkında bilgi kazanılır. Bu yaklaşım ürün kararlarını yalnız sezgiye bırakmadan daha disiplinli öğrenme süreci oluşturur.

Experimentation Culture Nedir?

Experimentation culture, organizasyonun belirsiz ürün kararlarında kontrollü deneyleri doğal karar mekanizması olarak kullanmasıdır. Burada her değişikliğin test edilmesi gerekmez. Kritik bug fix, yasal gereklilik ve accessibility düzeltmeleri doğrudan uygulanabilir. Deney yapılacak alanlarda ise başarısız sonuç cezalandırılmaz ve learning değeri önemsenir. Kültür olgunlaştıkça ekipler “fikrim doğru mu?” sorusundan “bu hipotezi en güvenilir biçimde nasıl sınarız?” sorusuna geçer.

A/B Test Nedir?

A/B test iki veya daha fazla deneyimin rastgele seçilmiş kullanıcı grupları üzerinde karşılaştırıldığı kontrollü deney yöntemidir. Kullanıcıların bir bölümü mevcut kontrol deneyimini görürken diğer grup önerilen treatment deneyimini görür. Gruplar arasında yeterli randomization ve veri kalitesi sağlandığında metrik farkı değişikliğin etkisi hakkında nedensel yorum yapmayı kolaylaştırır. Bu nedenle A/B testing basit bir analytics karşılaştırmasından farklıdır. CRO A/B testlerinde istatistiksel anlamlılık ve örneklem büyüklüğü nasıl belirlenir sorusunun doğru cevabı da randomization, önceden tanımlanan metric ve sample size planıyla başlar.

Control ve Treatment

Control mevcut deneyimi temsil eder. Treatment ise test edilen yeni varyanttır. İki grubun test edilen değişiklik dışında mümkün olduğunca aynı koşullarda olması gerekir. Trafik kaynağı veya kullanıcı tipi randomization sayesinde gruplara dengeli dağılmalıdır. Sonuç analizi control ile treatment arasındaki metric farkı üzerinden yapılır.

Champion ve Challenger

Champion mevcut en iyi bilinen deneyimi ifade etmek için kullanılabilir. Challenger ise bu deneyimi geçmesi beklenen yeni alternatif olabilir. Bu terimler özellikle sürekli optimizasyon yapılan ürünlerde kullanışlıdır. Bir challenger kazandığında yeni champion haline gelebilir. Böylece deney programı ardışık öğrenme ve iyileştirme döngüsü oluşturur.

Randomized Experiment

Randomized experiment kullanıcıların gruplara rastgele atanmasına dayanır. Randomization gözlenen ve gözlenmeyen birçok kullanıcı özelliğinin varyantlar arasında dengelenmesine yardımcı olur. Assignment algoritmasının stabil olması gerekir. Trafik dağılımındaki beklenmeyen sapmalar Sample Ratio Mismatch kontrolüyle izlenmelidir. Randomization bozulduğunda deney sonucunun güvenilirliği ciddi biçimde azalır.

Kullanıcıların Varyantlara Dağıtılması

Varyant dağılımı çoğu basit testte yüzde 50 kontrol ve yüzde 50 treatment olabilir. Üç veya daha fazla varyantta farklı trafik oranları kullanılabilir. Randomization unit user, account, session veya organization seviyesinde seçilebilir. Aynı kullanıcıya farklı ziyaretlerde farklı varyant göstermek istenmiyorsa sticky assignment uygulanmalıdır. Trafik dağılım kararı istatistiksel plan ve ürün riskine göre verilmelidir.

Conversion Lift Nasıl Ölçülür?

Conversion lift treatment dönüşüm oranının control dönüşüm oranına göre değişimini ifade eder. Mutlak fark ve göreceli fark ayrı hesaplanmalıdır. Örneğin dönüşüm yüzde 10'dan yüzde 11'e çıktığında mutlak artış bir yüzde puanı, göreceli artış ise yaklaşık yüzde 10'dur. İstatistiksel belirsizlik confidence interval veya kullanılan metodolojiye uygun başka araçlarla birlikte gösterilmelidir. Yalnız pozitif lift görmek testin otomatik olarak başarılı olduğu anlamına gelmez.

A/B Test Altyapısı Nedir?

A/B test altyapısı kullanıcıları varyantlara dağıtan basit bir kod parçasından çok daha fazlasıdır. Assignment, feature delivery, exposure logging, event collection, metrics, statistics ve experiment management katmanlarının birlikte çalıştığı bütünsel sistemdir. Kurumsal CRO ve A/B test altyapısı kurulum hizmeti değerlendirirken yalnız visual editor özelliklerine bakmak bu nedenle yeterli olmaz. Platformun kullanıcı kimliğini nasıl yönettiği, exposure verisini nasıl sakladığı ve metrics engine'in nasıl çalıştığı daha kritik olabilir. Sağlam altyapı deney sonucunun yeniden üretilebilir ve denetlenebilir olmasını sağlar.

Basit Testing Tool ile Experimentation Infrastructure Farkı

Basit testing tool bir web sayfasında iki varyantı hızlıca göstermeye yardımcı olabilir. Experimentation infrastructure ise ürünün farklı katmanlarında güvenilir deney çalıştırmayı sağlayan ortak platformdur. Backend, mobile app, web ve API deneyleri aynı kimlik ve ölçüm sistemiyle yönetilebilir. Data warehouse ve analytics eventleriyle entegrasyon bulunur. Bu fark özellikle birden fazla ürün ekibinin aynı anda deney yaptığı kurumsal yapılarda belirginleşir.

Assignment Layer

Assignment layer kullanıcının hangi deney varyantına ait olduğunu belirler. Deterministic hashing yaygın yöntemlerden biridir. Randomization unit ve experiment namespace burada önemli rol oynar. Aynı kullanıcı tekrar geldiğinde aynı varyantı görmesi gerekiyorsa assignment stabil kalmalıdır. Assignment sonucu exposure gerçekleşmeden önce ayrı bir durum olarak tutulabilir.

Feature Delivery Layer

Feature delivery layer atanmış varyantın ürün deneyimine uygulanmasını sağlar. Client-side CSS veya JavaScript değişikliği, backend feature flag veya API response farklılığı bu katmanda gerçekleşebilir. Assignment ile rendering birbirinden ayrıldığında hybrid experimentation mümkün hale gelir. Default behavior ve failover kuralları burada tanımlanmalıdır. Platform kesintisinde ürünün güvenli varsayılan deneyime dönmesi önemlidir.

Exposure Logging Layer

Exposure logging kullanıcı deney varyantını gerçekten gördüğünde veya deneyimden etkilendiğinde kayıt oluşturur. Assignment yapılmış olması tek başına exposure anlamına gelmez. Kullanıcı deney koşuluna hiç ulaşmadan oturumdan çıkmış olabilir. Bu kişiyi deney populationına dahil etmek sonuçları seyreltebilir. Exposure event güvenilir experimentation sisteminin en kritik veri kayıtlarından biridir.

Event Collection Layer

Event collection kullanıcı davranışlarını standart şema ile toplar. Page viewed, product viewed, add to cart, purchase completed ve form submitted gibi olaylar bu katmandan geçebilir. Event isimleri ve properties tutarlı olmalıdır. Duplicated veya kayıp eventler experiment sonucunu bozabilir. Data quality monitoring bu nedenle deney platformunun ayrılmaz parçasıdır.

Metrics Layer

Metrics layer ham eventleri deney metriklerine dönüştürür. Conversion rate, revenue per user veya retention gibi metric tanımları merkezi tutulabilir. Numerator, denominator, population ve attribution window sabit şema içinde yazılır. Böylece farklı ekipler aynı isimde farklı hesaplama yapmaz. Metric versioning geçmiş deneylerin yeniden analiz edilmesini kolaylaştırır.

Statistical Analysis Layer

Statistical analysis layer varyantlar arasındaki farkın belirsizliğini hesaplar. Frequentist veya Bayesian metodoloji kullanılabilir. Önemli olan yaklaşımın ekip tarafından anlaşılır ve şeffaf olmasıdır. Peeking ve erken durdurma gibi karar riskleri kullanılan metodolojiye göre yönetilmelidir. İstatistik motoru data quality kontrollerinden geçmeyen deneyde sonuç üretse bile bu sonuç güvenilir kabul edilmemelidir.

Experiment Management Layer

Experiment management layer hipotez, owner, varyant, tarih, metric ve karar bilgilerinin yönetildiği alandır. Launch approval ve rollout durumları burada tutulabilir. Experiment repository bu katmanla entegre edilebilir. Aynı deneyin yanlışlıkla tekrar başlatılması önlenebilir. Governance ve audit ihtiyacı olan kurumsal ekipler için bu bölüm önemlidir.

Kurumsal Experimentation Platform Mimarisi

Kurumsal experimentation platformu birden fazla ürün, ekip ve kanal üzerinde tutarlı deney yürütmeyi amaçlar. Experiment management service, feature flag service, assignment service, SDK, exposure pipeline, analytics event pipeline, data warehouse, metrics engine, statistical engine ve dashboard temel bileşenler arasında yer alabilir. Her bileşenin aynı teknolojiyle yazılması gerekmez. Mimari tasarımda latency, reliability, identity ve data correctness en kritik kriterlerdir. Server-side ve client-side A/B test altyapısı karşılaştırması yapılırken de yalnız rendering yöntemi değil bütün bu veri akışının güvenilirliği değerlendirilmelidir.

Experiment Management Service

Experiment management service deney konfigürasyonlarını saklar. Experiment ID, varyant oranları, eligibility ve başlangıç tarihleri bu serviste tutulabilir. Değişiklikler audit log ile kaydedilmelidir. Production config ile draft config ayrılabilir. Yanlış konfigürasyonun bütün kullanıcı kitlesini etkilememesi için approval ve validation süreçleri kullanılmalıdır.

Feature Flag Service

Feature flag service özelliklerin açılıp kapatılmasını ve progressive rollout yapılmasını sağlar. Deney varyantları aynı flag mekanizması üzerinden sunulabilir. Ancak feature flag tek başına experimentation sistemi değildir. Exposure ve metrics katmanı olmadan nedensel etki ölçülemez. Stale flag temizliği technical debt yönetimi açısından önemlidir.

Assignment / Randomization Service

Assignment service identity ile experiment ID üzerinden stabil varyant seçimi yapar. Deterministic hash yaklaşımı yüksek performans sağlayabilir. Namespace veya layer kuralları eş zamanlı test çakışmalarını yönetebilir. Servisin düşük latency ile çalışması özellikle server-side request path üzerinde önemlidir. Caching ve local SDK evaluation bazı mimarilerde merkezi servis bağımlılığını azaltabilir.

SDK Katmanı

SDK uygulama ekiplerinin experimentation platformuna standart şekilde bağlanmasını sağlar. Web, backend, iOS, Android veya diğer çalışma ortamları için farklı SDK'lar olabilir. Assignment, exposure ve flag evaluation davranışı SDK içinde standardize edilebilir. SDK version compatibility düzenli izlenmelidir. Eski SDK'lar metric veya exposure hatasına yol açabileceği için upgrade politikası gereklidir.

Exposure Pipeline

Exposure pipeline kullanıcının hangi experiment ve variant deneyimine gerçekten maruz kaldığını kaydeder. Event içinde experiment ID, variant ID, user ID ve timestamp bulunabilir. Duplicate exposure politikası açık olmalıdır. Aynı kullanıcının yüzlerce exposure kaydı üretmesi analiz maliyetini artırabilir. Metric calculation hangi exposure eventinin esas alınacağını önceden tanımlamalıdır.

Analytics Event Pipeline

Analytics pipeline ürün davranış eventlerini toplar. Exposure ile conversion verisinin aynı identity sistemini kullanması join kalitesini belirler. Event gecikmesi ve kaybı monitoring altında olmalıdır. Schema registry veya event contract yaklaşımı data quality sağlar. Experimentation altyapısı mevcut analytics sistemini tekrar kurmak yerine güvenilir şekilde kullanabilir.

Data Warehouse

Data warehouse exposure, event, revenue ve kullanıcı verilerini ortak analiz katmanında buluşturur. Warehouse-native experimentation modelinde metric hesapları doğrudan bu veri üzerinde çalışabilir. Source of truth tanımı açık olmalıdır. Finansal revenue ile analytics revenue arasında fark varsa deney kararında hangi kaynağın kullanılacağı önceden belirlenmelidir. Raw data export veri denetimi ve yeniden analiz açısından büyük avantaj sağlar.

Metrics Engine

Metrics engine ham eventlerden standart deney metrikleri üretir. Bir metric bir kez tanımlanıp birçok deneyde yeniden kullanılabilir. Attribution window ve population kuralları config içinde saklanır. Metric değişirse versioning uygulanmalıdır. Böylece geçen yılın deneyi bugün farklı formülle yeniden hesaplanıp yanlış yorumlanmaz.

Statistical Engine

Statistical engine metric farkı, belirsizlik ve karar sinyalleri üretir. Frequentist veya Bayesian yaklaşım kullanılabilir. SRM ve sanity check gibi kalite kontrolleri analysis öncesinde çalıştırılmalıdır. Multiple comparisons konusu çok sayıda metric ve varyant olduğunda dikkate alınmalıdır. Platform kullanıcıya yalnız “kazandı” etiketi göstermek yerine metodolojiyi açıklayabilmelidir.

Experiment Dashboard

Dashboard deneyin health ve outcome durumunu tek ekranda göstermelidir. Assignment ratio, exposure count, primary metric, guardrails, segmentler ve SRM sonucu görünür olabilir. Dashboard sonuç yorumunu otomatikleştirmemelidir. Kullanıcı sample size ve test duration planını da görebilmelidir. Karar notu ve rollout durumu repository ile senkron tutulabilir.

Experimentation Veri Akışı Nasıl Çalışır?

Bir deney veri akışı kullanıcı ürüne girdiği anda başlamaz; identity ve eligibility mantığı doğru tanımlandığında başlar. Kullanıcı uygun deneye dahil edilir, varyant atanır ve gerçekten deneyimi gördüğünde exposure event oluşur. Sonraki davranış eventleri aynı identity altında toplanır. Conversion event attribution penceresi içinde exposure ile birleştirilir. Son aşamada metrics engine ve statistical engine sonucu üretir, fakat data quality kontrolleri geçmeden hiçbir sonuç nihai kabul edilmemelidir.

Kullanıcı Ürüne Girer

Kullanıcının web, mobil veya backend kanalından ürüne girişi ilk bağlamı oluşturur. Anonymous veya authenticated identity bulunabilir. Kullanıcının ülke, app version veya subscription planı eligibility için gerekli olabilir. Bu properties deney kararı anında güncel olmalıdır. Yanlış context kullanıcıyı hatalı deneye dahil edebilir.

Identity Oluşturulur

Identity experimentation sisteminin temelidir. Anonymous ID, user ID veya account ID farklı ürünlerde kullanılabilir. Login sonrasında anonymous davranışın authenticated identity ile nasıl birleştirileceği önceden tanımlanmalıdır. Aynı kişinin iki farklı varyanta düşmesi mümkün olduğunca önlenmelidir. Privacy prensipleri gereksiz kişisel veri toplamadan kimlik tutarlılığı sağlamayı hedeflemelidir.

Experiment Eligibility Kontrol Edilir

Her kullanıcı her deneye girmek zorunda değildir. Ülke, ürün paketi, cihaz veya belirli davranış koşulları eligibility kriteri olabilir. Kriterlerin deney başlamadan önce tanımlanması gerekir. Sonradan segment değiştirerek yalnız olumlu sonuç gösteren kullanıcıları seçmek analizi bozar. Eligibility logic versionlanmalı ve audit edilebilir olmalıdır.

Varyant Atanır

Eligible kullanıcı randomization service tarafından varyanta atanır. Hash key randomization unit ile experiment ID kombinasyonundan üretilebilir. Trafik oranları konfigürasyona göre uygulanır. Sticky assignment gerekiyorsa aynı kullanıcı tekrar geldiğinde sonuç değişmemelidir. Assignment event ile exposure event birbirinden ayrı tutulmalıdır.

Exposure Kaydedilir

Kullanıcı deneyin etkilediği alanı gerçekten gördüğünde exposure oluşur. Bu kayıt experiment populationının daha doğru tanımlanmasını sağlar. Lazy-loaded veya alt sayfadaki deneyde assignment yapılmış kullanıcıların tamamı exposure yaşamayabilir. Yanlış exposure logging sonucu treatment etkisi seyrelmiş görünebilir. Bu nedenle exposure trigger QA sürecinde özel olarak test edilmelidir.

Kullanıcı Davranış Event'leri Toplanır

Exposure sonrası kullanıcı davranışları standart event schema ile kaydedilir. Add to cart, checkout started veya signup completed gibi olaylar örnek olabilir. Event timestamp ve identity alanları doğru olmalıdır. Client ve server eventlerinin duplicate üretmemesi gerekir. Data pipeline lag deney dashboardunda görünür olmalıdır.

Conversion Event Oluşur

Primary conversion event deney hipoteziyle uyumlu olmalıdır. CTA testinde yalnız tıklama yerine son iş sonucu daha değerli olabilir. Bununla birlikte düşük frekanslı final conversion test süresini uzatabilir. Secondary funnel metrics davranışın neden değiştiğini anlamaya yardımcı olur. Event definition test başlamadan önce sabitlenmelidir.

Exposure ile Conversion Join Edilir

Conversion event doğru exposure kaydıyla ilişkilendirilmelidir. Identity mismatch kullanıcı conversionının kaybolmasına neden olabilir. Attribution window çok kısa seçilirse geç dönüşümler dışarıda kalır. Çok uzun pencere ise başka etkileri teste dahil edebilir. Metric definition bu join mantığını açık biçimde içermelidir.

Sonuçlar İstatistiksel Olarak Analiz Edilir

Yeterli sample ve planlanan süre tamamlandığında varyantlar karşılaştırılır. Statistical engine lift ve belirsizlik hesaplarını üretir. Guardrail metrikleri ayrıca incelenir. SRM veya tracking problemi varsa sonuç yorumlanmadan önce deney invalid kabul edilebilir. Son karar yalnız p-value veya tek bir probability değerine değil iş etkisi, risk ve öğrenme bağlamına dayanmalıdır.

Assignment ile Exposure Arasındaki Fark

Assignment kullanıcının hangi varyanta ayrıldığını, exposure ise kullanıcının test edilen deneyimi gerçekten gördüğünü ifade eder. Bu ayrım özellikle sayfanın alt kısmında, modal içinde veya belirli ürün akışında çalışan deneylerde önemlidir. Kullanıcı treatment grubuna atanmış olabilir fakat değişikliği hiç görmeden çıkmış olabilir. Böyle bir kullanıcıyı treatment populationına dahil etmek etkiyi yapay olarak azaltabilir. Güvenilir CRO altyapısı assignment ve exposure eventlerini ayrı kavramlar olarak işler.

Assignment Event Nedir?

Assignment event kullanıcının randomization sonucunu kaydeder. Kullanıcı ürün deneyimine ulaşmasa bile assignment gerçekleşebilir. Bu kayıt sistem health ve traffic allocation kontrolünde değerlidir. SRM analizi assignment seviyesinde yapılabilir. Conversion analizi için exposure population daha uygun olabilir.

Exposure Event Nedir?

Exposure event kullanıcının test edilen farklılığı gerçekten görmesiyle oluşur. Event deneyin etkilediği component render edildiğinde veya feature kullanıldığında gönderilebilir. Trigger çok erken olursa assignment ile aynı hale gelir. Çok geç olursa gerçek exposureların bir bölümü kaçabilir. QA sürecinde kullanıcı yolculuklarıyla doğrulanmalıdır.

Kullanıcının Varyantı Gerçekten Görmesi Neden Önemlidir?

Nedensel etkiyi ölçebilmek için kullanıcının değişiklikten etkilenmiş olması gerekir. Hiç görmediği bir varyant kullanıcının davranışını değiştiremez. Assignment-only population birçok deneyde dilution etkisi yaratabilir. Bununla birlikte intent-to-treat yaklaşımı bazı deney tasarımlarında bilinçli tercih olabilir. Hangi populationın kullanılacağı metodoloji dokümanında açıkça tanımlanmalıdır.

Yanlış Exposure Logging'in Sonuçları

Eksik exposure treatment sampleını olduğundan küçük gösterebilir. Duplicate exposure eventleri event volume analizini bozabilir. Yanlış varyant ID gönderilmesi conversionların hatalı gruba bağlanmasına neden olur. Bu hatalar istatistik motorunun matematiksel olarak doğru fakat gerçekte yanlış sonuç üretmesine yol açabilir. Data quality monitoring CRO platformunda bu nedenle birinci sınıf özellik olmalıdır.

Randomization Unit Nasıl Seçilir?

Randomization unit kullanıcıların deney gruplarına hangi temel kimlik üzerinden ayrılacağını belirler. Web CRO testlerinde user-level yaklaşım sık görülür, fakat B2B, marketplace ve network ürünlerinde account veya organization seviyesi daha doğru olabilir. Yanlış birim seçildiğinde aynı karar birimine bağlı kişiler farklı varyantlara düşerek contamination oluşturabilir. Örneğin kurumsal satın alma deneyinde aynı şirketteki iki kullanıcının farklı pricing varyantı görmesi ticari ve ölçümsel sorun yaratabilir. Seçim ürünün gerçek karar yapısına göre yapılmalıdır.

User-Level Randomization

User-level randomization her kullanıcıyı bağımsız deney birimi kabul eder. Bireysel SaaS ve e-ticaret akışlarında yaygındır. Login olmayan kullanıcılar için anonymous ID kullanılabilir. Cross-device davranış identity merge gerektirebilir. Aynı kişinin farklı cihazlarda farklı varyant görme riski analiz edilmelidir.

Session-Level Randomization

Session-level randomization her oturumda yeni varyant atayabilir. Bu yaklaşım sticky kullanıcı deneyimi açısından riskli olabilir. Kullanıcı bugün kontrol, yarın treatment görebilir. Bazı kısa süreli veya içerik deneylerinde kullanılabilir. Uzun kullanıcı yolculuklarında genellikle user-level yaklaşım daha anlaşılırdır.

Device-Level Randomization

Device-level randomization kullanıcı hesabının olmadığı ortamlarda pratik olabilir. Cookie veya local identifier kullanılabilir. Aynı kişi telefon ve bilgisayarda farklı varyant görebilir. Cross-device conversion attribution zorlaşabilir. Bu sınırlama test raporunda açıkça belirtilmelidir.

Account-Level Randomization

B2B veya ekip tabanlı SaaS ürünlerinde account-level randomization daha uygun olabilir. Aynı hesap içindeki bütün kullanıcılar aynı varyantı görür. Böylece ekip içi deneyim tutarlılığı korunur. İstatistiksel birim kullanıcı değil account olduğundan sample size planı buna göre yapılmalıdır. Kullanıcı sayısını account sample gibi kullanmak yanlış güven aralığı oluşturabilir.

Organization-Level Randomization

Organization-level randomization enterprise ürünlerde kullanılabilir. Büyük müşterinin tüm kullanıcıları aynı treatment altında tutulur. Kurumlar arası büyüklük farkı metric aggregation yöntemini etkileyebilir. Revenue gibi sonuçlar birkaç büyük müşteri tarafından domine edilebilir. Statistical plan cluster yapısını dikkate almalıdır.

Marketplace ve Network Ürünlerinde Randomization

Marketplace ürünlerinde alıcı ve satıcı davranışı birbirini etkileyebilir. Bir tarafın treatmentı kontrol grubunun sonucunu dolaylı biçimde değiştirebilir. Bu durum interference problemi oluşturur. Cluster, geographic veya marketplace-level experiment tasarımları gerekebilir. Standart user randomization her network ürününde güvenilir sonuç vermeyebilir.

Sticky Assignment Nedir?

Sticky assignment aynı kullanıcıya deney süresince aynı varyantın gösterilmesini sağlayan yaklaşımdır. Kullanıcı pazartesi treatment, salı control görürse deneyim tutarlılığı bozulabilir ve sonuç contamination yaşayabilir. Deterministic hashing, cookie veya server-side identity bu amaçla kullanılabilir. Login öncesi anonymous ID ile login sonrası user ID birleşimi dikkatli tasarlanmalıdır. Sticky davranış testin türüne göre bilinçli şekilde belirlenmelidir.

Aynı Kullanıcıya Aynı Varyantı Göstermek

Kullanıcı deney boyunca aynı varyantı gördüğünde deney etkisi daha tutarlı olur. Özellikle pricing, onboarding ve navigation değişikliklerinde bu önemlidir. Kullanıcı farklı varyantları görürse öğrenme veya alışkanlık etkisi oluşabilir. Assignment persistence test planında belirtilmelidir. QA farklı session ve cihaz senaryolarını kapsamalıdır.

Deterministic Hashing

Deterministic hashing identity ve experiment ID üzerinden sabit bir sayı üretir. Aynı giriş aynı sonucu verdiği için merkezi state saklama ihtiyacını azaltabilir. Trafik bucketları bu değer üzerinden varyantlara ayrılır. Hash algoritması ve bucketing mantığı değiştirilirse kullanıcı assignmentları kayabilir. Platform upgrade sürecinde stability testi yapılmalıdır.

Cookie-Based Assignment

Cookie tarayıcı tabanlı testlerde varyant bilgisini saklamak için kullanılabilir. Kullanıcı cookie'yi temizlerse yeniden assignment oluşabilir. Consent ve privacy gereksinimleri dikkate alınmalıdır. Cross-device tutarlılık sağlamaz. Login olan ürünlerde server-side identity daha güçlü çözüm olabilir.

Server-Side Identity

Server-side identity authenticated kullanıcılar için daha stabil assignment sağlar. User ID veya account ID backend tarafından bilinir. Feature flag evaluation sunucu tarafında yapılabilir. Client manipulation riski azalır. Latency ve availability için caching veya local evaluation değerlendirilebilir.

Cross-Session Consistency

Cross-session consistency kullanıcı farklı günlerde geri geldiğinde aynı deneyimi görmesini sağlar. Uzun testlerde önemlidir. Identity storage süresi deney süresinden kısa olmamalıdır. Anonymous kullanıcılar için browser storage sınırlamaları dikkate alınmalıdır. Login olduktan sonra identity merge politikası uygulanmalıdır.

Login Sonrası Identity Merge

Kullanıcı anonymous olarak treatment görüp login olduktan sonra control'a atanırsa deney contamination oluşabilir. Identity merge sistemi önceki assignmentı authenticated profile'a taşıyabilir. Ancak farklı cihaz geçmişleri çakışabilir. Öncelik kuralı açıkça tanımlanmalıdır. Exposure history analysis sırasında identity geçişi hesaba katılmalıdır.

Feature Flag ile A/B Test Arasındaki Fark

Feature flag bir özelliğin kimlere açık olduğunu kontrol eder, A/B testing ise varyantların davranış üzerindeki nedensel etkisini ölçmeye çalışır. Feature flag progressive rollout, kill switch ve operasyonel kontrol için mükemmeldir. Ancak metrics, exposure ve statistical analysis katmanı yoksa yalnız flag kullanarak güvenilir experimentation yapılamaz. Olgun platformlar feature flags ile experiment assignment mekanizmasını birlikte kullanabilir. Bu birleşim release riskini azaltırken ürün öğrenmesini de destekler.

Feature Flag Ne İşe Yarar?

Feature flag kod deployment ile feature release süreçlerini ayırır. Kod productionda bulunabilir fakat belirli kullanıcılar için kapalı tutulabilir. Yüzde 1, yüzde 10 ve yüzde 100 progressive rollout yapılabilir. Problem çıkarsa kill switch ile özellik kapatılabilir. Bu özellik experimentation dışında da değer taşır.

A/B Testing Ne İşe Yarar?

A/B testing iki veya daha fazla deneyimin outcome farkını ölçer. Randomization ve measurement temel gereksinimlerdir. Conversion, revenue veya retention gibi metricler karşılaştırılır. Test başlamadan decision rule belirlenmelidir. Sonuç ürün kararını desteklemek için kullanılır.

Flag ile Varyant Dağıtımı

Feature flag treatment ve control dağıtımı için kullanılabilir. Flag service deterministic assignment yapabilir. Experiment metadata ile flag config birlikte tutulabilir. Ancak exposure logging ayrıca gereklidir. Kullanıcının flag değerini alması her zaman featureı gördüğü anlamına gelmez.

Experimentation İçin Ölçüm Katmanı

Measurement layer exposure sonrası kullanıcı davranışını toplar. Primary ve guardrail metricler merkezi engine üzerinden hesaplanabilir. Identity tutarlılığı conversion attribution için gereklidir. Sample ratio ve event quality kontrolleri yapılmalıdır. Feature flag ürünü bu katmanı sağlamıyorsa ek analytics altyapısı gerekir.

Feature Flag Tek Başına Neden Yeterli Değildir?

Flag yalnız kullanıcıya hangi deneyimin sunulacağını söyleyebilir. Sonucun neden değiştiğini veya değişimin güvenilir olup olmadığını göstermez. Exposure ve conversion join yapılmadan lift hesaplanamaz. İstatistiksel belirsizlik ve SRM kontrolü ayrıca gereklidir. Bu nedenle flag experimentation altyapısının önemli ama tek olmayan parçasıdır.

Feature Flag Yaşam Döngüsü

Feature flags kalıcı config çöplüğüne dönüşmemelidir. Create, develop, QA, experiment, progressive rollout, full rollout ve cleanup adımları yaşam döngüsü olarak yönetilebilir. Kazanan varyant permanent hale geldikten sonra eski kod ve flag kaldırılmalıdır. Stale flag sayısı teknik borç KPI'ı olarak takip edilebilir. Kurumsal platformlarda owner ve expiry date tanımlamak bu süreci otomatikleştirir.

Create

Yeni flag oluşturulurken isim, owner ve amaç kaydedilmelidir. Experiment için kullanılacaksa experiment ID ile ilişkilendirilebilir. Default value güvenli davranışı temsil etmelidir. Targeting rules versionlanmalıdır. Production erişimi approval sürecine bağlı olabilir.

Develop

Geliştirme sırasında control ve treatment kodları flag arkasına alınır. Her iki path unit veya integration testten geçmelidir. Default variant bağımlılık kesintisinde çalışmalıdır. Instrumentation bu aşamada eklenmelidir. QA başlamadan tracking contract hazır olmalıdır.

QA

QA her varyantı zorla seçebilen test mode kullanabilir. Assignment, rendering ve exposure ayrı ayrı kontrol edilir. Mobile ve browser kapsamı doğrulanır. Event payloadları analytics debugger ile incelenir. Performance ve accessibility guardrail kontrolleri de yapılmalıdır.

Experiment

Experiment aşamasında trafik randomize edilir. Config değişiklikleri sınırlı tutulmalıdır. Test sırasında primary metric değiştirilmemelidir. Health dashboard SRM ve event volume izler. Kritik bug dışında treatment tasarımında değişiklik yapılmamalıdır.

Progressive Rollout

Kazanan varyant doğrudan yüzde 100'e açılmak zorunda değildir. Yüzde 10, 25 ve 50 gibi aşamalı rollout yapılabilir. Reliability ve guardrail metrics bu aşamada izlenir. Büyük backend değişikliklerinde kapasite riski azaltılır. Son karar sonrasında full rollout yapılır.

Full Rollout

Full rollout bütün eligible kullanıcıların kazanan deneyime geçtiği aşamadır. Experiment artık aktif randomization gerektirmeyebilir. Analytics sonuçları rollout sonrasında da izlenmelidir. Long-term metric değişimleri test sonucu ile karşılaştırılabilir. Ardından cleanup işi planlanmalıdır.

Cleanup

Cleanup control kodunu ve gereksiz flag configini kaldırır. Kazanan behavior normal product code haline gelir. Experiment-specific eventler gerekirse kapatılır. Documentation final decision ile güncellenir. Bu iş ertelenirse flag debt hızla büyür.

Stale Flag Yönetimi

Stale flag artık aktif kullanım amacı olmayan fakat kodda kalan flagdir. Otomatik expiry veya owner notification sistemi kullanılabilir. Repository scan ile eski flag referansları bulunabilir. Stale flag sayısı engineering health metriği olabilir. Düzenli cleanup günü teknik borcu kontrol altında tutar.

Client-Side A/B Testing

Client-side A/B testing varyant değişikliğinin tarayıcıda JavaScript veya benzeri client mekanizmasıyla uygulanmasıdır. CRO için A/B testing araçları ve deney platformları nasıl seçilir sorusunda client-side desteği özellikle hızlı landing page testlerinde önemlidir. Visual editor ve hızlı deployment avantaj sağlar. Buna karşılık flicker, layout shift, performance ve analytics timing sorunları görülebilir. Basit içerik veya stil deneylerinde kullanışlı olsa da checkout logic veya pricing gibi kritik backend davranışları için server-side yaklaşım daha doğru olabilir.

Nasıl Çalışır?

Client SDK sayfa açıldığında kullanıcı kimliği ve experiment config üzerinden varyantı değerlendirir. Treatment gerekiyorsa DOM veya component üzerinde değişiklik uygular. Exposure event değişiklik kullanıcıya gösterildiğinde gönderilir. Config remote servisten geliyorsa latency yönetilmelidir. Cache ve preload stratejileri flicker riskini azaltabilir.

Visual Editor

Visual editor teknik olmayan ekiplerin sayfa elementlerini hızlı değiştirmesine yardımcı olur. Metin, renk ve layout değişiklikleri kod yazmadan hazırlanabilir. Ancak karmaşık uygulama state'i olan modern frontendlerde editor güvenilir çalışmayabilir. DOM selector değişiklikleri testin bozulmasına neden olabilir. Production QA yine developer desteği gerektirebilir.

JavaScript Injection

JavaScript injection treatment değişikliğini runtime sırasında uygular. Script çok geç çalışırsa kullanıcı önce control içeriğini görebilir. Büyük injection kodu performance maliyeti oluşturabilir. Security policy ve CSP kısıtları da dikkate alınmalıdır. Kod review olmadan üretime dinamik script eklemek kurumsal risk oluşturabilir.

Avantajları

Client-side testing hızlı deney geliştirmeye imkan verir. Marketing ve CRO ekipleri küçük UI testlerini daha bağımsız yürütebilir. Backend deployment gerektirmeyen değişikliklerde time to experiment düşer. Landing page ve copy testleri için pratik olabilir. Mevcut analytics eventleriyle hızlı entegrasyon kurulabilir.

Sınırlamaları

Client-side testler flicker ve Core Web Vitals etkisi oluşturabilir. JavaScript devre dışı veya hata durumunda treatment uygulanmayabilir. Kritik business logic client tarafında güvenli biçimde değiştirilemez. Bot ve SEO davranışı split URL veya rendering modeline göre ayrıca değerlendirilmelidir. Büyük product experiment programında tek başına client-side yaklaşım yetersiz kalabilir.

Hangi Deneylerde Kullanılmalı?

Copy, görsel hiyerarşi, form label ve düşük riskli layout değişiklikleri client-side için uygun olabilir. Treatment yalnız browser görünümünü etkiliyorsa hızlı öğrenme sağlar. Backend state veya payment logic değişmiyorsa uygulama daha kolaydır. Performance guardrail yine izlenmelidir. Yüksek değerli funnel adımlarında daha güvenilir server veya hybrid yaklaşım düşünülmelidir.

Client-Side Testlerde Flicker Problemi

Flicker kullanıcıya önce control içeriğinin kısa süre görünmesi, ardından treatmentın uygulanmasıdır. Bu durum yalnız estetik problem değildir. Kullanıcı davranışını etkileyebilir, layout shift oluşturabilir ve test sonucunu kirletebilir. Deney grupları farklı performance koşulları yaşarsa ölçülen lift değişikliğin kendisinden değil yükleme farkından kaynaklanabilir. Bu nedenle client-side experimentation sisteminde flicker ve performance QA zorunlu olmalıdır.

Original Content Flash

Original content flash tarayıcının başlangıç HTML'ini render edip ardından treatment değişikliğini uygulamasıdır. Kullanıcı metnin veya fiyatın değiştiğini görebilir. Bu durum güveni azaltabilir. Variant script daha erken çalıştırılabilir veya kritik değişiklik server tarafına taşınabilir. Anti-flicker yöntemlerinin de kendi performans maliyeti olduğu unutulmamalıdır.

Layout Shift

Treatment element boyutunu değiştiriyorsa sonradan uygulanan DOM düzenlemesi CLS oluşturabilir. Control ve treatment farklı layout stability yaşayabilir. CLS guardrail olarak deney dashboardunda izlenebilir. Alan başlangıçtan rezerve edilebilir. Büyük tasarım değişikliklerinde server render daha uygun olabilir.

Performance Etkisi

Experiment SDK ve varyant kodu JavaScript payloadını artırabilir. Remote config çağrısı network latency ekleyebilir. Main thread çalışması INP etkisi yaratabilir. Core Web Vitals varyant bazında segmentlenmelidir. Pozitif conversion lift performance kaybıyla birlikte yorumlanmalıdır.

Deney Sonucunun Kirlenmesi

Treatment daha yavaş render oluyorsa kullanıcı davranışındaki fark tasarım değil latency kaynaklı olabilir. Bu durumda test farklı iki deneyim yerine farklı iki performans koşulunu da karşılaştırmış olur. Guardrail metrics bu sorunu görünür kılar. Exposure timing ile page performance verisi birleştirilebilir. Sonuç yorumunda teknik fark mutlaka değerlendirilmelidir.

Flicker Önleme Yöntemleri

Config preload, synchronous snippet veya server-side assignment kullanılabilir. Bazı sistemler içerik kısa süre gizleyerek anti-flicker yaklaşımı uygular. Ancak bu yöntem sayfanın görünmesini geciktirebilir. En iyi çözüm deney türüne göre değişir. Performance ölçmeden yalnız flicker görünümünü gizlemek doğru optimizasyon değildir.

Server-Side A/B Testing

Server-side A/B testing varyant kararının backend veya uygulama servisi üzerinde verilmesidir. Pricing, checkout, recommendation, API response ve onboarding logic gibi deneylerde güçlüdür. Kullanıcı sayfayı aldığında treatment zaten response içinde bulunabilir, bu nedenle client flicker riski azalır. Ancak engineering eforu ve platform entegrasyonu client-side teste göre daha yüksek olabilir. Server-side ve client-side A/B test altyapısı karşılaştırması yapılırken test hızının yanında güvenilirlik, performans, business logic ve veri kalitesi de değerlendirilmelidir.

Server-Side Assignment

Backend request sırasında user veya account identity üzerinden varyant belirlenir. Evaluation local SDK veya remote service ile yapılabilir. Remote dependency latency oluşturabileceği için caching önemlidir. Assignment sonucu response üretiminde kullanılır. Exposure yalnız feature gerçekten kullanıldığında loglanmalıdır.

Backend SDK

Backend SDK feature evaluation ve exposure API'lerini standardize eder. Java, Go, Node, Python veya diğer backend dilleri için SDK bulunabilir. SDK error durumunda default behavior açık olmalıdır. Version compatibility monitoring yapılmalıdır. Merkezi platform ekipleri ortak abstraction geliştirerek vendor lock-in riskini azaltabilir.

API Deneyleri

API response shape veya sıralaması server-side deneyle değiştirilebilir. Mobile ve web aynı backend assignmentı paylaşabilir. Experiment ID response metadata ile downstream clienta aktarılabilir. Exposure server veya client tarafından kaydedilebilir. Cross-platform measurement için identity tutarlılığı gerekir.

Pricing Logic

Pricing experiment yüksek ticari ve etik risk taşıyabilir. Account-level assignment gerekebilir. Fiyat deneyleri hukuk, brand ve fairness açısından review edilmelidir. Revenue kadar refund, cancellation ve retention guardrailleri izlenmelidir. Sonuç yalnız kısa vadeli conversion lift üzerinden verilmemelidir.

Checkout

Checkout deneylerinde payment ve order state backend tarafında yönetildiği için server-side yaklaşım güçlüdür. Treatment akışının transaction güvenilirliğini bozmaması gerekir. Error rate ve payment success guardrail olmalıdır. Revenue attribution finansal source of truth ile doğrulanabilir. Kill switch launch öncesi hazır tutulmalıdır.

Recommendation Engine

Recommendation algoritmaları server-side deneylerle karşılaştırılabilir. Randomization user veya session seviyesinde yapılabilir. CTR kısa vadeli secondary metric olabilir fakat revenue veya retention daha anlamlı primary veya OEC olabilir. Algorithm latency guardrail olarak izlenmelidir. Marketplace ürünlerinde interaction effects ayrıca değerlendirilmelidir.

Avantajları ve Dezavantajları

Server-side testing daha güvenilir feature delivery ve düşük flicker avantajı sunar. Kritik business logic üzerinde daha geniş deney alanı sağlar. Buna karşılık developer eforu ve platform entegrasyonu gerekir. Visual editor kadar hızlı değildir. Olgun programlarda client-side ve server-side yöntemler birbirinin alternatifi değil farklı kullanım alanları için tamamlayıcıdır.

Hybrid Experimentation Nedir?

Hybrid experimentation assignmentın server tarafında yapılıp rendering veya etkileşim değişikliğinin client tarafında uygulanabildiği modeldir. Bu yaklaşım kimlik ve randomization kontrolünü merkezileştirirken frontend esnekliğini korur. Shared experiment ID exposure ve conversion verilerinin bütün platformlarda aynı deneye bağlanmasını sağlar. Web, mobil ve backend davranışları tek deney içinde ölçülebilir. Karma ürün mimarisine sahip büyük organizasyonlarda hybrid model pratik denge sağlayabilir.

Server-Side Assignment

Varyant backend üzerinde belirlenir. Kullanıcı response içinde experiment context alabilir. Böylece farklı frontendler aynı assignmentı kullanır. Randomization merkezi kalır. Frontend kendi başına yeniden assignment yapmamalıdır.

Client-Side Rendering

Frontend kendisine verilen variant ID'ye göre component render eder. Visual değişiklik client kodunda olabilir. Assignment gecikmesi sayfa renderını engellememelidir. Default variant davranışı açık olmalıdır. Exposure component görünür olduğunda gönderilebilir.

Shared Experiment ID

Experiment ID web, API ve analytics sistemlerinde aynı olmalıdır. Bu ortak anahtar exposure ve conversion join işlemini kolaylaştırır. Naming convention merkezi yönetilmelidir. Environment farkları ayrı metadata ile tutulabilir. Production ve staging eventleri karışmamalıdır.

Cross-Platform Measurement

Kullanıcı webde exposure alıp mobil uygulamada conversion tamamlayabilir. Unified identity varsa bu davranış ölçülebilir. Attribution window ve channel kuralları önceden tanımlanmalıdır. Cross-device identity eksikse rapor sınırlılığı açıklanmalıdır. CDP veya warehouse entegrasyonu bu modeli güçlendirebilir.

Ne Zaman Tercih Edilir?

Backend kararının tutarlı olması ancak frontend deneyiminin hızlı değiştirilmesi gerektiğinde hybrid model kullanılabilir. Çok kanallı ürünler bu yaklaşımdan fayda görür. Pricing veya eligibility serverda, presentation clientta yönetilebilir. Platform karmaşası doğru SDK standardı olmadan büyüyebilir. Mimari yalnız esneklik için değil veri doğruluğu için tasarlanmalıdır.

A/B, A/B/n, Multivariate ve Split URL Testleri

Her deney aynı test formatını gerektirmez. A/B iki deneyimi, A/B/n birden fazla alternatif varyantı, multivariate test birden fazla element kombinasyonunu ve split URL ise farklı URL tabanlı deneyimleri karşılaştırabilir. Varyant sayısı arttıkça gerekli örneklem ve analiz yükü büyür. Düşük trafik üzerinde çok varyant açmak test süresini gereksiz uzatabilir. Test türü merak edilen nedensel soruya göre seçilmelidir.

A/B Testing

A/B testing control ve tek treatmentı karşılaştırır. En sade deney yapılarından biridir. Trafik iki gruba dağıtıldığı için sample verimliliği yüksektir. Güçlü tek hipotez için genellikle iyi başlangıçtır. Sonuç yorumlaması A/B/n modele göre daha kolaydır.

A/B/n Testing

A/B/n bir control ve birden fazla treatment içerir. Üç farklı onboarding akışı aynı anda değerlendirilebilir. Trafik daha fazla gruba bölünür. Multiple comparison konusu analysis planında dikkate alınmalıdır. Varyantların her biri anlamlı hipotez temsil etmelidir.

Multivariate Testing

Multivariate testing birden fazla element kombinasyonunun etkisini ölçmeye çalışır. Başlık, görsel ve CTA kombinasyonları örnek olabilir. Kombinasyon sayısı hızla büyüyebilir. Yüksek trafik gerektirir. Çoğu ekipte net A/B hipotezleri daha uygulanabilir olabilir.

Split URL Testing

Split URL farklı deneyimleri ayrı URL'ler üzerinden sunar. Büyük sayfa tasarımlarında veya farklı uygulama stacklerinde kullanılabilir. SEO ve canonical yönetimi dikkat gerektirir. Arama motoru trafiği ile deney dağıtımı uyumlu olmalıdır. Kalıcı duplicate URL yapısı oluşturulmamalıdır.

Hangi Test Türü Hangi Problem İçin?

Tek net hipotez için A/B en sade seçimdir. Birkaç bağımsız challenger varsa A/B/n düşünülebilir. Çok yüksek trafik ve interaction sorusu varsa multivariate anlamlı olabilir. Tamamen farklı page implementation karşılaştırılacaksa split URL kullanılabilir. Test tipi platform özelliğine göre değil öğrenilmek istenen soruya göre seçilmelidir.

A/A Test Nedir?

A/A test iki gruba işlevsel olarak aynı deneyimi göstererek experimentation altyapısının güvenilirliğini kontrol eder. Teoride iki grup arasında sistematik dönüşüm farkı beklenmez. Assignment, event tracking, exposure ve statistical engine bu test sırasında gözlemlenebilir. Platform devreye alınmadan önce birkaç A/A test çalıştırmak gerçek deneylerde çıkabilecek veri sorunlarını erkenden yakalayabilir. Ben yeni experimentation sistemlerinde ilk güven testlerinden biri olarak A/A çalışmasını özellikle değerli buluyorum.

Aynı Varyantı İki Gruba Vermek

Kullanıcılar iki random gruba ayrılır fakat iki grup da aynı deneyimi görür. Bu nedenle gerçek treatment etkisi yoktur. Metrik farklarının normal istatistiksel dalgalanma içinde kalması beklenir. Sistematik fark assignment veya tracking sorununu gösterebilir. Test yeterli sample ile çalıştırılmalıdır.

Assignment Altyapısını Doğrulamak

A/A test beklenen yüzde 50 ve yüzde 50 dağılımın gerçekleşip gerçekleşmediğini gösterir. SRM kontrolü uygulanabilir. Belirli browser veya region bir grupta fazla görünüyorsa assignment incelenmelidir. Sticky behavior ayrıca test edilebilir. Hash algoritması production trafik üzerinde doğrulanır.

Event Tracking'i Doğrulamak

İki grup aynı deneyimi gördüğü için conversion event dağılımı benzer olmalıdır. Bir varyantın event hacmi sistematik yüksekse instrumentation problemi olabilir. Variant property doğru gönderiliyor mu kontrol edilir. Missing event ve duplicate oranları analiz edilir. Data pipeline lag iki grup için karşılaştırılır.

False Positive Seviyesini İncelemek

Çok sayıda A/A deneyinin belirli oranında rastlantısal anlamlı fark görülmesi beklenebilir. Bu durum kullanılan significance threshold ile ilişkilidir. Platform sürekli A/A testlerinde beklenenden çok daha yüksek false positive üretiyorsa metodoloji incelenmelidir. Peeking davranışı sonucu artırabilir. Decision rule test sırasında değişmemelidir.

Platform Devreye Almadan Önce A/A Testi

Yeni platform doğrudan yüksek değerli checkout testinde denenmemelidir. Önce düşük riskli A/A deneyleriyle sistem health doğrulanabilir. Assignment, exposure, metrics ve dashboard kontrol edilir. Operasyon ekibi launch ve stop süreçlerini pratik eder. Sonrasında gerçek A/B test daha güvenli başlatılır.

Experiment Tracking Plan Nasıl Hazırlanır?

Tracking plan deney başlamadan önce hangi eventlerin, properties değerlerinin ve identity alanlarının kullanılacağını tanımlar. Event taxonomy ile naming convention ekipler arasında ortak dil oluşturur. Experiment ID, variant ID ve exposure timestamp her deney eventini analiz edilebilir hale getirir. Tracking plan QA ekibinin neyi kontrol edeceğini de netleştirir. Plansız event üretimi zamanla analytics sisteminde aynı davranışın farklı isimlerle kaydedilmesine yol açar.

Event Taxonomy

Event taxonomy kullanıcı davranışlarını mantıksal kategorilere ayırır. Page, product, checkout ve account eventleri gruplanabilir. Aynı davranış için farklı ekiplerin farklı isim kullanması önlenir. Taxonomy dokümanı versionlanmalıdır. Yeni event eklemek review gerektirebilir.

Event Naming Convention

Naming convention event isimlerinin biçimini standardize eder. Verb-object veya object-action gibi model seçilebilir. Büyük ve küçük harf kullanımı sabit olmalıdır. PurchaseCompleted ve purchase_completed gibi iki farklı format aynı sistemde kullanılmamalıdır. İsim kullanıcı davranışını açıkça anlatmalıdır.

Event Properties

Properties eventin bağlamını taşır. Product ID, page type veya payment method örnek olabilir. Gereksiz property eklemek veri maliyeti ve privacy riskini artırır. Tip ve allowed values açıkça tanımlanmalıdır. Schema değişikliği version ile yönetilmelidir.

User Properties

User properties segment analizinde kullanılabilir. Customer type, subscription plan veya country örnek olabilir. Sensitive PII experimentation için gereksizse toplanmamalıdır. Property snapshot mı yoksa güncel değer mi kullanılacağı metric planında belirtilmelidir. Test sırasında değişen user properties segment yorumunu etkileyebilir.

Experiment ID

Experiment ID deneyin sistemler arası ortak kimliğidir. Human-readable isim yanında stabil teknik ID kullanılabilir. Bir isim daha sonra değişse bile ID sabit kalır. Warehouse ve dashboard join işlemleri bu alanı kullanabilir. ID tekrar kullanılmamalıdır.

Variant ID

Variant ID control ve treatment seçeneklerini ayırır. “A” ve “B” yerine anlamlı ama stabil kodlar tercih edilebilir. Display name değişebilir fakat technical ID değişmemelidir. Analytics payloadında variant ID bulunmalıdır. Yanlış mapping ciddi data quality sorunu oluşturur.

Exposure Timestamp

Exposure timestamp attribution window başlangıcını belirleyebilir. Kullanıcının conversion eventinin exposuredan önce gelmemesi gerekir. Timestamp timezone standardı ortak olmalıdır. Client clock güvenilmezse server receive time alternatif olarak tutulabilir. Event ordering kontrolleri pipeline içinde yapılabilir.

CRO İçin Event Naming Standardı

Event naming standardı CRO analizinin tekrar kullanılabilir olmasını sağlar. Page Viewed, Product Viewed, Add to Cart, Checkout Started, Purchase Completed, Form Submitted ve Signup Completed gibi olaylar ürün funnelını açık biçimde temsil edebilir. Gerçek isimlendirme stiliniz farklı olabilir, önemli olan bütün ekiplerin aynı davranış için aynı event contractını kullanmasıdır. Event versiyonlama eski dashboardların bozulmasını önler. Dönüşüm oranı optimizasyonu sisteminde measurement foundation iyi değilse hiçbir A/B test motoru bu eksikliği telafi edemez.

Page Viewed

Page Viewed sayfa görüntüleme davranışını temsil eder. SPA sistemlerinde route change ile browser reload ayrımı açık olmalıdır. Page type ve URL properties eklenebilir. Duplicate page eventler session metricsi bozabilir. Experiment exposure ile event sırası kontrol edilmelidir.

Product Viewed

Product Viewed ürün detay görüntülemesini temsil eder. Product ID ve category properties tutulabilir. Aynı component viewporta girdiğinde tekrar event üretme politikası belirlenmelidir. Recommendation testlerinde bu event secondary metric olabilir. Bot ve internal traffic filtreleri uygulanmalıdır.

Add to Cart

Add to Cart önemli commerce funnel eventidir. Quantity ve product ID gibi bilgiler içerebilir. Client click ile server cart success aynı şey değildir. Primary metric için başarılı cart mutation eventini kullanmak daha güvenilir olabilir. Duplicate event idempotency ile kontrol edilebilir.

Checkout Started

Checkout Started kullanıcının ödeme akışına girişini temsil eder. Event trigger'ın hangi adım olduğu açık olmalıdır. Cart sayfasını görüntülemek checkout başlatmak sayılmayabilir. Funnel metric standardı bütün deneylerde aynı olmalıdır. Checkout redesign testlerinde güçlü secondary metric olabilir.

Purchase Completed

Purchase Completed mümkünse server-side order success kaynağından üretilmelidir. Client thank-you page eventine tek başına güvenmek eksik veya duplicate kayıt yaratabilir. Order ID deduplication için kullanılabilir. Revenue finansal sistemle karşılaştırılmalıdır. Experiment ROI analizinin önemli kaynağıdır.

Form Submitted

Form Submitted yalnız buton tıklamasını değil başarılı submission sonucunu temsil etmelidir. Validation error olan kullanıcı conversion sayılmamalıdır. Backend success event daha güvenilir olabilir. Form type property eklenebilir. B2B lead testlerinde qualified lead ile birlikte kullanılması daha anlamlıdır.

Signup Completed

Signup Completed hesap oluşturmanın başarıyla tamamlandığını gösterir. E-posta doğrulama gerekiyorsa activation ile signup ayrılabilir. Deney primary metric seçimi ürün amacına bağlıdır. Basit account creation artarken activation düşebilir. Guardrail veya secondary metrics bu farkı ortaya çıkarır.

Event Versiyonlama

Event schema değiştiğinde version bilgisi tutulmalıdır. Property anlamı değişirse eski ve yeni veriyi aynı metricte karıştırmak risklidir. Migration dönemi için dual tracking kullanılabilir. Metric engine doğru versionları seçmelidir. Event catalog değişiklik tarihini saklamalıdır.

Analytics'te Source of Truth Nasıl Belirlenir?

Bir deney sonucunda testing platform, web analytics, product analytics ve finansal sistem farklı dönüşüm sayıları gösterebilir. Bu durum her zaman bug anlamına gelmez. Identity, sessionization, attribution window, bot filtering ve event processing kuralları sistemler arasında değişebilir. Deney başlamadan hangi metric için hangi kaynağın source of truth olduğu belirlenmelidir. Özellikle revenue testlerinde finansal veri ile product analytics arasında reconciliation yapılması önemlidir.

Testing Platform Analytics

Testing platform exposure ve deney populationı için güçlü kaynak olabilir. Ancak conversion eventlerini kendi scriptiyle topluyorsa ana analytics sisteminden farklı sayılar üretebilir. Metric logic açıkça incelenmelidir. Raw event export büyük avantaj sağlar. Platform dashboardundaki hazır metricler körü körüne kabul edilmemelidir.

Web Analytics

Web analytics trafik ve marketing attribution için güçlü olabilir. Cookie ve consent davranışı deney populationını etkileyebilir. Ad blocker veya browser restriction event kaybı oluşturabilir. A/B result için user-level identity yeterli mi kontrol edilmelidir. Testing engine olarak tek başına kullanılması genellikle uygun değildir.

Product Analytics

Product analytics kullanıcı funnel ve feature davranışında güçlüdür. Event taxonomy experimentation ile uyumluysa conversion metric kaynağı olabilir. Identity merge ve cross-platform tracking değerlendirilmelidir. Event schema governance önemlidir. Metric definitions experimentation repository ile ilişkilendirilebilir.

Data Warehouse

Warehouse farklı kaynakları birleştiren en esnek source of truth olabilir. Exposure, behavior ve revenue aynı sorguda analiz edilebilir. SQL metric definitions versionlanabilir. Data latency real-time dashboarda göre daha yüksek olabilir. Warehouse-native experimentation özellikle veri ekibi güçlü organizasyonlarda etkili yaklaşım olabilir.

Finansal Sistem

Revenue, refund ve realized profit için finansal sistem daha doğru kaynak olabilir. Analytics eventinde görünen purchase daha sonra iptal veya refund olabilir. Uzun vadeli experiment ROI bu farklılığı hesaba katmalıdır. Order ID üzerinden reconciliation yapılabilir. Financial data availability delay karar zamanını etkileyebilir.

Farklı Sistemlerde Sayılar Neden Farklılaşır?

Consent, timezone, user identity ve event filtering farkları sayı değişimine neden olabilir. Bir sistem session, diğeri user bazında metric hesaplayabilir. Attribution window farklı olabilir. Duplicate order filtreleri aynı olmayabilir. Sayıları zorla eşitlemek yerine neden farklı olduklarını belgelemek daha doğru yaklaşımdır.

GA4 ile A/B Testing Altyapısı Nasıl Entegre Edilir?

GA4 deney assignment ve variant bilgisini analytics segmentlerine taşımak için kullanılabilir. Ancak GA4'ü tek başına randomization ve statistical experiment engine olarak görmek doğru değildir. Experiment assignment event veya property ile gönderilebilir, conversion eventleri mevcut measurement sistemi üzerinden takip edilebilir. Data warehouse export daha ayrıntılı analiz sağlar. Deney platformu ile analytics arasındaki identity ve timestamp uyumu entegrasyonun kalitesini belirler.

Experiment Assignment Event'i

Kullanıcı varyanta atandığında assignment event gönderilebilir. Event experiment ID ve variant ID içermelidir. Assignment ile exposure ayrımı korunmalıdır. Analytics raporunda assignment sayısı health kontrolü için kullanılabilir. Final analysis exposure population üzerinden yapılabilir.

Variant Property

Variant property eventlere deney bağlamı ekleyebilir. Bu özellik debugging ve segment analysis için faydalıdır. Çok sayıda eş zamanlı deney varsa tek property yetersiz olabilir. Experiment context array veya ayrı event modeli gerekebilir. Analytics schema sınırları baştan değerlendirilmelidir.

Conversion Event

Mevcut GA4 conversion eventleri deney secondary analysisinde kullanılabilir. Event definition experimentation metric ile aynı olmalıdır. Client-side kayıp olasılığı yüksek revenue olaylarında server-side data tercih edilebilir. Event duplication kontrolü yapılmalıdır. Analytics sayısı source of truth değilse karar raporunda bu durum açıklanmalıdır.

Audience Segments

Experiment variant bilgisi audience veya exploration segmentlerinde kullanılabilir. Bu yöntem davranış keşfi için yararlıdır. Post-hoc çok sayıda segment aramak false discovery riskini artırır. Confirmatory segmentler testten önce tanımlanmalıdır. Analytics exploration sonucu yeni hipotez üretmek için kullanılabilir.

Data Warehouse Export

Warehouse export event-level analizi kolaylaştırır. Exposure eventleri GA4 data ile SQL üzerinden birleştirilebilir. Identity ve timestamp normalization yapılmalıdır. Statistical analysis ayrı pipeline ile çalıştırılabilir. Ham veri denetimi platform dashboarduna bağımlılığı azaltır.

GA4'ü Tek Başına Experiment Engine Olarak Görmemek

GA4 analytics ve audience analizi için güçlü olabilir fakat assignment, sticky bucketing, SRM ve decision rule gibi experimentation ihtiyaçlarının tamamını çözmez. Randomization ayrı platform veya uygulama katmanında yapılmalıdır. Exposure logging standardı oluşturulmalıdır. Statistical engine metodolojisi ayrıca tanımlanmalıdır. Entegrasyon, araçların güçlü olduğu rolleri birbirine bağlamalıdır.

CDP ve Data Warehouse Entegrasyonu

CDP ve data warehouse entegrasyonu farklı kanallardaki identity, exposure ve conversion verilerini aynı kullanıcı bağlamında birleştirebilir. Unified customer ID özellikle webden exposure alıp mobilde conversion tamamlayan kullanıcıların ölçümünde önemlidir. Revenue ve long-term retention gibi metrikler warehouse üzerinden hesaplanabilir. Warehouse-native experimentation merkezi metric definitions açısından güçlüdür. Bununla birlikte privacy ve identity governance daha dikkatli yönetilmelidir.

Unified Customer ID

Unified ID farklı cihaz ve kanallardaki davranışları ilişkilendirir. Anonymous ve authenticated identity merge kuralları belirlenmelidir. Aynı kişinin duplicate profile oluşturması experiment populationını bozabilir. PII yerine internal pseudonymous ID tercih edilebilir. Identity graph doğruluğu düzenli ölçülmelidir.

Experiment Exposure Data

Exposure eventleri CDP veya warehouse'a gönderilebilir. Experiment ID, variant ve timestamp temel alanlardır. Source system metadata debugging için faydalıdır. Duplicate exposure handling kuralı metric engine içinde bulunmalıdır. Event retention experiment repository süresiyle uyumlu olmalıdır.

Conversion Data

Conversion data web analytics, backend veya CRM kaynaklarından gelebilir. Her metric için authoritative source tanımlanmalıdır. Lead created ile qualified lead ayrı olaylardır. Attribution exposure sonrasındaki uygun pencereye göre yapılmalıdır. Late-arriving events analysis refresh gerektirebilir.

Revenue Data

Revenue order veya billing sisteminden alınabilir. Gross revenue ile net revenue farklı metriclerdir. Refund ve cancellation etkisi long-term OEC içinde değerlendirilebilir. Currency normalization global ürünlerde gereklidir. Revenue per user CRO açısından güçlü primary metric olabilir.

Long-Term Metrics

Retention, repeat purchase ve churn deney bitiminden haftalar sonra ölçülebilir. Kısa test sonucunda hemen görünmez. Experiment repository long-term refresh desteklemelidir. Holdout groups uzun vadeli etkiyi ölçmek için kullanılabilir. Kısa vadeli conversion kazancı uzun vadeli zarar üretmediğinden emin olunmalıdır.

Warehouse-Native Experimentation

Warehouse-native yaklaşım mevcut event ve business verisini doğrudan deney analizinde kullanır. Ayrı analytics kopyası oluşturmaya gerek kalmayabilir. Metric SQL definitions version control altında tutulabilir. Data latency ve compute maliyeti dikkate alınmalıdır. Güçlü veri mühendisliği ekibi bulunan organizasyonlarda esneklik sağlar.

Experiment Metric Nasıl Tanımlanır?

Experiment metric yalnız bir dashboard ismi değildir. Metric name, numerator, denominator, population, attribution window, aggregation method ve data source birlikte tanımlanmalıdır. Aynı “conversion rate” ifadesi farklı ekiplerde tamamen farklı hesaplanabilir. Metric catalog bu tanımları merkezi olarak saklamalıdır. Test başlamadan metric definition değişmez hale getirildiğinde sonuç üzerinde sonradan oynama riski azalır.

Metric Name

Metric adı neyin ölçüldüğünü açıkça anlatmalıdır. “Conversion” gibi belirsiz isim yerine “Purchase Conversion per Exposed User” daha anlaşılır olabilir. Display name ile technical key ayrı tutulabilir. İsim yıllar içinde aynı anlamı korumalıdır. Değişiklik gerekiyorsa yeni version oluşturulmalıdır.

Numerator

Numerator başarı olayını tanımlar. Purchase metricinde satın alma yapan kullanıcı sayısı veya order sayısı olabilir. Aynı kullanıcı birden fazla purchase yapabiliyorsa metric türü değişir. Binary conversion ile count metric ayrılmalıdır. Numerator event deduplication kuralı içermelidir.

Denominator

Denominator deney populationını belirler. Exposed user, session veya account kullanılabilir. Yanlış denominator conversion oranını ciddi biçimde değiştirir. Randomization unit ile metric unit uyumu önemlidir. Metric dokümanı bunu açıkça göstermelidir.

Population

Population hangi kullanıcıların metric hesabına dahil olduğunu belirtir. Eligible assigned users veya exposed users farklı sonuç üretebilir. Geographic veya plan filterları testten önce tanımlanmalıdır. Post-hoc population değişikliği p-hacking riskini artırır. Analysis population decision rule içinde bulunmalıdır.

Attribution Window

Attribution window exposure ile outcome arasındaki süreyi belirler. E-ticarette birkaç gün, B2B lead sürecinde haftalar gerekebilir. Çok kısa pencere conversion kaybeder. Çok uzun pencere başka etkileri dahil edebilir. Ürün davranışına göre seçilmelidir.

Aggregation Method

Metric kullanıcı başına average, ratio, sum veya binary dönüşüm olabilir. Revenue gibi heavy-tailed veriler özel istatistik yaklaşımı gerektirebilir. Winsorization veya variance reduction yöntemleri kullanılacaksa önceden tanımlanmalıdır. Aggregation experiment başladıktan sonra sonuca göre değiştirilmemelidir. Engine aynı tanımı bütün deneylerde tutarlı uygulamalıdır.

Data Source

Data source event tablosu veya business system kaynağını belirtir. Purchase için order database, engagement için product analytics kullanılabilir. Source değişirse metric version değişebilir. Data latency bilinmelidir. Experiment dashboard sonuç timestampini göstermelidir.

Primary Metric Nedir?

Primary metric deneyin ana başarı kriteridir. Hipotez hangi kullanıcı davranışını değiştirmeyi hedefliyorsa metric bu davranışla doğrudan ilişkili olmalıdır. Conversion rate, revenue per user, activation veya retention örnek olabilir. Bir deneyde çok sayıda primary metric tanımlamak karar belirsizliği yaratır. Ana metric yanında secondary ve guardrail metricler sonucu açıklamak ve riski kontrol etmek için kullanılır.

Testin Ana Başarı Kriteri

Primary metric test başlamadan önce seçilmelidir. Treatmentın başarılı sayılması bu metric üzerinde beklenen yönlü etkiye bağlıdır. Metric değişikliği test sonucuna bakıldıktan sonra yapılmamalıdır. İş değerini temsil etmelidir. Decision rule doğrudan primary metric ile bağlantılıdır.

Conversion Rate

Conversion rate signup, purchase veya form completion gibi binary outcome için uygundur. Denominator user veya session olabilir. Baseline sample size planında kullanılır. Düşük baseline daha büyük sample gerektirebilir. Conversionın gerçekten iş değeri taşıdığı doğrulanmalıdır.

Revenue per User

Revenue per user conversion ile order value etkisini birlikte yakalar. E-ticarette güçlü OEC adayı olabilir. Dağılım çok değişken olabilir. Büyük siparişler varianceı artırabilir. Statistical engine bu metric türüne uygun yöntem kullanmalıdır.

Activation

SaaS onboarding testlerinde activation final purchase'tan daha hızlı feedback sağlayabilir. Activation event gerçekten gelecekteki kullanıcı değerini öngörmelidir. Sadece kolay ölçüldüğü için seçilmemelidir. Retention correlation geçmiş veriyle doğrulanabilir. Deney programı zaman içinde daha iyi activation tanımı geliştirebilir.

Retention

Retention uzun vadeli kullanıcı değerini güçlü şekilde temsil eder. Ancak sonucu beklemek deney karar süresini uzatabilir. Proxy metric kısa vadeli primary, retention ise guardrail veya long-term metric olabilir. Holdout ile takip edilebilir. Kısa vadeli kazanan değişikliğin churn yaratmadığından emin olmak önemlidir.

Hipotezle Metrik Uyumu

Hipotez checkout friction azaltıyorsa primary metric purchase completion olabilir. Aynı testte homepage pageviews ana metric seçilirse nedensel bağ zayıflar. Metric değişikliğin beklenen mekanizmasını yansıtmalıdır. Secondary metricler ara davranışı açıklayabilir. Hipotez ve metric review launch öncesi yapılmalıdır.

Secondary Metric Nedir?

Secondary metrics deney sonucunun arkasındaki davranışı anlamaya yardımcı olur. Funnel steps, average order value, engagement ve önceden tanımlanmış segment sonuçları bu gruba girebilir. Ana karar primary metric üzerinden verilir. Secondary sonuçlar mechanism ve future hypothesis üretmek için kullanılır. Çok sayıda secondary metric içinde yalnız olumlu olanı seçmek false discovery riskini artırır.

Kullanıcı Davranışını Açıklamak

Primary conversion arttığında bunun neden arttığını secondary metrics gösterebilir. Örneğin treatment kullanıcıları checkouta daha fazla geçirmiş olabilir. Product view veya add to cart değişimi mekanizmayı açıklar. Bu bilgi sonraki test hipotezlerini besler. Secondary metrics önceden seçildiğinde yorum daha güvenilir olur.

Funnel Steps

Funnel step metrics kullanıcıların hangi aşamada kaybedildiğini gösterir. Product viewed, add to cart ve checkout started ayrı izlenebilir. Treatment yalnız bir adımı iyileştirip sonraki adımı kötüleştirebilir. Drop-off patterni mekanizmayı gösterir. Final conversion her zaman funnelın bütün hikayesini anlatmaz.

Average Order Value

Conversion yükselirken average order value düşebilir. Bu durumda revenue per user net etkiyi daha doğru gösterebilir. Discount veya bundle deneylerinde özellikle önemlidir. AOV distribution segment bazında değişebilir. Primary metric ile birlikte değerlendirilmelidir.

Engagement

Engagement time, feature usage veya content depth bazı deneylerde açıklayıcı olabilir. Engagement artışı her zaman iş değeri artışı anlamına gelmez. Kullanıcı daha fazla zaman harcıyor çünkü görev zorlaşmış olabilir. Context önemlidir. Metric yönü önceden “iyi” veya “kötü” olarak tanımlanmalıdır.

Segment Sonuçları

New vs returning veya mobile vs desktop segmentleri önceden tanımlanabilir. Segment interaction için yeterli sample gerekir. Toplam sonuç negatifken küçük bir segmentte pozitif fark görülmesi yeni hipotez olabilir. Doğrudan rollout kararı için confirmatory follow-up gerekebilir. Post-hoc segment avcılığı yapılmamalıdır.

Guardrail Metric Nedir?

Guardrail metric bir değişiklik ana hedefi iyileştirirken ürünün başka önemli alanına zarar verip vermediğini kontrol eder. Error rate, page speed, refund, cancellation, retention ve accessibility guardrail örnekleridir. Conversion artarken checkout error oranı yükseliyorsa treatment güvenli kabul edilmeyebilir. CRO ekibinin yalnız kazancı değil yan etkileri de ölçmesi gerekir. Olgun experimentation programlarında guardrails launch checklistin zorunlu parçasıdır.

Kazanırken Başka Bir Alanı Bozmamak

Bir değişiklik kullanıcıyı daha agresif biçimde satın almaya yönlendirebilir. Kısa vadede conversion artarken refund veya complaint artabilir. Bu nedenle başarı tek dimension ile ölçülmemelidir. Guardrails korunması gereken ürün kalitesi sınırlarını tanımlar. Rollout kararı bu sınırlar ihlal edilirse durdurulabilir.

Error Rate

Backend veya frontend error rate teknik deneylerde önemli guardraildir. Yeni checkout flow conversion artırsa bile API error yükseliyorsa rollout risklidir. Error metric experiment variant bazında segmentlenmelidir. Infrastructure monitoring ile experiment dashboard birleştirilebilir. Critical threshold otomatik kill switch tetikleyebilir.

Page Speed

Client-side personalization veya yeni component page speed'i etkileyebilir. LCP ve INP experiment guardrail olabilir. Performance farkı kullanıcı davranışını da dolaylı etkiler. Varyantlar eşit teknik koşullarda olmalıdır. Pozitif conversion lift büyük performance kaybını otomatik olarak haklı çıkarmaz.

Refund

Pricing veya promotion deneylerinde refund rate önemlidir. Kullanıcı yanlış beklentiyle conversion yapmış olabilir. Kısa deney penceresinde refundlar geç gelebilir. Long-term refresh yapılmalıdır. Net revenue metric bu etkileri kapsayabilir.

Cancellation

Subscription ürünlerde trial veya signup artışı cancellation yükselişiyle birlikte görülebilir. Bu durum düşük kaliteli acquisition göstergesi olabilir. Cancellation birkaç hafta sonra gerçekleşebilir. Test sonucu repository içinde sonradan güncellenebilir. OEC kısa ve uzun vadeli metricleri dengelemelidir.

Retention

Retention kullanıcı değerinin uzun vadeli göstergesidir. Onboarding friction azaltılırken yanlış kullanıcıları ürüne çekmek retentionı düşürebilir. Cohort bazında kontrol ve treatment karşılaştırılabilir. Holdout group faydalı olabilir. Primary conversion kararı retention guardrailiyle birlikte ele alınmalıdır.

Accessibility

Conversion artıran tasarım accessibility standardını bozmamalıdır. Kontrast, keyboard navigation ve screen reader davranışı QA kapsamında kontrol edilmelidir. Accessibility fixleri test sonucu beklemeden uygulanması gereken alanlar olabilir. Guardrail otomatik test ve manual review içerebilir. Etik CRO kullanıcı erişilebilirliğini ticari metrik uğruna azaltmaz.

Overall Evaluation Criterion (OEC) Nedir?

Overall Evaluation Criterion deney programının uzun vadeli iş ve kullanıcı değerini temsil eden üst seviye başarı çerçevesidir. Yalnız kısa vadeli conversion oranına bağlı kalmamak için kullanılır. Revenue per user, retention ve kullanıcı memnuniyeti gibi bileşenler birlikte düşünülebilir. OEC her deneyde tek formül olmak zorunda değildir fakat organizasyonun neyi optimize ettiğini açık hale getirir. Bu yaklaşım lokal metric kazanımlarının global ürün zararına dönüşmesini engellemeye yardımcı olur.

Kısa Vadeli Conversion'ın Ötesine Geçmek

CTA tıklaması kısa sürede ölçülür fakat iş değerini tam temsil etmeyebilir. Kullanıcı tıklayıp checkoutta vazgeçebilir. Bu nedenle final conversion veya revenue daha anlamlı olabilir. Uzun vadeli retention ayrıca izlenebilir. OEC metric seçimini iş stratejisine bağlar.

İş Değeri

OEC revenue, profit veya qualified lead gibi business metricleri içerebilir. Vanity metrics ana hedef olmamalıdır. B2B ürünlerde pipeline revenue aylar sonra ortaya çıkabilir. Proxy metric geçmiş korelasyonla seçilebilir. Long-term validation sürdürülmelidir.

Kullanıcı Değeri

Kullanıcı için iyi deney yalnız daha fazla purchase değildir. Görevi daha hızlı tamamlamak, yanlış satın alma yapmamak ve güven duymak önemlidir. Satisfaction veya support contact metricleri yardımcı olabilir. Dark pattern kullanarak conversion artırmak OEC yaklaşımıyla çelişir. Uzun vadeli kullanıcı güveni ürün değerinin parçasıdır.

Uzun Vadeli Etki

Deney bitiminden sonra retention ve repeat purchase gözlemlenebilir. İlk iki haftadaki kazanç birkaç ay sonra kaybolabilir. Permanent holdout uzun vadeli incrementality ölçümünde faydalıdır. Experiment repository sonuçları zaman içinde güncellenebilir. Karar kalitesi yalnız launch günündeki metriclere bağlanmamalıdır.

Guardrail Dengesi

OEC ana başarı yönünü, guardrails ise kabul edilemez yan etkileri tanımlar. Primary metric pozitif olsa bile guardrail ihlali rollout engelleyebilir. Bu kurallar testten önce belirlenmelidir. Riskli deneylerde daha sıkı threshold kullanılabilir. Product ve data ekipleri birlikte decision framework oluşturmalıdır.

Dönüşüm Oranı Nasıl Hesaplanır?

Dönüşüm oranı temel olarak conversion sayısının ilgili populationa bölünmesiyle hesaplanır. Ancak user-based, session-based ve event-based yöntemler aynı testte farklı değerler üretebilir. Dönüşüm oranı optimizasyonu için metric unit randomization unit ile uyumlu olmalıdır. Kullanıcı randomize edilip session dönüşümü analiz edildiğinde bağımsızlık varsayımı bozulabilir. Bu nedenle metric hesaplama formülü launch öncesi analytics ve data science reviewundan geçmelidir.

User-Based Conversion

User-based conversion en az bir conversion yapan kullanıcıların exposed kullanıcı sayısına oranıdır. Aynı kişi üç purchase yapsa bile binary metricte bir conversion sayılır. Signup veya form completion için uygundur. Randomization user seviyesindeyse istatistiksel açıdan doğal eşleşme sağlar. Anonymous identity kalitesi önemlidir.

Session-Based Conversion

Session conversion conversionlı sessionların toplam sessionlara oranıdır. Bir kullanıcının birden fazla sessionı bulunabilir. Session tanımı analytics sistemine göre değişebilir. User randomization ile session metric kullanıldığında cluster etkisi göz önüne alınmalıdır. Web funnel analizinde açıklayıcı secondary metric olarak kullanılabilir.

Event-Based Conversion

Event-based metric toplam conversion event sayısını başka bir event veya populationa oranlayabilir. Purchase count veya add-to-cart eventleri örnek olabilir. Aynı kullanıcının yoğun davranışı sonucu domine edebilir. Deney objectiveine göre doğru olabilir. Statistical distribution user-based binary metricten farklıdır.

Paydanın Yanlış Seçilmesinin Etkisi

Denominator deney sonucunun anlamını belirler. Exposure yaşamayan assigned kullanıcıları dahil etmek lift değerini küçültebilir. Sessions yerine users kullanmak oranı değiştirebilir. Population test başladıktan sonra değiştirilirse sonuç manipülasyonuna açık hale gelir. Metric spec payda tanımını açıkça saklamalıdır.

A/B Test Hipotezi Nasıl Yazılır?

İyi A/B test hipotezi gözlenen problemi, önerilen değişikliği, hedef kullanıcıyı, beklenen davranışı, primary metric'i ve neden bu etkinin beklendiğini açıklar. “Yeni tasarım daha iyi olacak” test edilebilir güçlü bir hipotez değildir. Hipotez falsifiable olmalıdır, yani veriler hipotezin yanlış olduğunu gösterebilmelidir. Araştırma bulgusu veya analytics kanıtı gerekçe kısmında yer almalıdır. Bu standart ekiplerin rastgele fikirleri test kuyruğuna eklemesini azaltır.

Gözlenen Problem

Hipotez gerçek bir kullanıcı veya business probleminden başlamalıdır. Funnel drop, user interview veya usability observation kaynak olabilir. “Sayfayı değiştirmek istiyoruz” problem tanımı değildir. Problem metric ve evidence ile desteklenmelidir. Aynı problem için farklı çözüm hipotezleri üretilebilir.

Önerilen Değişiklik

Değişiklik treatmentın neyi farklı yapacağını net biçimde açıklar. Birden fazla büyük değişiklik aynı treatmentta birleştirilirse hangi unsurun etki yarattığını anlamak zorlaşır. Ancak büyük redesign testinde paket değişiklik bilinçli olabilir. Scope experiment repository içinde belgelenmelidir. Varyant screenshot veya specification eklenebilir.

Hedef Kullanıcı

Hedef kullanıcı eligibility populationını tanımlar. New visitors, mobile users veya trial customers örnek olabilir. Segment sonradan seçilmemelidir. Population business problemle ilişkili olmalıdır. Sample size bu eligible trafik üzerinden hesaplanmalıdır.

Beklenen Davranış

Hipotez kullanıcının neyi farklı yapacağını söyler. Formu daha fazla tamamlamak veya checkouta daha hızlı geçmek örnek olabilir. Davranış ölçülebilir olmalıdır. Belirsiz “memnuniyet artacak” ifadesi ölçüm planı olmadan yetersizdir. Beklenen mekanizma secondary metrics ile desteklenebilir.

Primary Metric

Hipotez primary metric ile doğrudan bağlantılı olmalıdır. Kullanıcıların daha fazla purchase yapması bekleniyorsa metric purchase conversion olabilir. Sadece click metric seçmek business etkisini eksik temsil edebilir. Metric catalogdan standart tanım kullanılmalıdır. Test başladıktan sonra primary metric değiştirilmemelidir.

Neden Bu Etkiyi Bekliyoruz?

Gerekçe araştırma kanıtını içerir. Kullanıcıların fiyatı geç gördüğü usability testinde ortaya çıkmış olabilir. Funnel data belirli adımda kayıp gösterebilir. Support feedback ortak problemi işaret edebilir. Hipotez bu kanıtı test edilebilir ürün değişikliğine dönüştürür.

Hipotez Standardı

Standart hipotez formatı ekiplerin test fikirlerini karşılaştırmayı kolaylaştırır. “Eğer X yaparsak, Y kullanıcılarında Z metriği değişecektir, çünkü...” yapısı basit ve işlevseldir. Bu format değişiklik, population, outcome ve reasoning bileşenlerini tek cümlede toplar. Hipotezin falsifiable olması gerekir. Standardizasyon yaratıcılığı azaltmaz; aksine fikirlerin ölçülebilir hale gelmesini sağlar.

“Eğer X Yaparsak”

X test edilen değişikliği belirtir. Örneğin checkout formundaki zorunlu alanları azaltmak olabilir. Değişiklik ölçülebilir ve uygulanabilir olmalıdır. Treatment specification ile aynı anlamı taşımalıdır. Birden fazla X varsa test kapsamı büyür.

“Y Kullanıcılarında”

Y eligible populationı ifade eder. Yeni mobil kullanıcılar veya trial customers örnek olabilir. Kullanıcı grubu önceden tanımlanmalıdır. Çok dar segment sample size sorununa yol açabilir. Reach prioritization aşamasında değerlendirilir.

“Z Metriği Değişecektir”

Z primary outcome metricidir. Yönlü hipotez artış veya azalış beklentisini söyleyebilir. Metric merkezi catalogdan seçilmelidir. Proxy metric kullanılıyorsa business ilişkisi açıklanmalıdır. Karar standardı bu metric üzerinden verilir.

“Çünkü...”

Çünkü bölümü mekanizma ve kanıtı açıklar. User research veya analytics bulgusu burada yer alabilir. Gerekçe yoksa test rastgele fikir olmaya yaklaşır. Learning sonucunda bu mekanizmanın doğru olup olmadığı değerlendirilir. Kaybeden test bile reasoning hakkında bilgi sağlar.

Falsifiable Hypothesis

Falsifiable hipotez yanlışlanabilir bir iddiadır. “Kullanıcılar yeni deneyimi sevecek” ölçüm tanımı olmadan zayıftır. “Mobil yeni kullanıcıların signup conversionı artacaktır” daha nettir. Result null veya negatif olduğunda hipotez desteklenmemiş sayılabilir. Bu yaklaşım confirmation bias riskini azaltır.

Experiment Backlog Nasıl Oluşturulur?

Experiment backlog yalnız ekip üyelerinin aklına gelen fikirlerden oluşmamalıdır. Araştırma bulguları, kullanıcı feedbacki, funnel problemleri, analytics anomalileri ve ürün fikirleri ortak havuzda toplanabilir. Her madde doğrudan test değil önce problem ve hipotez olarak ifade edilmelidir. Daha sonra impact, confidence, effort, reach, risk ve learning value ile önceliklendirme yapılabilir. Bu yaklaşım CRO ekibinin test sayısını değil öğrenme değerini optimize etmesine yardımcı olur.

Araştırma Bulguları

Usability test, interview ve survey bulguları deney fırsatı üretebilir. Aynı problem birden fazla araştırmada görülüyorsa confidence artar. Kullanıcı davranışının nedeni analytics ile birleştirilebilir. Research insight doğrudan solutiona çevrilmemelidir. Önce problem statement oluşturulmalıdır.

Kullanıcı Feedback'i

Support ticket, review ve survey feedback değerli sinyal olabilir. Sık tekrar eden şikayetler funnel problemine işaret edebilir. Yüksek sesli az sayıda kullanıcı bütün populationı temsil etmeyebilir. Quantitative data ile doğrulama yapılmalıdır. Feedback hipotez kaynağı olarak kullanılmalıdır.

Funnel Problemleri

Funnel analysis yüksek drop-off noktalarını gösterir. Ancak drop-off her zaman problem anlamına gelmez. Kullanıcı niyeti ve trafik kalitesi dikkate alınmalıdır. Qualitative research neden kayıp olduğunu anlamaya yardımcı olur. Funnel ve research birlikte güçlü hipotez üretir.

Analytics Anomalileri

Belirli cihaz veya trafik kaynağında beklenmeyen conversion düşüşü gözlenebilir. Önce tracking problemi olmadığı doğrulanmalıdır. Gerçek kullanıcı problemi ise experiment opportunity olabilir. Anomali segment odaklı hipotez üretir. Post-hoc bulgu confirmatory test gerektirebilir.

Ürün Fikirleri

Product ve engineering ekipleri yeni feature fikirleri üretebilir. Her fikir kullanıcı problemine ve metric hedefe bağlanmalıdır. Büyük feature gradual rollout ve holdout gerektirebilir. Risk yüksekse experiment review board değerlendirebilir. Fikir backlogda evidence seviyesiyle saklanabilir.

Hipotezlere Dönüştürme

Problem çözüm fikriyle aynı şey değildir. Her problem için birkaç farklı treatment hipotezi üretilebilir. En yüksek evidence ve learning value taşıyan seçenek seçilir. Hipotez formatı population ve primary metric içermelidir. Backlog test sayısı yerine problem kalitesine göre yönetilmelidir.

CRO Testleri Nasıl Önceliklendirilir?

Test önceliklendirme yalnız tahmini conversion artışına göre yapılmamalıdır. Impact, confidence, effort, reach, risk ve learning value birlikte değerlendirilmelidir. Çok büyük potansiyel etkisi olan ama düşük confidence taşıyan fikir keşif testi olarak değerli olabilir. Küçük etki ve yüksek engineering eforlu test ise düşük öncelik alabilir. Puanlama modeli kararın kendisi değil ekip tartışmasını daha tutarlı hale getiren araçtır.

Impact

Impact test başarılı olursa oluşturacağı potansiyel business değerini ifade eder. Conversion, revenue veya retention etkisi düşünülebilir. Tarihsel benzer deneyler tahmini güçlendirebilir. Büyük yüzey her zaman büyük impact anlamına gelmez. Metric ve kullanıcı problemiyle bağ kurulmalıdır.

Confidence

Confidence hipotezi destekleyen kanıtın gücüdür. Analytics, research ve geçmiş test sonuçları confidence oluşturabilir. Yalnız kişisel görüş düşük confidence sayılmalıdır. Yüksek confidence sonucu garanti etmez. Önceliklendirme uncertaintyyi görünür hale getirir.

Effort

Effort development, design, QA ve analysis maliyetini içerir. Basit copy testi düşük, backend pricing experiment yüksek effort olabilir. Experimentation platform olgunlaştıkça time to experiment düşebilir. Effort yalnız coding saatinden ibaret değildir. Governance ve risk review da dahil edilmelidir.

Reach

Reach kaç kullanıcının treatmenttan etkilenebileceğini gösterir. Yüksek traffic homepage geniş reach sağlar. Dar enterprise segment düşük kullanıcı sayısına rağmen yüksek business value taşıyabilir. Reach ve value birlikte düşünülmelidir. Sample feasibility bu faktörden doğrudan etkilenir.

Risk

Risk finansal, teknik, brand veya privacy etkisini kapsar. Pricing ve payment testleri yüksek riskli olabilir. Risk arttıkça QA, guardrail ve review ihtiyacı büyür. Progressive rollout kullanılabilir. Düşük riskli UI testleri daha hızlı self-service modele uygun olabilir.

Learning Value

Bazı testler kazanmasa bile stratejik kullanıcı davranışı hakkında önemli bilgi üretir. Learning value bu faydayı hesaba katar. Büyük ürün yönünü doğrulayan deney yüksek öğrenme değerine sahip olabilir. Buton rengi testi ise düşük olabilir. Program yalnız win rate odaklı değil learning velocity odaklı olmalıdır.

A/B Test İçin Sample Size Nasıl Planlanır?

Sample size planı baseline conversion rate, Minimum Detectable Effect, statistical power, hata toleransı, trafik miktarı ve deney süresine bağlıdır. Test başladıktan sonra “birkaç gün daha bakalım” yaklaşımı güvenilir değildir. Önceden tahmini sample ve minimum duration belirlenmelidir. Haftanın günleri ve satın alma döngüsü de süre planına dahil edilmelidir. CRO A/B testlerinde istatistiksel anlamlılık ve örneklem büyüklüğü nasıl belirlenir sorusunda tek bir evrensel kullanıcı sayısı yoktur; gerekli sample metric ve beklenen etkiye göre hesaplanır.

Baseline Conversion Rate

Baseline control grubunun beklenen mevcut dönüşüm oranıdır. Geçmiş analytics verisinden tahmin edilebilir. Seasonality nedeniyle yakın tarihli dönem kullanılmalıdır. Çok değişken baseline sample planını belirsizleştirir. Pre-experiment calibration yapılabilir.

Minimum Detectable Effect

MDE testin tespit etmek için tasarlandığı en küçük iş anlamlı etkidir. Çok küçük MDE seçmek sample ihtiyacını büyütür. Gerçek business decision için anlamsız küçük farkları tespit etmeye çalışmak kaynak israfı olabilir. Product ve finance ekipleri MDE seçiminde katkı sağlayabilir. ROI eşiği iyi başlangıç noktasıdır.

Statistical Power

Power gerçek bir etki varken testin bunu tespit etme olasılığıdır. Düşük power false negative riskini artırır. Sample size büyüdükçe power artar. Yaygın hedefler kullanılabilir ancak her program kendi methodology standardını belirlemelidir. Power launch planının parçası olmalıdır.

Hata Toleransı

False positive ve false negative maliyetleri ürün kararına göre değişir. Yüksek riskli pricing deneyinde daha sıkı confidence gerekebilir. Küçük UI testinde farklı threshold kabul edilebilir. Statistical policy merkezi tanımlanmalıdır. Sonuca göre threshold değiştirilmemelidir.

Trafik Miktarı

Eligible traffic test süresini doğrudan etkiler. Toplam site trafiği yerine deneye gerçekten girebilecek population hesaplanmalıdır. Exposure rate assignmenttan daha düşük olabilir. Traffic split birden fazla varyant arasında bölünür. Eş zamanlı experiments availabilityyi etkileyebilir.

Deney Süresi

Sample hedefi bir günde dolsa bile day-of-week etkisi nedeniyle test en az tam iş döngüsünü kapsayabilir. Ürün davranışına göre bir veya birkaç hafta gerekebilir. Çok uzun test external changes riskini artırır. Minimum ve maximum duration planlanmalıdır. Sequential method kullanılıyorsa stopping rule buna göre tanımlanmalıdır.

Minimum Detectable Effect (MDE) Nedir?

MDE deneyin güvenilir biçimde tespit etmeyi amaçladığı en küçük farktır. Bu değer istatistiksel değil aynı zamanda iş kararıdır. Yüzde 0,1 gelir artışı teknik olarak ölçülebilir olsa bile uygulama maliyetinden düşükse önemli olmayabilir. Çok küçük MDE seçmek test süresini ve sample ihtiyacını büyütür. İyi CRO programı MDE'yi “ne kadar küçük fark bulabiliriz?” yerine “hangi fark kararımızı değiştirir?” sorusuyla belirler.

İş Açısından Anlamlı En Küçük Etki

MDE business threshold olarak düşünülmelidir. Yeni checkout geliştirmesi yüksek engineering maliyeti taşıyorsa çok küçük lift rollout için yeterli olmayabilir. Incremental profit tahmini kullanılabilir. Risk ve maintenance maliyeti hesaba katılmalıdır. Metric yüzde farkı karar değerine bağlanmalıdır.

Çok Küçük MDE'nin Örnekleme Etkisi

MDE küçüldükçe gerekli sample büyür. Düşük traffic sitelerde test aylar sürebilir. Bu sürede seasonality ve external changes sonucu etkileyebilir. Daha büyük ürün değişikliği veya farklı research yöntemi daha verimli olabilir. Statistical precision business feasibility ile dengelenmelidir.

Ürün Ekibiyle MDE Belirlemek

Data scientist MDE'yi tek başına belirlememelidir. Product owner hangi liftin rollout kararını haklı çıkaracağını bilir. Finance incremental revenue threshold sağlayabilir. Engineering effort de değerlendirilir. Ortak karar experiment brief içinde kaydedilir.

MDE ile ROI İlişkisi

MDE testin tespit etmeye çalıştığı minimum iş değerini temsil edebilir. Incremental revenue geliştirme ve platform maliyetinden düşükse testin ekonomik anlamı zayıflar. Lifetime value bazı ürünlerde değerlendirmeye eklenmelidir. Long-term guardrails ROI hesabını değiştirebilir. Experiment prioritization bu ilişkiyi kullanabilir.

Statistical Power Nedir?

Statistical power gerçekten MDE büyüklüğünde veya daha yüksek bir etki olduğunda deneyin bu farkı tespit edebilme olasılığıdır. Underpowered test anlamlı ürün etkisini gözden kaçırabilir. Bu durumda “fark yok” demek yerine testin yeterli bilgi üretmediğini söylemek daha doğrudur. Sample size, baseline ve variance powerı belirler. Olgun experimentation platformu test başlamadan power planını kullanıcıya göstermelidir.

Gerçek Etkiyi Tespit Etme Yeteneği

Power testin sensitivity seviyesini ifade eder. Daha yüksek power daha fazla sample gerektirir. İstenen power business riskine göre seçilebilir. Aynı standardın bütün organizasyonda kullanılması karar tutarlılığı sağlar. Methodology dokümantasyonu açık olmalıdır.

Underpowered Experiment

Underpowered experiment beklenen effecti güvenilir tespit edecek kadar veriye sahip değildir. Null result gerçek etkisizlik anlamına gelmeyebilir. Çok varyant veya düşük traffic yaygın nedenlerdir. Test öncesi feasibility assessment yapılmalıdır. Sonuç inconclusive olarak sınıflandırılabilir.

False Negative

False negative gerçekte etki varken testin bunu tespit edememesidir. Düşük power riskini yükseltir. Çok yüksek metric variance de etkileyebilir. Kaybedilen iyi feature fırsatı business maliyeti oluşturabilir. Sample plan false positive kadar false negative riskini de düşünmelidir.

Sample Size İlişkisi

Daha büyük sample genellikle powerı artırır. Ancak sonsuz sample pratik değildir. MDE, power ve traffic arasında denge kurulur. Variance reduction teknikleri bazı metriklerde sample ihtiyacını azaltabilir. Bu yöntemler önceden standardize edilmelidir.

Frequentist ve Bayesian A/B Testing

Frequentist ve Bayesian yaklaşımlar A/B test sonuçlarını farklı istatistiksel çerçevelerle değerlendirir. Frequentist yöntem confidence interval ve p-value gibi kavramları kullanabilir. Bayesian yaklaşım treatmentın control'dan daha iyi olma olasılığı veya expected loss gibi karar metricleri sunabilir. Hiçbir yaklaşım kötü tracking veya yanlış randomization problemini çözmez. Platform seçerken metodoloji şeffaflığı, kullanıcıya anlaşılır karar kuralları ve peeking davranışının nasıl yönetildiği mutlaka incelenmelidir.

Frequentist Yaklaşım

Frequentist test önceden belirlenmiş sample ve significance planına dayanabilir. Null hypothesis altında gözlenen verinin olasılığı değerlendirilir. P-value treatmentın daha iyi olma olasılığı değildir. Bu yanlış yorum ekiplerde sık görülür. Methodology eğitimi önemlidir.

Bayesian Yaklaşım

Bayesian analysis öncül dağılım ve gözlenen veriyi birleştirerek posterior dağılım üretir. “Treatmentın daha iyi olma olasılığı” gibi daha sezgisel sonuçlar sunabilir. Prior seçimi şeffaf olmalıdır. Expected loss rollout kararında kullanılabilir. Bayesian olmak plansız erken durdurmayı otomatik olarak güvenli yapmaz.

Sonuçların Yorumlanmasındaki Fark

Frequentist confidence interval ve Bayesian credible interval aynı anlama gelmez. Platform kullanıcıları terminolojiyi doğru anlamalıdır. Decision rule metodolojiye uygun tanımlanmalıdır. Aynı deney farklı yöntemlerle farklı sunum görebilir. Kurum bir standart seçip sürekli uygulamalıdır.

Platform Seçerken Metodoloji Şeffaflığı

Platform yalnız yeşil “winner” etiketi göstermemelidir. Sample requirement, statistical assumptions ve stopping rule belgelenmelidir. Multiple metrics düzeltmesi varsa açıklanmalıdır. Raw result ve confidence bilgisi erişilebilir olmalıdır. Black-box statistics kurumsal karar riskini artırır.

Testi Erken Durdurmak Neden Risklidir?

Deney ilk iki günde treatment lehine büyük fark gösterebilir ve sonraki günlerde bu fark ortadan kaybolabilir. Sürekli dashboarda bakıp “kazanan görünüyor” anında testi durdurmak false positive riskini artırabilir. Bu davranış peeking olarak bilinir. Sequential testing gibi yöntemler ara bakışları kontrollü hale getirebilir, ancak önceden tanımlanmış stopping rule gerektirir. Deney programında sabır yalnız operasyon tercihi değil istatistiksel kalite şartıdır.

Peeking

Peeking test sonucuna sürekli bakıp significance oluştuğunda durdurma davranışıdır. Klasik fixed-horizon analizde false positive oranını yükseltebilir. Ekiplerin dashboard erişimi karar kuralını değiştirmemelidir. Health metrics izlenebilir fakat outcome kararları planlanan zamanda yapılmalıdır. Sequential methodology kullanılıyorsa farklı kurallar geçerlidir.

Rastlantısal Dalgalanmalar

Küçük samplelarda conversion rate doğal olarak çok oynar. Treatment ilk gün yüzde 20 önde görünebilir. Trafik arttıkça fark daralabilir veya yön değiştirebilir. Bu davranış normaldir. Early result communication stakeholder beklentisini yanlış yönlendirebilir.

Sequential Testing

Sequential testing belirli ara analizleri istatistiksel olarak hesaba katar. Erken stop bazı koşullarda mümkün olabilir. Platform methodology bunu açıkça desteklemelidir. Kullanıcı kendi başına klasik p-value'a bakıp sequential davranmamalıdır. Decision boundaries önceden tanımlanmalıdır.

Önceden Tanımlanan Decision Rule

Decision rule testin ne zaman ve hangi koşulda biteceğini tanımlar. Sample, duration, statistical threshold ve guardrail şartları içerebilir. Test başladıktan sonra treatment lehine kural değiştirilmemelidir. Repository bu kuralı saklamalıdır. Audit ve reproducibility güçlenir.

“Kazanan Görünüyor” Yanılgısı

Dashboardda treatment yeşil görünmesi final karar değildir. Sample size, SRM ve minimum duration kontrol edilmelidir. Guardrails negatif olabilir. Business lift MDE altında kalabilir. Karar standardı görsel renkten daha önemlidir.

Sample Ratio Mismatch (SRM) Nedir?

Sample Ratio Mismatch beklenen varyant dağılımıyla gözlenen dağılım arasında normal rastlantıyla açıklanması zor fark oluşmasıdır. Yüzde 50 ve yüzde 50 planlanan testte sistematik yüzde 60 ve yüzde 40 dağılım görülebilir. Bu durum assignment, tracking, eligibility veya exposure problemi gösterebilir. SRM bulunan deneyde sonucu yorumlamak ciddi risk taşır. Experiment health dashboard her testte bu kontrolü otomatik çalıştırmalıdır.

Beklenen Trafik Dağılımı

Experiment config varyantların beklenen trafik oranını belirler. İki kollu testte 50/50 yaygındır. Riskli treatmentta 90/10 başlanabilir. Statistical SRM testi bu expected ratio üzerinden çalışır. Config değişiklikleri timeline içinde kaydedilmelidir.

Gerçek Trafik Dağılımı

Actual assignment veya exposure count varyant bazında ölçülür. Küçük farklar doğal random variationdır. Büyük sapma investigation gerektirir. Segment bazında SRM kontrolü sorunun belirli platforma özgü olduğunu gösterebilir. Raw exposure data erişilebilir olmalıdır.

Assignment Problemleri

Hash bugı, targeting condition veya cache sorunu dağılımı bozabilir. Belirli user IDs treatmenta daha fazla düşebilir. Cross-device logic problem yaratabilir. Assignment service logları incelenmelidir. A/A testleri bu sorunları platform launch öncesi yakalayabilir.

Tracking Problemleri

Assignment doğru olsa bile treatment exposure eventi kaybolabilir. Client script yalnız bir varyantta hata veriyor olabilir. Ad blocker veya browser behavior farklı etkileyebilir. Assignment ratio ile exposure ratio ayrı karşılaştırılmalıdır. Sorunun randomization mı instrumentation mı olduğu ayrıştırılır.

SRM Varken Sonuçlara Güvenilir mi?

Genel olarak SRM çözülmeden outcome sonucuna güvenilmemelidir. Sapmanın bilinen ve zararsız teknik açıklaması varsa metodoloji ekibi ayrıca değerlendirebilir. Ancak “sonuç yine de iyi görünüyor” kabul edilebilir gerekçe değildir. Root cause bulunmalıdır. Gerekirse deney invalid ilan edilip yeniden çalıştırılır.

Experiment Sanity Checks

Sanity checks deney outcome analizinden önce altyapının sağlıklı çalıştığını doğrular. Assignment ratio, exposure count, event volume, conversion baseline, bot traffic, internal traffic ve A/A karşılaştırmaları bu kapsamdadır. Bir test istatistiksel olarak anlamlı görünebilir fakat event tracking bozuksa karar yanlış olur. Bu kontroller mümkün olduğunca otomatik çalışmalıdır. Experiment health ile experiment result aynı dashboardda fakat ayrı statüler olarak gösterilebilir.

Assignment Ratio

Expected ve actual assignment dağılımı karşılaştırılır. SRM test edilir. Experiment başında özellikle yakından izlenir. Traffic ramp sırasında farklı expected ratios kullanılabilir. Config timeline sonuç yorumunda saklanır.

Exposure Count

Assignment ile exposure sayıları arasındaki fark incelenir. Çok düşük exposure eligibility veya trigger problemi gösterebilir. Treatment ve control arasında exposure rate sistematik farklı olmamalıdır. Component render logic kontrol edilir. Exposure deduplication kuralı uygulanır.

Event Volume

Primary conversion event günlük hacmi baseline ile karşılaştırılır. Ani düşüş tracking deployment sorunu olabilir. Variant bazında event ratio kontrol edilir. Data pipeline lag dashboarda eklenmelidir. Missing data varken outcome sonucu hesaplanmamalıdır.

Conversion Baseline

Control conversion geçmiş baseline ile yaklaşık uyumlu olmalıdır. Büyük fark seasonality veya tracking değişimini gösterebilir. Yeni traffic campaign population kalitesini değiştirebilir. Baseline birebir aynı olmak zorunda değildir. Beklenmeyen sapma investigation gerektirir.

Bot Traffic

Botlar assignment ve pageview hacmini yapay biçimde artırabilir. Human experiment population mümkün olduğunca botlardan temizlenmelidir. Server-side API experimentlerinde automation traffic ayrıca filtrelenebilir. Bot identification analytics standardının parçası olmalıdır. Variantlar arasında farklı bot dağılımı ciddi sorun yaratabilir.

Internal Traffic

Employee ve QA kullanıcıları test sonucunu bozabilir. Internal identity veya IP segmenti dışarıda tutulabilir. Ancak remote çalışan ekiplerde IP bazlı filtre yetersiz olabilir. Test account flag kullanılabilir. QA exposureları production analyticsden ayrı tutulmalıdır.

A/A Comparison

Platform health geçmiş A/A sonuçlarıyla izlenebilir. Sürekli systematic lift çıkması measurement bias gösterebilir. SRM ve false positive oranı takip edilebilir. Yeni SDK veya pipeline release sonrasında A/A tekrar yapılabilir. Platform değişikliklerinin etkisi kontrollü doğrulanır.

Deney Sonuçlarını Bozan Etkiler

Deney randomize olsa bile seasonality, haftanın günü, marketing campaign, novelty, primacy, tracking changes ve dış olaylar sonuç yorumunu zorlaştırabilir. Randomization aynı dönemdeki birçok dış etkiyi iki gruba dengeli dağıtır, fakat test süresi veya exposure dinamiği yine önemlidir. Büyük marketing campaign population compositionı değiştirebilir. Tracking deployment ise grupları asimetrik etkileyebilir. Experiment timeline üzerinde önemli dış olayların işaretlenmesi yorum kalitesini artırır.

Seasonality

Bayram, kampanya dönemi veya yıl sonu davranışı baselineı değiştirebilir. Control ve treatment aynı anda çalıştığı için birçok seasonal etki dengelenir. Ancak test sonucu başka döneme genellenirken dikkat gerekir. Long-term rollout farklı performans gösterebilir. Repository experiment context saklamalıdır.

Day-of-Week

Hafta içi ve hafta sonu kullanıcı davranışı değişebilir. Test bir salı başlayıp perşembe durursa tam döngüyü kapsamaz. Minimum duration en az bir veya birkaç tam hafta olabilir. Traffic volume ürün tipine göre değişir. Sample dolsa bile zaman dengesine bakılmalıdır.

Marketing Campaign

Büyük kampanya yeni kullanıcı oranını artırabilir. Randomization gruplara kampanya trafiğini dağıtır, ancak treatment effect segment bazında farklı olabilir. Campaign launch timeline kaydedilmelidir. Pre-specified traffic source analysis yapılabilir. Population shift rollout tahminini etkileyebilir.

Novelty Effect

Yeni deneyim kullanıcıların ilk anda daha fazla ilgisini çekebilir. Bu etki zamanla azalabilir. Uzun testlerde treatment lift trendi gözlenebilir. Returning users segmenti farklı tepki verebilir. Permanent rollout öncesi uzun vadeli metric izlenmelidir.

Primacy Effect

Kullanıcı alışık olduğu control deneyimine bağlı olabilir. Yeni treatment ilk günlerde kötü performans gösterip zamanla iyileşebilir. Özellikle workflow ve navigation değişikliklerinde görülebilir. Cohort by exposure date analysis yardımcı olabilir. Test süresi yeterince uzun olmalıdır.

Tracking Changes

Test sırasında analytics event kodunun değiştirilmesi sonucu invalid hale getirebilir. Variantlardan biri yeni tracking code alıyorsa bias oluşur. Data instrumentation freeze uygulanabilir. Zorunlu değişiklik experiment timelinea eklenmelidir. Gerekirse test yeniden başlatılmalıdır.

External Events

Haber, ekonomik değişim veya servis kesintisi kullanıcı davranışını etkileyebilir. Randomization birçok durumda etkileri dengeler. Ancak belirli segment farklı etkilenebilir. Incident timeline outcome analiziyle birlikte değerlendirilmelidir. Sonuç başka döneme uygulanırken dikkat edilmelidir.

Experiment Collision Nedir?

Experiment collision aynı kullanıcının aynı ürün alanında birden fazla deneyden etkilenmesi ve bu deneylerin birbirinin sonucunu değiştirmesi durumudur. Her eş zamanlı deney collision değildir. Bir header rengi testi ile backend search ranking testi çoğu zaman bağımsız çalışabilir. Ancak checkout layout ve checkout pricing testleri interaction effect oluşturabilir. Experiment layers ve namespace sistemi yüksek riskli çakışmaları yönetmeye yardımcı olur.

Aynı Kullanıcının Birden Fazla Teste Girmesi

Olgun programlarda kullanıcı aynı anda birçok deneye girebilir. Bunu tamamen engellemek experiment velocityyi düşürür. Önemli olan gerçekten etkileşen deneyleri belirlemektir. Product surface ve metric overlap incelenebilir. Orthogonal experiments birlikte çalışabilir.

Interaction Effect

Bir treatmentın etkisi diğer experiment variantına bağlı olarak değişebilir. Bu durumda tek deney sonucu aggregate olarak farklı görünebilir. Factorial analysis yüksek traffic gerektirebilir. Kritik collision riski varsa mutual exclusion daha basittir. Interaction monitoring exploratory sinyal sağlayabilir.

Sonuçların Kirlenmesi

İki deney aynı CTA veya funnel adımını değiştiriyorsa hangi treatmentın etkili olduğu belirsizleşebilir. Primary metric aynı olabilir. Exposure combinations ayrıca analiz edilebilir fakat sample parçalanır. Deney planında collision review yapılmalıdır. High-risk surfaces experiment layer ile korunabilir.

Ne Zaman Problem Olur?

Aynı kullanıcıya iki test girmesi tek başına problem değildir. Değişikliklerin aynı mekanizma veya metric üzerinde etkileşmesi önemlidir. Pricing ve promotion deneyleri güçlü interaction riski taşır. Bağımsız feature adoption deneyleri daha az riskli olabilir. Governance rule yüzeye göre tanımlanmalıdır.

Eş Zamanlı A/B Testler Nasıl Yönetilir?

Büyük experimentation programında testleri tamamen sıraya koymak öğrenme hızını ciddi biçimde düşürür. Experiment layers, namespace, mutually exclusive groups, traffic isolation ve orthogonal experiment mantığı eş zamanlı testleri yönetmek için kullanılabilir. Kullanıcı aynı anda farklı ürün yüzeylerindeki bağımsız deneylere girebilir. Etkileşim riski yüksek deneyler aynı layer içinde birbirini dışlayabilir. Bu mimari experimentation velocity ile sonuç güvenilirliği arasında denge sağlar.

Experiment Layers

Layer belirli ürün yüzeyinde aynı anda tek deney assignmentı yapılmasını sağlayabilir. Checkout layer ve pricing layer ayrı olabilir. Aynı layer içindeki deneyler traffic bucket paylaşır. Layer design çok katı olursa experimentation kapasitesi düşer. Gerçek collision riskine göre tasarlanmalıdır.

Namespace

Namespace kullanıcı hash alanını deneyler arasında organize eder. Traffic segmentleri belirli deneylere ayrılabilir. Stable hashing aynı kullanıcı assignmentını korur. Namespace resize dikkatli yapılmalıdır. Yanlış değişiklik active test populationını kaydırabilir.

Mutually Exclusive Groups

Mutual exclusion kullanıcıyı iki belirli testten yalnız birine dahil eder. Aynı product surface veya pricing deneyleri için uygundur. Sample her test için azalır. Bu nedenle yalnız gerçek interaction riskinde kullanılmalıdır. Config management merkezi yapılmalıdır.

Traffic Isolation

Traffic isolation belirli kullanıcı yüzdesini deney grubu için ayırabilir. Holdout veya riskli rolloutta kullanılabilir. High-value customer segmentleri deney dışında bırakılabilir. Ancak external validity azalabilir. Eligibility decision business policy ile uyumlu olmalıdır.

Orthogonal Experiments

Orthogonal experiments bağımsız hash salt kullanarak aynı kullanıcıları farklı deneylerde randomize eder. Büyük platformlarda yüksek concurrency sağlar. Interaction effects ortalamada dengelenebilir. Yine de aynı yüzeyde büyük değişiklikler için dikkat gerekir. Platform experiment metadata ile overlap analiz edebilir.

Interaction Monitoring

Önemli deney çiftleri için exposure combination analizi yapılabilir. Beklenmeyen metric farkı interaction sinyali olabilir. Çok sayıda kombinasyon false discovery riskini artırır. Exploratory kullanım daha uygundur. Doğrulama için yeni kontrollü test gerekebilir.

Holdout Group Nedir?

Holdout group belirli özellik veya deney programından bilinçli olarak etkilenmeyen kullanıcı grubudur. Permanent veya global holdout uzun vadeli incrementality ölçümünde kullanılabilir. Tek tek testler kazansa bile bütün experimentation programının toplam etkisini ölçmek farklı sorudur. Holdout grubu sürekli control baseline sağlar. Ancak business opportunity cost nedeniyle oranı dikkatli seçilmelidir.

Permanent Holdout

Permanent holdout uzun süre yeni özelliklerin bir bölümünü görmeyen kullanıcı grubudur. Long-term cumulative impact ölçülebilir. Kullanıcı deneyimi zaman içinde control'dan çok geri kalabilir. Etik ve ürün riski değerlendirilmelidir. Holdout oranı düşük tutulabilir.

Global Holdout

Global holdout birçok experiment veya rollouttan hariç tutulan populationdır. Program-level incrementality ölçmeye yardımcı olur. Randomization stabil tutulmalıdır. Major mandatory features holdout dışında uygulanabilir. Governance kapsamı açık olmalıdır.

Uzun Vadeli Incrementality

Kısa testler tek feature etkisini ölçer. Bir yıl boyunca yüzlerce kazanımın gerçekten toplam revenue veya retention artışı üretip üretmediği global holdout ile görülebilir. Etkiler additive olmayabilir. Bazı featurelar birbirini güçlendirebilir veya zayıflatabilir. Program ROI daha güvenilir hesaplanır.

Experiment Programının Toplam Etkisini Ölçmek

Win rate toplam business impacti göstermez. Küçük kazanan testler büyük kaybeden rolloutlardan daha az değer üretebilir. Global holdout gerçek incremental value ölçümüne yaklaşır. Finance ve product analytics ile birlikte analiz yapılır. CRO programının yönetim seviyesinde değeri daha net anlatılır.

Segment Analizi Nasıl Yapılmalı?

Segment analysis treatment etkisinin farklı kullanıcı gruplarında değişip değişmediğini anlamaya yardımcı olur. New vs returning, mobile vs desktop, traffic source, geography ve customer type sık kullanılan segmentlerdir. Kritik segmentler test başlamadan önce tanımlanmalıdır. Çok sayıda post-hoc segment aramak false discovery riskini büyütür. Segment sonucu ana test kararından çok yeni hipotez üretme aracı olarak kullanılabilir.

New vs Returning

Yeni kullanıcı treatmenta farklı tepki verebilir. Returning user mevcut deneyime alışmış olabilir. Novelty ve primacy effects bu segmentlerde görülebilir. Sample yeterli olmalıdır. Segment planı experiment brief içinde yer almalıdır.

Mobile vs Desktop

Mobil ve masaüstü kullanıcı davranışı farklıdır. Client-side test performance etkisi mobilde daha yüksek olabilir. Layout treatment yalnız mobile breakpoints üzerinde çalışabilir. Device segment primary interaction için anlamlı olabilir. Cross-device identity sınırlılığı açıklanmalıdır.

Traffic Source

Organic, paid veya direct kullanıcıların intent seviyesi farklı olabilir. Treatment effect kaynak bazında değişebilir. Marketing campaign deney sırasında traffic mixi değiştirebilir. Pre-specified segment analysis faydalıdır. Çok küçük kanallar ayrı yorumlanmamalıdır.

Geography

Ülke veya bölge kullanıcı beklentileri ve ödeme seçeneklerini etkileyebilir. Pricing testleri geography bakımından özellikle hassastır. Legal ve currency farklılıkları dikkate alınmalıdır. Global aggregate sonuç her pazarda geçerli olmayabilir. Country-level rollout gerektiğinde confirmatory test yapılabilir.

Customer Type

Free, paid, enterprise veya high-value customers farklı davranabilir. Randomization unit account seviyesinde olabilir. Treatment bir segmentte güçlü diğerinde negatif olabilir. Segment rollouts policy ile yönetilebilir. Business impact sample sayısından farklı ağırlık taşıyabilir.

Segmentleri Önceden Belirlemek

Pre-registration benzeri yaklaşım confirmatory segmentleri önceden yazar. Analiz özgürlüğünü sınırlayarak false discovery riskini azaltır. Yeni exploratory segmentler yine incelenebilir. Ancak sonuç “keşif” olarak etiketlenmelidir. Follow-up experiment ile doğrulama yapılır.

Post-Hoc Segmentasyonun Riskleri

Test bittikten sonra onlarca segment içinde yalnız pozitif olanı aramak data dredging problemine dönüşebilir. Yeterince çok karşılaştırma yapıldığında rastlantıyla güçlü görünen farklar bulunabilir. Küçük samplelı segmentlerde variance yüksektir. Bu nedenle exploratory ve confirmatory analysis birbirinden açıkça ayrılmalıdır. Post-hoc bulgu yeni hipotez olarak değerli olabilir fakat doğrudan rollout kanıtı olarak kullanılmamalıdır.

Data Dredging

Data dredging sonuç gördükten sonra çok sayıda breakdown deneyerek hikaye bulma davranışıdır. Analysis flexibility false positive oranını yükseltir. Dashboard sınırsız segment sunarken metodoloji uyarısı göstermelidir. Predefined analysis ayrı sekmede olabilir. Exploratory bulgular repositoryde işaretlenmelidir.

False Discovery

Çok fazla test yapıldığında bazı farklar tesadüfen anlamlı görünür. Multiple comparison correction bazı durumlarda kullanılabilir. Daha basit çözüm confirmatory metric ve segments listesini sınırlamaktır. Exploratory sonucu yeni test doğrulamalıdır. “Mobil Safari'de kazandı” gibi küçük bulgular dikkatle yorumlanmalıdır.

Küçük Örneklem

Segment sampleı toplam deneyden çok daha küçüktür. Confidence interval genişler. Büyük lift görülebilir fakat belirsizlik yüksek olabilir. Minimum segment sample standardı belirlenebilir. Sonuç decision-making yerine hypothesis generation için kullanılabilir.

Exploratory vs Confirmatory Analysis Ayrımı

Confirmatory analysis testten önce tanımlanan soruları cevaplar. Exploratory analysis yeni pattern keşfeder. İkisi de değerlidir fakat aynı kanıt gücünde değildir. Dashboard ve report etiketleri bu farkı göstermelidir. Organizasyon araştırma kültürü daha sağlıklı hale gelir.

Düşük Trafikli Sitelerde CRO Nasıl Yapılır?

Düşük trafik A/B testingi imkansız yapmaz, ancak küçük etkileri güvenilir tespit etmeyi zorlaştırır. Aylar süren ve MDE'si anlamsız derecede küçük testler yerine daha güçlü hipotezlere odaklanmak gerekir. Kullanılabilirlik testleri, user interviews, session replay ve funnel analysis deney öncesi evidence kalitesini artırabilir. Büyük tasarım veya teklif değişiklikleri daha yüksek effect üretme potansiyeline sahiptir. Bazı durumlarda A/B test yerine doğrudan araştırma ve before-after monitoring daha ekonomik olabilir.

A/B Test Feasibility

Eligible traffic ve baseline conversion ile sample calculation yapılmalıdır. Testin tahmini süresi üç ay çıkıyorsa feasibility sorgulanmalıdır. Business environment bu sürede değişebilir. Daha büyük MDE veya daha geniş population düşünülebilir. Test etmemek de geçerli karar olabilir.

Büyük Etkili Değişikliklere Odaklanmak

Düşük trafficte buton rengi gibi küçük effectli testler verimsiz olabilir. Offer, pricing veya form friction gibi temel problemlere odaklanmak daha anlamlıdır. Research evidence confidence artırır. Riskli büyük değişiklik QA gerektirir. Learning value prioritizationda önemli hale gelir.

Kullanılabilirlik Testleri

Beş veya birkaç kullanıcıyla yapılan usability session istatistiksel A/B test değildir. Ancak belirgin usability problemlerini ortaya çıkarabilir. Kullanıcı neden formu tamamlamıyor anlaşılabilir. Bu insight daha güçlü treatment tasarımına dönüşür. A/B test ihtiyacını azaltmaz fakat hipotez kalitesini artırır.

User Interviews

Interviews kullanıcı motivasyon ve engellerini anlamaya yardımcı olur. Quantitative effect ölçmez. Customer segments arasında ortak temalar bulunabilir. Product positioning ve pricing hipotezleri üretilebilir. Interview bulgusu analytics ile birlikte değerlendirilmelidir.

Session Replay

Session replay kullanıcıların gerçek sayfa davranışını gözlemlemeyi sağlar. Rage click veya form confusion görülebilir. Privacy masking mutlaka uygulanmalıdır. Birkaç dikkat çekici session bütün kullanıcıları temsil etmeyebilir. Patternler funnel data ile doğrulanmalıdır.

Funnel Analysis

Funnel analysis en yüksek kayıp noktasını gösterir. Düşük trafik sitelerde bile uzun dönem veri kullanılabilir. Segmentler aşırı bölünmemelidir. Drop-off nedeni qualitative research ile araştırılmalıdır. Deney backlog problemi çözmeye odaklanmalıdır.

Daha Az Ama Daha Güçlü Hipotez

Düşük trafik programında experiment velocity doğal olarak düşüktür. Bu durumda her test daha yüksek evidence ve business impact taşımalıdır. Backlog sıkı önceliklendirilmelidir. Büyük sampleı küçük fikirlere harcamamak gerekir. Program öğrenme başına trafik maliyetini optimize eder.

Her Değişiklik A/B Test Edilmeli mi?

Her ürün değişikliğini A/B test etmek gerekli veya ekonomik değildir. Kritik bug fix, yasal gereklilik ve accessibility düzeltmeleri çoğu zaman doğrudan uygulanmalıdır. Çok düşük traffic veya çok küçük iş etkisi bulunan değişikliklerde test maliyeti faydayı aşabilir. Experimentation kültürü “her şeyi test et” değil “belirsiz ve önemli kararları uygun yöntemle doğrula” anlayışıdır. Bu ayrım ekiplerin test altyapısını gereksiz bürokrasiye dönüştürmesini önler.

Kritik Bug Fix

Checkout çalışmıyorsa control gruba bozuk deneyim göstermeye devam etmek doğru değildir. Bug doğrudan düzeltilmelidir. Fix sonrası monitoring yapılabilir. Regression guardrails kullanılmalıdır. A/B test kalite doğrulama aracının yerine geçmez.

Yasal Gereklilik

Legal compliance değişiklikleri çoğu durumda zorunludur. Kullanıcıların bir bölümüne mevzuata aykırı deneyim gösterilemez. UX implementation seçenekleri arasında deney yapılabilir. Ancak compliance baseline korunmalıdır. Legal review launch sürecine dahil edilmelidir.

Accessibility Fix

Erişilebilirlik sorununu yalnız conversion sonucu pozitif çıkarsa düzeltmek etik değildir. Standarda uygun fix doğrudan uygulanabilir. Sonrasında usability metricleri izlenebilir. Alternatif accessible tasarımlar kendi aralarında test edilebilir. Minimum accessibility kalite seviyesi guardraildir.

Düşük Trafik

Sample size gerçekçi sürede dolmayacaksa A/B test uygun değildir. Qualitative research veya staged rollout kullanılabilir. Daha büyük treatment tasarlanabilir. Metric daha sık gerçekleşen proxy ile değiştirilebilir, fakat business ilişkisi doğrulanmalıdır. Test etmenin kendisi amaç değildir.

Çok Küçük İş Etkisi

Beklenen lift geliştirme ve analiz maliyetinden düşük olabilir. Bu durumda test yapmak ROI açısından anlamsızdır. Basit low-risk improvement doğrudan uygulanıp monitoring yapılabilir. MDE iş eşiği bu kararı kolaylaştırır. CRO programı kaynakları yüksek değerli problemlere ayırmalıdır.

Test Etmenin Maliyetinin Değerden Büyük Olması

Experiment instrumentation, QA ve sample süresi maliyetlidir. Büyük engineering dependency küçük UI değişikliğini test etmeyi anlamsız kılabilir. Cost-benefit prioritization yapılmalıdır. Platform self-service hale geldikçe marginal cost azalır. Yine de her fikri test etme zorunluluğu yoktur.

Multi-Armed Bandit Nedir?

Multi-armed bandit trafik dağılımını gözlenen performansa göre dinamik olarak değiştiren optimizasyon yaklaşımıdır. Klasik A/B test genellikle sabit randomization ile treatment effect öğrenmeye odaklanır. Bandit ise exploration ve exploitation arasında denge kurarak daha iyi görünen varyanta daha fazla trafik gönderebilir. Bu yöntem kısa ömürlü kampanya veya sürekli içerik optimizasyonunda yararlı olabilir. Ancak öğrenme ile gelir optimizasyonu aynı amaç değildir ve nedensel etki yorumunda farklı metodoloji gerekir.

Trafiği Dinamik Dağıtmak

Bandit algorithm performans sinyali aldıkça traffic ratioyu değiştirir. Kötü varyanta daha az kullanıcı gönderebilir. Regret azaltma amacı vardır. Sample klasik sabit randomization gibi dağılmaz. Analysis method buna uygun olmalıdır.

Exploration vs Exploitation

Exploration farklı varyantlar hakkında yeni bilgi toplar. Exploitation mevcut bilgiye göre en iyi görünen varyanta daha fazla trafik verir. Çok fazla exploitation yanlış erken sonuca kilitlenebilir. Çok fazla exploration revenue fırsatını azaltabilir. Algorithm objective açık olmalıdır.

Klasik A/B Testten Farkı

Klasik test kontrollü effect estimate için daha sade veri üretir. Bandit allocation zaman içinde değişir. Basit conversion rate karşılaştırması bias oluşturabilir. Amaç best arm delivery olabilir. Product decision ihtiyacına göre yöntem seçilmelidir.

Ne Zaman Kullanılır?

Kısa ömürlü kampanya creatives bandit için uygun olabilir. Sürekli recommendation slotları da değerlendirilebilir. Büyük kalıcı ürün kararlarında net causal learning daha önemli olabilir. Governance ve metric stability gerekir. Her A/B problemi bandit ile çözülmemelidir.

Öğrenme ile Gelir Optimizasyonu Arasındaki Fark

Deney bazen hangi treatmentın neden daha iyi olduğunu öğrenmek için yapılır. Bandit ise çalışma süresince daha iyi varyanta trafik yönlendirerek outcome optimize etmeyi hedefleyebilir. Bu iki amaç farklıdır. Experiment repository method type saklamalıdır. Paydaşlara sonuç türü açıkça anlatılmalıdır.

Personalization ile Experimentation Arasındaki Fark

Experimentation genel veya segment bazlı treatment etkisini ölçmeye çalışır. Personalization ise farklı kullanıcı özelliklerine göre farklı deneyim sunmayı hedefler. Bir personalization algoritması daha fazla conversion üretiyor gibi görünebilir, ancak gerçek incrementality kontrollü deneyle doğrulanmalıdır. Model prediction ile causal effect aynı şey değildir. Bu nedenle personalization platformları da holdout veya randomized experiment desteğine ihtiyaç duyar.

Genel Kazanan Varyant

Standart A/B test bütün eligible population için average treatment effect ölçebilir. Control veya treatment genel kazanan olabilir. Segment heterogeneity ayrıca incelenebilir. Average result her kullanıcı için aynı effect anlamına gelmez. Rollout kararı ürün stratejisine göre verilir.

Segment Bazlı Deneyim

Belirli customer segment farklı treatmenttan daha fazla fayda görebilir. Segment önceden tanımlıysa targeted experiment yapılabilir. Sample size her segment için yeterli olmalıdır. Post-hoc segment sonucu doğrudan personalization rule olmamalıdır. Confirmatory test tercih edilir.

Kişiselleştirme Algoritması

Algorithm user features üzerinden content veya offer seçebilir. Offline prediction accuracy business uplift garantisi değildir. Feedback loop ve selection bias oluşabilir. Randomized holdout gerçek incrementality ölçer. Fairness ve privacy ayrıca değerlendirilmelidir.

Personalization'ın Etkisini Deneyle Doğrulamak

Personalized engine treatment, standard experience control olabilir. Revenue, engagement veya retention karşılaştırılır. Algorithm latency guardrail olabilir. New users için cold-start davranışı ayrıca incelenebilir. Rollout sonrası global holdout uzun vadeli etkiyi ölçebilir.

CRO Experiment QA Süreci

Experiment QA yalnız treatmentın görsel olarak doğru görünmesini kontrol etmek değildir. Assignment, variant, event, cross-browser, mobile, performance ve analytics kontrolleri birlikte yapılmalıdır. Kullanıcı doğru varyanta düşüyor fakat exposure eventi yanlış gönderiliyorsa test yine başarısızdır. Production launch öncesi forced variant ve debug mode kullanılabilir. QA checklist deney repository içinde tamamlandı olarak işaretlenmeden launch yapılmamalıdır.

Assignment QA

Test kullanıcıları control ve treatmenta zorla atanabilir. Sticky behavior farklı sessionlarda doğrulanır. Eligibility conditions sınır değerlerde test edilir. Anonymous ve logged-in identity senaryoları kontrol edilir. Traffic split config review yapılır.

Variant QA

Control ve treatment design specification ile karşılaştırılır. Functional behavior test edilir. Hidden veya unintended element farkı olmamalıdır. Localization ve responsive layout kontrol edilir. Treatment yalnız planlanan değişikliği içermelidir.

Event QA

Assignment ve exposure event payloadları incelenir. Experiment ve variant IDs doğrulanır. Conversion event yalnız başarılı actionda oluşmalıdır. Duplicate events kontrol edilir. Analytics tool ve warehouse ingestion doğrulanır.

Cross-Browser QA

Modern browserlar ve kritik traffic payına sahip sürümler test edilir. Client-side injection browser davranışına göre farklı çalışabilir. CSP ve privacy restrictions kontrol edilir. Legacy support product policyye göre belirlenir. Tracking consistency browser bazında izlenir.

Mobile QA

Mobile viewport ve gerçek cihazlarda treatment denenmelidir. Touch target ve keyboard davranışı kontrol edilir. Network latency client experimenti etkileyebilir. Core Web Vitals ölçümü yapılır. App experimentlerinde version compatibility ayrıca test edilir.

Performance QA

Control ve treatment page performance karşılaştırılır. JavaScript payload ve SDK latency ölçülür. LCP, INP ve CLS guardrail olabilir. Büyük fark outcome sonucunu kirletebilir. Performance budget launch kriterine eklenebilir.

Analytics QA

Analytics dashboard ve raw event data karşılaştırılır. Conversion sayıları test transaction ile doğrulanır. Timestamp ve identity doğru mu kontrol edilir. Staging eventleri production datasetine karışmamalıdır. Data source ownership net olmalıdır.

A/B Test Launch Checklist

Launch checklist deneyin yalnız teknik olarak değil metodolojik olarak da hazır olduğunu doğrular. Hipotez, primary metric, guardrails, sample size, assignment, exposure, eventler, variant QA ve kill switch kontrol edilmelidir. Bu liste kurumsal ekiplerde release riskini ciddi biçimde azaltır. High-risk experimentlerde data reviewer ve engineering owner onayı gerekebilir. Checklist tamamlanmadan “trafik az, hemen başlatalım” yaklaşımı uzun vadede daha fazla zaman kaybettirir.

Hipotez Onaylı mı?

Problem, treatment, population ve expected outcome yazılı olmalıdır. Evidence kaynağı belirtilmelidir. Hipotez falsifiable olmalıdır. Product ve CRO owner aynı soruyu test ettiğini anlamalıdır. Sonradan hipotez yeniden yazılmamalıdır.

Primary Metric Tanımlı mı?

Metric catalog key belirtilmelidir. Numerator ve denominator açık olmalıdır. Data source seçilmelidir. MDE metric üzerinden hesaplanır. Outcome dashboard aynı tanımı kullanmalıdır.

Guardrail'ler Var mı?

Testin risk alanına göre error, performance veya business guardrails seçilir. Thresholdlar launch öncesi belirlenir. Violation durumunda stop rule tanımlanabilir. Owner alarm almalıdır. Guardrail olmayan yüksek riskli test açılmamalıdır.

Sample Size Planlandı mı?

Baseline, MDE ve power ile sample hesaplanmalıdır. Eligible traffic kullanılır. Minimum duration belirlenir. Testin feasibility durumu onaylanır. Multi-variant dağılım hesaba katılır.

Assignment Doğru mu?

Randomization unit ve traffic split kontrol edilir. Sticky behavior test edilir. Eligibility doğru mu incelenir. Namespace collision kontrolü yapılır. A/A health geçmişi gözden geçirilebilir.

Exposure Çalışıyor mu?

Exposure doğru kullanıcı anında oluşmalıdır. Assignmentla karıştırılmamalıdır. Duplicate event politikası uygulanmalıdır. Control ve treatment exposure rate karşılaştırılır. Production debug ile sample event doğrulanır.

Event'ler Doğru mu?

Primary conversion event gerçek başarıyı temsil etmelidir. Event name ve properties standarda uymalıdır. Duplicate ve missing test edilir. Warehouse ingestion kontrol edilir. Source of truth kararı kaydedilir.

Varyant QA Tamam mı?

Design, functional ve responsive QA tamamlanmalıdır. Cross-browser kontrol yapılır. Performance measurement bulunur. Accessibility test edilir. Approval kaydı repositoryye eklenir.

Kill Switch Hazır mı?

Beklenmeyen hata durumunda treatment hızlı kapatılabilmelidir. Default variant güvenli çalışmalıdır. Flag owner ve on-call iletişimi belli olmalıdır. Rollback procedure test edilmiş olmalıdır. High-risk deneylerde bu şarttır.

A/B Testlerde Performans Yönetimi

Experimentation scriptleri ve SDK'lar doğrudan kullanıcı deneyimini etkileyebilir. Page load, Core Web Vitals, JavaScript payload, SDK latency ve layout shift varyant bazında takip edilmelidir. Client-side treatment conversionı artırırken sayfayı yavaşlatıyorsa gerçek rollout etkisi uzun vadede farklı olabilir. Performance guardrail her testte gerekli olmayabilir, ancak kritik web deneylerinde standart hale getirilebilir. CRO ile web performance ekiplerinin ortak metric dili bu noktada önemlidir.

Page Load

Treatment ek kaynak indiriyorsa page load artabilir. Network waterfall QA sırasında karşılaştırılır. Experiment config çağrısı critical path üzerinde olmamalıdır. Cache stratejisi uygulanabilir. Long page load kullanıcı davranışını outcome metric üzerinden de etkileyebilir.

Core Web Vitals

LCP, INP ve CLS control ile treatment arasında karşılaştırılabilir. Özellikle client injection CLS riski taşır. Büyük JavaScript INP'yi etkileyebilir. Performance data exposure context ile segmentlenmelidir. Negatif guardrail rollout kararını etkileyebilir.

JavaScript Payload

Experiment SDK ve treatment bundle boyutu ölçülmelidir. Dynamic import düşük öncelikli treatment kodu için kullanılabilir. Her active test bundle'a yeni code ekleyebilir. Cleanup yapılmazsa experimentation technical debt yaratır. Bundle budget CI içinde takip edilebilir.

SDK Latency

Remote feature evaluation request latency oluşturabilir. Server-side path üzerinde timeout riski vardır. Local caching veya polling config modeli tercih edilebilir. P95 assignment latency observability metriği olabilir. Default variant failover davranışı tanımlanmalıdır.

Layout Shift

Client-side DOM değişiklikleri layout shift üretebilir. Treatment alanı başlangıçtan rezerve edilebilir. Anti-flicker script de görünümü geciktirebilir. CLS experiment guardrail olabilir. Visual QA yanında field measurement yapılmalıdır.

Performance Guardrail

Performance guardrail kabul edilemez latency veya Core Web Vitals regressionını sınırlar. Threshold ürün standardına göre belirlenir. Kritik ihlalde experiment otomatik durdurulabilir. Conversion lift ile performance cost birlikte raporlanır. Optimization yalnız ticari metric için kullanıcı deneyimini feda etmemelidir.

Split URL Testlerinin SEO Etkisi

Split URL testleri arama motorlarının görebileceği birden fazla URL oluşturabildiği için SEO yönetimi gerektirir. Crawling, canonical ve test süresi dikkatli planlanmalıdır. Arama motoruna kullanıcıdan tamamen farklı içerik sunan yöntemlerden kaçınılmalıdır. Test URL'leri kalıcı duplicate architecture haline gelmemelidir. E-ticaret URL mimarisi ve canonical yönetimi hakkında daha geniş teknik bağlam için https://www.diyarbakiryazilim.com.tr/posts/e-ticaret-kategorilerinde-filtreleme-ve-canonical-url-yonetimi adresindeki yaklaşım da incelenebilir.

Ayrı URL'ler

Control ve treatment farklı URL'lerde olabilir. Routing experiment assignmenta göre kullanıcıyı yönlendirebilir. URL'lerin analytics identitysi aynı deneyle ilişkilendirilmelidir. Permanent crawlable duplicates önlenmelidir. Test sonrası treatment rollout routeu sadeleştirilmelidir.

Crawling

Arama motoru test URL'lerini keşfedebilir. Bu davranış deployment planında hesaba katılmalıdır. Robots kullanımının indexing ve testing sonuçlarına etkisi değerlendirilmelidir. SEO ekibi experiment owner ile koordineli çalışmalıdır. Test manipülatif crawler targeting yapmamalıdır.

Canonical Yönetimi

Canonical sinyalleri duplicate test URL'lerinin ilişkisinde kullanılabilir. Uygulama test modeline göre belirlenmelidir. Treatment URL kalıcı hedef olacaksa rollout sonrası canonical güncellenir. Canonical yanlış kullanılırsa indexing karmaşası oluşabilir. SEO QA launch checklistine eklenmelidir.

Test Süresinin Yönetilmesi

Split URL test gereksiz uzun süre açık kalmamalıdır. Sample ve minimum duration planına göre çalıştırılır. Sonuç sonrası rollout veya cleanup yapılır. Eski treatment URL'leri uygun şekilde kapatılır veya yönlendirilir. Experiment technical debt önlenir.

Arama Motoru Trafiği ile Experimentation Uyumu

Organic kullanıcılar randomization populationına dahil edilebilir. Arama motoruna özel treatment üretmek doğru değildir. Analytics traffic source segmenti exploratory analysis için kullanılabilir. SEO performance kısa test süresinde ayrı izlenebilir. Büyük değişiklik rollout sonrası Search Console monitoring gerektirebilir.

Mobile App A/B Testing Altyapısı

Mobil uygulamalarda A/B testing webden farklı release ve identity kısıtlarına sahiptir. Remote config ve feature flags app store release beklemeden davranış değiştirmeyi sağlayabilir. App version ve SDK compatibility experiment eligibility için önemlidir. Assignment persistence uygulama yeniden başlatıldığında korunmalıdır. Mobile eventlerin backend veya product analytics ile güvenilir biçimde toplanması gerekir.

Remote Config

Remote config uygulama davranış parametrelerini sunucudan değiştirmeye imkan verir. Copy, layout seçenekleri veya feature thresholds yönetilebilir. Config cache offline kullanım için önemlidir. Default value uygulama binary içinde bulunmalıdır. Experiment assignment config ile birlikte çalışabilir.

Feature Flags

Mobile feature rollout flag arkasına alınabilir. App store review beklemeden kullanıcı yüzdesi değiştirilebilir. Kill switch kritik buglarda değerlidir. Flag evaluation düşük latency ile yapılmalıdır. Cleanup sonraki app versionlarında tamamlanmalıdır.

App Version

Eski app version treatment kodunu desteklemeyebilir. Eligibility minimum version içerebilir. Version distribution experiment sampleını etkiler. Upgrade davranışı segment analysis gerektirebilir. Assignment version değişiminde korunmalıdır.

SDK Compatibility

Experiment SDK sürümleri farklı app binarylerde çalışabilir. Schema ve exposure behavior backward compatible olmalıdır. Eski SDK event formatı metric engine tarafından desteklenebilir. Upgrade adoption izlenmelidir. Breaking changes uzun release cycle nedeniyle dikkatle planlanmalıdır.

Assignment Persistence

Local storage ve server identity birlikte kullanılabilir. Kullanıcı app reinstall yaptığında anonymous ID değişebilir. Login sonrası assignment merge uygulanabilir. Cross-device deneyim gerekirse account-level identity kullanılır. Sticky behavior QA edilir.

Mobile Events

Offline eventler network geldiğinde sonradan gönderilebilir. Timestamp event time ve receive time ayrı tutulmalıdır. Duplicate retry kontrolü gerekir. Data pipeline lag experiment dashboardda görünmelidir. App crash metric guardrail olabilir.

App Store Release Cycle

Yeni treatment code app binary deployment gerektiriyorsa test hazırlığı daha uzun sürer. Feature flags kodu önceden ship etmeye yardımcı olur. Experiment app adoption yeterli olduğunda başlatılabilir. Old version kullanıcıları control dışında kalabilir. Eligibility sample planında dikkate alınmalıdır.

SaaS Ürünlerinde CRO A/B Testleri

SaaS deney programı signup, onboarding, activation, trial-to-paid, pricing, upgrade ve retention yolculuklarını kapsayabilir. Burada final purchase yerine recurring value ve activation daha önemli olabilir. Kullanıcının planı veya account identity randomization unit seçiminde rol oynar. Conversion sonucu haftalar sonra ortaya çıkabilir. Kısa vadeli signup lift retention guardrail ile birlikte değerlendirilmelidir.

Signup

Signup form alanları ve social login seçenekleri test edilebilir. Primary metric completed signup olabilir. Fraud veya low-quality signup guardrail gerekebilir. Client click yerine backend account creation event kullanılmalıdır. Marketing source segmenti önceden tanımlanabilir.

Onboarding

Onboarding steps, checklist veya guided setup test edilebilir. Activation metric signup'tan daha anlamlı olabilir. Time to value secondary metric olabilir. Treatment complexity support contactı artırabilir. Returning users test dışında bırakılabilir.

Activation

Activation ürünün temel değerini ilk kez yaşama davranışıdır. Doğru activation definition historical retention ilişkisiyle doğrulanmalıdır. Experiment treatment kullanıcıyı bu milestone'a hızla ulaştırmayı hedefler. Time-to-activation analiz edilebilir. Fake engagement yerine gerçek değer sinyali seçilmelidir.

Trial-to-Paid

Trial uzunluğu veya paywall messaging test edilebilir. Conversion gecikmeli oluşabilir. Revenue ve refund metricleri birlikte izlenmelidir. Account-level randomization B2B SaaS için uygun olabilir. Trial users farklı cohortlarda segmentlenebilir.

Pricing

Pricing deneyleri yüksek risk ve business value taşır. Legal ve brand review gerekebilir. Revenue per visitor yanında conversion ve churn izlenmelidir. Same account tutarlı fiyat görmelidir. Global pazarlarda currency ve geography rules karmaşık olabilir.

Upgrade

Upgrade prompt timing veya package presentation test edilebilir. Existing paid users hassas populationdır. Cancellation ve support tickets guardrail olabilir. Incremental MRR primary metric olarak kullanılabilir. Long-term retention takip edilmelidir.

Retention

Retention deneyleri uzun observation window gerektirir. Feature engagement kısa proxy olabilir. Permanent holdout faydalıdır. Cohort metric engine gereklidir. Sample plan basit immediate conversion testinden farklıdır.

E-Ticarette A/B Test Altyapısı

E-ticaret experimentation ürün detay, search, recommendation, cart, checkout ve payment akışlarında kullanılabilir. Revenue guardrails ve order data doğruluğu kritik önemdedir. Kullanıcı davranışı session içinde hızla değiştiği için exposure timing doğru olmalıdır. Promotion ve pricing deneyleri campaign takvimiyle çakışabilir. E-ticaret programında final karar yalnız conversion değil revenue, margin, refund ve checkout reliability ile birlikte verilmelidir.

Product Detail Page

Hero görseli, fiyat sunumu, social proof veya CTA test edilebilir. Add to cart secondary metric olabilir. Purchase conversion daha güçlü business metricdir. Mobile ve desktop effect farklılaşabilir. Page performance guardrail izlenmelidir.

Search

Search ranking ve filters server-side deney için uygundur. Search success, product click ve revenue metricleri kullanılabilir. Query mix treatment effecti etkileyebilir. Randomization user veya session olabilir. Search latency guardrail olmalıdır.

Recommendation

Recommendation algorithm CTR ve revenue üzerinde test edilebilir. Placement exposure doğru loglanmalıdır. User-level personalization interaction yaratabilir. Revenue per exposed user daha anlamlı olabilir. Recommendation latency izlenmelidir.

Cart

Cart upsell veya shipping messaging test edilebilir. Average order value ve purchase conversion birlikte değerlendirilmelidir. Aggressive upsell checkout abandonment artırabilir. Performance ve error guardrail önemlidir. Cart state server-side tutulduğunda assignment backendde yapılabilir.

Checkout

Checkout field count ve step structure yüksek impact alanıdır. Payment success final metric olabilir. Form error rate secondary metric olarak kullanılır. Reliability riskinden dolayı progressive rollout yapılabilir. Kill switch launch öncesi hazırlanmalıdır.

Payment

Payment method order veya routing deneyleri yüksek risklidir. Transaction success ve fraud guardrails gerekir. Kullanıcıya fiyat veya ücret bilgisi şeffaf gösterilmelidir. Financial source of truth kullanılmalıdır. Experiment review board uygun olabilir.

Revenue Guardrails

Conversion yükselirken AOV veya margin düşebilir. Revenue per user ve contribution margin birlikte izlenebilir. Refund ve cancellation gecikmeli guardrails olabilir. Promotion testlerinde net profit değerlendirilmelidir. CRO yalnız sipariş sayısını optimize etmemelidir.

B2B Ürünlerde A/B Test

B2B ürünlerde düşük trafik, uzun satış döngüsü ve account-level davranış klasik web CRO testlerini zorlaştırabilir. Randomization kullanıcı yerine account seviyesinde yapılabilir. Demo request, qualified lead ve pipeline revenue gibi metrikler kullanılır. Sonuçların oluşması haftalar veya aylar sürebilir. Bu nedenle qualitative research ve büyük treatment hipotezleri B2B experimentation programında daha önemli hale gelir.

Account-Level Assignment

Aynı şirketteki kullanıcılar aynı varyantı görmelidir. Pricing veya enterprise workflow için özellikle önemlidir. Sample unit account olur. Büyük hesapların metric ağırlığı özel yöntem gerektirebilir. Cross-user contamination azalır.

Düşük Trafik

B2B website traffic çoğu B2C üründen düşüktür. Tiny MDE testleri pratik değildir. Daha büyük effectli messaging ve form değişikliklerine odaklanılabilir. Bayesian veya frequentist seçim sample sorununu sihirli biçimde çözmez. Research yöntemleri programı tamamlar.

Uzun Satış Döngüsü

Demo request bugün oluşup revenue aylar sonra gelebilir. Primary proxy metric qualified opportunity olabilir. Historical correlation doğrulanmalıdır. Long-term pipeline outcome sonradan experiment recorda eklenir. Immediate conversion tek başına yeterli değildir.

Demo Request

Demo request form completion CRO metricidir. Form quality ve lead intent dikkate alınmalıdır. Treatment daha çok düşük kaliteli lead üretirse sales yükü artabilir. Qualified lead guardrail veya primary metric olabilir. CRM integration gereklidir.

Qualified Lead

Qualified lead sales kriterini karşılayan potansiyel müşteridir. Event analytics yerine CRM source of truth kullanılabilir. Exposure ile CRM record identity join edilmelidir. Attribution haftalar sürebilir. Data warehouse entegrasyonu faydalıdır.

Pipeline Revenue

Pipeline revenue deneylerin gerçek ticari etkisine daha yakındır. Ancak sample çok seyrek olabilir. Few large deals metric varianceını yükseltir. Account-level analysis gerekir. Test sonuçları kısa ve uzun dönem şeklinde raporlanabilir.

Experiment Repository Nedir?

Experiment repository organizasyonun bütün deney geçmişini saklayan kurumsal hafızadır. Experiment ID, hipotez, owner, tarih, varyantlar, metrics, sonuç, decision ve learning bilgileri burada tutulur. Yalnız kazanan testleri kaydetmek selection bias yaratır. Başarısız ve inconclusive deneyler de gelecek fikirlerin kalitesini artırır. Repository sayesinde ekipler aynı hipotezi tekrar tekrar test etmek yerine önceki kanıt üzerinden yeni soru geliştirebilir.

Experiment ID

Her deney benzersiz ID taşır. Dashboard, feature flag ve warehouse aynı ID'yi kullanır. Human-readable title ayrıca bulunabilir. ID yeniden kullanılmamalıdır. Cross-system audit kolaylaşır.

Hipotez

Original pre-launch hipotez saklanmalıdır. Test sonrasında yeniden yazılmamalıdır. Evidence ve expected mechanism eklenir. Sonuç hipotezin desteklenip desteklenmediğini gösterir. Learning gelecekte arama yapılabilir hale gelir.

Owner

Experiment owner koordinasyondan sorumludur. Product, CRO veya growth rolünde olabilir. Data reviewer ve engineering owner ayrıca saklanabilir. Owner değişirse repository güncellenir. Sonuç ve cleanup görevleri sahipsiz kalmaz.

Tarihler

Start, stop ve analysis tarihleri tutulmalıdır. Traffic ramp değişiklikleri timelinea eklenebilir. Major campaign ve tracking change not edilebilir. Long-term metric refresh tarihleri saklanır. Historical analysis kolaylaşır.

Varyantlar

Control ve treatment descriptions repositoryde bulunur. Screenshot veya design linki eklenebilir. Technical flag IDs kaydedilir. Treatment code cleanup sonrasında bile geçmiş referans korunur. Meta-analysis için treatment category kullanılabilir.

Metrics

Primary, secondary ve guardrail metricler saklanır. Metric version kayıt altına alınır. MDE ve sample planı eklenir. Source of truth belirtilir. Sonradan metric cherry-picking önlenir.

Sonuç

Lift, uncertainty ve guardrail outcomes kaydedilir. SRM veya data quality problemi varsa açıkça belirtilir. Segment findings confirmatory veya exploratory olarak etiketlenir. Screenshot yerine structured result tercih edilir. Gelecekte toplu analiz mümkün olur.

Decision

Ship, do not ship, iterate, inconclusive veya follow-up kararları standardize edilebilir. Karar sonuçla aynı şey değildir. Pozitif lift business risk nedeniyle ship edilmeyebilir. Kararın owner ve tarihi tutulur. Rollout status sonradan güncellenir.

Learning

Learning deney programının en değerli çıktılarından biridir. Kullanıcı davranışı hakkındaki yeni bilgi kısa cümlelerle yazılır. “Treatment kazanmadı” learning değildir. Hangi mekanizmanın desteklenmediği açıklanır. Sonraki hipotezler repository search üzerinden bu bilgiyi kullanabilir.

Başarısız A/B Testler Saklanmalı mı?

Evet, kaybeden veya nötr testler program hafızası için son derece değerlidir. Yalnız kazanan deneyleri saklamak organizasyonun geçmişe dair yanlış olumlu tablo görmesine neden olur. Aynı hipotezin farklı ekipler tarafından tekrar test edilmesi önlenebilir. Meta-analysis hangi treatment kategorilerinin daha sık değer ürettiğini gösterebilir. Learning velocity, win rate'ten daha sağlıklı program KPI'ı olabilir.

“Kaybeden” Testlerin Değeri

Negatif treatment kullanıcıların belirli ihtiyacını anlamaya yardımcı olur. Beklenen mekanizma çalışmamış olabilir. Design assumption yanlış olabilir. Bu bilgi sonraki yatırımı kurtarır. Üretime yanlış feature çıkmasını önlemek de experiment ROI'nın parçasıdır.

Aynı Hipotezin Tekrar Test Edilmesini Önlemek

Repository search yapılmadığında ekipler yıllar önce test edilmiş fikri tekrar kurabilir. Bu tamamen yanlış değildir, koşullar değişebilir. Ancak önceki result bilinerek yeni treatment tasarlanmalıdır. Duplicate experiment warning uygulanabilir. Kurumsal hafıza engineering eforunu azaltır.

Kurumsal Hafıza

Çalışanlar ekipten ayrılsa bile experiment knowledge kaybolmamalıdır. Structured repository karar rationale saklar. Yeni ekip üyeleri geçmiş ürün öğrenimlerini hızlı anlayabilir. Strategy review geçmiş evidence kullanır. CRO kişisel hafızadan kurumsal sisteme dönüşür.

Meta-Analysis

Yüzlerce deney toplandığında ortak patternler analiz edilebilir. Örneğin onboarding simplification testlerinin ortalama effecti incelenebilir. Publication bias önlemek için kaybeden testlerin de dataset içinde olması gerekir. Experiment taxonomy meta-analysis kalitesini artırır. Gelecek prioritization daha veri temelli olur.

Learning Velocity

Learning velocity belirli dönemde kaç güvenilir ürün sorusunun cevaplandığını ölçebilir. Her test kazanmak zorunda değildir. Hızlı ama düşük kaliteli test çok öğrenme üretmeyebilir. Data quality failure sonucu düşürür. Program KPI'ı yalnız quantity olmamalıdır.

CRO Programında Hangi KPI'lar İzlenmeli?

CRO programı yalnız toplam conversion lift ile ölçülmemelidir. Experiment velocity, time to experiment, decision lead time, experiment coverage, incremental value, learning rate ve data quality failure rate program sağlığını gösterir. Bu metriklerin bazıları hız, bazıları kalite ve bazıları business impact ölçer. Win rate tek başına ekipleri güvenli ve küçük testlere yönlendirebilir. Dengeli KPI seti experimentation programını daha sürdürülebilir hale getirir.

Experiment Velocity

Belirli dönemde tamamlanan güvenilir experiment sayısıdır. Yüksek sayı her zaman iyi değildir. Testler düşük impactli olabilir. Segment veya product team bazında izlenebilir. Data quality ve learning metrics ile birlikte kullanılmalıdır.

Time to Experiment

Fikirden launch'a geçen süreyi ölçer. Platform friction ve QA bottlenecklerini gösterir. Self-service tooling süreyi azaltabilir. High-risk testlerin doğal olarak daha uzun sürmesi mümkündür. Median süre daha anlamlı olabilir.

Decision Lead Time

Test bittikten final decisiona kadar geçen süredir. Analysis queue veya stakeholder delay problemi gösterebilir. Automated metrics engine süreyi azaltır. Long-term metric gereken deneyler ayrı kategoriye alınmalıdır. Kararsız testlerin flag debt oluşturması engellenir.

Experiment Coverage

Ürün geliştirmelerinin ne kadarının kontrollü deneyle değerlendirildiğini gösterebilir. Her feature test edilmediği için yüzde 100 hedef doğru değildir. High uncertainty changes için coverage daha anlamlıdır. Team adoption ölçülebilir. Governance olgunluğunu gösterir.

Incremental Value

Deneylerden rollout edilen değişikliklerin tahmini incremental revenue veya conversion etkisidir. Winner lift trafik ve rollout süresiyle ölçeklenebilir. Double counting riski vardır. Global holdout daha güvenilir program-level impact sağlayabilir. Finance reconciliation yapılmalıdır.

Learning Rate

Learning rate cevaplanan stratejik hipotez sayısını ölçebilir. Null result da learning olabilir. Repository taxonomy gereklidir. Quality scoring uygulanabilir. Programın yalnız shipping değil knowledge production rolü görünür olur.

Data Quality Failure Rate

SRM, missing events veya tracking bug nedeniyle invalid olan deneylerin oranıdır. Yüksek değer platform ve QA problemi gösterir. Bu KPI düşürüldüğünde gerçek experiment capacity artar. Root causes kategori bazında izlenebilir. Platform roadmap data quality sorunlarına öncelik verebilir.

A/B Test Win Rate İyi Bir KPI mıdır?

Win rate yardımcı bir gözlem metriği olabilir fakat ana performans hedefi yapılmamalıdır. Her testin kazanması bekleniyorsa ekip muhtemelen yalnız güvenli ve küçük değişiklikleri test ediyordur. Gerçek inovasyon belirsizlik içerir. Win rate'i hedef yapmak selection bias ve sonuç manipülasyonu riskini artırır. Learning value, incremental business impact ve experiment quality daha dengeli KPI'lardır.

Neden Her Testin Kazanması Beklenmemeli?

Experimentation belirsizliği çözmek için yapılır. Sonuç zaten kesinse test değeri düşüktür. Güçlü hipotezler bile kullanıcı davranışında beklenmedik sonuç verebilir. Null veya negative sonuç kötü ekip performansı değildir. Yanlış featureı productiona almamak büyük değer yaratabilir.

Hipotez Kalitesi

Düşük win rate zayıf hypothesis process sinyali olabilir. Ancak tek başına kanıt değildir. Evidence score ve learning quality ayrıca incelenmelidir. Research-driven hipotezlerin outcome dağılımı analiz edilebilir. Program improvement için meta-analysis kullanılabilir.

Selection Bias

Win rate hedeflenirse ekipler yalnız kazanma ihtimali yüksek testleri seçer. Büyük ama belirsiz fikirler test edilmez. Kaybeden sonuçları repositoryye kaydetmeme eğilimi oluşabilir. Program innovation kapasitesi düşer. KPI tasarımı davranışı şekillendirir.

Öğrenme Değeri

Bir test kaybetse bile müşteri motivasyonunu anlamayı sağlayabilir. Büyük roadmap yatırımını iptal ettirebilir. Bu tasarruf doğrudan conversion lift olarak görünmez. Learning value qualitatif ve stratejik ölçülebilir. Repository bu faydayı saklar.

Win Rate'i Hedef Yapmanın Riskleri

İnsanlar ölçüldükleri metriği optimize eder. Win rate hedefi küçük MDE, early stop ve cherry-picking davranışını teşvik edebilir. Data quality kültürü zayıflar. Experiment programı bilimsel öğrenmeden başarı gösterisine dönüşür. Leadership daha dengeli KPI seti kullanmalıdır.

CRO ROI Nasıl Hesaplanır?

CRO ROI yalnız platform lisans maliyetini conversion lift ile karşılaştırmak değildir. Incremental conversion, incremental revenue, development cost, platform cost, analytics cost ve incremental profit birlikte değerlendirilmelidir. Kazanan treatmentın ne kadar süre ve trafik üzerinde rollout edildiği önemlidir. Kaybeden testlerin önlediği yanlış yatırımlar da program değerine katkı sağlayabilir. Program-level ROI için global holdout en güçlü doğrulama yöntemlerinden biri olabilir.

Incremental Conversion

Control baseline ile treatment lift rollout trafficine uygulanabilir. Statistical uncertainty hesaba katılmalıdır. Effect zamanla decay edebilir. Tek test sonucu sonsuza kadar aynı lift üretmez. Periodic post-rollout measurement gerekir.

Incremental Revenue

Incremental conversion average revenue ile birleştirilebilir. Revenue per user metrici daha doğrudan olabilir. Campaign overlap double counting yaratabilir. Net revenue finance data ile doğrulanmalıdır. Currency ve tax policy belirlenmelidir.

Development Cost

Design, frontend, backend ve QA zamanı maliyete dahildir. Experiment code sonradan cleanup gerektirir. Opportunity cost de düşünülebilir. Platform self-service effortı azaltabilir. Cost measurement prioritizationı geliştirir.

Platform Cost

SaaS license, infrastructure veya self-hosting maliyeti dahil edilir. Event volume veya monthly active user pricing modeli scale ile değişebilir. Vendor cost yalnız sticker price değildir. Integration ve support effort hesaba katılmalıdır. Build vs buy analizine veri sağlar.

Analytics Cost

Warehouse compute, data engineering ve statistical analysis maliyeti olabilir. Data quality maintenance görünmeyen önemli giderdir. Experimentation scale arttıkça automated metrics engine maliyeti düşürebilir. Tracking governance ayrıca kapasite gerektirir. Program ROI toplam operating model üzerinden hesaplanmalıdır.

Incremental Profit

Revenue artışı her zaman profit artışı değildir. Discount treatment marginı düşürebilir. Refund ve fulfillment maliyeti hesaba katılmalıdır. Contribution margin metric daha gerçek iş değeri sağlayabilir. Finance partner CRO programına dahil edilmelidir.

Experiment ROI

Experiment ROI incremental profit ile toplam deney maliyetinin ilişkisini gösterir. Tek test ROI'sı volatile olabilir. Program-level yıllık ROI daha anlamlıdır. Global holdout ve repository data kullanılabilir. Learning ve risk reduction değeri ayrıca qualitatively raporlanabilir.

A/B Testing Platformu Seçim Kriterleri

CRO için A/B testing araçları ve deney platformları nasıl seçilir sorusunun yanıtı yalnız visual editor karşılaştırması değildir. Client-side, server-side, feature flags, SDK kapsamı, statistical engine, SRM kontrolü, segmentation, warehouse integration, raw data export, privacy, self-hosting ve maliyet birlikte değerlendirilmelidir. Mevcut engineering ve data stack ile uyum önemlidir. Büyük ekiplerde governance ve experiment repository yetenekleri de kritik hale gelir. Platform seçimi gerçek use case listesiyle proof of concept üzerinden yapılmalıdır.

Client-Side Support

Landing page ve frontend tests için client SDK gerekli olabilir. Flicker prevention yaklaşımı incelenmelidir. Visual editor modern SPA ile uyumlu mu test edilmelidir. Performance payload ölçülmelidir. CSP ve privacy compatibility kontrol edilmelidir.

Server-Side Support

Backend SDK ve remote evaluation özellikleri değerlendirilmelidir. Latency ve caching modeline bakılmalıdır. Critical path failure behavior test edilmelidir. API ve mobile use cases desteklenmelidir. Feature delivery ile exposure logging ayrımı bulunmalıdır.

Feature Flags

Flag lifecycle ve progressive rollout platformun kullanım alanını genişletir. Experiment ve feature flag entegrasyonu önemlidir. Kill switch hızlı çalışmalıdır. Stale flag management bulunabilir. Audit log kurumsal kullanım için değerlidir.

SDK Kapsamı

Kullanılan backend ve mobile dilleri desteklenmelidir. SDK behavior bütün dillerde tutarlı olmalıdır. Open specification veya OpenFeature uyumu vendor bağımlılığını azaltabilir. Version release cadence incelenmelidir. Community ve documentation kalitesi önemlidir.

Statistiksel Motor

Platform kullandığı methodology açıkça belgelemelidir. Sample size ve stopping rule desteği olmalıdır. Confidence veya Bayesian probability doğru açıklanmalıdır. Revenue gibi non-binary metric desteği incelenmelidir. Black-box winner badge tek başına yeterli değildir.

SRM Kontrolü

Sample Ratio Mismatch otomatik tespit edilmelidir. Assignment ve exposure seviyesinde ayrı kontrol faydalıdır. Alert özelliği bulunmalıdır. Root cause debugging data erişimi verilmelidir. SRM varken sonucu gizlememelidir.

Segmentation

Predefined segments ve exploratory breakdown desteklenebilir. Segment sample uncertainty görünür olmalıdır. Post-hoc cherry-picking'i teşvik eden arayüzden kaçınılmalıdır. Raw data export confirmatory analysis için yararlıdır. Business properties integration gereklidir.

Warehouse Integration

Exposure data warehouse'a kolay aktarılmalıdır. Existing metrics warehouse üzerinden kullanılabiliyorsa büyük avantajdır. Batch latency bilinmelidir. SQL metric definitions desteklenebilir. Data residency gereksinimleri kontrol edilmelidir.

Raw Data Export

Raw assignment, exposure ve outcome data erişilebilir olmalıdır. Vendor dashboard sonucunu bağımsız doğrulama imkanı sağlar. Export format ve latency incelenmelidir. API limitleri gözden geçirilmelidir. Data ownership contract açık olmalıdır.

Privacy

Platform hangi user identifiersı tuttuğunu açıkça belirtmelidir. PII minimization desteklenmelidir. Consent integration ve deletion workflow bulunmalıdır. Data region seçenekleri değerlendirilebilir. KVKK süreçleri hukuk ekibiyle birlikte incelenmelidir.

Self-Hosting

Self-hosting veri kontrolü sağlayabilir. Ancak maintenance, security ve upgrade sorumluluğu kuruma geçer. Total cost hesaplanmalıdır. HA ve backup planı gerekir. Sırf lisans maliyetinden kaçmak için self-hosting seçilmemelidir.

Maliyet

Pricing MAU, event volume veya seat bazlı olabilir. Experiment program büyüdükçe maliyet modeli değişir. Implementation ve training cost eklenmelidir. Vendor migration riski değerlendirilmelidir. Total cost of ownership karşılaştırılmalıdır.

Build vs Buy: Kendi A/B Test Altyapımızı mı Kurmalıyız?

Build vs buy kararı yalnız yazılım lisans fiyatına göre verilmemelidir. SaaS experimentation platform hızlı time to value sağlayabilir, open source veri kontrolü sunabilir, tamamen in-house sistem ise yüksek esneklik sağlar. Buna karşılık statistical expertise, SDK maintenance, data pipeline ve platform reliability ciddi engineering maliyeti yaratır. Çok büyük ürün organizasyonları özel sistemden fayda görebilir. Küçük ve orta ekipler için satın alınan veya açık kaynak hibrit çözüm daha ekonomik olabilir.

SaaS Experimentation Platform

SaaS çözüm assignment, dashboard ve statistics hazır sunabilir. Setup süresi kısadır. Vendor support operasyon yükünü azaltır. Data export ve privacy sınırlamaları incelenmelidir. Uzun dönem pricing scale dikkatle değerlendirilmelidir.

Open Source

Open source self-hosting ve kod görünürlüğü sağlar. Community maintenance seviyesi kritik önemdedir. Statistical engine kalitesi incelenmelidir. Upgrade ve security patches kurum sorumluluğunda olabilir. Build effort tamamen ortadan kalkmaz.

Tamamen In-House Platform

In-house sistem ürün mimarisine tam uyum sağlayabilir. Custom identity ve metrics engine geliştirilebilir. Bunun bedeli yüksek platform engineering maliyetidir. Statistics ve data quality uzmanlığı gerekir. Yıllarca bakım kapasitesi planlanmalıdır.

Engineering Cost

Assignment service ilk sürümü kolay görünebilir. Asıl maliyet SDK, observability, dashboard, flags, repository ve data quality katmanlarında ortaya çıkar. On-call ve incident management gerekir. Platform roadmap ürün ekipleriyle yarışabilir. Total ownership uzun dönem hesaplanmalıdır.

Statistical Expertise

Experiment engine güvenilir methodology gerektirir. Sample size, sequential testing ve multiple comparisons konuları uzmanlık ister. Yanlış engine hatalı business kararları üretir. Vendor methodology de bağımsız review edilmelidir. In-house için data science kapasitesi şarttır.

Maintenance

SDK versions, database schema ve infrastructure sürekli bakım ister. Product platform olarak uptime beklentisi oluşur. Stale flags ve experiment configs temizlenmelidir. Security patches uygulanır. “Bir kez yazalım” yaklaşımı gerçekçi değildir.

Vendor Lock-in

Vendor-specific SDK ve event schema migration maliyeti oluşturabilir. OpenFeature benzeri abstraction yaklaşımları yardımcı olabilir. Raw data export olmazsa lock-in artar. Experiment IDs ve metric definitions kurum tarafında tutulmalıdır. Exit plan satın alma sırasında düşünülmelidir.

Time to Value

SaaS platform birkaç haftada ilk test sağlayabilir. In-house çözüm aylar sürebilir. Ancak mevcut data warehouse integration custom ihtiyaç taşıyabilir. Pilot plan karar için iyi yöntemdir. İlk 30 günde A/A ve düşük riskli A/B deneyle gerçek maliyet görülebilir.

Open Source A/B Testing Altyapıları

Açık kaynak experimentation yaklaşımı full platform, product analytics plus experimentation, feature flag infrastructure, statistical library veya experiment-as-code biçiminde olabilir. Her yaklaşım aynı kapsamı sunmaz. Feature flag projesi güçlü assignment sağlayıp statistical analysis sunmayabilir. Analytics ürünü metric hesaplayıp server-side delivery konusunda sınırlı olabilir. Seçim yaparken ürünün aktif maintenance durumu, exposure logging ve data ownership özellikleri birlikte incelenmelidir.

Full Experimentation Platform

Full platform management, assignment, metrics ve dashboard sunmayı hedefler. Self-hosting seçeneği olabilir. Production readiness ayrıca değerlendirilmelidir. HA ve upgrade süreçleri belgelenmelidir. Statistical methodology review edilmelidir.

Product Analytics + Experimentation

Analytics sistemi existing event data üzerinde deney analizi sağlayabilir. Tracking entegrasyonu kolaylaşır. Feature delivery ayrı flag platformuyla yapılabilir. Exposure event standardı gereklidir. Analytics source of truth advantage sağlar.

Feature Flag Infrastructure

Flag infrastructure reliable assignment ve rollout sağlar. Experiment analysis için warehouse veya ayrı statistics layer gerekir. OpenFeature uyumu entegrasyonu kolaylaştırabilir. SDK kalitesi kritik önemdedir. Stale flag cleanup süreci incelenmelidir.

Statistical Library

Statistical library metric inputlarından result üretir. Assignment ve exposure sistemini çözmez. Data team custom warehouse-native platform kurabilir. Methodology code review edilebilir. Validation test suites gereklidir.

Experiment-as-Code

Experiment config Git repository içinde code veya config olarak tutulabilir. Pull request review governance sağlar. CI validation yanlış traffic splitleri engelleyebilir. Dashboard yine ayrı gerekir. Engineering-centric ekipler için güçlü model olabilir.

Hangi Yaklaşım Hangi Ekip İçin?

Low engineering capacity full platformdan fayda görebilir. Güçlü data warehouse ekibi warehouse-native modele yönelebilir. Platform engineering kültürü olan kurum flag plus custom metrics engine seçebilir. Privacy ihtiyacı self-hosting yönlendirebilir. Tek doğru yaklaşım yoktur.

Open Source ve İşbirliği ile Experimentation

Açık kaynak araçlar experimentation bilgisinin ekipler ve topluluklar arasında paylaşılmasını kolaylaştırabilir. Self-hosting veri sahipliğini güçlendirebilir, kodun incelenebilirliği platform davranışını daha anlaşılır kılar. Community contribution SDK ve entegrasyonların gelişmesini sağlar. OpenFeature uyumu ortak feature flag standardına yaklaşmayı destekler. Git ve CI tabanlı workflow da experimentation config değişikliklerini software delivery disiplinine bağlar.

Self-Hosting

Self-hosting exposure ve identity verisini kurum altyapısında tutabilir. Güvenlik kontrolü artar. Operasyon sorumluluğu da tamamen kuruma geçer. Backup, scaling ve monitoring kurulmalıdır. Total cost lisanssız olduğu için sıfır değildir.

Veri Sahipliği

Raw exposure ve outcome data kurumun erişiminde kalmalıdır. Vendor migration sırasında geçmiş deneyler kaybolmamalıdır. Open data schema faydalıdır. Data retention kurum politikasıyla yönetilir. Experiment repository bağımsız tutulabilir.

Kodun İncelenebilirliği

Open source assignment algorithm ve statistics code incelenebilir. Security review yapılabilir. Community audit hata bulmaya yardımcı olabilir. Ancak açık kod otomatik olarak güvenilirlik garantisi değildir. Test coverage ve maintenance activity kontrol edilmelidir.

Community Contributions

Yeni SDK veya integration community tarafından eklenebilir. Issue history proje sağlığını gösterir. Pull request review kalitesi önemlidir. Fork maintenance yükü oluşturabilir. Kurum kendi critical patchesini upstream projeye katkı olarak sunabilir.

Experimentation SDK Geliştirme

Ortak SDK wrapper farklı platformları tek internal interface arkasında toplayabilir. Exposure standardı kurum tarafından belirlenir. Vendor change daha kolay olur. SDK observability ve default behavior içerir. Documentation product teams için sade olmalıdır.

OpenFeature Uyumu

OpenFeature benzeri standard interfaces flag evaluation bağımlılığını azaltabilir. Provider değişse bile application code daha stabil kalabilir. Experiment-specific metrics katmanı ayrıca gerekir. Context schema standardize edilebilir. Platform portability artar.

Git/CI Tabanlı Workflow

Experiment config pull request ile değiştirilebilir. Traffic split ve eligibility review edilir. Automated schema validation çalışır. Production promotion audit trail oluşturur. Emergency kill switch yine hızlı ayrı kanal gerektirebilir.

Açık Kaynak A/B Platformu Seçerken Kontrol Listesi

Açık kaynak bir projenin Git deposunun bulunması production kullanımı için yeterli değildir. Projenin aktif bakımı, lisansı, assignment stability, exposure logging, metrics, statistical analysis, SDK kapsamı, self-hosting maliyeti ve upgrade süreci incelenmelidir. Son commit tarihi tek başına kalite göstergesi değildir. Issue çözüm hızı ve release cadence daha anlamlı olabilir. Pilot A/A test gerçek sistem davranışını doğrulamak için güçlü adımdır.

Proje Aktif Olarak Bakımı Yapılıyor mu?

Release history ve issue activity incelenmelidir. Critical security fixlere yanıt süresi önemlidir. Tek maintainer riski değerlendirilmelidir. Roadmap ürün ihtiyaçlarıyla uyumlu mu bakılmalıdır. Fork zorunluluğu bakım maliyetini artırır.

Lisans

Open source lisans ticari kullanım ve dağıtım koşullarını belirler. Legal ekip review yapmalıdır. Network use veya modification şartları incelenir. Enterprise plugin farklı lisans taşıyabilir. Compliance en başta netleştirilmelidir.

Assignment Stability

Hash ve bucketing algorithm upgrade sırasında assignmentı değiştirmemelidir. Stability tests bulunmalıdır. Traffic split update behavior belgelenmelidir. Sticky assignment desteklenmelidir. Cross-SDK consistency test edilmelidir.

Exposure Logging

Platform assignment ile exposure farkını desteklemelidir. Event hook ve timestamp bulunmalıdır. Duplicate policy açık olmalıdır. Raw export mümkün olmalıdır. Exposure olmadan güvenilir experiment analysis zorlaşır.

Metrics

Custom metrics tanımlanabiliyor mu incelenmelidir. User, session veya revenue metric desteği önemlidir. Attribution window config gereklidir. Warehouse data kullanımı avantaj sağlar. Metric versioning bulunması uzun dönem kaliteyi artırır.

Statistical Analysis

Methodology documentation detaylı olmalıdır. Sample size ve SRM desteği kontrol edilir. Multiple variant analysis bulunmalıdır. Revenue distribution gibi non-binary metricler test edilir. Sonuç bağımsız notebook ile doğrulanabilir.

SDK'lar

Kurumun kullandığı diller için SDK bulunmalıdır. Release cadence ve API stability değerlendirilir. Mobile offline behavior incelenir. Server SDK latency benchmark yapılır. Custom wrapper ihtiyacı planlanır.

Self-Hosting Maliyeti

Database, queue ve compute kaynakları maliyet oluşturur. HA ve backup gerekir. On-call sorumluluğu bulunur. Upgrade engineering kapasitesi tüketir. SaaS ile total cost karşılaştırılmalıdır.

Upgrade Süreci

Schema migrations nasıl çalışıyor incelenmelidir. Zero-downtime upgrade mümkün mü bakılmalıdır. Backward compatibility önemlidir. SDK ve server version matrix bulunmalıdır. Rollback planı test edilmelidir.

Experimentation Altyapısında Privacy ve KVKK

Experimentation sisteminin güçlü olması daha fazla kişisel veri toplaması gerektiği anlamına gelmez. Çoğu deney için pseudonymous veya anonymous ID yeterlidir. PII minimizasyonu, consent, data retention ve third-party platform veri akışları açıkça yönetilmelidir. Self-hosted seçenekler veri kontrolü sağlayabilir fakat güvenlik sorumluluğunu ortadan kaldırmaz. KVKK ve ilgili kurum politikaları ürün, hukuk ve güvenlik ekipleriyle birlikte değerlendirilmelidir.

Hangi Kullanıcı Verisi Gereklidir?

Experiment assignment için çoğu zaman stabil internal ID yeterlidir. E-posta veya isim gerekli değildir. Eligibility plan type veya country gibi properties kullanabilir. Her property business gerekçesine sahip olmalıdır. Data minimization platform design prensibi olmalıdır.

PII Minimizasyonu

PII exposure event içinde taşınmamalıdır. Warehouse join için pseudonymous key kullanılabilir. Analytics payload review edilmelidir. Debug logs sensitive data içermemelidir. Data catalog property classification yapabilir.

Anonymous ID

Anonymous ID login olmayan kullanıcı deneyleri için kullanılır. Cookie veya local storage tabanlı olabilir. Consent ve browser restriction etkisi vardır. Login sonrası merge policy gereklidir. Retention süresi açık olmalıdır.

Consent

Measurement ve personalization izin gereksinimleri hukuki çerçeveye göre belirlenmelidir. Consent durumuna göre analytics event akışı değişebilir. Experiment assignment ile analytics tracking aynı hukuki role sahip olmayabilir. Hukuk ekibi kullanım senaryosunu değerlendirmelidir. Kullanıcı tercihi sistemler arasında tutarlı uygulanmalıdır.

Data Retention

Raw exposure event sonsuza kadar tutulmamalıdır. Historical aggregate results daha uzun saklanabilir. User deletion talepleri event storea uygulanmalıdır. Backup retention ayrıca değerlendirilir. Repository anonymized result saklayabilir.

Third-Party Platforms

SaaS vendor hangi data regionda işlem yapıyor incelenmelidir. Subprocessors ve contract şartları değerlendirilir. Raw data export ve deletion API önemlidir. Vendor SDK gereksiz identifier toplamamalıdır. Security assessment procurement sürecine dahil edilmelidir.

Self-Hosted Alternatifler

Self-hosted sistem data residency avantajı sağlayabilir. Ancak patching ve access control kurum sorumluluğundadır. Encryption ve backup kurulmalıdır. Internal misuse riski de yönetilmelidir. Privacy yalnız verinin fiziksel konumuna indirgenmemelidir.

Experimentation Sisteminde Güvenilirlik

Experimentation altyapısı production request pathine girdiğinde reliability ürün güvenilirliğinin parçası olur. SDK çalışmazsa ne olacağı, assignment service kesintisinde sistemin fail-open mı fail-closed mu davranacağı ve default variantın ne olduğu önceden belirlenmelidir. Caching uzak servis bağımlılığını azaltabilir. Kill switch kritik treatmentı hızlı kapatır. Experiment platformu yüzünden ana ürünün çalışmaması kabul edilebilir bir mimari değildir.

SDK Çalışmazsa Ne Olur?

SDK exception product requestini düşürmemelidir. Safe default variant döndürülmelidir. Error telemetry merkezi monitoring'e gitmelidir. Client script fail durumunda control render edilebilir. Experiment outcome data eksik sayılmalıdır.

Assignment Service Kesintisi

Remote assignment service unavailable olabilir. Local cached config kullanılabilir. Timeout çok düşük tutulmalıdır. Product latency etkilenmemelidir. Incident dashboard experiment impacti göstermelidir.

Fail-Open

Fail-open hata durumunda featureı açık bırakabilir. Bazı low-risk rollouts için uygun olabilir. Security-sensitive featurelarda risklidir. Decision feature kategorisine göre verilmelidir. Config içinde davranış açıkça tanımlanmalıdır.

Fail-Closed

Fail-closed problem olduğunda featureı kapatır. Güvenlik veya ödeme deneylerinde daha uygun olabilir. User experience etkisi değerlendirilmelidir. Default control path her zaman çalışmalıdır. Platform outage product outage olmamalıdır.

Default Variant

Default variant productionda en güvenli deneyimi temsil eder. Çoğu testte control olabilir. Config alınamadığında bu davranış uygulanır. Default code path düzenli test edilmelidir. Treatment rollout sonrası default güncelleme cleanup işinin parçasıdır.

Caching

Config caching latency ve availabilityyi iyileştirir. TTL değişiklik hızına göre seçilir. Kill switch cache nedeniyle çok geç uygulanmamalıdır. Push update veya short TTL kullanılabilir. Stale config behavior dokümante edilmelidir.

Kill Switch

Kill switch treatmentı hızlı biçimde kapatmalıdır. Yüksek riskli deneylerde on-call ekip yetkili olmalıdır. Audit log tutulur. Emergency change normal approvaldan daha hızlı olabilir. Olay sonrasında root cause review yapılır.

Experimentation Observability

Experimentation observability assignment latency, SDK error rate, exposure volume, event pipeline lag, missing metrics ve SRM alertlerini birlikte izler. Amaç yalnız altyapının ayakta olduğunu değil güvenilir experiment verisi ürettiğini anlamaktır. Experiment health dashboard result dashboarddan ayrı risk sinyalleri gösterebilir. Platform deploymentları exposure veya event metriclerinde anomali yaratırsa hızlı fark edilir. Bu yaklaşım data quality failure rate'i düşürür.

Assignment Latency

Server ve client evaluation süresi ölçülmelidir. P95 latency product performancea etkisini gösterir. Remote service calls ayrı izlenir. Cache hit ratio faydalı context sağlar. SLO tanımlanabilir.

SDK Error Rate

SDK evaluation exceptions variant deliveryyi bozabilir. Language ve version bazında error rate izlenir. Yeni SDK release regression oluşturabilir. Error spike experiment sonuçlarını invalid hale getirebilir. Rollback mekanizması bulunmalıdır.

Exposure Volume

Exposure event sayısı expected traffic ile karşılaştırılır. Ani düşüş component trigger problemi olabilir. Varyant bazında dağılım incelenir. Assignment volume ile fark hesaplanır. Health alarmı oluşturulabilir.

Event Pipeline Lag

Conversion event warehouse'a gecikmeli gelebilir. Dashboard incomplete data gösterebilir. Pipeline lag açıkça sunulmalıdır. Statistical result final data watermark sonrası hesaplanabilir. Late event refresh politikası bulunmalıdır.

Missing Metrics

Primary metric sıfır veya beklenenden çok düşük gelirse instrumentation sorunu olabilir. Metric engine source table availability kontrol eder. Data quality status sonucu bloklayabilir. Owner alert alır. Outcome chart boşken winner hesaplanmamalıdır.

SRM Alert

SRM test sırasında otomatik izlenmelidir. Alarm assignment ve exposure seviyesinde farklı olabilir. Segment root cause helper sunulabilir. SRM resolved olmadan decision kilitlenebilir. Platform kullanıcıyı veri sorununa karşı korur.

Experiment Health Dashboard

Dashboard assignment, exposure, events ve statistical sanity durumunu gösterir. Green health sonucu “treatment kazandı” anlamına gelmez. Result ayrı katmandır. Data freshness timestamp görünür olmalıdır. Incident linkleri eklenebilir.

CRO Experimentation Governance

Kurumsal experimentation programı self-service olmak isterken kontrolsüz hale gelmemelidir. Kim deney açabilir, launch onayını kim verir, sonucu kim yorumlar ve rollout kararını kim verir açıkça tanımlanmalıdır. Low-risk UI testleri daha hafif governance ile ilerleyebilir. Pricing, checkout, privacy ve brand riskli deneyler daha güçlü review gerektirir. Experiment owner, data reviewer ve engineering owner rolleri sorumluluk ayrımını netleştirir.

Kim Deney Açabilir?

Platform erişimi role-based olabilir. Eğitim tamamlayan product veya growth ekipleri low-risk test açabilir. High-risk experiment ekstra permission gerektirebilir. Naming ve tracking standards otomatik validate edilir. Audit log tutulur.

Kim Launch Onayı Verir?

Launch approval test riskine göre değişir. CRO owner ve engineering owner temel onay verebilir. Pricing deneyinde legal veya finance review gerekir. Accessibility değişikliğinde design review eklenebilir. Governance risk-proportionate olmalıdır.

Kim Sonucu Yorumlar?

Experiment owner dashboard sonucunu tek başına final karar yapmamalıdır. Data reviewer statistical ve data quality durumunu inceler. Product owner business context ekler. Guardrails değerlendirilir. Karar repositoryde gerekçelendirilir.

Kim Rollout Kararı Verir?

Rollout business owner sorumluluğunda olabilir. Data sonucu karar girdisidir. Engineering reliability ve operational risk değerlendirir. High-risk feature progressive rolloutla açılır. Kazanan treatmentın bile ship edilmeme ihtimali vardır.

Experiment Owner

Owner deney briefinden cleanup'a kadar koordinasyonu yönetir. Hypothesis ve metriclerin önceden tanımlanmasını sağlar. QA ve launch süreçlerini takip eder. Sonuç ve learning repositoryye eklenir. Owner değişirse handoff yapılır.

Data Reviewer

Data reviewer sample plan, SRM ve metric quality kontrol eder. Analysis methodologyye uygun mu doğrular. Post-hoc claimsleri ayırır. Inconclusive result yanlış winner ilan edilmesini önler. Merkezi data science veya embedded analyst olabilir.

Engineering Owner

Engineering owner variant implementation ve reliabilityden sorumludur. Kill switch ve cleanup işlerini takip eder. SDK veya event bugını düzeltir. Rollout capacity riskini değerlendirir. Experiment platform ekibiyle koordinasyon sağlar.

Experiment Review Board Gerekli mi?

Her küçük CRO testi için merkezi kurul approvalı experimentation velocityyi gereksiz düşürebilir. Buna karşılık pricing, checkout, privacy, accessibility, brand ve ethics açısından yüksek riskli testlerde review board değerli olabilir. Risk tier modeli deneyleri farklı governance seviyelerine ayırabilir. Low-risk copy test self-service ilerlerken yüksek riskli fiyat deneyi multi-disciplinary review alabilir. Amaç bürokrasi oluşturmak değil geri dönüşü zor zararları launch öncesi yakalamaktır.

Büyük Riskli Deneyler

Yüksek revenue veya geniş user impact taşıyan deneyler özel review alabilir. Rollback zorsa risk yükselir. Sample ramp küçük başlayabilir. Guardrails sıkı tanımlanır. Executive visibility gerekebilir.

Pricing Experiments

Pricing müşteri güveni ve fairness açısından hassastır. Same account consistency sağlanmalıdır. Legal ve finance review yapılabilir. Revenue yanında churn ve support guardrails izlenir. Segment discrimination riski değerlendirilmelidir.

Checkout

Checkout doğrudan revenue pathidir. Error veya payment failure ciddi iş kaybı oluşturur. Engineering QA ve monitoring zorunludur. Progressive rollout yapılabilir. Kill switch hazır olmalıdır.

Privacy

Yeni personalization deneyleri ek user data kullanabilir. Consent ve data minimization review gerekir. Sensitive properties experimentation targeting için kullanılmamalıdır. Third-party data flow kontrol edilir. Hukuk ve security onayı gerekebilir.

Accessibility

Treatment accessibility standardını düşürmemelidir. Automated ve manual QA yapılır. Accessibility değişiklikleri conversiona kurban edilmemelidir. Design system guardrails kullanılabilir. Review board yüksek riskli interaction değişikliğini değerlendirebilir.

Brand Risk

Aggressive copy kısa vadeli conversion artırabilir ama marka güvenini zedeleyebilir. Brand team yüksek görünürlüklü experimentleri review edebilir. Customer complaints guardrail olabilir. Long-term trust OEC içinde değerlendirilmelidir. CRO yalnız lokal click optimization değildir.

Ethics

Manipulative UX, hidden costs veya cancellation friction etik risk oluşturur. Experiment “kazanırsa” bile uygulanmamalıdır. Ethics principle organization policyde açık olmalıdır. Kullanıcı çıkarı guardrail olarak görülmelidir. Review board gri alanlarda karar desteği sağlar.

CRO'da Etik ve Dark Pattern Riski

Conversion artışı her zaman iyi ürün sonucu anlamına gelmez. Kullanıcıyı yanıltan, iptal etmeyi zorlaştıran veya maliyeti gizleyen tasarımlar kısa vadeli metric kazanımı sağlayabilir. Bu tür manipulative UX uzun vadede güven, retention ve brand değerini azaltır. Guardrail metrics ve ethics governance bu nedenle CRO programının parçası olmalıdır. İyi experimentation kullanıcıyı daha kolay ikna etmek değil daha iyi değer sunmak için kullanılır.

Conversion Artışı Her Zaman İyi midir?

Hayır, conversion quality önemlidir. Yanlış anlaşılmış offer daha fazla purchase ve daha fazla refund üretebilir. Aggressive signup flow churnü artırabilir. Primary metric guardrails ile birlikte değerlendirilmelidir. Business objective uzun vadeli değer olmalıdır.

Manipulative UX

Manipulative design kullanıcıyı istemediği aksiyona yönlendirebilir. Default selection, confusing copy veya false urgency örnek olabilir. Bu yöntemler kısa vadeli lift yaratabilir. Kullanıcı güveni ve regulatory risk büyür. CRO guidelines açık etik sınırlar içermelidir.

Kullanıcı Güveni

Trust doğrudan ölçülmesi zor ama uzun vadeli önemli değerdir. Complaint, repeat purchase ve retention proxy olabilir. Pricing consistency güveni etkiler. Experiment programı brand riskini raporlamalıdır. Dark pattern kazanan test sayılmamalıdır.

Cancellation Friction

İptal etmeyi zorlaştırmak churn metricini yapay biçimde düşürebilir. Kullanıcı memnuniyeti ve support cost kötüleşebilir. Regulatory risk oluşabilir. Retention yalnız sistemde kalan account sayısıyla ölçülmemelidir. Etik ürün ilkeleri decision frameworke dahil edilmelidir.

Hidden Costs

Ek maliyeti checkout sonunda göstermek ilk funnel metricleri iyileştirebilir. Final conversion veya refund kötüleşebilir. Price transparency kullanıcı güveni açısından önemlidir. A/B test unethical behaviorı meşrulaştırmaz. Legal ve brand guardrails uygulanmalıdır.

Uzun Vadeli Guardrail'ler

Retention, refund, support complaint ve repeat purchase uzun vadeli etkileri yakalayabilir. Test bittikten sonra metric refresh yapılmalıdır. Permanent holdout ek bilgi sağlar. Short-term winner long-term loser olabilir. OEC bu dengeyi kurmalıdır.

Experimentation Maturity Model

Experimentation maturity modeli organizasyonların ad hoc testlerden experiment-driven çalışma modeline nasıl ilerleyebileceğini gösterir. Seviye 1'de testler bireysel ve düzensizdir. Seviye 2 standart A/B testing, seviye 3 merkezi platform, seviye 4 self-service ve seviye 5 yaygın karar kültürü oluşturur. Her şirketin en üst seviyeye çıkması gerekmez. Ama veri kalitesi ve governance temeli atlanarak yalnız test sayısını artırmak olgunluk sayılmaz.

Seviye 1: Ad Hoc Testler

Testler tek tek araçlarla yapılır. Tracking standardı sınırlıdır. Sonuçlar spreadsheetlerde kaybolabilir. A/A veya SRM kontrolü bulunmayabilir. İlk hedef measurement foundation kurmaktır.

Seviye 2: Standart A/B Testing

Hipotez ve metric şablonları oluşur. Sample size planı standardize edilir. Ortak event taxonomy kullanılır. Experiment repository başlatılır. Hâlâ platform kullanımı merkezi ekip desteği gerektirebilir.

Seviye 3: Merkezi Experimentation Platform

Assignment, exposure ve metrics merkezi sisteme taşınır. Feature flags entegre edilir. Dashboard ve health checks ortak hale gelir. Data warehouse source of truth kullanılabilir. Birden fazla ekip aynı platformu kullanır.

Seviye 4: Self-Service Experimentation

Eğitimli product ekipleri düşük riskli testleri bağımsız başlatabilir. Guardrails ve launch validation otomatik çalışır. Platform team templates ve SDK sağlar. Review yalnız yüksek riskli deneylerde gerekir. Experiment velocity yükselir.

Seviye 5: Experiment-Driven Organization

Belirsiz büyük ürün kararları düzenli olarak deneyle doğrulanır. Global holdout program impactini ölçer. Learning repository strategyye girdi sağlar. Experimentation Center of Excellence standartları geliştirir. Win rate yerine incremental value ve learning quality önemsenir.

Experimentation Center of Excellence

Experimentation Center of Excellence product, data science, engineering, UX research, CRO, growth ve platform engineering ekiplerini ortak standart etrafında birleştirebilir. Bu yapı bütün testleri merkezi olarak yapmak zorunda değildir. Daha iyi model platform, metodoloji, eğitim ve governance standartlarını sağlarken ürün ekiplerinin self-service çalışmasını desteklemektir. A/B test yanlış uygulandığında hız değil yanlış güven üretir. Center of Excellence bu riski azaltıp organizasyon genelinde ortak deney dilini güçlendirir.

Product

Product ekipleri iş problemlerini ve roadmap önceliklerini getirir. Hipotez ve MDE kararına katkı sağlar. Rollout kararının business ownerıdır. Experiment learning ürün stratejisini günceller. Test yalnız CRO ekibinin işi değildir.

Data Science

Data science statistical methodology ve metric design standardını yönetebilir. Sample size ve variance konularında destek verir. SRM ve complex experiment analysis geliştirir. Platform statistical engineini validate eder. Eğitim materyali hazırlar.

Engineering

Engineering reliable implementation ve feature flag lifecycle sağlar. SDK integration standardını uygular. Performance ve error guardrails yönetir. Cleanup technical debt önler. Experiment platform feedbackini roadmap'e taşır.

UX Research

Research güçlü hypothesis generation sağlar. Kullanıcı problemlerini deney öncesi anlamaya yardımcı olur. Null result sonrasında mekanizmayı araştırabilir. Düşük traffic ürünlerde A/B yerine alternatif evidence üretir. Experimentation researchin yerine geçmez.

CRO/Growth

CRO ve growth ekipleri funnel opportunities ve experiment backlog yönetebilir. Copy ve page experiments konusunda expertise sağlar. Program KPI'larını takip eder. Marketing campaign ile test takvimini koordine eder. Learning paylaşımını artırır.

Platform Engineering

Platform team assignment, SDK, exposure pipeline ve observability sağlar. Product teams için self-service araç geliştirir. Reliability SLO yönetir. Vendor integration veya in-house components bakımını yapar. Data quality failuresi azaltır.

Standartlar ve Eğitim

Hipotez, sample size, QA ve decision templates ortaklaştırılır. Yeni çalışanlar experimentation onboarding alır. A/A lab eğitimi yapılabilir. Dokümantasyon gerçek örneklerle güncellenir. Standartlar ekipleri yavaşlatmak yerine güvenilirliği hızlandırır.

En İyi Programlama Dili A/B Test Altyapısı İçin Hangisidir?

A/B test altyapısı için tek bir en iyi programlama dili yoktur. Browser-side experimentation doğal olarak JavaScript veya TypeScript kullanırken server-side sistem mevcut backend diliyle çalışabilir. SQL metric ve warehouse analizinin, Python ise istatistik ve data science işlemlerinin güçlü aracıdır. Asıl önemli olan dil değil assignment stability, latency, data correctness, observability ve maintainability gibi mimari kriterlerdir. Dil seçimi ekip yetkinliği ve mevcut ürün altyapısıyla uyumlu olmalıdır.

Tek Bir En İyi Dil Neden Yoktur?

Experimentation platform farklı katmanlardan oluşur. Frontend SDK ile metrics engine aynı dilde olmak zorunda değildir. Backend ecosystem ekip verimliliğini etkiler. Data warehouse zaten SQL kullanır. Architecture polyglot olabilir.

JavaScript / TypeScript

JavaScript browser experimentation için doğal dildir. Client SDK ve visual treatment uygulanabilir. TypeScript schema ve API güvenilirliğini artırır. Performance ve bundle size dikkat gerektirir. Backend Node.js servislerde de kullanılabilir.

Browser-Side Experimentation

Client assignment, DOM change ve exposure event JS ile yapılabilir. Flicker riski yönetilmelidir. SDK payload küçük tutulmalıdır. CSP uyumu gerekir. Measurement eventleri standardized wrapper kullanmalıdır.

Backend Dilleri

Java, Go, Python, C#, PHP veya diğer backend dilleri server-side experimentation için kullanılabilir. Mevcut application stack tercih edilmelidir. SDK availability platform seçiminde önemlidir. Low-latency flag evaluation gerekir. Dil değiştirmek experimentation için şart değildir.

Server-Side Experimentation

Assignment request path içinde yapılabilir. Local cache latencyyi azaltır. Feature logic backendde çalışır. Exposure güvenilir contextte kaydedilir. Infrastructure reliability ana kriterdir.

SQL

SQL experiment metrics ve segmentation için güçlüdür. Exposure ile conversion join yapılabilir. Window functions attribution hesaplarında kullanılır. Metric definitions version control altında tutulabilir. Warehouse-native model SQL'i merkezi araç haline getirir.

Metric ve Warehouse Analizi

Revenue per user ve funnel metrics SQL ile hesaplanabilir. Experiment population table standardized olmalıdır. Data quality queries otomatik çalıştırılabilir. Scheduled jobs dashboardu besler. Query cost monitoring uygulanmalıdır.

Python

Python statistics ve custom analysis için yaygın tercihtir. Sample size calculator ve SRM tests geliştirilebilir. Notebook exploratory analysis için kullanılabilir. Production statistical engine test edilmiş package kullanmalıdır. Reproducibility önemlidir.

İstatistik ve Data Science

Confidence interval, Bayesian model ve variance analysis Python ile uygulanabilir. Simulation experiment design kararlarını test edebilir. Methodology unit tests yazılmalıdır. Notebook sonucu repositoryye structured formda aktarılmalıdır. İnsan review devam etmelidir.

Dil Seçiminden Daha Önemli Mimari Kriterler

Stable assignment, correct exposure, reliable metrics ve low latency olmadan dil seçimi anlamsızdır. SDK failure productu bozmamalıdır. Data source ve identity standardı güvenilir olmalıdır. Observability sorunları erken yakalamalıdır. Platform kullanıcıya doğru karar üretmelidir.

Yazılımcı Olmak İçin Experimentation Bilgisi Neden Değerlidir?

Experimentation bilgisi yazılımcının kod ile kullanıcı sonucu arasındaki ilişkiyi daha iyi anlamasını sağlar. Event tracking, product analytics, feature flags, SQL, temel istatistik, data quality ve hypothesis-driven development becerileri modern ürün geliştirmede değerlidir. Geliştirici yalnız özelliği “çalışır” hale getirmez, etkisinin nasıl ölçüleceğini de düşünür. Bu yaklaşım teknik ve ürün ekipleri arasındaki iletişimi güçlendirir. Özellikle growth, SaaS ve e-ticaret ürünlerinde experimentation bilgisi geliştiricinin etki alanını genişletir.

Event Tracking

Developer eventin doğru anda ve doğru payloadla üretilmesini sağlar. Duplicate ve race condition problemlerini önler. Backend success ile client click farkını anlar. Schema contract kullanır. Data quality product code kalitesinin parçası olur.

Product Analytics

Product analytics developerın feature usage sonucunu görmesini sağlar. Funnel ve retention kavramlarını anlamak implementation kararlarını geliştirir. Event debugging daha kolay olur. Developer metric definition tartışmasına katkı sağlar. Code ve business impact ilişkisi güçlenir.

Feature Flags

Feature flags release riskini azaltır. Progressive rollout ve kill switch güvenli deployment sağlar. Experiment integration ürün etkisini ölçer. Stale flag cleanup technical discipline gerektirir. Developer operational ownership kazanır.

SQL

SQL geliştiricinin production davranışını doğrudan analiz etmesine yardımcı olur. Experiment exposure ve event tabloları sorgulanabilir. Data anomaly root cause bulunabilir. Product analyst ile ortak dil oluşur. Büyük dataset düşüncesi gelişir.

Temel İstatistik

Developer p-value veya randomization kavramlarını doğru anlar. “İki gün test ettik, kazandı” hatasını fark eder. Sample size ve variance konusunda temel sezgi geliştirir. Data scientist ile daha verimli çalışır. İleri model uzmanlığı şart değildir.

Data Quality

Experimentation data bugları product bugları kadar önemlidir. Missing exposure yanlış business kararına yol açabilir. Developer monitoring ve schema validation kurar. Event contracts test edilir. Measurement reliability engineering concern haline gelir.

Hypothesis-Driven Development

Developer feature requestin hangi problemi çözmeye çalıştığını sorar. Success metric baştan bilinir. Implementation treatment scope ile uyumlu olur. Gereksiz feature complexity azalabilir. Product development öğrenme döngüsüne dönüşür.

Experimentation Engineer Hangi Yetkinliklere Sahip Olmalı?

Experimentation engineer frontend veya backend bilgisiyle sınırlı bir rol değildir. Distributed systems, data engineering, statistics, analytics, product thinking ve platform engineering becerilerini bir araya getirir. Assignment service kadar exposure pipeline ve metrics engine de sorumluluk alanına girebilir. Bu rol ürün ekiplerinin güvenilir biçimde daha fazla test yapabilmesini sağlayan altyapıyı kurar. İyi experimentation engineer yalnız sistem performansını değil yanlış ürün kararı riskini de azaltır.

Backend / Frontend Development

SDK ve feature delivery katmanını anlamak gerekir. Browser performance ve backend latency deney kalitesini etkiler. Cross-platform APIs tasarlanır. Failure behavior test edilir. Developer experience platform adoption için önemlidir.

Distributed Systems

Config distribution ve caching distributed system problemidir. Consistency ve availability tradeoffları vardır. Kill switch hızlı yayılmalıdır. Region ve latency düşünülmelidir. Assignment determinism bütün node'larda aynı kalmalıdır.

Data Engineering

Exposure ve event pipeline yüksek hacimli data taşır. Schema evolution yönetilir. Late events ve deduplication çözülür. Warehouse model design yapılır. Data freshness observability izlenir.

Statistics

Randomization, sample size ve SRM bilgisi gerekir. Statistical engine validation yapılır. Methodology product teams'e açıklanır. Complex metrics için data scientist ile çalışılır. Black-box results engellenir.

Analytics

Metric definitions ve funnel logic anlaşılmalıdır. Source of truth problemleri çözülür. Identity ve attribution tasarlanır. Dashboard kullanıcı ihtiyaçlarına göre geliştirilir. Experiment result business contextle sunulur.

Product Thinking

Platformun amacı daha fazla API değil daha iyi ürün kararlarıdır. User journey ve product risk anlaşılmalıdır. Self-service workflow basit tasarlanmalıdır. Gereksiz governance azaltılır. Learning repository product strategyye bağlanır.

Platform Engineering

SDK, APIs, documentation ve observability platform ürünü olarak yönetilir. SLO ve incident management bulunur. Multi-team adoption ölçülür. Backward compatibility önemlidir. Internal customer feedback roadmap'e girer.

Diyarbakır'daki Yazılım Ekiplerinde CRO Yetkinliği Nasıl Geliştirilir?

CRO ve experimentation yetkinliği yalnız teorik istatistik eğitimiyle gelişmez. Analytics workshop, A/B testing atölyesi, feature flag uygulaması, SQL analizi ve e-ticaret deney projeleri birlikte çalışıldığında öğrenme daha hızlı olur. Gerçek olmayan demo ürün üzerinde A/A ve A/B test kurmak katılımcıların bütün veri akışını görmesini sağlar. Diyarbakır Yazılım Topluluğu'nun yürüttüğü proje yaklaşımını incelemek için https://www.diyarbakiryazilim.com.tr/projects adresi kullanılabilir. Topluluk hakkında daha fazla bilgi için https://www.diyarbakiryazilim.com.tr/about sayfasına göz atabilirsiniz.

Analytics Workshop

Workshop event taxonomy ve funnel analiziyle başlayabilir. Katılımcılar aynı conversion metricini SQL ve analytics aracında hesaplayabilir. Sayıların neden farklılaştığı tartışılır. Source of truth kavramı uygulanır. Son bölümde metric catalog hazırlanabilir.

A/B Testing Atölyesi

Katılımcılar control ve treatment içeren demo deney kurabilir. Sample size planı yapılır. Exposure eventleri incelenir. A/A test üzerinden SRM gösterilebilir. Final result yerine methodology öğrenimine odaklanılır.

Feature Flag Uygulamaları

Basit feature flag service demo projeye entegre edilebilir. Deterministic assignment uygulanır. Progressive rollout ve kill switch denenir. Stale flag cleanup pratiği yapılır. A/B testing ile feature flag farkı gerçek kod üzerinde görülür.

SQL ve Data Analysis

Exposure ve conversion tabloları SQL ile join edilir. User-based conversion hesaplanır. Segment ve guardrail queryleri yazılır. SRM için observed counts çıkarılır. Katılımcılar veri kalitesi kontrollerini öğrenir.

E-Ticaret Deney Projeleri

Demo e-ticaret ürününde product detail veya checkout hipotezi oluşturulabilir. Add to cart secondary, purchase primary metric seçilebilir. Revenue guardrail eklenir. Client ve server assignment farkı karşılaştırılır. Sonuç experiment repositoryye yazılır.

Açık Kaynak Experimentation

Topluluk açık kaynak feature flag veya experiment demo sistemi geliştirebilir. Kod review ile assignment logic tartışılır. Synthetic event generator kullanılır. Privacy-safe demo data oluşturulur. Öğrenimler dokümantasyonla paylaşılır.

Diyarbakır Yazılım Topluluğu İçin Experimentation Lab Modeli

Experimentation Lab modeli katılımcıların theory, coding, analytics ve statistics alanlarını tek proje üzerinde birleştirmesini sağlayabilir. Açık kaynak demo ürün, ortak event schema, feature flag platformu, A/A test ve A/B test aynı laboratuvar içinde kurulabilir. Data analysis workshop sonuçların yorumlanmasını öğretir. Test sonuçlarının toplulukla paylaşılması yalnız kazanan varyantı değil kullanılan metodolojiyi de içermelidir. Böyle bir model junior ve senior geliştiriciler arasında gerçek ürün mühendisliği pratiği oluşturabilir.

Açık Kaynak Demo Ürün

Demo ürün kişisel veri içermeyen synthetic kullanıcılarla çalışabilir. E-ticaret veya SaaS akışı seçilebilir. Source code herkes tarafından incelenebilir. Experiment surface kolayca değiştirilebilir. Eğitim amaçlı safe environment oluşur.

Ortak Event Schema

Page viewed, signup ve purchase gibi eventler standardize edilir. Schema JSON veya typed interface ile tanımlanabilir. Versioning uygulanır. Analytics ve warehouse aynı event contractı kullanır. Katılımcılar measurement foundation önemini öğrenir.

Feature Flag Platformu

Basit flag service deployment kontrolü sağlar. SDK demo web uygulamasına bağlanır. Assignment deterministic hash ile yapılır. Exposure logging ayrı katman olarak eklenir. A/B testing için eksik measurement parçaları görünür olur.

A/A Test

İlk lab deneyi iki aynı varyantla yapılır. Traffic distribution gözlenir. SRM hesaplanır. Event volume karşılaştırılır. Platform health doğrulanmadan gerçek treatment açılmaz.

A/B Test

Gerçek hipotez belirlenir. Sample plan synthetic veya controlled users üzerinde simüle edilir. Treatment uygulanır. Primary ve guardrail metrics analiz edilir. Decision standardı uygulanır.

Data Analysis Workshop

SQL ve Python kullanılarak experiment data analiz edilir. Frequentist ve Bayesian sunum farkı örneklenebilir. Post-hoc segment riskleri gösterilir. Data quality bug senaryoları eklenebilir. Katılımcılar yalnız chart okumak yerine verification yapar.

Sonuçların Toplulukla Paylaşılması

Sunum hipotez, method, result ve learning yapısını izlemelidir. Kaybeden sonuçlar gizlenmemelidir. Code ve anonim data paylaşılabilir. Yeni üyeler geçmiş deneyleri repositoryden inceleyebilir. Topluluk experimentation kültürü kazanır.

AI CRO ve A/B Testing'i Nasıl Değiştiriyor?

AI hipotez üretimi, varyant yazımı, segment keşfi ve experiment summary alanlarında CRO ekiplerini hızlandırabilir. Ancak hızlı varyant üretimi kaliteli deney tasarımıyla aynı şey değildir. Model onlarca alternatif oluşturabilir fakat hangi kullanıcı probleminin çözülmeye değer olduğuna insan ekip karar vermelidir. Segment keşfi exploratory olarak faydalıdır, confirmatory kanıt için yeni deney gerekebilir. AI kullanımında insan kontrolü, privacy ve guardrail kuralları korunmalıdır.

AI ile Hipotez Üretimi

AI research notes ve funnel problemlerinden hipotez fikirleri çıkarabilir. Öneriler evidence yerine geçmez. CRO uzmanı kullanıcı problemi ve business priority ile review yapmalıdır. Çok sayıda düşük kaliteli fikir backlogu doldurmamalıdır. AI brainstorming hızlandırıcı olarak kullanılabilir.

AI ile Varyant Üretimi

Copy ve görsel alternatifleri hızlı üretilebilir. Brand ve accessibility review gereklidir. Her varyant ayrı anlamlı hipotez taşımalıdır. Çok fazla varyant sampleı böler. Üretim hızı experimentation capacityden daha yüksek olabilir.

Segment Keşfi

Model heterogeneity patternlerini bulmaya yardımcı olabilir. Bu analiz post-hoc discovery niteliğindedir. Küçük sample segments false discovery üretebilir. Follow-up confirmatory test planlanmalıdır. Sensitive attributes personalization için dikkatle kullanılmalıdır.

Experiment Summary

AI dashboard metriclerini anlaşılır özetleyebilir. Sayısal değerler kaynak veriden alınmalıdır. SRM veya data quality warning gizlenmemelidir. Karar gerekçesi insan tarafından onaylanmalıdır. Otomatik narrative sonucu abartmamalıdır.

Personalization

AI user behavior prediction ile kişiselleştirme yapabilir. Ancak predicted response causal uplift anlamına gelmez. Randomized holdout gerçek incrementality ölçer. Fairness ve privacy guardrail gerekir. Algorithm performance experimentle doğrulanmalıdır.

İnsan Kontrolü

Business goal, ethics ve user value insan sorumluluğunda kalmalıdır. AI statistical decision rule'u değiştirmemelidir. Experiment owner sonuçları review eder. Data scientist complex claimsleri doğrular. Automation karar kalitesini destekler ama ownershipi ortadan kaldırmaz.

AI Optimizasyonu A/B Testin Yerini Alabilir mi?

AI otomatik optimizasyon bazı use case'lerde daha iyi görünen varyantı hızlı seçebilir, ancak controlled experimentation ihtiyacını ortadan kaldırmaz. Prediction ile causal inference farklı sorulara cevap verir. Model hangi kullanıcıya hangi offerın verileceğini tahmin edebilir, fakat bu offerın gerçekten incremental etki yarattığını ancak uygun deney tasarımı gösterebilir. Black-box kararlar guardrail ve fairness sorunları oluşturabilir. İnsan tarafından belirlenen iş hedefleri ve kontrollü holdout grupları önemini korur.

Prediction ile Causal Inference Farkı

Prediction outcome olasılığını tahmin eder. Causal inference interventionın outcome üzerindeki etkisini sorar. Yüksek purchase propensity user zaten treatment olmadan da satın alabilir. Personalization modeli bunu karıştırabilir. Randomized experiment incremental effecti ölçer.

Otomatik Optimizasyon

AI traffic allocation veya content selection yapabilir. Objective function neyse sistem onu optimize eder. Yanlış metric dark pattern davranışını teşvik edebilir. Guardrails objective yanında bulunmalıdır. Human review model policyyi belirler.

Kontrollü Deney İhtiyacı

Yeni model rolloutunda control holdout gerekir. Revenue, retention ve fairness karşılaştırılır. Model update sonrası effect yeniden ölçülmelidir. Offline evaluation tek başına yeterli değildir. Production causal evidence korunmalıdır.

Black-Box Karar Riski

Model neden belirli offerı seçtiğini açıklamayabilir. Regulatory veya brand risk oluşabilir. Segment fairness monitoring yapılmalıdır. Experiment data karar etkisini görünür kılar. Critical domains stronger governance gerektirir.

Guardrail Metrics

AI objective conversion olsa bile refund, complaint ve retention guardrail olabilir. Technical latency ayrıca izlenmelidir. Guardrail violation rolloutı durdurabilir. Model optimization tek metric üzerinde bırakılmamalıdır. OEC business ve user valueyi dengeler.

İnsan Tarafından Belirlenen İş Hedefleri

Model hangi outcomeun önemli olduğuna karar vermemelidir. Product ve business ekipleri objective seçer. Ethics ve customer trust sınırlarını belirler. Data science measurementı uygular. Experimentation insan hedeflerini güvenilir biçimde test eder.

Kurumsal A/B Testing Workflow'u

Kurumsal workflow problem tanımlamadan documentation ve cleanup aşamasına kadar bütün experiment yaşam döngüsünü standardize eder. Research, hypothesis, prioritization, experiment design, metric definition ve sample plan launch öncesi tamamlanır. Development ve QA sonrasında test başlatılır, monitoring ile data quality izlenir ve analysis sonunda karar verilir. Rollout veya rollback sonrası flag cleanup yapılır. Bu akış deneylerin kişisel alışkanlıklara değil ortak kalite standardına göre yürütülmesini sağlar.

1. Problem Tanımlama

Önce kullanıcı veya business problemi açıkça yazılır. Metric evidence eklenir. Solution henüz sabitlenmez. Problem owner belirlenir. Backlog maddesi oluşturulur.

2. Research

Analytics, usability ve feedback verisi toplanır. Sorunun nedenleri araştırılır. Segment farklılıkları belirlenir. Existing experiment repository aranır. Evidence confidence seviyesi belirlenir.

3. Hypothesis

Değişiklik, population ve expected metric effect yazılır. Mechanism açıklanır. Falsifiable ifade kullanılır. Product ve CRO review yapar. Hipotez test boyunca değişmez.

4. Prioritization

Impact, confidence, effort ve reach değerlendirilir. Risk ve learning value eklenir. Feasibility sample hesabıyla kontrol edilir. High-risk test governance queueya girer. Roadmap sırası belirlenir.

5. Experiment Design

Randomization unit ve traffic split seçilir. Eligibility tanımlanır. Concurrent experiments collision açısından kontrol edilir. Client, server veya hybrid implementation belirlenir. Exposure trigger tanımlanır.

6. Metric Definition

Primary, secondary ve guardrail metrics seçilir. Metric catalog versions kaydedilir. Source of truth belirlenir. Attribution window yazılır. Decision rule metriclerle bağlanır.

7. Sample Size Plan

Baseline, MDE ve power kullanılır. Eligible traffic ile duration tahmini yapılır. Minimum ve maximum test süresi belirlenir. Sequential method varsa stopping rule yazılır. Underpowered test launch edilmez.

8. Development

Control ve treatment code geliştirilir. Feature flag entegrasyonu yapılır. Tracking events eklenir. Automated tests yazılır. Default behavior güvenli tutulur.

9. QA

Assignment, variant ve event QA tamamlanır. Cross-browser ve mobile test yapılır. Performance ve accessibility kontrol edilir. Production debug eventleri doğrulanır. Checklist onaylanır.

10. Launch

Trafik küçük yüzdeyle başlatılabilir. Initial health metrics izlenir. SRM ve error rate kontrol edilir. Sorun yoksa planlanan split'e çıkılır. Launch timestamp repositoryye yazılır.

11. Monitoring

Health dashboard assignment ve exposure izler. Primary outcome erken karar için kullanılmaz. Guardrail violation alarm üretir. Pipeline lag kontrol edilir. Major external events timelinea eklenir.

12. Analysis

Planlanan sample ve duration tamamlanınca result analiz edilir. SRM ve data quality önce kontrol edilir. Primary metric effect ve uncertainty raporlanır. Secondary ve guardrails yorumlanır. Exploratory segments ayrı etiketlenir.

13. Decision

Ship, do not ship, iterate veya inconclusive kararı verilir. Business impact ve risk değerlendirilir. Decision rationale repositoryye yazılır. Stakeholder consensus kaydedilir. Sonuç winner badge'e indirgenmez.

14. Rollout / Rollback

Kazanan treatment progressive rolloutla açılabilir. Guardrails izlenmeye devam eder. Kaybeden treatment kapatılır. Default variant güncellenir. Long-term metric takip planı oluşturulur.

15. Documentation ve Cleanup

Final result, learning ve decision tamamlanır. Eski code path silinir. Feature flag kaldırılır. Experiment config archive edilir. Yeni hipotezler backlog'a eklenir.

Experiment Sonuç Kararları Nasıl Standardize Edilir?

Deney sonucu yalnız “kazandı” veya “kaybetti” biçiminde sınıflandırıldığında birçok önemli durum kaybolur. Ship, Do Not Ship, Iterate and Retest, Inconclusive, Segment-Based Follow-Up ve Long-Term Holdout gibi standart karar türleri daha doğru kurumsal hafıza oluşturur. Kararın gerekçesi statistical result, business impact ve guardrail durumuyla birlikte yazılmalıdır. Pozitif effect her zaman ship anlamına gelmez. Aynı şekilde null result treatment fikrinin sonsuza kadar yanlış olduğu anlamına gelmeyebilir.

Ship

Primary metric business açısından anlamlı olumlu etki gösterir. Guardrails kabul edilebilir durumdadır. Data quality kontrolleri geçmiştir. Rollout risk planı hazırlanır. Long-term monitoring devam eder.

Do Not Ship

Treatment negatif veya anlamsız business outcome üretmiş olabilir. Guardrail ihlali de bu karara yol açabilir. Code path kapatılır. Learning repositoryye yazılır. Hipotez gerekirse yeniden formüle edilir.

Iterate and Retest

Mechanism promising fakat treatment implementation yetersiz olabilir. Secondary metrics bunu gösterebilir. Yeni treatment önemli değişiklik içermelidir. Aynı testi küçük kozmetik farkla tekrar etmek yerine learning kullanılmalıdır. Yeni experiment ID oluşturulur.

Inconclusive

Sample yetersiz veya confidence interval çok geniş olabilir. Data quality sorunu sonucu geçersiz kılabilir. “No effect” demek doğru olmayabilir. Test yeniden çalıştırılabilir veya problem düşük priorityye alınabilir. Repository belirsizliği açıkça saklar.

Segment-Based Follow-Up

Exploratory segmentte farklı effect görülebilir. Doğrudan segment rollout yapılmamalıdır. New confirmatory hypothesis oluşturulur. Segment sample planı yapılır. Personalization opportunity olarak değerlendirilebilir.

Long-Term Holdout

Kısa vadeli primary metric pozitif olabilir. Retention veya revenue effectini görmek için holdout devam eder. Full rollout geciktirilebilir. Long-term result repositoryye eklenir. Özellikle subscription ve recommendation sistemlerinde değerlidir.

Kararın Gerekçelendirilmesi

Decision note yalnız istatistik değerini değil business reasoning'i içerir. MDE altında kalan positive lift ship edilmeyebilir. Engineering complexity veya brand risk hesaba katılabilir. Karar daha sonra review edilebilir. Kurumsal şeffaflık artar.

Test Sonrası Feature Flag Cleanup

Test sonrasında flag ve deney kodunu bırakmak kısa vadede kolay görünür, uzun vadede ciddi technical debt yaratır. Kazanan varyant kalıcı product behavior haline getirilmeli, eski kod silinmeli ve experiment config temizlenmelidir. Flag kaldırılmadığında code path sayısı artar ve gelecekteki debugging zorlaşır. Cleanup Definition of Done içine eklenmelidir. Experiment velocity yüksek organizasyonlarda otomatik stale flag alert sistemi faydalıdır.

Kazanan Varyantın Kalıcı Hale Getirilmesi

Treatment code normal default behaviora dönüştürülür. Experiment evaluation gereksiz hale gelir. Analytics standard events korunabilir. Long-term metric tracking devam eder. Code review kazanan implementationı sadeleştirir.

Eski Kodun Silinmesi

Control path kullanılmıyorsa repositoryden çıkarılır. Dead code bundle ve bakım maliyeti oluşturur. Regression testler yeni defaulta göre güncellenir. Git history geçmiş implementationı zaten korur. Runtime flag için eski kod tutulmamalıdır.

Flag'in Kaldırılması

Flag config platformdan archive edilir. Application reference bulunmadığı doğrulanır. Dashboard active flag count güncellenir. Audit history saklanabilir. Stale flag technical debt azalır.

Experiment Config Temizliği

Traffic rules ve targeting configs kapatılır. Result repositoryde archived state alır. Exposure event generation durdurulur. Metric definitions shared ise korunur. Platform clutter azalır.

Technical Debt Oluşumunun Önlenmesi

Flag expiry date create sırasında belirlenebilir. Cleanup ticket experiment launch ile birlikte açılabilir. CI stale reference check yapabilir. Team KPI active stale flag sayısını izleyebilir. Platform hygiene sürdürülebilir hale gelir.

30 Günlük A/B Test Altyapısı Pilot Planı

İlk 30 günlük pilotun amacı büyük experimentation platformu tamamlamak değil güvenilir bir end-to-end test akışını kanıtlamaktır. İlk hafta event schema, conversion definitions ve identity temeli kurulmalıdır. İkinci hafta feature flag, assignment ve exposure mekanizması devreye alınabilir. Üçüncü hafta A/A testiyle tracking ve SRM doğrulanır. Son hafta düşük riskli gerçek A/B test başlatılarak hypothesis, metric, launch ve analysis süreci uçtan uca test edilir.

1-7. Gün: Measurement Foundation

İlk hafta analytics ve identity temeline ayrılmalıdır. Existing eventler audit edilir. Primary conversion tanımları standardize edilir. Anonymous ve logged-in user davranışı belgelenir. Data source of truth kararı verilir.

Event Schema

Temel funnel eventleri tanımlanır. Naming convention ve properties yazılır. Experiment ID ve variant fields eklenir. Schema validation kurulur. Test eventleri warehouse'a gönderilir.

Conversion Definitions

Purchase, signup veya form conversion açıkça tanımlanır. Numerator ve denominator yazılır. Attribution window seçilir. Source of truth belirlenir. Baseline conversion hesaplanır.

Identity

Anonymous ID ve user ID stratejisi belirlenir. Login merge kuralı yazılır. Privacy review yapılır. Randomization unit seçilir. Test kullanıcıları için debug identity oluşturulur.

8-14. Gün: Platform

İkinci hafta feature delivery ve experimentation plumbing kurulur. Basit flag service veya seçilen platform entegre edilir. Deterministic assignment çalışır. Exposure events oluşturulur. Experiment config management test edilir.

Feature Flag

Control ve treatment flag arkasına alınır. Default value güvenli seçilir. Kill switch denenir. Owner ve expiry date eklenir. Audit log doğrulanır.

Assignment

User ID hash ile varyanta atanır. 50/50 distribution synthetic data üzerinde test edilir. Sticky behavior doğrulanır. Eligibility condition eklenir. Assignment logları izlenir.

Exposure

Exposure doğru component renderında tetiklenir. Assignmenttan ayrıldığı doğrulanır. Duplicate policy uygulanır. Warehouse eventleri kontrol edilir. Dashboard exposure count gösterir.

15-21. Gün: İlk A/A Test

Üçüncü hafta aynı deneyimin iki kopyasıyla A/A test çalıştırılır. Assignment ratio, exposure ve conversion eventleri incelenir. SRM otomatik kontrol edilir. Platform sonucu yanlış winner ilan ediyor mu bakılır. Data quality sorunu bulunursa gerçek A/B teste geçmeden düzeltilir.

Tracking QA

Control ve treatment aynı event hacmine yakın olmalıdır. Conversion definitions tekrar doğrulanır. Identity join kontrol edilir. Pipeline lag ölçülür. Missing event alarms ayarlanır.

Assignment QA

Traffic ratio expected distribution ile karşılaştırılır. Sticky assignment gerçek kullanıcı oturumlarında test edilir. Mobile ve desktop split incelenir. Eligibility leakage var mı bakılır. Hash stability doğrulanır.

SRM

SRM test otomatik çalıştırılır. Threshold methodology documenta eklenir. Alarm kanalı belirlenir. Root cause playbook hazırlanır. A/A sonucunda beklenmeyen sapma varsa pilot durdurulur.

22-30. Gün: İlk A/B Test

Son hafta düşük riskli fakat gerçek business hipotezi seçilir. Sample size planı yapılır. Test launch edilir ve health monitoring çalıştırılır. Pilot süresi tam outcome için yetmezse yalnız platform validation tamamlanır ve sonuç zorla yorumlanmaz. Amaç ilk ayda güvenilir workflow kurmaktır.

Hypothesis

Research veya funnel bulgusu seçilir. Hipotez standard formatta yazılır. Population belirlenir. Evidence kaydedilir. Product owner onay verir.

Metric

Primary ve guardrail metric seçilir. MDE belirlenir. Sample hesaplanır. Source of truth kaydedilir. Dashboard metric spec ile bağlanır.

Launch

QA checklist tamamlanır. Küçük traffic ramp ile başlanır. Health checks gözlenir. Planlanan split'e çıkılır. Launch timestamp repositoryye eklenir.

Analysis

Sample ve minimum duration tamamlanmadan final karar verilmez. Aylık pilot kapanışında health ve data quality review yapılabilir. Tam result daha sonra methodologyye göre değerlendirilir. Repository decision status güncellenir. Pilot öğrenimleri platform roadmap'e eklenir.

90 Günlük Experimentation Programı

İlk 90 gün platformu yalnız kurmak değil repeatable workflow ve governance oluşturmak için kullanılmalıdır. İlk 30 gün measurement foundation, sonraki 30 gün standart süreç ve son 30 gün self-service ile governance geliştirilir. Experiment repository ve dashboard ilk günden itibaren büyütülmelidir. Eğitim product ve engineering ekiplerinin platformu doğru kullanmasını sağlar. 90 gün sonunda amaç onlarca test çalıştırmak değil güvenilir test kapasitesi oluşturmak olmalıdır.

İlk 30 Gün: Foundation

Identity, event schema, assignment ve exposure temeli kurulur. A/A test yapılır. İlk düşük riskli A/B experiment başlatılır. Data quality issues kaydedilir. Pilot success criteria platform reliability odaklıdır.

31-60 Gün: Repeatable Workflow

Hypothesis, sample plan, QA ve decision templates standardize edilir. Birkaç farklı product team test çalıştırır. Experiment collision rules belirlenir. Metric catalog genişletilir. Cleanup workflow uygulanır.

61-90 Gün: Self-Service ve Governance

Low-risk experiments için self-service access açılır. Eğitim ve certification modeli uygulanabilir. High-risk review process belirlenir. SLO ve observability dashboard devreye alınır. Center of Excellence veya platform owner modeli netleşir.

Experiment Repository

Bütün pilot testler structured repositoryde bulunur. Search ve tags eklenir. Result ve learning standard alanlar olur. Duplicate hypothesis detection manuel veya otomatik yapılabilir. Kurumsal hafıza oluşur.

Dashboard

Health ve outcome dashboards ayrılır. SRM, exposure ve pipeline lag görünür olur. Program KPI'ları ayrıca raporlanır. Data freshness açıkça gösterilir. Team filtresi kullanılabilir.

Training

Product teams hipotez ve metric design eğitimi alır. Engineering exposure ve flag lifecycle öğrenir. Analysts methodology standardını uygular. A/A lab pratik sağlar. Documentation gerçek case study ile güncellenir.

A/B Test Altyapısı Kontrol Listesi

Güvenilir A/B test altyapısı randomization, sticky assignment, exposure logging, event schema, source of truth, primary metric, guardrails, sample size, A/A testi, SRM, concurrent experiment management, client ve server-side support, kill switch, privacy, repository ve flag cleanup süreçlerini birlikte yönetmelidir. Bu maddelerden birkaçının eksik olması her testin geçersiz olduğu anlamına gelmez, ancak kurumsal ölçekte risk hızla büyür. Checklist platform selection ve pilot evaluation için kullanılabilir. Özellikle exposure ve data quality konuları araç demosunda gözden kaçırılmamalıdır. Teknik platformun amacı test açmak değil doğru karar üretmektir.

Randomization doğru mu?

Hash ve traffic split test edilmelidir. Randomization unit ürüne uygun olmalıdır. SRM health check bulunmalıdır. Segment bias kontrol edilir. A/A deneyleri düzenli yapılabilir.

Assignment sticky mi?

Kullanıcı sessionlar arasında aynı varyantı görmelidir. Identity merge kuralı bulunur. Cookie loss riski bilinir. Server identity desteklenebilir. Assignment algorithm upgrade stability korunur.

Exposure loglanıyor mu?

Assignment ve exposure ayrı events olmalıdır. Exposure trigger doğru anda çalışmalıdır. Duplicate policy bulunmalıdır. Raw event export mümkün olmalıdır. Missing exposure monitoring yapılmalıdır.

Event schema standart mı?

Event names ortak taxonomy izlemelidir. Properties types tanımlanır. Versioning uygulanır. Data catalog bulunur. Tracking QA launch öncesi yapılır.

Source of truth belli mi?

Her metric authoritative data source taşır. Analytics ve finance farkları belgelenir. Warehouse join rules versionlanır. Data freshness görünürdür. Karar aynı metric definition üzerinden yapılır.

Primary metric önceden tanımlanıyor mu?

Experiment brief primary metric içerir. Test başladıktan sonra değiştirilmez. Hipotezle uyumludur. Metric version kaydedilir. Decision rule buna bağlanır.

Guardrail metric var mı?

Riskli testlerde teknik ve business guardrails bulunur. Thresholdlar önceden belirlenir. Alerting entegre edilir. Violation stop rule oluşturabilir. Long-term guardrails ayrıca izlenebilir.

Sample size planlanıyor mu?

Baseline ve MDE kullanılır. Power standardı vardır. Eligible traffic üzerinden duration hesaplanır. Minimum test süresi tanımlanır. Underpowered tests açıkça işaretlenir.

A/A testi yapıldı mı?

Platform launch öncesi A/A önerilir. Assignment ve tracking doğrulanır. False positive davranışı gözlenir. SDK değişikliği sonrası tekrar yapılabilir. Sonuç repositoryde saklanır.

SRM kontrolü var mı?

Expected ve actual traffic ratio otomatik karşılaştırılır. Assignment ve exposure seviyeleri ayrılabilir. Alert sistemi bulunur. Root cause playbook hazırlanır. SRM varken outcome decision bloklanır.

Eş zamanlı experiment'lar yönetiliyor mu?

Experiment layers ve collision rules tanımlanır. High-risk tests mutual exclusion kullanabilir. Orthogonal tests parallel çalışır. Overlap metadata saklanır. Interaction exploratory olarak izlenebilir.

Client ve server-side destek var mı?

Web UI tests client side olabilir. Backend logic için server SDK gerekir. Shared experiment ID kullanılabilir. Hybrid pattern desteklenebilir. Tek platform bütün use caseleri karşılamıyorsa integration strategy oluşturulur.

Kill switch mevcut mu?

Riskli treatment anında kapatılabilir. On-call erişimi bulunur. Default variant güvenlidir. Audit log tutulur. Kill switch cache propagation test edilir.

Data privacy kuralları tanımlı mı?

PII minimization uygulanır. Consent davranışı belgelenir. Retention policy vardır. Third-party vendor assessment yapılır. User deletion workflow desteklenir.

Experiment repository mevcut mu?

Hypothesis, metrics, result ve learning kaydedilir. Kazanan ve kaybeden testler birlikte saklanır. Search ve tags bulunur. Decision rationale görünürdür. Long-term metric updates yapılabilir.

Flag cleanup süreci var mı?

Kazanan rollout sonrası control code silinir. Flag archive edilir. Expiry reminders bulunur. Stale flag metric izlenir. Cleanup Definition of Done içine dahildir.

Sıkça Sorulan Sorular

CRO nedir?

CRO, mevcut kullanıcı trafiği içindeki değerli dönüşümlerin oranını sistematik biçimde geliştirme sürecidir. Kullanıcı araştırması, analytics, funnel analizi ve kontrollü deneyler birlikte kullanılabilir. CRO yalnız daha fazla buton tıklaması üretmek değildir. Purchase, signup, revenue veya retention gibi gerçek iş metricleri önemlidir. En iyi sonuç sürekli öğrenme ve ölçüm kültürüyle elde edilir.

A/B testi nedir?

A/B testi kullanıcıların random biçimde control ve treatment gruplarına ayrıldığı kontrollü deneydir. Varyantlar arasında primary metric farkı ölçülür. Randomization nedensel yorum yapmayı kolaylaştırır. Sample size ve test süresi önceden planlanmalıdır. Tracking veya SRM problemi varsa sonuç güvenilir kabul edilmemelidir.

CRO ile A/B testing arasındaki fark nedir?

CRO daha geniş optimizasyon pratiğidir. A/B testing CRO içinde kullanılan deney yöntemlerinden biridir. CRO research ve usability çalışmalarını da kapsar. Düşük traffic sitelerde A/B testi yapılmadan da CRO çalışması yürütülebilir. Experimentation ise kontrollü öğrenmeyi ürün geliştirmeye sistematik biçimde bağlar.

A/B test altyapısı nasıl kurulur?

Önce identity, event schema ve conversion definitions hazırlanmalıdır. Ardından assignment, feature flag ve exposure logging katmanları kurulmalıdır. Data warehouse veya analytics sistemi conversion eventlerini exposure ile birleştirir. Metrics ve statistical engine sonucu hesaplar. Platform gerçek teste geçmeden A/A experiment ile doğrulanmalıdır.

Feature flag ile A/B test arasındaki fark nedir?

Feature flag özelliğin kimlere açık olduğunu kontrol eder. A/B test ise random gruplar arasında outcome farkını ölçer. Flag deney delivery katmanı olabilir. Exposure, metrics ve statistical analysis olmadan tek başına experimentation değildir. Olgun platformlar iki yeteneği birlikte kullanır.

Client-side mı server-side A/B test mi kullanılmalı?

Basit copy ve layout testlerinde client-side hızlıdır. Pricing, checkout veya API logic için server-side daha güvenilir olabilir. Client-side flicker ve performance riski taşır. Server-side engineering effort gerektirir. Hybrid model birçok kurumsal üründe dengeli çözüm sağlar.

A/A test nedir?

A/A test iki random gruba aynı deneyimi gösterir. Amaç assignment ve tracking altyapısını doğrulamaktır. SRM ve false positive davranışı izlenebilir. Gerçek treatment etkisi beklenmez. Yeni experimentation platformlarında önemli kalite testidir.

A/B test için kaç kullanıcı gerekir?

Tek bir evrensel kullanıcı sayısı yoktur. Baseline conversion rate, MDE, statistical power ve varyant sayısı sample ihtiyacını belirler. Düşük effecti ölçmek daha fazla kullanıcı gerektirir. Eligible traffic toplam site trafiğinden farklı olabilir. Sample calculator launch öncesi kullanılmalıdır.

MDE nedir?

Minimum Detectable Effect testin tespit etmek için tasarlandığı en küçük anlamlı etkidir. MDE business kararıdır. Çok küçük MDE sample ihtiyacını büyütür. Product ve finance ekipleri karar değerini belirleyebilir. MDE ROI ile ilişkilendirilmelidir.

A/B test ne kadar süre çalıştırılmalıdır?

Test planlanan sample ve minimum duration tamamlanana kadar çalışmalıdır. En az tam haftalık kullanıcı döngüsü birçok web ürününde anlamlıdır. Seasonality ve purchase cycle dikkate alınır. Tek bir sabit süre bütün testlere uymaz. Sequential methodology kullanılıyorsa özel stopping rule uygulanır.

Test erken durdurulabilir mi?

Klasik fixed-horizon testte yalnız “kazanan göründü” diye erken durdurmak risklidir. Peeking false positive ihtimalini artırabilir. Sequential testing kontrollü early stop sağlayabilir. Platformun methodology desteği açık olmalıdır. Decision rule test başlamadan önce yazılmalıdır.

Sample Ratio Mismatch nedir?

SRM expected ve actual varyant dağılımı arasında beklenmeyen sapmadır. Assignment veya exposure problemi gösterebilir. Tracking bugı da neden olabilir. SRM bulunan deneyde outcome sonucuna güvenmek risklidir. Root cause çözülmeden final decision verilmemelidir.

Aynı anda birden fazla A/B test yapılabilir mi?

Evet, olgun experimentation programları birçok testi eş zamanlı çalıştırabilir. Her testin birbirini etkilemesi gerekmez. Aynı product surface üzerindeki yüksek interaction riskli deneyler mutually exclusive group kullanabilir. Namespace ve layers traffic allocationı yönetir. Tamamen seri test yapmak program hızını gereksiz düşürebilir.

Guardrail metric nedir?

Guardrail treatment primary metric kazanırken başka önemli alanı bozup bozmadığını kontrol eder. Error rate, performance, refund veya retention örnek olabilir. Threshold launch öncesi belirlenir. İhlal rolloutı durdurabilir. Kullanıcı ve iş kalitesini korur.

GA4 ile A/B testing yapılabilir mi?

GA4 experiment assignment ve conversion analizine destek verebilir. Variant property ve conversion eventleri analytics içinde segmentlenebilir. Ancak GA4 tek başına assignment, sticky randomization ve statistical experiment engine değildir. Data warehouse export daha ayrıntılı analiz sağlar. Ayrı experimentation platformuyla entegre kullanılması daha güçlüdür.

Açık kaynak A/B testing araçları kullanılabilir mi?

Evet, açık kaynak platformlar kullanılabilir. Maintenance, lisans, assignment stability ve statistical methodology incelenmelidir. Self-hosting operasyon maliyeti oluşturur. Raw data ownership avantaj sağlayabilir. A/A test production readiness doğrulamak için kullanılmalıdır.

Kendi experimentation altyapımızı kurmalı mıyız?

Bu karar ürün ölçeği ve engineering kapasitesine bağlıdır. Büyük organizasyon özel metrics ve identity ihtiyaçları nedeniyle in-house platformdan fayda görebilir. Küçük ekiplerde SaaS veya açık kaynak çözüm daha hızlı değer sağlar. Statistical ve maintenance maliyeti hesaplanmalıdır. Build vs buy total cost üzerinden değerlendirilmelidir.

A/B testing için en iyi programlama dili hangisidir?

Tek bir en iyi dil yoktur. JavaScript browser-side, mevcut backend dili server-side, SQL warehouse analysis ve Python statistical analysis için güçlüdür. Assignment stability ve data correctness dilden daha önemlidir. SDK coverage teknoloji seçimini etkiler. Ekip mevcut stackini değiştirmek zorunda değildir.

Düşük trafikli sitelerde A/B test yapılabilir mi?

Yapılabilir fakat küçük effectleri tespit etmek uzun sürebilir. Feasibility sample size hesabıyla kontrol edilmelidir. Büyük effectli hipotezlere odaklanmak daha verimli olabilir. User research ve usability testing CRO çalışmalarını destekler. Bazı durumlarda A/B test yapmamak daha doğru karardır.

AI A/B testing'in yerini alabilir mi?

AI hipotez ve varyant üretimini hızlandırabilir. Personalization ve traffic optimization yapabilir. Ancak prediction causal effect ölçümüyle aynı değildir. Randomized holdout yeni algoritmanın gerçek incrementality etkisini göstermeye devam eder. İnsan tarafından belirlenen iş hedefleri, ethics ve guardrails önemini korur.

Ek Sık Sorulan Sorular

Dönüşüm oranı optimizasyonunda (CRO) A/B testleri nasıl uygulanır?

Önce kullanıcı veya funnel problemi veriye dayalı biçimde tanımlanmalıdır. Ardından falsifiable hipotez, target population, primary metric, guardrail metrics ve sample size planı hazırlanır. Kullanıcılar güvenilir randomization mekanizmasıyla control ve treatment gruplarına ayrılır ve gerçek varyant görünümü exposure event olarak kaydedilir. Planlanan süre tamamlandıktan sonra data quality, SRM ve statistical result birlikte değerlendirilir. Sonuç yalnız kazanan varyant seçmek için değil kullanıcı davranışı hakkında öğrenme üretmek için experiment repository içinde saklanmalıdır.

A/B test altyapısı kurulurken hangi araçlar ve teknik gereksinimler kullanılmalıdır?

Temel ihtiyaçlar identity, assignment, sticky bucketing, feature delivery, exposure logging, event collection, metrics engine ve statistical analysis katmanlarıdır. Client-side ve server-side SDK desteği ürün mimarisine göre seçilmelidir. Data warehouse integration, raw data export, SRM detection, kill switch ve observability kurumsal kullanımda önemli hale gelir. Araç seçerken yalnız visual editor değil methodology, privacy ve reliability de incelenmelidir. Platform satın alınsa bile event schema ve source of truth kurum tarafından açıkça tanımlanmalıdır.

A/B testlerinde örneklem büyüklüğü, test süresi ve istatistiksel anlamlılık nasıl belirlenir?

Örneklem büyüklüğü baseline conversion, Minimum Detectable Effect, hedef statistical power ve hata toleransına göre hesaplanmalıdır. Trafik yalnız toplam site ziyaretçisi değil eligible ve exposed population üzerinden değerlendirilmelidir. Test sample dolana ve önceden tanımlanan minimum süre tamamlanana kadar çalıştırılmalıdır. Frequentist veya Bayesian metodoloji seçilebilir, ancak decision rule test başlamadan önce belirlenmelidir. Sürekli sonucu kontrol edip “kazanan görünüyor” diye erken durdurmak kullanılan metodoloji bunu özel olarak desteklemiyorsa güvenilirliği azaltabilir.

CRO çalışmalarında hangi sayfa öğeleri ve dönüşüm metrikleri A/B testine dahil edilmelidir?

Başlık, CTA, form yapısı, hero alanı, ürün sayfası, checkout, onboarding, pricing ve recommendation gibi kullanıcı kararını etkileyen alanlar test edilebilir. Her değişikliğin test edilmesi gerekmez ve kritik bug veya accessibility fix doğrudan uygulanabilir. Metric seçimi değişikliğin gerçek iş hedefiyle uyumlu olmalıdır. Purchase conversion, revenue per user, signup, qualified lead ve activation primary metric olabilirken funnel steps secondary metric olarak kullanılabilir. Page speed, error, refund, cancellation ve retention gibi guardrails treatmentın başka alanlarda zarar üretmesini önlemeye yardımcı olur.

CRO ve A/B test altyapısı kurulumu konusunda yakınımda danışmanlık veya eğitim nerede bulabilirim?

CRO ve A/B test optimizasyonu danışmanlığı yakınımda şeklinde araştırma yaparken yalnız landing page varyantı hazırlayan bir hizmet yerine measurement, randomization, exposure, statistics ve governance katmanlarını birlikte değerlendiren yaklaşım aramak daha yararlıdır. Diyarbakır Yazılım Topluluğu'nun çalışmaları ve topluluk yapısı hakkında bilgi için https://www.diyarbakiryazilim.com.tr/about adresini inceleyebilirsiniz. Proje örnekleri için https://www.diyarbakiryazilim.com.tr/projects sayfasına bakabilirsiniz. Kurumsal CRO ve A/B test altyapısı kurulum hizmeti değerlendirilirken A/A testi, event QA, SRM kontrolü, data privacy ve flag cleanup gibi süreçlerin kapsamda olup olmadığını özellikle sormak gerekir. Böylece yalnız test açabilen değil güvenilir deney sonuçları üretebilen bir sistem kurabilirsiniz.

Sonuç: Dönüşüm Oranı Optimizasyonu (CRO) A/B Test Altyapıları Tek Bir Test Aracından Daha Fazlasıdır

Dönüşüm Oranı Optimizasyonu (CRO) A/B Test Altyapıları, iki tasarım hazırlayıp hangisinin daha fazla tıklama aldığını görmekten çok daha geniş bir mühendislik ve ürün yönetimi konusudur. Güvenilir sistemde identity, randomization, sticky assignment, exposure logging, event tracking, metric definitions, sample planning, statistics, QA, observability ve governance aynı yaşam döngüsünün parçalarıdır. Client-side testler hız sağlarken server-side deneyler kritik business logic için daha güçlü kontrol sunabilir ve birçok kurum hybrid modelden fayda görebilir. En olgun CRO programı yalnız kazanan deney sayısını değil incremental value, learning quality, data quality ve kullanıcı güvenini birlikte optimize eder. Experimentation altyapısı, CRO çalışmaları ve uygulamalı yazılım projeleri hakkında toplulukla bağlantı kurmak için https://www.diyarbakiryazilim.com.tr adresini ziyaret edebilirsiniz.