Tarihi Bağlam
2010 ile 2015 yılları arasında, işletmelerin iOS ve Android için native uygulamaları desteklediği ve OS sürümlerine göre pazarın %95'ini kapsayan tam uyumluluk yaklaşımı egemendi. Ancak işlevselliğin karmaşıklığındaki artış ve modern API'lara (örneğin, Biometric API, Camera2, Jetpack Compose) geçişle birlikte legacy kodunun desteklenmesi maliyetleri, tutulan kullanıcıların marjinal kârını aşmaya başladı. 2020'li yıllara gelindiğinde, gerçek kapatma etkisini değerlendirmek için bir metodoloji geliştirilmesi gerekeceği için artık "n-2" politikası standart haline geldi.
Sorunun Tanımı
Zorunlu kapatma, kendini seçme içselliğini oluşturur: Eski cihazları olan kullanıcılar gereken iOS veya Android sürümüne güncelleyemezken, modern akıllı telefonlara sahip aktif kullanıcılar hızlı bir şekilde güncellenmektedir. Gözlemlenen MAU düşüşü, gerçek kayıptan (churn) veya PWA'ya (Progressive Web App) veya mobil web'e geçişten kaynaklanabilir. Klasik A/B testleri mümkün değildir çünkü kapatma teknik bir doğaya sahiptir ve belirli bir OS sürümünü kullanan tüm kullanıcılara aynı anda uygulanmaktadır; ayrıca, yerel uygulama ile web sürümü arasındaki kimlik takibi, Safari ve Chrome üzerindeki cookies ile ilgili kısıtlamalar nedeniyle zordur.
Detaylı Çözüm
Optimal metodoloji, kesikli regresyon (RDD) ve sentetik kontrol (Synthetic Control Method) kombinasyonuna dayanmaktadır. İlk olarak, bir RDD uygulanmakta, OS sürümüne göre bir eşik belirlenmekte (örneğin, Android 8.0 ile Android 9.0 arasında) ve eşik altında kalan sürüme sahip kullanıcılar, eşik üstünde kalan kullanıcılar için kontrol grubu olarak kullanılmaktadır. Ayrıca, akıllı telefon modelleri ve geçmiş kullanım sıklığı gibi pürüzsüz özellikler için düzeltmeler yapılmaktadır.
İkincisi, web kanalına göçü değerlendirmek için, kapanmadan önceki davranış kalıpları ile benzer kullanıcı kohortlarına göre geçmiş DAU verilerine dayanarak sentetik bir kontrol oluşturulmaktadır. Etkilenmeyen kohortların (örneğin, benzer cihaz yapılarına sahip diğer bölgelerdeki kullanıcılar) ağırlıklı bir kombinasyonu oluşturulmakta ve bu model, karşı-faktürel metriklerin yolunu simüle etmektedir.
Üçüncüsü, güncellemeyi yapmış olan kullanıcılarla, ancak güncellemeyi yapmamış olan kullanıcıları karşılaştırmak için difference-in-differences yaklaşımı ve Propensity Score Matching kullanılmaktadır; cihazların teknik özellikleri için düzeltmeler yapmak önemlidir. Customer Data Platform (CDP) üzerinden cross-device göçünü takip etmek önemlidir; mobil uygulamadaki device_id, web sürümündeki cookie_id ile birleştirilerek tek bir user_id altında oturum açıldığında ilişkilendirilir. Ayrıca, OS sürümüne ve web alternatifinin mevcudiyetine bağlı olarak kayıptan önce geçen süreyi değerlendirmek için survival analysis (Cox modelleri) kullanılmaktadır.
Kontekst: Büyük bir pazar yeri, güvenli ödemeler için Biometric API'nin uygulanması amacıyla Android 7.0 ve altındaki sürümlerin desteklenmesini bırakmaya karar verdi (yaklaşık %8'lik bir kullanıcı tabanı). Projenin bütçesi, aktif kullanıcıların %3'ünden fazlasını kaybetmemeyi gerektiriyordu ve bu kayıp yeni sürümlerdeki dönüşüm artışıyla telafi edilebilmeliydi.
Seçenek 1: Kapatma tarihlerinden önce ve sonra MAU değerlerini basitçe karşılaştırarak kayıp yüzdesini hesaplamak. Artılar: hesaplama kolaylığı, sonuçların hızlı alınması, karmaşık bir altyapı gerektirmemesi. Eksiler: mevsimselliği, web'e geçişi ve cihazlara göre kendini seçmeyi tamamen göz ardı etmesi; kullanıcılar yalnızca m.site'ye geçtiği için yanlış pozitif kayıplar verme riski yüksektir.
Seçenek 2: Güncellenmiş cihazlarla Android 8.0 kullanıcıları ve güncellenemeyen Android 7.0 kullanıcıları arasında eşleştirerek bir kohort analizi oluşturmak. Artılar: teknik sınırlamaları dikkate alır, güncelleyememe etkisini istenmeme davranışından izole etmeyi sağlar. Eksiler: OEM üreticileri (Samsung, Xiaomi) nedeniyle temiz veri elde etmenin zorluğu, farklı marka kullanıcılarının davranışlarındaki farklılıklar ve coğrafi heterojenlik.
Seçenek 3: Daha eski cihazların yüksek oranla bulunduğu coğrafi bölgeler düzeyinde Synthetic Control yaklaşımının uygulanması (A bölgesi %30 Android 7'ye sahipken, B bölgesinin bu oranın %5 olduğu durumlar ile; kapatma öncesi ve sonrası karşılaştırılması) ile pazarın genel trendlerine dair düzeltmeler yapılmaktadır. Artılar: makroekonomik faktörleri ve mevsimselliği dikkate alır, işletmeye olan genel etkileri değerlendirmeyi mümkün kılar. Eksiler: büyük örneklemler gerektirir ve bölgedeki diğer eş zamanlı müdahalelerin olmamasını varsayar.
Seçilen Çözüm: Seçenek 3'ün, web'e göçü izlemek için yetkilendirilmiş kullanıcıların kohort analizi ile kombinasyonu uygulanmıştır (web üzerinden SSO girişleriyle). Tercih, gerçek kaybı web trafiğinin kanibalizasyonundan ayırma gerekliliğinden kaynaklanmaktadır; bu, unit-economics değerlendirmesi için kritik öneme sahiptir (web kullanıcılarının AOV'si %15 daha düşüktür).
Sonuç: Analiz, "kayıp" MAU'ların yalnızca %40'ının gerçekten kaybolduğunu, %35'inin PWA'ya göç ettiğini ve %25'inin çeyrek içinde cihazlarını güncellediğini ortaya koymuştur. Gerçek negatif etki, tahmin edilenden 2.5 kat daha az çıkmış, bu da kalan %92'lik kullanıcı kitlesi için API güncelleme stratejisinin devam ettirilmesine ve yeni ödeme özellikleri sayesinde GMV'de %8 büyüme sağlanmasına olanak tanımıştır.
Eski uygulama sürümlerinde kalan kullanıcılar arasında teknik bir güncelleme yapamama ile davranışsal olarak güncellemeyi reddetme arasındaki fark nasıl ayırt edilir?
Cevap, CDP üzerindeki device_change events analizi üzerine inşa edilmelidir. Davranışsal olarak güncellemeyi reddeden kullanıcılar (lazy updaters), tarihleri içerisinde "giderek güncelleyerek" ilerleyen bir kalıp saptama eğilimindedir (örneğin, birkaç minör sürümü atlayarak, kritik güvenlik yamanmalarını kurmak) oysa, teknik olarak sınırlı kullanıcılar cihazın tüm yaşam döngüsü boyunca asla OS version değişikliği yapmamaktadır. Ayrıca, web versiyonunda WebGL veya Canvas üzerinden hardware fingerprint analizi de yapılmaktadır: kullanıcı PWA'da, kapatma öncesi yerel uygulamadaki aynı cihazla (kullanıcı-agent ve ekran çözünürlüğü üzerinden) görünüyor ise, bu kullanıcıyı, kaybedilmiş değil göç eden olarak doğrulanır. Ayrıca, app_version geçmişine göre de segmentleme yapmak önemlidir: Eğer kullanıcı düzenli olarak Android 7 sürümü arasında güncellenmiş (7.0->7.1 arasında), ancak 8.0'a geçmemişse, bu bir teknik sınırlamaya işaret eder.
Neden standart Propensity Score Matching, güçlü bir kullanıcı gelir ile cihaz modeli arasındaki korelasyon olduğunda zorunlu yükseltme etkisini değerlendirirken yanlı sonuçlar verebilir?
Standart PSM koşullu bağımsızlık varsayımlarına dayanarak, gözlemlenen kovaryantların kendini seçmeyi tamamen açıkladığını varsayar. Ancak, sunset politikası durumunda gizli bir değişken olan disposable income vardır; bu hem akıllı telefon modeli (lüks model ile bütçe model arasındaki fark) hem de kullanıcı LTV'si ile korele olmaktadır. Bütçe cihazları genellikle OS güncellemelerini almazlar ve onların sahiplerinin ödeme güçleri daha düşüktür. Standart PSM, zengin kullanıcıları yeni cihazlarla, fakir kullanıcılarla eski cihazlar gibi "ağırlıklandıracağı" için olumsuz etkileri hafifletecektir; oysa davranışsal kalıpları temelde farklıdır. Çözüm, PSM uygulamasından önce cihaz fiyat segmentlerine (low-end, mid-range, flagship) göre kesin stratifiye edilmiş Coarsened Exact Matching (CEM) veya OEM üreticilerinin güncelleme politikalarını dışsal bir şok olarak kullanan instrumental değişkenler (IV) kullanmaktır.
Farklı uygulama sürümleri arasındaki ağ etkilerini, eğer "ürünü paylaş" işlevi eski ve yeni sürümlerde farklı çalışıyorsa, kayıpları değerlendirirken doğru bir şekilde nasıl dikkate alabiliriz?
Ağ etkileri, tedavi (treatment) ve kontrol grupları arasında spillover yaratmaktadır: Eğer yeni sürümde aktif bir kullanıcı (tedavi) eski sürümdeki bir arkadaşıyla içerik paylaşamazsa (yeni deep link formatını desteklemiyorsa), bu hem uygulama kullanıcılarının deneyimini kötüleştirir ve kontrol grubunun kaybını hızlandırabilir. Bu durumu düzeltmek için network-based DID (Ağ Ağırlıklı Difference-in-Differences) yöntemi uygulanmalıdır. Sosyal bağlantıların grafiği (örneğin, referral codes, ortak siparişler veya uygulama içi mesajlaşma analizi ile) oluşturulmakta ve metriklerin "bulaşması" değerlendirilmelidir: kontrol grubundaki bir kullanıcının tedavi grubuyla (yeni versiyon) birçok bağlantısı varsa, bu kullanıcının davranışı yanlış anlaşılacaktır. Modelde Treatment x Network_Exposure etkileşim terimi eklenmektedir; burada Network_Exposure, ağdaki yeni versiyonu kullanan bağlantıların oranıdır. Ağ etkilerinin yüksek olduğu durumlarda, gerçek etki azaltılacak, çünkü birçok "kontrol" kullanıcısı dolaylı etkilerle karşılaşacaktır; bu nedenle kontaminasyon göz önünde bulundurularak intention-to-treat (ITT) düzeltmesi gereklidir.