Soruya cevap
Tarihsel olarak, ürün ekipleri, yalnızca büyüme ve yeni işlevlerin benimsenmesine odaklandılar; ancak dijital ürünlerin doyuma ulaşması ve teknik borcun birikmesiyle işlevlerin (feature deprecation) gerekçeli bir şekilde kaldırılması kritik bir görev haline geldi. Sorun, kaldırılan işlevi aktif bir şekilde kullanmış olan kullanıcıların, geri kalan kitleye göre katılım ve sadakat açısından sistematik olarak farklı olmalarıdır; bu durum seçim sapması (selection bias) yaratmakta ve aşamalı kapatma, mevsimsellik ve doğal ayrılma ile zaman serilerini çarpıtmaktadır.
Gerçek nedensel etkinin izole edilmesi için her kohort içinde Difference-in-Differences (DiD) yöntemi veya CausalImpact'in Bayesian Structural Time Series temellisine dayalı olarak uygulanması gereklidir; etkilenmeyen kohortlar sentetik kontrol olarak kullanılmalıdır. Temel adım, her kohort içinde bir etkinlik puanı eşleştirme (PSM) modeli oluşturmaktır: işlevden mahrum kalan kullanıcılar (treatment) için, hiç bu fonksiyonu kullanmamış olan (control) benzer aktiflik, tenure ve dönüşüm geçmişine sahip kullanıcı çiftleri eşleştirilir. Eğer işlevin kullanımında belirgin bir eşik (örneğin, ayda >5 kullanımı) varsa, Regression Discontinuity Design (RDD) verimli bir şekilde kullanılabilir; bu, kullanıcıları kapatma eşiğinin her iki tarafında doğrudan karşılaştırmayı mümkün kılar.
Ek olarak survivorship bias'ı kontrol etmek de önemlidir: eğer işlev düşük kullanım nedeniyle kaldırılıyorsa, analiz yalnızca karar anında aktif olan kullanıcıları içermelidir; gözlem öncesi süreçte ayrılanları hariç tutmalıdır. Uzun vadeli etkinin değerlendirilmesi için, kaldırma anından itibaren üçüncü ve yedinci gün tutulumunu takip etmek için dinamik etkileri olan staggered DiD uygulanır ve Parallel Trends Assumption, önceki dönemlerde yer alan sahte testlerle kontrol edilir.
Hayattan bir durum
Büyük bir edtech ürününde, mentorlara yönelik eski metin sohbetinin video danışmanlıkla değiştirilmesine karar verildi, çünkü sohbetten kullanıcıların %3'ü daha azını kullanıyordu, ancak bunun bakımı ekip kaynaklarının %20'sini alıyordu. Yayın aşamalı olarak planlandı: önce yeni kullanıcılara kapatma, sonra düşük aktifliğe sahip kohortlara ve nihayetinde power kullanıcılarına. İş dünyası, kaldırmanın olumlu kullanıcılar arasında bir negatif dalga ve ayrılma yaratmasından endişeliydi; çünkü bu kullanıcılar, görevlerin netleştirilmesi için sohbeti yoğun bir şekilde kullanmışlardı.
İlk seçenek, her kohort için kapatma öncesi ve sonrası retention üzerinde basit bir karşılaştırmalı analizdi. Bu yaklaşım, hızlı bir uygulanabilirlik ve paydaşlara netlik sağlamasına rağmen, kaldırmanın etkisini kohortun doğal yaşlanmasından (cohort aging) ve öğrencilerin yaz dönemindeki mevsimsel aktivite değişimlerinden ayırma konusunda ciddi sıkıntılar yaşamaktaydı. İkinci seçenek, sohbeti %50 kullanıcı için gizleyen bir özellik bayrağıyla klasik bir A/B testi oldu, ancak iki UI versiyonunun desteklenmesinin teknik zorluğu ve etik kaygılar nedeniyle bu seçenek dışlandı: kullanıcılara sohbet desteği vaat edip diğerlerine, hata olduğunda reddetmek doğru olamazdı.
Üçüncü ve seçilen seçenek, sentetik kontrol ile Difference-in-Differences yöntemiyle analiz olmaktı. Sohbet erişimini kaybeden her kohort için, analitikler, sohbeti asla açmamış olan önceki kohorttan bir kullanıcı çiftini buldu; ancak bu kullanıcıların dersleri görüntüleme örüntüsü, ev ödevlerini tamamlama geçmişi ve coğrafyası özdeş olmalıydı. Bu, işlev kaybından temiz etkinin genel eğilimlerden izole edilerek treatment grubunun (sohbeti kaybedenler) ve kontrol grubunun (hiç kullanmamış olanlar) retention eğilimlerini karşılaştırmayı sağladı.
Sonuç gösterdi ki, power kullanıcıları için (sohbet kullanım sıklığı açısından en üst %10) kaldırma, 30 gün içinde tutulma oranını %8 oranında düşürdü; ancak bu, video danışmanlıklardaki dönüşümde %15 artış ve uygulama performans метрикlerinde (legacy kodun kaldırılması sayesinde çarpışma oranında %12 azalma) iyileşme ile telafi edildi. Orta segment için etkisi istatistiksel olarak önemsizdi; bu durum iş dünyasının, power kullanıcıların yeni iletişim kanalına kişiselleştirilmiş teklifler aracılığıyla göçünü odaklanarak işlevin tam olarak kapatılmasını gerekçelendirmesine olanak tanıdı.
Adayların sıklıkla gözden kaçırdığı noktalar
Bir işlevin kaldırılma etkisini, arayüzün "kolaylaştırma" etkisinden (simplification effect) nasıl ayırt edersiniz; burada bilişsel yükteki azalma işlev kaybının olumsuz etkilerini maskeleyebilir?
Cevap, metriklerin parçalanmasında yatmaktadır: yalnızca retention izlemekle kalmayıp, ayrıca kalan işlev için görev tamamlama süresi, hata oranı ve özellik keşfi oranlarını da izlemek gereklidir. Eğer sohbet kaldırıldıktan sonra ödev teslim süresi metriği düşerse (kullanıcılar daha hızlı çalışmaları teslim eder) ve retention stabil kalıyorsa, bu, iletişim kanalının kaybını telafi eden olumlu bir kolaylaştırma etkisine işaret eder. Nicel bir değerlendirme için bir aracı analiz oluşturulur: "kaldırma → retention" ve "kaldırma → UI'yi kolaylaştırma → retention" arasındaki doğrudan nedensel ilişkiler değerlendirilir; bu, temiz negatifin yapısal UX iyileştirmesinden ayrılmasına olanak tanır.
Bir işlevin kaldırılması için "inferior olmama" testi (non-inferiority testing) için istatistiksel gücü nasıl doğru hesaplarsınız, gerekçe zarar vermenin izin verilen eşiği aşmadığını kanıtlamaktır?
Adaylar genellikle, "güvenli" bir kaldırma ile ilgili haksız sonuçlara yol açan klasik bir güç hesaplaması uygularlar. Non-inferiority testing'de, null hipotez "etkisi eşiği aştı" şeklindedir ve güç, iş dünyası tarafından önceden belirlenmiş İndifference Margin (δ)'ye bağlıdır (örneğin, retention'da -2%). Güç formülü beklenen gerçek etkinin (genellikle 0 veya küçük olumlu) ve varyansın belirtilmesini gerektirir; δ'ya yaklaşım, üstel olarak büyük örnekler gerektirir. Kohortlar aracılığıyla kümeleme düzeltmesi ile eşleştirilmiş oranlar için özel güç hesaplayıcıları kullanmak gerekir; çünkü aynı kohort içinde kullanıcılar kapatma zamanına göre korelasyon gösterirler.
Bir kullanıcının işlevi kaldırmasının, diğerlerinin davranışını iletişim bağlantılarındaki kesinti yoluyla nasıl etkilediği gibi ağ etkilerini (spillover effects) nasıl hesaba katarsınız?
Sosyal ürünlerde veya B2B SaaS'de, bir aktörün (örneğin, yöneticinin eski API'yi kaldırması) bir işlevi kullanmayı kaldırmak, son kullanıcıların (çalışanların) deneyimini etkiler ve treatment ile control arasında müdahale yaratır. Bu etkinin izole edilmesi için küme bazlı rastgeleleştirme veya maruz kalma haritası analizine başvurulur: bireysel treatment durumunun yerine, işlevi kaybeden sosyal grafikteki kullanıcıların (takım, aile) yüzdesi kullanılır. Eğer bireysel bir kapatma olayı ile kümedeki kaybeden oranı arasında yüksek bir korelasyon varsa (>0.8), klasik OLS yanlı tahminler verir. Çözüm, kesiklik durumunun aracısı olarak aloormanlar arası değişken kullanımı (IV-regression) veya Fisher'in rastgeleleştirme testi gibi müdahale için nedensel çıkarım yöntemlerinin uygulanmasıdır; burada kesim kohortuna ait olma durumu bir araçtır ve işlevin kaybı değişkenidir.