Mobil A/B Test Altyapısı: Kurulum, İstatistik ve Tuzaklar

Mobil uygulamada A/B test kurmak, web tarafında alıştığın deneyden köklü biçimde farklıdır: kod dağıtımı anlık değildir; örneklem hesaplarken karşına mağaza inceleme süresi ve sürüm parçalanması çıkar. Bu yazıda mobil A/B testin web'den dört temel farkını, sunucu-taraflı bayrak ile mağaza deneyi arasındaki seçimi, örneklem büyüklüğü hesabını ve deney kaydı disiplinini adım adım kuruyoruz — mobil a/b test altyapısı kurarken karşılaşacağın gerçek tuzaklarla birlikte.

💡 Pro Tip: Deneyi kurmadan önce "hangi metrik birincil karar metriğim?" sorusuna tek cümlelik bir cevap yaz ve deney boyunca değiştirme — vekil metrik peşinde koşmak, mobil testlerde en sık görülen sonuç çarpıtma sebebidir.

İçindekiler

• Mobil A/B testin web'den dört farkı
• Sunucu-taraflı bayrak mı, mağaza deneyi mi
• Örneklem büyüklüğü ve süre hesabı
• Sürüm dağılımı ve kohort kirlenmesi
• Erken durdurma ve çoklu karşılaştırma tuzağı
• Metrik seçimi: vekil metrik nasıl yanıltır
• Deney kaydı ve karar defteri
• SSS
• Mobil uygulamada A/B test nasıl kurulur?
• Kaç kullanıcıyla anlamlı sonuç alınır?
• Sürüm dağılımı test sonucunu nasıl bozar?
• Sunucu-taraflı bayrak ile mağaza deneyi aynı anda kullanılabilir mi?
• Erken durdurma neden riskli?
• Güncelleme (Eylül 2026)
• Sonuç
• Kaynaklar

Mobil A/B testin web'den dört farkı

Web'de bir deney değişkenini değiştirip dakikalar içinde trafiğin tamamına yayabilirsin. Mobilde durum farklı işler, çünkü dört yapısal kısıt araya girer:

• Dağıtım gecikmesi: İstemci-taraflı bir kod değişikliği mağaza incelemesinden geçmek zorunda; bu da deneyin "anlık" değil "kademeli" yayılması anlamına gelir.
• Sürüm parçalanması: Kullanıcı tabanın aynı anda birden fazla uygulama sürümünde dağılır; bir deney yalnızca belirli bir minimum sürümü çalıştıran kullanıcılarda anlamlıdır.
• Offline/senkron gecikmesi: Mobil istemci deney atamasını (variant assignment) her zaman anlık sunucudan çekemez; önbelleğe alınmış eski atama, kullanıcıyı yanlış kohortta bırakabilir.
• Platform mağaza kuralları: Apple ve Google, mağaza sayfası düzeyindeki deneyleri (creative/metadata) kendi araçları üzerinden sınırlandırır; bunlar uygulama-içi davranış deneyinden ayrı bir rejime tabidir.

Bu dört kısıt, mobil A/B test altyapısını kurarken "hangi katmanda deney yapıyorum?" sorusunu netleştirmeyi zorunlu kılar: uygulama içi davranış mı, yoksa mağaza sayfası mı?

Web tarafında alışılmış bir diğer varsayım da "kullanıcı her seferinde aynı sekmeyi açar" fikridir; mobilde kullanıcı uygulamayı kapatıp günler sonra tekrar açabilir, arada işletim sistemi güncellemesi, ağ değişimi (wifi'den mobil veriye geçiş) veya cihaz değişimi yaşanabilir. Bu yüzden deney atamasının kalıcılığı (persistence) mobilde web'den daha kritik bir mühendislik sorunudur: atamayı yalnızca bellekte tutarsan, uygulama arka plana atıldığında veya işletim sistemi belleği geri aldığında kullanıcı yeniden atanabilir ve deney içi tutarlılık bozulur. Bu nedenle varyant ataması ya cihazda kalıcı depoya (örn. Keychain/UserDefaults, Android'de SharedPreferences/DataStore) yazılmalı ya da ileride anlatacağımız deterministik hash yöntemiyle her seferinde aynı sonucu üretecek şekilde hesaplanmalıdır — ikisinin birleşimi en güvenli yoldur: hash ile hesapla, sonucu cihaza yaz, bir sonraki açılışta önce cihazdaki kayda bak.

Sunucu-taraflı bayrak mı, mağaza deneyi mi

İki farklı deney türünü karıştırmak, mobil A/B testte en yaygın tasarım hatasıdır.

Sunucu-taraflı bayrak (server-side flag) deneyleri, uygulama zaten kullanıcının cihazında kuruluyken davranış veya arayüz farkını uzaktan açıp kapatır. Firebase Remote Config bu modelin yaygın örneğidir: hedef metrik bir Analytics event'i ya da bir dönüşüm hunisi (conversion funnel) olabilir; hedef kullanıcı grubu birden fazla kritere "AND" mantığıyla zincirlenerek tanımlanır ve hedef metrik yanında crash-free oranı, retention ve gelir gibi ikincil metrikler paralel izlenebilir — platform deneyi izlerken hedefe en çok yaklaşan varyantı "leader" olarak işaretler.

Mağaza deneyi (store-level experiment) Apple tarafında iki ayrı araçla yapılır ve bunları karıştırmamak gerekir. Product Page Optimization (PPO) gerçek bir A/B testidir: orijinal sayfaya karşı en fazla üç alternatif ikon/ekran görüntüsü/önizleme kombinasyonu (treatment) test edilebilir, trafiğin ayrılan yüzdesi treatment'lar arasında eşit bölüşülür (örn. trafiğin %40'ını iki treatment'a ayırırsan her biri toplam trafiğin %20'sini, orijinal sayfa kalan %60'ı alır) ve test 90 gün sürer ya da manuel durdurulana kadar devam eder.

Custom Product Pages (CPP) ise A/B testi değildir — kendi URL'i olan, App Store dışına (reklam, sosyal medya, e-posta) yönlendirmek için kullanılan alternatif mağaza sayfalarıdır; uygulama başına en fazla 35 aktif CPP oluşturulabilir. Google Play tarafındaki karşılığı Store Listing Experiments'tir. Her iki durumda da test edilen şey uygulamanın kendisi değil, mağaza sayfasının metadata'sı ve görselleridir (ikon, ekran görüntüsü, başlık, açıklama) — kullanıcı uygulamayı henüz indirmeden önceki dönüşüm huninin bir parçasıdır.

Bu iki türü aynı deney panosunda karıştırmak, "hangi değişiklik hangi metriği etkiledi?" sorusunu cevapsız bırakır — her ikisi için ayrı deney kaydı tutman gerekir.

Pratikte üçüncü bir ara katman daha var: build-time A/B (derleme-zamanı deney). Bazı ekipler, sunucu-taraflı bayrak altyapısı henüz kurulmamışken iki ayrı build (control/treatment) üretip mağazaya kademeli olarak yayınlar (örn. faz'lı rollout yüzdesiyle). Bu yöntem çalışır ama iki dezavantajı vardır: birincisi, mağaza incelemesi her varyant için ayrı ayrı geçilmesi gerektiğinden deney başlatma gecikmesi katlanır; ikincisi, deneyi durdurmak da yeni bir mağaza incelemesi gerektirir, yani "kötü sonuç veren varyantı hemen kapat" refleksi mobilde web'deki gibi anlık çalışmaz.

Sunucu-taraflı bayrak bu ikinci sorunu tamamen ortadan kaldırır: kötü giden bir deneyi durdurmak için tek gereken sunucudaki koşulu değiştirmektir, yeni bir build göndermek değil. Bu yüzden yeni bir mobil deney altyapısı kuruyorsan, önceliği sunucu-taraflı bayrağa ver; mağaza deneyini yalnızca gerçekten mağaza sayfası metadata'sını test ediyorsan kullan.

Örneklem büyüklüğü ve süre hesabı

Mobilde örneklem hesabı web'dekiyle aynı istatistiksel temele dayanır, ama pratik kısıtlar (günlük aktif kullanıcı sayısı, sürüm benimseme hızı) hesaplamayı daha sıkı hale getirir.

Standart iki-oranlı test için gereken örneklem büyüklüğü formülü:

1n = ( (Z_α/2 + Z_β)^2 × (p1×(1-p1) + p2×(1-p2)) ) / (p1 - p2)^2

Burada Z_α/2 anlamlılık eşiğine (genelde %95 güven için 1.96), Z_β istatistiksel güce (genelde %80 güç için 0.84) karşılık gelir; p1 kontrol grubunun temel dönüşüm oranı, p2 ise beklenen yeni oran, (p1-p2) de tespit etmek istediğin minimum fark (minimum detectable effect).

Somut bir örnek: kontrol grubu dönüşümü %10 (p1=0.10), beklenen iyileşme 2 puan (p2=0.12) ise:

1import math
2 
3z_alpha = 1.96  # %95 güven
4z_beta = 0.84   # %80 güç
5p1, p2 = 0.10, 0.12
6 
7numerator = (z_alpha + z_beta) ** 2 * (p1 * (1 - p1) + p2 * (1 - p2))
8denominator = (p1 - p2) ** 2
9n_per_group = math.ceil(numerator / denominator)
10print(n_per_group)  # 3834

Bu hesap grup başına ~3.834 kullanıcı gerektirir (toplam ~7.668). Mobilde asıl mesele bu sayıya _ulaşmak_ değil, bu sayıya hangi sürüm karışımında ulaşacağın: yeni bir davranış deneyi yalnızca deneyi taşıyan minimum sürümü çalıştıran kullanıcılarda anlamlıdır, dolayısıyla günlük "uygun" kullanıcı havuzun DAU'nun tamamı değil, o sürüm eşiğini geçmiş alt kümesidir. Sürüm benimseme hızı yavaşsa, deney süresi örneklem büyüklüğünden değil sürüm yayılım eğrisinden belirlenir.

Deney süresini kabaca kestirmek için basit bir bölme yeterli: gereken_gün ≈ gereken_toplam_örneklem / (günlük_uygun_kullanıcı × trafik_bölüştürme_oranı). Örneğin günde 5.000 kullanıcı uygun sürümde uygulamayı açıyorsa ve trafiğin tamamını deneye ayırıyorsan, ~7.668 kullanıcıya ulaşmak yaklaşık 1,5 gün sürer; ama uygun sürümdeki kullanıcı oranı DAU'nun yalnızca %20'siyse (sürüm henüz yeterince yayılmamışsa, yani günlük uygun havuz 1.000'e düşerse) aynı hesap ~7,7 güne çıkar. Bu yüzden deney planlarken "kaç gün sürecek?" sorusuna cevap verirken sürüm benimseme eğrisini (adoption curve) mutlaka örneklem hesabına dahil et; aksi halde deneyin "istatistiksel olarak yeterli" göründüğü gün aslında hâlâ dar bir sürüm dilimini temsil ediyor olabilir ve sonucu tüm kullanıcı tabanına genellemek yanıltıcı olur.

Ayrıca güç analizini yalnızca deney başında değil, deney ilerledikçe de gözden geçirmek gerekir: eğer gerçekleşen dönüşüm oranı (p1) hesapladığın varsayımdan belirgin şekilde sapıyorsa, orijinal örneklem hesabı artık geçerli değildir ve deneyin planlanan süresi yeniden hesaplanmalıdır — bu yeniden hesaplama deneyi "erken durdurma" anlamına gelmez, çünkü anlamlılık testi yapılmıyor, yalnızca planlama varsayımı güncelleniyor.

Sürüm dağılımı ve kohort kirlenmesi

Android ekosistemi tek bir "güncel sürüm" varsayımını web'den daha fazla zorlar: kullanıcı tabanı aynı anda çok sayıda OS ve uygulama sürümüne yayılmış durumdadır. Bu, deneyine iki şekilde sızar:

• Kohort kirlenmesi: Deney başladıktan sonra bir kullanıcı uygulamayı günceller ve farklı bir kod yoluna girerse, o kullanıcının önceki ölçümleri artık hangi varyanta ait olduğu belirsizleşir. Çözüm: kullanıcıyı ilk atandığı varyanta "sabitle" (sticky assignment) ve sürüm güncellemesi deney bitene kadar varyantı değiştirmesin.
• Sürüme göre stratifikasyon: Yeni bir davranışı yalnızca minimum sürüm N ve üzeri çalıştırabiliyorsa, kontrol ve deney gruplarını rastgele ayırmadan önce "uygun sürüm" filtresini uygula — aksi halde eski sürümdeki kullanıcılar deney havuzuna hiç girmemiş gibi görünüp örneklem hesabını saptırır.

1import CryptoKit
2import Foundation
3 
4// Sürüm eşiği + sticky assignment iskeleti (basitleştirilmiş)
5struct ExperimentGate {
6    let minimumBuildNumber: Int
7    let currentBuildNumber: Int
8 
9    var isEligible: Bool {
10        currentBuildNumber >= minimumBuildNumber
11    }
12}
13 
14func stickyVariant(for userId: String, salt: String) -> String {
15    // Kullanıcı + deney tuzu SHA-256 ile hash'lenir. Swift'in yerleşik
16    // hashValue'su süreçler arası SABİT DEĞİLDİR (Apple: "Hasher is usually
17    // randomly seeded ... will return different values on every new
18    // execution of your program"), bu yüzden sticky assignment için
19    // kullanılamaz; SHA-256 çıktısı ise deterministiktir ve uygulama
20    // yeniden başlatıldığında da aynı sonucu üretir.
21    let hashInput = "\(userId)-\(salt)"
22    let digest = SHA256.hash(data: Data(hashInput.utf8))
23    let bytes = Array(digest)  // SHA256Digest bir Sequence'tır, Collection değil
24    let value = (UInt32(bytes[0]) << 24) | (UInt32(bytes[1]) << 16) | (UInt32(bytes[2]) << 8) | UInt32(bytes[3])
25    let bucket = Int(value % 100)
26    return bucket < 50 ? "control" : "treatment"
27}

Erken durdurma ve çoklu karşılaştırma tuzağı

Deney panoları deney sürerken canlı p-değeri gösterdiğinde, bu ekiplerin "anlamlı görününce" deneyi erken durdurma isteğini tetikler. Sorun şu: sabit örneklem için hesaplanmış bir anlamlılık eşiği (α=0.05), deneyi her gün tekrar tekrar kontrol edip "anlamlı çıkınca dur" mantığıyla kullanıldığında yanlış-pozitif oranını hesapta olduğundan çok daha yükseğe taşır. Bu, istatistik literatüründe "tekrarlanan anlamlılık testi" (repeated significance testing) sorunu olarak bilinir.

İkinci tuzak çoklu karşılaştırmadır: aynı deneyde birden fazla metriği (dönüşüm, retention, oturum süresi, gelir) aynı anda test edip "hangisi anlamlı çıkarsa onu raporla" yaklaşımı, tesadüfen anlamlı görünen bir metriği gerçek etki sanmana yol açar. Önlem:

• Birincil metriği deneyden ÖNCE tek cümleyle yaz ve deney kartına ekle; deney bitince değiştirme.
• Erken durdurma gerekiyorsa, sabit-örneklem yöntemi yerine sequential testing (ardışık test) yöntemi kullanan bir platforma geç — bu yöntemler sürekli izlemeye izin verirken yanlış-pozitif oranını kontrol altında tutacak şekilde tasarlanmıştır.
• İkincil metrikleri "keşifsel" olarak etiketle; onlardan çıkan sonuçları yeni bir deneyle doğrulamadan karar defterine "kanıtlanmış" olarak yazma.

Metrik seçimi: vekil metrik nasıl yanıltır

Vekil metrik (proxy metric), asıl önemsediğin sonucu (örn. 30 günlük retention) ölçmek uzun sürdüğü için onun yerine kullandığın, daha erken gözlemlenebilen bir göstergedir (örn. ilk oturumda tamamlanan onboarding adımı). Sorun, vekil metrik ile asıl metrik arasındaki korelasyonun deney varyantları arasında farklı olabilmesidir.

Somut senaryo: bir onboarding deneyinde treatment grubu "ilk oturum tamamlama oranını" kontrol grubuna göre yükseltiyor görünebilir, ama bu artış agresif bir bildirim izni istemi yüzünden gerçekleşmişse, aynı kullanıcılar birkaç gün içinde bildirimleri kapatıp uygulamayı daha az kullanabilir. Vekil metrik "iyileşti" derken asıl metrik (retention) kötüleşmiş olabilir.

• Vekil metrik seçerken geçmiş verinle (deney dışı) vekil-asıl korelasyonunu önceden doğrula; bu korelasyon deney başladıktan sonra kontrol edilemez.
• Uzun vadeli metriği mutlaka paralel izle, vekil metriğe göre karar verip deneyi kapatsan bile.
• Vekil metrik "iyileşti" ama mekanizması açıklanamıyorsa (neden iyileşti sorusuna cevap yoksa), kararı ertele.

Vekil metrik seçimini kod düzeyinde de görünür kılmak faydalıdır: metriği hesaplayan sorguya veya event tanımına, hangi asıl metriğin vekili olduğunu ve doğrulama tarihini not düşmek, aylar sonra "bu metrik neden burada?" sorusunu tekrar sormanı önler.

1// Android: sürüm eşiği + deney havuzu filtresi (basitleştirilmiş)
2data class ExperimentGate(
3    val minimumVersionCode: Int,
4    val currentVersionCode: Int,
5) {
6    val isEligible: Boolean
7        get() = currentVersionCode >= minimumVersionCode
8}
9 
10fun stickyVariant(userId: String, experimentSalt: String): String {
11    // userId + tuz birlikte hash'lenir; sürüm güncellemesi
12    // veya uygulama yeniden başlatma bu sonucu değiştirmez.
13    val input = "$userId-$experimentSalt"
14    val bucket = Math.floorMod(input.hashCode(), 100)
15    return if (bucket < 50) "control" else "treatment"
16}

Deney kaydı ve karar defteri

Deney sayısı arttıkça, "bu metrik neden değişti, hangi deneyden?" sorusu ekip hafızasına değil yazılı kayda dayanmalı. Minimum bir deney kaydı şu alanları içermeli:

• Deney adı ve hipotez: tek cümlelik, ölçülebilir hipotez.
• Birincil metrik ve minimum tespit edilebilir etki (MDE): deney başlamadan sabitlenmiş.
• Hedef kohort ve minimum sürüm: hangi kullanıcı alt kümesi uygun.
• Başlangıç/bitiş tarihi ve örneklem hesabı: ne kadar süreceği, kaç kullanıcı gerektiği.
• Sonuç ve karar: anlamlı mı, uygulamaya alındı mı, alınmadıysa neden.

1{
2  "experimentId": "onboarding-single-step-2024q4",
3  "hypothesis": "Onboarding'i 3 adımdan 1 adıma indirmek ilk-oturum tamamlama oranını artırır",
4  "primaryMetric": "day1_activation_rate",
5  "minimumDetectableEffect": 0.02,
6  "targetCohort": { "minBuildNumber": 412, "platforms": ["ios", "android"] },
7  "startDate": "2024-11-04",
8  "plannedSampleSizePerGroup": 3834,
9  "status": "running"
10}

Bu kayıt, hem deneyi erken durdurma baskısına karşı bir referans noktası olur (planlanan örneklem büyüklüğüne bak, henüz ulaşmadıysa bekle) hem de gelecekteki deneylerin aynı hatayı tekrarlamasını önler.

SSS

Mobil uygulamada A/B test nasıl kurulur?

Önce test edeceğin katmanı seç: uygulama-içi davranış için sunucu-taraflı bayrak (Firebase Remote Config gibi), mağaza sayfası için Apple Product Page Optimization (PPO) veya Google Play Store Listing Experiments. Ardından birincil metriği, hedef kohortu (minimum sürüm dahil) ve örneklem büyüklüğünü deney başlamadan sabitle; kullanıcı atamasını sticky hash ile yap ve sonucu deney kaydına yaz.

Kaç kullanıcıyla anlamlı sonuç alınır?

Sabit bir sayı yoktur; gereken örneklem büyüklüğü kontrol grubunun temel dönüşüm oranına, tespit etmek istediğin minimum farka (MDE) ve seçtiğin güven/güç seviyesine bağlıdır. İki-oranlı test formülüyle (bu yazıdaki Python örneğine bak) kendi senaryonu hesapla; küçük bir MDE hedeflemek örneklem ihtiyacını hızla büyütür.

Sürüm dağılımı test sonucunu nasıl bozar?

Deney yalnızca belirli bir minimum sürümü çalıştıran kullanıcılarda anlamlıysa, eski sürümdeki kullanıcıları deney havuzuna dahil etmek örneklem hesabını saptırır; ayrıca deney sürerken sürüm güncelleyen kullanıcıların varyantı sabitlenmezse (sticky assignment yoksa) aynı kullanıcı deney içinde gruptan gruba kayabilir ve ölçüm kirlenir.

Sunucu-taraflı bayrak ile mağaza deneyi aynı anda kullanılabilir mi?

Evet ama ayrı deney kayıtlarıyla: biri indirme-öncesi huniyi (mağaza sayfası), diğeri indirme-sonrası davranışı (uygulama içi) ölçer. İkisini aynı deney panosunda karıştırmak, hangi metriğin hangi değişiklikten etkilendiğini belirsizleştirir.

Erken durdurma neden riskli?

Sabit örneklem için hesaplanmış bir anlamlılık eşiği, deneyi tekrar tekrar kontrol edip anlamlı görününce durdurma alışkanlığıyla kullanıldığında yanlış-pozitif oranını hesapta olduğundan daha yükseğe taşır. Sürekli izleme gerekiyorsa ardışık test (sequential testing) destekleyen bir yöntem/platforma geç.

Güncelleme (Eylül 2026)

Bu yazı 2024-11-20 tarihindeki araç ve sürümlerle yazıldı; o tarihten sonra mobil A/B test altyapısında değişen üç gelişme:

• Firebase A/B Testing, Remote Config'e entegre edildi. Bağımsız Drafts akışı deprecated edildi ve 31 Ekim 2026'da kaldırılıyor; mevcut taslaklar artık yalnızca görüntülenebilir/kopyalanabilir/silinebilir durumda, yeniden başlatılamıyor. Deneyler artık doğrudan Remote Config'in koşul tabanlı hedefleme akışıyla kuruluyor. (Kaynak: firebase.google.com/docs/ab-testing/faq-and-troubleshooting)
• Apple Custom Product Pages'in kapsamı genişledi. 30 Temmuz 2025'ten itibaren CPP'lere anahtar kelime atanabiliyor ve organik arama sonuçlarında görünebiliyorlar (önceden yalnızca ücretli/Apple Ads bağlantılarıyla erişilebiliyordu); 29 Ekim 2025'te uygulama başına maksimum aktif CPP sayısı 35'ten 70'e çıkarıldı (hatırlatma: CPP kendi başına bir A/B testi değildir — deney aracı olan PPO'dan ayrı, hedefe özel bir mağaza sayfası aracıdır). (Kaynak: adapty.io/blog/custom-product-pages-app-store)
• Android sürüm parçalanması sürüyor. Google'ın Aralık 2025 dağıtım verisine göre Android 16 kullanıcıların %7,5'ine, Android 15 ise %19,3'üne ulaşmış durumda; bu da sürüme göre stratifikasyonun (bu yazıdaki "Sürüm dağılımı ve kohort kirlenmesi" bölümü) 2026'da hâlâ kritik bir kontrol olduğunu doğruluyor. (Kaynak: androidheadlines.com, Ocak 2026)

Sonradan yayımlanan ilgili yazılar:

• App Store Optimization (ASO) — mağaza sayfası deneyinin ASO bağlamı
• iOS Crash Reporting ve Analytics — deney metriklerini besleyen analytics altyapısı
• TipKit: iOS Onboarding ve Feature Discovery Pattern Rehberi — onboarding deneylerinde kullanılan pattern'ler
• iOS App Store'da $1M Kazandım: Gerçek Strateji ve Rakamlar — deney kararlarının iş sonucuna etkisi

Sonuç

Mobil A/B test altyapısı kurmak, web deneyinin mobile taşınmış hali değil; dağıtım gecikmesi, sürüm parçalanması ve mağaza kuralları yüzünden ayrı bir disiplin ister. Sunucu-taraflı bayrak ile mağaza deneyini ayrı tut, örneklem büyüklüğünü deneyden önce hesapla, kullanıcı atamasını sticky yap ve her deneyi yazılı bir karar defterine kaydet — bu dört alışkanlık, mobil ekiplerin en sık düştüğü kohort kirlenmesi ve erken durdurma hatalarının büyük kısmını önler.

İlgili yazılar:

• iOS CI/CD Pipeline — deney içeren sürümlerin dağıtım hattı

Kaynaklar

• Firebase A/B Testing — FAQ and Troubleshooting — Remote Config entegrasyonu ve Drafts akışının kaldırılma takvimi.
• Firebase A/B Testing — Genel Bakış — deney kurulumu ve koşul tabanlı hedefleme.
• Apple Developer — App Store Product Page Optimization — mağaza sayfası deneyinin resmi kapsamı ve sınırları.
• Apple Developer — Custom Product Pages — CPP'nin App Store için resmi tanımı (güncel üst sınır için Güncelleme bölümüne bak).
• Adapty — Custom Product Pages Rehberi — CPP sayı limiti ve anahtar kelime atama güncellemeleri.
• The ASO Project — Google Play Store Listing Experiments Güncellemeleri — Play Console deney kontrol paneli değişiklikleri.
• Android Headlines — Android Sürüm Dağılımı 2025-2026 — kohort stratifikasyonunu gerekli kılan parçalanma verisi.
• Statsig — A/B Testing ve Feature Flag Araçları Karşılaştırması — sequential testing ve varyans azaltma yöntemleri.