Bir senaryo, bir olay tipini değerlendiren kurallar bütünüdür. Kuralları arayüzden kurarsınız; bu sayfa hangi yapı taşlarının olduğunu ve nasıl birleştiklerini anlatır.

​
Tetikleme koşulu

Senaryonun hangi olaylarda hiç çalışacağını belirleyen ön filtre. Örneğin yalnızca satış ve iptal işlemlerini değerlendirmek isterseniz, geri kalanı kural yazmadan burada elenir ve Unknown sonucuyla döner.

​
Kural = koşul ağacı + puan

Her kural bir koşul ağacıdır: alanlar, karşılaştırmalar ve bunların iç içe VE/VEYA birleşimleri. Ağaç doğru sonuç verirse kuralın puanı toplama eklenir.

​
Operatörler

equal, notequal, contains, notcontains, startswith, endswith, isempty, isnotempty, in (listede), notin, similarity (benzerlik oranı).
equal, notequal, lessthan, lessthanorequal, greaterthan, greaterthanorequal, between, notbetween.
Karşılaştırmaların yanında hazır pencereler: last24hours, lastnhours, last7days, last90days, lastndays, thismonth, lastmonth ve ileri yöndeki karşılıkları.
matchesregex, notmatchesregex — düzenli ifadeyle eşleme. Kart numarası şekli, tek kullanımlık e-posta alan ailesi, telefon ön eki gibi contains ile yazılamayan koşullar için.Her eşleme bir zaman sınırı altında koşar; sınırı aşan bir desen eşleşmemiş sayılır ve sayaca yazılır. Yayın anında desenin geçerliliği kontrol edilir.
Kelime sınırı (\b, \y) kabul edilmez. Bellek içi ve SQL değerlendiricileri bu ifadeyi farklı yorumlar, yani aynı kural agregat alındığında farklı cevap verir. Bunun yerine sınırı açıkça yazın: (^|[^a-z])kelime([^a-z]|$).
Değer yerine başka bir alan seçebilirsiniz: fatura ülkesi ile teslimat ülkesi, kart sahibi adı ile hesap adı, sipariş toplamı ile satır toplamı.Editörde değerin yanındaki geçiş düğmesiyle açılır. Referans edilen alan payload’da yoksa koşul eşleşmez — olumsuz operatörlerde de eşleşmez, yani veri eksikken kural tetiklenmez.
ipgeolocation, ipdatacenter, emaildisposable, emailfreeprovider, emailnomx, phoneinvalid, phonecountry, phonelinetype, uabot, uadevicetype, sslcertcheck, whoislookup, sanctionsmatch, cryptoaddresssanctioned.cryptoaddresssanctioned, bir String alanın değeri yaptırım listesindeki bir kripto adresi olduğunda tetiklenir. Değer almaz. Yanındaki sanctionsmatch’in aksine benzerliğe değil, adresin standart biçimine tam eşitlik arar: ismin yazımları vardır, adresin ise tek bir biçimi ve tek bir sahibi vardır — yani yakın bir eşleşme daha zayıf bir eşleşme değil, başka bir adrestir.
sanctionsmatch gibi bu da tarayamadığında kapalı tarafa düşer: liste o host’a yüklenemediği için taranamayan bir adres eşleşme sayılır. Liste hiç gelmediği için “listede değil” demek zayıflamış bir kontrol değil, kimsenin yapmadığı bir temize çıkarmadır. Durumu /healthz/verbose bildirir; her işlem birden eşleşmeye başladığında ilk bakılacak yer orasıdır.
Ayrıntı: Sinyaller ve Yaptırım taraması.
in, notin bir değerin listede olup olmadığını sorar ve tam eşitlik arar. Kart BIN’i, IBAN, cihaz kimliği için doğru olan budur.watchlistmatch ise isim için vardır: aynı normalizasyon ve aynı benzerlik ölçüsüyle çalışır, yani “Muhammet Yilmaz” ile “Muhammed Yılmaz” tek kişidir. Yalnızca kişi ya da kurum adı taşıyor olarak işaretlenmiş listelere karşı kullanılır.
Bir isim listesini in ile karşılaştırmak, listeyi pratikte hiç tetiklenmez hâle getirir: isim size müşterinin sisteminde nasıl yazıldıysa öyle gelir, ve yalnızca birinin iki yere aynı şekilde yazdığı kayıtlar yakalanır. Kural doğru görünür, çalışmaz.

​
Liste ağırlıkları

Üyelik tek bir soruyu iyi cevaplar: bu değer listede mi. Risk ise nadiren evet ya da hayırdır — kumar, elektronikten; elektronik, marketten risklidir. Bunu üyelikle anlatmak, her bant için ayrı liste tutmak demektir; üçünden ikisi güncellenir ve listeler birbirinden ayrışır. Liste kaydına isteğe bağlı bir ağırlık verilebilir, ve koşul değerin kendisi yerine bu ağırlığı karşılaştırır. Editörde agregatla aynı yerden seçilir — çünkü aynı işi yapar: karşılaştırmanın sol tarafını değiştirir, operatör ve değer aynen çalışır.
Ağırlığı olmayan kayıt ile ağırlığı sıfır olan kayıt aynı şey değildir. Listede ağırlığı bulunmayan bir değer sıfır kabul edilerek karşılaştırılır — atlansaydı “ağırlık < 10” kuralı tam da yakalamak için yazıldığı bilinmeyen kitleyi kaçırırdı — ve karar kaydına hangisi olduğu yazılır.
CSV ile yükleme değer,ağırlık satırlarını kabul eder. Virgülsüz satırlar eskisi gibi düz üyelik kaydı olarak eklenir.

​
Hız kuralları ve agregatlar

Bir koşul tek işleme değil, geçmişe bakabilir: aynı cihaz son 24 saatte kaç hesaba dokundu, aynı IBAN kaç farklı göndericiden tahsilat aldı. Alanın yanındaki Aggregate seçicisiyle açılır; alt filtreler hangi kayıtların sayılacağını belirler.
PRIOR_DECISIONS, PRIOR_ALERTS ve LINKED_ENTITIES agregatlarının altına alt filtre yazılamaz. Üçü de kaydın kendi tablosunu sorgulamaz, yani bir filtrenin daraltacağı sorgu yoktur — ama farklı yerlerden okurlar ve hangisinden okudukları önemlidir: ilk ikisi platformun kendi karar geçmişinden cevaplanır, LINKED_ENTITIES ise kimlik bağlantı grafiğinden. Grafikte her tanımlayıcı–kayıt çifti için tek satır vardır: tanımlayıcı, onu taşıyan kayıt ve ne zaman görüldüğü — kaydın kendi sütunlarından hiçbiri yoktur. Yayınlama alt filtreyi reddeder; sessizce yok saymak, yazarın yazdığından geniş bir kitleyi saydırırdı.

​
Kendi kararlarımızın geçmişi

Diğer bütün agregatlar müşterinin bize gönderdiğini okur. Son ikisi bizim ne yaptığımızı okur, ve “bu kartı bu ay dört kez incelemeye gönderdik” hiçbir işlem verisinde bulunmayan bir sinyaldir. İkisi ayrı agregattır çünkü ayrı ifadelerdir: yirmi kez karar verdiğimiz müşteri genelde sık müşteridir, dört kez incelemeye gönderdiğimiz müşteri değildir. Sayım, kaydın pivot değeri üzerinden yapılır — karar zaten ait olduğu varlığa yazılır ve vakalar onunla gruplanır. Pivotu olmayan bir tabloda sayım sıfırdır.
Pencere 30 gündür ve kuralda değiştirilemez. Şu anda verilen karar sayıma dahil değildir: henüz kaydedilmemiştir, ve sayılsaydı kural yazarın kastettiğinden bir işlem önce tetiklenirdi.
Karar verilen işlem kendi agregatına dahil edilir — ama yalnızca bunun kesin yapılabildiği yerlerde (COUNT, SUM, MIN, MAX). Böylece cevap, çağıranın olayı karardan önce gönderip göndermediğine göre değişmez.

​
İmkânsız seyahat

TIME_SINCE_LAST ve DISTANCE_FROM_LAST aynı senaryoda yan yana durunca tek bir alanın üretemeyeceği bir sinyal çıkar: kart sahibinin o sürede varamayacağı bir yerden gelen ödeme.
DISTANCE_FROM_LAST, "41.0082,28.9784" biçiminde bir metin alanı okur. Ondalık ayırıcı noktadır ve sunucunun yerel ayarından etkilenmez.
Önceki kayıt yoksa — ya da konumu okunamıyorsa — cevap sıfır değil, yok. Sıfır “aynı yer” ya da “az önce oldu” diye okunur ve hiç işlem yapmamış her müşteride hız kuralını tetiklerdi. Cevabı olmayan bir karşılaştırma iki yönde de eşleşmez: ne “500 km’den uzak” ne “60 saniyeden yakın” tetikler.

​
Puanlama

Puan pozitif ya da negatif olabilir. Negatif puan, yanlış alarmı düşürmenin en doğrudan yoludur: “on ikiden fazla başarılı işlemi olan müşteri” kuralına -20 vermek, o müşterilerin tek bir zayıf sinyalle eşiği aşmasını engeller.
Puanları 5’in katları olarak tutun ve toplam bütçenizi baştan belirleyin. Her kurala rastgele bir sayı vermek, altı ay sonra kimsenin eşikleri neden oraya koyduğunu hatırlayamadığı bir sisteme dönüşür.

​
Eşikler

Üç eşik, dört sonuç. Eşikler artan sırada olmalıdır — inceleme ≤ engelle-ve-incele ≤ red.
Eşiği nereye koyacağınıza karar vermek için tahmin yürütmeniz gerekmez: Analiz → Eşik simülasyonu geçmiş kararlarınızı yeni eşiklerle yeniden okur ve kaç işlemin başka sonuçlanacağını söyler.

​
Sürüm yayınlama

Kural değişiklikleri taslak sürümde birikir; canlı sürüm etkilenmez. Publish dediğinizde taslak canlı olur ve eskisi kayıtta kalır. Taslak, siz yayınlayana kadar hiçbir kararı etkilemez — yarım kalmış bir kural seti canlı trafiğe bakmaz.

​
Yayın doğrulaması

Publish, senaryoyu canlıya almadan önce şunları kontrol eder ve sorunların hepsini birden raporlar: Hepsi birden raporlanır, çünkü teker teker yayınlamak canlı trafiğe karşı deneme yanılma demektir.

​
Yayında ikinci onay

Ayarlar → Organizasyon → Yayın kuralları ile açılır. Açıkken Publish yayınlamaz, bir talep kaydeder: taslak taslak kalır, başka biri inceleyip yayınlar. Talep eden kendi talebini onaylayamaz.
Talepten sonra taslakta yapılan her düzenleme talebi geçersiz kılar ve sonraki yayın onay değil, yeni bir talep sayılır. Bu olmasaydı kontrol sıradan işe benzeyen tek hamlede kırılırdı: Ada yayın talep eder, Grace kuralları düzenler, Grace onaylar — iki farklı kişi, iki adım da kayıtlı, ama canlıya çıkan değişikliği Grace’ten başka kimse okumamış olur.
Düzenlemeyi reddetmek yerine talebi geçersiz kılmak bilinçli bir tercihtir: inceleyen kişinin işi düzeltilmesi gerekeni bulmaktır, ve bulduğu için cezalandıran bir kontrol herkese okumadan onaylamayı öğretir. Varsayılan kapalıdır. Kontrol olduğu kadar maliyettir de, ve iki kişilik bir ekip bunu ödeyemez.

​
Sürümleri karşılaştırma

Kurallar ekranındaki Compare versions iki sürüm arasında ne düzenlendiğini gösterir: eklenen, silinen ve değişen kurallar; değişen her alanın öncesi ve sonrası; eşikler, schedule ve tetikleme koşulu. Bu, gölge koşumun cevapladığı sorunun diğer yarısıdır. Gölge koşum iki sürümün canlı trafikte nasıl davrandığını ölçer; bu ekran birinin ne değiştirdiğini söyler. Ölçülebilir bir etkisi olmayan değişiklik de hesabı sorulabilecek bir değişikliktir. Kural koşulları JSON olarak değil, cümle olarak gösterilir — yan yana iki JSON bloğu, kimsenin gerçekten yapmadığı bir karşılaştırmadır; onaylanır ve geçilir.
Kurallar isimle eşleştirilir. Taslak açılırken her kural yeni bir satıra kopyalanır, yani sürümler arasında kalıcı bir kural kimliği yoktur. Bunun bedeli, bir kuralı yeniden adlandırmanın “silindi + eklendi” olarak görünmesidir; ekran bunu açıkça yazar. Formülleri eşleştirip yeniden adlandırma tahmin etmek, olmayan bir düzenlemeyi anlatmak olurdu.

​
Yayınlanan sürüm değişmez

Sürüm numarası yayın anında verilir ve o sürüm bir daha düzenlenemez. Düzenleme her zaman taslağa gider; taslak yoksa canlı sürümün kopyası olarak açılır.
Her karar hangi sürümle verildiğini taşır ve o sürüm oynamaz. “Bu kararı hangi kurallar verdi” sorusunun cevabı, karar altı ay önce verilmiş olsa da aynıdır — geri alma da ne değiştiğini hatırlamaya çalışmak değil, önceki sürümü yayınlamaktır.

​
Kural sağlıklı mı?

Analiz → Kural performansı her kural için şunu söyler: kaç kez tetiklendi ve kaç kararda sonucu gerçekten değiştirdi. İkincisi, kuralın puanı çıkarılıp geri kalan yeniden puanlanarak hesaplanır. Çok tetiklenip hiç belirleyici olmayan bir kural, her skora gürültü ekliyor demektir. Silmeden önce puanını düşürmeyi deneyin.