Olay Tabanlı Otomasyon
Olay tabanlı otomasyon; kayıt, satın alma veya quiz tamamlama gibi ayrık olaylara yanıt olarak aksiyonlar çalıştırır ve her olayı bir aksiyon sinyali olarak ele alır.
Önemli noktalar
- Bir olay ad, zaman damgası, eyleyen kimliği ve tipli özellikler taşır.
- Tek bir olay, üretici haberdar olmadan çok sayıda tüketiciyi besleyebilir.
- Kopya ve sırasız teslim normaldir; tüketiciler idempotent çalışmak zorundadır.
- Tutarlı olay adlandırma, mevcut akışları yeniden kullanmanın ön koşuludur.
- Olaylar geçmişi tutar; güncel durumu taşıyan alanların yerini tutmaz.
Derinlemesine
Olay, gerçekleşen bir şeyin adlandırılmış kaydıdır; üzerinde bir zaman damgası, eyleyen kimliği ve bir dizi özellik taşır. Bir üretici olayı yayar, bir veri yolu veya webhook onu taşır, bir ya da daha fazla tüketici ise ada abone olur ve yükü işler. Yük olayla birlikte geldiği için tüketicinin ek bir sorgu yapmasına gerek kalmaz: kademe, kategori skorları ve yanıt kimliklerini taşıyan bir quiz_completed olayı, takibin dallanması için gereken her şeyi zaten içerir ve ek bir veri çağrısını gereksiz kılar.
Olay tabanlı otomasyonun kalitesi neredeyse tamamen şemaya bağlıdır. İyi adlandırılmış az sayıda olaydan ve tutarlı özellik adlarından oluşan küçük bir sözlük, üreticiye dokunmadan yeni tüketici eklemenizi sağlar; bütün mesele budur. Gevşek adlandırma tersini yapar: quiz_done, quizCompleted ve completed_quiz aynı işi yapan üç ayrı entegrasyona dönüşür. Ödünleşim hız ile disiplin arasındadır; taksonomi tanımlamak ilk kurulumu yavaşlatır ama bunu atlamak, sonraki her otomasyonun kimsenin bakımını üstlenmediği bir çeviri katmanı taşımasına yol açar. Bu katman zamanla en pahalı teknik borca dönüşür.
Ekipler genellikle her yüzey için tek bir üretici tutar ve çok sayıda tüketicinin abone olmasına izin verir. Aynı quiz_completed olayı CRM kaydını günceller, kişiyi bir diziye kaydeder, satış kanalına bildirim düşer ve analiz için veri ambarına iner; tüketicilerin hiçbiri diğerlerinden haberdar değildir. Segmentasyonu özellikler yapar: toplam skor yerine en zayıf kategoriye göre dallanmak, adayın gerçek boşluğunu adıyla anan bir takip üretir. Yeni bir tüketici eklemek o noktada yeniden kurulum değil, yalnızca bir abonelik kadar ucuza mal olur.
Olaylar neyin olduğunu anlatır, şu anda neyin doğru olduğunu değil. Bir kişinin güncel durumunu yeniden kurmak için bir aylık olayı yeniden oynatmak hem pahalıdır hem de çoğu zaman yanlıştır; çünkü olaylar sırasız gelir ve üretici yeniden denediğinde kopyalar normaldir. Bu yüzden tüketicilerin, her olayın taşıdığı benzersiz kimliğe dayanarak idempotent çalışması gerekir. Olaylar kötü de yaşlanır: üreticiden kaldırılan bir özellik tüketicileri sessizce bozar, geçmiş olaylar ise eski biçimini korur; şema değişikliğini kapsayan her analizin elle uzlaştırılması gerekir.
Pratikte örnek
Nasıl ölçülür
Önce teslim sağlığını izleyin: yayılan olaylar, teslim edilen olaylar ve tüketici başına hatalar. Hata sayısı artan bir tüketici otomasyonları sessizce düşürür ve bu, pazarlamaya hiç takip almamış leadler olarak yansır. Kuyruk gecikmesini de izleyin; yani olay zaman damgası ile tüketicinin onu işlemesi arasındaki farkı, çünkü gecikme, gerçek zamanlı bir tasarımı sessizce fiilen bir toplu işe çevirir.
Ardından şema uyumunu ölçün: tüm zorunlu özellikleri dolu gelen olayların payını. Bu payda görülen yavaş bir düşüş genellikle üreticinin sessizce değiştiğini ve tüketicilere haber verilmediğini gösterir. Bunu olay türüne göre sonuçlarla eşleştirin; quiz tamamlamayla sürülen otomasyonlardan gelen kişilerin dönüşümünü sayfa görüntülemeyle sürülenlerle karşılaştırın, böylece hangi olayın gerçekten bir tüketiciyi hak ettiğini, hangisinin yalnızca gürültü ürettiğini öğrenirsiniz.
Sık yapılan hatalar
Alışılmış hata, her ekibin kendi olay adlarını uydurmasına izin vermektir. Bir yıl içinde aynı kullanıcı eylemi üç farklı adla ve üç farklı özellik biçimiyle gelir; her yeni otomasyon bir eşleme tablosuyla başlar. Erken bir adlandırma kuralı üzerinde anlaşın: nesne artı geçmiş zaman fiili, küçük harf ve her olayda aynı kimlik özellikleri. Listeyi yalnızca kodda değil, pazarlama ekibinin de okuyabileceği bir yerde yayımlayın.
İkinci hata, tam olarak bir kez teslimi varsayan bir tüketicidir. Webhook yeniden denemesi aynı quiz tamamlamayı iki kez gönderir, kişi iki karşılama e-postası alır ve skor iki kez eklenir. Olay kimliğini saklayıp tekrarları yok sayın ya da aksiyonu doğal olarak tekrarlanabilir kurun; alanı artırmak yerine bir değere eşitleyin. Bunu bir olayı bilerek yeniden oynatarak test edin; böyle bir şeyin hiç olmayacağını ummayın.
Sıkça sorulan sorular
Olay yükü nedir?
Yük, bir olaya eklenen veridir; örneğin bir quizden gelen skor, kademe ve yanıtlar. Otomasyonlar, her olayı aynı şekilde ele almak yerine bir sonraki aksiyonu kişiselleştirmek için yükü okur.
Olay adlarını neden standartlaştırmalı?
Tutarlı olay adları ve özellikleri, otomasyonları güvenilir ve analizleri araçlar arasında doğru tutar. Bir adlandırma kuralı olmadan akışlar bozulur ve raporlamaya güvenmek zorlaşır.
Olay ile tetikleyici arasındaki fark nedir?
Tetikleyici bir platformun izlediği koşuldur; olay ise bir şey gerçekleştiğinde bir sistemin yayımladığı mesajdır. Tetikleyici genellikle tek bir aracın içinde yaşar ve kendi veritabanını okur; olay araçlar arasında dolaşır ve bir yük taşır. Çoğu yığın ikisini birlikte kullanır: olay webhook ile gelir, alan araç bu gelişi bir tetikleyici olarak işler.
Olayları nasıl adlandırmalıyım?
Nesne artı geçmiş zaman fiili, küçük harf ve alt çizgiyle: quiz_completed, deal_created, trial_started. Sözlüğü küçük tutun ve e-posta, hesap kimliği, zaman damgası gibi kimlik özelliklerini her olaya koyun. Değişken veriyi adın içine gömmekten kaçının; quiz_completed_security gibi bir ad, basit bir özellik filtresi yerine her varyant için yeni bir tüketici yazmayı zorunlu kılar.
Quiz tamamlama olayında hangi özellikler bulunmalı?
En azından kişi kimliği, skorkart kimliği, toplam skor, atanan kademe ve kategori bazlı dağılım. Tek tek yanıt kimliklerini de eklemek, sonraki otomasyonların ek sorgu yapmadan belirli bir yanıta göre dallanmasını sağlar. Skorkart için bir sürüm numarası koyun; böylece soru değişikliğini kapsayan bir analiz, hangi sürümün hangi skoru ürettiğini ayırt edebilir.
Event bus mı gerekir, webhook yeterli mi?
Bir üretici birkaç tüketiciyle konuştuğu sürece webhook yeterlidir. Aynı olayı birden çok araç istemeye başladığında bus kendini amorti eder; yeniden deneme, geçmişi yeniden oynatma ve üreticiye dokunmadan abone ekleme tek bir yerde toplanır. Çoğu ekip webhook ile başlar ve yeniden deneme mantığını kopyalamaya başladığında bus tarafına geçer.
Olay ateşlendiğinde tüketici kapalıysa ne olur?
Bu, taşıma katmanına bağlıdır. Yeniden denemesi olmayan düz bir webhook olayı kaybeder ve otomasyon hiç çalışmaz. Kuyruğu olan sistemler olayı saklar ve yeniden teslim eder; tüketicilerin kopyalara dayanıklı olması gerekmesinin nedeni budur. Platformunuzun ne kadar süre yeniden denediğini ve hataların bir yerde görünüp görünmediğini sorun, çünkü sessiz kayıp düşük dönüşüm gibi görünür.
Aynı olayları hem analitik hem otomasyon için kullanabilir miyim?
Evet, zaten amaç budur: iyi tanımlanmış tek bir akış hem veri ambarını hem pazarlama araçlarını besler. Ancak ikisinin toleransları farklıdır. Analitik dakikalarca bekleyebilir ve kopyaları sonradan temizleyebilir; otomasyon olayı hızlı ve tek seferde ister. İkisini aynı üreticiden dağıtın ama otomasyonu, ambardaki yükleme tamamlanana kadar beklemeye asla zorlamayın.