मुख्य सामग्री पर जाएं
इवेंट का मूल्यांकन उसी इंजन से होता है जिससे लेन-देन का मूल्यांकन होता है। नियम मॉडल, शर्त शब्दावली और कार्रवाइयों का सेट एक ही है। एक नियम केवल यह घोषित करता है कि वह किन रिकॉर्ड प्रकारों पर लागू होता है।

लागू होता है

scope.record_types तय करता है कि नियम किन पर ट्रिगर होगा।
इसे छोड़ने से नियम केवल लेन-देन पर रहता है। इवेंट आने से पहले लिखे गए हर नियम का व्यवहार पहले जैसा ही रहता है, और केवल इसलिए कि scope खाली है, कोई नियम लॉगिन से मेल खाना शुरू नहीं करता।
कंसोल में यह नियम के Trigger चरण पर लागू होता है सेलेक्टर है। इवेंट चुनने पर इवेंट श्रेणियाँ चेकलिस्ट दिखती है, जो नियम को और सीमित करती है। उसे पूरी तरह अनचेक छोड़ने पर हर श्रेणी का मूल्यांकन होता है।
"__current__" का अर्थ है “जिस इवेंट का मूल्यांकन किया जा रहा है, उसमें मौजूद उसी मान के बराबर”। इसी से नियम बिना किसी मान का नाम लिए प्रति विषय, प्रति डिवाइस या प्रति राउंड बताता है। जिन रिकॉर्ड में समूहीकृत मान नहीं है, उन्हें कभी एक साथ समूहित नहीं किया जाता। जिस इवेंट में कोई डिवाइस फ़िंगरप्रिंट नहीं है, वह बिना फ़िंगरप्रिंट वाले अन्य इवेंट के “समान डिवाइस” के बराबर नहीं है। और जो इवेंट कोई विषय नहीं बताता, वह अन्य अनाम इवेंट के “समान विषय” के बराबर नहीं है। जब मूल्यांकन हो रहे इवेंट में किसी "__current__" फ़ील्ड का मान नहीं है, तो वह एग्रीगेशन उसके ऑपरेटर चाहे जो हो, मेल नहीं खाता।

इवेंट फ़ील्ड

शर्तें नेमस्पेस वाले पाथ पढ़ती हैं। लेन-देन की वह शब्दावली जो आप पहले से जानते हैं (action_type, subject_vendor_data, subject_ip_country, custom_values.<key>) इवेंट पर भी हल होती है। विषय संकेत मॉनिटर किए गए उपयोगकर्ता पर कैश होते हैं, हर इवेंट पर दोबारा गणना नहीं होती, इसलिए नियम उन्हें इनजेशन की गति से पढ़ सकता है।

एग्रीगेशन

वेलोसिटी

वही रिड्यूसर जो आप लेन-देन पर पहले से उपयोग करते हैं, count, sum, avg, min, max, distinct_count, एक रोलिंग window (30m, 24h, 7d, 30d) पर।

अनुपात

एक ही window पर दो रिड्यूसर। वेजर-टू-डिपॉज़िट, विथड्रॉल-टू-डिपॉज़िट, बोनस-टू-डिपॉज़िट और चार्जबैक दरें इसी तरह व्यक्त होती हैं।
1,000 जमा करें, 20 का वेजर लगाएँ, फिर निकासी का अनुरोध करें, तो अनुपात 0.02 होगा, यह न्यूनतम खेल वाली मनी लॉन्ड्रिंग का क्लासिक पैटर्न है।
बिना हर वाला अनुपात कभी मेल नहीं खाता। कोई डिपॉज़िट न होना शून्य अनुपात नहीं है, वह कोई साक्ष्य नहीं है, और वहाँ सक्रिय होने से हर नए उपयोगकर्ता पर फ़्लैग लग जाता।

अनुक्रम

विंडो के भीतर क्रमबद्ध प्रेडिकेट। हर चरण action_type, event_category या किसी मनमाने match फ़िल्टर पर मेल खाता है, और अनुक्रम आगे बढ़ने से पहले min_count घटनाओं की माँग कर सकता है।
पहले क्रेडेंशियल स्टफ़िंग, फिर MFA टेकओवर, फिर पेआउट रीडायरेक्ट, और अंत में ड्रेन। नियम उस इवेंट पर ट्रिगर होता है जो श्रृंखला पूरी करता है, और मिलने वाले साक्ष्य में हर चरण के इवेंट id सूचीबद्ध होते हैं। अनुक्रम की स्थिति प्रति नियम और प्रति विषय रखी जाती है, इसलिए वह टाइमलाइन दोबारा स्कैन करने के बजाय इवेंट आने के साथ आगे बढ़ती है। विंडो से पुरानी प्रगति हटा दी जाती है, उसे गिना नहीं जाता।

सह-संबंध

क्रॉस-विषय जॉइन: इस इवेंट के समूह में आने वाले हर इवेंट पर रिड्यूस।
"pair": true दोनों सिरों को एक अक्रमित समूह के रूप में मिलाता है, इसलिए A→B और B→A एक ही समूह में आते हैं। इसी से एक नियम मिलीभगत के दोनों हिस्से देख पाता है। चिप डंपिंग, विपरीत दिशा में दाँव और एफ़िलिएट स्व-रेफ़रल, ये सभी इसी प्रकार के हैं। सह-संबंध नियम को हमेशा सीमित करने वाले filters दें। उनके बिना वह विंडो के हर इवेंट पर विचार करता है।

रीयल-टाइम और एसिंक्रोनस नियम

कुछ नियम इनजेस्शन अनुरोध के भीतर ही जवाब दे सकते हैं, जबकि कुछ नहीं। जिस इवेंट के नियम अभी लंबित हैं, वह "correlation_pending": true के साथ वापस आता है। एसिंक्रोनस पास पूरा होने पर उसका स्टेटस और स्कोर उसी जगह अपडेट हो जाते हैं। री-रनिंग आइडेम्पोटेंट है, इसलिए कोई नियम अपना स्कोर दो बार लागू नहीं करता। यह बँटवारा जानबूझकर किया गया है: विषयों के बीच की रिंग क्वेरी लॉगिन को इंतज़ार नहीं करवा सकती।

कार्रवाइयाँ

ट्रांज़ैक्शन नियमों वाली ही कार्रवाई शब्दावली लागू होती है: add_score, change_status, add_tags, add_note, add_to_list, open_case। इवेंट के लिए दो अंतर हैं:
  • AWAITING_USER पर change_status केवल ट्रांज़ैक्शन का परिणाम है (इवेंट के लिए कोई सुधार प्रवाह नहीं है) और इसे IN_REVIEW के रूप में लागू किया जाता है।
  • open_case केस को किसी ट्रांज़ैक्शन के बजाय विषय से जोड़ता है और केस पर मिलान किए गए इवेंट का आईडी दर्ज करता है।

प्रमाण

हर मिलान यह संग्रहीत करता है कि उसने क्या देखा: एग्रीगेशन विंडो, गणना किया गया मान, अपेक्षित मान, नमूना इवेंट आईडी, और हर मिलान किए गए फ़ील्ड का स्रोत। इसलिए कोई विश्लेषक किसी मिलान पर कार्रवाई करने से पहले देख सकता है कि सर्वर द्वारा दर्ज IP है या क्लाइंट द्वारा दिया गया संकेत। कंसोल इवेंट ड्रॉअर में हर मिलान किए गए फ़ील्ड के आगे उसका स्रोत दिखाता है।

उदाहरण

जमा, टोकन खेल, तेज़ निकासी। शर्त event.action_type eq withdrawal_requested, साथ ही ऊपर वाला वेजर-से-जमा अनुपात 24h की विंडो पर lte 0.1 पर।
30d की विंडो पर, प्रति विषय count(chargeback_opened) और count(deposit_completed) का अनुपात, gte 0.5। एक ही इंस्ट्रूमेंट को कई खातों में पकड़ने के लिए विषय के बजाय event.payment.payment_fingerprint से समूहित करें।
ऊपर वाला ato_drain अनुक्रम, add_score 90 और change_status DECLINED के साथ।
ऊपर दिया गया जोड़ी-सहसंबंध। value को उस रकम पर सेट करें जो आपकी टेबल के लिए महत्वपूर्ण हो, और खेलों को अलग रखने के लिए event.gameplay.game_id को group_by में जोड़ें।
event.action_type eq bot_signal_observed, event.bot.timing_variance_ms lte 10 और event.device.bot_score gte 90 पर शर्तें, add_tags के साथ। एक स्क्रिप्ट के बजाय फ़ार्म पकड़ने के लिए इन्हें प्रति IP event.device.fingerprint के distinct_count के साथ मिलाएँ।
event.action_type eq self_exclusion_match और event.payload.re_registration_attempt eq true पर शर्त, open_case के ज़रिए एस्केलेट करें।

आगे

इवेंट इनजेस्शन

एनवेलप, दस श्रेणियाँ और बैच अनुबंध।

नियम API

नियम प्रोग्रामेटिक रूप से बनाएँ, अपडेट करें और बैक-टेस्ट करें।
अंतिम संशोधन 7 नवंबर 2026