क्रिप्टो कैसीनो
धार गियर
कैसे - ट्रैकिंग और पोस्टबैक काम करते हैं
1) क्या है - और इसकी आवश्यकता क्यों है
S2S (सर्वर-टू-सर्वर) ट्रैकिंग ब्राउज़र कुकीज़और लॉक पर निर्भरता के बिना ट्रैफ़िक स्रोत (आपके रिडायरेक्टर/ट्रैकर/नेटवर्क) और ऑपरेटर (कैसीनो) के सर्वर के बीच घटनाओं का आदान-प्रदान है।
पोस्टबैक - प्रेषक के बैकएंड से प्राप्तकर्ता के URL तक एक घटना (reg/KYC/FTD/2nd_dep/...) के साथ एक निवर्तमान HTTP अनुरोध।
लाभ:- Adblock/ITP/निजी मोड के कारण डेटा नहीं खोया है।
- बिलिंग की गुणवत्ता और गुणवत्ता की उच्च सटीकता।
- आप सुरक्षित रूप से राशि/मुद्रा और सेवा झंडे हस्तांतरित कर सकते हैं।
2) बुनियादी श्रृंखला और भूमिकाएँ
1. क्लिक करें: उपयोक्ता विज्ञापन पर क्लिक करें - आपका पुनर्निर्देशक 'क्लिक _ आईडी' बनाता है और पैरामीटर (utm, geo, युक्ति, ) लॉग करता है।
2. Redirect: उपयोगकर्ता ऑपरेटर के लैंडिंग पर जाता है, 'क्लिक _ id' को URL या एन्क्रिप्टेड पर धकेल दिया जाता है।
3. पंजीकरण/सीसीएम/जमा ऑपरेटर पर होते हैं।
4. पोस्टबैक: ऑपरेटर का सर्वर 'पंजीकरण', 'kyc _ अनुमोदित', 'डिपॉजिट _ सक्सेस', आदि घटनाओं को आपके ट्रैकर को भेजता है, उन्हें मूल 'क्लिक _ id' में बांधता है।
5. BI/रिपोर्टिंग: आप UTM/क्रिएटिव/जियो/डिवाइस सेक्शन में घटनाओं को एकत्र करते हैं, CPA/ROAS/LTV पर विचार करते हैं।
पाठ योजना:
विज्ञापन → क्लिक करें → [आपका पुनर्निर्देशक उत्पन्न करता है click_id] → एलपी/ऐप →
↑ │
└──────── पोस्टबैक (S2S) ─┘3) इवेंट आइडेंटिफायर और लिंकेज
click_id (अनिवार्य) - पहले स्पर्श की अद्वितीय आईडी; एट्रिब्यूशन कुंजी।
event_id (पीला) - प्रत्येक घटना की अद्वितीय आईडी (पहचान के लिए)।
user_id/ account_id (थोक) - ऑपरेटर की तरफ खिलाड़ी आईडी (केवल S2S के लिए प्रेषित)।
session_id (थोक) - UX/गति पार्सिंग के लिए।- एनालिटिक्स के लिए अनुभाग।
नियम: click_id आपके द्वारा बनाया गया है; इसके पक्ष में ऑपरेटर मैपिंग 'क्लिक _ id ↔ उपयोगकर्ता/खाता' संग्रहीत करता है।
4) घटना क्षेत्र: न्यूनतम रचना
4. 1. पंजीकरण
json
{
"घटना": "पंजीकरण", " :" ":" ":" ":" ":" जियो ":" बीआर "," डिवाइस ":" एंड्रॉइड ":": ":" "" आईपी ":" 203। 0. 113. 7", "ua": "Mozilla/5। 0" ", हस्ताक्षर": "hmac_sha256 (पेलोड)"
}4. 2. KYC अनुमोदित
json
{
"घटना": "kyc_approved," "event_id":" kyc_b21... "," click_id" ":" clk_123..., "account_id":" "," u_456... ":" ts_event" "" 2025-10-21T15:10:05Z, "kyc_level":" "मूल" पूर्ण" ", हस्ताक्षर": ""..
}4. 3. जमा (एफटीडी/दोहराएँ)
json
{
"घटना": " ": " ": " ": " ": " ": "" "" राशि ": 100। 00, "मुद्रा": "USD", "is_ftd": सत्य ", payment_method": "कार्ड पिक्स क्रिप्टो बटुआ "", " :" "" हस्ताक्षर ":" "..
}आवश्यक क्षेत्र हैं 'घटना', 'ईवेंट _ आईडी', 'क्लिक _ आईडी', 'टीएस _ इवेंट' (यूटीसी), 'हस्ताक्षर'.
मुद्रा क्षेत्र हमेशा 'क्यूरेंसी' (ISO-4217) और संख्या के रूप में एक साथ होते हैं, तार नहीं।
5) सुरक्षा: हस्ताक्षर और पहुंच
Подпись (HMAC-SHA256): 'हस्ताक्षर = HMAC (गुप्त, canonical_payload)'; कैनोनाइज़फ़ील्ड ऑर्डर - स्थिर सत्यापन।
प्राधिकरण स्तर पर अल्पकालिक टोकन (JWT/अपारदर्शी): TTL 5-15 मिनट।
पहचान: एक ही 'ईवेंट _ आईडी' के साथ पोस्ट को दोहराएं बिना डबल के '200 ओके' की उपज होनी चाहिए।
आईपी अनुमति-सूची और एमटीएलएस (यदि संभव हो) प्रोड पर।- दर सीमित: "फटने" और बॉट्स से समापन बिंदु की रक्षा करें।
- पोस्टबेक एंडपॉइंट से HTTP रीडायरेक्ट का निषेध; केवल प्रत्यक्ष जवाब।
6) विश्वसनीयता: रिट्रेज़, कतारें और आदेश
इवेंट रिसेप्शन और रिपोर्ट प्रोसेसिंग के बीच कतार (काफ्का/रैबिटएमक्यू/एसक्यूएस) - ताकि चोटियों पर डेटा न खोया जा सके।
घातीय ठहराव और बैकऑफ़जिटर के साथ रेट्राई; प्रयासों की सीमा और DLQ (मृत-अक्षर कतार)।
आदेश वैकल्पिक है, लेकिन BI में छंटाई के लिए 'ts _ event' होना वांछनीय है।
अनुरोध/अनुक्रिया लॉग (संवेदनशील डाटा के बिना), 'घटना _ आईडी' द्वारा सहसंबंध।
7) समय क्षेत्र, मुद्रा और स्थिरता
यूटीसी में सभी समय टिकट ('2025-10-21T15: 12: 31Z')।
रिपोर्ट में, परियोजना समय क्षेत्र निर्दिष्ट करें, लेकिन यूटीसी में घटनाओं को संग्रहीत क
लेनदेन मुद्रा में मात्रा को संग्रहीत करें और उन्हें विश्वसनीय दर (तारीख-समय-आधारित एफएक्स) के माध्यम से रिपोर्ट मुद्रा में डुप्लिकेट करें।
8) डीडुप्लिकेशन और व्यावसायिक नियम
पहचान: दोहराएं - "पहले से ही संसाधित।"
फॉलबैक तंत्र के रूप में (click_id + ईवेंट प्रकार + ts-window) द्वारा डीडुप्लीकेशन।
एफटीडी वैधता नियम: न्यूनतम जमा, कोई बोनस "शून्य" पुनर्पूर्ति; अनुबंध में ठीक करें।
चार्जबैक/रिफंड एक ईमानदार एनजीआर के लिए अलग "नकारात्मक आय" घटनाएं हैं।
9) गोपनीयता और अनुपालन
पीआईआई को यूआरएल और सामने पास न करें; S2S संवेदनशील क्षेत्रों के लिए एक जगह है।
स्टोर सहमति (एनालिटिक्स/विज्ञापन) और उन्हें संस्करण।- फ़ील्ड्स को कम से कम करें: केवल एट्रिब्यूशन और बिलिंग के लिए क्या आवश्यक है
- नियमित रूप से प्रतिधारण लॉग नीतियों की समीक्षा
10) Web2App और मोबाइल वास्तविकताएं
अनुप्रयोगों के लिए, MMP/SDK साइड पर 'क्लिक _ id' ↔ 'इंस्टॉल _ id' बांटें।
जब कोई नियतात्मक आईडी (आईओएस गोपनीयता) नहीं होती है - एक संभाव्य मैच + सर्वर नियमों का उपयोग करें, और - बिलिंग के लिए "सच्चाई" बनी हुई है।
11) निगरानी और एसएलए
मेट्रिक्स:- सफल/गलत पोस्टबैक (%/मिनट), p95 विलंबता, रिट्रेज़का अनुपात, डुप्लिकेट का अनुपात।
- दिन-प्रतिदिन पार्टियों (ऑपरेटर बनाम ट्रैकर) के बीच घटना विसंगति।
- वितरण में देरी (अंतर्ग्रहण अंतराल) और घंटे तक "विफलताएं"।
- पोस्टबैक रिसेप्शन उपलब्धता ≥ 99। 5 %/महीना
- DWH ≤ 60 सेकंड में लिखने से पहले औसत देरी; p95 एपीआई प्रतिक्रिया ≤ 500 मीटर।
- 5 कार्य दिवसों के भीतर कच्चे लॉग का डेसिंक्रोनाइजेशन> 3% → अनिवार्य सामंजस्य।
12) चेकलिस्ट
12. 1. लॉन्च से पहले टेक चेक करें
- पीढ़ी और लॉग के साथ पुनर्निर्देशक।
- पोस्टबैक एंडपॉइंट: टीएलएस, एचएमएसी, जेडब्ल्यूटी, आईपी अनुमति-सूची, पहचान।
- पेलोड योजनाएं और विहित क्षेत्र आदेश प्रलेखित हैं।
- कतार + डीएलक्यू, रिट्रेज़, त्रुटि/विलंब अलर्ट।
- यूटीसी समय, आईएसओ मुद्रा, एफटीडी/रिफंड/चार्जबैक नियम।
- संदर्भ लॉग को ठीक करने के साथ सैंडबॉक्स में चलता है।
12. 2. ऑपरेटिंग चेक (हर हफ्ते)
- घटनाओं और मात्रा की मात्रा द्वारा "ऑपरेटर ↔ ट्रैकर" का सामंजस्य।
- डुप्लिकेट और "खोई हुई" घटनाओं का विश्लेषण; रिट्रेज़का ऑडिट।
- कुंजी/टोकन, जीवनकाल और घूर्णन की जाँच करता है।
- घटनाओं को देखें और नियमों को समायोजित करें।
13) बार-बार गलतियाँ और उनसे कैसे बचें
1. Retrays में कोई पहचान - FTD डुप्लिकेट नहीं। 'घटना _ id' दर्ज करें और "देखा" स्टोर करें।
2. अलग-अलग समय क्षेत्र "फ्लोटेड" । घटना लॉग में हमेशा यूटीसी।
3. स्ट्रिंग रकम/अल्पविराम पार्सिंग त्रुटियां। अवधि और आईएसओ मुद्रा के साथ संख्या पास करें।
4. "कच्चे" JSON पर हस्ताक्षर → चाबियों के क्रम से टूटता है। → कैनोनाइजेशन करें।
5. कोई DLQ/Retrays → Microsobes पर घटनाओं का नुकसान। → कतार + बैकऑफ + अलर्ट।
6. कमजोर प्रमाणीकरण → नकली पोस्टबैक। → HMAC + JWT + mTLS/IP सूची।
7. एफटीडी नियमों की कमी - बिलिंग विवाद। अनुबंध में परिभाषाओं को ठीक करें।
14) नमूना अनुरोध और प्रतिक्रियाएँ
14. 1. POST/पोस्टबैक (ऑपरेटर → ट्रैकर)
POST/पोस्टबैक HTTP/1। 1
सामग्री प्रकार: अनुप्रयोग/json
प्राधिकरण: वाहक eyJhbGciOi...
एक्स-हस्ताक्षर: sha256 = ab12...
{"घटना ": "जमा _ सफलता"," ईवेंट _ आईडी":" डीपी _ 9a", "click_id":"clk_123,""account_id":"u_456," "राशि": 100। 00, "मुद्रा ": "USD"," is _ ftd": true, "ts_event":"2025-10-21T15:12:31Z"}
200 ओके
{"स्थिति":" ठीक है", "पहचान": गलत}
200 ओके
{"स्थिति":" ठीक है", "पहचान": सही}14. 2. हस्ताक्षर त्रुटि
403 निषिद्ध
{"त्रुटि ": "हस्ताक्षर _ अमान्य", "संकेत ":" विहित क्रम"} की जाँच करें15) घटनाएं और पार्सिंग
लक्षण: ऑपरेटर के पास FTD = 120 है, आपके पास 117 है।
योजना:1. समय सीमा (यूटीसी) और मुद्राओं का सामंजस्य।
2. 'घटना _ id '/' क्लिक _ id' द्वारा कच्चा लॉग उतारा जा रहा है.
3. हस्ताक्षर/टीटीएल के कारण अस्वीकृत टोकन/पहचान के लिए खोजें।
4. DLQ से "अटक" घटनाओं की अतिरिक्त डिलीवरी, सुलह कार्य।
16) 30-60-90 कार्यान्वयन योजना
0-30 दिन - सर्किट एमवीपी
'क्लिक _ आईडी' और लॉग के साथ रीडायरेक्टर लॉन्च करें।- पोस्टबैक के रिसेप्शन को लागू करें: HMAC, JWT, पहचान, कतारें, DLQ, अलर्ट।
- सैंडबॉक्स उठाएँ, परीक्षण मात्रा के साथ एंड-टू-एंड रेग/एफटीडी स्क्रिप्ट चलाएँ।
- दस्तावेज़ क्षेत्र योजनाबद्ध और विहित।
31-60 दिन - गुणवत्ता और पैमाने
मौद्रिक घटनाओं और दोहरी मुद्रा लेखांकन (txn & रिपोर्ट) को शामिल करें।
p95 विलंबता, विसंगतियों और रिट्रे की निगरानी स्थापित करें।
एसएलए/घटना प्रक्रियाओं पर हस्ताक्षर करें; चार्जबैक/रिफंड इवेंट जोड़ें।
BI में, शोकेस इकट्ठा करें: FTD, Payback, D7/D30 ARPU cohorts।
61-90 दिन - स्थिरता और लेखा परीक्षा
गुप्त/प्रमाणपत्र, गलती सहिष्णुता जांच का घुमाव भरें।- लोड परीक्षण और "आपातकालीन अभ्यास" (कतार ड्रॉप/डीबी) करें।
- सुलह प्लेबुक और एफटीडी योजनाओं/नियमों के त्रैमासिक ऑडिट को औपचारिक रूप दें।
17) नीचे की रेखा
S2S ट्रैकिंग ईमानदार एट्रिब्यूशन और बिलिंग की "रीढ़" है: click_id प्राथमिक कुंजी के रूप में, संरक्षित पोस्टबैक, आइडेम्पोटेंसी, रिट्रेज़और सख्त समय/मुद्रा स्वच्छता। इस पारदर्शी एफटीडी वैधता नियमों, चार्जबैक घटनाओं और परिपक्व निगरानी में जोड़ें - और आपको एक विश्वसनीय प्रणाली मिलती है जहां प्रत्येक रूपांतरण सर्वर द्वारा पुष्टि की जाती है और रिपोर्ट में एक प्रतिशत तक परिवर्तित होती है।