मैं कैसे मापूँ कि मेरे OTP पहुँचने में कितना समय लेते हैं?

रिपोर्ट किए गए डिलीवरी समय के लिए Verify के sent और delivered टाइमस्टैम्प की तुलना करें, और सत्यापन के पूरे अनुभव के लिए created और verified टाइमस्टैम्प की तुलना करें।

कोड का इंतज़ार कर रहे ग्राहक के लिए कतार, डिलीवरी, पढ़ना और दर्ज करना, सब एक ही देरी लगते हैं। यह तय करने से पहले कि धीमा साइनअप संदेश की डिलीवरी के कारण है या पूरे सत्यापन प्रवाह के कारण, इन अंतरालों को अलग करें।

मुझे कौन-से टाइमस्टैम्प एकत्र करने चाहिए?

Verify के जीवनचक्र इवेंट वेबहुक सब्सक्रिप्शन के माध्यम से एकत्र करें। उनके पेलोड के टाइमस्टैम्प संग्रहीत करें।

इवेंट पेलोड इन चरणों की पहचान करते हैं:

इवेंटटाइमस्टैम्पयह क्या दर्ज करता है
verify.verification.createdcreated_atसत्यापन बनाया गया
verify.attempt.sentsent_atBird ने एक सत्यापन कोड किसी चैनल को सौंपा
verify.attempt.delivereddelivered_atचैनल ने डिलीवरी की सूचना दी
verify.attempt.undeliveredfailed_atसत्यापन कोड का वह प्रयास विफल हुआ
verify.verification.verifiedverified_atप्राप्तकर्ता ने सही कोड जमा किया
verify.verification.failedfailed_atडिलीवरी योजना कोई कोड नहीं पहुँचा सकी

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

डुप्लिकेट डिलीवरी हटाने के लिए webhook-id का उपयोग करें, जो किसी इवेंट की पहचान करता है और फिर से प्रयास करने पर भी नहीं बदलता। इवेंट को क्रम में लगाते समय पेलोड के timestamp का उपयोग करें, क्योंकि इवेंट जिस क्रम में पहुँचते हैं, वह बदल सकता है।

कौन-सा अंतराल मेरे प्रश्न का उत्तर देता है?

रिपोर्ट किए गए डिलीवरी समय के लिए भेजे जाने से डिलीवर होने तक का अंतराल उपयोग करें। पूरे सत्यापन के समय के लिए बनाए जाने से सत्यापित होने तक का अंतराल उपयोग करें।

अंतरालइसमें क्या शामिल है
created_at से sent_at तकचैनल द्वारा सत्यापन कोड स्वीकार किए जाने से पहले का समय, जिसमें पहले के चैनलों की विफलताएँ भी शामिल हो सकती हैं
sent_at से delivered_at तकचैनल द्वारा स्वीकार किए जाने के बाद की प्रोसेसिंग और रिपोर्ट किया गया डिलीवरी अंतराल
created_at से verified_at तकपूरा इंतज़ार, जिसमें कोड पढ़ना और दर्ज करना शामिल है

भेजे जाने का टाइमस्टैम्प हमेशा कैरियर को सबमिशन का समय नहीं दर्शाता। SMS के लिए, Bird का चैनल प्रयास को स्वीकार करता है, और उसके बाद आगे की SMS पाइपलाइन उसे कैरियर को सबमिट करती है।

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

समय के साथ एक ही चैनल और बाज़ार की तुलना करें। देशों के बीच के अंतर डिलीवरी की गति के साथ-साथ रिपोर्टिंग के तरीकों से भी आ सकते हैं।

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

कोड दोबारा भेजे जाने पर मैं इवेंट्स को कैसे जोड़ूँ?

इवेंट्स को verification_id, चैनल और प्राप्तकर्ता के पते के आधार पर समूहित करें। जो जोड़े अस्पष्ट रहें, उन्हें बाहर रखें।

Verify के सार्वजनिक इवेंट्स में प्रयास का कोई पहचानकर्ता नहीं होता। दोबारा भेजने या चैनल बदलने पर उसी सत्यापन पहचानकर्ता के अंतर्गत एक नया प्रयास बनता है।

भेजे जाने के इवेंट और उसके डिलीवर होने के इवेंट के webhook-id मान अलग होते हैं। यह हेडर इवेंट्स की दोहराव हटाने के काम आता है। यह किसी प्रयास के चरणों को आपस में नहीं जोड़ता।

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

ऐसे नमूनों को सटीक प्रयास विलंब देने के बजाय अस्पष्ट के रूप में चिह्नित करें। सत्यापन के बनने से सत्यापित होने तक का अंतराल एक अलग माप बना रहता है।

अनुपलब्ध या प्रतिबंधित चैनल भेजे जाने के इवेंट के बिना भी विफल हो सकता है। भेजे जाने से डिलीवर होने तक का अंतराल निकालने से पहले sent_at का होना अनिवार्य रखें।

मेरे आँकड़े डैशबोर्ड से अलग क्यों हो सकते हैं?

डैशबोर्ड किसी अलग अंतराल को माप सकता है। उसमें आपकी इवेंट रिपोर्ट से अलग प्रयास भी शामिल हो सकते हैं।

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

इसकी रिपोर्टिंग अवधि शुल्क लगने के समय पर आधारित होती है। इसलिए भेजने के समय पर आधारित इवेंट रिपोर्ट में प्रयासों का अलग समूह शामिल हो सकता है।

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

जब कोई योग्य नमूना मौजूद नहीं होता, तो पर्सेंटाइल null होता है। इस अंतर को बनाए रखें और शून्य न दिखाएँ, क्योंकि शून्य तुरंत डिलीवरी का संकेत देगा।

किसी अंतर की जाँच करने से पहले एक ही रिपोर्टिंग अवधि की तुलना करें। जब आपके एप्लिकेशन को अपना अंतराल और समूहन चाहिए, तो वेबहुक इवेंट का उपयोग करें।

धीमे और न पहुँचे कोड की रिपोर्ट कैसे करें?

समय के साथ-साथ डिलीवर न हुए प्रयासों और पूरे न हुए सत्यापनों की भी रिपोर्ट करें।

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

verify.verification.failed इवेंट समाप्त हो चुकी डिलीवरी योजनाओं को कवर करता है। समय-सीमा खत्म होने और गलत कोड वाले प्रयास समाप्त होने पर यह इवेंट नहीं भेजा जाता, इसलिए यह पूरा न होने वाले सत्यापनों की पूरी गिनती नहीं है।

अपने एप्लिकेशन में सत्यापन बनने और सफलतापूर्वक पूरा होने को ट्रैक करें। अनसुलझे सत्रों को अलग रखें और उन्हें कोई गढ़ी हुई डिलीवरी अवधि न दें।

प्रयासों को चैनल और प्राप्तकर्ता के बाज़ार के अनुसार बाँटें। जब रिपोर्ट किए जाते हैं, तो carrier और mcc_mnc संदेश संभालने वाले नेटवर्क की पहचान करते हैं। ईमेल, WhatsApp और Telegram के लिए दोनों null होते हैं।

चैनल फ़ेलओवर से समझ आ सकता है कि किसी ग्राहक को कोड देर से क्यों मिला। पूरी देरी को एक ही चैनल का डिलीवरी समय मानने से पहले प्रयासों का क्रम जाँचें।

संक्षेप में

  1. वह अंतराल चुनें जिसकी आपको ज़रूरत है।

    रिपोर्ट किया गया डिलीवरी समय और पूरे हुए सत्यापन का समय अलग-अलग प्रश्नों का उत्तर देते हैं। पूरा होने के समय में कोड पढ़ना और दर्ज करना भी शामिल है।

  2. प्रयासों की जोड़ी सावधानी से बनाएँ।

    इवेंट सत्यापन की पहचान करते हैं, पर हर प्रयास की नहीं। एक ही चैनल पर बार-बार भेजने से जोड़ी बनाना अस्पष्ट हो सकता है।

  3. विफलताओं को विलंब रिपोर्ट के साथ रखें।

    केवल सफल डिलीवरी गिनने से वे कोड छूट जाते हैं जो कभी पहुँचे ही नहीं। डिलीवर न हुए और अधूरे सत्यापनों की रिपोर्ट अलग से दें।

  4. एक जैसे ट्रैफ़िक की ही तुलना करें।

    डिलीवरी रिपोर्ट चैनल और बाज़ार के अनुसार अलग होती हैं। पर्सेंटाइल की तुलना करने से पहले अपने अंतराल और सैंपल के नियम दर्ज करें।

उसी नेटवर्क पर बनाएँ।

एक टेस्ट API key आपको तुरंत मिल जाती है। भुगतान विधि जोड़ने और सेंडर सत्यापित करने पर प्रोडक्शन अनलॉक होता है।

आपका अगला आइडिया। जुड़ने के लिए तैयार।