> ## Documentation Index
> Fetch the complete documentation index at: https://docs.didit.me/llms.txt
> Use this file to discover all available pages before exploring further.

# इवेंट नियम - वेलोसिटी, अनुपात, अनुक्रम, सहसंबंध

> Didit के साथ इवेंट डेटा पर वेलोसिटी, अनुपात, अनुक्रम और सहसंबंध नियम बनाएँ, उसी नियम बिल्डर में जो आपके ट्रांज़ैक्शन नियमों में है।

[इवेंट](https://docs.didit.me/hi/transaction-monitoring/events.md) का मूल्यांकन उसी इंजन से होता है जिससे लेन-देन का मूल्यांकन होता है। नियम मॉडल, शर्त शब्दावली और कार्रवाइयों का सेट एक ही है। एक नियम केवल यह घोषित करता है कि वह किन रिकॉर्ड प्रकारों पर लागू होता है।

## लागू होता है

`scope.record_types` तय करता है कि नियम किन पर ट्रिगर होगा।

| `record_types` | ट्रिगर होता है |
| - | - |
| छोड़ा गया हो या `["transaction"]` | केवल लेन-देन - **डिफ़ॉल्ट** |
| `["event"]` | केवल इवेंट |
| `["transaction", "event"]` | दोनों |

> [!NOTE]
>
> इसे छोड़ने से नियम केवल लेन-देन पर रहता है। इवेंट आने से पहले लिखे गए हर नियम का व्यवहार पहले जैसा ही रहता है, और केवल इसलिए कि scope खाली है, कोई नियम लॉगिन से मेल खाना शुरू नहीं करता।

कंसोल में यह नियम के Trigger चरण पर **लागू होता है** सेलेक्टर है। इवेंट चुनने पर **इवेंट श्रेणियाँ** चेकलिस्ट दिखती है, जो नियम को और सीमित करती है। उसे पूरी तरह अनचेक छोड़ने पर हर श्रेणी का मूल्यांकन होता है।

```json theme={null}
{
  "title": "Failed login burst",
  "scope": {
    "record_types": ["event"],
    "event_categories": ["security"]
  },
  "aggregation": [
    {
      "metric": "count",
      "operator": "gte",
      "value": 3,
      "window": "30m",
      "filters": {
        "subject_vendor_data": "__current__",
        "event.action_type": "login_failed"
      }
    }
  ],
  "actions": [
    { "type": "add_score", "value": 40 },
    { "type": "change_status", "value": "IN_REVIEW" }
  ]
}
```

`"__current__"` का अर्थ है "जिस इवेंट का मूल्यांकन किया जा रहा है, उसमें मौजूद उसी मान के बराबर"। इसी से नियम बिना किसी मान का नाम लिए *प्रति विषय*, *प्रति डिवाइस* या *प्रति राउंड* बताता है।

जिन रिकॉर्ड में समूहीकृत मान नहीं है, उन्हें कभी एक साथ समूहित नहीं किया जाता। जिस इवेंट में कोई डिवाइस फ़िंगरप्रिंट नहीं है, वह बिना फ़िंगरप्रिंट वाले अन्य इवेंट के "समान डिवाइस" के बराबर नहीं है। और जो इवेंट कोई विषय नहीं बताता, वह अन्य अनाम इवेंट के "समान विषय" के बराबर नहीं है। जब मूल्यांकन हो रहे इवेंट में किसी `"__current__"` फ़ील्ड का मान नहीं है, तो वह एग्रीगेशन उसके ऑपरेटर चाहे जो हो, मेल नहीं खाता।

## इवेंट फ़ील्ड

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

| समूह | पाथ |
| - | - |
| इवेंट | `event.category`, `event.action_type`, `event.occurred_at`, `event.amount`, `event.currency`, `event.direction`, `event.session_id`, `event.session_sequence`, `event.score`, `event.status`, `event.ingest_source`, `event.retention_class`, `event.subject_vendor_data`, `event.business_vendor_data` |
| डिवाइस और नेटवर्क | `event.device.fingerprint`, `event.device.persistent_device_id`, `event.device.bot_score`, `event.ip.address`, `event.ip.country`, `event.ip.asn_number`, `event.ip.asn_organization`, `event.ip.is_vpn_or_tor`, `event.ip.is_data_center`, `event.ip.proxy_type`, `event.ip.country_name`, `event.ip.city`, `event.ip.connection_type`, `event.ip.travel_distance_km`, `event.ip.travel_speed_kmh` |
| गेमप्ले | `event.gameplay.game_id`, `event.gameplay.table_id`, `event.gameplay.round_id`, `event.gameplay.hand_id`, `event.gameplay.match_id`, `event.gameplay.market_id`, `event.gameplay.side`, `event.gameplay.role`, `event.gameplay.counterparty_vendor_data`, `event.gameplay.net_result_amount`, `event.bonus.bonus_id`, `event.affiliate.affiliate_code` |
| भुगतान और विवाद | `event.payment.reference_id`, `event.payment.payment_fingerprint`, `event.payment.instrument_reference_hash`, `event.payment.withdrawal_address_hash`, `event.dispute.dispute_id`, `event.dispute.chargeback_id` |
| सुरक्षा और ज़िम्मेदार गेमिंग | `event.security.changed_field`, `event.responsible_gambling.identity_match_ref` |
| बॉट और सहायता टेलीमेट्री | `event.bot.timing_variance_ms`, `event.bot.actions_per_minute`, `event.bot.pointer_entropy`, `event.bot.reaction_time_ms_p50`, `event.bot.assistance_indicator` |
| विषय संकेत | `subject.email.risk_score`, `subject.email.social_count`, `subject.email.is_disposable`, `subject.email.deliverability`, `subject.email.domain_reputation`, `subject.email.first_seen_days`, `subject.email.is_breached`, `subject.phone.risk_score`, `subject.phone.line_type`, `subject.phone.social_count`, `subject.phone.carrier`, `subject.phone.country`, `subject.phone.is_disposable` |
| अन्य सब कुछ | `event.payload.<key>`, `custom_values.<key>` |

विषय संकेत मॉनिटर किए गए उपयोगकर्ता पर कैश होते हैं, हर इवेंट पर दोबारा गणना नहीं होती, इसलिए नियम उन्हें इनजेशन की गति से पढ़ सकता है।

## एग्रीगेशन

### वेलोसिटी

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

### अनुपात

एक ही window पर दो रिड्यूसर। वेजर-टू-डिपॉज़िट, विथड्रॉल-टू-डिपॉज़िट, बोनस-टू-डिपॉज़िट और चार्जबैक दरें इसी तरह व्यक्त होती हैं।

```json theme={null}
{
  "metric": "ratio",
  "window": "24h",
  "filters": { "subject_vendor_data": "__current__" },
  "numerator":   { "metric": "sum", "field": "event.amount", "filters": { "event.action_type": "bet_placed" } },
  "denominator": { "metric": "sum", "field": "event.amount", "filters": { "event.action_type": "deposit_completed" } },
  "operator": "lte",
  "value": 0.1
}
```

1,000 जमा करें, 20 का वेजर लगाएँ, फिर निकासी का अनुरोध करें, तो अनुपात 0.02 होगा, यह न्यूनतम खेल वाली मनी लॉन्ड्रिंग का क्लासिक पैटर्न है।

> [!NOTE]
>
> **बिना हर** वाला अनुपात कभी मेल नहीं खाता। कोई डिपॉज़िट न होना शून्य अनुपात नहीं है, वह कोई साक्ष्य नहीं है, और वहाँ सक्रिय होने से हर नए उपयोगकर्ता पर फ़्लैग लग जाता।

### अनुक्रम

विंडो के भीतर क्रमबद्ध प्रेडिकेट। हर चरण `action_type`, `event_category` या किसी मनमाने `match` फ़िल्टर पर मेल खाता है, और अनुक्रम आगे बढ़ने से पहले `min_count` घटनाओं की माँग कर सकता है।

```json theme={null}
{
  "metric": "sequence",
  "key": "ato_drain",
  "window": "24h",
  "steps": [
    { "event_category": "security", "action_type": "login_failed", "min_count": 3 },
    { "event_category": "security", "action_type": "mfa_changed" },
    { "event_category": "payment",  "action_type": "withdrawal_address_changed" },
    { "event_category": "payment",  "action_type": "withdrawal_requested" }
  ]
}
```

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

अनुक्रम की स्थिति प्रति नियम और प्रति विषय रखी जाती है, इसलिए वह टाइमलाइन दोबारा स्कैन करने के बजाय इवेंट आने के साथ आगे बढ़ती है। विंडो से पुरानी प्रगति हटा दी जाती है, उसे गिना नहीं जाता।

### सह-संबंध

क्रॉस-विषय जॉइन: इस इवेंट के समूह में आने वाले हर इवेंट पर रिड्यूस।

```json theme={null}
{
  "metric": "correlation",
  "window": "7d",
  "pair": true,
  "group_by": ["subject_vendor_data", "event.gameplay.counterparty_vendor_data"],
  "filters": { "event.action_type": "p2p_settlement" },
  "correlate": {
    "metric": "sum",
    "field": "event.gameplay.net_result_amount",
    "filters": { "event.gameplay.role": "winner" }
  },
  "operator": "gte",
  "value": 500
}
```

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

सह-संबंध नियम को हमेशा सीमित करने वाले `filters` दें। उनके बिना वह विंडो के हर इवेंट पर विचार करता है।

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

कुछ नियम इनजेस्शन अनुरोध के भीतर ही जवाब दे सकते हैं, जबकि कुछ नहीं।

| चलते हैं | कौन से नियम |
| - | - |
| **अनुरोध के भीतर** | वेलोसिटी, अनुपात और सीमित अनुक्रम (विंडो 24 घंटे तक) |
| **कुछ मिनटों में, एसिंक्रोनस रूप से** | सहसंबंध नियम, और 24 घंटे से लंबी विंडो वाले अनुक्रम |

जिस इवेंट के नियम अभी लंबित हैं, वह `"correlation_pending": true` के साथ वापस आता है। एसिंक्रोनस पास पूरा होने पर उसका स्टेटस और स्कोर उसी जगह अपडेट हो जाते हैं। री-रनिंग आइडेम्पोटेंट है, इसलिए कोई नियम अपना स्कोर दो बार लागू नहीं करता।

यह बँटवारा जानबूझकर किया गया है: विषयों के बीच की रिंग क्वेरी लॉगिन को इंतज़ार नहीं करवा सकती।

## कार्रवाइयाँ

ट्रांज़ैक्शन नियमों वाली ही कार्रवाई शब्दावली लागू होती है: `add_score`, `change_status`, `add_tags`, `add_note`, `add_to_list`, `open_case`।

इवेंट के लिए दो अंतर हैं:

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

## प्रमाण

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

| स्रोत | अर्थ |
| - | - |
| `server` | Didit ने इसे निकाला है (IP, यूज़र एजेंट, उद्गम)। प्रामाणिक। |
| `sdk` | Didit SDK ने इसे डिवाइस से रिपोर्ट किया। |
| `customer` | आपके सिस्टम ने इसे उपलब्ध कराया। |

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

## उदाहरण

> [accordion] न्यूनतम खेल से मनी लॉन्ड्रिंग
>
> जमा, टोकन खेल, तेज़ निकासी। शर्त `event.action_type eq withdrawal_requested`, साथ ही ऊपर वाला वेजर-से-जमा अनुपात `24h` की विंडो पर `lte 0.1` पर।

> [accordion] फ़्रेंडली फ़्रॉड
>
> `30d` की विंडो पर, प्रति विषय `count(chargeback_opened)` और `count(deposit_completed)` का अनुपात, `gte 0.5`। एक ही इंस्ट्रूमेंट को कई खातों में पकड़ने के लिए विषय के बजाय `event.payment.payment_fingerprint` से समूहित करें।

> [accordion] खाता अधिग्रहण से रकम निकासी
>
> ऊपर वाला `ato_drain` अनुक्रम, `add_score 90` और `change_status DECLINED` के साथ।

> [accordion] चिप डंपिंग
>
> ऊपर दिया गया जोड़ी-सहसंबंध। `value` को उस रकम पर सेट करें जो आपकी टेबल के लिए महत्वपूर्ण हो, और खेलों को अलग रखने के लिए `event.gameplay.game_id` को `group_by` में जोड़ें।

> [accordion] बॉट खेल और रीयल-टाइम सहायता
>
> `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` के साथ मिलाएँ।

> [accordion] स्व-बहिष्करण से बच निकलना
>
> `event.action_type eq self_exclusion_match` और `event.payload.re_registration_attempt eq true` पर शर्त, `open_case` के ज़रिए एस्केलेट करें।

## आगे

> [card] [इवेंट इनजेस्शन](https://docs.didit.me/hi/transaction-monitoring/events.md)
>
> एनवेलप, दस श्रेणियाँ और बैच अनुबंध।

> [card] [नियम API](https://docs.didit.me/hi/transaction-monitoring/rules-api.md)
>
> नियम प्रोग्रामेटिक रूप से बनाएँ, अपडेट करें और बैक-टेस्ट करें।


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.