SaaS için etkinlik izleme planı: isimler, özellikler, 10 pano

Erken anlamanız gerekenler (ve neden zor olduğu)

İlk SaaS uygulamanızdaki erken analitik genellikle kafa karıştırıcı hissedilir çünkü aynı anda iki sorununuz vardır: çok az kullanıcı ve çok az bağlam. Bir avuç güçlü kullanıcı grafiklerinizi çarpıtabilir, birkaç “turist” (kaydolup gidenler) ise her şeyi bozuk gösterir.

En zor olanı kullanım gürültüsünü gerçek sinyallerden ayırmaktır. Gürültü, yoğun görünen ama ilerleme anlamına gelmeyen etkinliklerdir; ayarlarda gezinme, sayfa yenileme veya birden fazla test hesabı oluşturma gibi. Sinyaller ise değer tahmin eden eylemlerdir: onboarding’i tamamlamak, bir ekip arkadaşını davet etmek ya da ilk başarılı iş akışını tamamlamak gibi.

İyi bir SaaS etkinlik izleme planı, bir veri ekibine ihtiyaç duymadan ilk 30 günde birkaç temel soruyu yanıtlamanıza yardımcı olmalıdır.

Hızlıca yanıtlayabilmeniz gerekenler

Takibiniz bu soruları cevaplayabiliyorsa iyi bir konumdasınız:

• İlk değere ulaşmadan önce yeni kayıtlar nerede düşüyor?
• Kaç kullanıcı 24 saat içinde ve 7 gün içinde “ilk değere” ulaşıyor?
• Hangi özellikler geri gelen kullanıcılar tarafından kullanılıyor?
• Başarıya giden en yaygın yol nedir (ve en yaygın çıkmaz hangisi)?
• Geri gelen kullanıcılar aynı işi yapmak için mi dönüyor, yoksa sadece etrafa mı bakıyorlar?

Bunu sıradan İngilizce ile: aktivasyon, kullanıcının ilk gerçek kazanım anıdır. Retansiyon ise bu kazanımı tekrar tekrar almak için geri gelip gelmediğidir. İlk günde mükemmel tanımlar gerekmez; ancak net bir varsayım ve bunu ölçme yolu gerekir.

Hızlı inşa ediyorsanız (örneğin Koder.ai gibi bir platformda her gün yeni akışlar yayınlıyorsanız) risk, her şeyi instrument etmektir. Daha fazla etkinlik daha fazla kafa karışıklığı anlamına gelebilir. "İlk kazanç" ve "tekrar eden kazanç" ile eşleşen küçük eylem setiyle başlayın, sonra yalnızca bir karar buna bağlıysa genişletin.

Aktivasyonu ve retansiyonu basit terimlerle tanımlayın

Aktivasyon, yeni bir kullanıcının ilk gerçek değeri elde ettiği andır. Retansiyon ise zaman içinde geri gelip değeri almaya devam edip etmedikleridir. Eğer ikisini basit kelimelerle söyleyemiyorsanız, takibiniz hiçbir şey cevaplamayan bir etkinlik yığınına dönüşür.

Ürününüzde iki “kişi”yi adlandırarak başlayın:

• Çekirdek kullanıcı: işi yapan kişi (tıklayan, yükleyen, gönderen, oluşturan).
• Hesap: faturayı ödeyen ve sahibi olan müşteri (kişi veya şirket).

Birçok SaaS uygulamasında ekipler vardır, yani bir hesabın birçok kullanıcısı olabilir. Bu yüzden SaaS etkinlik izleme planınız, kullanıcı davranışını, hesap sağlığını veya her ikisini ölçüp ölçmediğiniz konusunda net olmalıdır.

Aktivasyon için bir cümle

Aktivasyonu, net bir eylem ve açık bir sonucu içeren tek bir cümle olarak yazın. İyi aktivasyon anları şöyle hissedilir: “X yaptım ve Y elde ettim.”

Örnek: “Bir kullanıcı ilk projesini oluşturur ve başarıyla yayınlar.” (Koder.ai gibi bir araçla inşa ediyorsanız bu “ilk başarılı deploy” veya “ilk kaynak kodu dışa aktarma” olabilir; ürünün vaadine bağlı olarak.)

Bu cümleyi ölçülebilir hale getirmek için, genellikle ilk değerden hemen önce olan birkaç adımı listeleyin. Kısa tutun ve gözlemleyebileceğiniz şeylere odaklanın:

• Kayıt
• İlk çalışma alanı/proje oluşturma
• Temel girdiyi ekleme (veri, içerik, entegrasyon veya ayarlar)
• Ana eylemi çalıştırma (gönderme, yayınlama, üretme, davet etme)
• Bir başarı durumuna ulaşma (tamamlandı, teslim edildi, dağıtıldı)

Retansiyon sizin için ne anlama geliyor

Retansiyon, ürününüzün kullanım sıklığına uygun bir takvime göre “geri gelip gelmedikleri”dir.

Ürününüz günlük kullanılıyorsa günlük retansiyona bakın. Birkaç kez haftada kullanılan bir iş aracıyıysa haftalık retansiyon kullanın. Aylık iş akışıysa aylık retansiyon uygundur. En iyi seçim, “geri gelmenin” gerçekçi olarak devam eden değeri işaret ettiği seçenektir, suçlulukla yapılan girişleri değil.

Adım adım: ilk etkinlik izleme planınızı oluşturun

İlk değere giden yol ile başlayın

SaaS için bir etkinlik izleme planı, yeni bir kişinin kayıt olmadan ilk gerçek kazanıma kadar nasıl ilerlediğini anlatan basit bir hikâyeyi takip ettiğinde en iyi şekilde çalışır.

Kısa onboarding yolunu yazın. Örnek: Kayıt -> e-posta doğrulama -> çalışma alanı oluşturma -> ekip arkadaşını davet etme (isteğe bağlı) -> veri bağlama (veya proje kurma) -> ilk kilit eylemi tamamlama -> sonucu görme.

Şimdi birinin takılıp kalabileceği veya vazgeçebileceği anları işaretleyin. Bu anlar, takip edeceğiniz ilk etkinlikler olur.

Minimum seti tanımlayın ve test edin

İlk versiyonu küçük tutun. Genelde 8–15 etkinliğe ihtiyacınız olur, 80’e değil. Bu soruları cevaplayan etkinliklere odaklanın: Başladılar mı? İlk değere ulaştılar mı? Geri döndüler mi?

Pratik bir yapım sırası:

• Onboarding ve ilk-değer yolunu eşle (tek bir sayfa, tartışma yok)
• Bu yolun her adımını kapsayan kısa bir etkinlik listesi seç
• Her etkinliği küçük bir spesifikasyonda tanımla (isim, ne zaman tetiklenir, hangi özellikler)
• Her etkinliğe bir sabit kullanıcı ID’si ve bir hesap/çalışma alanı ID’si ekle
• Yayınlamadan önce gerçek akışları çalıştırarak olayları test et

Etkinlik spesifikasyonu için bir dokümanda küçük bir tablo yeterlidir. İçerik: etkinlik adı, tetikleyici (üründe ne olması gerekiyor), kim tetikleyebilir ve her zaman göndereceğiniz özellikler.

İki ID erken karışıklıkların çoğunu önler: benzersiz bir kullanıcı ID’si (kişi) ve bir hesap veya çalışma alanı ID’si (çalıştıkları yer). Bu, kişisel kullanımı ekip benimsemesi ve yükseltmelerinden ayırmanıza yardımcı olur.

Yayınlamadan önce bir “yeni kullanıcı” testi yapın: yeni bir hesap oluşturun, onboarding’i tamamlayın, sonra her etkinliğin bir kez tetiklendiğini kontrol edin (sıfır değil, beş değil), doğru ID’lerle ve zaman damgalarıyla. Koder.ai gibi bir platformda inşa ediyorsanız bu testi olağan ön-yayın kontrolünüze dahil edin ki uygulama değiştikçe izleme doğru kalsın.

Etkinlikler için basit bir adlandırma kuralı

Adlandırma kuralı “doğru olmak” ile ilgili değil; grafikleriniz ürün değiştiğinde bozulmasın diye tutarlı olmakla ilgilidir.

Çoğu SaaS uygulaması için işe yarayan basit bir kural, snake_case içinde verb_noun kullanmaktır. Fiili net, ismi spesifik tutun.

Kopyalayabileceğiniz örnekler:

• created_project, invited_teammate, uploaded_file, scheduled_demo
• submitted_form (geçmiş zaman tamamlanmış bir eylem gibi okunur)
• connected_integration, enabled_feature, exported_report

Etkinliklerin çoğu için geçmiş zaman tercih edin. Bu belirsizliği ortadan kaldırır. Örneğin, started_checkout faydalı olabilir, ama gelir ve retansiyon çalışmaları için completed_checkout istediğiniz olaydır.

clicked_blue_button veya pressed_save_icon gibi UI-özgü isimlerden kaçının. Butonlar değişir, düzen değişir ve izleme eski ekranların tarihçesine dönüşür. Altta yatan niyeti adlandırın: saved_settings veya updated_profile.

UI değişse bile isimleri sabit tutun. created_workspace’ı sonra created_team olarak değiştirirseniz aktivasyon grafiğiniz ikiye bölünür ve sürekliliği kaybedersiniz. Eğer adı değiştirmek zorundaysanız, bunu bir göç olarak ele alın: eskiyi yeniye eşleyin ve kararı belgeleyin.

Rezerv edilmiş küçük önekler

Kısa bir önek seti, etkinlik listesi düzenli ve okunması kolay tutar. Birkaç tane seçin ve ona bağlı kalın.

Örneğin:

• auth_ (signup, login, logout)
• onboarding_ (ilk değere götüren adımlar)
• billing_ (deneme, ödeme, faturalar)
• admin_ (roller, izinler, organizasyon ayarları)

Koder.ai gibi sohbet odaklı bir oluşturucuda SaaS’inizi inşa ediyorsanız bu kural hâlâ geçerlidir. Bugün oluşturulan bir özellik yarın yeniden tasarlanabilir, ama created_project her UI yinelemesinde anlamlı kalır.

Eklenmesi gereken özellikler (ve bunları nasıl tutarlı yaparsınız)

İyi etkinlik isimleri ne olduğunu söyler. Özellikler (properties) ise bunu kimin, nerede yaptığı ve sonucun ne olduğu gibi sorulara cevap verir. Küçük, tahmin edilebilir bir set tutarsanız, SaaS etkinlik izleme planınız yeni özellikler ekledikçe okunabilir kalır.

“Her zaman açık” küçük bir çekirdek ile başlayın

Neredeyse her etkinlikte bulunacak birkaç özellik seçin. Bu, panoları müşteri tipine göre dilimlemenizi sağlar ve sonra yeniden kurulum gerektirmez.

Pratik çekirdek set:

• user_id ve account_id (bunu kim yaptı ve hangi çalışma alanına ait)
• plan_tier (free, pro, business, enterprise)
• timestamp (olayın ne zaman olduğu, mümkünse sunucudan)
• app_version (yayın sonrası değişiklikleri görmeniz için)
• signup_source (kullanıcının nereden geldiği: ads, referral, organic gibi)

Sonra anlamı değiştiğinde ek bağlam ekleyin. Örneğin, “Project Created” olayını project_type veya template_id ile göndermek çok daha faydalıdır; “Invite Sent” ise seats_count ile anlamlı hale gelir.

Sonuçları, sadece eylemleri değil, takip edin

Bir eylem başarısız olabiliyorsa, açık bir sonuç ekleyin. Basit bir success: true/false genelde yeterlidir. Başarısızsa kısa bir error_code (ör. "billing_declined" veya "invalid_domain") ekleyin ki sorunları ham loglara bakmadan gruplayabilesiniz.

Gerçekçi bir örnek: Koder.ai’da “Deploy Started” sonucu olmadan kafa karıştırıcıdır. success ve error_code ekleyin; böylece yeni kullanıcıların eksik alan kurulumu, kredi limitleri veya bölge ayarları yüzünden mi başarısız olduğunu hızlıca görürsünüz.

Panolarınızı kurtaran tutarlılık kuralları

İsim, tür ve anlamı bir kez kararlaştırın, sonra ona bağlı kalın. Eğer plan_tier bir etkinlikte string ise diğerinde sayı göndermeyin. Eşanlamlılıklardan (account_id vs workspace_id) kaçının ve asla bir özelliğin anlamını zaman içinde değiştirmeyin.

Daha iyi bir versiyona ihtiyacınız varsa, yeni bir özellik adı oluşturun ve panolar geçene kadar eskiyi saklayın.

Veri hijyeni ve gizlilik temelleri

Temiz takip verisi büyük ölçüde iki alışkanlıktır: yalnızca ihtiyaç duyduğunuzu gönderin ve hataları düzeltmeyi kolaylaştırın.

Analitiği bir eylem günlüğü olarak görün, kişisel detayları depolayacağınız yer olarak değil. Ham e-posta adresleri, tam isimler, telefon numaraları veya kullanıcıların serbest metin alanlarına yazdığı şeyleri göndermekten kaçının (support notları, geri bildirim kutuları, sohbet mesajları). Serbest metin genelde planlamadığınız hassas bilgiler içerebilir.

Bunun yerine dahili ID’leri kullanın. user_id, account_id ve workspace_id gibi şeyleri takip edin ve kişisel veriye eşlemeyi kendi veritabanınızda veya CRM’inizde tutun. Bir ekip arkadaşının gerçekten bir olayı bireyle eşlemesi gerekiyorsa, bunu iç araçlarınız aracılığıyla yapın; analitiğe PII kopyalamayın.

IP adresleri ve konum verileri için önceden bir karar verin. Birçok araç IP’yi varsayılan olarak yakalar; “şehir/ülke” zararsız görünebilir ama hâlâ kişisel veri sayılabilir. Bir yaklaşım seçin ve belgeleyin: hiçbir şey saklama, yalnızca kaba konum (ülke/bölge) saklama veya güvenlik için IP’yi geçici saklayıp sonra silme.

İlk panolarla birlikte yayınlamak için basit bir hijyen kontrol listesi:

• Göndereceğiniz etkinlik özelliklerinin bir izin-listesini tanımlayın (diğerleri engellensin)
• Bir kullanıcının verisini isteğe göre silme yolu ekleyin (user_id ve account_id ile)
• Erişimi sınırlayın: ham etkinlikleri kim görebilir, kim dışa aktarabilir, ve kim takibi değiştirebilir
• “Güvenli” vs “güvenli değil” özellik örnekleri içeren kısa bir takip dokümanı tutun

Koder.ai üzerinde SaaS’inizi inşa ediyorsanız aynı kuralları sistem loglarına ve snapshot’lara uygulayın: tanımlayıcıları tutarlı tutun, PII’yi event payload’larından uzak tutun ve kimin neyi neden görebileceğini yazın.

Erken aktivasyon ve retansiyon için olması gereken 10 pano

İyi bir SaaS etkinlik izleme planı ham tıklamaları cevaplara dönüştürür. Bu panolar iki şeye odaklanır: insanların ilk değere nasıl ulaştığı ve geri gelip gelmediği.

Aktivasyonu açıklayan panolar

• 1) Yeni kullanıcı trendi (günlük/haftalık) + signup_source: Yeni hesapları sayın ve nereden geldiklerine göre kırın (ads, organic, referral, invite). Aktivasyon sağlamayan ani artışlara dikkat edin.
• 2) Düşüşlerin vurgulandığı aktivasyon hunisi: Basit bir huni: Signup -> Email verified -> Project created -> First value action. En büyük düşüş adımını öne çıkarın ve oturumları inceleyin.
• 3) İlk değere ulaşma süresi (median, p75): Kullanıcıların ilk değer olayına ne kadar sürede ulaştığını ölçün. Median tipik yolu gösterir; p75 zorlananları gösterir.
• 4) Özellik benimseme (ilk 5 değer eylemi): Gerçek kullanım anlamı taşıyan birkaç eylemi takip edin (ayar tıklamaları değil). Okunabilir kalması için en fazla 5 ile sınırlayın.
• 5) Aktivasyon oranı signup_source’a göre: Aynı aktivasyon tanımını kaynak bazında ayırın. Bir kanal meraklı ziyaretçiler getirir, diğeriyse alıcıları.

Koder.ai gibi bir platformda ilk versiyonunuzu oluştursanız bile bu panolar aynıdır — anahtar tutarlı etkinliklerdir.

Retansiyonu açıklayan panolar

• 6) Retansiyon kohortları (hafta 1, hafta 4): Kayıt haftasına göre kohortlar, retansiyon anahtar bir eylemle ölçülür. Ürünün zaman içinde daha yapışkan olup olmadığını gösterir.
• 7) Geri gelen kullanıcı trendi (WAU): Haftalık aktif kullanıcılar (anahtar eyleme dayalı) “girişler”i gerçek kullanımdan ayırır.
• 8) Tekrarlanan değer sıklığı: Kullanıcıların çekirdek eylemi haftada kaç gün gerçekleştirdiği. Bu, alışkanlık oluşturan bir iş akışınız olup olmadığını ortaya koyar.
• 9) Yeniden-aktivasyon hunisi: Inactive -> Returned -> Did key action. Hatırlatıcılar ve yeni özelliklerin insanları geri getirip getirmediğini görmenizi sağlar.
• 10) Sürtünme panosu (hatalar ve başarısız eylemler): error_shown, payment_failed veya integration_failed gibi olayları takip edin. Buradaki sıçramalar sessizce aktivasyonu ve retansiyonu öldürür.

Örnek senaryo: kayıttan ilk değere kadar yeni bir SaaS’i izleme

Basit bir B2B SaaS düşünün; 14 günlük ücretsiz deneme sunuyor. Bir kişi kayıt olur, ekip için bir çalışma alanı oluşturur, ürünü dener ve ideal olarak bir ekip arkadaşını davet eder. Amacınız, insanların nerede takıldığını hızlıca öğrenmektir.

“İlk değer”i şöyle tanımlayın: kullanıcı bir çalışma alanı oluşturur ve ürünün onlar için çalıştığını kanıtlayan bir temel görevi tamamlar (örneğin “CSV içe aktarır ve ilk raporu üretir”). Erken takipte her şey bu ana dönmelidir.

Gün birinde yayına alabileceğiniz hafif bir etkinlik seti şöyle olabilir (isimler basit fiil geçmiş zamanlı ve nesne net):

• created_workspace
• completed_core_task
• invited_teammate

Her etkinlik için, neden olduğunu (veya olmadığını) açıklamak için yeterli özellik ekleyin. İyi erken özellikler:

• signup_source (google_ads, referral, founder_linkedin vb.)
• template_id (hangi başlangıç kurulumunu seçtiler)
• seats_count (özellikle ekip davetleri için)
• success (true/false) ve success=false ise kısa bir error_code

Şimdi panolarınızı hayal edin. Aktivasyon huniniz: signed_up -> created_workspace -> completed_core_task. Eğer workspace oluşturma ile çekirdek görev arasındaki düşüş büyükse, template_id ve success ile segmentleyin. Bir şablonun birçok başarısız koşuya yol açtığını (success=false) veya bir signup_source’tan gelenlerin yanlış şablonu seçip hiçbir zaman değere ulaşmadığını öğrenebilirsiniz.

Ardından “ekip genişleme” görünümünüz (completed_core_task -> invited_teammate) insanların yalnızca başarılı olduktan sonra mı davet ettiğini yoksa davetlerin erken olup davet edilenlerin çekirdek görevi tamamlamadığını mı gösterir.

İşte bir SaaS etkinlik izleme planının amacı: her şeyi toplamak değil, gelecek hafta düzeltebileceğiniz en büyük darboğazı bulmaktır.

Erken içgörüleri bozan yaygın hatalar

Çoğu takip hatası araçlarla ilgili değildir. Olaya tıklanan şeyi ölçerken ne elde ettiklerini söylemeyen verilerle olur. Eğer veriniz “kullanıcı değere ulaştı mı?” sorusunu cevaplayamıyorsa, SaaS etkinlik izleme planınız meşgul hissedecek ama hâlâ sizi tahmin etmekte bırakacaktır.

Hata 1: Sonuç yerine tıklamaları ölçmek

Tıklamalar takip etmesi ve yanlış okumak için kolaydır. Bir kullanıcı “Proje oluştur”a üç kez tıklayıp yine de başarısız olabilir. İlerlemenin tanımını yapan olayları tercih edin: bir çalışma alanı oluşturuldu, bir ekip arkadaşı davet edildi, veri bağlandı, yayınlandı, ilk fatura gönderildi, ilk çalışma tamamlandı gibi.

Hata 2: Her sprintte etkinlik isimlerini yeniden adlandırmak

Eğer isimleri en son UI metnine uydurmak için değiştirirseniz trendler kırılır ve haftalık bağlamı kaybedersiniz. Sabit bir etkinlik adı seçin, sonra anlamı özelliklerle evriltin (örneğin project_created’ı saklayın, yeni bir giriş noktası eklerseniz creation_source ekleyin).

Hata 3: B2B tanımlayıcıları unutmak

Sadece user_id gönderirseniz hesap sorularını yanıtlayamazsınız: hangi ekipler aktive oldu, hangi hesaplar churn etti, her hesap içinde kim güç kullanıcı. Her zaman bir account_id ekleyin (ve ideal olarak role veya seat_type) ki hem kullanıcı hem hesap retansiyonunu görebilesiniz.

Hata 4: Çok fazla özellik göndermek

Daha fazlası daha iyi değildir. Devasa, tutarsız bir özellik seti boş değerler, garip yazım varyantları ve kimsenin güvenmediği panolar yaratır. Küçük bir “her zaman var” set tutun; fazladan özellikleri yalnızca belirli bir soruya hizmet edecekse ekleyin.

Hata 5: Uçtan uca test etmeyi unutmak

Yayınlamadan önce doğrulayın:

• Etkinlikler bir kez tetikleniyor (iki kez değil) ve doğru anda
• Gerekli ID’ler mevcut (user_id, gerektiğinde account_id)
• Özellik değerleri kararlaştırılan listeyle eşleşiyor (sürpriz stringler yok)
• Panolar gerçek akışlardan güncelleniyor, yalnızca test verilerinden değil
• Kullanıcı yolunu sırayla yeniden oynatabiliyorsunuz

Koder.ai ile SaaS’inizi inşa ediyorsanız, takibi diğer bir özellik gibi ele alın: beklenen olayları tanımlayın, tam bir kullanıcı yolunu çalıştırın ve ancak sonra yayınlayın.

Takibi yayına almadan önce hızlı kontrol listesi

Daha fazla etkinlik eklemeden önce, takip sisteminizin 1. haftada gerçekten sahip olduğunuz soruları cevaplayıp cevaplamayacağını doğrulayın: insanlar ilk değere ulaşıyor mu ve geri geliyorlar mı.

Ana akışlarla başlayın (kayıt, onboarding, ilk değer, tekrar eden kullanım). Her akış için ilerlemeyi kanıtlayan 1–3 çıktı olayı seçin. Her tıklamayı takip ederseniz gürültüye boğulursunuz ve yine önemli anı kaçırırsınız.

Aynı adlandırma kuralını her yerde kullanın ve basit bir dokümana yazın. Amaç, iki kişinin bağımsız olarak aynı etkinliği adlandırıp aynı sonucu elde edebilmesidir.

Yayın öncesi kontrollerin çoğunu yakalayan kısa bir kontrol:

• Önce sonuç: Her ana akışın birkaç çıktı olayı var, onlarca UI tıklaması değil.
• İsimler tutarlı: Etkinlikler aynı fiil+isim stilini takip ediyor ve anlamı tek bir yerde belgelenmiş.
• Özellikler tipi olarak tutarlı: Kritik özellikler tüm etkinliklerde aynı türde kalıyor (ör. plan her zaman string, seat_count her zaman sayı).
• Panolar tanımlarla uyumlu: Aktivasyon panonuz aktivasyon olayınızı, retansiyon panonuz retansiyon olayınızı kullanıyor (rastgele bir vekil değil).
• Kullanıcı gibi QA yapın: Uygulamadan geçin ve olayların bir kez, doğru anda, doğru özelliklerle tetiklendiğini onaylayın.

Basit bir QA hilesi: Tam bir yolculuğu iki kez yapın. İlk koşu aktivasyonu doğrular. İkinci koşu (oturumu kapatıp tekrar girerek veya ertesi gün dönerek) retansiyon sinyallerini kontrol eder ve çift tetikleme hatalarını engeller.

Koder.ai ile inşa ediyorsanız, snapshot/rollback sonrası da aynı QA’yı yapın ki uygulama değiştikçe takip doğru kalsın.

Sonraki adımlar: hafif tutun ve yineleyin

İlk takip kurulumunuz küçük hissettirmeli. Uygulamayı yayına almak haftalar sürerse, daha sonra değiştirmekten kaçınırsınız ve veri üründen geri kalır.

Aynı panolara haftalık basit bir rutin seçin: aynı gün ve saatte aktivasyon ve retansiyon panolarına bakın, şaşırdığınız 3 çıkarımı ve 1 takip sorusu yazın ve yalnızca o soruyu açığa çıkaracaksa izlemeyi değiştirin. Amaç “daha fazla etkinlik” değil; daha net cevaplardır.

İyi bir kural: her seferinde 1–2 etkinlik ekleyin, her biri bugün cevaplayamadığınız tek bir soruya bağlı olsun. Örneğin: “Bir ekip arkadaşı davet eden kullanıcılar daha sık mı aktive oluyor?” Eğer zaten invite_sent takip ediyorsanız ama invite_accepted’i takip etmiyorsanız, sadece eksik olayı ve segment etmek için ihtiyaç duyduğunuz tek özelliği (ör. plan_tier) ekleyin. Yayınlayın, panoya bir hafta bakın, sonra sonraki değişimi kararlaştırın.

Erken ekipler için işe yarayan basit bir ritim:

• Haftada bir aktivasyon ve retansiyon panolarını inceleyin, aynı gün ve saatte
• 3 çıkarım ve 1 takip sorusu yazın
• Takibi sadece o soruyu açığa çıkaracaksa ekleyin veya ayarlayın
• Etkinlik isimlerini sabit tutun; önce özellik ekleyin sonra yeni etkinlik ekleyin
• Hiçbir şeyi silmeyin; emin olana kadar silmek trendleri bozar

Takip güncellemeleri için küçük bir değişiklik günlüğü tutun ki ileride herkes sayılara güvensin. Bir dokümanda veya repo notunda olabilir. İçerik:

• Tarih ve sahibi
• Ne değişti (etkinlik/özellik ismi)
• Neden değişti (soru)
• Beklenen etki (etkilenecek panolar)

İlk uygulamanızı inşa ediyorsanız, uygulamayı gerçekleştirmeden önce akışı planlayın. Koder.ai’da Planning Mode, onboarding adımlarını ve her adımda ihtiyaç duyulan etkinlikleri listelemek için pratik bir yoldur.

Onboarding üzerinde iterasyon yaparken takip tutarlılığınızı koruyun. Koder.ai snapshot’ları ve rollback kullanıyorsanız, ekranları ve adımları ayarlarken akışın ne zaman değiştiğinin net kaydını tutarak aktivasyondaki ani kaymaları açıklamayı kolaylaştırabilirsiniz.