Ürün Kullanım Verilerini Özellik Benimseme Raporuna Nasıl Dönüştürürsünüz? (2026)

Kullanım dışa aktarımı uzun bir olay listesidir: kullanıcı kimliği, olay adı, zaman damgası, belki bir veya iki özellik. Özellik benimseme raporu ise tek bir yüzdedir. Aralarındaki mesafe bir formül değil, üç karardır.

Paydaya hangi kullanıcıların dahil edileceği. Özelliği kullanmış sayılmak için neyin kriter alınacağı. Ve hangi zaman aralığında ölçüm yaptığınız.

Bunlardan herhangi birini değiştirdiğinizde, sayı onlarca yüzde puanı oynar. Rapor yine de doğru görünür, sorun da zaten budur.

Bu kılavuz, öncelikle neyin netleştirilmesi gerektiğini, üç manuel yöntemi ve her birinin nerede tıkandığını ele almaktadır.

Başlamadan önce ihtiyacınız olanlar

Önceden birleştirilmiş bir özete değil, olay düzeyinde satırlara ihtiyacınız var. Bir kullanıcı tanımlayıcısı ve bir zaman damgası içeren, olay başına bir satır.

Özelliği gerçekten temsil eden olay adına ihtiyacınız var. Bu kulağa geldiği kadar kolay değildir, çünkü çoğu özellik birden fazla olay tetikler. Bir özellik benimseme oranı, ancak bu eşleştirme kadar iyi olabilir.

Ayrıca bunu kimlerin kullanabileceğini de bilmeniz gerekir. Özellik, hesapların yalnızca bir kısmına bir bayrak (flag) arkasında sunulduysa, geri kalan hiç kimse paydaya dahil edilmemelidir.

Hızlı bir sağlamlık kontrolü daha sonra size bir saat kazandırır. Dışa aktarılan verideki benzersiz kullanıcıları sayın ve bunu bilinen aktif kullanıcı sayınızla karşılaştırın. Arada büyük bir fark varsa, dışa aktarma fark etmediğiniz bir şekilde filtrelenmiştir.

Sayıyı değiştiren üç karar

Payda. Kayıtlı tüm kullanıcılar, aylık aktif kullanıcılar veya yalnızca özellik için uygun olan kullanıcılar. Bunlar, aynı olaylardan üç farklı yüzde üretir. Her özellik benimseme oranı bir kesirdir, bu nedenle herhangi bir hesaplama yapmadan önce her iki yarıyı da adlandırın.

Yeni sunulan bir özellik için genellikle en dürüst seçim "uygun olanlar"dır. Kayıtlı tüm kullanıcılar, en kötü görünen ve ihtiyatlı bir yaklaşım olarak savunulması en kolay olan sayıdır.

"Kullanılmış" olmanın anlamı. Olayın bir kez tetiklenmesi, iki kez tetiklenmesi veya iki ayrı oturumda tetiklenmesi. Bir tanıtım turu sırasındaki tek bir tıklama benimseme değildir, ve çoğu ekip bunu acı yoldan öğrenir.

Bir eşik değer belirleyin ve bunu rapora yazın. İki farklı günde iki kullanım, yaygın ve savunulabilir bir kuraldır.

Zaman aralığı. Benimseme, zamandaki tek bir an değildir. Uygun kullanıcıların belirli bir süre içinde bu eylemi gerçekleştirme oranıdır, dolayısıyla bu süre tanımın bir parçasıdır.

Bir aracın metodolojisini kopyalamadan önce bilinmesi gereken, belgelenmiş bir incelik şudur. Amplitude's retention documentation hesaplamanın nasıl çalıştığını açıklar. Bu hesaplama, "başlangıç olayının tarihini, belirttiğiniz geri dönüş olayının tarihiyle karşılaştırarak elde tutma verilerini hesaplar."

Tarih aralığı yalnızca ilk olay için geçerlidir. Amplitude açıkça "kullanıcıların analizde görünmesi için bu süre zarfında geri dönüş olayını tetiklemek zorunda olmadığını" belirtir.

Bu mantıklı bir davranıştır ve insanları şaşırtır. Her iki olayı da aynı zaman aralığına göre filtreleyen bir e-tablo araçla eşleşmeyecektir ve ikisi de yanlış değildir.

Manuel olarak nasıl yapılır

Seçenek 1: Benzersiz kullanıcıları sayın, ardından bölün

Yinelemeleri temizleyerek başlayın, çünkü ham olay sayıları benimseyenleri göstermez. UNIQUE işleviyle benzersiz kullanıcı listesini çekin.

Ardından, olay adı ve tarih sınırlarıyla birlikte COUNTIFS işlevini kullanarak bu kullanıcılardan kaçının özellik olayını tetiklediğini sayın. Uygun kullanıcı sayınıza bölün.

İki sayımı tek bir formül içinde iç içe geçirmek yerine görünür hücrelerde tutun. Birisi paydanın ne olduğunu soracaktır ve siz de onu doğrudan gösterebilmek istersiniz.

Bunun sınırı, size hiçbir detayı olmayan tek bir sayı vermesidir. %18'in benimsediğini bilirsiniz ama kimlerin benimsediği hakkında hiçbir şey bilmezsiniz.

Seçenek 2: Kullanıcı düzeyinde bir bayrak tablosu oluşturun

Uygun kullanıcı başına bir satır, soru başına bir sütun. Olayı tetiklediler mi, kaç kez tetiklediler ve kaç farklı günde tetiklediler.

Artık veriyi dilimleyebilirsiniz. Plana göre, kayıt kohortuna (cohort) göre, hesap boyutuna göre veya ilk katılımı (onboarding) tamamlayıp tamamlamadıklarına göre benimseme.

Özellik benimsemenin sadece raporlanabilir olmaktan çıkıp eyleme geçirilebilir hale geldiği yer burasıdır. Harmanlanmış bir %18 oranı, yeni kullanıcıların %40'ta, geçen yılki kullanıcılerin ise %4'te olduğunu gizler.

İşte bu fark asıl bulgudur. cohort analysis kılavuzumuz, davranışlar değişmese bile kayıt hacmi her değiştiğinde harmanlanmış rakamın neden hareket ettiğini açıklamaktadır.

Sınır ise hacim ve birleştirmelerdir (joins). Bir milyon satırlık bir dışa aktarma ve bir hesap tablosu, formüllerin artık kullanışlı olmaktan çıktığı noktadır.

Seçenek 3: Sayıların yanında bir tanımlar sekmesi bulundurun

Olay adını, eşik değerini, zaman aralığını, paydayı ve kimlerin uygun olduğunu yazın.

Raporu gelecek ay karşılaştırılabilir kılan şey budur. Aynı zamanda birisinin on dakika içinde sayıya ihtiyacı olduğunda atlanan sekmedir.

Sınırlama, bir tanımı belgelemenin onu uygulamaya koymadığı gerçeğidir. Birileri her döngüde hala aynı beş filtreyi yeniden oluşturur.

Ortak sınır. Her üçü de olay adlarının temiz olduğunu varsayar. Bir kod yeniden yapılandırmasından (refactor) sonra aynı eylem üç farklı ad altında tetiklendiğinde, asıl iş herhangi bir sayıma başlamadan önce bunları uzlaştırmaktır.

Manuel yöntemin yavaşladığı yerler

İlk rapor bir sabahınızı alır. Dördüncüsü daha uzun sürer, çünkü o zamana kadar tanım sessizce değişmiştir.

Ürün değiştiğinde olay adları da değişir. Kod tabanındaki bir yeniden adlandırma, grafiğinizde ani bir düşüşe neden olur ve tıpkı kullanıcıların özelliği bırakması gibi görünür. Bir özellik benimseme grafiğinin, bir müşteri kararından ziyade bir kod değişikliğini raporlaması işte bu şekilde gerçekleşir.

Dağıtım (rollout) değişiklikleri paydayı bozar. Özellik hesapların %100'üne ulaşır ve uygun nüfus üç katına çıktığı için benimseme oranı düşmüş gibi görünür.

Bir de en uzun süre hayatta kalan sayım hatası vardır. Benzersiz kullanıcılar yerine olay sayılarının toplanması, birkaç sadık kullanıcının (power user) özelliği yoğun şekilde kullanması durumunda benimseme oranını yapay olarak şişirir.

Yalnızca teslim tarihi yaklaştığında ortaya çıkan bir maliyet daha vardır. Birisi "Bu iyi mi?" diye sorduğunda, tek bir yüzde buna cevap veremez ve karşılaştırmayı oluşturmak ikinci bir proje haline gelir.

Powerdrill Bloom ile rapor nasıl oluşturulur

Adım 1: Kullanım dışa aktarımınızı yükleyin

Olay dışa aktarımını veya olay ve hesap dosyalarını birlikte yükleyin. Powerdrill Bloom, sütunları yükleme anında analiz eder, böylece tutarsız olay adları ve eksik kullanıcı kimlikleri herhangi bir yüzde hesaplanmadan önce ortaya çıkar.

Adım 2: Tanımı doğal dille açıklayın

Kuralları oluşturmak yerine doğrudan ifade edin. Olayı, eşik değerini, zaman aralığını ve hangi kullanıcıların uygun olduğunu belirtin.

Ardından tuzakları yakalayan soruları sorun. Herhangi bir olay adının birbirine çok benzer görünüp görünmediğini sorun. Kaç olayın tetiklendiğine kıyasla kaç benzersiz kullanıcının olayı tetiklediğini ve özellik benimseme oranının kayıt ayına göre nasıl değiştiğini sorun.

Adım 3: Grafiği, raporu veya sunumu dışa aktarın

Benimseme trendini, segmente göre bir tabloyu veya sayıyı ve tanımı bir arada sunan bir slaytı dışa aktarın.

Bunun her döngüde yeniden oluşturmaktan neden daha iyi olduğu

	Manuel yöntem	Powerdrill Bloom
Kullanıcıları olaylardan tekilleştirme	Dosya başına yardımcı sütunlar	Benzersiz kullanıcıları isteyin
Kohorta veya plana göre bölme	Tabloyu birleştirin ve yeniden oluşturun	Kırılımı isteyin
Sürümden sonra yeniden adlandırılan olaylar	Daha sonra grafikte fark edin	Yükleme sırasında ortaya çıkar
Uygun kullanıcı kitlesini değiştirme	Paydayı yeniden düzenleyin	Yeni kuralı belirtin

Üçüncü satır, doğruluğun kazanıldığı veya kaybedildiği yerdir. Yeniden adlandırılan bir olay ile gerçek bir düşüş, çizgi grafikte tamamen aynı görünür ve bunlardan yalnızca biri ürün tarafında bir aksiyon gerektirir.

Sık yapılan hatalar

Kullanıcılar yerine olayları saymak. İki yüz kişiden gelen on bin olay benimseme değildir. Her zaman önce yinelemeleri temizleyin (tekilleştirin).

Bayrak eklenmiş bir özellikte kayıtlı tüm kullanıcıları payda olarak kullanmak. Hesapların yalnızca üçte biri bunu görebiliyorsa, diğer üçte iki benimsemeyenler değildir. Onlar uygun değildir.

Tek bir tıklamayı benimseme olarak kabul etmek. İlk katılım (onboarding) sırasındaki tek bir olay yalnızca maruz kalmadır. Sayının bir anlam ifade etmesini istiyorsanız, ayrı günlerde tekrarlanan kullanım şartı koşun.

Aylar genelinde harmanlanmış bir oranı karşılaştırmak. Yeni ve mevcut kullanıcılar farklı oranlarda benimser, bu nedenle bu karışım sayıyı kendi kendine hareket ettirir. Bir sonuca varmadan önce kohorta göre bölün.

Olay yeniden adlandırmasını göz ardı etmek. Kodun yeniden yapılandırılması (refactor), kayıp (churn) gibi görünen ani bir düşüş yaratır. Kullanıcı davranışını incelemeden önce olay sözlüğünü kontrol edin.

Bir aracın zaman aralığını nasıl çalıştığını okumadan kopyalamak. Belgelenmiş elde tutma aralıkları genellikle yalnızca ilk olayı filtreler, bu nedenle her iki olayı da filtreleyen bir e-tablo bununla uyuşmayacaktır.

Yüzdeyi herhangi bir tanım eklemeden raporlamak. Payda ve eşik değer olmadan sayı anlamsızdır. İyi bir KPI dashboard metriklerini nasıl etiketliyorsa, her ikisini de grafiğe yerleştirin.

Sonuç

Bölme işleminden önce uygun kullanıcı kitlesine karar verin, bir kullanım eşiği belirleyin, zaman aralığını sabitleyin ve kullanıcıları tekilleştirin. Bu dördü, özellik benimseme yüzdesini bir ürün ekibinin üzerinde harekete geçebileceği bir şeye dönüştürür.

Bunu maliyetli kılan şey, tanımın ürün değişikliklerine karşı ayakta kalması gerektiğidir. Yeniden adlandırılan olaylar ve genişletilen dağıtımlar, hiç kimse rapora dokunmasa bile sayıyı değiştirir.

Raporlama döngünüz bu noktada tıkanıyorsa, kullanım dışa aktarımınızda Powerdrill Bloom'u deneyin. Ayrıca kohort elde tutma grafiği oluşturma kılavuzumuza, ürün analitiği için en iyi yapay zeka araçları derlememize ve CSV AI assistant sayfamıza göz atın.

Sıkça sorulan sorular

Özellik benimseme nedir?

Olaylardan ziyade benzersiz kullanıcılar olarak ölçülen, tanımlanmış bir zaman aralığında bir özelliği kullanan uygun kullanıcıların oranıdır. Tanım, yalnızca payda ve kullanım eşiği belirtildiğinde geçerli olur.

Bunu bir olay dışa aktarımından nasıl hesaplarım?

Zaman aralığınız içinde özellik olayını tetikleyen benzersiz kullanıcıları sayın, ardından uygun kullanıcı sayısına bölün. Her zaman önce yinelemeleri temizleyin (tekilleştirin), çünkü bir kullanıcı yüzlerce olay üretebilir.

Payda tüm kullanıcılar mı yoksa aktif kullanıcılar mı olmalı?

Özelliğe gerçekten erişebilecek kullanıcılar olan uygun kitleyi kullanın. Kayıtlı tüm kullanıcılar ihtiyatlı bir rakam üretir ve bir dağıtım bayrağının arkasındaki benimsemeyi olduğundan az gösterir.

Ölçüm aralığı ne kadar uzun olmalı?

Normal bir kullanım döngüsü için yeterince uzun olmalıdır; yani günlük kullanılan ürünler için haftalık, periyodik olanlar için aylık. Raporlar arasında bunu sabit tutun, çünkü değiştirmek sayıyı da değiştirir.

Sayım neden analitik aracıyla farklılık gösteriyor?

Genellikle zaman aralığı veya tekilleştirme kuralı nedeniyle. Belgelenmiş elde tutma hesaplamaları genellikle tarih filtresini yalnızca ilk olaya uygular; her iki olay üzerine kurulu bir e-tablo bunu yeniden üretemez.