इडेम्पोटेंट Postback: फ़ाइनेंस टीमों को दोहरी गिनती से फ़र्क़ क्यों पड़ता है
रीट्राई के लिए सुरक्षित Postback वही फ़र्क़ है जो फ़ाइनेंस साइन करे ऐसे आँकड़े और फ़ाइनेंस बहस करे ऐसे आँकड़े के बीच। इडेम्पोटेंट का मतलब, ऑपरेटर एक इवेंट एक से ज़्यादा बार क्यों भेजते हैं, और तब एफ़िलिएट को वॉलेट में क्या दिखना चाहिए।
फ़ाइनेंस टीमें Postback से नफ़रत नहीं करतीं। ऐसे कुल जोड़ से नफ़रत करती हैं जिन्हें दोबारा चलाकर न मिलाया जा सके। अगर एक ही पहला डिपॉज़िट दो बार दिख सकता है क्योंकि अनुरोध टाइम आउट हुआ और फिर भेजा गया, महीना बंद नहीं हो सकता। कोई शुक्रवार दोपहर दो CSV और एक हाइलाइटर के साथ बिताएगा। इडेम्पोटेंट Postback वही तरीक़ा है जिससे वह शुक्रवार रद्द होता है।
यह क्षमता वाला पोस्ट है। AFFILIFY कन्वर्ज़न एक बार गिनता है, ऑपरेटर एक से ज़्यादा बार भेजे तो भी। डुप्लिकेट पहचानने का तरीक़ा सार्वजनिक चेकलिस्ट नहीं है। जानना यह है कि समस्या की शक्ल क्या है, तार पर क्या डालें, और रीट्राई आने पर एफ़िलिएट वॉलेट को क्या करना चाहिए।
चौड़ा ट्रैकिंग चित्र चाहिए तो Postback बनाम पिक्सल बनाम इमेज टैग तुलना है। यह S2S का फ़ाइनेंस वाला टुकड़ा है।
इडेम्पोटेंट का यहाँ मतलब
इडेम्पोटेंट का मतलब है एक ही इवेंट दो बार लागू करें तो सहेजा नतीजा न बदले। FTD #84102 भेजिए। कतार ने 200 न देखा इसलिए फिर भेजिए। अब भी एक FTD है। अब भी एक कमीशन है। दूसरा अनुरोध एरर नहीं है और दूसरा खिलाड़ी नहीं है।
उलटा वह काउंटर है जो हर HTTP अनुरोध पर बढ़ता है। वह काउंटर आपकी रीट्राई लॉग से सहमत होगा। ऑपरेटर के खिलाड़ी डेटाबेस से नहीं, या उस एफ़िलिएट से नहीं जिसने एक ही इंसान भेजा।
रीट्राई बग नहीं हैं। नेटवर्क फ़ेल होते हैं। लोड बैलेंसर टाइम आउट करते हैं। 200 खो जाता है। गंभीर इंटीग्रेशन "पक्की पावती तक भेजते रहो" को हैप्पी पाथ मानता है, जो तभी सुरक्षित है जब रिसीवर डुप्लिकेट निगल सके। पूरा प्रोडक्ट रिक्वायरमेंट इतना ही है।
ऑपरेटरों को क्या भेजना चाहिए
click id पहले से है। इवेंट टाइप पहले से है: रजिस्ट्रेशन, FTD, डिपॉज़िट, और जो और डील माँगे। उस इवेंट के लिए स्थिर पहचानकर्ता भेजिए ताकि रीट्राई नई चीज़ न रहकर वही ऑब्जेक्ट रहे। सटीक फ़ील्ड नाम Postback डॉक्स में हैं, यहाँ नहीं।
तीन नियम महीना-अंत बचाते हैं।
वही पेलोड फिर भेजिए। नॉन्स मत बढ़ाइए, नया इवेंट id मत गढ़िए, टाइम आउट "ठीक" करने के लिए FTD-2 मत भेजिए। दूसरी भेज पहली भेज फिर से होनी चाहिए।
HTTP सफलता को इकलौती लेजर मत बनाइए। आपकी तरफ़ अनुरोध से पहले दर्ज होना चाहिए "हमने FTD #84102 भेजने का इरादा किया", और बाद में "उन्होंने FTD #84102 स्वीकार किया"। सिर्फ़ अनुरोध दर्ज हो तो टाइम आउट छेद लगता है और आप उसे भरने के लिए दूसरा इवेंट भेज देंगे।
NGR अवधि है, पिंग नहीं। डिपॉज़िट इवेंट प्रति डिपॉज़िट इडेम्पोटेंट हो सकता है। मासिक NGR आँकड़ा तारीखों की रेंज का बयान है। उसे उस रेंज के बयान के रूप में भेजिए, छोटे इंक्रीमेंट की धारा के रूप में नहीं जिनके जुड़ने की उम्मीद हो। NGR और नेगेटिव कैरीओवर उसी का एफ़िलिएट वाला वर्ज़न है कि वे कटौती स्थिर क्यों होनी चाहिए।
पिक्सल यह अच्छा नहीं कर सकते। ब्राउज़र में दो बार फ़ायर पिक्सल दो फ़ायर हैं। इमेज टैग वही। S2S 2026 में डिफ़ॉल्ट इसलिए है कि तीन में से वही है जिसे फ़ाइनेंस टीम दोबारा चलाकर सह सकती है। यही क्षमता दावा Postback बनाम पिक्सल में है।
एफ़िलिएट को क्या दिखना चाहिए
एक खिलाड़ी, एक FTD, एक CPA पंक्ति। कन्वर्ज़न खोलें तो ब्रांड, क्लिक, GEO, sub-id, टाइमस्टैम्प दिखना चाहिए। जुड़वाँ नहीं दिखना चाहिए।
डिपॉज़िट बाद में उलटा हो तो वह दूसरा इवेंट है, डुप्लिकेट नहीं। चार्जबैक, बोनस दुरुपयोग, रद्द पेमेंट: वे समायोजन के रूप में आते हैं, पैसा रोक सकते हैं, और लंबित कमीशन वापस खींच सकते हैं। वे रीट्राई नहीं हैं। पेआउट कैसे काम करते हैं लंबित, उपलब्ध, रोकी गई और समीक्षा में कवर करता है। पेआउट ख़ुद बाहर जाते समय एक बार गिने जाते हैं, उसी वजह से जिस वजह से Postback अंदर आते समय एक बार गिने जाते हैं।
कुछ दोगुना लगे तो वॉलेट से शुरू मत कीजिए। लिंक से शुरू कीजिए। टूटा click id गायब कन्वर्ज़न पैदा करता है, अतिरिक्त नहीं। पहले ट्रैकिंग लिंक QA कीजिए। फिर देखिए क्या दो लैंडिंग, दो sub-id या दो ब्रांड ने दो असली क्लिक बनाए। एक इंसान से दो असली क्लिक दो इवेंट हो सकते हैं। वह दोहरी गिनती नहीं। दो क्लिक हैं।
यह ऑपरेटरों के लिए सेलिंग पॉइंट क्यों है
जो एफ़िलिएट प्रोग्राम दो बार गिने वह ज़्यादा चुकाएगा, फिर क्लॉबैक करेगा, फिर रिश्ता ख़र्च करेगा। जो रीट्राई गिरा दे वह कम गिनेगा, फिर बहस करेगा, फिर रिश्ता दूसरी तरफ़ ख़र्च करेगा। इडेम्पोटेंट S2S उबाऊ तीसरा विकल्प है: भेजिए, ज़रूरत हो तो फिर भेजिए, कुल जोड़ नहीं हिलता।
इसीलिए AFFILIFY कन्वर्ज़न बकेट की जगह पंक्ति के रूप में दिखा सकता है। पंक्ति इवेंट है। रीट्राई कुल जोड़ वहीं छोड़ता है।
एफ़िलिएट तरफ़ वही नियम है जिसकी वजह से 15 तारीख बंद हो सकती है। लंबित उपलब्ध होता है ऐसे कुल जोड़ पर जो इसलिए नहीं बदलता कि कतार 14:58 पर आ पहुँची। KYC अब भी निकासी का गेट है। लेवल अब भी क्वालिफ़ाइंग डिपॉज़िट एक बार गिनता है। इनमें से कुछ नहीं चलता अगर FTD ख़ुद रीट्राई लॉग के ख़िलाफ़ सिक्का उछाल हो।
ऑपरेटर के रूप में यह तार कर रहे हों तो डॉक्स से शुरू कीजिए, अपना click पैरामीटर इस्तेमाल कीजिए, और "पक्की पावती तक भेजते रहो" को सामान्य मानिए। एफ़िलिएट हों तो इसके बारे में सोचना कभी नहीं चाहिए, यही बात है। जब सोचना पड़े, ऊपर कुछ दो अलग इवेंट भेज रहा है और उन्हें एक कह रहा है। वह इंटीग्रेशन बग है, रीट्राई नहीं।
अक्सर पूछे जाने वाले सवाल
Postback के लिए इडेम्पोटेंट का मतलब क्या है?
एक ही इवेंट एक से ज़्यादा बार भेजा जा सकता है और गिना एक बार जाता है। टाइम आउट और रीट्राई अपेक्षित हैं। दूसरा HTTP अनुरोध दूसरा FTD नहीं है और दूसरा कमीशन नहीं है। पेलोड बदला और नया इवेंट id गढ़ा गया, तो वह नया इवेंट है, रीट्राई नहीं।
ऑपरेटर रीट्राई करे तो क्या मुझे AFFILIFY वॉलेट में डुप्लिकेट FTD दिखेंगे?
नहीं। एक ही इवेंट का रीट्राई दूसरी पंक्ति नहीं जोड़ता और दूसरा CPA नहीं जोड़ता। दो पंक्तियाँ दिखें तो दो इवेंट थे: दो क्लिक, दो डिपॉज़िट, या दो अलग इवेंट टाइप। वह ब्रांड के साथ खोलने लायक़ है, यह मानकर नहीं कि प्लेटफ़ॉर्म ने दो बार गिना।
क्या यह पेआउट के इडेम्पोटेंट होने जैसा ही है?
वही विचार, दूसरी दिशा। आने वाले कन्वर्ज़न रीट्राई पर भी एक बार गिने जाते हैं। जाने वाले पेआउट पेआउट प्रोवाइडर से दो बार पूछे जाने पर भी एक बार क्रेडिट होते हैं। दोनों इसलिए हैं कि फ़ाइनेंस हाइलाइटर के बिना महीना बंद कर सके। [पेआउट कैसे काम करते हैं](/blog/how-affilify-payouts-work) जाने वाला पक्ष है।
क्या पिक्सल को भी यह चाहिए?
पिक्सल और इमेज टैग ब्राउज़र में फ़ायर होते हैं और पेज जितनी बार लोड हो उतनी बार फ़ायर होंगे। उन्हें सर्वर Postback की तरह रीट्राई-सुरक्षित नहीं बनाया जा सकता। यही एक वजह है कि S2S डिफ़ॉल्ट है और पिक्सल उन लोगों का फ़ॉलबैक है जो अभी सर्वर इवेंट नहीं भेज सकते। S2S चुनिए।
