---
url: 'https://www.corbado.com/th/passkey-benchmark-2026/conditional-ui-usage'
title: 'เกณฑ์มาตรฐานการเข้าสู่ระบบสำเร็จด้วย Conditional UI'
description: 'เกณฑ์มาตรฐานการเข้าสู่ระบบด้วย Conditional UI แสดงให้เห็นว่าการแนะนำพาสคีย์ส่งผลต่อความสำเร็จในการเข้าสู่ระบบบนเดสก์ท็อปอย่างไร'
lang: 'th'
dir: 'ltr'
keywords: 'Conditional UI, ป้อนอัตโนมัติด้วยพาสคีย์, conditional mediation, การเข้าสู่ระบบสำเร็จด้วยพาสคีย์'
---

# ความสำเร็จในการเข้าสู่ระบบด้วย Conditional UI

*แปลอัตโนมัติจากภาษาอังกฤษ ดู[ต้นฉบับ](https://www.corbado.com/passkey-benchmark-2026/conditional-ui-usage.md) →*

[← เบนช์มาร์กทั้งหมด](https://www.corbado.com/th/passkey-benchmark-2026.md)

ความสำเร็จในการเข้าสู่ระบบด้วย Conditional UI เป็นการเปรียบเทียบเส้นทางการเข้าสู่ระบบก่อนถึงเซิร์ฟเวอร์ ระหว่างตอนที่ผู้ใช้พิมพ์ตัวระบุกับตอนที่มีตัวช่วยพาสคีย์ในระดับฟิลด์ ซึ่งแสดงให้เห็นว่าทำไมความสำเร็จของพาสคีย์ฝั่งเซิร์ฟเวอร์ถึงดูเกือบสมบูรณ์แบบ ทั้งที่ประสิทธิภาพที่แท้จริงของ Conditional UI นั้นขึ้นอยู่กับการผูกฟิลด์ ตัวเลือกของผู้ใช้ ความสำเร็จในการเข้าสู่ระบบขั้นสุดท้าย และความเร็ว

## จุดที่ Conditional UI ล้มเหลวจริงๆ: จุดวัดผลสามจุด

*Q1 2026 · Conditional UI ณ จุดวัดผลสามจุด*

Conditional UI (CUI) มักถูกรายงานเป็นตัวเลขเดียว: อัตราความสำเร็จฝั่งเซิร์ฟเวอร์ ตัวเลขนั้นอยู่ท้ายสุดของโฟลว์และดูเหมือนจะสมบูรณ์แบบ ตัวเลขก่อนหน้าสองจุด ซึ่งเป็นจุดที่ผู้ใช้ drop out ไปจริงๆ อยู่ด้านล่างนี้

1. **การโต้ตอบกับข้อเสนอแนะแรก** — *55–90%*. ผู้ใช้เลือกและดำเนินการตามข้อเสนอแนะพาสคีย์แรกที่มองเห็นจนเสร็จ. นี่คือช่วงเวลาก่อนถึงเซิร์ฟเวอร์: ข้อเสนอแนะปรากฏขึ้น ผู้ใช้เลือก และเบราว์เซอร์ยืนยันเสร็จสิ้น การ Drop-off ที่นี่หมายถึงผู้ใช้ปิดหน้าต่าง, สลับบัญชี, ไม่สามารถปลดล็อคเครื่องได้, ไม่มี credential ที่ใช้ได้บนอุปกรณ์ หรือล้มเลิกก่อนที่จะเกิด signed request
2. **การล็อกอินบนเส้นทาง CUI ครั้งสุดท้าย** — *90–95%*. ล็อกอินสำเร็จหลังจากรวมการลองใหม่และการใช้ช่องทางสำรอง. ในที่สุดการล็อกอินก็สำเร็จ บางครั้งหลังจากพยายามใช้ CUI อีกครั้ง, autofill หรือพิมพ์ผ่านช่องทางสำรอง นี่คือตัวเลขความสำเร็จในมุมมองของผู้ใช้
3. **ตัวชี้วัดที่ทีมส่วนใหญ่รายงาน** — *97–99%*. การตรวจสอบฝั่งเซิร์ฟเวอร์สำเร็จหลังจากส่ง signed request แล้ว. ตัวเลขนี้มีประโยชน์สำหรับวัดความน่าเชื่อถือของเซิร์ฟเวอร์ แต่มันเริ่มนับหลังจากที่ประสบการณ์ผู้ใช้ Conditional UI ทำงานสำเร็จไปแล้ว

### เปรียบเทียบหลัก: ป้อนเอง (manual) vs มีตัวช่วย (assisted)

| เบราว์เซอร์ | สมบูรณ์ (แมนนวล) | สมบูรณ์ (ตัวช่วย) | Δ ตัวช่วย | ลองใหม่แบบแมนนวล 5 นาที | ลองใหม่พร้อมตัวช่วย 5 นาที |
| --- | --- | --- | --- | --- | --- |
| macOS Chrome | 86% | 91% | +4pp | 25% | 32% |
| macOS Safari | 83% | 91% | +9pp | 23% | 23% |
| Windows Chrome | 87% | 89% | +2pp | 22% | 24% |
| Windows Edge | 86% | 88% | +2pp | 21% | 21% |

### รายละเอียดแบบมีตัวช่วย (Assisted-entry)

| เบราว์เซอร์ | สัดส่วน CUI ในกลุ่มมีตัวช่วย | ความสำเร็จแบบสมบูรณ์ของ CUI | Autofill ที่ได้รับการปกป้อง | Autofill ที่ไม่ได้รับการปกป้อง |
| --- | --- | --- | --- | --- |
| macOS Chrome | 28% | 94% | 91% | 89% |
| macOS Safari | 49% | 94% | 87% | 89% |
| Windows Chrome | 11% | 94% | 86% | 89% |
| Windows Edge | 9% | 94% | 86% | 88% |

### จุดที่ Conditional UI เปลี่ยนเป็น Adoption

ตัวเลขที่ชี้วัดจริงๆ ไม่ใช่การที่เบราว์เซอร์รองรับ Conditional UI หรือไม่ แต่มันคือความถี่ที่ผู้ใช้จริงเห็นข้อเสนอแนะพาสคีย์ที่ถูกต้องในเวลาที่เหมาะสม แล้วเข้าสู่การล็อกอินโดยไม่สับสนบัญชี, ไม่โดนโปรแกรมจัดการรหัสผ่านขัดจังหวะ หรือต้องเปลี่ยนไปใช้ช่องทางสำรองด้วยตนเอง

ใช้สัญญาณเหล่านี้เพื่อประเมินการนำไปใช้งานของคุณ

- **สัดส่วนข้อเสนอแนะต่ำ** (ช่องว่างคุณสมบัติ): ให้ตรวจสอบความครอบคลุมของ credential ที่หายไป, พาสคีย์ที่อยู่บนอุปกรณ์อื่น, การเชื่อมโยงฟิลด์ไม่ถูกต้อง, หน้าต่างซ้อนทับจากโปรแกรมจัดการรหัสผ่าน, ความไม่ตรงกันของบริบท RP/บัญชี หรือการเปิดใช้งานที่ยังสร้างฐาน credential ไม่มากพอ
- **การสำเร็จทางอ้อม** (ช่องว่างการกำหนดเส้นทาง): ผู้ใช้ยังคงล็อกอินได้ แต่ไม่ใช่โดยตรง เป้าหมายของการเพิ่มประสิทธิภาพคือความเร็วและความตรงไปตรงมา: ลดการเบี่ยงเบนของ identifier, รองรับการกู้คืน และใช้ entry แบบ recognized-device หรือ one-tap ในจุดที่บริบทชัดเจนพอ

### หมายเหตุ

1. ความสำเร็จของการล็อกอินขั้นสุดท้ายรวมเอาการโต้ตอบที่ตามมาในกระบวนการล็อกอินเดียวกัน: ผู้ใช้สามารถสลับบัญชี, ปิด prompt, ลองใช้ CUI อีกครั้ง หรือเปลี่ยนไปใช้วิธีพิมพ์ช่องทางสำรองก่อนที่จะล็อกอินสำเร็จในที่สุด
2. Conditional UI assertion ที่ถูกต้องแทบจะได้รับการยอมรับจากฝั่งเซิร์ฟเวอร์เสมอ ช่องว่างของการวัดผลนั้นอยู่ก่อนที่ assertion จะเกิดขึ้น การรายงานผลเฉพาะจากเซิร์ฟเวอร์จึงดูดีกว่าประสบการณ์การเข้าสู่ระบบที่เกิดขึ้นจริง
3. สัดส่วนของ Conditional UI ใน assisted entry ขึ้นอยู่กับความหลากหลายของอุปกรณ์ในการใช้งานและระยะเวลาที่ผลิตภัณฑ์เปิดให้บริการ การใช้งานบนเดสก์ท็อป Windows มักแสดงฐานข้อเสนอแนะในเครื่องที่น้อยกว่า เนื่องจากผู้ใช้หลายคนเก็บพาสคีย์ที่ใช้ได้ไว้บนโทรศัพท์มากกว่าบนอุปกรณ์ปัจจุบัน
4. พฤติกรรม autofill ที่ดีเป็นเงื่อนไขสำคัญสำหรับ Conditional Create ที่มีประสิทธิภาพ ดู [Conditional Create Rate](/th/passkey-benchmark-2026/conditional-create.md) สำหรับมุมมองในทางกลับกัน ที่คุณภาพของ autofill จะคาดการณ์ความถี่ในการสร้างพาสคีย์โดยอัตโนมัติหลังจากการล็อกอินด้วยรหัสผ่านสำเร็จ

## อ่านเพิ่มเติม

งานวิจัย Corbado ที่คัดสรรมาและเอกสารอ้างอิงหลัก

- **การใช้งาน · web.dev** — [Sign in with a passkey through form autofill](https://web.dev/articles/passkey-form-autofill) — คู่มือการใช้งานของ Google สำหรับ Conditional UI ในแบบฟอร์มชื่อผู้ใช้และรหัสผ่านที่มีอยู่
- **Conditional UI · Corbado blog** — [WebAuthn Conditional UI Passkeys & Autofill](https://www.corbado.com/blog/webauthn-conditional-ui-passkeys-autofill) — คำอธิบายเชิงปฏิบัติเกี่ยวกับการป้อนพาสคีย์อัตโนมัติ การประสานงานแบบมีเงื่อนไข และการผูกฟิลด์ตัวระบุ
- **การรองรับอุปกรณ์ · passkeys.dev** — [Passkey Device Support](https://passkeys.dev/device-support/) — เมทริกซ์ความเข้ากันได้สำหรับพฤติกรรมการป้อนพาสคีย์อัตโนมัติและเข้าสู่ระบบข้ามแพลตฟอร์มและเบราว์เซอร์

[← เบนช์มาร์กทั้งหมด](https://www.corbado.com/th/passkey-benchmark-2026.md)

---

*เกณฑ์มาตรฐานประจำปีสำหรับความพร้อม การสร้าง การใช้งาน และกลยุทธ์การนำพาสคีย์มาใช้ โดย Corbado แพลตฟอร์มวิเคราะห์ข้อมูลพาสคีย์สำหรับทีม CIAM [เรียนรู้เพิ่มเติม →](https://www.corbado.com).*