कोड का इंतज़ार करने वाला ग्राहक कतार, डिलीवरी, पढ़ना और दर्ज करना सब एक ही देरी के रूप में अनुभव करता है। यह तय करने से पहले कि धीमा साइनअप मैसेज डिलीवरी के कारण है या पूरे सत्यापन प्रवाह के कारण, इन अंतरालों को अलग करें।
कौन से टाइमस्टैम्प एकत्र करने चाहिए?
Webhook सब्सक्रिप्शन के ज़रिए Verify लाइफ़साइकल इवेंट्स एकत्र करें। उनके पेलोड टाइमस्टैम्प स्टोर करें।
इवेंट पेलोड इन चरणों की पहचान करते हैं:
| इवेंट | टाइमस्टैम्प | यह क्या रिकॉर्ड करता है |
|---|---|---|
verify.verification.created | created_at | सत्यापन बनाया गया |
verify.attempt.sent | sent_at | Bird ने एक चैनल को सत्यापन कोड सौंपा |
verify.attempt.delivered | delivered_at | चैनल ने डिलीवरी की रिपोर्ट दी |
verify.attempt.undelivered | failed_at | सत्यापन कोड पहुँचाने का वह प्रयास विफल हुआ |
verify.verification.verified | verified_at | प्राप्तकर्ता ने सही कोड सबमिट किया |
verify.verification.failed | failed_at | डिलीवरी प्लान कोड डिलीवर नहीं कर सका |
प्रत्येक टाइमस्टैम्प के साथ इवेंट टाइप रखें। दो failed_at फ़ील्ड अलग-अलग दायरे बताते हैं: एक प्रयास और सत्यापन का डिलीवरी प्लान।
webhook-id का उपयोग करके डिलीवरी डिडुप्लिकेट करें, जो एक इवेंट की पहचान करता है और फिर से प्रयास करने पर भी स्थिर रहता है। इवेंट्स को क्रम में रखने के लिए पेलोड के timestamp का उपयोग करें, क्योंकि डिलीवरी क्रम बदल सकता है।
कौन सा अंतराल मेरे सवाल का जवाब देता है?
रिपोर्ट की गई डिलीवरी टाइमिंग के लिए sent-to-delivered का उपयोग करें। पूर्ण सत्यापन टाइमिंग के लिए created-to-verified का उपयोग करें।
| अंतराल | इसमें क्या शामिल है |
|---|---|
created_at से sent_at | चैनल द्वारा सत्यापन कोड स्वीकार करने से पहले का समय, जिसमें पहले की चैनल विफलताएँ शामिल हो सकती हैं |
sent_at से delivered_at | चैनल स्वीकृति के बाद की प्रोसेसिंग और रिपोर्ट किया गया डिलीवरी अंतराल |
created_at से verified_at | पूरा इंतज़ार, जिसमें कोड पढ़ना और दर्ज करना शामिल है |
Sent टाइमस्टैम्प हमेशा कैरियर सबमिशन को नहीं दर्शाता। SMS के लिए, Bird का चैनल प्रयास को स्वीकार करता है इससे पहले कि डाउनस्ट्रीम SMS पाइपलाइन इसे कैरियर को सबमिट करे।
डिलीवरी रिपोर्ट सांकेतिक होती हैं। कैरियर और मेलबॉक्स प्रदाता इस बात में भिन्न होते हैं कि वे क्या पुष्टि करते हैं और कितनी जल्दी रिपोर्ट करते हैं।
समय के साथ एक ही चैनल और बाज़ार की तुलना करें। देशों के बीच अंतर रिपोर्टिंग प्रथाओं और डिलीवरी गति दोनों को दर्शा सकते हैं।
Verified इवेंट पुष्टि करता है कि कोड प्राप्त हुआ और उपयोग किया गया। इसका अंतराल केवल मैसेज डिलीवरी के बजाय पूर्णता को मापता है।
कोड दोबारा भेजे जाने पर इवेंट्स को कैसे जोड़ें?
इवेंट्स को verification_id, चैनल और प्राप्तकर्ता पते के अनुसार ग्रुप करें। अस्पष्ट बनी रहने वाली जोड़ियों को बाहर रखें।
Verify के सार्वजनिक इवेंट्स में कोई प्रयास पहचानकर्ता नहीं होता। दोबारा भेजने या चैनल बदलने से उसी सत्यापन पहचानकर्ता के अंतर्गत एक और प्रयास बनता है।
एक sent इवेंट और उसके delivered इवेंट के webhook-id मान अलग होते हैं। वह हेडर इवेंट्स को डिडुप्लिकेट करता है। यह किसी प्रयास के चरणों को नहीं जोड़ता।
टाइमस्टैम्प क्रम सरल अनुक्रमों को अलग कर सकता है। एक ही चैनल पर एक ही पते पर बार-बार भेजना ओवरलैप हो सकता है। केवल क्रम से यह साबित नहीं होता कि कौन सी डिलीवरी मेल खाती है।
ऐसे सैंपल को सटीक प्रयास विलंब देने के बजाय अस्पष्ट चिह्नित करें। सत्यापन का created-to-verified अंतराल एक अलग माप बना रहता है।
एक अनुपलब्ध या प्रतिबंधित चैनल बिना sent इवेंट के विफल हो सकता है। Sent-to-delivered अंतराल की गणना करने से पहले sent_at की उपस्थिति सुनिश्चित करें।
मेरे आँकड़े डैशबोर्ड से अलग क्यों हो सकते हैं?
डैशबोर्ड एक अलग अंतराल माप सकता है। यह आपकी इवेंट रिपोर्ट से अलग प्रयास भी शामिल कर सकता है।
डैशबोर्ड योग्य, शुल्क लगाए गए और डिलीवर किए गए प्रयासों के लिए प्रयास निर्माण से नतीजे तक का समय मापता है। यह सुधारे गए डिलीवरी टाइमआउट को उस विलंब सैंपल से बाहर रखता है क्योंकि उनके नतीजे तक का समय मापी गई डिलीवरी नहीं है।
इसकी रिपोर्टिंग विंडो शुल्क समय का उपयोग करती है। इसलिए भेजने के समय पर आधारित इवेंट रिपोर्ट में प्रयासों का अलग समूह शामिल हो सकता है।
स्टोर की गई विलंब चार्ज पढ़े जाने के समय की डिलीवरी स्थिति दर्शाती है। बाद का डिलीवरी अपडेट उस सैंपल को अपरिवर्तित छोड़ सकता है।
जब कोई योग्य सैंपल मौजूद नहीं होता तो पर्सेंटाइल null होता है। शून्य दिखाने के बजाय इस अंतर को बनाए रखें, क्योंकि शून्य तत्काल डिलीवरी का अर्थ देगा।
विसंगति की जाँच करने से पहले एक ही रिपोर्टिंग विंडो की तुलना करें। जब आपके ऐप्लिकेशन को अपना अंतराल और ग्रुपिंग चाहिए तो webhook इवेंट्स का उपयोग करें।
धीमे और गायब कोड की रिपोर्ट कैसे करें?
विलंब के साथ-साथ अनडिलीवर प्रयासों और अधूरे सत्यापनों की भी रिपोर्ट करें।
केवल डिलीवर किए गए प्रयासों वाली विलंब रिपोर्ट उन लोगों को छोड़ देती है जिनके कोड कभी पहुँचे ही नहीं। उन विफलताओं को समय सारांश के साथ दिखाएँ।
verify.verification.failed इवेंट उन डिलीवरी प्लान को कवर करता है जिनके सभी विकल्प समाप्त हो चुके हैं। कोड की अवधि समाप्त होने या गलत कोड प्रयासों की सीमा पूरी होने पर यह इवेंट नहीं बनता, इसलिए यह सत्यापन पूरा न होने की पूरी गिनती नहीं है।
अपने ऐप्लिकेशन में सत्यापन निर्माण और सफल पूर्णता ट्रैक करें। अनसुलझे सेशन को काल्पनिक डिलीवरी अवधि देने के बजाय अलग रखें।
प्रयासों को चैनल और प्राप्तकर्ता बाज़ार के अनुसार विभाजित करें। रिपोर्ट किए जाने पर, carrier और mcc_mnc हैंडलिंग नेटवर्क की पहचान करते हैं। दोनों ईमेल, WhatsApp और Telegram के लिए null होते हैं।
चैनल फ़ेलओवर ग्राहक के देर से आए कोड की व्याख्या कर सकता है। पूरी देरी को एक चैनल का डिलीवरी समय मानने से पहले प्रयासों के क्रम की जाँच करें।
संक्षेप में
आपको जो अंतराल चाहिए वह चुनें।
रिपोर्ट की गई डिलीवरी समय और पूर्ण सत्यापन समय अलग-अलग सवालों के जवाब देते हैं। पूर्णता में कोड पढ़ना और दर्ज करना शामिल है।
प्रयासों की जोड़ियाँ सावधानी से बनाएँ।
इवेंट्स सत्यापन की पहचान करते हैं, लेकिन प्रत्येक प्रयास की नहीं। एक ही चैनल पर बार-बार भेजने से जोड़ी बनाना अस्पष्ट हो सकता है।
विफलताओं को विलंब रिपोर्ट के साथ रखें।
केवल सफल डिलीवरी उन कोड्स को बाहर कर देती हैं जो कभी पहुँचे ही नहीं। अनडिलीवर और अधूरे सत्यापनों की अलग से रिपोर्ट करें।
समान ट्रैफ़िक की तुलना करें।
डिलीवरी रिपोर्ट चैनल और बाज़ार के अनुसार भिन्न होती हैं। पर्सेंटाइल की तुलना करने से पहले अपने अंतराल और सैंपल नियम रिकॉर्ड करें।