23 Ara 2025·8 dk
Segmentasyon ve Kohort Analizi için Web Uygulaması Nasıl Kurulur
Müşteri segmentasyonu ve kohort analizi için web uygulaması oluşturma rehberi: veri modeli, boru hattı, UI, metrikler ve dağıtım adım adım.
Müşteri segmentasyonu ve kohort analizi için web uygulaması oluşturma rehberi: veri modeli, boru hattı, UI, metrikler ve dağıtım adım adım.
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.
İnsanların hangi kararları almak istediğini ve hangi sayılara güveneceklerini yazın. Yaygın sorular arasında şunlar vardır:
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.
Birincil kullanıcıları ve iş akışlarını belirleyin:
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.
İ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ı ölçülebilir olmalı. Örnekler:
Bu metrikler, ileride ortaya çıkan ödünler karşısında kuzey yıldızınız olur.
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.
Birincil bir tanımlayıcı seçin ve her şeyin ona nasıl eşleneceğini belgeleyin:
Kimlik birleştirmede açık olun: anonim ile bilinen profilleri ne zaman birleştirirsiniz ve bir kullanıcı birden fazla hesaba aitse ne olur?
Kullanım senaryolarınızı yanıtlayan kaynaklarla başlayın, sonra gerektiğinde ekleyin:
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.
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ı.
Tanımları sade dilde yazın ve her yerde yeniden kullanın:
Bu sözlüğü bir ürün gereksinimi gibi ele alın: UI'da görünür olmalı ve raporlarda referans gösterilmelidir.
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.
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.
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:
Bu, uzman olmayanların “SMB, AB bölgesinde, Pro plan, partner yoluyla edinilmiş” gibi segmentler oluşturmasını kolaylaştırır.
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:
account_plan_history(account_id, plan, valid_from, valid_to).Sorgu hızı mı yoksa depolama/ETL basitliği mi önceliğiniz olduğunu belirleyin.
Basit, sorgu-dostu bir temel model:
user_id, account_id, event_name, timestamp, properties)user_id, created_at, region, vb.)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ı 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.
Ürününüzün hangi kohort türlerine ihtiyaç duyduğunu seçin. Yaygın seçenekler:
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 indeksini (hafta 0, hafta 1 gibi sütunlar) nasıl hesaplayacağınızı tanımlayın:
Küçük tercihler bile sayıları değiştirebilir ve uyuşmazlıklara yol açabilir.
Her kohort tablosu hücresinin neyi temsil ettiğini tanımlayın. Tipik metrikler:
Ayrıca oran metrikleri için payda belirleyin (örn. tutma oranı = hafta N'de aktif kullanıcılar ÷ hafta 0 kohort büyüklüğü).
Kohortlar sınır durumlarda karmaşıklaşır. Kuralları belirleyin:
Bu kararları sade dilde belgeleyin; gelecekteki siz ve kullanıcılarınız minnettar olacaktır.
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.
Çoğu ürün, tek bir entegrasyon yoluna bağlı kalmamak için karışık kaynaklar kullanır:
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.
Kötü veri yayılmadan mümkün olduğunca yakınında doğrulama ekleyin.
Odaklanılacaklar:
Kayıtları reddettiğinizde veya düzelttiğinizde, değişikliği açıklayabilmek için bir denetim (audit) loguna yazın.
Ham veri tutarsızdır. Bunu temiz, tutarlı analitik tablolara dönüştürün:
İşleri bir zaman çizelgesinde (veya streaming) çalıştırın ve operasyonel koruyucular ekleyin:
Boru hattını bir ürün gibi ele alın: ölçümlendirin, izleyin ve sıkıcı derecede güvenilir tutun.
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.
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.
Ham eventleri saklayın, ama analitik-dostu yapılar ekleyin:
Bu ayrım, kohortları/segmentleri yeniden hesaplamayı events tablosunu yeniden yazmadan yapmanızı sağlar.
Çoğu kohort sorgusu zaman, varlık ve event türüne göre filtreler. Öncelikler:
(event_name, event_time))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.
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.
Gerçek sorulara karşılık gelen küçük bir kural setiyle başlayın:
Country = United States, Plan is Pro, Acquisition channel = AdsTenure is 0–30 days, Revenue last 30 days > $100Used Feature X at least 3 times in the last 14 days, Completed onboarding, Invited a teammateHer 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ı”).
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:
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.
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:
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.
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.
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.
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.
Her metrik etiketine (Retention, Churn, Revenue, Active users) tooltip ekleyin ve şunu belirtin:
Kısa bir tooltip, uzun yardım sayfasından daha etkilidir; karar anında yanlış yorumlamayı engeller.
Isı haritasının üzerine en yaygın filtreleri koyun ve geri alınabilir yapın:
Aktif filtreleri etiketler (chip) halinde gösterin ve tek tıkla “Reset” sunun ki insanlar keşfetmeye çekinmesin.
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.
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.
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:
İ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.
Uygulamanız birden fazla workspace/müşteri destekliyorsa, “biri başka workspace verisini görmeye çalışacak” varsayımıyla tasarlayın:
Bu, analistlerin özel filtreler oluştururken yanlışlıkla tenant verisi sızdırmasını önler.
Çoğu segmentasyon ve tutma analizi ham kişisel veriler olmadan yapılabilir. Alınan veriyi azaltın:
Ayrıca veriyi dinamik ve beklemede şifreleyin, gizli anahtarları uygun bir secrets manager'da saklayın.
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ı:
Saklama/silme iş akışı, kohort grafikleri kadar önemlidir.
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.
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:
Bu testler CI'de çalışmalı ki sorgu mantığı veya aggregasyonlarda her değişiklik otomatik kontrol edilsin.
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:
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.
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.
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.
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.
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.
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.
Ne kırıldığını ve ne yavaşladığını izleyin:
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.
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.
Start with 2–3 specific decisions the app must support (e.g., week-1 retention by channel, churn risk by plan), then define:
Build the MVP to answer those reliably before adding alerts, automations, or complex logic.
Write definitions in plain language and reuse them everywhere (UI tooltips, exports, docs). At minimum, define:
Then standardize , , and so charts and CSVs match.
Pick a primary identifier and explicitly document how others map to it:
user_id for person-level retention/usageaccount_id for B2B rollups and subscription metricsanonymous_id for pre-signup behaviorDefine when identity stitching occurs (e.g., on login), and what happens with edge cases (one user in multiple accounts, merges, duplicates).
A practical baseline is an events + users + accounts model:
event_name, timestamp (UTC), , , (JSON)If attributes like plan or lifecycle status change over time, storing only the “current” value will make historical cohorts drift.
Common approaches:
plan_history(account_id, plan, valid_from, valid_to)Choose based on whether you prioritize query speed or storage/ETL simplicity.
Pick cohort types that map to a single anchor event (signup, first purchase, first key feature use). Then specify:
Also decide whether cohort membership is immutable or can change if late/corrected data arrives.
Decide up front how you handle:
Put these rules in tooltips and export metadata so stakeholders can interpret results consistently.
Start with ingestion paths that match your sources of truth:
Add validation early (required fields, timestamp sanity, dedupe keys) and keep an audit log of rejects/fixes so you can explain number changes.
For moderate volumes, PostgreSQL can work with careful indexing/partitioning. For very large event streams or heavy concurrency, consider a warehouse (BigQuery/Snowflake/Redshift) or an OLAP store (ClickHouse/Druid).
To keep dashboards fast, precompute common results into:
segment_membership (with validity windows if membership changes)Use simple, predictable RBAC and enforce it server-side:
For multi-tenant apps, include everywhere and apply row-level scoping (RLS or equivalent). Minimize PII, mask by default, and implement deletion workflows that remove raw and derived data (or mark aggregates stale for refresh).
user_idaccount_idpropertiesKeep event_name controlled (a known list) and properties flexible but documented. This combination supports both cohort math and non-expert segmentation.
Keep raw events for drill-down, but make the default UI read summaries.
workspace_id