Passkey Benchmark 2026
العربية

مترجم آليًا من الإنجليزية. عرض الأصل

← جميع المعايير

اكتمال تسجيل الدخول عبر Conditional UI

يقارن اكتمال تسجيل الدخول عبر Conditional UI مسار تسجيل الدخول قبل الخادم عندما يكتب المستخدمون معرفاً مقابل توفر مساعدة مفتاح المرور على مستوى الحقل. ويوضح لماذا قد يبدو نجاح مفتاح المرور على جانب الخادم شبه مثالي بينما يعتمد الأداء الحقيقي لـ Conditional UI على ربط الحقول، واختيار المستخدم، واكتمال تسجيل الدخول النهائي والسرعة.

Q1 2026 · Conditional UI في ثلاث نقاط قياس

أين تفشل Conditional UI فعليًا: نقاط القياس الثلاث

عادةً ما يتم الإبلاغ عن Conditional UI (CUI) برقم واحد: معدل النجاح من جانب الخادم (server-side). يقع هذا الرقم في نهاية المسار ويبدو شبه مثالي. فيما يلي الرقمان السابقان، حيث ينسحب المستخدمون فعليًا.

1 التفاعل الأول مع الاقتراح 55–90% يختار المستخدمون ويكملون أول اقتراح مرئي من مفتاح المرور

هذه هي اللحظة التي تسبق الخادم: الاقتراح مرئي، ويختاره المستخدم، وينتهي تحقق المتصفح. الانخفاض هنا يعني أن المستخدمين يتجاهلون المطالبة، أو يبدلون الحسابات، أو لا يستطيعون إلغاء القفل محليًا، أو ليس لديهم بيانات اعتماد قابلة للاستخدام على الجهاز، أو يتخلون عن العملية قبل وجود طلب موقّع.

2 تسجيل الدخول النهائي عبر مسار CUI 90–95% ينجح تسجيل الدخول بعد تضمين المحاولات المتكررة والبدائل (fallback)

ينجح تسجيل الدخول في النهاية، أحيانًا بعد محاولة CUI أخرى، أو التعبئة التلقائية، أو الكتابة البديلة. هذا هو رقم الإكمال المواجه للمستخدم.

3 المقياس الذي تبلغ عنه معظم الفرق 97–99% ينجح التحقق من الخادم بعد إرسال طلب موقّع

هذا الرقم مفيد لموثوقية الخادم، لكنه يبدأ بعد أن تكون تجربة المستخدم في Conditional UI قد نجحت بالفعل.

أين تتحول Conditional UI إلى تبنٍ فعلي

الرقم الحاسم ليس ما إذا كان المتصفح يدعم Conditional UI، بل هو مدى تكرار رؤية مستخدم حقيقي للاقتراح الصحيح من مفتاح المرور في اللحظة المناسبة، ثم وصوله إلى تسجيل الدخول دون ارتباك في الحساب، أو تحويلات عبر مدير كلمات المرور، أو لجوء إلى بديل يدوي.

المنصة حصة اقتراح مفتاح المرور ما يعنيه ذلك
macOS مرتفع الاقتراحات مرئية في معظم الإدخالات المدعومة.
Windows منخفض يمتلك عدد أقل من مستخدمي سطح المكتب مفتاح المرور محلي قابل للاستخدام، لذا يتم تشغيل CUI بشكل أقل.

استخدم هذه الإشارات لقراءة عملية النشر الخاصة بك.

حصة اقتراح منخفضة فجوة الأهلية

ابحث عن نقص في تغطية بيانات الاعتماد، أو مفاتيح المرور على جهاز آخر، أو ربط حقول غير صحيح، أو تراكبات مدير كلمات المرور، أو عدم تطابق في سياق RP/الحساب، أو عملية إطلاق لم تبنِ قاعدة بيانات اعتماد كافية بعد.

إكمال غير مباشر فجوة التوجيه

لا يزال المستخدمون يسجلون الدخول، ولكن ليس بشكل مباشر. هدف التحسين هو السرعة والمباشرة: تقليل تحويلات المعرّفات (identifier detours)، ودعم الاسترداد، واستخدام جهاز معترف به أو الدخول بنقرة واحدة (one-tap entry) عندما يكون السياق قويًا بما يكفي.

  1. يتم دمج إكمال تسجيل الدخول النهائي عبر التفاعلات اللاحقة ضمن نفس عملية تسجيل الدخول: يمكن للمستخدمين تبديل الحسابات، أو تجاهل مطالبة، أو إعادة محاولة CUI، أو اللجوء للكتابة قبل أن يكتمل تسجيل الدخول في النهاية.
  2. يتم قبول تأكيد Conditional UI الصالح بشكل شبه دائم من جانب الخادم (server-side)؛ تكمن فجوة القياس قبل وجود التأكيد (assertion). لذلك تبدو التقارير المقتصرة على الخادم أكثر إيجابية من تجربة إدخال تسجيل الدخول الحقيقية.
  3. تعتمد حصة Conditional UI ضمن الدخول المساعد (assisted entry) على مزيج أجهزة النشر ومدة إطلاق المنتج الفعلي. غالبًا ما تُظهر عمليات النشر على سطح مكتب Windows قاعدة اقتراحات محلية أصغر لأن العديد من المستخدمين يحتفظون بما لديهم من مفاتيح المرور القابلة للاستخدام على هواتفهم بدلاً من الجهاز الحالي.
  4. يعد سلوك التعبئة التلقائية السليم شرطًا أساسيًا لنجاح Conditional Create. راجع Conditional Create Rate للعرض العكسي، حيث تتنبأ جودة التعبئة التلقائية بمدى تكرار إنشاء مفتاح المرور تلقائيًا بعد تسجيل الدخول الناجح بكلمة المرور.
مصادر ذات صلة

قراءات إضافية

أبحاث Corbado منتقاة ومراجع أساسية.

← جميع المعايير