Adgora में डुप्लिकेट कन्वर्ज़न की जाँच

पोस्टबैक के बाद Adgora कैंपेन में डुप्लिकेट कन्वर्ज़न: समस्या-निवारण के तरीकों की तुलना

किसी विज़िटर ने कार्रवाई सिर्फ़ एक बार पूरी की हो, फिर भी कन्वर्ज़न दो बार दिखाई दे सकता है। अतिरिक्त रिकॉर्ड बार-बार भेजे गए पोस्टबैक, एक ही इवेंट को एक से ज़्यादा बार स्वीकार करने वाले रिसीविंग एंडपॉइंट, या एक इवेंट को दो जगह गिनने वाली रिपोर्टिंग की वजह से बन सकता है। अगर आपका सवाल है कि पोस्टबैक के बाद कन्वर्ज़न दो बार क्यों दिखता है, तो कैंपेन की सेटिंग बदलने से पहले पूरे रास्ते का पता लगाएँ और पहचानें कि दूसरा रिकॉर्ड सबसे पहले कहाँ दिखाई देता है।

यह तुलना डुप्लिकेट रोकने के तीन तरीकों पर केंद्रित है: इवेंट-ID डीडुप्लिकेशन, ट्रांज़ैक्शन-ID जाँच और समय-अवधि के नियम। सही विकल्प इस बात पर निर्भर करता है कि आपका इंटीग्रेशन कौन-से आइडेंटिफ़ायर देता है और क्या ग्राहक वास्तव में एक से ज़्यादा बार कन्वर्ज़न कर सकते हैं। बहुत व्यापक रूप से डुप्लिकेट हटाने वाला नियम असली बिक्री या साइन-अप भी मिटा सकता है।

समाधानों की तुलना करने से पहले मानदंड तय करें

हर समाधान को तीन मानदंडों पर परखें: क्या वह दोहराए गए इवेंट को रोकता है, क्या वह वैध रूप से दोबारा होने वाले कन्वर्ज़न को बनाए रखता है, और क्या लाइव कैंपेन प्रभावित किए बिना उसका परीक्षण किया जा सकता है? पोस्टबैक फ़्लो में बदलाव करने से पहले इन मानदंडों को लिख लें। वरना, कन्वर्ज़न की कम संख्या सफल लग सकती है, भले ही नियम ने वैध गतिविधि को दबा दिया हो।

जिस कार्रवाई को आप माप रहे हैं, उसके लिए तय करें कि डुप्लिकेट किसे माना जाएगा। एक बार होने वाले चेकआउट में एक ही ऑर्डर का दो बार दर्ज होना संभवतः डुप्लिकेट है। सब्सक्रिप्शन रिन्यूअल में, एक ही ग्राहक की अलग-अलग समय पर की गई दो खरीदारी वैध हो सकती हैं। परिभाषा को सिर्फ़ कैंपेन के लिए नहीं, बल्कि उस खास इवेंट के लिए तय करें।

नतीजों की तुलना के लिए ज़रूरी रिकॉर्ड संभालकर रखें: सोर्स इवेंट, कोई भी इवेंट या ट्रांज़ैक्शन आइडेंटिफ़ायर, पोस्टबैक के प्रयास, एंडपॉइंट के जवाब और Adgora की कन्वर्ज़न रिपोर्ट। अगर कोई फ़ील्ड उपलब्ध नहीं है, तो यह मान लेने के बजाय कि दोनों रिकॉर्ड एक ही कार्रवाई से जुड़े हैं, उसकी अनुपलब्धता दर्ज करें। एक छोटा-सा टेस्ट लॉग, कन्वर्ज़न “कुछ ज़्यादा लग रहे हैं” जैसे अस्पष्ट दावे से ज़्यादा उपयोगी होता है।

पोस्टबैक के पूरे रास्ते में एक कन्वर्ज़न को ट्रेस करें

रिपोर्ट किए गए किसी एक कन्वर्ज़न को चुनें और मूल कार्रवाई से लेकर रिपोर्टिंग व्यू तक उसका पता लगाएँ। ऑर्डर कन्फ़र्मेशन, फ़ॉर्म सबमिशन या ऐप में की गई कार्रवाई जैसे सोर्स इवेंट से शुरुआत करें। उसका टाइमस्टैम्प और उस समय से जुड़ा कोई भी आइडेंटिफ़ायर नोट करें। फिर उससे संबंधित आउटगोइंग पोस्टबैक और रिसीविंग एंडपॉइंट में मौजूद रिकॉर्ड ढूँढ़ें।

हर चरण पर आइडेंटिफ़ायर और टाइमस्टैम्प की तुलना करें। अगर सोर्स में एक इवेंट है, लेकिन एंडपॉइंट में उससे मेल खाते दो रिकॉर्ड हैं, तो दूसरा रिकॉर्ड पोस्टबैक डिलीवरी और एंडपॉइंट स्टोरेज के बीच कहीं आया है। अगर एंडपॉइंट में एक रिकॉर्ड है, लेकिन Adgora दो कन्वर्ज़न दिखाता है, तो एंडपॉइंट डीडुप्लिकेशन बदलने के बजाय रिपोर्टिंग या इंपोर्ट पाथ की जाँच करें।

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

पूरा क्रम दर्ज करें: सोर्स इवेंट, पोस्टबैक बनना, डिलीवरी का प्रयास, एंडपॉइंट का जवाब, सेव किया गया रिकॉर्ड और Adgora की रिपोर्ट। इससे टीम को जाँचने के लिए एक ठोस क्रम मिलता है। साथ ही, यह एक आम भटकाव से भी बचाता है: एंडपॉइंट में पहले से दो रिकॉर्ड बन चुके हों, फिर भी कैंपेन को दोष देना।

डीडुप्लिकेशन के तरीकों की साथ-साथ तुलना करें

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

खरीदारी के लिए ट्रांज़ैक्शन-ID जाँच अच्छी तरह काम कर सकती है, बशर्ते हर ऑर्डर का एक स्थिर रेफ़रेंस हो। लीड फ़ॉर्म, ट्रायल शुरू होने या ऐसे किसी दूसरे इवेंट के लिए यह कम उपयुक्त है, जिसमें स्वाभाविक रूप से ट्रांज़ैक्शन ID नहीं बनती। इसका दायरा भी जाँचें: ट्रांज़ैक्शन रेफ़रेंस शायद सिर्फ़ एक अकाउंट या स्टोर के भीतर अद्वितीय हो, इसलिए डीडुप्लिकेशन की कुंजी में वह संदर्भ भी शामिल करना पड़ सकता है।

जब इंटीग्रेशन में कोई स्थिर इवेंट या ट्रांज़ैक्शन आइडेंटिफ़ायर उपलब्ध न हो, तो समय-अवधि के नियम एक वैकल्पिक उपाय हैं। इनके तहत तय समय के भीतर आए मिलते-जुलते कन्वर्ज़न को एक माना जा सकता है, लेकिन “कम समय में हुए” का मतलब “एक ही इवेंट” नहीं होता। ग्राहक चुनी गई अवधि के भीतर दो वैध कार्रवाइयाँ कर सकता है। देखे गए डुप्लिकेट पैटर्न को ठीक करने वाली सबसे छोटी अवधि चुनें, फिर नियम को व्यापक रूप से लागू करने से पहले वैध रूप से दोबारा होने वाले कन्वर्ज़न जाँचें।

जो टीमें कैंपेन मेज़रमेंट की व्यापक समीक्षा कर रही हैं, उनके लिए यही सावधानी ट्रैफ़िक सोर्स और कन्वर्ज़न की परिभाषाओं पर भी लागू होती है। Adgora की क्रिप्टो ऐड नेटवर्क टार्गेटिंग विकल्पों की गाइड टार्गेटिंग के विकल्पों को समझने में मदद कर सकती है, लेकिन टार्गेटिंग में बदलाव से उस डुप्लिकेट का समाधान नहीं होगा जो पोस्टबैक के एंडपॉइंट तक पहुँचने के बाद बनता है।

रीट्राई और जवाब देने के व्यवहार की जाँच करें

टाइमआउट होने का मतलब यह नहीं कि पोस्टबैक विफल हो गया। हो सकता है एंडपॉइंट ने इवेंट सेव कर लिया हो, लेकिन स्पष्ट पुष्टि न भेजी हो। ऐसे में भेजने वाला सिस्टम फिर से प्रयास कर सकता है। पुष्टि करें कि भेजने वाला सिस्टम टाइमआउट को कैसे संभालता है, किन रिस्पॉन्स कोड पर रीट्राई होता है और क्या एंडपॉइंट इवेंट सेव करने के बाद ही जवाब देता है।

डुप्लिकेट का कारण रीट्राई को मानने से पहले असली अनुरोध और जवाब के लॉग देखें। प्रयासों की संख्या, टाइमस्टैम्प, रिस्पॉन्स कोड और हर प्रयास में भेजे गए इवेंट आइडेंटिफ़ायर की जाँच करें। फिर अपने इस्तेमाल वाले एनवायरनमेंट में एंडपॉइंट के दस्तावेज़ में बताए गए व्यवहार की पुष्टि करें।

यहाँ एक व्यावहारिक फ़र्क है। अगर हर दोहराए गए अनुरोध में एक ही ID है, लेकिन एंडपॉइंट दोनों को सेव करता है, तो रिसीविंग साइड पर इडेम्पोटेंट हैंडलिंग की ज़रूरत हो सकती है। अगर एक ही सोर्स कार्रवाई के लिए दोहराए गए अनुरोधों में अलग-अलग ID हैं, तो पता लगाएँ कि ये ID कहाँ बनाई जा रही हैं। सिर्फ़ रीट्राई नीति इस अंतर को नहीं समझा सकती।

डुप्लिकेट और दोबारा होने वाले इवेंट—दोनों पर समाधान जाँचें

किसी नियम को लागू करने से पहले दो नियंत्रित परीक्षण करें। पहले, एक ही आइडेंटिफ़ायर वाला कन्वर्ज़न पोस्टबैक दो बार भेजें। नतीजे में एक ही कन्वर्ज़न सेव होना चाहिए। दूसरे, अलग-अलग आइडेंटिफ़ायर वाले दो वैध कन्वर्ज़न बनाएँ—जैसे दो अलग ऑर्डर—और पुष्टि करें कि दोनों दिखाई देते हैं।

दोनों परीक्षणों के लिए सोर्स लॉग, डिलीवरी लॉग, एंडपॉइंट रिकॉर्ड और Adgora रिपोर्ट की तुलना करें। समाधान तभी सफल है, जब वह दोहराए गए इवेंट को हटाए और दूसरे वैध इवेंट को बनाए रखे। अगर आप समय-अवधि का नियम इस्तेमाल कर रहे हैं, तो प्रस्तावित अवधि के भीतर दोबारा होने वाले इवेंट का परीक्षण करें; अवधि से बाहर किया गया परीक्षण यह नहीं दिखाएगा कि नियम बहुत व्यापक है या नहीं।

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

अगर कैंपेन ऐप में की गई कार्रवाइयाँ भी ट्रैक करते हैं, तो सुनिश्चित करें कि परीक्षण में इवेंट भेजने का वास्तविक तरीका शामिल हो। ऐप इंस्टॉल कैंपेन के लिए क्रिप्टो विज्ञापन का अलग अवलोकन कैंपेन का संदर्भ समझने में मदद कर सकता है, लेकिन डुप्लिकेट की जाँच में इंस्टॉल या इन-ऐप इवेंट को उसके अपने पोस्टबैक पाथ से ही ट्रेस करना होगा।

वापस पुराने बदलाव पर लौटने की योजना के साथ लागू करें

सीमित स्तर से शुरुआत करें: एक इवेंट प्रकार, एक एंडपॉइंट या एक टेस्ट कैंपेन। नियम बदलने से पहले मौजूदा कॉन्फ़िगरेशन सेव करें और सोर्स इवेंट, डिलीवर हुए पोस्टबैक, एंडपॉइंट रिकॉर्ड और रिपोर्ट किए गए कन्वर्ज़न की शुरुआती संख्या नोट करें। इस आधार के बिना, बाद में आई गिरावट का मतलब समझना मुश्किल होगा।

समस्या के दोनों पहलुओं पर नज़र रखें। डुप्लिकेट की संख्या कम होना तभी अच्छा है, जब वैध कन्वर्ज़न भी सुरक्षित रहें। रिकॉर्ड गायब होने, दोबारा हुई खरीदारी में अचानक गिरावट, डिलीवरी की बढ़ती त्रुटियों या एंडपॉइंट स्टोरेज और Adgora रिपोर्टिंग के बीच अंतर पर नज़र रखें। इनमें से कोई संकेत दिखे, तो बदलाव रोकें और प्रभावित इवेंट ID या ट्रांज़ैक्शन रेफ़रेंस की तुलना करें।

लॉन्च से पहले बदलाव वापस लेने की स्पष्ट शर्त तय करें। उदाहरण के लिए, अगर किसी ज्ञात टेस्ट कन्वर्ज़न को दबा दिया जाए या वैध रूप से दोबारा हुए इवेंट एंडपॉइंट लॉग से गायब हो जाएँ, तो बदलाव वापस लें। नई व्यवस्था को असली कैंपेन रिकॉर्ड पर जाँच लेने तक पुराना नियम उपलब्ध रखें।

क्या बदला, कब बदला और किन इवेंट प्रकारों पर इसका असर होगा—यह सब दर्ज करें। इससे पोस्टबैक से जुड़े सुधार को कैंपेन में किए गए दूसरे बदलावों से अलग पहचानना आसान होता है। कन्वर्ज़न की संख्या अचानक बदलने पर, यह रिकॉर्ड अगले व्यक्ति को पहले जैसा व्यवहार बहाल करने का सीधा तरीका भी देता है।

निष्कर्ष: जहाँ संभव हो, इवेंट-स्तर की पहचान को प्राथमिकता दें

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

अगर उपयुक्त इवेंट ID उपलब्ध न हो, तो ऐसी खरीदारी के लिए ट्रांज़ैक्शन ID इस्तेमाल करें जिसका रेफ़रेंस भरोसेमंद हो। दूसरे इवेंट के लिए समय-अवधि का नियम उपलब्ध सबसे सीमित विकल्प हो सकता है, लेकिन उसे लागू करने से पहले वैध रूप से दोबारा होने वाले कन्वर्ज़न पर जाँच लें। अगर आप यह तय कर रहे हैं कि Adgora में डुप्लिकेट कन्वर्ज़न कैसे रोकें, तो सबसे अच्छा समाधान वह है जो दोहराए गए रिकॉर्ड को हटाए और दूसरी वास्तविक कार्रवाई को बनाए रखे—न कि वह जो बस कुल संख्या घटा दे।