--- url: 'https://www.corbado.com/hi/blog/authentication-observability' title: 'CIAM के लिए ऑथेंटिकेशन ऑब्जर्वेबिलिटी की आवश्यकता क्यों है' description: 'जानें कि कंज्यूमर ऑथेंटिकेशन ऑब्जर्वेबिलिटी क्यों महत्वपूर्ण है। क्लाइंट-साइड टेलीमेट्री, पासकी एनालिटिक्स और रियल-टाइम अडॉप्शन के साथ बैकएंड लॉग्स से आगे बढ़ें।' lang: 'hi' author: 'Vincent Delitz' date: '2026-06-15T14:01:12.060Z' lastModified: '2026-06-16T06:07:43.963Z' keywords: 'ऑथेंटिकेशन ऑब्जर्वेबिलिटी, CIAM ऑब्जर्वेबिलिटी, पासकी ऑब्जर्वेबिलिटी, लॉगिन सक्सेस रेट, पासकी अडॉप्शन मेट्रिक्स, WebAuthn टेलीमेट्री' category: 'Passkeys Strategy' --- # CIAM के लिए ऑथेंटिकेशन ऑब्जर्वेबिलिटी की आवश्यकता क्यों है ## 1. परिचय [FIDO Alliance](https://www.corbado.com/glossary/fido-alliance) 93% पासकी सक्सेस रेट की रिपोर्ट करता है - लेकिन अधिकांश CIAM टीमों को लॉन्च के बाद अडॉप्शन 5% और 15% के बीच अटका हुआ दिखाई देता है। यह अंतर इसलिए मौजूद है क्योंकि बैकएंड लॉग यह नहीं देख सकते कि कंज्यूमर के डिवाइस पर क्या होता है। ऑथेंटिकेशन ऑब्जर्वेबिलिटी उस अंतर को पाटती है। ## Key Facts - FIDO Alliance पासकी इंडेक्स (2025) के अनुसार, पासवर्ड और SMS OTP के लिए 63% की तुलना में पासकी साइन-इन **93% सक्सेस रेट** प्राप्त करते हैं। - मजबूत डिवाइस सपोर्ट के बावजूद अधिकांश CIAM डिप्लॉयमेंट में पासकी अडॉप्शन लॉन्च के बाद **5% और 15%** के बीच रुक जाता है। - **80% से अधिक पासकी विफलताएं कंज्यूमर के डिवाइस पर होती हैं** इससे पहले कि कोई अनुरोध बैकएंड सर्वर तक पहुंचे। - बैकएंड IdP लॉग यह नहीं बता सकते कि क्या किसी कंज्यूमर ने Face ID रद्द कर दिया, कोई बायोमेट्रिक टाइमआउट था, या पासवर्ड मैनेजर एक्सटेंशन द्वारा अवरुद्ध कर दिया गया था। - ऑथेंटिकेशन ऑब्जर्वेबिलिटी **संपूर्ण क्लाइंट-साइड जर्नी** को ट्रैक करती है, जिसमें कंज्यूमर द्वारा अपना ईमेल टाइप करने से पहले की प्री-आइडेंटिफायर घटनाएं भी शामिल हैं। - डायनामिक डिवाइस सप्रेशन ज्ञात टूटे हुए डिवाइस/OS संयोजनों के लिए सपोर्ट टिकटों को **60%** तक कम कर सकता है। - कोहोर्ट-आधारित नजिंग हाई-कॉन्फिडेंस डिवाइस सेगमेंट (जैसे macOS + Safari + Apple Silicon) के लिए पासकी एनरोलमेंट को सिंगल डिजिट से **47%** तक बढ़ा सकती है। - ऑथेंटिकेशन ऑब्जर्वेबिलिटी दो मुख्य KPI को ट्रैक करती है: **पासकी एक्टिवेशन रेट** (कितने पात्र कंज्यूमर एक पासकी बनाते हैं) और **पासकी यूसेज रेट** (दैनिक लॉगिन के लिए कितने इसका उपयोग करते हैं)। ## 2. CIAM ऑब्जर्वेबिलिटी वर्कफोर्स IAM से कैसे भिन्न है कंज्यूमर आइडेंटिटी और वर्कफोर्स IAM शब्दावली शेयर करते हैं लेकिन इसके अलावा और कुछ नहीं। वर्कफोर्स IAM में, IT हर लैपटॉप, ब्राउज़र और सिक्योरिटी की का प्रबंधन करता है। यदि पासकी टूट जाती है, तो एनवायरनमेंट ज्ञात होता है। CIAM में, कंज्यूमर अनमैनेज्ड डिवाइस का उपयोग करते हैं - बजट [Android](https://www.corbado.com/blog/how-to-enable-passkeys-android) फोन, पांच साल पुराने iPad, कई पासवर्ड मैनेजर एक्सटेंशन वाले शेयर्ड PC - और क्लाइंट-साइड एनवायरनमेंट अप्रत्याशित होता है। ### 2.1 अनाम यूज़र और प्री-आइडेंटिफायर ब्लाइंडनेस समस्या वर्कफोर्स IAM में, प्रत्येक यूज़र लॉगिन करने से पहले Active Directory में मौजूद होता है। CIAM में, एक कंज्यूमर तब तक अदृश्य रहता है जब तक वह अपना ईमेल टाइप नहीं करता। यदि वे उससे पहले चले जाते हैं - क्योंकि एक पासकी प्रॉम्प्ट ने उन्हें भ्रमित कर दिया या पासवर्ड मैनेजर ओवरले ने ऑटोफिल को अवरुद्ध कर दिया - तो आपका बैकएंड कुछ भी रिकॉर्ड नहीं करता है। यह "प्री-आइडेंटिफायर ब्लाइंडनेस" कंज्यूमर ऑथेंटिकेशन में सबसे बड़ी विज़िबिलिटी गैप है और वह बिंदु है जहां सबसे अधिक रेवेन्यू लीक होता है। **उदाहरण:** एक [ई-कॉमर्स](https://www.corbado.com/passkeys-for-e-commerce) प्लेटफॉर्म के लॉगिन पेज पर 15% बाउंस रेट था लेकिन कोई बैकएंड त्रुटि नहीं थी। क्लाइंट-साइड ऑब्जर्वेबिलिटी से पता चला कि [1Password](https://www.corbado.com/blog/1password-passkeys-best-practices-analysis) एक्सटेंशन नेटिव पासकी ऑटोफिल को कवर कर रहा था। कंज्यूमर ने एक अव्यवस्थित UI देखा और चले गए। किसी भी सर्वर लॉग ने इसे कभी कैप्चर नहीं किया। ### 2.2 कंज्यूमर ऑथेंटिकेशन के लिए कौन से मेट्रिक्स मायने रखते हैं ![लॉगिन के तरीके तुलना डैशबोर्ड](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/login_methods_comparison_dashboard_a38e552f34.png) CIAM के लिए ऑथेंटिकेशन ऑब्जर्वेबिलिटी क्लासिक SRE "गोल्डन सिग्नल" को लॉगिन-विशिष्ट KPI में बदल देती है। पासकी एनालिटिक्स डैशबोर्ड में ट्रैक करने के लिए सबसे महत्वपूर्ण मेट्रिक्स: - **लॉगिन सक्सेस रेट (LSR):** लॉगिन प्रयासों का प्रतिशत जो बिना किसी त्रुटि के पूरे होते हैं। यदि यह रातोंरात 91% से गिरकर 85% हो जाता है, तो कुछ टूट गया है। - **ऑथेंटिकेशन ड्रॉप-ऑफ रेट:** उन कंज्यूमर का प्रतिशत जो लॉगिन फ्लो शुरू करते हैं लेकिन कभी पूरा नहीं करते। हर निर्णय बिंदु पर ट्रैक किया गया - पेज पर लैंड करने से लेकर बायोमेट्रिक वेरिफिकेशन पूरा करने तक। - **पासकी एक्टिवेशन रेट (एपेंड रेट):** उन सभी कंज्यूमर में से जिनके डिवाइस पासकी का समर्थन करते हैं, कितनों ने [पासकी बनाई है जब उनसे ऐसा करने के लिए कहा गया था](https://www.corbado.com/blog/passkey-analytics)? लक्ष्य: पहले वर्ष के भीतर 60% से अधिक पात्र यूज़र। - **पासकी यूसेज रेट (लॉगिन रेट):** सभी लॉगिन प्रयासों में से, कितने पासकी का उपयोग करते हैं? लक्ष्य: 40% से अधिक लॉगिन। वास्तविक अडॉप्शन प्रगति को मापने के लिए [लिगेसी फॉलबैक रेट्स](https://www.corbado.com/blog/passkey-day-2-problems) के खिलाफ ट्रैक किया गया। - **पासवर्ड रीसेट वॉल्यूम:** एक स्पाइक का मतलब है कि कंज्यूमर अंदर नहीं जा सकते - यह चर्न और बढ़ती [सपोर्ट लागतों](https://www.corbado.com/blog/passkey-adoption-business-case) का एक मजबूत लीडिंग इंडिकेटर है। वर्कफोर्स IAM में, एक विफल लॉगिन एक हेल्पडेस्क टिकट बनाता है। CIAM में, यह चर्न और संभवतः केवल एक हेल्पडेस्क टिकट बनाता है। ऑथेंटिकेशन हर उच्च-मूल्य वाली कंज्यूमर कार्रवाई - चेकआउट, सब्सक्रिप्शन रिन्यूअल, डैशबोर्ड एक्सेस को गेट करता है। एक सब्सक्रिप्शन SaaS कंपनी ने पाया कि प्रति माह दो या अधिक विफल लॉगिन वाले कंज्यूमर ने सामान्य दर के 3 गुना पर चर्न किया। ऑब्जर्वेबिलिटी ने उस संबंध को दृश्यमान बनाया। ## 3. पासकी के लिए बैकएंड लॉग और जेनेरिक एनालिटिक्स क्यों विफल होते हैं अधिकांश CIAM टीमें IdP लॉग और [GA4](https://www.corbado.com/blog/tracking-logins-google-analytics-ga4) या Mixpanel जैसे टूल पर भरोसा करती हैं। पासवर्ड-आधारित लॉगिन के लिए, वह पर्याप्त था। पासकी के लिए, ऐसा नहीं है - क्योंकि महत्वपूर्ण क्षण सर्वर से कंज्यूमर के डिवाइस पर स्थानांतरित हो गया है। ### 3.1 क्लाइंट-साइड "ब्लैक बॉक्स" पासवर्ड के साथ, फ्लो सीधा है: कंज्यूमर क्रेडेंशियल भेजता है, सर्वर उनकी जांच करता है, सर्वर परिणाम लॉग करता है। पासकी के साथ, ब्राउज़र एक नेटिव OS मोडल - [iCloud Keychain](https://www.corbado.com/glossary/icloud-keychain), [Google Password Manager](https://www.corbado.com/blog/how-to-use-google-password-manager), [Windows Hello](https://www.corbado.com/glossary/windows-hello) या थर्ड-पार्टी एक्सटेंशन खोलता है। यदि कोई बायोमेट्रिक टाइम आउट हो जाता है, गलत क्रेडेंशियल मैनेजर टेकओवर कर लेता है या कंज्यूमर रद्द कर देता है - यह सब सर्वर तक कोई अनुरोध पहुंचने से पहले होता है। **उदाहरण:** एक [बैंकिंग](https://www.corbado.com/passkeys-for-banking) ऐप ने [iOS](https://www.corbado.com/blog/how-to-enable-passkeys-ios) अपडेट के बाद पासकी प्रयासों में 30% की गिरावट देखी। बैकएंड लॉग ने कम अनुरोध दिखाए लेकिन शून्य त्रुटियां। क्लाइंट-साइड ऑब्जर्वेबिलिटी ने कारण पाया: [iOS 18](https://www.corbado.com/blog/ios-18-passkeys-automatic-passkey-upgrades).2 ने बदल दिया कि Safari ने ऑटोफिल ड्रॉपडाउन को कैसे प्रदर्शित किया, और कंज्यूमर ने बस पासकी विकल्प को अनदेखा कर दिया। निम्नलिखित आरेख दर्शाता है कि प्रत्येक ऑथेंटिकेशन विधि के लिए विज़िबिलिटी कहाँ समाप्त होती है: ### 3.2 जेनेरिक एनालिटिक्स पासकी-विशिष्ट डेटा को मिस करते हैं कस्टम इवेंट (GA4 कस्टम डायमेंशन, Mixpanel कस्टम प्रॉपर्टीज़) स्वीकार करने वाले टूल भी पासकी डेटा के साथ संरचनात्मक सीमाओं से टकराते हैं। पासकी का प्रदर्शन OS वर्ज़न + ब्राउज़र वर्ज़न + क्रेडेंशियल मैनेजर + हार्डवेयर ऑथेंटिकेटर के सटीक संयोजन - हज़ारों अद्वितीय संयोजनों पर निर्भर करता है। [GA4](https://www.corbado.com/blog/tracking-logins-google-analytics-ga4) 500 से अधिक अद्वितीय मानों वाले कस्टम डायमेंशन को हाई-कार्डिनैलिटी के रूप में फ़्लैग करता है, अतिरिक्त मानों को "(अन्य)" बकेट में रोल करता है या सैंपलिंग ट्रिगर करता है - प्रभावी रूप से डिवाइस/ब्राउज़र/क्रेडेंशियल-मैनेजर संयोजनों की लंबी पूंछ को छिपाता है जो पासकी डिबगिंग के लिए सबसे ज्यादा मायने रखते हैं। Mixpanel इवेंट वॉल्यूम द्वारा शुल्क लेता है और कोई नेटिव WebAuthn इवेंट स्कीमा प्रदान नहीं करता है। वे पासकी के लिए अद्वितीय सिग्नल भी मिस करते हैं: क्या क्रेडेंशियल iCloud के माध्यम से सिंक किया गया है या डिवाइस-बाउंड है? क्या कंज्यूमर QR कोड के माध्यम से क्रॉस-डिवाइस ऑथेंटिकेशन (Cross-Device Authentication) का प्रयास कर रहा है? क्या बैकग्राउंड में [Conditional UI](https://www.corbado.com/glossary/conditional-ui) ट्रिगर किया गया था? ये नेटिव ब्राउज़र API स्टेट्स हैं जिन्हें कैप्चर करने के लिए उद्देश्य-निर्मित इंस्ट्रूमेंटेशन की आवश्यकता होती है। ## 4. ऑथेंटिकेशन ऑब्जर्वेबिलिटी वास्तव में क्या ट्रैक करती है ऑथेंटिकेशन ऑब्जर्वेबिलिटी केवल "अधिक लॉगिंग" नहीं है। इसका वास्तविक मूल्य उस संदर्भ में निहित है जो यह प्रदान करता है - [परिणाम से कंज्यूमर की संपूर्ण जर्नी को बैकफिलिंग और बैक-कैलकुलेटिंग करना](https://www.corbado.com/pricing), उन घटनाओं के लिए भी जो कंज्यूमर के अपना ईमेल टाइप करने से पहले हुई थीं। ### 4.1 शुरुआत से अंत तक सेरेमनी के चरण एक उद्देश्य-निर्मित क्लाइंट-साइड SDK [संपूर्ण पासकी लाइफसाइकिल](https://www.corbado.com/blog/passkey-analytics) को एक संरचित [इवेंट टैक्सोनॉमी](https://www.corbado.com/blog/hardware-passkey-adoption-observability) के रूप में ट्रैक करता है: ![फ़नल एनालिसिस डायग्राम](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/funnel_analysis_diagram_817efe52e9.png) - **कंज्यूमर ने कैसे शुरुआत की:** [Conditional UI](https://www.corbado.com/glossary/conditional-ui) ऑटोफिल, समर्पित "Sign in with Passkey" बटन या मैन्युअल ईमेल एंट्री - **डिवाइस चेक:** एक साइलेंट [कैपेबिलिटी प्रोब](https://developer.chrome.com/blog/passkeys-client-capabilities) यह निर्धारित करता है कि क्या कोई UI दिखाए जाने से पहले डिवाइस पासकी का समर्थन करता है - **ऑथेंटिकेटर विकल्प:** फोन के मैनेजर से सिंक किया गया पासकी या NFC, USB या Bluetooth के माध्यम से बाहरी हार्डवेयर की - **बायोमेट्रिक चरण:** [Face ID](https://www.corbado.com/faq/is-face-id-passkey), फिंगरप्रिंट या PIN - और क्या यह सफल रहा, टाइम आउट हो गया या रद्द हो गया? - **अंतिम परिणाम:** एक विशिष्ट [WebAuthn एरर कोड](https://www.corbado.com/blog/webauthn-errors) जो बताता है कि क्या विफल रहा - केवल "सक्सेस" या "एरर" नहीं **उदाहरण:** एक [रिटेल](https://www.corbado.com/passkeys-for-e-commerce) ऐप ने इन चरणों को ट्रैक किया और पाया कि 22% [Android](https://www.corbado.com/blog/how-to-enable-passkeys-android) पासकी प्रयास "ऑथेंटिकेटर विकल्प" पर विफल हो रहे हैं। मूल कारण: [Samsung](https://www.corbado.com/blog/samsung-passkeys) Pass कुछ Galaxy डिवाइस पर डिफ़ॉल्ट क्रेडेंशियल मैनेजर था, और यह उन WebAuthn एक्सटेंशन का समर्थन नहीं करता था जिनकी ऐप को आवश्यकता थी। [Google Password Manager](https://www.corbado.com/blog/how-to-use-google-password-manager) ने काम किया होता, लेकिन [Samsung](https://www.corbado.com/blog/samsung-passkeys) की OS स्किन ने पहले [Samsung](https://www.corbado.com/blog/samsung-passkeys) Pass को अनुरोध रूट किए। नीचे दिया गया आरेख इन सेरेमनी चरणों को एक फ़नल के रूप में दिखाता है जिसमें प्रत्येक चरण में विशिष्ट विफलता बिंदु होते हैं: ### 4.2 व्यावसायिक निर्णयों के लिए WebAuthn एरर कोड की व्याख्या करना जब एक सेरेमनी विफल हो जाती है, तो ब्राउज़र एक विशिष्ट [एरर कोड](https://www.corbado.com/blog/webauthn-errors) लौटाता है। तकनीकी परिभाषा की तुलना में व्यावसायिक व्याख्या अधिक मायने रखती है: | **एरर (Error)** | **क्या हुआ (What happened)** | **क्या करें (What to do)** | | --------------------- | --------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------- | | **NotAllowedError** | कंज्यूमर ने रद्द कर दिया या टाइम आउट हो गया। | सबसे आम। यदि दर बढ़ती है, तो विभिन्न प्री-प्रॉम्प्ट मैसेजिंग का परीक्षण करें। घर्षण रहित फॉलबैक सुनिश्चित करें। | | **NotSupportedError** | डिवाइस पासकी का समर्थन नहीं करता है। | इस डिवाइस प्रकार के लिए पासकी UI को सप्रैस करें। पासवर्ड या OTP पर डिफ़ॉल्ट करें। | | **SecurityError** | HTTPS या डोमेन कॉन्फिगरेशन समस्या। | TLS सर्टिफिकेट और Relying Party ID सेटिंग्स की तुरंत जांच करें। | | **UnknownError** | क्रेडेंशियल मैनेजर क्रैश हो गया या एक्सटेंशन ने हस्तक्षेप किया। | जांचें कि क्या कोई विशिष्ट एक्सटेंशन (Bitwarden, LastPass) समस्या का कारण बनता है। | | **AbortError** | आपके ऐप के टाइमआउट ने अनुरोध को समाप्त कर दिया। | टाइमआउट बढ़ाएँ - कुछ बायोमेट्रिक प्रतिक्रियाओं को अधिक समय की आवश्यकता होती है। | **उदाहरण:** एक [ट्रैवल](https://www.corbado.com/passkeys-for-travel) बुकिंग साइट ने देखा कि Firefox यूज़र्स के लिए UnknownError बढ़कर 8% हो गया है। उन त्रुटियों में से 92% उन कंज्यूमर से आई हैं जिनका [Bitwarden](https://www.corbado.com/blog/passkey-analysis-bitwarden-developer-survey-2024) एक्सटेंशन सक्रिय था - इसने WebAuthn कॉल को इंटरसेप्ट किया और चुपचाप विफल हो गया। सुधार: [Bitwarden](https://www.corbado.com/blog/passkey-analysis-bitwarden-developer-survey-2024) का पता लगाएं और पासकी प्रॉम्प्ट को छोड़ दें जब तक कि एक्सटेंशन बग हल न हो जाए। [WebAuthn स्पेक](https://www.w3.org/TR/webauthn-3/) विकसित हो रहा है। [प्रस्तावित नए एरर कोड]() जैसे UserCancellationError (जानबूझकर रद्द करना बनाम टाइमआउट) और HybridPrerequisitesError (क्रॉस-डिवाइस के लिए Bluetooth अनुपलब्ध) ब्राउज़र द्वारा अपनाए जाने के बाद अधिक ग्रैन्युलैरिटी जोड़ देंगे। ## 5. कंज्यूमर पासकी के लिए साइन अप क्यों नहीं करते हैं (और कैसे पता करें) सबसे कठिन समस्या यह डिबग करना नहीं है कि पासकी सेरेमनी क्यों विफल हुई। यह उस प्रश्न का उत्तर देना है जो हर PM पूछता है: [कंज्यूमर पहली बार में पासकी के लिए साइन अप क्यों नहीं कर रहे हैं](https://www.corbado.com/pricing)? यह प्री-एनरोलमेंट समस्या है, और बैकएंड लॉग इसके प्रति पूरी तरह से अंधे हैं। ### 5.1 कंज्यूमर द्वारा आइडेंटिफायर प्रदान करने से पहले जर्नी को बैकफिल करना एक अच्छी ऑब्जर्वेबिलिटी प्रणाली डेटा कैप्चर करती है, तब भी जब कंज्यूमर पासकी के साथ कुछ नहीं करता है। जब कोई लॉगिन पेज पर आता है, तो SDK चुपचाप जाँचता है: क्या यह डिवाइस पासकी का समर्थन करता है? क्या [Conditional UI उपलब्ध है](https://developer.chrome.com/blog/passkeys-client-capabilities)? क्या कोई प्लेटफॉर्म ऑथेंटिकेटर मौजूद है? ![पासकी क्लाइंट कैपेबिलिटीज़](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/client_capabilities_ce51dce167.png) यदि डिवाइस सक्षम है लेकिन कंज्यूमर इसके बजाय "Sign In With Password" पर क्लिक करता है, तो सिस्टम एक प्री-एनरोलमेंट परित्याग घटना को लॉग करता है। हज़ारों सत्रों में, ये घटनाएँ [पैटर्न प्रकट करती हैं](https://www.corbado.com/pricing) - क्या ड्रॉप-ऑफ़ अस्पष्ट प्रॉम्प्ट, पासकी के बारे में शिक्षा की कमी या [पासवर्ड मैनेजर ओवरले](https://www.passkeycentral.org/news-and-events/passkey-upgrades-and-improvements) फॉर्म फ़ील्ड को इंटरसेप्ट करने के कारण होता है। **उदाहरण:** एक [हेल्थकेयर](https://www.corbado.com/passkeys-for-healthcare) पोर्टल ने देखा कि 70% Mac यूज़र्स पासकी विकल्प को अनदेखा कर रहे हैं। ऑब्जर्वेबिलिटी ने दिखाया कि पासकी प्रॉम्प्ट फ़ोल्ड के नीचे दिखाई दिया। अधिकांश कंज्यूमर ने कभी नीचे स्क्रॉल नहीं किया। प्रॉम्प्ट को पासवर्ड फ़ील्ड के ऊपर ले जाने से एनरोलमेंट दोगुना हो गया। ### 5.2 Conditional UI: अदृश्य विफलता बिंदु [Conditional UI](https://www.corbado.com/glossary/conditional-ui) पासकी को सेव किए गए पासवर्ड के साथ ब्राउज़र के ऑटोफिल ड्रॉपडाउन में दिखाई देने देता है। यह बैकग्राउंड में चुपचाप चलता है। आपके बैकएंड को कभी पता नहीं चलता कि यह फायर हुआ जब तक कि कंज्यूमर वास्तव में पासकी का चयन नहीं करता। पासकी ऑब्जर्वेबिलिटी ट्रैक करती है कि क्या Conditional UI लागू किया गया था। यदि यह हज़ारों डिवाइस पर फायर होता है लेकिन लगभग कोई भी पासकी का चयन नहीं करता है, तो समस्या UI है - क्रिप्टो नहीं। हो सकता है कि ऑटोफिल ड्रॉपडाउन गलत तरीके से रेंडर हो, या कस्टम CSS ब्राउज़र के नेटिव व्यवहार को दबा रहा हो। **उदाहरण:** एक मीडिया स्ट्रीमिंग सेवा ने पाया कि Conditional UI 94% सक्षम उपकरणों पर सही ढंग से फायर हुआ, लेकिन चयन दर केवल 3% थी। लॉगिन फॉर्म ने एक कस्टम-स्टाइल इनपुट का उपयोग किया जिसने नेटिव ऑटोफिल ड्रॉपडाउन को सप्रैस कर दिया। एक मानक इनपुट पर स्विच करने से चयन 31% हो गया। ## 6. डेटा से एक्शन तक: टूटे हुए उपकरणों को सप्रैस करना और सर्वश्रेष्ठ को नज़ (nudge) करना ऑब्जर्वेबिलिटी डेटा एकत्र करना केवल तभी मायने रखता है जब आप उस पर कार्रवाई करते हैं। सिस्टम को एक नियम इंजन फ़ीड करना चाहिए जो वास्तविक समय में कंज्यूमर को जो दिखाई देता है उसे बदल देता है। ### 6.1 सिस्टमिक विफलताओं बनाम यादृच्छिक रद्दीकरण को पहचानना ![टेक्नोलॉजी ब्रेकडाउन](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/technology_breakdown_aa7a88ecdc.png) हर पासकी विफलता एक बग नहीं है। [Face ID](https://www.corbado.com/faq/is-face-id-passkey) प्रॉम्प्ट पर कंज्यूमर का "Cancel" टैप करना रूटीन है। लेकिन जब विफलताएं [किसी विशिष्ट डिवाइस/OS/ब्राउज़र संयोजन के आसपास क्लस्टर होती हैं](https://www.corbado.com/blog/hardware-passkey-adoption-observability), तो वह सिस्टमिक होता है। **उदाहरण:** वैश्विक पासकी सक्सेस रेट: 92%। Chrome के साथ One UI 6.0 पर Samsung Galaxy A14: 15%। यह यूज़र एरर नहीं है - यह एक [टूटा हुआ क्रेडेंशियल मैनेजर कार्यान्वयन](https://dev.to/corbado/passkey-day-2-problems-5-risks-in-production-deployments-2hcl) है। ऑब्जर्वेबिलिटी इसे हफ्तों के बजाय घंटों में सामने लाती है। ### 6.2 टूटे हुए एनवायरनमेंट को स्वचालित रूप से सप्रैस करना जब लॉगिन विफल हो जाता है तो कंज्यूमर आपके ऐप को दोष देते हैं - अपने फोन निर्माता को नहीं। एक बार जब ऑब्जर्वेबिलिटी एक डिवाइस/OS संयोजन की पहचान कर लेती है जहां पासकी मज़बूती से टूट जाती है, तो एक ["किल स्विच"](https://www.corbado.com/passkeys-for-banking) पासकी प्रॉम्प्ट को सप्रैस कर देता है और टूटे हुए मोडल को देखने से पहले कंज्यूमर को एक विश्वसनीय फॉलबैक - मैजिक लिंक, TOTP या पासवर्ड - पर रूट कर देता है। **उदाहरण:** एक राइड-शेयरिंग ऐप ने संयुक्त 82% [पासकी विफलता दर](https://www.corbado.com/blog/passkey-day-2-problems) के साथ तीन बजट [Android](https://www.corbado.com/blog/how-to-enable-passkeys-android) मॉडल की पहचान की। उन उपकरणों के लिए पासकी को सप्रैस करने के बाद, प्रभावित क्षेत्रों से सपोर्ट टिकट एक सप्ताह के भीतर 60% गिर गए। ### 6.3 हाई-कॉन्फिडेंस कोहोर्ट को नज़ करना दूसरी ओर, यदि ऑब्जर्वेबिलिटी दिखाती है कि macOS + Safari + Apple Silicon कंज्यूमर 98% पर सफल होते हैं, तो वह कोहोर्ट [असर्टिव नज़िंग](https://www.corbado.com/) के लिए सुरक्षित है - पासकी मोडल को ऑटो-इनवोक करना, "Your [iCloud Keychain](https://www.corbado.com/glossary/icloud-keychain) is ready to secure your account" प्रदर्शित करना या "More options" के पीछे छिपे पासवर्ड के साथ पासकी को डिफ़ॉल्ट बनाना। **उदाहरण:** एक ऑनलाइन [मार्केटप्लेस](https://www.corbado.com/passkeys-for-e-commerce) ने पासवर्ड लॉगिन के बाद एक ऑटो-ट्रिगर्ड एनरोलमेंट मोडल के साथ [हाई-कॉन्फिडेंस कोहोर्ट्स को नज़ किया](https://www.corbado.com/pricing)। macOS/Safari कंज्यूमर ने 47% पर एनरोल किया। अन्य सभी कोहोर्ट्स (कम आक्रामक नज़िंग): 11%। निम्नलिखित डिसीजन ट्री ऑब्जर्वेबिलिटी डेटा द्वारा संचालित सप्रैस-या-नज़ लॉजिक को सारांशित करता है: ## 7. एक्टिवेशन रेट और यूसेज रेट को आगे बढ़ाना ऑथेंटिकेशन ऑब्जर्वेबिलिटी दो KPI की सेवा करती है: [एक्टिवेशन रेट](https://www.corbado.com/blog/passkey-analytics) (क्या कंज्यूमर पासकी बना रहे हैं?) और यूसेज रेट (क्या वे नियमित रूप से उनका उपयोग कर रहे हैं?)। ### 7.1 एक्टिवेशन रेट को बढ़ाना एक्टिवेशन रेट उन पात्र कंज्यूमर्स का प्रतिशत मापता है जिन्होंने पासकी बनाई है। मानक एनालिटिक्स इसकी गणना नहीं कर सकते क्योंकि वे नहीं जानते कि कौन से उपकरण पासकी का समर्थन करते हैं। ऑब्जर्वेबिलिटी [निरंतर कैपेबिलिटी प्रोबिंग](https://www.corbado.com/blog/passkey-analytics) के साथ इसे हल करती है। - **आफ्टर-पेन प्रॉम्प्ट्स (After-Pain Prompts):** जब कोई कंज्यूमर पासवर्ड रीसेट के माध्यम से संघर्ष करता है, तो तुरंत एक पासकी निर्माण प्रॉम्प्ट दिखाएं। निराशा ताज़ा है - इस क्षण स्वीकृति दर सबसे अधिक है। - **लगातार प्रॉम्प्टिंग (Persistent Prompting):** [एनालिटिक्स दिखाते हैं](https://www.corbado.com/blog/passkey-analytics) कि तीसरे या चौथे प्रॉम्प्ट पर भी डबल-डिजिट रेट पर कंवर्ट होता है, जब तक कि यह नॉन-ब्लॉकिंग हो। **उदाहरण:** एक [बैंकिंग](https://www.corbado.com/passkeys-for-banking) ऐप ने हर पासवर्ड-रीसेट फ्लो के बाद पासकी निर्माण का प्रॉम्प्ट दिया। 34% कंज्यूमर्स ने रीसेट करने के ठीक बाद एक पासकी बनाई, जबकि सामान्य लॉगिन के दौरान प्रॉम्प्ट दिए जाने पर यह 8% था। ### 7.2 यूसेज रेट को बढ़ाना एक कंज्यूमर पासकी बना सकता है लेकिन आदत से अपना पासवर्ड टाइप करता रहता है। यूसेज रेट ट्रैक करता है कि सभी लॉगिन के सापेक्ष कितनी बार पासकी का उपयोग किया जाता है। - **बेहतर इनीशिएशन UX:** यदि टेलीमेट्री दिखाती है कि सक्रिय पासकी वाले कंज्यूमर अभी भी यूज़रनेम टाइप कर रहे हैं, तो ऑटोफिल विफल हो रहा है। टेक्स्ट फ़ील्ड के सामने रखा गया एक प्रमुख "[One-Tap](https://docs.corbado.com/corbado-connect/features/one-tap-login)" बटन लिगेसी व्यवहार को इंटरसेप्ट करता है। - **क्रॉस-डिवाइस लॉगिन को ठीक करें:** iPhone पासकी के साथ Windows लैपटॉप में लॉग इन करते समय, कंज्यूमर QR कोड स्कैन करते हैं और Bluetooth का उपयोग करते हैं। यदि [CDA पूर्णता गिर जाती है](https://www.corbado.com/blog/passkey-day-2-problems) (जैसे 42% तक), तो "Turn on Bluetooth" और "Point camera here" स्पष्ट निर्देश कई प्रयासों को बचाते हैं। **उदाहरण:** एक [बीमा](https://www.corbado.com/passkeys-for-insurance) पोर्टल ने पाया कि 60% नामांकित कंज्यूमर अभी भी पासवर्ड का उपयोग करते थे। पासकी ऑटोफिल पासवर्ड फ़ील्ड के नीचे रेंडर हुआ। इसे ऊपर ले जाने और "Sign in with [Face ID](https://www.corbado.com/faq/is-face-id-passkey)" बटन जोड़ने से दो महीनों के भीतर पासकी का उपयोग 40% से बढ़कर 73% हो गया। ## 8. डे 2 बुरे सपने: नेटिव ऐप्स और साइलेंट प्लेटफॉर्म बदलाव पासकी सेट करना आसान हिस्सा है। कंज्यूमर डिवाइस की अराजकता में उन्हें काम करते रहना वह जगह है जहां [ऑब्जर्वेबिलिटी आवश्यक हो जाती है](https://www.corbado.com/blog/passkey-day-2-problems)। ### 8.1 नेटिव ऐप कॉम्प्लेक्सिटी ब्राउज़र में पासकी सीधी है। नेटिव [iOS](https://www.corbado.com/blog/how-to-enable-passkeys-ios) और Android ऐप्स में, QA सतह तिगुनी हो जाती है। डेवलपर्स नेटिव API (iOS पर AuthenticationServices, Android पर Credential Manager) या एम्बेडेड WebViews के बीच चयन करते हैं। प्रत्येक पथ [अलग तरह से विफल होता है](https://dev.to/corbado/passkey-day-2-problems-5-risks-in-production-deployments-2hcl)। **उदाहरण:** एक फूड डिलीवरी ऐप का [iOS](https://www.corbado.com/blog/how-to-enable-passkeys-ios) कार्यान्वयन पूरी तरह से काम करता था, लेकिन उनके Android ऐप ने एक एम्बेडेड [WebView](https://www.corbado.com/blog/native-app-passkeys) का उपयोग किया जिसने Android 13 पर चुपचाप पासकी अनुरोध छोड़ दिए। [नेटिव-विशिष्ट टेलीमेट्री](https://www.corbado.com/blog/hardware-passkey-adoption-observability) के बिना, टीम ने सर्वर-साइड समस्या को दोष देने में तीन सप्ताह बिताए। ### 8.2 साइलेंट OS अपडेट Apple, Google और Microsoft लगातार अपडेट शिप करते हैं। अधिकांश पासकी सपोर्ट में सुधार करते हैं, लेकिन कुछ [साइलेंट रिग्रेशन](https://www.corbado.com/blog/passkey-day-2-problems) पेश करते हैं जो बिना चेतावनी के मौजूदा लॉजिक को तोड़ देते हैं। **उदाहरण:** [iOS 18](https://www.corbado.com/blog/ios-18-passkeys-automatic-passkey-upgrades).1 ने बदल दिया कि Mac पर Chrome को Safari ने [डिवाइस क्षमताओं](https://www.corbado.com/blog/hardware-passkey-adoption-observability) की रिपोर्ट कैसे की। Chrome ने गलत तरीके से रिपोर्ट करना शुरू कर दिया "no [platform authenticator](https://www.corbado.com/glossary/platform-authenticator) available," पासकी विकल्प को पूरी तरह से छिपाते हुए। बैकएंड लॉग ने कम प्रयास दिखाए लेकिन कोई त्रुटि नहीं। क्लाइंट-साइड ऑब्जर्वेबिलिटी ने घंटों के भीतर सटीक OS + ब्राउज़र संयोजन को फ़्लैग किया। ## 9. CIAM टीमों के लिए निर्माण बनाम खरीद एक बार जब आप क्लाइंट-साइड टेलीमेट्री की आवश्यकता देखते हैं, तो प्रश्न यह है: इसे स्वयं बनाएं या [एक विशेष समाधान खरीदें](https://www.corbado.com/pricing)? ### 9.1 इन-हाउस बनाने की छिपी लागत DIY पथ सरल लगता है: JavaScript में WebAuthn कॉल रैप करें, इवेंट्स को अपने लॉगिंग स्टैक में पाइप करें। व्यवहार में, जेनेरिक टूल [कार्डिनैलिटी को नहीं संभाल सकते](https://www.corbado.com/blog/passkey-analytics)। जैसे-जैसे इकोसिस्टम विकसित होता है, आपकी टीम को इवेंट टैक्सोनॉमी को बनाए रखना चाहिए - [नए एरर कोड पर शोध करना](https://www.corbado.com/pricing) और प्रत्येक OS रिलीज़ के बाद पार्सर को अपडेट करना। जब कुछ टूट जाता है, तो फिक्स को कॉन्फ़िगरेशन परिवर्तन के बजाय कोड डिप्लॉय की आवश्यकता होती है। **उदाहरण:** एक रिटेलर ने इन-हाउस पासकी टेलीमेट्री बनाने में छह महीने बिताए। जब macOS 15.2 ने उनकी कैपेबिलिटी डिटेक्शन को तोड़ दिया, तो फिक्स को शिप होने में दो सप्ताह लगे - एक पूर्ण फ्रंटएंड डिप्लॉय साइकिल। एक वेंडर समाधान घंटों में सर्वर-साइड को अपडेट कर देता। ### 9.2 एक वेंडर समाधान क्या प्रदान करता है एक विशेष वेंडर हज़ारों कंज्यूमर ऐप्स में डेटा एग्रीगेट करता है। जब कोई Chrome अपडेट किसी विशिष्ट Android वर्ज़न के लिए पासकी निर्माण को तोड़ देता है, तो वेंडर विश्व स्तर पर इसका पता लगाता है और सभी ग्राहकों को अद्यतित एरर क्लासिफिकेशन पुश करता है - इससे पहले कि आपके कंज्यूमर प्रभावित हों। | **क्षमता (Capability)** | **इन-हाउस (In-House)** | **वेंडर समाधान (Vendor Solution)** | | ----------------------- | ------------------------------------------------------------- | -------------------------------------------------------------------------------------------- | | **विज़िबिलिटी** | केवल बैकएंड लॉग; क्लाइंट-साइड छोटा कर दिया गया। | संपूर्ण फ़नल में पूर्ण क्लाइंट-साइड WebAuthn ट्रैकिंग। | | **एरर हैंडलिंग** | मैनुअल लॉग कोरिलेशन; नए कोड प्रतिक्रियात्मक रूप से खोजे गए। | वैश्विक डेटा से ऑटो-अपडेटेड टैक्सोनॉमी; प्लेन-टेक्स्ट मूल कारण। | | **अडॉप्शन टूल्स** | UX अनुमान और A/B परीक्षण। | दुनिया के सबसे बड़े पासकी डेटासेट से कोहोर्ट नज़िंग। | | **रखरखाव** | प्रत्येक OS अपडेट के लिए पार्सर परिवर्तन की आवश्यकता होती है। | वेंडर सभी OS और ब्राउज़र क्विर्क मैपिंग बनाए रखता है। | | **इंसिडेंट रिस्पॉन्स** | कोड रोलबैक। | त्वरित [किल-स्विच](https://www.corbado.com/passkeys-for-banking) और कॉन्फिगरेशन-लेवल फॉलबैक। | वेंडर प्लेटफ़ॉर्म आपको बेंचमार्क करने की सुविधा भी देते हैं: [FIDO Alliance](https://www.corbado.com/glossary/fido-alliance) 93% बेसलाइन सक्सेस रेट की रिपोर्ट करता है। यदि आपका 75% है, तो प्लेटफ़ॉर्म दिखाता है कि आप कहां और क्यों कम प्रदर्शन करते हैं। ## 10. Corbado CIAM के लिए ऑथेंटिकेशन ऑब्जर्वेबिलिटी कैसे प्रदान करता है [Corbado](https://www.corbado.com/) एक रेडी-मेड पासकी ऑब्जर्वेबिलिटी और अडॉप्शन लेयर प्रदान करता है। यह मौजूदा आइडेंटिटी स्टैक - Okta, [Auth0](https://www.corbado.com/blog/auth0-passkeys-analysis), Ory, कस्टम IdPs - में कुछ भी बदले बिना एकीकृत होता है। फ्रंट-एंड SDK लॉगिन जर्नी में विशिष्ट बिंदुओं पर अतुल्यकालिक रूप से JavaScript ईवेंट फ़ायर करता है - पासकी निर्माण, Conditional UI इनवोकेशन, बायोमेट्रिक वेरिफिकेशन, एरर स्टेट्स। यह सबसे सख्त [गोपनीयता आवश्यकताओं](https://www.corbado.com/features) को पूरा करते हुए कभी भी पासवर्ड, प्राइवेट की या PII को नहीं छूता है। प्लेटफ़ॉर्म क्या प्रदान करता है: - **फ़नल एनालिसिस:** दिखाता है कि कंज्यूमर कहाँ ड्रॉप ऑफ करते हैं - ईमेल दर्ज करने से पहले, पासकी प्रॉम्प्ट देखने के बाद, बायोमेट्रिक वेरिफिकेशन के दौरान - [OS, ब्राउज़र और क्रेडेंशियल मैनेजर द्वारा विभाजित](https://www.corbado.com/blog/passkey-analytics)। - **प्लेन-टेक्स्ट डायग्नोस्टिक्स:** WebAuthn एरर कोड्स को मानव-पठनीय स्पष्टीकरणों में अनुवादित करता है ("[Bitwarden](https://www.corbado.com/blog/passkey-analysis-bitwarden-developer-survey-2024) extension intercepted the passkey request") और सिस्टमिक विफलताओं से वन-ऑफ रद्दीकरण को अलग करता है। - **क्रॉस-डिप्लॉयमेंट एरर डेटाबेस:** जब कोई त्रुटि अन्य डिप्लॉयमेंट (जैसे Vivo OS पर टूटा हुआ Conditional UI) में प्रकट होती है, तो प्लेटफ़ॉर्म आपके एनवायरनमेंट के लिए इसे सक्रिय रूप से फ़्लैग करता है - इससे पहले कि आपके कंज्यूमर इस पर हिट करें। - **पूर्ण डिवाइस कवरेज:** [हार्डवेयर सिक्योरिटी की, NFC कार्ड और नेटिव iOS/Android फ़्लो को ट्रैक करता है](https://www.corbado.com/blog/hardware-passkey-adoption-observability), न कि केवल ब्राउज़र-आधारित लॉगिन को। - **रोलआउट सेफ्टी:** डायनामिक किल-स्विच, क्रमिक कोहोर्ट रोलआउट, A/B परीक्षण और [स्मार्ट फॉलबैक रूटिंग](https://www.corbado.com/passkeys-for-banking)। ## 11. निष्कर्ष कंज्यूमर ऑथेंटिकेशन ऑब्जर्वेबिलिटी 5% पर रुकने वाले पासकी अडॉप्शन और आपके अधिकांश यूज़र्स तक पहुंचने वाले अडॉप्शन के बीच का अंतर है। बैकएंड लॉग यह नहीं देख सकते कि कंज्यूमर के डिवाइस पर क्या होता है - और पासकी के लिए, वह जगह है जहाँ 80% विफलताएं होती हैं। एक उद्देश्य-निर्मित [ऑब्जर्वेबिलिटी लेयर](https://www.corbado.com/pricing) को लागू करके, CIAM टीमें अनुमान लगाने से जानने की ओर बढ़ती हैं: कंज्यूमर साइन अप क्यों नहीं करते हैं, कौन से डिवाइस टूटते हैं और कौन से कोहोर्ट आक्रामक रोलआउट के लिए तैयार हैं। ## FAQ ### ऑथेंटिकेशन ऑब्जर्वेबिलिटी क्या है? ऑथेंटिकेशन ऑब्जर्वेबिलिटी संपूर्ण कंज्यूमर लॉगिन जर्नी से टेलीमेट्री एकत्र करने और उसका विश्लेषण करने की प्रथा है - जिसमें क्लाइंट-साइड इवेंट्स शामिल हैं जो किसी भी अनुरोध के बैकएंड तक पहुंचने से पहले होते हैं। यह डिवाइस कैपेबिलिटीज़, क्रेडेंशियल मैनेजर के व्यवहार, बायोमेट्रिक इंटरैक्शन और WebAuthn एरर स्टेट्स पर संदर्भ प्रदान करके पारंपरिक लॉगिंग से आगे जाता है। मानक मॉनिटरिंग के विपरीत जो आपको बताती है कि जब कुछ टूटता है, तो ऑब्जर्वेबिलिटी आपको बताती है कि ऐसा क्यों होता है। ### ऑथेंटिकेशन ऑब्जर्वेबिलिटी मानक लॉगिन एनालिटिक्स से कैसे भिन्न है? मानक लॉगिन एनालिटिक्स (IdP लॉग, [GA4](https://www.corbado.com/blog/tracking-logins-google-analytics-ga4), Mixpanel) केवल सर्वर-साइड परिणाम और मोटे फ्रंटएंड इवेंट जैसे बटन क्लिक कैप्चर करते हैं। ऑथेंटिकेशन ऑब्जर्वेबिलिटी नेटिव ब्राउज़र API कॉल, क्रेडेंशियल मैनेजर इंटरैक्शन और कंज्यूमर के डिवाइस पर बायोमेट्रिक प्रॉम्प्ट के परिणामों को कैप्चर करती है। यह हाई-कार्डिनैलिटी डेटा पासकी द्वारा उत्पन्न—हज़ारों अद्वितीय OS, ब्राउज़र, क्रेडेंशियल मैनेजर और हार्डवेयर संयोजनों—को संभालता है जिन्हें जेनेरिक एनालिटिक्स प्लेटफ़ॉर्म छोटा कर देते हैं या छोड़ देते हैं। ### पासकी डिप्लॉयमेंट कम अडॉप्शन पर क्यों रुक जाते हैं? अधिकांश पासकी डिप्लॉयमेंट 5% और 15% अडॉप्शन के बीच रुक जाते हैं क्योंकि टीमों में क्लाइंट-साइड विफलताओं और प्री-एनरोलमेंट परित्याग में विज़िबिलिटी की कमी होती है। कंज्यूमर्स के पास सक्षम डिवाइस हो सकते हैं लेकिन वे कभी भी पासकी प्रॉम्प्ट नहीं देखते हैं (UI प्लेसमेंट समस्याएँ), प्रतिस्पर्धा करने वाले पासवर्ड मैनेजर ओवरले से भ्रमित हो जाते हैं, या साइलेंट डिवाइस-लेवल बग्स का सामना करते हैं। क्लाइंट-साइड टेलीमेट्री के बिना, ये समस्याएं अदृश्य हैं। ### CIAM में प्री-आइडेंटिफायर ब्लाइंडनेस क्या है? प्री-आइडेंटिफायर ब्लाइंडनेस (Pre-Identifier Blindness) बैकएंड सिस्टम की यह देखने में असमर्थता को संदर्भित करता है कि कंज्यूमर द्वारा अपना ईमेल या यूज़रनेम टाइप करने से पहले क्या होता है। CIAM में, कंज्यूमर तब तक अनाम रहते हैं जब तक वे स्वयं की पहचान नहीं करते। यदि वे उस बिंदु से पहले लॉगिन पेज को छोड़ देते हैं - भ्रमित UI, एक्सटेंशन कॉन्फ्लिक्ट या टूटे हुए Conditional UI के कारण - तो कोई भी बैकएंड लॉग इवेंट को कैप्चर नहीं करता है। ऑथेंटिकेशन ऑब्जर्वेबिलिटी क्लाइंट-साइड साइलेंट फ़ीचर डिटेक्शन के साथ इस अंतर को पाटती है जो पेज लोड होने पर तुरंत चलता है। ### ऑब्जर्वेबिलिटी पासकी अडॉप्शन में कैसे मदद करती है (न कि केवल डिबगिंग में)? ऑब्जर्वेबिलिटी टूटे हुए सेरेमनी का निदान करने से कहीं अधिक काम करती है। यह पहचानती है कि किन कंज्यूमर सेगमेंट में उच्चतम पासकी सक्सेस रेट हैं और डेटा-संचालित नज़िंग को सक्षम बनाती है—हाई-कॉन्फिडेंस डिवाइस कोहोर्ट के लिए ऑटो-ट्रिगरिंग एनरोलमेंट। यह प्रॉम्प्ट करने के सर्वोत्तम क्षणों (जैसे, पासवर्ड रीसेट के बाद जब निराशा ताज़ा हो) को भी प्रकट करती है और डेटा के माध्यम से साबित करती है कि लगातार, नॉन-ब्लॉकिंग प्रॉम्प्टिंग तीसरे या चौथे प्रयास पर भी डबल-डिजिट दर पर कंवर्ट होती है। ### प्रोडक्शन में सबसे आम पासकी विफलताएं क्या हैं? प्रोडक्शन CIAM डिप्लॉयमेंट में सबसे आम विफलताएं हैं: टूटे हुए क्रेडेंशियल मैनेजर कार्यान्वयन (जैसे क्षेत्रीय ओईएम से बजट एंड्रॉइड फोन) के साथ विशिष्ट डिवाइस/OS संयोजन, थर्ड-पार्टी पासवर्ड मैनेजर एक्सटेंशन (Bitwarden, [1Password](https://www.corbado.com/blog/1password-passkeys-best-practices-analysis), [LastPass](https://www.corbado.com/blog/lastpass-data-breach)) WebAuthn कॉल को इंटरसेप्ट करते हैं और चुपचाप विफल हो जाते हैं, साइलेंट OS अपडेट रिग्रेशन जो ब्राउज़र डिवाइस क्षमताओं की रिपोर्ट करने के तरीके को बदलते हैं, और कस्टम-स्टाइल इनपुट फ़ील्ड या CSS विरोधों के कारण Conditional UI रेंडर नहीं हो रहा है।