Özellik Benimsemesini ve Kullanıcı Davranışını İzleyen Bir Web Uygulaması Nasıl Kurulur

Hedefleri, Soruları ve Başarı Metriklerini Tanımlayın

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”yi sade terimlerle tanımlayın

Benimseme genellikle tek bir an değildir. Değerin nasıl sağlandığına uyan bir veya daha fazla tanım seçin:

• Kullanım: bir kullanıcı özelliği en az bir kez dener (yeni lansmanlar için iyi).\n- Tekrar kullanım: kullanıcı belirli bir zaman penceresinde tekrar kullanır (alışkanlık oluşturan iş akışları için iyi).\n- Değer sağlandı: kullanıcı, özelliğin sağlamayı amaçladığı sonucu elde eder (çoğunlukla en iyi sinyal).

Ö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.

Takibin hangi kararları desteklemesi gerektiğini listeleyin

Takibiniz eyleme dönüşecek soruları yanıtlamalı, örneğin:

• Hangi şeyi iyileştirmeliyiz çünkü kullanılıyor ama değer sağlamada başarısız oluyor?
• Hangi şeyi kaldırmalıyız çünkü düşük benimseme ile karmaşıklık ekliyor?
• Hangi şeyi öne çıkarmalıyız çünkü retention veya yükseltmeleri tetikliyor?

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.”).

Paydaşları ve raporları nasıl kullanacaklarını belirleyin

Farklı ekiplerin farklı görünümlere ihtiyacı vardır:

• Product (PM): segmentlere göre benimseme, sürüm sonrası etki, değer kilometre taşları.\n- Growth/Marketing: kampanya etkisi, dönüşüm hunileri, yeniden etkileşim.\n- Support/Success: hangi özelliklerin daha az ticket veya daha yüksek yenileme ile ilişkili olduğu.\n- Mühendislik: enstrümantasyon sağlığı, olay hacmi değişiklikleri, sürüm işaretleri.

Başarı metriklerini ve gözden geçirme sıklığını belirleyin

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.

İhtiyacınız Olan Veriyi Haritalandırın: Kullanıcılar, Özellikler, Olaylar, Sonuçlar

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.

Temel varlıklardan başlayın

Her varlığı sade dilde tanımlayın, sonra saklayabileceğiniz ID'lere çevirin:

• Kullanıcı: uygulamayı kullanan kişi (başlangıçta anonim, sonra kimlik doğrulanmış olabilir).\n- Hesap / workspace: birden fazla kullanıcının ait olduğu ödeyen müşteri veya ekip konteyneri.\n- Oturum (Session): zamanla sınırlı ziyaret (etkileşim ve hata ayıklama için faydalı; bazı ürünler için isteğe bağlı).\n- Özellik: benimsemesini ölçmek istediğiniz adlandırılmış yetenek (çoğunlukla tek bir tıklama değil, bir dizi olay).\n- Olay: kaydedebileceğiniz bir eylem veya sistem olayı (ör. 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.

Destekleyeceğiniz benimseme görünümlerini seçin

Ürün hedeflerinize uyan raporlama açılarından bazılarını seçin:

• Huniler (adım adım aktivasyon)\n- Kohortlar (kayıt tarihine, plana, kanala göre gruplar)\n- Retention (geri gelip ana eylemleri tekrar ediyorlar mı?)\n- Yollar (Paths) (bir kilometre taşından önce/sonra yaygın diziler)\n- İlk değere ulaşma süresi (ilk anlamlı sonuca ne kadar sürede ulaşılıyor)

Olay tasarımınız bu hesaplamaları basit hale getirmeli.

Platformları ve performans hedeflerini belirleyin

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.

Tutarlı Kalan Bir Olay İzleme Şeması Tasarlayın

İ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.

Açık bir adlandırma konvansiyonuyla başlayın

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_report

Geç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.

Gerekli özellikleri ("kontrat") tanımlayın

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 özelliklere dikkatli izin verin

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ı versiyonlayın ve bir enstrümantasyon spesifikasyonu yazın

Ş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 Problemini Çözün: Anonim, Giriş Yapmış ve Hesap Düzeyi Görünümler

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.

Anonim vs tanımlanmış kullanıcılar (ve ne zaman bağlanmalı)

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.

Giriş, çıkış ve hesap değiştirmenin metrikleri bozmadan ele alınması

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.

Kimlik birleştirme kuralları (çift sayımı önleme)

Birleştirme kurallarını açıkça tanımlayın:

• Kullanıcı birleştirme: stabil dahili 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.
• Hesap birleştirme: sisteminiz tarafından oluşturulan stabil bir 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.

Stabil anahtarları saklayın

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.

İstemci Tarafı vs Sunucu Tarafı Takibi Seçin (ve Karıştırın)

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.

İstemci-tarafı takip (tarayıcı)

Tarayıcıda UI etkileşimleri ve sadece tarayıcıda olan bağlam için istemci tarafı takibi kullanın. Tipik örnekler:

• Sayfa/ekran görüntülemeleri, buton tıklamaları, sekme değişimleri, modal açma/kapatma\n- “Özellik görüldü” anları (ör. ayarlar sayfası açıldı)\n- İstemci bağlamı: URL, referrer, UTM etiketleri, cihaz, viewport boyutu, dil

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.

Sunucu-tarafı takip (API'ler ve işler)

Tamamlanmış çıktıyı veya faturalama/güvenlik açısından hassas eylemleri temsil eden her olay için sunucu tarafı takibini kullanın:

• Özellik başarılı şekilde etkinleştirildi/kayıt edildi\n- Davet kabul edildi, ödeme başarılı, export üretildi\n- Arka plan işleri: senkronizasyon tamamlandı, rapor teslim edildi, e-posta gönderildi

Sunucu tarafı genellikle daha doğrudur çünkü reklam engelleyiciler, sayfa yeniden yüklemeleri veya kopuk bağlantılardan etkilenmez.

Önerilen yaklaşım: varsayılan olarak hibrit

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.

Güvenilirlik: yeniden deneme, backoff, çevrimdışı tamponlama

Olayların en çok kaybolduğu yerlerde dayanıklılık ekleyin:

• İstemci: küçük bir kuyruğu 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.

Sistem Mimarisi Planlayın: Alma (Ingestion), Depolama ve Sorgu

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.

Temel bileşenler (ve neden önemli oldukları)

Basit, ayrılabilir bir hizmet setiyle başlayın:

• Collector endpoint: tarayıcı, mobil ve backend'den gelen olayları alan küçük bir HTTP servisi. Hızlı ve minimal tutun—temelleri doğrulayın, sunucu zaman damgası ekleyin ve hızlı dönüş yapın.\n- Kuyruk/stream: trafik dalgalanmalarını sönümlendirir ve alımı işlemden ayırır (Kafka, Kinesis, Pub/Sub, SQS).\n- Workers: stream'i tüketip zenginleştirme, dedupe, şema uygulama ve veriyi depolamaya yönlendirme işleri yapar.\n- Analitik store: büyük, eklemeli olay verisi için optimize edilmiş depolama (ClickHouse, BigQuery, Snowflake, Redshift).\n- API: panolar (huniler, kohortlar, retention) için tutarlı sorgu uçları ve izinler sağlar.\n- UI: panolar ve keşif araçları; bunu ayrı tutun ki depolama/sorgu mantığını değiştirdiğinizde frontend'i yeniden yazmanız gerekmesin.

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.

Depolama: ham olaylar vs. agregatlar

İki katman kullanın:

• Eklemeli ham olaylar denetim izlenebilirliği ve yeniden işleme için. Bunu gerçek kaynak olarak kabul edin.\n- Agregatlar/materialize edilmiş görünümler hız için (günlük aktif kullanıcılar, feature_active_users, huni adım sayıları). Sürekli çalıştırılan aynı sorgular için materialized view'lar özellikle yararlıdır.

Gerçek zamanlı vs. toplu (kararlar temelinde seçin)

Ekibinizin gerçekten ihtiyaç duyduğu tazeliği seçin:

• Yakın gerçek zamanlı (saniyeler/dakikalar) lansmanları, onboarding düşüşlerini veya kesintileri izlemek için.\n- Günlük toplu trend raporlaması, haftalık benimseme ve yönetici özetleri için—daha ucuz ve genellikle daha basit.

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.

Ölçek planı: partitioning ve büyüme

Büyüme için erken tasarlayın:

• Zamana göre (günlük/aylık) partitioning, sorguları sınırlı tutar ve retention politikalarını kolaylaştırır.\n- Hesap/tenant'a göre partitioning, B2B izinleri ve performans için faydalıdır.\n- Opsiyonel olarak olay türüne göre partitioning, birkaç yüksek hacimli olay baskınsa işe yarar.

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.

Olaylar ve Hızlı Analitik Sorguları için Veri Modelleme

İ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.

İki katmanlı veritabanı stratejisi seçin

Çoğu ekip için iki depo en iyisidir:

• İlişkisel DB (Postgres/MySQL) yavaş değişen meta veriler için: kullanıcılar, hesaplar, özellik tanımları, erişim kontrolü, konfigürasyon.\n- Sütunlu/warehouse (ClickHouse/BigQuery/Snowflake) yüksek hacimli olaylar için; hızlı taramalar ve agregasyonlar gerekiyorsa.

Bu ayrım, ürün veritabanınızı hafif tutar ve analitik sorguları daha ucuz/ hızlı yapar.

Temel tabloları tanımlayın (ve sıkıcı tutun)

Pratik bir temel şöyle görünür:

• raw_events: her olay için bir satır (event_name, timestamp, user_id/anonymous_id, session_id, account_id, properties JSON, source).\n- users: kullanıcı profili + mevcut tanımlayıcılar.\n- accounts: B2B rollupları için şirket/organizasyon varlığı.\n- feature_catalog: kanonik özellik listeniz (key, display_name, category, lifecycle status).\n- sessions: oturum sınırları (başlangıç/bitiş, cihaz, referrer) davranış analizi için.\n- aggregates: önceden hesaplanmış günlük/haftalık metrikler (ör. DAU, feature_active_users, huni adım sayıları).

Datawarehouseda sık sorguladıklarınızı denormalize edin (ör. account_id'yi olaylara kopyalayın) pahalı join'lerden kaçınmak için.

Maliyeti ve hızı retention + partitioning ile kontrol edin

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:

• Yüksek seviye ürün olaylarını daha uzun tutun (aylar/yıllar).\n- Gürültülü debug olaylarını hızlıca silin.

Bu, “sonsuz büyüme”nün sessizce en büyük analitik sorununuz haline gelmesini engeller.

Veri kalite kontrollerini modele dahil edin

Kalite kontrollerini modellemenin bir parçası olarak görün, sonra temizlik yapmayın:

• Eksik zorunlu özellikler (ör. feature_key)\n- Hatalı zaman damgaları (gelecek tarihler, timezone parsing sorunları)\n- Çift olaylar (yeniden denemeler, çift enstrümantasyon)

Doğrulama sonuçlarını (veya reddedilen olaylar tablosunu) saklayın ki enstrümantasyon sağlığını izleyip panolar sapmadan önce düzeltebilesiniz.

Benimseme Metriklerini Hesaplayın: Huniler, Kohortlar, Retention ve Yollar

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.

Huniler: benimseme bir sıra olarak (tek tıklama değil)

Her özellik için bir huni tanımlayın, böylece kullanıcıların nerede düştüğünü görebilirsiniz. Pratik bir desen:

• Keşif → kullanıcı özellik giriş noktasını görür (buton, menü, banner)\n- İlk kullanım → ilk anlamlı etkileşim (ör. 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: benzerleri birbirine karşılaştırın

Kohortlar, eski ve yeni kullanıcıları karıştırmadan iyileşmeyi ölçmenize yardımcı olur. Yaygın kohortlar:

• Haftalık yeni kullanıcılar (kayıt haftası)\n- Aktive olmuş kullanıcılar (aktivasyon olayına ulaşmış)\n- Retained kullanıcılar (geri gelip anlamlı bir şey yapmış)\n- Power kullanıcılar (yüksek sıklık veya gelişmiş eylemler)

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: “geri gelip kullanmaya devam ediyorlar mı?”

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.

Segmentasyon ve yollar: kim benimser ve nasıl ulaşırlar

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.

İnsanların Gerçekten Kullanacağı Panolar Oluşturun

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.

Hedef kitleye özel sayfalarla baş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ı:

• Genel Bakış: benimseme trendi, retention trendi ve birkaç başlık KPI\n- Özellik sayfası: huni, kohort retention ve bir özellik için kullanım sıklığı\n- Segment gezgini: planlar, bölgeler veya workspace boyutlarını yan yana karşılaştırma

Keşfi kolaylaştırın (karışık yapmadan)

“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:

• Tarih aralığı\n- Plan / seviye\n- Workspace/hesap öznitelikleri (büyüklük, sektör)\n- Bölge\n- Uygulama sürümü (veya sürüm kanalı)

Paylaşma, dışa aktarma ve kaydedilmiş görünümler

Panolar, insanlar gördüklerini paylaşabildiklerinde iş akışlarının parçası olur. Ekleyin:

• CSV dışa aktarma hızlı analiz için\n- Kaydet ve paylaş edilebilen bir görünüm (filtreler + grafik durumu + seçili segment)\n- Opsiyonel planlı e-posta/Slack özetleri, kaydedilmiş görünüme işaret eden

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.

Uyarılar, Anomali Tespiti ve Sürüm İşaretleri Ekleyin

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.

Gerçek hata modlarına uyan uyarı kuralları belirleyin

Temel benimseme akışınızı koruyan birkaç yüksek sinyalli uyarı ile başlayın:

• İlk kullanımda ani düşüş (ör. “Feature X: first_use” olayları/saat %40 düşüş). Bu genellikle bir UI regresyonu, izin değişikliği veya takip hatasıdır.\n- Hata spike'ı (istemci hataları, API 4xx/5xx veya 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.

Anomali tespiti: önce basit tutun

Temel anomali tespiti pahalı ML olmadan da çok etkili olabilir:

• Güncel değerleri geri dönük ortalamayla karşılaştırın (ör. son 7 gün, aynı saat dilimi).\n- Sezonellik farkındalığı ekleyin (hafta içi vs hafta sonu, mesai saatleri vs gece) gerektiği yerde.\n- Düşük trafik metriklerinin spam yapmaması için minimum hacim kuralı kullanın.

Sürüm işaretleri: “ne değişti?” için zaman çizelgesi

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.

Yönlendirme, sessiz saatler ve sahiplik

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.

Gizlilik, Rıza ve Erişim Kontrolü

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: kullanıcıların onayladığını toplayın

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:

• Analitik kütüphaneleri yalnızca rızadan sonra yükleyin (sadece "göndermeyi durdur" değil).\n- Rıza kararını zaman damgası ve versiyon ile saklayın ki kullanıcı neyi kabul ettiğinizi ispatlayabilesiniz.\n- Üründe basit bir tercih UI'si sağlayın.

Hassas veriyi minimize edin (ve olaylara sokmayı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:

• Serbest metin alanları (genelde yanlışlıkla kişisel bilgi içerir)\n- Token veya query parametreleri içerebilecek tam URL'ler\n- Ekran görüntüsünde görünmesini istemeyeceğiniz herhangi bir şey

Şeffaf olun: dokümantasyon ve açık bir gizlilik sayfası

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ğı.

Erişim kontrolü: kullanıcı düzeyi veriyi kim görebilir kısıtlayın

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.

Yaygınlaştırma Planı, QA ve Uzun Vadeli Bakım

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.

"Golden event"lerle küçük başlayın

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 staging ve production'da doğrulayın

Takibi “tamam” saymadan önce bir kontrol listesi kullanın:

• Olay bir kez ateşleniyor (yeniden yükleme, retry veya SPA rota değişikliklerinde çift tetikleme yok)\n- Gerekli özellikler mevcut ve tipleri tutarlı\n- PII dışlandı veya uygun şekilde maskelendi\n- Olaylar beklenen gecikme içinde alınıyor\n- Kimlikler doğru şekilde bağlanıyor (anonim → girişli)

Staging ve production'da çalıştırabileceğiniz örnek sorgular ekleyin. Örnekler:

• "Son 30 dakikada olay isimlerine göre say" (eksik/fazla olayları tespit etmek için)\n- "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)

Her sürüm için enstrümantasyon QA iş akışı

Enstrümantasyonu sürüm sürecinizin bir parçası yapın:

1. Takip değişikliği UI/API değişikliğiyle aynı PR içinde\n2. İnceleyen kişi olay isimlerini/özellikleri şema ile karşılaştırır\n3. QA, staging'de bilinen bir test hesabıyla olayları doğrular\n4. Sürüm notu herhangi bir takip değişikliğini içerir (yeni olaylar, yeniden adlandırılan özellikler)

Uzun vadeli bakım (şema, backfill'ler, dökümantasyon)

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.