SaaS Deneme Dönüşümleri İçin Web Uygulaması Nasıl Oluşturulur

Bu web uygulaması neyi çözmeli (ve kimler için)

Bu web uygulamasının hedefi basit: aktivasyonu iyileştirerek SaaS deneme dönüşümünü artırmak. Pratikte bu, daha fazla deneme kullanıcısının “aha” anına hızlı, tutarlı ve daha az çıkmazla ulaşmasına yardımcı olmaktır.

“Bir başka analitik aracı” olmak yerine, uygulama üç işi tek yerde birleştirmeli:

1) Denemede önemli olanı takip edin

İlk proje oluşturuldu, bir takım arkadaşı davet edildi, bir entegrasyon bağlandı gibi anlamlı ilerlemeyi gösteren ana eylemleri yakalayın. Her tıklamayı değil—sadece aktivasyon ve satın alma niyetiyle eşleşen birkaç temel olayı.

2) İnsanların nerede takıldığını analiz edin

Ham etkinliği net yanıtlarla dönüştürün: hangi adımlar tamamlanıyor, hangileri atlanıyor ve nerede düşüş yaşanıyor. İşte aktivasyon huniniz, onboarding kontrol listesi ilerlemeniz ve segment karşılaştırmalarınız burada yer alır.

3) Davranış bir risk veya hazır sinyali verdiğinde aksiyon tetikleyin

Ekiplerin sadece görmesi değil, içgörüler üzerine harekete geçmesi gerekiyor. Örneğin: 2. adıma 2. günde ulaşmamış kullanıcılara yönlendirme yapın veya yüksek uyumlu bir hesap aktivasyonu yakalayıp yükseltme yapmamışsa satışa uyarı gönderin. Eğer zaten mesajlaşma araçlarınız varsa, bu hafif tutulsun—olay gönderin/webhook veya görev oluşturun.

Kullanıcılar kimler olacak

• Ürün yöneticileri: hangi onboarding adımlarının önemli olduğuna karar verir ve aktivasyonun iyileşip iyileşmediğini görür.
• Büyüme/pazarlama: aktivasyon kilometre taşlarına bağlı kampanyalar ve deneyler yürütür.
• Destek/CS: takılan deneme hesaplarını tespit eder ve öncelikli temas sağlar.
• Satış (varsa): sadece kayıtlarına bakmayıp güçlü niyet gösteren hesaplara odaklanır.

Haftalık olarak cevaplaması gereken sorular

İyi bir kural: uygulama bu soruları hızlı cevaplayabiliyorsa işini yapıyor demektir.

• Hafta hafta deneme→ücretli dönüşümümüz iyileşiyor mu?
• Yeni denemelerin yüzde kaçı aktivasyona ulaşıyor ve ne kadar sürüyor?
• Hangi onboarding adımı en büyük düşüşe neden oluyor?
• Hangi kanallar/segmentler en iyi (ve en kötü) şekilde aktive olup yükseltiyor?
• Bu hafta hangi hesaplara bir hatırlatma veya insan müdahalesi yapılmalı?

İsterseniz bu genel bakışı daha sonra metrik tanımları bölümünüze bağlayabilirsiniz (ör. /blog/define-activation-metrics) ki ekipler aynı “aktivasyon” anlamında hizalansın.

Önemli aktivasyon ve dönüşüm metriklerini tanımlayın

Panoları veya otomatik hatırlatmaları kurmadan önce gerçekten neyi iyileştirmeye çalıştığınız konusunda net olun. Deneme programları genellikle ürün kötü olduğu için değil, “başarı”nın belirsiz olması nedeniyle başarısız olur.

Deneme dönüşümü vs. aktivasyon

Deneme dönüşümü bir iş sonucu: deneme kullanıcısı ücretli müşteri olur (veya fatura ister, aboneliğe başlar vs.). Bu ikili, gecikmeli ve genellikle fiyatlandırma, satın alma süreci veya satış takibi gibi dışsal etkenlerden etkilenir.

Aktivasyon bir ürün sonucu: deneme kullanıcısı uygulamanın onlar için değer sağlayabileceğini gösteren “aha” anına ulaşır. Bu öne dönük, daha erken olur ve ürün ile onboarding için daha eyleme geçirilebilir.

Sağlıklı bir program önce aktivasyonu iyileştirir—çünkü aktivasyon dönüşümü olası kılan şeydir.

1–3 aktivasyon çıktısı seçin (10 değil)

Uzun vadeli kullanımı güvenilir şekilde öngören küçük bir eylem seti seçin. İyi aktivasyon çıktıları spesifik, ölçülebilir ve değere bağlıdır (gösteriş tıklamaları değil). Örnekler:

• İlk proje oluşturuldu (kullanıcı gerçek işe başlar)
• Veri içe aktarıldı / entegrasyon bağlı (kullanıcı dünyasını uygulamaya taşıyor)
• Bir ekip arkadaşı davet edildi (işbirliği ve tutunma sinyali)

“Giriş yapıldı” veya “Ayarlar ziyaret edildi” gibi öğeler yalnızca gerçekten yükseltmelerle korelasyon gösteriyorsa kullanılmalı.

Hedefleri belirleyin: oran ve aktivasyona zaman

Başarıyı iki rakamla tanımlayın:

• Aktivasyon oranı: deneme penceresi içinde aktivasyona ulaşan denemelerin yüzdesi (örn. %35 aktifleştirildi).
• Aktivasyona zaman (TTA): kayıt ile aktivasyon arasındaki medyan süre (örn. 20 dakikadan kısa veya 1 gün içinde).

Bu iki metrik birlikte, sadece “birileri aktive oluyor” izlenimini değil, denemenin anlamlı olması için yeterince hızlı olup olmadığınızı gösterir.

Varsayımları ve “iyi”nin ne olduğunu dokümante edin

Şunları yazın:

• Her aktivasyon çıktısının neden değer gösterdiği (hipoteziniz)
• Segment bazında “iyi” vs “kötü” neye benzer (ör. self-serve vs satış destekli)
• Dönüşümü etkileyen kısıtlar (yıllık faturalama, güvenlik incelemesi, ekip onayı)

Bu, metrikleri paylaşılan bir sözleşmeye dönüştürür—sonra onboarding veya fiyatlandırma değiştirdiğinizde neyin neden hareket ettiğini bileceksiniz.

Deneme→ücretli hunisini ve aktivasyon kontrol listesini tasarlayın

Deneme→ücretli huni, birinin “meraklı” olmaktan “ödemeye yeterince emin” olmaya geçiş hikayesidir. Göreviniz bu hikayeyi kısa, net ve ölçülebilir kılmak—böylece insanların nerede takıldığını görüp düzeltebilirsiniz.

Deneme yolculuğunu haritalayın (kayıttan yükseltmeye)

Beklenen yolculuğu düz bir dille yazın:

Kayıt → ilk giriş → onboarding kurulum → ana eylem (“aha” anı) → tekrar kullanım → yükseltme kararı

“Ana eylem”, kullanıcıların ürünün değerini ilk kez hissettiği tek andır (ör. ilk projeyi oluşturmak, ekip arkadaşı davet etmek, veri içe aktarmak veya bir şeyi yayınlamak). İsmini koyamıyorsanız, huni belirsiz olur ve onboarding tahmine dayanır.

Asgari uygulanabilir onboarding kontrol listesi oluşturun

Kontrol listeniz sadece ana eyleme ulaşmak için gerekli adımları içermeli—sadece “olsa iyi olur” olanları değil. İyi bir aktivasyon kontrol listesi genelde 3–7 maddedir ve kurulum ile değeri karıştırır.

Örnek yapı:

• Hesap temellerini doğrulayın (e-posta doğrulandı, workspace oluşturuldu)
• Gerekli olan tek entegrasyonu bağlayın (varsa)
• İlk gerçek nesneyi oluştur/aktar (proje, liste, kampanya vb.)
• Ana eylemi tamamlayın (gönder, yayınla, paylaş, otomatikleştir)
• Bir sonuç görün (rapor oluşturuldu, mesaj teslim edildi, zaman tasarrufu görüldü)

Her maddeyi ikili (tamamlandı/tamamlanmadı) yapın. Bir etkinlikten adımın tamamlandığını anlayamıyorsanız, çok belirsizdir.

Düşüşleri ve yaygın engelleri belirleyin

Her adım için kullanıcıların ilerlememesine yaygın olarak neyin neden olduğunu listeleyin:

• Karışıklık: belirsiz etiketler, çok fazla seçenek
• Sürtünme: uzun formlar, erken zorunlu alanlar
• Eksik önkoşullar: içe aktarılacak veri yok, davetlenecek ekip arkadaşı yok
• Zamanlama: adım onay veya bilgi gerektiriyor

Bu, öncelikli düzeltme listeniz ve sonraki adım olarak hatırlatıcı kurallarınız olur.

Yolculuğu adlandırılmış bir huniye dönüştürün

Yolculuğu, net ve tutarlı isimlerle huni adımlarına çevirin. Kullanıcı merkezli ve eylem temelli kalın:

Kayıt Oldu → Aktive Oldu (Ana Eylem Tamamlandı) → Geri Döndü (2. oturum) → Etkileşim (Ana Eylemin Tekrarı) → Yükseltti

Daha sonra /blog/product-analytics-plan gibi bir kaynak oluşturursanız, bu adlar izlediğiniz event isimleriyle eşleşmeli ki panolar okunaklı ve kararlar hızlı olsun.

Bir etkinlik izleme planı oluşturun (neyi neden takip edeceksiniz)

İlerlemenin ne olduğunu önceden kararlaştırmazsanız, gürültülü analitik ve belirsiz cevaplar elde edersiniz. Bir izleme planı ürün, pazarlama ve mühendislik arasında hafif bir sözleşmedir: topladığımız etkinlikler, içerikleri ve hangi amaçlarla kullanılacakları.

Yüksek sinyal veren küçük bir setle başlayın

Sadece harekete geçeceğiniz şeyleri takip edin. SaaS deneme dönüşümü için basit bir başlangıç seti genelde şunları içerir:

• Önemli yüzeyler için sayfa görüntülemeleri (fiyatlandırma, onboarding, yükseltme/paywall)
• Aktivasyon adımlarını temsil eden ana eylemler (teammate davet etme, entegrasyon bağlama, ilk proje oluşturma)
• İlerlemeyi engelleyen hatalar (API hataları, doğrulama hataları, başarısız ödemeler)
• Paywall/yükseltme görüntülemeleri (yükseltme modalı açıldı, ödeme süreci başlatıldı)

"Kim" ve "hangi koşullar altında"ı açıklayan özellikleri tanımlayın

Özellikleri olmayan etkinlikler neden bir segmentin daha iyi dönüştüğünü açıklayamaz. Faydalı özellikler şunlardır:

• plan (trial, starter, pro)
• role (owner, admin, member)
• device (desktop, mobile)
• source (utm_source veya edinim kanalı)
• company_size (1, 2–10, 11–50, 50+)

Özellikleri olaylar arasında tutarlı tutun ki herhangi bir huni adımını aynı şekilde segmentleyebilin.

Veriler kullanılabilir kalsın diye adlandırmayı standartlaştırın

Net bir konvansiyon kullanın:

• Etkinlikler: geçmiş zaman kipinde verb_noun, örn. project_created, integration_connected
• Özellikler: snake_case, örn. company_size, signup_source
• Upgrade Clicked vs clicked_upgrade gibi kopyalardan kaçının

Basit bir izleme planı tablosu (takımla paylaşın)

Buna karar verildiğinde, panolara ve uyarılara bağlayabilirsiniz (bkz. /blog/funnel-dashboards) ve tanımları yeniden icat etmeden ilerlersiniz.

Veri toplama ve analiz için basit bir mimari seçin

Deneme dönüşümünü anlamak için “büyük veri” yığınına ihtiyacınız yok. Küçük, net bir mimari doğru uygulaması daha kolaydır—ve ürün kararları alırken ona daha çok güvenilir.

Temel yapı taşları

En azından beş parçayı planlayın:

• Frontend: kararlı bir kullanıcı/deneme tanımlayıcısı ile ürün etkinlikleri yayar (ör. “workspace oluşturuldu”, “teammate davet edildi”).
• API: etkinlikleri doğrular, sunucu tarafı bağlam (plan, deneme durumu) ekler ve sahtecilik önler.
• Veritabanı: hesaplar, denemeler, abonelikler gibi gerçek kaynağı tutar ve ham etkinlikleri saklar.
• Arka plan işleri: metrikleri toplar, huni tabloları oluşturur ve periyodik olarak kohort/retention hesaplar.
• Panolar: toplu tabloları okuyan bir BI aracı veya basit dahili sayfalar (ham etkinlikler değil).

Faydalı bir kural: ham etkinlikler hata ayıklama içindir; toplu tablolar raporlama içindir.

Eğer dahili bir sürümü hızlı göndermeye çalışıyorsanız, yazılı bir spesifikasyondan React UI, Go API ve PostgreSQL şeması iskeleti oluşturmanıza yardımcı olacak Koder.ai gibi bir platform size hız kazandırabilir—ardından huniler, listeler ve panolar üzerine chat ile yineleyebilirsiniz; isterseniz kaynak kodu dışa aktarma seçeneğini koruyarak ilerlersiniz.

Gerçek zamanlı olan ile günlük toplu işlemin ayrımı

Gerçek zamanlı yalnızca kullanıcı deneyimini değiştirdiğinde gereklidir:

• Gerçek zamanlı: onboarding hatırlatmaları, “aktivasyon kontrol listesi” ilerlemesi, deneme bitiş uyarıları, uygulama içi istemler.
• Günlük toplu: huni dönüşüm oranları, kohort retention, segment karşılaştırmaları, haftalık eğilim grafikleri.

Bu ayrım maliyet ve karmaşıklığı düşük tutar ama zamanında müdahaleyi destekler.

Tek satırla açıklanabilir basit veri akışı

Borudaki herkesin tekrar edebileceği bir pipeline tasarlayın:

Uygulama → ingest endpoint → ham etkinlik deposu → planlı toplama → metrik tabloları → panolar

Her adımda hafif gözlemlenebilirlik ekleyin (etkinlik hacmi kontrolleri, şema doğrulama hataları, iş çalıştırma durumu) ki boşluklar dönüşüm sayıları bozulmadan önce yakalansın.

Gizlilik ve yetki sınırları (erken karar verin)

Hiçbir zaman toplamayacağınız verileri tanımlayın (örn. parolalar, tam mesaj içerikleri) ve nelerin izinli olduğunu belirleyin (özellik kullanımı, zaman damgaları, cihaz türü). Erişimi ayırın:

• Ürün/ekip panoları: toplanmış metrikler.
• Mühendislik/hata ayıklama: sınırlı ham etkinlik erişimi.

Ayrıca saklama süresini belirleyin (örn. ham etkinlikleri 90 gün sonra silmek) ve bunu dokümante edin ki analitiğin sessizce bir uyum riskine dönüşmesi engellensin.

Denemeler, etkinlikler ve çıktılar için veri modelini tasarlayın

İyi bir veri modeli deneme dönüşümünü tekrarlanabilir kılar: “kim takılıyor?”, “ne yaptılar?” ve “ardından ne oldu?” sorularını her hafta özel sorgular yazmadan cevaplayabilirsiniz. Temel nesneleri (kişiler, hesaplar, denemeler) davranış verilerinden (etkinlikler) ve iş sonuçlarından (çıktılar) ayrı saklayın.

Saklanacak temel varlıklar (ve neden)

En azından şu kayıtları birinci sınıf modelleyin:

• User: birey (email, isim, rol, durum).
• Account/Workspace: tenant sınırı (plan, sektör, büyüklük, sahibi, durum).
• Membership: kullanıcıları hesaplara bağlar (rol + izinler).
• Trial: değerlendirme penceresi (başlangıç/bitiş, kaynak, deneme varyantı, mevcut durum).
• Subscription: ücretli durum ve yaşam döngüsü (provider id'leri, plan, başlangıç/bitiş, iptal nedeni).
• Event: her anlamlı eylem (event adı, zaman, aktör, özellikler).
• Message/Nudge: gönderdiğiniz onboarding e-postaları/uygulama içi istemleri (şablon, kanal, gönderildi/görüldü/tıklandı).

Bu ayrım, dönüşümü raporlarken faturalama mantığını ürün kullanım verileriyle karıştırmamanızı sağlar.

Huni adımlarını ve aktivasyon kilometre taşlarını veriye modelleyin

“Activated”ı tek bir boolean olarak sert kodlamak yerine şunları oluşturun:

• FunnelStep (örn. “Teammate davet edildi”, “Entegrasyon bağlandı”) sıralama ve kurallarla.
• ActivationMilestone (örn. “İlk proje oluşturuldu”) eşiklerle (adet/zaman penceresi).
• TrialProgress her hesabın her adımı/kilometre taşını ne zaman geçtiğini kaydeder.

Bu, aktivasyon kontrol listesini migration olmadan düzenlenebilir kılar ve birden fazla ürün veya persona destekler.

Çok kiracılı ayrım ve erişim kontrolü

Her tenant-özgü kayıt için account_id zorunlu alan olarak değerlendirin (denemeler, etkinlikler, mesajlar, ilerleme). Sorgularda ve indekslerde bunu zorunlu kılın. Eğer admin kullanıcılarınız varsa, bu erişimi implicit e-posta alanı yerine Membership üzerindeki rollerle açıkça yönetin.

Saklama politikaları ve silme desteği

Gün birinden itibaren silmeyi planlayın:

• Soft-delete kullanıcılar/hesaplar (referential integrity için id'leri tutun).
• Hard-delete/anonimleştirme kişisel alanları (email, IP, cihaz id'leri) toplu sonuçları korurken.
• created_at, deleted_at ve bir data_retention_expires_at zaman damgaları ekleyin ki otomatik temizlik yapılabilsin.

Bu yapı ile “ne yaptılar” (etkinlikler) ile “istediğiniz şey”i (aktivasyon ve yükseltmeler) deneme yaşam döngüsü boyunca güvenle bağlayabilirsiniz.

Güvenilir etkinlik alımı uygulayın

Etkinlik akışınız dalgalıysa, her huni grafiği bir tartışma olur: “Kullanıcılar gerçekten düştü mü—yoksa izleme mi bozuldu?” Güvenilir alım, pahalı araçlardan çok öngörülebilir kuralların uygulanmasıdır—sadece iyi veriyi kabul edin, güvenli saklayın ve hataları görünür kılın.

Güvenilir bir collector API oluşturun

Collector küçük, sıkıcı bir endpoint olmalı (örn. POST /events) ve dört işi iyi yapmalı:

• Doğrulama: zorunlu alanlar (event adı, zaman damgası, user/trial tanımlayıcıları), izin verilen değerler ve makul zaman sınırları.
• Kimlik doğrulama: ortam başına API anahtarı kullanın ve gerektiğinde döndürün.
• Hız sınırlama: bir anahtar/IP başına istekleri sınırlayın ki hatalı bir sürüm hatası tüm boruyu doldurmasın.
• Şema sürümleme: schema_version ekleyin ki olay özelliklerini evrimleştirseniz bile eski istemciler bozulmasın.

Pratik bir minimum event payload örneği:

{
  "event_name": "activation_step_completed",
  "occurred_at": "2025-12-26T12:34:56Z",
  "user_id": "u_123",
  "trial_id": "t_456",
  "properties": {"step": "invite_teammate"},
  "event_id": "01J..."
}

İstemci tarafı ve sunucu tarafı takip desteği

UI eylemleri (tıklama, görüntüleme, checklist etkileşimleri) için istemci tarafı olaylarını, güvenmeniz gereken çıktı/sonuçlar (abonelik yükseltildi, ödeme başarısız oldu, veri içe aktarıldı) için sunucu tarafı olaylarını kullanın. Her ikisi varsa, sunucu tarafını doğruluk kaynağı olarak kabul edin ve istemci tarafını tanısal bağlam olarak kullanın.

Yeniden denemeler, çoğaltma önleme ve geç gelen olaylar

Ağlar başarısız olur ve tarayıcılar kapanır. Alımı dayanıklı yapın:

• Yeniden denemeler: istemciler güvenli yeniden deneme yapabilsin; istekleri idempotent yapın.
• Çoğaltma önleme: benzersiz event_id zorunlu kılın ve bir pencere içinde tekrarları yoksay.
• Geç gelen olaylar: daha eski zaman damgalarını (bir sınır içinde) kabul edin ama hem occurred_at hem received_at saklayın ki raporlama doğru kalsın.

İzleme ve uyarılar

Sessiz hataları yakalayacak temel kontroller ekleyin:

• İngestion başarı oranı, doğrulama hata oranı, kuyruk/yığılma boyutu ve işleme gecikmesi izleyin.
• Başarı oranı düştüğünde, hatalar arttığında veya gecikme eşik aştığında uyarın.

Hedef basit: biri “bu hunuya güveniyor muyuz?” diye sorduğunda “evet” diyebilin—ve bunu kanıtlayın.

Huni sağlığı ve aktivasyon ilerlemesi için panolar oluşturun

Panolar deneme dönüşümünü bir “hissetme” olmaktan çıkarıp karar alınabilir bir dizi haline getirir. Amacınız her şeyi takip etmek değil—deneme→ücretli yolunu görünür kılmak, insanların nerede takıldığını vurgulamak ve sayıların arkasındaki gerçek hesapları incelemeyi kolaylaştırmak.

1) Huni sağlığı: adım adım dönüşüm ve düşüşler

Deneyimi yansıtan tek bir huni görünümüyle başlayın. Her adımda gösterilecekler:

• Adıma giren kullanıcılar/hesaplar
• Bir sonraki adıma dönüşüm (%)
• Düşüş sayısı ve (%)

Adımları davranışa göre hizalayın, sayfa görüntülemelerine göre değil (örn. “İlk proje oluşturuldu”, “Ekip arkadaşı davet edildi”, “Entegrasyon bağlandı”, “Aktivasyon kilometre taşına ulaşıldı”, “Yükseltme tıklandı”, “Ödeme tamamlandı”). Hem benzersiz hesaplar hem benzersiz kullanıcılar gösterirseniz, bir şampiyonun aktif olduğu ama ekibin benimsemediği durumları görebilirsiniz.

2) Aktivasyon ve yükseltme hızı: time-to-X dağılımları

Ortalamalar sorunları gizler. İki dağılım grafiği ekleyin:

• Aktivasyona zaman (ilk deneme etkileşimi → aktivasyon kilometre taşı)
• Yükseltmeye zaman (deneme başlangıcı → ücretli)

Yüzdelikler (P50/P75/P90) kullanın ki bir alt kümenin beklenenden çok daha yavaş olup olmadığını görün. Uzayan kuyruk genelde onboarding sürtünmesi, değerin belirsizliği veya eksik takip anlamına gelir.

3) Büyüme şeklinize uygun filtreler

Her pano hızlıca kırılma yapmayı desteklemeli ki “bu kimde oluyor?” sorusunu veri dışarı aktarmadan cevaplayabilesiniz:

• Edinim kaynağı (organik, ücretli, partner)
• Plan/deneme türü (self-serve, satış destekli)
• Segment (şirket büyüklüğü, rol, sektör)
• Tarih aralığı (deneme başlangıç haftası/ay)

Karşılaştırmaların adil olması için varsayılan kohort hakemi olarak deneme başlangıç tarihini kullanın.

4) İnceleme ve aksiyon için drill-down

Grafikler, dilimin arkasındaki gerçek kullanıcı/hesap listesine bağlanmalı (örn. “3. adımda düştü”, “>7 gün aktivasyona geçti”). Ana sütunlar: kayıt tarihi, kaynak, mevcut adım, son aktivite zaman damgası, aktivasyon kontrol listesi ilerlemesi ve sahibinin (sales atandıysa) bilgisi. Bu, panoyu raporlama olmaktan çıkarıp iş akışına dönüştürür—destek ulaşır, ürün oturum tekrarlarını izler, pazarlama hangi kanalların niyet getirdiğini görür.

Yükseltmeleri belirleyen şeyleri bulmak için kohortlar ve retention görünümleri ekleyin

Huniler nerede düştüğünü söyler. Kohortlar ve retention kim düştüğünü ve geri gelip gelmediğini söyler. Bu fark, “deneme dönüşümü düştü” ile “LinkedIn’den gelen ve entegrasyonları değerlendirmek için kayıtlı kullanıcıların dönüşümü düştü” arasındaki ayrımı yapar.

Gerçek satın alma davranışına uyan kohortlar tanımlayın

Başlangıçta güvenilir şekilde yakalayabileceğiniz birkaç kohort boyutu ile başlayın ve zaman içinde tutarlı tutun:

• Kayıt haftası (veya ay) — ürün sürümlerinin veya fiyat değişikliklerinin etkisini görmek için
• Edinim kanalı (ücretli arama, organik, partner, yönlendirme) — lead kalitesini karşılaştırmak için
• Persona (rol/takım) — kayıt sırasında sorulan veya firmografik veriden çıkarılan
• Kullanım vakası (ne yapmaya çalıştıkları) — onboarding sorusu veya ilk akış seçimiyle

Başlangıçta listeyi kısa tutun. Çok fazla kohort türü analiz gürültüsü yaratır ve kararları yavaşlatır.

Kohortlar arasında aktivasyon ve dönüşümü karşılaştırın

Her kohort için karşılaştırın:

• Aktivasyon oranı (ana “aha” eylemlerini tamamladılar mı?)
• Aktivasyona zaman (aynı aktivasyon, ama daha hızlı olan genellikle daha iyi dönüşür)
• Deneme→ücretli dönüşüm oranı (sonuç)

Bu neyi düzeltmeniz gerektiğini hızlıca ortaya çıkarır. Örnek: bir kanal yüksek kayıt hacmi ama düşük aktivasyon veriyorsa—reklam vaadi ile ürünün ilk deneyimi uyuşmuyor demektir.

Deneme sırasında retention sinyallerini takip edin

Yükseltmeler nadiren tek bir oturumdan olur. Deneme sağlığına odaklanan bir retention görünümü ekleyin:

• Tekrar ziyaretler (D1/D3/D7, 14 günlük deneme süresince)
• Tekrarlayan ana eylem (ana eylemi 2+ kez yaptı mı?)
• Takım daveti / işbirliği (uygun ise)

Bir kez aktive olup geri dönmeyen kohortlara dikkat edin—bu kullanıcılar genellikle daha iyi rehberliğe, şablonlara veya hatırlatmalara ihtiyaç duyar.

İçgörüleri paylaşılabilir yapın (export)

Her kohort ve retention raporu CSV dışa aktarımı desteklemeli ki ekipler bulguları paylaşsın, haftalık güncellemelere eklesin veya daha derin analiz yapsın. Dışa aktarımlar ayrıca ürün analitiğinizi faturalama verileri veya CRM notlarıyla karşılaştırırken yardımcı olur.

Davranışa dayalı onboarding hatırlatmaları tetikleyin

Davranışa dayalı hatırlatmalar, zamanında yardım gibi geldiğinde en iyi sonucu verir; sadece tekrar eden hatırlatmalar gibi hissettirmemeli. Amaç basit: deneme kullanıcısı değere yakınsa (veya takıldıysa) onu bir sonraki anlamlı adıma yönlendirmek.

Küçük bir kural motoruyla başlayın

AI'ye gerek yok—sadece okunabilir “if user did X and not Y, then nudge” kuralları yeterlidir; bunlar aktivasyon kontrol listesine bağlı olsun.

IF created_project = true AND invited_teammate = false AFTER 24h
THEN show banner “Invite a teammate to collaborate”

IF connected_integration = false AND viewed_integrations_page = true
THEN tooltip “Connect your first integration in 2 minutes”

Kurallarınızı okunabilir ve düzenlenebilir tutun (hatta sadece ekibiniz görse bile). En sık görülen düşüş noktalarını hedefleyen 5–10 kural önceliklendirin.

İş için doğru kanalı kullanın

Farklı hatırlatmalar farklı anlara uyar:

• Uygulama içi bannerlar kullanıcı zaten aktifken “sonraki adımı yap” istemleri için
• Tooltipler belirli bir ekran veya özellik için rehberlik sağlar
• Kontrol listeleri ilerlemeyi görünür kılar ve bunalmayı azaltır
• E-posta geri dönüş olmadan yeniden etkileşim için

Her mesajın tek bir eyleme işaret ettiğinden ve kullanıcının bağlamını (rolü, planı, tamamladıkları) kullandığından emin olun.

Frekans kısıtları ve sessiz saatler ekleyin

Hatırlatmalar spam'e dönüşmesin diye gardlar koyun. Pratik bir varsayılan “kullanıcı başına günde en fazla 1–2 hatırlatma” ve kullanıcının zaman dilimine göre sessiz saatlerdir. Ayrıca bastırma kuralları ekleyin (örn. kurulumla mücadele eden kullanıcılara yükseltme istemleri gönderme).

Her gönderimi kaydedin ve etkisini ölçün

Hatırlatmaları bir ürün özelliği gibi ele alın: ne gönderildi, ne zaman ve neden (kural ID, kanal, varyant) kaydedin. Sonra bunun doğru metriği—bir aktivasyon adımının tamamlanması, uygulamaya dönüş veya deneme→ücretli dönüşüm—hareket ettirip ettirmediğini ölçün ki işe yarayanı tutup yaramayanı emekliye ayırabilesiniz.

Deneme yaşam döngüsünü faturalama ve yükseltme akışına bağlayın

Ürün analitiğiniz ve onboarding çalışmaları ancak deneme yaşam döngüsü faturalamaya bağlıysa değer üretir. Amaç basit: uygulamanızdaki her “deneme anı” bir faturalama durumuna ve tersi şekilde bağlanmalı ki dönüşümü doğru ölçebilesiniz ve kullanıcı deneyimini bozmayın.

Faturalama olaylarını temel ürün olayları olarak entegre edin

En azından şu faturalama olaylarını aynı takip akışına gönderin:

• Deneme başlangıcı (kaynak, plan, seat sayısı)
• Deneme bitişi (planlanan tarih ve gerçek bitiş)
• Yükseltme / abonelik oluşturuldu (plan, dönem, kupon, gelir)
• İptal (anında vs dönem sonunda, varsa sebep)

Bunu yaparak “değer gördüler mi?” ile “ödeme yaptılar mı?”yı olaylara bağlarsınız; sadece sayfa görüntülerinden tahmin etmek zorunda kalmazsınız.

Yükseltme istemlerini değer anlarına göre tasarlayın

Yükseltme istemleri niyet ve ilerlemeyle tetiklendiğinde daha iyi performans gösterir; sadece gün sayısına göre değil. Örnekler:

• Kullanıcı aktivasyon kontrol listesini kanıtlayan bir maddeyi tamamladı → bir sonraki aşamayı açan bir yükseltme istemi gösterin.
• Kullanıcı bir limite ulaştı (projeler, dışa aktarımlar, otomasyonlar) → özel faydayı gösteren bağlamsal bir paywall gösterin.

Ayrıca paywall görüntülemeleri ve /pricing ziyaretleri gibi olayları açık huni adımları olarak takip edin ki kullanıcıların tereddüt ettiği yerleri görün.

Deneme bitiş durumlarını güveni bozmadan yönetin

Deneme bitişinde ne olacağını tanımlayın ve bunu takip edin:

• Güzartı dönemi (dönüştürmek için ekstra günler)
• Ücretsiz kata düşürme
• Sınırlı erişim (salt okunur, kullanım sınırlı)

Durumu uygulama içinde görünür yapın (“Deneme 2 gün içinde bitiyor”) ve yükseltme akışının kullanıcı kaybettiği anda tek tıkla ulaşılabilir olmasını sağlayın—navigasyonun arkasına saklamayın.

Aktivasyonu ve deneme dönüşümünü artırmak için deneyler yürütün

Deneyler “bunun işe yarayacağını düşünüyoruz”u ölçülebilir bir iyileşmeye dönüştürür. Küçük, odaklı ve denemenin belirli bir anına bağlı tutun: ilk deneyim, ana aktivasyon adımı veya yükseltme kararı gibi.

Basit, yüksek etkili testlerle başlayın

Her seferinde bir şeyi değiştiren A/B testleriyle başlayın:

• Onboarding kontrol listesi kelimeleri (“Veri kaynağınızı bağlayın” vs “İlk dosyanızı içe aktarın”)
• Adımların sıralaması (önce kurulum vs önce değer gösterimi)
• Hatırlatmalar (başarısız bir eylemden sonra uygulama içi ipucu, 24 saat sonra bir hatırlatma)
• Yükseltme istemleri (zamanlama, yerleşim, varsayılan gösterilen plan)

Bunlar kolayca gönderilir, düşük risklidir ve genellikle her yeni denemeyi etkiledikleri için büyük kazançlar üretebilir. Eğer hipotezten çalışan varyanta (ör. yeni checklist UI + event enstrümantasyonu) hızla geçmek istiyorsanız, ekipler genellikle Koder.ai üzerinde prototipleyip kazanan yaklaşımı rafine eder—özellikle iç araçları yeniden kurmadan bir full-stack tabanı (React + Go + PostgreSQL) hızlıca elde etmek istediğinizde.

Başarı metriklerini ve güvenlik sınırlarını önceden tanımlayın

Yayınlamadan önce şunları yazın:

• Birincil başarı metriği: genelde aktivasyon oranı, aktivasyona zaman veya deneme→ücretli dönüşüm
• İkincil metrikler: önemli onboarding adımının tamamlanması, etkileşim sıklığı, deneme başına destek talebi sayısı
• Güvenlik sınırları: opt-out oranı, yükseltme sonrası hızlı churn, iade talepleri veya negatif NPS sinyalleri

Ayrıca kimlerin dahil olduğu (ör. deney başladıktan sonra başlatılan yeni denemeler) ve ne kadar süreyle çalıştırılacağı net olsun.

Yaygın deney tuzaklarından kaçının

Dikkat edilmesi gerekenler:

• Çok küçük örneklem: rastgele “kazanan” çıkarsınız ve sonra geri dönersiniz
• Peeking: grafiğin bugün iyi görünmesine dayanıp erken durmak
• Yanlı segmentler: sadece power user veya tek bir edinim kanalında test etmek

Eğer segment gerekiyorsa, bunu önceden planlayın ve ayrı bir analiz gibi ele alın.

Öğrenimleri dokümante edin ki sonuçlar birikmeli olsun

Her test için kısa bir kayıt tutun: hipotez, varyantlar, tarihler, hedef segment, sonuçlar ve karar. Kaydı gönderilen değişiklikle ve panonuzla ilişkilendirin ki gelecekte neden dönüşümün hareket ettiğini açıklayabilesiniz. Basit bir dahili sayfa (veya /blog/experiment-notes eğer herkese açık olacaksa) aynı testlerin farklı isimlerle tekrar edilmesini önler.