Deneme kullanıcılarını takip eden, aktivasyonu ölçen ve olaylar, panolar, kohortlar ile deneyler kullanarak SaaS deneme dönüşümlerini iyileştiren bir web uygulaması nasıl kurulur öğrenin.
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:
İ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ı.
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.
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.
İyi bir kural: uygulama bu soruları hızlı cevaplayabiliyorsa işini yapıyor demektir.
İ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.
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ü 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.
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:
“Giriş yapıldı” veya “Ayarlar ziyaret edildi” gibi öğeler yalnızca gerçekten yükseltmelerle korelasyon gösteriyorsa kullanılmalı.
Başarıyı iki rakamla tanımlayın:
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.
Şunları yazın:
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 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.
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.
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ı:
Her maddeyi ikili (tamamlandı/tamamlanmadı) yapın. Bir etkinlikten adımın tamamlandığını anlayamıyorsanız, çok belirsizdir.
Her adım için kullanıcıların ilerlememesine yaygın olarak neyin neden olduğunu listeleyin:
Bu, öncelikli düzeltme listeniz ve sonraki adım olarak hatırlatıcı kurallarınız olur.
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.
İ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ı.
Sadece harekete geçeceğiniz şeyleri takip edin. SaaS deneme dönüşümü için basit bir başlangıç seti genelde şunları içerir:
Ö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.
Net bir konvansiyon kullanın:
project_created, integration_connectedcompany_size, signup_sourceUpgrade Clicked vs clicked_upgrade gibi kopyalardan kaçının| Event name | When it fires | Key properties | Why it matters |
|---|---|---|---|
signup_completed | account created | source, company_size, device | temel deneme hacmi + kanal kalitesi |
onboarding_checklist_viewed | checklist opened | role | aktivasyon rehberine maruziyeti ölçer |
activation_step_completed | each checklist step done | step_name, role | hangi adımların aktivasyonu tetiklediğini belirler |
paywall_viewed | upgrade screen/modal shown | trigger, plan | niyeti ve sürtünmenin başladığı yeri gösterir |
checkout_started | billing flow begins | plan, billing_period | dönüşüm için öne bakan gösterge |
error_shown | blocking error displayed | error_code, surface | yükseltmeleri engelleyen hataları önceliklendirir |
Buna karar verildiğinde, panolara ve uyarılara bağlayabilirsiniz (bkz. /blog/funnel-dashboards) ve tanımları yeniden icat etmeden ilerlersiniz.
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.
En azından beş parçayı planlayın:
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ı yalnızca kullanıcı deneyimini değiştirdiğinde gereklidir:
Bu ayrım maliyet ve karmaşıklığı düşük tutar ama zamanında müdahaleyi destekler.
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.
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:
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.
İ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.
En azından şu kayıtları birinci sınıf modelleyin:
Bu ayrım, dönüşümü raporlarken faturalama mantığını ürün kullanım verileriyle karıştırmamanızı sağlar.
“Activated”ı tek bir boolean olarak sert kodlamak yerine şunları oluşturun:
Bu, aktivasyon kontrol listesini migration olmadan düzenlenebilir kılar ve birden fazla ürün veya persona destekler.
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.
Gün birinden itibaren silmeyi planlayın:
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.
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.
Collector küçük, sıkıcı bir endpoint olmalı (örn. POST /events) ve dört işi iyi yapmalı:
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..."
}
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.
Ağlar başarısız olur ve tarayıcılar kapanır. Alımı dayanıklı yapın:
event_id zorunlu kılın ve bir pencere içinde tekrarları yoksay.occurred_at hem received_at saklayın ki raporlama doğru kalsın.Sessiz hataları yakalayacak temel kontroller ekleyin:
Hedef basit: biri “bu hunuya güveniyor muyuz?” diye sorduğunda “evet” diyebilin—ve bunu kanıtlayın.
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.
Deneyimi yansıtan tek bir huni görünümüyle başlayın. Her adımda gösterilecekler:
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.
Ortalamalar sorunları gizler. İki dağılım grafiği ekleyin:
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.
Her pano hızlıca kırılma yapmayı desteklemeli ki “bu kimde oluyor?” sorusunu veri dışarı aktarmadan cevaplayabilesiniz:
Karşılaştırmaların adil olması için varsayılan kohort hakemi olarak deneme başlangıç tarihini kullanın.
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.
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.
Başlangıçta güvenilir şekilde yakalayabileceğiniz birkaç kohort boyutu ile başlayın ve zaman içinde tutarlı tutun:
Başlangıçta listeyi kısa tutun. Çok fazla kohort türü analiz gürültüsü yaratır ve kararları yavaşlatır.
Her kohort için karşılaştırın:
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.
Yükseltmeler nadiren tek bir oturumdan olur. Deneme sağlığına odaklanan bir retention görünümü ekleyin:
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.
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ı 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.
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.
Farklı hatırlatmalar farklı anlara uyar:
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.
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).
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.
Ü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.
En azından şu faturalama olaylarını aynı takip akışına gönderin:
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 istemleri niyet ve ilerlemeyle tetiklendiğinde daha iyi performans gösterir; sadece gün sayısına göre değil. Örnekler:
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şinde ne olacağını tanımlayın ve bunu takip edin:
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.
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.
Her seferinde bir şeyi değiştiren A/B testleriyle başlayın:
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.
Yayınlamadan önce şunları yazın:
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.
Dikkat edilmesi gerekenler:
Eğer segment gerekiyorsa, bunu önceden planlayın ve ayrı bir analiz gibi ele alın.
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.
Aktivasyon bir öncü ürün metriğidir: deneme kullanıcısı uygulamanın değerini kanıtlayan “aha” anına ulaşır.
Deneme→ücretli dönüşüm ise bir geriden gelen iş sonucudur: kullanıcı abonelik başlatır/ödeme yapar.
Önce aktivasyonu iyileştirin; çünkü aktivasyon daha erken olur, daha kontrol edilebilirdir ve genellikle dönüşümü artırır.
Uzun vadeli kullanımı güçlü şekilde öngören 1–3 sonuç seçin; örnekler:
“Giriş yapıldı” gibi gösteriş amaçlı olaylardan kaçının; bunların yükseltmelerle korelasyonu kanıtlanmadıysa.
Daha fazlası için /blog/define-activation-metrics bölümünde tanımları hizalayın.
İki sayı kullanın:
Bu ikisi birlikte, yalnızca “birkaç” kullanıcının aktive olmadığını gizlemeden hız ve oranı ölçmenizi sağlar.
Bunu 3–7 ikili (done/not done) adımdan oluşan, ana eyleme ulaşmaya zorunlu kılan bir listeyle yapın. Pratik bir örnek:
Eğer bir adımı bir olayla “tamamlandı”/“tamamlanmadı” şeklinde ölçemiyorsanız, adım çok belirsizdir.
İşe yarar, yüksek sinyal veren küçük bir setle başlayın:
project_created, integration_connected)paywall_viewed, checkout_started)Basit bir kural vardır:
Bu, sistemin güvenilir ve maliyet-etkin kalmasını sağlar.
Küçük bir collector endpoint (ör. POST /events) kullanın ve şunları destekleyin:
event_id)Üç katmanı ayrı modelleyin:
account_id/trial_id ile raw eventlerBu, “activated = true” gibi sabit kodlamalardan kaçınmanızı sağlar ve kontrol listesi değişse bile migration gerektirmez.
Haftalık kararları cevaplayan panolar oluşturun:
Panolar raporlama olmaktan çıkıp iş akışına dönüşmeli: destek müdahale edebilmeli, ürün session replay izleyebilmeli, pazarlama hangi kanalların yüksek niyet getirdiğini görebilmeli.
Kontrol listenize bağlı 5–10 basit kuralı önceleyin:
Doğru kanalın seçildiğinden emin olun (kullanıcı aktifse uygulama içi, inaktifse e-posta), frekans sınırları ekleyin ve her gönderimi kaydederek etkinin ölçülebilir olmasını sağlayın.
error_shown)Kim ve hangi koşullar altında daha iyi dönüştüğünü açıklayan özellikleri (source, role, company_size, plan) takip edin ve adlandırmayı standartlaştırın ki panolar okunabilir kalsın.
schema_versionAyrıca hem occurred_at hem received_at kayıt ederek geç gelen olayların zaman temelli metrikleri bozmasını engelleyin.