Olay tasarımından panolara, gizliliğe ve yayına kadar özellik benimsemesi ve kullanıcı davranışını izleyen bir web uygulaması kurmak için pratik rehber.
Herhangi bir şeyi takip etmeden önce, “özellik benimsemesi”nin sizin ürününüz için gerçekte ne anlama geldiğine karar verin. Bu adımı atlarsanız çok veri toplarsınız—ve hâlâ toplantılarda bunun ne “anlama geldiği” konusunda tartışırsınız.
Benimseme genellikle tek bir an değildir. Değerin nasıl sağlandığına uyan bir veya daha fazla tanım seçin:
Örnek: “Kaydedilen Aramalar” için benimseme kaydedilmiş bir arama oluşturdu (kullanım), 14 gün içinde 3+ kez çalıştırdı (tekrar) ve bir uyarı alıp tıklayarak geçti (değer sağlandı) olabilir.
Takibiniz eyleme dönüşecek soruları yanıtlamalı, örneğin:
Bunları karar ifadeleri olarak yazın (ör. “Eğer X sürümü sonrası aktivasyon düşerse, onboarding değişikliklerini geri alırız.”).
Farklı ekiplerin farklı görünümlere ihtiyacı vardır:
Haftalık olarak gözden geçirilecek az sayıda metrik seçin ve her dağıtımdan sonra hafif bir sürüm kontrolü ekleyin. Eşikler tanımlayın (ör. “30 gün içinde aktif kullanıcılar arasında benimseme oranı ≥ %25”) ki raporlama tartışma değil karar üretsin.
Herhangi bir şeyi enstrümante etmeden önce, analitik sisteminizin hangi “varlıkları” tanımlayacağını kararlaştırın. Bu varlıkları doğru alırsanız, ürün evrildikçe raporlar anlaşılır kalır.
Her varlığı sade dilde tanımlayın, sonra saklayabileceğiniz ID'lere çevirin:
project_created, invite_sent).\n- Sonuç (Outcome): kullanıcıların/hesapların ulaşmasını istediğiniz değer kilometre taşı (ör. “ilk rapor paylaşıldı”, “abonelik aktifleştirildi”).Her olay için gerekli minimum özellikleri yazın: user_id (veya anonim ID), account_id, zaman damgası ve birkaç ilgili öznitelik (plan, rol, cihaz, feature flag vb.). “Belki işe yarar” diye her şeyi dökmekten kaçının.
Ürün hedeflerinize uyan raporlama açılarından bazılarını seçin:
Olay tasarımınız bu hesaplamaları basit hale getirmeli.
Kapsam hakkında açık olun: öncelikle sadece web mi yoksa web + mobil mi. Çapraz platform takip, olay adlarını ve özellikleri erken standardize ederseniz en kolay olur.
Son olarak, pazarlık edilemez hedefleri belirleyin: kabul edilebilir sayfa performans etkisi, ingestion gecikmesi (panoların ne kadar taze olması gerektiği) ve pano yükleme süresi. Bu kısıtlar, takip, depolama ve sorgulama seçimlerini yönlendirir.
İyi bir takip şeması “her şeyi izlemek”ten çok olayları öngörülebilir kılmakla ilgilidir. Eğer olay adları ve özellikler sürüklenirse, panolar bozulur, analistler veriye güvenmeyi bırakır ve mühendisler yeni özellikleri enstrümante etmekten kaçınır.
Basit, tekrarlanabilir bir desen seçin ve ona sadık kalın. Yaygın bir tercih verb_noun şeklindedir:
viewed_pricing_page\n- started_trial\n- enabled_feature\n- exported_reportGeçmiş veya şimdiki zaman tercih edin ve tutarlı kullanın; eşanlamlılardan (clicked, pressed, tapped) kaçının, eğer gerçekten farklı anlamları yoksa.
Her olay, ileride güvenilir segmentasyon, filtreleme ve join işlemleri yapabilmeniz için küçük bir zorunlu özellik seti taşımalıdır. En azından tanımlayın:
user_id (biliniyorsa, anonim kullanıcılar için nullable)\n- account_id (ürününüz B2B/multi-seat ise)\n- timestamp (mümkünse sunucu tarafından oluşturulmuş)\n- feature_key (ör. "bulk_upload" gibi stabil bir tanımlayıcı)\n- plan (ör. free, pro, enterprise)Bu özellikler, benimseme takibi ve kullanıcı davranışı analitiğini çok daha kolaylaştırır çünkü her olayda eksik olanı tahmin etmek zorunda kalmazsınız.
Opsiyonel alanlar bağlam ekler ama aşırıya kaçmak kolaydır. Tipik opsiyonel özellikler:
device, os, browser\n- page, referrer\n- experiment_variant (veya ab_variant)Opsiyonel özellikleri olaylar arasında tutarlı tutun (aynı anahtar adları, aynı değer formatları) ve mümkünse "izin verilen değerler"i belgeleyin.
Şemanızın evrileceğini varsayın. Anlamı veya zorunlu alanları değiştirdiğinizde event_version (ör. 1, 2) ekleyin ve güncelleyin.
Son olarak, her olayı, ne zaman tetikleneceğini, gerekli/opsiyonel özellikleri ve örnekleri listeleyen bir enstrümantasyon spesifikasyonu yazın. Bu dokümanı uygulamanızla birlikte kaynak kontrolüne koyun ki şema değişiklikleri kod gibi incelenebilsin.
Kimlik modeliniz zayıfsa, benimseme metrikleriniz gürültülü olur: huniler uyuşmaz, retention olduğundan kötü görünür ve “aktif kullanıcılar” çoğaltılmış kullanıcılarla şişer. Amaç aynı anda üç görünümü desteklemektir: anonim ziyaretçiler, giriş yapmış kullanıcılar ve hesap/workspace aktivitesi.
Her cihaz/oturum için bir anonymous_id ile başlayın. Kullanıcı kimlik doğrulaması yaptığında, o anonim geçmişi bir user_id ile ilişkilendirin.
Kimlikleri, kullanıcı hesabının mülkiyetini kanıtladığında (başarılı giriş, magic link doğrulaması, SSO) bağlayın. Zayıf sinyallerle (formda yazılan e-posta gibi) bağlamaktan kaçının, eğer bağlarsanız bunu “pre-auth” olarak açıkça ayırın.
Kimlik geçişlerini olay olarak ele alın:
login_success (içerir: user_id, account_id ve mevcut anonymous_id)\n- logout\n- account_switched (from account_id → account_id)Önemli: logout'ta anonim cookie'yi değiştirmeyin. Eğer onu döndürürseniz, oturumları parçalara ayırırsınız ve benzersiz kullanıcı sayıları şişer. Bunun yerine stabil anonymous_id'yi tutun, fakat logout sonrası user_id ilişkilendirmesini durdurun.
Birleştirme kurallarını açıkça tanımlayın:
user_id'yi tercih edin. Eğer e-posta ile birleştirmeniz gerekiyorsa, bunu sunucu tarafında yapın ve yalnızca doğrulanmış e-postalar için uygulayın. Denetim izi tutun.account_id/workspace_id kullanın, değiştirilebilir bir isim değil.Birleştirme yaparken bir eşleme tablosu (eski → yeni) yazın ve bunu sorgu zamanında veya bir backfill işi ile tutarlı şekilde uygulayın. Bu, kohortlarda “iki kullanıcı” görünmesini önler.
Aşağıdakileri saklayın ve gönderin:
anonymous_id (tarayıcı/cihaz başına stabil)user_id (kişi başına stabil)account_id (workspace başına stabil)Bu üç anahtarla, giriş öncesi davranışı, kullanıcı başına benimsemeyi ve hesap düzeyi benimsemeyi çifte sayım olmadan ölçebilirsiniz.
Olayları nerede takip ettiğiniz, neye güvenebileceğinizi değiştirir. Tarayıcı olayları insanların ne yapmaya çalıştığını söyler; sunucu olayları gerçekten neyin gerçekleştiğini söyler.
Tarayıcıda UI etkileşimleri ve sadece tarayıcıda olan bağlam için istemci tarafı takibi kullanın. Tipik örnekler:
Ağ trafiğini azaltmak için olayları toplayın: bellekte kuyruklayın, her N saniyede veya N olayda gönderin ve ayrıca visibilitychange/sayfa gizlenmesi sırasında flush edin.
Tamamlanmış çıktıyı veya faturalama/güvenlik açısından hassas eylemleri temsil eden her olay için sunucu tarafı takibini kullanın:
Sunucu tarafı genellikle daha doğrudur çünkü reklam engelleyiciler, sayfa yeniden yüklemeleri veya kopuk bağlantılardan etkilenmez.
Pratik bir desen: istemcide niyeti, sunucuda başarıyı takip edin.
Örneğin, feature_x_clicked_enable (istemci) ve feature_x_enabled (sunucu) olaylarını yayınlayın. Ardından sunucu olaylarını, tarayıcı bağlamıyla zenginleştirmek için tarayıcıdan API'ye hafif bir context_id (veya istek ID'si) geçirin.
Olayların en çok kaybolduğu yerlerde dayanıklılık ekleyin:
localStorage/IndexedDB'de tutun, üstel backoff ile yeniden deneyin, denemeleri sınırlandırın ve event_id ile dedupe yapın.\n- Sunucu: geçici hatalarda yeniden deneyin, dahili bir kuyruk kullanın ve yeniden denemenin çift sayım getirmemesi için idempotency sağlayın.Bu karışım, zengin davranış detayı ile güvenilir benimseme metriklerini birleştirir.
Bir özellik-benimseme analitik uygulaması temelde bir boru hattıdır: olayları güvenilir şekilde yakalayın, ucuza saklayın ve insanların sonuçlara güvenip kullandığı kadar hızlı sorgulayın.
Basit, ayrılabilir bir hizmet setiyle başlayın:
Hızlı bir prototip için Koder.ai gibi bir araç, dashboard UI (React) ve backend (Go + PostgreSQL) için başlangıç bir “çalışan dilim” oluşturmanıza yardımcı olabilir—boru hattını sertleştirmeden önce işe yarayan bir dilim elde etmek için faydalıdır.
İki katman kullanın:
Ekibinizin gerçekten ihtiyaç duyduğu tazeliği seçin:
Birçok ekip her ikisini yapar: “şu anda ne oluyor” için gerçek zamanlı sayaçlar ve kanonik metrikleri yeniden hesaplayan gece işleri.
Büyüme için erken tasarlayın:
Ayrıca retention planlayın (ör. ham için 13 ay, agregatlar daha uzun) ve hataları düzeltmek için olayları yeniden işleyebileceğiniz bir replay yolu hazırlayın; böylece panoları yamalamak zorunda kalmazsınız.
İyi analitik, sık sorulan soruları hızla cevaplayacak bir modelle başlar (huniler, retention, özellik kullanımı) ve her sorgunun özel mühendislik işi olmasını engeller.
Çoğu ekip için iki depo en iyisidir:
Bu ayrım, ürün veritabanınızı hafif tutar ve analitik sorguları daha ucuz/ hızlı yapar.
Pratik bir temel şöyle görünür:
Datawarehouseda sık sorguladıklarınızı denormalize edin (ör. account_id'yi olaylara kopyalayın) pahalı join'lerden kaçınmak için.
raw_events'ı zamanla partitionlayın (günlük yaygın) ve opsiyonel olarak workspace/app ile. Olay türüne göre retention uygulayın:
Bu, “sonsuz büyüme”nün sessizce en büyük analitik sorununuz haline gelmesini engeller.
Kalite kontrollerini modellemenin bir parçası olarak görün, sonra temizlik yapmayın:
Doğrulama sonuçlarını (veya reddedilen olaylar tablosunu) saklayın ki enstrümantasyon sağlığını izleyip panolar sapmadan önce düzeltebilesiniz.
Olaylar akmaya başladıktan sonra, bir sonraki adım ham tıklamaları “Bu özellik gerçekten benimseniyor mu ve kim tarafından?” sorusunu yanıtlayan metriklere dönüştürmektir. Birlikte çalışan dört görünüme odaklanın: huniler, kohortlar, retention ve yollar.
Her özellik için bir huni tanımlayın, böylece kullanıcıların nerede düştüğünü görebilirsiniz. Pratik bir desen:
feature_used)\n- Tekrar kullanım → makul bir pencerede ikinci kullanım (ör. 7 gün içinde)\n- Değer eylemi → değeri kanıtlayan çıktı (export oluşturuldu, otomasyon etkinleştirildi, rapor paylaşıldı)Huni adımlarını güvendiğiniz olaylara bağlayın ve adımları tutarlı adlandırmayla koruyun. Eğer “ilk kullanım” birden fazla yolla olabiliyorsa, adımı OR koşulları ile tanımlayın (ör. import_started OR integration_connected).
Kohortlar, eski ve yeni kullanıcıları karıştırmadan iyileşmeyi ölçmenize yardımcı olur. Yaygın kohortlar:
Her kohort içinde benimseme oranlarını izleyin ki yeni onboarding veya UI değişikliklerinin işe yarayıp yaramadığını görün.
Retention, sadece “uygulama açma”dan ziyade bir özelliğe bağlıyken daha faydalıdır. Bunu özelliğin temel olayını (veya değer eylemini) belirli günlerde (Gün 7/30 gibi) tekrarlama olarak tanımlayın. Ayrıca “ikinci kullanıma geçen süre”yi izleyin—bu genellikle ham retention'dan daha hassastır.
Davranışı açıklayan boyutlara göre metrikleri parçalayın: plan, rol, sektör, cihaz, edinim kanalı. Segmentler genellikle benimsemenin bir grup için güçlü, diğerinde sıfıra yakın olduğunu ortaya çıkarır.
Yollar analizi, benimsemeden önceki ve sonraki yaygın dizileri bulmak için kullanılır (ör. benimseyen kullanıcılar genellikle pricing, sonra docs, sonra bir entegrasyonu bağlar). Bunu onboarding promolarını keskinleştirmek ve darboğazları kaldırmak için kullanın.
Panolar, herkese hizmet etmeye çalışan tek bir “ana görünüm” denemesiyle başarısız olur. Bunun yerine, farklı kişilerin karar verme biçimlerine uyan odaklı sayfalar tasarlayın ve her sayfanın net bir soruyu yanıtlamasını sağlayın.
Yönetici özeti hızlı bir sağlık kontrolü olmalı: benimseme trendi, aktif kullanıcılar, en iyi özellikler ve son sürümden bu yana dikkat çeken değişiklikler. Bir özellik derin dalışı PM'ler ve mühendisler için inşa edilmeli: kullanıcılar nereden başlıyor, nerede düşüyor ve hangi segmentler farklı davranıyor?
İyi çalışan basit yapı:
“Ne oldu” için trend grafiklerini, “kim” için segmentli kırılımları ve “neden” için drill-down'ı ekleyin. Drill-down, bir çubuk/puan tıklanınca örnek kullanıcıları veya workspaceleri (izinlere uygun olarak) göstermeli, böylece ekipler kalıpları doğrulayabilir ve gerçek oturumları inceleyebilir.
Filtreleri sayfalar arasında tutarlı tutun ki kullanıcılar kontrolleri yeniden öğrenmek zorunda kalmasın. Özellik benimseme takibi için en faydalı filtreler:
Panolar, insanlar gördüklerini paylaşabildiklerinde iş akışlarının parçası olur. Ekleyin:
Bir ürün analitiği web uygulamasına entegre ediyorsanız, “Pinned” kaydedilmiş görünümlerle stakehold'ların her zaman önemli raporlara inmesini sağlayan bir /dashboards sayfası düşünün.
Panolar keşif için iyiyken, ekipler genellikle bir müşteri şikayet ettiğinde sorunları fark eder. Uyarılar bunu tersine çevirir: bir şey dakika içinde bozulduğunda haberiniz olur ve ne değiştiğine bağlayabilirsiniz.
Temel benimseme akışınızı koruyan birkaç yüksek sinyalli uyarı ile başlayın:
feature_failed olayları). Hem mutlak eşikler hem de 1.000 oturum başına hata oranı gibi oran bazlı eşikler ekleyin.\n- Sürüm sonrası eksik olaylar (olay sayısı neredeyse sıfıra düşerse). Bu, özellikle refactor'lar sonrası kırık enstrümantasyonu yakalar.Uyarı tanımlarını okunabilir ve sürüm kontrolünde tutun (basit bir YAML dosyası bile) ki tribal bilgi haline gelmesin.
Temel anomali tespiti pahalı ML olmadan da çok etkili olabilir:
Grafiklere deploy işaretleri doğrudan ekleyin: dağıtımlar, feature flag rollout'ları, fiyatlama değişiklikleri, onboarding ayarları. Her işaret zaman damgası, sahibi ve kısa bir not içermeli. Metrikler değiştiğinde, olası nedenleri hemen görürsünüz.
Uyarıları e-posta ve Slack benzeri kanallara gönderin, fakat sessiz saatler ve yükseltme (uyarı → pager) destekleyin. Her uyarının bir sahibi ve kısa bir runbook bağlantısı olmalı (basit bir /docs/alerts sayfası bile) ki ilk bakışta ne kontrol edileceği belli olsun.
Analitik veriler hızlıca kişisel veri haline gelebilir. Gizliliği yasal bir sonradan düşünce olarak değil, takip tasarımının parçası olarak ele alın: bu riski azaltır, güven oluşturur ve can sıkıcı yeniden çalışmaları önler.
Rıza gereksinimlerine saygı gösterin ve gerektiğinde kullanıcıların izni olmadan veri toplamayın. Pratik olarak bu, takip katmanınızın gönderimden önce bir rıza bayrağını kontrol etmesi ve kullanıcı isteğiyle oturum sırasında takibi durdurabilmesi anlamına gelir.
Daha sıkı kuralları olan bölgelerde “rıza-gated” özellikleri düşünün:
Hassas veriyi minimize edin: olaylarda ham e-postalardan kaçının; hash/opaque ID kullanın. Olay yükleri davranışı (ne oldu) tanımlamalı, kimliği değil. Hesap ile ilişki gerektiğinde internal user_id/account_id gönderin ve eşlemeyi güvenli veritabanınızda tutun.
Ayrıca toplamayın:
Ne topladığınızı ve nedenini belgeleyin; okunabilir bir gizlilik sayfasına bağlantı verin. Her olayı, amacını ve retention süresini açıklayan hafif bir “takip sözlüğü” oluşturun. Ürün UI'sinde /privacy gibi bir yere işaret edin ve okunur tutun: neyi topladığınız, neyi toplamadığınız ve nasıl çıkılacağı.
Rol tabanlı erişim uygulayın ki sadece yetkili ekipler kullanıcı düzeyi veriyi görebilsin. Çoğu kişi yalnızca agregat panolara ihtiyaç duyar; ham olay görünümlerini küçük bir grupla sınırlayın (ör. data/product ops). Dışa aktarma ve kullanıcı aramaları için denetim kayıtları ekleyin ve eski verilerin otomatik olarak süresinin dolmasını sağlayın.
İyi yapıldığında, gizlilik kontrolleri analizi yavaşlatmaz—analitik sisteminizi daha güvenli, daha net ve sürdürülebilir kılar.
Analitiği yayınlamak bir özellik yayınlamak gibidir: küçük, doğrulanabilir bir ilk sürüm ve ardından istikrarlı iterasyon isteyeceksiniz. Takip işini üretim kodu gibi sahiplenin: sahipler, kod incelemeleri ve testler olsun.
Bir özellik alanı için sıkı bir setle başlayın: Feature Viewed, Feature Started, Feature Completed, Feature Error gibi. Bu olaylar ekibin haftalık soracağı sorularla doğrudan eşleşmeli.
Kapsamı kasıtlı dar tutun: daha az olay kaliteyi hızlı doğrulamanızı sağlar ve hangi özelliklere gerçekten ihtiyaç duyduğunuzu öğrenirsiniz (plan, rol, source, feature variant gibi) sonra ölçeklersiniz.
Takibi “tamam” saymadan önce bir kontrol listesi kullanın:
Staging ve production'da çalıştırabileceğiniz örnek sorgular ekleyin. Örnekler:
feature_name için en iyi 20 özellik değeri" (Search vs search gibi yazım hatalarını yakalamak için)\n- "Tamamlama oranı = Completed / Started by app version" (sürüm regresyonlarını tespit etmek için)Enstrümantasyonu sürüm sürecinizin bir parçası yapın:
Değişime hazırlıklı olun: olayları silmek yerine kullanım dışı bırakın, anlam değişince özellikleri versiyonlayın ve periyodik denetimler planlayın.
Yeni zorunlu bir özellik eklediğinizde veya bir hata düzelttiğinizde backfill gerekip gerekmediğine karar verin ve veri eksik olan zaman penceresini belgelendirin.
Son olarak, hafif bir takip rehberi dokümanı tutun ve panolardan, PR şablonlarından bu rehbere bağlantı verin. İyi bir başlangıç noktası kısa bir kontrol listesi gibi /blog/event-tracking-checklist olabilir.
Önce ürününüz için “benimseme”nin ne anlama geldiğini yazın:
Ardından, özelliğinizin değer sunma biçimine en uygun tanımı(ları) seçin ve bunları ölçülebilir olaylara dönüştürün.
Haftalık inceleyebileceğiniz küçük bir metrik seti ve her sürüm sonrası hızlı bir kontrol seçin. Yaygın benimseme metrikleri:
Sonuçların tartışma değil karar üretmesi için açık eşik değerleri ekleyin (ör. “30 günde ≥ %25 benimseme”).
Raporların anlaşılır kalması için başlangıçta temel varlıkları tanımlayın:
Tutarlı kalmasını sağlamak için verb_noun gibi bir konvansiyon kullanın ve ürün genelinde tek bir zaman kipinde (geçmiş veya şimdiki) tutun.
Pratik kurallar:
Her olayın segmentasyon ve birleştirme için yeterli olması adına minimal bir “olay kontratı” oluşturun. Yaygın bir temel:
user_id (anonimse nullable)İstemci tarafında niyeti, sunucu tarafında başarıyı takip edin.
Bu hibrit yaklaşım reklam engelleyiciler, sayfa yeniden yüklemeleri ve bağlantı kopmalarından kaynaklanan veri kaybını azaltırken benimseme metriklerinin güvenilir kalmasını sağlar. Bağlamı bağlamak için istemciden API'ye context_id (istek ID'si) geçirin ve sunucu olaylarına ekleyin.
Üç stabil anahtar kullanın:
anonymous_id (tarayıcı/cihaz başına)user_id (kişi başına)account_id (workspace başına)Anonim → tanımlanmış bağlamayı yalnızca güçlü kanıt (başarılı giriş, doğrulanmış magic link, SSO) olduğunda yapın. , , gibi kimlik geçişlerini olay olarak takip edin ve logout sırasında anonim cookie'yi döndürmeyin; aksi takdirde oturumlar parçalara ayrılır ve benzersiz kullanıcı sayıları şişer.
Benimseme nadiren tek bir tıklama olduğundan, bunu bir huni olarak modelleyin:
Eğer “ilk kullanım” birden fazla şekilde olabiliyorsa, bu adımı ile tanımlayın (ör. OR ) ve adımları güvenilir olaylara (çoğu zaman sunucu tarafı) bağlayın.
Ekiplerin gerçekten kullanacağı panolar oluşturmak için herkese tek bir “ana görünüm” sunmaya çalışmak yerine, karar verme biçimlerine göre odaklanmış birkaç sayfa tasarlayın.
Önerilen basit yapı:
Filtreleri sayfalar arasında tutarlı tutun (tarih aralığı, plan, hesap öznitelikleri, bölge, uygulama sürümü). Kaydedilmiş görünümler ve CSV dışa aktarma ekleyin ki paylaşımlar net olsun.
Boru hattınıza ve sürecinize güvenmek için koruyucu önlemler oluşturun:
Her olay için en az user_id (veya anonymous_id), account_id (uygunsa), timestamp ve küçük bir ilgili özellik seti (plan/rol/cihaz/flag) yakalayın.
clicked vs pressed)report_exported)feature_key (ör. bulk_upload) kullanınOlay adlarını ve tetiklendiği durumları kodla birlikte sakladığınız bir enstrümantasyon spesifikasyonunda belgeleyin.
anonymous_id (giriş öncesi davranış için)account_id (B2B/multi-seat için)timestamp (mümkünse sunucu tarafından oluşturulmuş)feature_keyplan (veya tier)Opsiyonel özellikleri sınırlı ve tutarlı tutun (aynı anahtarlar ve değer formatları).
login_successlogoutaccount_switchedimport_startedintegration_connectedevent_versionAyrıca gizliliği tasarımın bir parçası olarak ele alın: onay gating, ham e-posta/serbest metin toplama yasakları ve kullanıcı düzeyindeki verilere erişimi rollere ve denetim kayıtlarına tabi kılın.