Rào cản đăng nhập giết chết tỷ lệ chuyển đổi: 5 triệu chứng và cách khắc phục

Whitepaper analytics xác thực. Hướng dẫn thực tế, mẫu triển khai và KPI cho chương trình passkeys.

Nhận whitepaper

Nếu bạn là một giám đốc sản phẩm (Product Manager) chịu trách nhiệm về xác thực, có thể bạn đã từng nghe: "Tại sao tỷ lệ chuyển đổi của chúng ta lại dậm chân tại chỗ?" Những "nghi phạm" thông thường sẽ bị đổ lỗi: chi phí quảng cáo, thời gian tải trang, trải nghiệm người dùng (UX) khi thanh toán. Nhưng có một bước trong phễu khó chẩn đoán hơn: quá trình đăng nhập.

Hầu hết các hệ thống phân tích đều coi xác thực là hệ nhị phân: đã đăng nhập hoặc chưa. Chúng không ghi nhận rào cản xác thực nằm ở giữa: người dùng đã thử ba mật khẩu rồi thoát, người có mã SMS đến chậm 45 giây, hay khách hàng cũ không thể nhớ liệu họ đã dùng "Đăng nhập bằng Google" hay tạo mật khẩu.

Điểm mù này rất tốn kém. Tỷ lệ từ bỏ giỏ hàng trung bình vào khoảng 70% và một phần đáng kể bắt nguồn từ rào cản đăng nhập. Không giống như việc từ bỏ thanh toán (điều mà mọi nhóm thương mại điện tử đều ám ảnh), các lỗi đăng nhập thường không được đo lường và khắc phục.

Tác động này mang tính cộng gộp: mỗi lần đăng nhập thất bại là sự lãng phí chi phí thu hút khách hàng (CAC), giảm giá trị vòng đời khách hàng (CLTV) và khách hàng có thể chuyển sang đối thủ cạnh tranh cung cấp đăng nhập không rào cản. Nếu bạn không thể đo lường nó, bạn không thể cải thiện nó.

Trước khi đi sâu hơn, hãy xem xét điều này: Nếu giảm vài phần trăm tỷ lệ bỏ ngang đăng nhập đồng nghĩa với việc tăng thêm doanh thu 6 con số (USD) hàng năm cho một công ty thương mại điện tử lớn, thì điều đó có ý nghĩa gì đối với công ty của bạn?

Nếu dữ liệu đó không tồn tại trong hệ thống phân tích của bạn, bạn đã xác định được triệu chứng đầu tiên của một vấn đề sâu xa hơn: bạn đang "nhắm mắt bay" trong việc xác thực.

Mỗi bước xác thực là một khoản thuế đánh vào ý định của người dùng. Câu hỏi đặt ra là: bạn có biết mình đang tính phí bao nhiêu không?

Hãy xem xét điều gì xảy ra khi một người dùng cũ muốn hoàn tất giao dịch mua hàng:

1. Họ thử mật khẩu thông thường. Sai.
2. Họ thử một biến thể khác. Vẫn sai.
3. Bây giờ họ đang ở điểm quyết định: đặt lại mật khẩu (mất 5+ phút rào cản) hoặc từ bỏ giỏ hàng (2 giây).

Đối với hầu hết người dùng, sự từ bỏ sẽ chiến thắng. Và hệ thống phân tích của bạn chỉ hiển thị tỷ lệ thoát (bounce), chứ không phải nguyên nhân gốc rễ.

"Thuế đăng nhập" này cộng dồn vào thời điểm tồi tệ nhất: lúc thanh toán. Người dùng đã đầu tư thời gian duyệt, so sánh, thêm vào giỏ hàng. Họ đã sẵn sàng trả tiền. Sau đó, rào cản xác thực ập đến và khối lượng nhận thức vượt quá động lực của họ.

graph TD
    A[Người dùng cũ tại trang thanh toán] --> B{Thử mật khẩu thông thường};
    B -- Thất bại --> C{Thử biến thể mật khẩu};
    C -- Thất bại --> D[Điểm quyết định có rào cản cao];
    D -- Con đường ít trở ngại nhất --> E["Từ bỏ giỏ hàng (2 giây)"];
    D -- Con đường nhiều trở ngại nhất --> F["Bắt đầu đặt lại mật khẩu (5+ phút)"];
    F --> G{Đặt lại thành công?};
    G -- Không --> E;
    G -- Có --> H[Quay lại thanh toán & Đăng nhập];

    style E fill:#ffcccc,stroke:#ff0000,stroke-width:2px,color:#990000
    style D fill:#fff4e6,stroke:#ff9900,stroke-width:2px

Những gì bài viết này đề cập: Bài viết này phân tích thực tế về 5 lỗi xác thực giết chết tỷ lệ chuyển đổi và cách chẩn đoán chúng trong phễu của chính bạn. Mỗi phần bao gồm những gì cần đo lường, nguyên nhân gốc rễ thường là gì và cách khắc phục ra sao. Mục tiêu là cung cấp cho bạn dữ liệu để xây dựng bài toán kinh doanh cho đầu tư vào xác thực và lộ trình để thực thi nó một cách hiệu quả.

Cách phát hiện: Theo dõi sự chênh lệch (delta) giữa login_modal_opened (mở modal đăng nhập) và login_successful (đăng nhập thành công). Nếu bạn thấy tỷ lệ bỏ ngang +20% trước khi quá trình xác thực hoàn tất, phần này áp dụng cho bạn.

Tại sao điều này quan trọng: Đây là thời điểm có ý định cao nhất trong phễu của bạn. Người dùng đạt đến bước đăng nhập đã quyết định tương tác: họ chỉ cách chuyển đổi một bước. Mất họ ở đây có tác động ROI tồi tệ nhất trong bất kỳ giai đoạn phễu nào.

Mô hình "bắt buộc đăng ký" là một kẻ hủy diệt chuyển đổi tàn bạo. Tại bước thanh toán, người dùng đã đầu tư thời gian duyệt web và so sánh. Việc buộc tạo tài khoản vào đúng thời điểm họ muốn thanh toán sẽ tạo ra rào cản tối đa ở mức ý định tối đa. Passkey có thể giúp giải quyết vấn đề này - hãy xem cách passkey tăng tỷ lệ chuyển đổi bằng cách đạt 93% đăng nhập thành công so với 63% của mật khẩu.

Để có phân tích chi tiết về thanh toán với tư cách khách (guest checkout) so với bắt buộc đăng nhập, hãy xem bài viết chuyên dụng của chúng tôi.

Đăng nhập bằng mạng xã hội (ví dụ: "Đăng nhập bằng Google", "Tiếp tục với Apple") về lý thuyết sẽ làm giảm rào cản. Nhưng việc triển khai kém sẽ tạo ra những vấn đề đăng nhập mới:

Nếu các nút này bị ẩn dưới màn hình hiển thị đầu tiên (below the fold), được hiển thị theo cách cho thấy chúng là tùy chọn phụ hoặc kém hơn, hoặc nếu chúng thiếu các "phạm vi" (scopes) phù hợp (yêu cầu quá nhiều dữ liệu), người dùng sẽ bị đẩy lại vào con đường dùng mật khẩu đầy rào cản.

Hơn nữa, "hiệu ứng NASCAR", nơi một màn hình lộn xộn với biểu trưng của mọi nhà cung cấp danh tính có thể có (Google, Facebook, Apple, v.v.), có thể dẫn đến chứng tê liệt quyết định. Ngược lại, việc chỉ cung cấp một tùy chọn mà người dùng không sử dụng (ví dụ: chỉ cung cấp đăng nhập Facebook khi khách hàng của bạn chủ yếu sử dụng thiết bị Apple) sẽ tạo ra ngõ cụt. Lựa chọn thiết kế thường bắt nguồn từ mong muốn sai lầm là "sở hữu thông tin xác thực" (buộc dùng mật khẩu cục bộ), vô tình làm tăng tỷ lệ bỏ ngang bằng cách đẩy người dùng về phía con đường nhiều trở ngại nhất.

Trên thiết bị di động, nơi không gian màn hình bị hạn chế và việc gõ phím dễ bị lỗi, bức tường bắt buộc đăng nhập thậm chí còn nguy hiểm hơn. Điền vào một biểu mẫu đăng ký có nhiều trường trên bàn phím điện thoại thông minh là một hoạt động có rào cản cao. Nếu nút "Đăng ký" không dễ dàng truy cập thông qua giải pháp "One-Tap" hoặc nếu biểu mẫu không hỗ trợ các thuộc tính tự động điền (autofill) một cách chính xác, tỷ lệ bỏ ngang sẽ tăng vọt so với máy tính để bàn. Khoảng cách giữa lưu lượng truy cập trên thiết bị di động (cao) và chuyển đổi trên thiết bị di động (thấp) thường được giải thích là do sự khó khăn tuyệt đối khi điều hướng những bức tường đăng nhập này trên màn hình 6 inch.

Cách phát hiện: Tỷ lệ đặt lại mật khẩu theo % tổng số lần thử đăng nhập. Con số trên 10% có nghĩa là sự mệt mỏi với mật khẩu đang làm tổn hại đến tỷ lệ chuyển đổi đăng nhập.

Tại sao điều này quan trọng: Tỷ lệ đặt lại mật khẩu là chỉ báo về những người dùng thất vọng. Mỗi lần đặt lại nghĩa là một người dùng muốn tham gia nhưng không thể đăng nhập.

Tỷ lệ đặt lại mật khẩu đo lường trực tiếp rào cản xác thực. Khi người dùng cũ nhìn thấy "Mật khẩu không chính xác", họ sẽ thử các biến thể khác. Nếu thất bại: bắt đầu đặt lại mật khẩu hoặc từ bỏ.

graph LR
    Step1(1. Nhấp vào 'Quên mật khẩu') --> Step2(2. Nhập Email);
    Step2 --> Step3{3. Chờ Email \n Độ trễ biến đổi};
    Step3 --Đến muộn--> DropOff1[Bỏ ngang: Mất tập trung/Mất kiên nhẫn];
    Step3 --Đã đến--> Step4(4. Chuyển ngữ cảnh sang Ứng dụng Email);
    Step4 --> Step5{5. Tìm Email \n Spam/Quảng cáo?};
    Step5 --Bị chôn vùi--> DropOff2[Bỏ ngang: Không tìm thấy email];
    Step5 --Tìm thấy--> Step6(6. Nhấp vào Liên kết Đặt lại);
    Step6 --> Step7{7. Tạo Mật khẩu Mới \n Quy tắc độ phức tạp};
    Step7 --Trượt quy tắc/Kiểm tra lịch sử--> DropOff3[Bỏ ngang: Thất vọng/Thoát do bực tức];
    Step7 --Thành công--> Step8(8. Xác nhận Mật khẩu);
    Step8 --> Step9(9. Quay lại Màn hình Đăng nhập);
    Step9 --> Step10(10. Nhập Thông tin xác thực mới);
    Step10 --> Success(Quay lại Thanh toán);

    style DropOff1 fill:#ffdede,stroke:none,color:#cc0000
    style DropOff2 fill:#ffdede,stroke:none,color:#cc0000
    style DropOff3 fill:#ffdede,stroke:none,color:#cc0000
    linkStyle 2,5,8 stroke:#cc0000,stroke-width:2px,stroke-dasharray: 5 5;

Khoảng 19% người dùng từ bỏ giỏ hàng do họ quên mật khẩu. Mỗi bước là một điểm bỏ ngang. Đến bước 5 (tìm email trong thư rác), bạn đã mất đi một lượng lớn người dùng.

Gần 50% người dùng sẽ từ bỏ nếu được thông báo rằng mật khẩu mới của họ không được trùng với mật khẩu cũ. Việc "kiểm tra lịch sử" này ngăn chặn cơ chế đối phó của người dùng đối với sự mệt mỏi về mật khẩu: tái sử dụng. Không có phương án thay thế xác thực ít rào cản (như passkey), người dùng sẽ tự tạo ngay những mật khẩu mà họ sẽ quên, đảm bảo rằng vòng luẩn quẩn này lặp lại.

Forrester ước tính tốn 70 USD cho mỗi lần đặt lại mật khẩu cần sự can thiệp của con người. Đối với các doanh nghiệp lớn, con số này lên tới hàng triệu đô la mỗi năm.

Chi phí vô hình còn tồi tệ hơn: những người dùng cũ thất vọng muốn mua hàng nhưng bị khóa tài khoản. Vòng lặp đặt lại mật khẩu là một "vết thương tự gây ra" lên tỷ lệ chuyển đổi.

Trớ trêu thay, rào cản của mật khẩu lại dẫn đến tính bảo mật yếu hơn. Vì người dùng cảm thấy thất vọng, họ phải dùng đến các hành vi nguy hiểm: viết mật khẩu ra giấy, sử dụng "Password123" hoặc chia sẻ thông tin xác thực. 46% người tiêu dùng Mỹ không thể hoàn tất giao dịch do lỗi xác thực và lỗi này thúc đẩy họ đến với các đối thủ cạnh tranh có thể mang lại trải nghiệm đăng nhập liền mạch. Mật khẩu đã trở thành vector chính cho cả các vi phạm bảo mật (thông qua nhồi thông tin xác thực) và vi phạm chuyển đổi (thông qua việc từ bỏ).

Cách phát hiện: Theo dõi quy trình yêu cầu OTP, gửi OTP và OTP thành công. Nếu thời gian gửi >30 giây hoặc nếu bạn có tỷ lệ thất bại >5%, thì SMS OTP đang gặp sự cố về chuyển đổi.

Tại sao điều này quan trọng: SMS OTP đánh đổi một vấn đề về trí nhớ lấy một vấn đề về việc phân phối. Các kiểu lỗi này vô hình: bạn chỉ thấy tỷ lệ bỏ ngang, chứ không thấy người dùng đang nhìn chằm chằm vào điện thoại của họ chờ một mã không bao giờ đến. Tồi tệ hơn: chi phí SMS tăng theo mức sử dụng, do đó bạn đang phải trả tiền cho rào cản xác thực.

Lỗ hổng cơ bản của xác thực bằng SMS là sự phụ thuộc vào mạng điện thoại (SS7) vốn chưa bao giờ được thiết kế cho xác thực thời gian thực. Việc phân phối phụ thuộc vào các công ty trung gian (aggregators), nhà mạng và các thỏa thuận chuyển vùng. Một sự cố có nghĩa là người dùng đang nhìn chằm chằm vào màn hình, chờ đợi một đoạn mã không bao giờ đến.

Gian lận bơm SMS (SMS pumping fraud) đã kích hoạt tính năng lọc thư rác chủ động của nhà mạng. Các mã OTP hợp pháp vẫn bị chặn, đặc biệt đối với người dùng quốc tế. Một người dùng ở Đức đăng ký dịch vụ của Mỹ có thể không bao giờ nhận được mã.

SMS OTP buộc người dùng phải rời khỏi quy trình thanh toán, mở ứng dụng Tin nhắn, ghi nhớ mã và quay lại. Trên các hệ thống quản lý bộ nhớ cứng nhắc, việc tải lại này đặt lại hoàn toàn quy trình thanh toán, xóa trắng dữ liệu biểu mẫu.

Mặc dù tính năng "Tự động điền OTP" (Auto-fill OTP) trên iOS và Android có thể giúp ích, nhưng tính năng này thường thất bại nếu định dạng SMS không khớp với các quy tắc kinh nghiệm của hệ điều hành.

Cách phát hiện: So sánh tỷ lệ chuyển đổi theo loại thiết bị. Nếu lưu lượng truy cập trên thiết bị di động chiếm hơn 70% nhưng tỷ lệ chuyển đổi tụt hậu so với máy tính để bàn 30%+, điều đó có thể đồng nghĩa với việc có một số rào cản xác thực trên nhiều thiết bị. Đồng thời kiểm tra tỷ lệ hết thời gian phiên (session timeout) tại lúc thanh toán.

Tại sao điều này quan trọng: Người dùng duyệt bằng thiết bị di động nhưng thường mua bằng máy tính để bàn. Nếu trạng thái xác thực không chuyển được, bạn đang buộc họ phải đăng nhập lại vào thời điểm tồi tệ nhất. Việc chủ động hết hạn phiên (do bộ phận bảo mật/tuân thủ thiết lập) sẽ giết chết chuyển đổi giữa lúc thanh toán hoặc giữa hai lần truy cập.

"Khoảng cách chéo thiết bị" (cross-device gap) là một hiện tượng được ghi nhận rất rõ ràng trong thương mại điện tử. Lưu lượng truy cập di động chiếm khoảng 75% số lượt truy cập, nhưng tỷ lệ chuyển đổi trên di động (khoảng 2%) tụt hậu đáng kể so với tỷ lệ chuyển đổi trên máy tính để bàn (khoảng 3%). Mặc dù kích thước màn hình đóng một vai trò quan trọng, nhưng một yếu tố chính góp phần vào khoảng cách này là việc không thể chuyển trạng thái xác thực một cách liền mạch.

Hãy xem xét một tình huống phổ biến: Một người dùng trên điện thoại thông minh nhấp vào một quảng cáo, duyệt qua cửa hàng và thêm các mặt hàng vào giỏ hàng. Họ đang duyệt với tư cách "khách". Họ quyết định hoàn tất giao dịch mua trên laptop, nơi dễ dàng nhập thông tin thẻ tín dụng hơn. Khi mở trang web trên máy tính để bàn, giỏ hàng của họ trống rỗng. Để lấy lại giỏ hàng, họ phải đăng nhập. Tuy nhiên, nếu họ tạo tài khoản trên thiết bị di động, họ có thể đã sử dụng tính năng "Đề xuất mật khẩu", tạo ra một chuỗi phức tạp mà họ chưa từng thấy. Bây giờ, trên máy tính để bàn Windows, họ không biết mật khẩu.

Họ thực sự bị khóa khỏi chính ý định mua hàng của mình. Họ phải bắt đầu đặt lại mật khẩu trên máy tính để bàn, hệ thống sẽ gửi email đến điện thoại của họ, buộc phải có một vòng lặp chuyển đổi thiết bị cồng kềnh, điều này thường dẫn đến việc từ bỏ. Rào cản để thu hẹp khoảng cách vật lý (air gap) giữa thiết bị di động và máy tính để bàn là quá cao.

Thời gian hết hạn phiên thường do các nhóm bảo mật/tuân thủ thiết lập (PCI-DSS, v.v.) mà không có ý kiến đầu vào từ bộ phận sản phẩm. Thời gian hết hạn 15 phút nghe có vẻ hợp lý cho đến khi bạn nhận ra "không hoạt động" đối với máy chủ là "đang tìm mã giảm giá" hoặc "đang kiểm tra giá của đối thủ cạnh tranh" đối với người dùng.

Điều này xảy ra sau khi người dùng đã cam kết. Việc bị từ chối giống như một sự trừng phạt. Không có tính năng tự động lưu dữ liệu biểu mẫu, họ phải nhập lại mọi thứ. 60% người tiêu dùng cho rằng sự thất vọng khi đăng nhập (bao gồm cả lỗi hết thời gian) là lý do hoàn toàn từ bỏ giỏ hàng.

Cách phát hiện: Kiểm tra xem tỷ lệ kích hoạt MFA tăng vọt sau một sự cố bảo mật hay không. Tìm kiếm các đợt gia tăng đột ngột của việc chặn "hoạt động đáng ngờ" tương quan với sự sụt giảm chuyển đổi. Khảo sát bộ phận hỗ trợ khách hàng để biết số lượng ticket "Tôi không thể đăng nhập".

Tại sao điều này quan trọng: Các nhóm bảo mật và sản phẩm thường hoạt động theo các phòng ban riêng biệt (silos). Sau một cuộc tấn công nhồi thông tin xác thực hoặc đợt kiểm toán tuân thủ, nhóm bảo mật thêm rào cản (ví dụ: bắt buộc MFA, tính điểm rủi ro chủ động) mà không có tầm nhìn về tác động đến chuyển đổi. Kết quả: gian lận giảm, nhưng doanh thu cũng giảm theo. Mục tiêu là tìm ra các phương pháp (như passkey) vừa bảo mật hơn vừa ít rào cản hơn.

Khi người dùng báo cáo "Tôi không thể đăng nhập", việc chẩn đoán mất bao lâu? Nếu bạn thiếu hệ thống ghi nhận về xác thực, bạn sẽ giống như "nhắm mắt bay".

Tỷ lệ thành công 90% có thể che giấu 50% thất bại đối với người dùng di động. Hãy chia nhỏ theo:

• Thiết bị/Trình duyệt: Chrome trên Android bị lỗi trong khi Safari trên iOS thành công cho thấy một lỗi cụ thể.
• Phương thức xác thực: Nếu mật khẩu có tỷ lệ thành công 90% nhưng đăng nhập mạng xã hội có 60%, hãy tập trung vào việc triển khai đăng nhập mạng xã hội.
• Điểm chạm đầu vào: Nếu đăng nhập trên header có tỷ lệ thành công 95% nhưng đăng nhập tại trang thanh toán có 70%, thì quy trình thanh toán có rào cản riêng.
• Mới so với cũ: Người dùng mới thất bại cho thấy vấn đề đăng ký; người dùng cũ thất bại cho thấy sự cố về mật khẩu/phiên.
• Khu vực/Thị trường: Tùy chọn đăng nhập qua mạng xã hội khác nhau rất lớn (Facebook mạnh ở Mỹ, Kakao/Naver ở Hàn Quốc, Google thống trị ở châu Âu). Độ tin cậy trong việc phân phối SMS cũng thay đổi tùy theo nhà cung cấp và quốc gia.

Để có phép đo toàn diện, hãy xem sổ tay phân tích xác thực của chúng tôi.

Bạn không cần phải loại bỏ nhà cung cấp danh tính (Identity Provider) hiện tại của mình (Auth0, Cognito, ForgeRock, Ping) để cải thiện. Các bản sửa lỗi UX có tác động cao có thể được thực hiện chỉ trong một chu kỳ (sprint).

• Hiện Mật khẩu: "Hiển thị Mật khẩu" (biểu tượng con mắt) giúp giảm bớt các lỗi đăng nhập do lỗi gõ phím trên thiết bị di động
• Tùy chọn Đăng nhập Bền vững: Nếu người dùng trước đây đã sử dụng Google, hãy làm nổi bật nút Google. Huy hiệu "Gần đây bạn đã sử dụng Google" giúp giảm thiểu khối lượng nhận thức
• Xác thực Trực tiếp (Inline Validation): Xác thực các yêu cầu về mật khẩu theo thời gian thực, không phải lúc gửi
• Mở rộng Phiên: Chỉ hết thời gian cho các hành động nhạy cảm, không phải khi duyệt sản phẩm
• Tự động Tập trung (Auto-Focus): Con trỏ chuột nằm sẵn ở trường email khi mở modal đăng nhập, bật đúng loại bàn phím trên thiết bị di động

Các tinh chỉnh về UX cũng có ích, nhưng đòn bẩy lớn nhất là loại bỏ hoàn toàn mật khẩu. Passkey giải quyết các Triệu chứng 1, 2, 3 và 5:

• Không cần gõ: Face ID/Touch ID/Windows Hello - không có mật khẩu nào để quên
• Không có độ trễ phân phối: Không có mã SMS. Thông tin xác thực nằm trên thiết bị
• Không cần đặt lại: Không thể quên passkey. Đồng bộ hóa qua iCloud Keychain hoặc Trình quản lý mật khẩu của Google
• Bảo mật tốt hơn: Thiết kế chống lừa đảo (phishing) - xác thực mạnh hơn mà không có rào cản

Bạn có thể trả lời những điều này về khả năng xác thực của hệ thống không?

• Tổ hợp thiết bị/trình duyệt nào có tỷ lệ bỏ ngang cao nhất?
• Phần trăm đăng nhập không thành công về mặt kỹ thuật so với do người dùng hủy, được chia nhỏ theo phương thức (mật khẩu, mạng xã hội, OTP, passkey) là bao nhiêu?
• Khi người dùng báo cáo "Tôi không thể đăng nhập", bạn có thể chẩn đoán trong vài phút - chứ không phải vài ngày - không?
• Tỷ lệ chuyển đổi đăng nhập khác nhau như thế nào: đăng nhập ở header so với đăng nhập khi thanh toán?

Nếu không, bạn đang có cùng điểm mù mà hầu hết các nhóm đang gặp phải. Corbado cung cấp khả năng quan sát (observability) cụ thể về xác thực trên tất cả các phương thức xác thực - được xây dựng cho các nhóm cần phân tích mà không cần thay đổi stack xác thực của họ.

• Phân tích Phễu: Theo dõi chuyển đổi ở từng bước từ login_initiated đến session_established - được phân đoạn theo mật khẩu, đăng nhập mạng xã hội, OTP và passkey
• Thông tin chi tiết cấp thiết bị: Nếu Android Chrome thất bại với tỷ lệ gấp 3 lần so với iOS Safari đối với một phương pháp cụ thể, bạn biết cần phải tập trung vào đâu
• Quy kết Lỗi: Lý do lỗi cụ thể (ví dụ: password_incorrect, otp_expired, social_login_cancelled, credential_not_found) biến các lỗi đăng nhập mơ hồ thành dữ liệu có thể hành động

• So sánh Phương thức: Phương thức xác thực nào có tỷ lệ thành công cao nhất? Rào cản thấp nhất? Xem phân tích passkey cho các KPI riêng của passkey
• Thử nghiệm A/B: Thử nghiệm mức độ nổi bật của phương thức xác thực, các luồng dự phòng và các lời nhắc (nudges) đăng ký
• Phân tích Thuần tập (Cohort Analysis): So sánh tỷ lệ chuyển đổi và việc từ bỏ giỏ hàng trên các phương thức xác thực
• Bảng điều khiển theo Thời gian thực: Theo dõi sức khỏe của quy trình xác thực trong ngày Thứ Sáu Đen tối (Black Friday) / các đợt phát hành sản phẩm

Khi bạn xác định tỷ lệ thành công của đăng nhập thanh toán thấp hơn 20% so với đăng nhập trên header:

• Tối ưu hóa Phương pháp: Đưa ra phương thức xác thực nhanh nhất cho mỗi người dùng dựa trên lịch sử
• Giao diện người dùng có Điều kiện (Conditional UI): Tính năng tự động điền của trình duyệt cung cấp thông tin xác thực đã lưu trữ, cho phép đăng nhập không rào cản
• Luồng Dự phòng: Định tuyến thông minh từ các phương thức bị lỗi sang các lựa chọn thay thế mà không gặp ngõ cụt
• Giảm Chi phí: Chuyển người dùng từ SMS OTP sang các phương thức chi phí thấp hơn như passkey. Một số công ty thấy chi phí SMS giảm hơn 70%

Tìm hiểu thêm về khả năng phân tích của Corbado.

Rào cản đăng nhập là một vấn đề về doanh thu ẩn nấp trong điểm mù của các chỉ số. Năm triệu chứng này có thể xác định và có thể khắc phục được:

1. Từ bỏ đăng nhập/đăng ký: Thêm tùy chọn thanh toán với tư cách khách, làm nổi bật đăng nhập mạng xã hội, khắc phục UX trên di động
2. Sự mệt mỏi với mật khẩu: Theo dõi tỷ lệ đặt lại, triển khai quy trình gắn thêm (append) passkey
3. Lỗi phân phối OTP: Đo lường tỷ lệ thành công theo khu vực/nhà cung cấp, xem xét các lựa chọn thay thế
4. Rào cản chéo thiết bị: Kéo dài phiên, giữ nguyên trạng thái giỏ hàng, cải thiện UX khi chuyển giao (handover)
5. Rào cản do bảo mật: Kết hợp mục tiêu của nhóm bảo mật và sản phẩm vào các chỉ số chuyển đổi chung

Vấn đề siêu việt (meta-problem): Hầu hết các tổ chức không thể thấy rào cản xác thực trong hệ thống phân tích của họ. Tỷ lệ thoát (bounces) được ghi nhận; nguyên nhân gốc rễ thì không.

Con đường dẫn đến đăng nhập không rào cản:

1. Xây dựng công cụ đo lường (instrument) cho phễu xác thực (xem sổ tay phân tích xác thực)
2. Phân đoạn tỷ lệ chuyển đổi đăng nhập theo thiết bị, phương thức, điểm chạm
3. Khắc phục các vấn đề có tác động lớn nhất trước (thường là các thay đổi về UX trong một sprint)
4. Xây dựng bài toán kinh doanh cho xác thực ít rào cản
5. Phân tích toàn bộ phễu thương mại điện tử của bạn để hiểu cách thức hoạt động của xác thực khớp với bức tranh chung trong hành trình thanh toán

Xác thực là bước duy nhất mà mọi người dùng đều phải hoàn tất. Tối ưu hóa nó là công việc mang lại đòn bẩy cao nhất cho tỷ lệ chuyển đổi mà hầu hết các nhóm đều chưa thực hiện.

Về Corbado

Corbado là Passkey Intelligence Platform dành cho các đội CIAM vận hành xác thực consumer ở quy mô lớn. Chúng tôi giúp bạn nhìn thấy điều mà log IDP và các công cụ analytics thông thường không thấy: những thiết bị, phiên bản OS, trình duyệt và trình quản lý credential nào hỗ trợ passkey, tại sao quá trình đăng ký không chuyển thành đăng nhập, luồng WebAuthn fail ở đâu, và khi nào một bản cập nhật OS hay trình duyệt làm hỏng đăng nhập một cách âm thầm — tất cả mà không cần thay thế Okta, Auth0, Ping, Cognito hay IDP nội bộ của bạn. Hai sản phẩm: Corbado Observe bổ sung observability cho passkey và mọi phương thức đăng nhập khác. Corbado Connect mang đến managed passkey với analytics tích hợp (song hành cùng IDP của bạn). VicRoads vận hành passkey cho hơn 5M người dùng với Corbado (kích hoạt passkey +80%). Trao đổi với chuyên gia Passkey →

Theo dõi các sự kiện rời rạc từ login_initiated đến session_established, phân đoạn theo phương thức xác thực, loại thiết bị và điểm chạm đầu vào. Tỷ lệ thành công tổng thể 90% có thể che giấu tỷ lệ thất bại 50% đối với các phân khúc cụ thể như người dùng di động. Phân đoạn theo người dùng mới so với người dùng cũ để phân biệt các sự cố đăng ký với các vấn đề về phiên và mật khẩu.

Hiệu ứng NASCAR xảy ra khi màn hình đăng nhập lộn xộn với các biểu trưng (logo) từ nhiều nhà cung cấp danh tính (IdP), tạo ra sự tê liệt quyết định vào thời điểm có ý định mua cao nhất trong phễu. Cách khắc phục là hiển thị một tùy chọn chính nổi bật với liên kết "Tùy chọn khác" (More options) làm tùy chọn phụ thay vì hiển thị tất cả các nhà cung cấp cùng một lúc. Việc chỉ cung cấp một nhà cung cấp mà người dùng không nhận ra sẽ tạo ra một ngõ cụt gây tổn hại không kém.

Thời gian hết hạn phiên thường được các nhóm bảo mật hoặc tuân thủ thiết lập mà không có ý kiến từ phía sản phẩm. Thời gian hết hạn 15 phút được máy chủ ghi nhận là không hoạt động trong khi người dùng đang kiểm tra mã giảm giá hoặc so sánh giá trên tab khác. 60% người tiêu dùng cho rằng sự thất vọng khi đăng nhập, bao gồm cả việc hết thời gian, là lý do hoàn toàn từ bỏ giỏ hàng, và nếu không có tính năng tự động lưu biểu mẫu, người dùng phải nhập lại tất cả dữ liệu thanh toán.

Tác động lớn hơn là tổn thất chuyển đổi: 46% người tiêu dùng Mỹ không hoàn tất giao dịch do lỗi xác thực, họ thường chuyển sang mua của đối thủ cạnh tranh. Phễu đặt lại mật khẩu chứa nhiều điểm bỏ ngang bao gồm độ trễ khi phân phối email, tính năng lọc thư rác và các quy tắc về độ phức tạp của mật khẩu, mỗi lỗi này làm mất đi một phần người dùng có ý định mua sắm cao trước khi họ quay lại trang thanh toán.

Gần 50% người dùng sẽ rời bỏ trang web nếu được thông báo rằng mật khẩu mới của họ không được trùng với mật khẩu cũ. Việc kiểm tra lịch sử sẽ chặn cơ chế đối phó chính đối với sự mệt mỏi về mật khẩu: sử dụng lại thông tin xác thực quen thuộc. Không có giải pháp thay thế với rào cản thấp, người dùng sẽ tự tạo ngay những mật khẩu mà họ sẽ quên, khởi động lại chu kỳ từ bỏ đầy đủ trong lần truy cập tiếp theo.