Segmentasyon ve Kohort Analizi için Web Uygulaması Nasıl Kurulur

Başlamadan Önce: Açık Kullanım Senaryoları ve Başarı Metrikleri

Tabloları tasarlamadan veya araç seçmeden önce uygulamanın hangi soruları yanıtlaması gerektiğini netleştirin. “Segmentasyon ve kohortlar” birçok şeyi ifade edebilir; açık kullanım senaryoları, karar vermeye yardımcı olmayan özellik dolu bir ürün inşa etmenizi engeller.

İş sorularını tanımlayın

İnsanların hangi kararları almak istediğini ve hangi sayılara güveneceklerini yazın. Yaygın sorular arasında şunlar vardır:

• Tutma analizi: “Yeni kullanıcıların % kaçı 1. hafta, 4. hafta ve 12. hafta geri dönüyor?”
• Aktivasyon: “Hangi onboarding adımları ilk 24 saatte ‘aha’ noktasına ulaşmayla ilişkilendiriliyor?”
• Abonelik iptali (churn): “Fiyat değişikliğinden sonra hangi müşteri segmentleri iptal etmeye daha meyilli?”
• LTV (ömür boyu değer): “Partner A üzerinden edinilen kullanıcılar ücretli aramadan daha yüksek LTV üretiyor mu?”

Her soru için zaman penceresini (günlük/haftalık/aylık) ve granülasyonu (kullanıcı, hesap, abonelik) not edin. Bu, geri kalan yapıyı hizalar.

Kullanıcıları ve ihtiyaçlarını listeleyin

Birincil kullanıcıları ve iş akışlarını belirleyin:

• Pazarlama edinim kohortlarına, kampanya segmentasyonuna ve raporlar için hızlı dışa aktarımlara ihtiyaç duyabilir.
• Ürün özellik benimseme kohortlarına, funnel düşüşlerine ve sürüm açıklamaları için açıklamalara ihtiyaç duyabilir.
• Destek / Success hesap düzeyinde segmentlere (örn. “yüksek riskli müşteriler”) ve öncelikli erişim için basit filtrelere ihtiyaç duyabilir.

Ayrıca pratik ihtiyaçları yakalayın: panoları ne sıklıkla kontrol ediyorlar, onların için “bir tık” ne anlama geliyor ve hangi veriyi yetkili sayıyorlar.

MVP ile sonraki özellikleri ayırın

İlk sürümün üst düzey 2–3 soruyu güvenilir şekilde yanıtlayacak şekilde tanımlayın. Tipik MVP kapsamı: temel segmentler, birkaç kohort görünümü (tutma, gelir) ve paylaşılabilir panolar.

“Olsa iyi olur” maddelerini sonra bırakın: zamanlanmış dışa aktarımlar, uyarılar, otomasyonlar veya karmaşık çok adımlı segment mantığı gibi.

Hızlıca ilk sürüme ulaşmak kritikse, MVP'yi bir sohbet tabanlı platformla (ör. Koder.ai) iskeletleyerek hızlandırmayı düşünün. Sohbette segment oluşturucuyu, kohort ısı haritasını ve temel ETL ihtiyaçlarını tanımlayarak çalışan bir React ön yüzü ve Go + PostgreSQL arka uç üretebilir—ardından paydaşlar tanımları netleştirirken planlama modu, snapsh otlar ve geri alma ile yineleyebilirsiniz.

Başarı kriterlerini netleştirin

Başarı ölçülebilir olmalı. Örnekler:

• İçgörüye ulaşma süresini günlerden dakikalara düşürmek
• Tekrarlayan manuel raporları ortadan kaldırmak
• Self-servis kullanımını artırmak (örn. veri ekibi olmadan cevaplanan soruların oranı)
• Karar alma hızını iyileştirmek (örn. onboarding değişikliklerinde daha hızlı iterasyon)

Bu metrikler, ileride ortaya çıkan ödünler karşısında kuzey yıldızınız olur.

Veri Kaynaklarını Belirleyin ve Temel Kavramları Tanımlayın

Ekran tasarlamadan veya ETL işleri yazmadan önce sisteminizde “bir müşteri” ve “bir eylem”in ne anlama geldiğine karar verin. Kohort ve segmentasyon sonuçları, altındaki tanımlara bağlı olarak güvenilir olur.

Bir müşteri tanımlayıcı stratejisi seçin

Birincil bir tanımlayıcı seçin ve her şeyin ona nasıl eşleneceğini belgeleyin:

• user_id: kişi düzeyinde kullanım ve tutma için en uygun.
• account_id: birden çok kullanıcının tek bir ödeyen varlığa bağlandığı B2B için en uygun.
• anonymous_id: kayıt öncesi davranış için gerekli; daha sonra bilinen kullanıcı ile nasıl birleştirileceğine dair kurallar gerekir.

Kimlik birleştirmede açık olun: anonim ile bilinen profilleri ne zaman birleştirirsiniz ve bir kullanıcı birden fazla hesaba aitse ne olur?

Hangi veri kaynaklarının dahil edileceğine karar verin

Kullanım senaryolarınızı yanıtlayan kaynaklarla başlayın, sonra gerektiğinde ekleyin:

• Uygulama olayları (event tracking): tıklamalar, özellik kullanımı, oturumlar, onboarding kilometre taşları.
• CRM: edinim kaynağı, satış aşaması, hesap sahibi, yaşam döngüsü durumu.
• Faturalama: plan, MRR, faturalar, iadeler, deneme başlangıç/bitiş, iptaller.
• Destek: ticketlar, CSAT, çözüm süresi, sorun kategorisi.

Her kaynak için kayıt sistemi ve yenileme sıklığını (gerçek zamanlı, saatlik, günlük) not edin. Bu, “neden sayılar uyuşmuyor?” gibi tartışmaları önler.

Zaman, para birimi ve takvim kurallarını standardize edin

Raporlama için tek bir zaman dilimi belirleyin (çoğu zaman işletme zaman dilimi veya UTC) ve “gün”, “hafta” ve “ay”ın ne anlama geldiğini tanımlayın (ISO haftaları mı yoksa Pazar başlangıçlı mı). Gelirle ilgili işlem yapıyorsanız, para birimi kuralları seçin: saklanan para birimi, raporlama para birimi ve döviz kuru uygulanma zamanlaması.

Anahtar terimleri belgeleyin

Tanımları sade dilde yazın ve her yerde yeniden kullanın:

• Aktif kullanıcı (örnek: bir dönemde en az bir nitelikli etkinlik gerçekleştirdi)
• Churn olmuş (örnek: aboneliği iptal etmiş veya N gün boyunca etkinlik göstermemiş)
• Dönüşüm (örnek: deneme → ücretli, kayıt → aktivasyon)
• Kohort başlangıcı (örnek: kayıt tarihi, ilk satın alma tarihi veya ilk “aktif” tarih)

Bu sözlüğü bir ürün gereksinimi gibi ele alın: UI'da görünür olmalı ve raporlarda referans gösterilmelidir.

Segmentasyon için Veri Modelini Tasarlayın

Bir segmentasyon uygulaması veri modeline bağlıdır. Analistler yaygın soruları basit bir sorguyla yanıtlayamıyorsa, her yeni segment özel bir mühendislik işi haline gelir.

Pişman olmayacağınız bir event şemasıyla başlayın

Takip ettiğiniz her şey için tutarlı bir event yapısı kullanın. Pratik bir temel şunlardır:

• event_name (örn. signup, trial_started, invoice_paid)
• timestamp (UTC olarak saklayın)
• user_id (eylemi yapan)
• properties (utm_source, device, feature_name gibi esnek detaylar için JSON)

event_name'i kontrollü tutun (tanımlı bir liste) ve properties'i esnek tutun—ancak beklenen anahtarları belgeleyin. Bu, raporlama için tutarlılık sağlar ve ürün değişikliklerini engellemez.

Müşteri özniteliklerini olaylardan ayrı modelleyin

Segmentasyon çoğunlukla “kullanıcıları/hesapları özniteliklere göre filtreleme”dir. Bu öznitelikleri yalnızca event properties içinde bırakmayın; bu alanları adanmış tablolara koyun.

Yaygın öznitelikler:

• Plan/seviye (Free, Pro, Enterprise)
• Bölge/ülke
• Edinim kanalı (organik, ücretli arama, partner)
• Persona (varsa)

Bu, uzman olmayanların “SMB, AB bölgesinde, Pro plan, partner yoluyla edinilmiş” gibi segmentler oluşturmasını kolaylaştırır.

Yavaş değişen öznitelikler için plan yapın

Plan gibi birçok öznitelik zaman içinde değişir. Eğer yalnızca geçerli planı saklarsanız, tarihsel kohort sonuçları kayar.

İki yaygın desen:

• Type 2 history table (önerilir): account_plan_history(account_id, plan, valid_from, valid_to).
• Olay zamanında snapshot: önemli öznitelikleri her olaya kopyalayın (sorgular daha hızlı, depolama daha fazla, ETL daha karmaşık).

Sorgu hızı mı yoksa depolama/ETL basitliği mi önceliğiniz olduğunu belirleyin.

“events + users + accounts” yapısını kullanın

Basit, sorgu-dostu bir temel model:

• events: davranışsal gerçekler (user_id, account_id, event_name, timestamp, properties)
• users: kişi düzeyi öznitelikler (user_id, created_at, region, vb.)
• accounts: şirket/abonelik düzeyi öznitelikler (account_id, plan, industry, vb.)

Bu yapı, hem müşteri segmentasyonu hem de kohort/tutma analizine temiz bir şekilde eşlenir ve ürün, ekip ve raporlama ihtiyaçları arttıkça ölçeklenir.

Kohort Analizi Kurallarını ve Hesaplamaları Planlayın

Kohort analizi, kuralları kadar güvenilirdir. UI'yı inşa etmeden veya sorguları optimize etmeden önce uygulamanın kullanacağı kesin tanımları yazın ki her grafik ve dışa aktarma paydaşların beklediğiyle uyuşsun.

Kohort “başlangıç” türlerini seçin

Ürününüzün hangi kohort türlerine ihtiyaç duyduğunu seçin. Yaygın seçenekler:

• Kayıt kohortu: hesap oluşturma tarihine göre gruplanmış kullanıcılar.
• İlk satın alma kohortu: ilk ücretli sipariş tarihine göre müşteriler.
• Özellik benimseme kohortu: belirli bir özelliği ilk kullandıkları tarihe göre gruplanmış kullanıcılar (örn. “ilk proje oluşturma”, “bir ekip üyesi davet etme”).

Her tür tek ve belirsiz bir çapa olayına (anchor event) bağlanmalı; bu çapa kohort üyeliğini belirler. Kohort üyeliğinin değişmez mi (bir kez atandığında asla değişmez) yoksa tarihsel veri düzeltildikçe değişebilir mi karar verin.

Kohort indeks mantığını tanımlayın

Kohort indeksini (hafta 0, hafta 1 gibi sütunlar) nasıl hesaplayacağınızı tanımlayın:

• Zaman taneleme: günlük, haftalık veya aylık.
• İndeks 0’un anlamı: genellikle çapanın olduğu dönem (örn. kayıt tarihi).
• Takvim hizalaması: haftalar Pazartesi mi Pazar mı başlıyor; aylar takvim ayı mı yoksa 30 günlük pencere mi.
• Zaman dilimi: kullanıcı zaman dilimi, workspace zaman dilimi veya UTC (birini seçin ve bağlı kalın).

Küçük tercihler bile sayıları değiştirebilir ve uyuşmazlıklara yol açabilir.

Hücre başına metrikleri seçin

Her kohort tablosu hücresinin neyi temsil ettiğini tanımlayın. Tipik metrikler:

• Kalan kullanıcılar: o dönemde aktif olan kullanıcı sayısı.
• Gelir: kohorttaki kullanıcılara o dönemde atfedilen ödemelerin toplamı.
• Siparişler: dönemdeki satın alma sayısı.
• Oturumlar / eventler: etkileşim hacmi.

Ayrıca oran metrikleri için payda belirleyin (örn. tutma oranı = hafta N'de aktif kullanıcılar ÷ hafta 0 kohort büyüklüğü).

Kenar durumları baştan ele alın

Kohortlar sınır durumlarda karmaşıklaşır. Kuralları belirleyin:

• Gecikmiş eventler: bir event günler sonra gelirse, tarihsel kohortları yeniden mi hesaplarsınız yoksa bir kesme süresi sonrası sonuçları dondurur musunuz?
• İadeler / chargeback'ler: geliri iade döneminde mi düşersiniz yoksa orijinal satın alma dönemini mi yeniden ifade edersiniz?
• Yeniden aktivasyonlar: bir kullanıcı etkinliğe dönerse sonraki dönemde tutulan sayılır mı (genelde evet) ve “dirilme” ayrı takip edilir mi?

Bu kararları sade dilde belgeleyin; gelecekteki siz ve kullanıcılarınız minnettar olacaktır.

Veri Boru Hattını Oluşturun: Topla, Temizle ve Zenginleştir

Segmentasyon ve kohort analiziniz, içeri giren verilere bağlıdır. İyi bir boru hattı veriyi tahmin edilebilir kılar: her gün aynı anlam, aynı yapı ve doğru detay seviyesinde gelir.

Alım seçenekleri

Çoğu ürün, tek bir entegrasyon yoluna bağlı kalmamak için karışık kaynaklar kullanır:

• Tracking SDK (istemci tarafı): UI etkileşimlerini yakalamak için hızlı kurulum sağlar (sayfa görüntülemeleri, buton tıklamaları). Reklam engelleyiciler ve mobil bağlantı kopukluklarına dikkat edin.
• Sunucu tarafı eventler: ödemeler, abonelik değişiklikleri, iadeler gibi “gerçek kaynağı” için en iyisi ve istemci kaynaklı taklit veya çift kayıtları azaltır.
• Batch importlar: tarihsel backfill'ler, CRM dışa aktarımları veya başka bir analitik araçtan geçiş için kullanışlıdır. CSV yüklemelerini ve zamanlanmış importları destekleyin.

Pratik bir kural: temel kohortları besleyecek küçük bir “olmazsa olmaz” event seti tanımlayın (örn. signup, first value action, purchase), sonra genişletin.

Doğrulama ve hijyen kontrolleri

Kötü veri yayılmadan mümkün olduğunca yakınında doğrulama ekleyin.

Odaklanılacaklar:

• Gerekli alanlar: event adı, timestamp, user_id (veya anonymous_id) ve segmentlediğiniz varlık için stabil bir tanımlayıcı.
• Timestamp akıl sağlığı kontrolleri: imkansız tarihleri reddedin (çok uzak gelecek), zaman dilimlerini UTC'ye normalleştirin ve aşırı geç gelen eventleri işaretleyin.
• Çoğaltma (duplicate) işleme: event_id varsa dedupe edin; yoksa güvenli bir bileşik (user_id + event_name + timestamp bucket + anahtar properties) kullanın.

Kayıtları reddettiğinizde veya düzelttiğinizde, değişikliği açıklayabilmek için bir denetim (audit) loguna yazın.

Dönüşümler ve zenginleştirme

Ham veri tutarsızdır. Bunu temiz, tutarlı analitik tablolara dönüştürün:

• İsimleri normalize edin: event ve property isimlendirmesini standardize edin (örn. snake_case) ve eski isimler için bir eşleme tutun.
• ID eşlemeleri: anonim etkinliği login sonrası bilinen kullanıcıya bağlayın; user_id'yi account_id/organization_id ile ilişkilendirin.
• Özniteliklerle zenginleştirin: plan seviyesi, bölge, edinim kanalı, cihaz tipi veya yaşam döngüsü durumu gibi alanları join'leyin ki segmentler karmaşık join'ler gerektirmesin.

Zamanlama, yeniden deneme ve izleme

İşleri bir zaman çizelgesinde (veya streaming) çalıştırın ve operasyonel koruyucular ekleyin:

• Geçici hatalar için geri çekişli (backoff) yeniden denemeler
• Hacim düştüğünde/arta geçtiğinde veya tazelik SLA'sı aşıldığında uyarılar
• Her çalıştırma için denetim logları (girdi, çıktı, hatalar, sürümler)

Boru hattını bir ürün gibi ele alın: ölçümlendirin, izleyin ve sıkıcı derecede güvenilir tutun.

Depolama Seçimi ve Hızlı Analitik Sorgular için Optimizasyon

Analitik veriyi nerede sakladığınız, kohort panonuzun anlık mı yoksa yavaş mı hissedileceğini belirler. Doğru seçim veri hacmine, sorgu kalıplarına ve sonuçların ne kadar çabuk gerekli olduğuna bağlıdır.

Depolama motoru seçimi

Birçok erken aşama ürün için PostgreSQL yeterlidir: tanıdık, işletmesi ucuz ve SQL desteği güçlü. Event hacminiz orta düzeydeyse ve indeksleme/partitioninge dikkat ederseniz iyi çalışır.

Çok büyük event akışları (yüz milyonlarca—milyarlarca satır) veya çoklu eşzamanlı pano kullanıcıları bekliyorsanız, esnek analitik için bir veri ambarı (BigQuery, Snowflake, Redshift) veya son derece hızlı dilimleme/aggregasyon için bir OLAP deposu (ClickHouse, Druid) düşünün.

Pratik bir kural: “hafta bazında retention, segment filtreli” sorgunuz Postgres'te tuning sonrası bile saniyeler alıyorsa, ambar/OLAP bölgesine yaklaşıyorsunuz demektir.

Kohortlar ve segmentleri destekleyecek tablolar ve görünümler

Ham eventleri saklayın, ama analitik-dostu yapılar ekleyin:

• cohorts: kohort tanımı ve anahtar tarihleri (örn. kayıt haftası)
• segment_membership: user_id/account_id ile segment_id eşlemesi, üyeliğin değişebildiği durumlar için valid_from/valid_to
• aggregated_metrics (veya materialized views): tutma, aktivasyon, dönüşüm, gelir için ön-özetlenmiş sayımlar

Bu ayrım, kohortları/segmentleri yeniden hesaplamayı events tablosunu yeniden yazmadan yapmanızı sağlar.

Hız için indeksleme ve partitioning

Çoğu kohort sorgusu zaman, varlık ve event türüne göre filtreler. Öncelikler:

• event_time ile partitioning (veya clustering)
• user_id/account_id, event_name ve sık kullanılan filtre sütunlarında indeksler (plan, ülke, platform)
• En yaygın WHERE cümlelerini eşleyen bileşik indeksler (örn. (event_name, event_time))

Panoların en çok istediğini öngerçekleştirin

Panolar aynı aggregasyonları tekrar eder: kohortla tutma, haftalık sayımlar, segment bazlı dönüşümler. Bunları zamanlanmış olarak (saatlik/günlük) özet tablolar halinde precompute edin ki UI binlerce satır değil, birkaç bin satır okusun.

Ham veriyi drill-down için erişilebilir tutun, ama varsayılan deneyimi hızlı özetlere bağlayın. Bu “özgürce keşfet” ile “spinner bekle” arasındaki farktır.

Uzman Olmayanların Kullanabileceği Bir Segment Oluşturucu Uygulayın

Segment oluşturucu, segmentasyonun başarılı olup olmadığını belirler. SQL yazıyor gibi hissettirirse, çoğu ekip kullanmaz. Amacınız, birinin verinin nasıl depolandığını bilmeden kimi kastettiğini tarif edebilmesini sağlayan bir “soru oluşturucu”dur.

Segment kurallarını sade İngilizce (kullanıcı dili) gibi hissettirin

Gerçek sorulara karşılık gelen küçük bir kural setiyle başlayın:

• Filtreler (öznitelikler): Country = United States, Plan is Pro, Acquisition channel = Ads
• Aralıklar (sayısal/tarih): Tenure is 0–30 days, Revenue last 30 days > $100
• Davranışlar (eventler): Used Feature X at least 3 times in the last 14 days, Completed onboarding, Invited a teammate

Her kuralı, açılır menüler ve kullanıcı dostu alan adlarıyla bir cümle olarak render edin (iç kolon isimlerini gizleyin). Mümkünse örnekler gösterin (örn. “Tenure = ilk oturumdan bu yana geçen gün sayısı”).

AND/OR mantığını ve kayıtlı segmentleri destekleyin

Uzman olmayanlar gruplar halinde düşünür: “ABD ve Pro ve Feature X kullananlar”, istisnalarla birlikte “(ABD veya Kanada) ve churn olmamış”. Yaklaşılabilir tutun:

• Kurallar arasında varsayılan olarak AND kullanın.
• Bir OR grubu eklemeye izin verin (“Bunlardan herhangi biri eşleşsin”).
• NOT için basit bir açma/kapama sunun (“Dışla kullanıcıları…”).

Kullanıcıların segmentleri kaydetmesine izin verin: ad, açıklama ve isteğe bağlı sahip/ekip bilgisi eklenebilsin. Kaydedilmiş segmentler panolar ve kohort görünümleri arasında yeniden kullanılabilir olmalı ve versiyonlanmalı ki değişiklikler eski raporları gizlice bozmasın.

Segment boyutunu (ve örneklemeyi) sade dilde açıklayın

Builder içinde kurallar değiştikçe güncellenen tahmini veya kesin segment büyüklüğünü gösterin. Eğer hız için örnekleme kullanıyorsanız bunu açıkça belirtin:

• “%10 event örneklemesine göre tahmin gösteriliyor (±%2).”
• Gerekli olduğunda “Kesin sayıyı hesapla” eylemi sağlayın.

Ayrıca neyin sayıldığını gösterin: “Kullanıcılar bir kez sayıldı” vs “eventler sayıldı” ve davranış kuralları için kullanılan zaman penceresini gösterin.

Ek ayar yapmadan karşılaştırma yapmayı kolaylaştırın

Karşılaştırmaları birinci sınıf seçenek yapın: aynı görünümde Segment A vs Segment B seçilebilsin (tutma, dönüşüm, gelir). Kullanıcıları aynı grafiği çoğaltmaya zorlamayın.

Basit bir desen: başka bir kaydedilmiş segment veya ad-hoc segment kabul eden “Karşılaştır…” seçici; net etiketler ve tutarlı renkler kullanın.

Kohort Panosu ve Raporlama UI'sını Tasarlayın

Bir kohort panosu başarısız olduğunda değil, bir soruyu hızlı yanıtladığında başarılıdır: “İnsanları tutuyor muyuz yoksa kaybediyor muyuz ve neden?” UI patternleri desenleri görmeyi kolaylaştırmalı, sonra okuyucuların detaylara SQL bilmeden inmesine izin vermeli.

Isı haritasını önce okunabilir yapın

Kohort ısı haritasını ana görünüm olarak kullanın, ama bunu bulmaca gibi değil rapor gibi etiketleyin. Her satır açıkça kohort tanımını ve boyutunu göstermeli (örn. “7 Eki haftası — 3.214 kullanıcı”). Her hücre yüzde ve mutlak sayılar arasında geçiş yapabilmeli; yüzdeler ölçeği gizler, sayılar oranı.

Sütun başlıklarını tutarlı tutun (“Hafta 0, Hafta 1, Hafta 2…” veya gerçek tarihler) ve satır etiketinin yanında kohort büyüklüğünü gösterin ki okuyucu güven aralığını değerlendirebilsin.

İnsanların tereddüt ettiği metrikleri açıklayın

Her metrik etiketine (Retention, Churn, Revenue, Active users) tooltip ekleyin ve şunu belirtin:

• pay ve payda nedir
• hangi zaman penceresi kullanıldı
• bunun “geri dönen kullanıcılar” mı yoksa “X eventini yapan kullanıcılar” mı olduğu

Kısa bir tooltip, uzun yardım sayfasından daha etkilidir; karar anında yanlış yorumlamayı engeller.

Güvenli hissettiren filtreler

Isı haritasının üzerine en yaygın filtreleri koyun ve geri alınabilir yapın:

• Tarih aralığı
• Kohort türü (kayıt tarihi, ilk satın alma tarihi, ilk oturum)
• Segment, plan, kanal

Aktif filtreleri etiketler (chip) halinde gösterin ve tek tıkla “Reset” sunun ki insanlar keşfetmeye çekinmesin.

Paylaşma ve dışa aktarma kaosunu önleyin

Geçerli görünüm için CSV dışa aktarımı sağlayın (filtreler ve yüzde/mutlak gösterim dahil). Ayrıca yapılandırmayı koruyan paylaşılabilir linkler sunun. Paylaşırken izinleri zorunlu kılın: bir link izleyicinin zaten sahip olduğu erişimden fazlasını vermemeli.

Bir “Bağlantıyı kopyala” eylemi varsa kısa bir onay gösterin ve kimlerin ne görebileceğini yönetmek için /settings/access metnini gösterin.

Güvenlik, Gizlilik ve Erişim Kontrolünü Ele Alın

Segmentasyon ve kohort analiz araçları genellikle müşteri verilerine dokunur; bu yüzden güvenlik ve gizlilik sonradan düşünülmemeli. Bunları ürün özellikleri gibi ele alın: kullanıcıları korur, destek yükünü azaltır ve ölçeklendikçe uyumluluğu sağlar.

Kimlik doğrulama ve roller

Hedef kitlenize uygun kimlik doğrulamadan başlayın (B2B için SSO, SMB için e-posta/şifre veya ikisi). Sonra basit, tahmin edilebilir roller uygulayın:

• Admin: workspace, bağlantılar, retention ayarları ve izinleri yönetir.
• Analyst: segmentler, kohortlar, panolar ve zamanlanmış raporlar oluşturur.
• Viewer: panoları ve kaydedilmiş segmentleri görüntüler, tanımları değiştiremez.

İzinleri UI ve API genelinde tutarlı hale getirin. Bir endpoint kohort verisi dışa aktarabiliyorsa, yalnızca UI izni yeterli değildir—sunucu tarafında da kontroller uygulayın.

Workspace izolasyonu ve satır düzeyi erişim

Uygulamanız birden fazla workspace/müşteri destekliyorsa, “biri başka workspace verisini görmeye çalışacak” varsayımıyla tasarlayın:

• Eventleri, kullanıcıları, segmentleri ve panoları saklayan her tablo workspace_id içermeli.
• Tüm analitik sorgular otomatik olarak aktif workspace'e göre scope edecek şekilde row-level security (RLS) veya eşdeğer filtreleme uygulayın.
• Workspace'ler arasında paylaşılan cache'lerden kaçının veya cache anahtarının workspace_id'yi içerdiğinden emin olun.

Bu, analistlerin özel filtreler oluştururken yanlışlıkla tenant verisi sızdırmasını önler.

Kişisel veri (PII) yönetimi: daha az topla, daha az göster

Çoğu segmentasyon ve tutma analizi ham kişisel veriler olmadan yapılabilir. Alınan veriyi azaltın:

• E-postalar/telefon numaraları yerine kararlı dahili ID'ler ve hashlenmiş tanımlayıcılar tercih edin.
• Hassas alanları daha sıkı erişim kurallarıyla ayrı saklayın.
• UI'da değerleri varsayılan olarak maskelenmiş gösterin (örn. son 2–4 karakter) ve açmak için yükseltilmiş izin gerektirin.

Ayrıca veriyi dinamik ve beklemede şifreleyin, gizli anahtarları uygun bir secrets manager'da saklayın.

Saklama ve silme iş akışları

Workspace başına saklama politikalarını tanımlayın: ham eventler, türetilmiş tablolar ve dışa aktarımlar ne kadar süre saklanacak. Silme iş akışları veriyi gerçekten kaldırmalı:

• user ID ile raw eventler ve türetilmiş agregalar üzerinden silme.
• etkilenen kohortları/segmentleri yeniden hesaplama (veya bunları bayat işaretleyip bir sonraki çalıştırmada yenileme).
• isteği ve sonucu denetim kaydında tutma.

Saklama/silme iş akışı, kohort grafikleri kadar önemlidir.

Doğruluk, Veri Kalitesi ve Performans için Test Yapın

Bir analitik uygulamasını test etmek sadece “sayfa yükleniyor mu?” demek değildir. Kararlar gönderiyorsunuz. Kohort tutmasında küçük bir hesaplama hatası veya segmentasyon filtrasyonunda gizli bir hata tüm ekipleri yanlış yönlendirebilir.

Doğruluk: kohort matematiğini kilitleyin

Kohort hesaplamalarınızı ve segment mantığınızı küçük, bilinen fixture'lar kullanarak birim testleri ile doğrulayın. Küçük bir veri seti oluşturun ve “doğru cevap”ın açık olduğu durumları test edin (örn. 10 kullanıcı 1. haftada kaydoldu, 4'ü 2. haftada geri döndü → %40 tutma). Test edin:

• Kohort atama kuralları (kayıt tarihi vs ilk event tarihi)
• Zaman bölme (gün/hafta/ay sınırları, zaman dilimi işlemleri)
• Segment filtreleri (AND/OR mantığı, dışlama, null işlemleri)
• Kenar durumlar (geri dönmeyen kullanıcılar, geç gelen eventler)

Bu testler CI'de çalışmalı ki sorgu mantığı veya aggregasyonlarda her değişiklik otomatik kontrol edilsin.

Veri kalitesi: kullanıcılar fark etmeden önce sorunları yakalayın

Analitik arızalarının çoğu veri arızasıdır. Her yüklemede veya en azından günlük olarak otomatik kontroller ekleyin:

• Eksik veya çoğaltılmış tanımlayıcılar (user_id, account_id)
• Event hacminde düşüş/ani artış (takibin kırıldığını gösterir)
• Şema değişiklikleri (yeni/eksik property, tip değişimleri)
• “İmkansız” değerler (negatif süreler, gelecek timestamp'ler)

Bir kontrol başarısız olduğunda, hangi event, hangi zaman penceresi ve sapmanın ne kadar olduğu gibi yeterli bağlamla uyarı verin.

Performans: ağır sorguları öngörülebilir kılın

Gerçek kullanım senaryolarını taklit eden performans testleri çalıştırın: geniş tarih aralıkları, çoklu filtreler, yüksek cardinality property'ler ve iç içe segmentler. p95/p99 sorgu sürelerini takip edin ve bütçeler belirleyin (örn. segment önizleme 2 saniyenin altında, pano 5 saniyenin altında). Testlerde regresyon olursa bir sonraki sürümde bunu bilirsiniz.

Kullanıcı kabulü: gerçek soruları doğrulayın

Son olarak, ürün ve pazarlama ekipleriyle kullanıcı kabul testleri yapın. Bugün sordukları gerçek soruları toplayın ve beklenen cevapları tanımlayın. Uygulama güvenilir sonuçları (veya neden farklı olduğunu açıklayabiliyorsa) üretemiyorsa, yayınlamaya hazır değildir.

Dağıtın, İzleyin ve Zaman İçinde İyileştirin

Segmentasyon ve kohort analiz uygulamanızı göndermek büyük bir lansmandan çok güvenli bir döngü kurmaktır: yayınla, gözle, öğren ve iyileştir.

Bir dağıtım yaklaşımı seçin

Ekip yeteneklerinize ve uygulamanın ihtiyaçlarına uyan yolu seçin.

Yönetilen hosting (örn. Git üzerinden dağıtım yapan platformlar) genellikle güvenilir HTTPS, geri alma ve otomatik ölçekleme sağlar ve en az ops işi gerektirir.

Konteynerler, çalışma zamanı davranışının tutarlı olması veya bulut sağlayıcılar arasında taşınma ihtiyacı varsa uygundur.

Serverless, kullanımın düzensiz olduğu durumlarda işe yarayabilir, ancak cold start'lar ve uzun süreli ETL işler konusunda dikkatli olun.

Eğer prototipten üretime uçmadan uçuşa kadar bir yol istiyorsanız, Koder.ai React + Go + PostgreSQL üreten, dağıtan ve barındıran; özel domain eklemeye, snapshot/rollback yapmaya olanak veren bir çözüm sunar.

Riskli veri kullanmadan ayrı ortamlar

Dev, staging ve production olmak üzere üç ortam kullanın.

Dev ve staging'de gerçek müşteri verisi kullanmaktan kaçının. Üretimi andıran yapıda (aynı sütunlar, aynı event tipleri, aynı kenar durumları) güvenli örnek veri yükleyin. Bu, testleri gerçekçi tutar ama gizlilik sorunlarını önler.

Staging'i prod benzeri kıyafet provası yapın: prod benzeri altyapı, izole kimlik bilgileri, izole veritabanları ve feature flag'lerle kohort kurallarını test edin.

İşe yarar gözlemlenebilirlik

Ne kırıldığını ve ne yavaşladığını izleyin:

• Request ID, kullanıcı/organizasyon bağlamı ve kohort/segment ID'leriyle loglar
• Front-end ve back-end istisnaları için hata takibi
• Panonun en yavaş endpoint'leri için sorgu zamanlamaları
• Boru hattı sağlığı: son başarılı çalıştırma, gecikme ve adım başına satır sayıları

ETL başarısızlıkları, artan hata oranları veya sorgu zaman aşımı sıklığındaki ani artış için basit uyarılar (e-posta/Slack) ekleyin.

İterasyonla geliştirin

Karmaşık olmayan kullanıcı geri bildirimlerine göre aylık (veya iki haftada bir) sürümler planlayın: kafa karıştıran filtreler, eksik tanımlar veya “neden bu kullanıcı bu kohortta?” soruları. Yeni kohort türleri, daha iyi UX varsayılanları ve daha net açıklamalar gibi raporları bozmadan karar alma sürecini açan eklentileri önceliklendirin. Feature flag'ler ve versiyonlanmış hesaplamalar güvenli evrim sağlar.

Eğer ekibiniz öğrendiklerini paylaşırsa, bazı platformlar (Koder.ai dahil) oluşturduğunuz build hakkında içerik yaratarak veya başkalarını yönlendirerek kredi kazanma programları sunar—hızlı deneme-yanılma maliyetlerini düşürmek için faydalı olabilir.