---
url: 'https://www.corbado.com/vi/blog/phan-tich-pheu-thuong-mai-dien-tu'
title: 'Phân tích phễu thương mại điện tử: Tại sao Amazon và Shopify chiến thắng'
description: 'Tìm hiểu cách Amazon và Shopify loại bỏ rào cản thanh toán bằng passkey, thanh toán nhanh và ứng dụng gốc, cùng cách họ đo lường những gì người khác bỏ qua để duy trì vị thế dẫn đầu.'
lang: 'vi'
author: 'Vincent Delitz'
date: '2026-05-20T15:52:04.584Z'
lastModified: '2026-05-20T16:12:59.317Z'
keywords: 'phễu thương mại điện tử, phân tích phễu thương mại điện tử, tối ưu hóa phễu thương mại điện tử, các giai đoạn phễu thương mại điện tử, số liệu phễu thương mại điện tử, ví dụ về phễu thương mại điện tử'
category: 'Authentication'
---

# Phân tích phễu thương mại điện tử: Tại sao Amazon và Shopify chiến thắng

## Key Facts

- **Thanh toán nhanh** (Apple Pay, Google Pay, Shop Pay) có tỷ lệ chuyển đổi cao hơn 20-40% so với
  các luồng tiêu chuẩn nhờ loại bỏ việc nhập dữ liệu thủ công và bỏ qua hoàn toàn các bước giỏ hàng.
- **Ép buộc tạo tài khoản** trực tiếp gây ra 24% trường hợp từ bỏ giỏ hàng; các quy tắc mật khẩu
  nghiêm ngặt làm tăng thêm 19% tỷ lệ từ bỏ thanh toán theo nghiên cứu của Viện Baymard.
- **Rào cản xác thực** ảnh hưởng đến \~85% người dùng chưa xác thực, với 35-60% bỏ cuộc
  ngay tại bước đăng nhập, biến xác thực thành một đòn bẩy doanh thu trực tiếp và có thể đo lường được.
- Cải thiện 10% **tỷ lệ xác thực thành công** thường mang lại mức tăng tổng doanh thu từ 3-5%, nhưng
  hầu hết các nhóm lại bỏ qua số liệu xác thực do sự thiên lệch trong đo lường.

## 1. Giới thiệu: Phễu thương mại điện tử

Khi bạn mua một thứ gì đó trên Amazon, bạn không thực sự _thanh toán_. Bạn nhấp vào một nút và món
hàng sẽ được giao đến. Không có rào cản nào cả. Không cần phải đưa ra quyết định.

Đối với hầu hết các cửa hàng trực tuyến khác, quá trình thanh toán bao gồm một loạt các lựa chọn chủ động tạo ra
tải lượng nhận thức: Khách hay Tài khoản? PayPal hay Thẻ tín dụng? Nhập chi tiết
thủ công hay phải trải qua một quá trình
đặt lại mật khẩu?

Khoảng cách này là một sự khác biệt cơ bản về chiến lược. Trong khi nhiều nhóm tập trung vào các cải tiến
nhỏ giọt để vắt kiệt những lợi ích nhỏ trước mắt, các nhà lãnh đạo thị trường đang phá vỡ
toàn bộ phễu. Họ hiểu một sự thật cốt lõi định hình
[thương mại điện tử](https://www.corbado.com/passkeys-for-e-commerce) hiện đại: **ma sát là kẻ thù.**

Họ dẫn đầu không chỉ vì họ lớn, mà vì họ cố gắng loại bỏ một cách có hệ thống
mọi rào cản giữa "Tôi muốn cái này" và "Tôi đã mua cái này". Họ đã tạo ra hai hiệu ứng
tách biệt: Đầu tiên, tỷ lệ chuyển đổi của họ
vượt trội so với thị trường, đồng thời thiết lập một tiêu chuẩn mới khiến cho các hệ thống thanh toán
truyền thống có cảm giác chậm chạp khi so sánh. Chuẩn mực đã thay đổi. Tại sao? Hãy cùng tìm hiểu.

## 2. Các giai đoạn phễu thương mại điện tử

Cấu trúc của một giao dịch [thương mại điện tử](https://www.corbado.com/passkeys-for-e-commerce) vẫn
cực kỳ nhất quán trong suốt một thập kỷ qua. Dù bạn mua giày thể thao, đặt chuyến bay hay
đặt phòng khách sạn, logic đều giống nhau. Người dùng truy cập, tìm một sản phẩm, thêm nó
vào giỏ hàng của họ và sau đó đối mặt với bài kiểm tra quan trọng của phễu: thanh toán.

Quá trình này được xác định bởi nhiều yếu tố, nhưng hôm nay chúng ta sẽ tập trung vào hai bức tường vô hình
đứng giữa sự quan tâm và việc mua hàng:

- **Rào cản thanh toán (Checkout Wall)**: Khoảnh khắc người dùng nhấp vào "Bắt đầu thanh toán", họ buộc phải đưa ra một
  lựa chọn. Họ tiếp tục với tư cách là khách, sử dụng nhà cung cấp thanh toán nhanh hay đăng nhập? Quyết định
  này chỉ ra một trong những nguồn gây bỏ cuộc lớn nhất trong toàn bộ phễu.
- **Rào cản thanh toán (Payment Barrier)**: Ngay cả sau khi vượt qua rào cản đầu tiên, việc nhập dữ liệu thủ công vẫn là
  mức độ ma sát cơ bản. Tìm thẻ tín dụng, gõ 16 chữ số, kiểm tra ngày hết hạn
  và nhập mã CVV là một công việc đòi hỏi nỗ lực cao. Mỗi giây tăng thêm ở bước này đều làm tăng
  khả năng từ bỏ.

Câu trả lời của ngành công nghiệp là giới thiệu các hệ số nhân chuyển đổi,
các tùy chọn [thanh toán](https://www.corbado.com/passkeys-for-payment) như PayPal,
Apple Pay và Klarna để nắm bắt những người dùng mà nếu không thì sẽ
rời đi. Nhưng về lâu dài, việc chỉ thêm các nhà cung cấp bên thứ ba là không đủ. Những người chiến thắng thực sự
hiểu rõ tâm lý đằng sau ba con đường mua hàng chính.

## 3. Thanh toán cho khách vs Tài khoản: Lựa chọn chuyển đổi

Đối với một người mua lần đầu, con đường ít trở ngại nhất gần như luôn là
thanh toán dành cho khách (guest checkout). Hãy xem xét một kịch bản điển hình: một
người dùng tìm kiếm giày mùa đông, nhấp vào một quảng cáo và truy cập vào một cửa hàng mà họ chưa từng nghe đến.
Họ thích sản phẩm đó, nhưng họ không có ý định quay lại. Họ đã có tài khoản
tại Amazon, Zalando và hàng tá nhà bán lẻ khác. Họ không muốn có thêm một mật khẩu nào nữa. Họ
chỉ muốn đôi giày.

Từ góc độ của người bán, việc ép buộc tạo tài khoản có vẻ hợp lý
vì dù sao họ cũng cần email và địa chỉ. Nhưng đối với người dùng, trường mật khẩu đó
đại diện cho một núi tải lượng nhận thức. Nó có nghĩa là tạo ra một mật khẩu an toàn (phù hợp với
chính sách mật khẩu tùy chỉnh của cửa hàng), gõ nó hai lần (có lẽ đi kèm bảo vệ
chống sao chép-dán), và lo sợ vòng lặp xác minh email không thể tránh khỏi. Nó kích hoạt sự mệt mỏi vì
lại thêm một bộ thông tin xác thực nữa, và sự nghi ngờ rằng tài khoản này sẽ chỉ đóng vai trò như một
phương tiện cho hoạt động tiếp thị trong tương lai.

Sự tiện lợi luôn chiến thắng. Các thương hiệu lâu đời với lượng người theo dõi trung thành có thể đủ khả năng yêu cầu
tài khoản, nhưng đối với tất cả những người khác,
thanh toán dành cho khách là một van an toàn. Các cửa hàng thông minh
hiểu rằng bạn không thể ép buộc một mối quan hệ trong lần hẹn hò đầu tiên; họ tập trung vào việc giảm thiểu
ma sát trước và lo về việc giữ chân khách hàng sau.

Đọc thêm bài phân tích chi tiết của chúng tôi về
cuộc tranh luận giữa thanh toán dành cho khách vs.
đăng nhập bắt buộc.

## 4. Thanh toán nhanh: PayPal, Apple Pay & Shopify

Nếu thanh toán cho khách là con đường phụ, thì thanh toán nhanh là đường cao tốc. Các nhà cung cấp như
PayPal, Google Pay và
Apple Pay đã làm thay đổi cơ bản hành vi người dùng bằng cách
điền sẵn các phần tẻ nhạt của biểu mẫu. Địa chỉ giao hàng, chi tiết
[thanh toán](https://www.corbado.com/passkeys-for-payment) và thông tin liên hệ được chèn vào chỉ với một cú chạm.
Ma sát của việc nhập dữ liệu biến mất.

Shopify đã nhận ra sự thay đổi này từ sớm và xây dựng Shop.app, một
lớp thanh toán nhanh trung lập nằm trên hàng ngàn cửa hàng độc lập. Đây là một
động thái chiến lược xuất sắc: nó mang lại cho các nhà cung cấp nhỏ sức mạnh của một
hiệu ứng mạng mà không buộc họ phải hy sinh thương hiệu của mình cho một
[thị trường (marketplace)](https://www.corbado.com/passkeys-for-e-commerce) lớn hơn.

Các triển khai tốt nhất là nhận biết được thiết bị và tối ưu hóa tự động. Một người dùng iPhone sẽ thấy
Apple Pay. Một
người dùng Android sẽ thấy
Google Pay. Điều này có thể được tối ưu hóa hơn nữa khi tùy chọn này
xuất hiện ngay trên chính trang sản phẩm, cho phép người dùng bỏ qua hoàn toàn giỏ hàng giống như
tính năng Mua hàng bằng một cú nhấp chuột (One-Click purchase) của Amazon (thực tế đã được Amazon cấp bằng sáng chế tại Hoa Kỳ trong 20
năm). Con đường mua hàng trực tiếp này là lý do tại sao các tùy chọn thanh toán nhanh luôn có tỷ lệ chuyển đổi cao hơn 20-40%
so với các luồng tiêu chuẩn. Nó không chỉ là một cái nút. Nó là một lối tắt xuyên qua phễu. Nếu
một người tiêu dùng biết đến phương thức thanh toán nhanh và sự tiện lợi của nó, họ biết họ có thể hoàn thành việc mua sắm
chỉ trong vài giây.

Trong [thương mại điện tử](https://www.corbado.com/passkeys-for-e-commerce), sự tiện lợi đồng nghĩa với tốc độ. Mỗi
giây được tiết kiệm và mỗi quyết định được loại bỏ đều chuyển hóa trực tiếp thành một lần bán hàng thành công.

Biểu đồ bên dưới minh họa cách ba con đường thanh toán này so sánh với nhau về ma sát
và tác động đến chuyển đổi.

## 5. Thanh toán bằng tài khoản: Con đường cam kết

Con đường thứ ba phức tạp nhất: tài khoản. Đây là nơi sự căng thẳng giữa
bảo mật và khả năng sử dụng trở nên gay gắt nhất.

### 5.1 Vấn đề "Tôi có tài khoản không?"

Trải nghiệm tồi tệ nhất trong thương mại điện tử là trò chơi đoán mò vì mục đích bảo mật. Một người dùng
nhập email và mật khẩu của họ và hệ thống từ chối cho biết liệu một tài khoản có tồn tại hay không hoặc liệu
mật khẩu có sai không.

Sự mơ hồ này tạo ra một vòng lặp gây bực bội. Khi các công ty hoạt động lâu năm hơn, có nhiều người dùng quên mất việc họ đã từng
đăng ký. Các nhà bán lẻ muốn họ đăng nhập để truy cập các đặc quyền trung thành và
lịch sử đơn hàng, nhưng việc che giấu sự tồn tại của một tài khoản (một thực tiễn sinh ra từ các mối lo ngại về bảo mật
liên quan đến việc "liệt kê tài khoản") thường
dẫn đến bỏ cuộc.
[Nghiên cứu từ Viện Baymard](https://baymard.com/blog/current-state-of-checkout-ux)
cho thấy các quy tắc mật khẩu nghiêm ngặt có thể dẫn đến **tỷ lệ từ bỏ thanh toán lên đến 19%**, bởi vì
người dùng gặp khó khăn khi đăng nhập hoặc quá trình đặt lại mật khẩu quá chậm.

Trong khi các ngân hàng phải che giấu sự tồn tại của tài khoản để ngăn chặn
lừa đảo có mục tiêu, thương mại điện tử lại hoạt động dưới các động lực khác. Những
cửa hàng hàng đầu đã nhận ra rằng lợi ích chuyển đổi từ việc giúp một người dùng đăng nhập lớn hơn nhiều so với
rủi ro lý thuyết.

Mối đe dọa thực sự ngày nay không phải là ai đó đoán xem một tài khoản _có tồn tại_ hay không (liệt kê). Mà là
những kẻ tấn công đã _có_ thông tin xác thực từ các vụ rò rỉ khác (nhồi thông tin xác thực) hoặc
lừa đảo (phishing). Biện pháp phòng thủ chống lại điều này là trí tuệ. Các nền tảng
hàng đầu sử dụng tính năng bảo vệ khỏi bot (như Cloudflare) và MFA dựa trên rủi ro
để chặn các nỗ lực đăng nhập độc hại ở quy mô lớn và ngăn chặn
việc liệt kê tài khoản, trong khi vẫn cho phép
họ nói một cách rõ ràng với người dùng hợp pháp: "Chào mừng bạn quay lại, vui lòng đăng nhập."

### 5.2 Sự tiến hóa của xác thực

Cách người dùng đăng nhập cũng đang thay đổi. Đăng nhập qua mạng xã hội (Google, Apple)
đang thống trị trên các ứng dụng và ngày càng phát triển trên web vì nó loại bỏ ma sát của việc đăng ký
và trong nhiều trường hợp cũng xác minh địa chỉ email. Tuy nhiên, các thương hiệu lớn thường cưỡng lại
việc này để tránh sự phụ thuộc vào Big Tech.

Tiêu chuẩn mặc định vẫn là email và mật khẩu, nhưng nó là một tiêu chuẩn đang hấp hối. Các phương pháp không cần mật khẩu
như OTP và liên kết ma thuật (magic links) đang ngày càng phổ biến, mặc dù chúng mang theo những rào cản riêng của mình
vì việc chờ đợi mã qua email làm gián đoạn luồng thao tác. Thú vị là, các nền tảng lâu đời
thường thấy tỷ lệ thành công nhanh chóng với mật khẩu rất cao chỉ vì tính năng tự động điền của trình duyệt
đã trở nên quá tốt và những khách hàng lâu năm đã lưu mật khẩu của họ trong trình duyệt trong
một thời gian dài. Đặc biệt trên Apple, tỷ lệ mật khẩu được lưu cực kỳ cao khá phổ biến
đối với các triển khai mật khẩu được xây dựng tốt cho phép lưu và tự động điền.

Nhưng ngành công nghiệp đang tiến tới một chân trời mới nơi mật khẩu hoàn toàn không tồn tại. Để xem phần
phân tích chi tiết về cách 50 thương hiệu hàng đầu triển khai các phương pháp này, hãy xem qua
Đánh giá chuẩn xác thực thương mại điện tử của chúng tôi.

## 6. Các ứng dụng gốc là mục tiêu cuối cùng

Đối với các thương hiệu ưu tiên web, ứng dụng gốc (native app) là chén thánh. Nó
đại diện cho trạng thái mối quan hệ tối cao nơi rào cản hầu như biến mất.

Để một người dùng cài đặt ứng dụng là điều khó khăn vì bạn không thể làm gián đoạn việc mua hàng để yêu cầu
họ tải xuống. Nhưng một khi ứng dụng đó đã có trên màn hình chính, cục diện sẽ thay đổi. Chiến lược này
rất đơn giản nhưng mạnh mẽ: cho phép duyệt web mà không cần đăng nhập, nhưng chỉ bắt buộc xác thực ở
lần thanh toán đầu tiên. Khi họ đã đăng nhập, họ sẽ luôn ở trạng thái đăng nhập. Mãi mãi.

Các liên kết vạn năng (Universal links) chốt lại thỏa thuận. Khi một người dùng đã cài đặt ứng dụng nhấp vào một liên kết trong
email hoặc quảng cáo, họ không bị đưa đến trang web di động nơi họ có thể phải đăng nhập lại.
Họ được liên kết sâu trực tiếp vào ứng dụng, đã được xác thực và sẵn sàng mua hàng.

Lợi ích cộng gộp là rất lớn. Tính cá nhân hóa diễn ra ngay lập tức. Rào cản
đăng ký và đăng nhập biến mất. Và điều quan trọng nhất, bạn ngừng trả tiền để có lại cùng một
khách hàng thông qua các kênh trả phí. Đối với người dùng ứng dụng, Chi phí chuyển đổi khách hàng (CAC) giảm
gần bằng không.

## 7. Sinh trắc học và Passkey: Danh tính thay vì Trí nhớ

Vấn đề với mật khẩu là chúng yêu cầu trí nhớ. Vấn đề với các ứng dụng là
chúng yêu cầu cài đặt. Giải pháp thu hẹp khoảng cách này chính là sinh trắc học.

Điện thoại di động đã bình thường hóa điều này. Touch ID và
Face ID là tiêu chuẩn để mở khóa cuộc sống của chúng ta. Người tiêu dùng
đã bỏ phiếu bằng chính ngón tay cái của họ: sự tiện lợi luôn luôn đánh bại các mối lo ngại về quyền riêng tư. Ngoài các
nhóm thị trường ngách, kỳ vọng này đã được thiết lập vững chắc.

Các ứng dụng gốc đã tận dụng điều này ngay lập tức. Nhưng web vẫn bị tụt lại phía sau, cho đến tận bây giờ.
**Passkey** đang mang "trải nghiệm Face ID" lên
trình duyệt. Chúng thay thế "những gì bạn biết" (một mật khẩu) bằng "chính bạn là ai" (sinh trắc học),
được xếp lớp lên trên hệ thống bảo mật riêng của thiết bị. Theo
[Liên minh FIDO (FIDO Alliance)](https://www.prweb.com/releases/fido-alliance-champions-widespread-passkey-adoption-and-a-passwordless-future-on-world-passkey-day-2025-302443727.html),
**74% người tiêu dùng** hiện đã biết về passkey và **69%** đã bật ít nhất một passkey.

Những người chỉ trích chỉ ra rằng điều này nhốt người dùng vào các hệ sinh thái của Apple (iCloud) hoặc Google. Điều này
là đúng. Nhưng hãy nhìn xem ai đang áp dụng chúng: Amazon, Stripe và PayPal. Họ là các
đối thủ cạnh tranh trực tiếp, thế nhưng họ đang tích cực triển khai passkey. Hãy xem các triển khai passkey thực tế từ 18 nhà bán lẻ lớn. Tại sao?

Bởi vì họ biết rằng **ma sát là kẻ thù**.

Công nghệ cơ bản (WebAuthn) đã tồn tại trong nhiều năm, nhưng việc áp dụng được thúc đẩy bởi
chuyển đổi, chứ không phải tiêu chuẩn. Amazon và PayPal không hề suy đoán. Họ đang nhìn vào
dữ liệu. Họ thấy rằng một người dùng có thể đăng nhập bằng một cái nhìn là một người dùng sẽ mua hàng.

Sinh trắc học giải quyết hai vấn đề cùng một lúc:

1. **Không có định danh nào để quên**: Bạn không cần nhớ email nào bạn đã sử dụng.
2. **Không có mật khẩu nào để quên**: Bạn chính là mật khẩu.

Điều này tạo ra một thực tế "một cú nhấp chuột". Một khách hàng đã đăng ký PayPal biết rằng họ chỉ cách
việc mua hàng một thao tác kiểm tra Face ID. Họ sẽ không bao giờ phải nhập lại
số thẻ tín dụng nữa. Một khi người tiêu dùng đã trải nghiệm mức độ trơn tru này, việc quay lại
mật khẩu sẽ giống như sử dụng một chiếc máy đánh chữ. Chuẩn mực đã thay đổi và nó sẽ không bao giờ quay lại như cũ.

## 8. Amazon vs. Shopify: Hai chiến lược chiến thắng

Amazon và Shopify đại diện cho hai cách tiếp cận khác nhau để chiến thắng
trong thương mại điện tử, tuy nhiên họ có chung một nỗi ám ảnh với việc loại bỏ ma sát.

**Amazon là Khu vườn có tường bao (Walled Garden).** Đây là mục tiêu cuối cùng đối với một nền tảng thương mại điện tử lâu đời.
Chiến lược của nó được xây dựng trên một bức tường tài khoản kiên cố, bạn đơn giản là không thể mua hàng nếu không là một phần của
hệ thống (=đã đăng nhập). Nhưng bên trong bức tường đó, **thanh toán không ma sát** là tiêu chuẩn. Các phương thức
[thanh toán](https://www.corbado.com/passkeys-for-payment) được lưu lại, địa chỉ được lưu sẵn và "Mua ngay"
thực sự là một hành động Mua hàng bằng một cú nhấp chuột (One-Click). Nhờ vào
việc phân phối ứng dụng gốc của họ, phần lớn khách hàng luôn trong trạng thái đăng nhập vĩnh viễn. Họ không cần các nút
thanh toán nhanh vì toàn bộ trải nghiệm Amazon _chính là_ một luồng thanh toán nhanh.

**Shopify là Người hỗ trợ (The Enabler).** Nó giải quyết một vấn đề khác: tạo điều kiện cho các cửa hàng độc lập
có thể cạnh tranh với sự tiện lợi của Amazon. Một người bán hàng bắt đầu trên
Shopify ngày nay sẽ có một phễu được tối ưu hóa ngay lập tức.
Shopify dân chủ hóa ngăn xếp công nghệ:

- **Thanh toán được tối ưu hóa theo hệ điều hành (OS)**: Phân phối Apple Pay cho người dùng iOS và
  Google Pay cho
  người dùng Android một cách tự động. Tất nhiên là
  bổ sung thêm Shop.app.
- **Hiệu ứng mạng**: Thông qua Shop.app và Shop Pay, nó nhận diện người dùng trên hàng ngàn
  cửa hàng khác nhau, mang theo thông tin xác thực của họ giống như một hộ chiếu kỹ thuật số.
- **Sẵn sàng cho tương lai**: Tham gia vào các sáng kiến kỹ thuật như
  FedCM của Google để giảm thiểu hơn nữa
  ma sát xác thực mà không cần
  người bán phải hiểu rõ công nghệ kỹ thuật đằng sau nó (có thể
  bạn không biết FedCM là gì, nhưng
  đáng ngạc nhiên là Google & Shopify đang rất tích cực trong việc phát triển tiêu chuẩn này và
  Apple đang chặn nó).

**Thách thức đối với cửa hàng độc lập**

Điều này để lại một câu hỏi quan trọng: Liệu có không gian dài hạn nào cho các nhà bán lẻ không phải là
Amazon cũng không sử dụng Shopify?

Câu trả lời là có, nhưng các rào cản kỹ thuật đã được nâng lên. Các thương hiệu lớn đang chạy trên các
ngăn xếp tùy chỉnh hoặc nền tảng cũ (ví dụ: Salesforce,
Adobe, Magento) hiện đang phải đối mặt với một
thực tế khó khăn. Họ phải xây dựng những gì mà Amazon và Shopify cung cấp ngay lập tức. Họ phải
thiết kế các luồng thanh toán nhanh của riêng mình, các tích hợp passkey của riêng mình và các
đồ thị danh tính của riêng họ. Không gian vẫn tồn tại, nhưng chỉ dành cho những ai sẵn sàng coi cơ sở hạ tầng thanh toán
là một sản phẩm cốt lõi, chứ không chỉ là một tiện ích.

Biểu đồ sau đây so sánh hai chiến lược chiến thắng này cạnh nhau.

## 9. Số liệu phễu thương mại điện tử: Bẫy đo lường

Nếu lợi ích của việc xác thực không có rào cản và ứng dụng gốc là quá rõ ràng, tại sao
không phải ai cũng áp dụng chúng? Câu trả lời nằm ở cách chúng ta đo lường thành công.

Thương mại điện tử là một cuộc chơi của từng centimet, được đo lường bằng
tỷ lệ chuyển đổi. Nhưng chuyển đổi là một
số liệu phức tạp, bị ảnh hưởng bởi mọi thứ, từ niềm tin thương hiệu cho đến chi phí vận chuyển. Trong sự hỗn loạn của dữ liệu,
các nhóm thường rơi vào một cái bẫy.

### 9.1 Chiến thắng dễ dàng (Ngắn hạn)

Hầu hết các tối ưu hóa phễu đều gây nghiện vì chúng mang lại sự hài lòng tức thì. Thêm một tùy chọn
thanh toán cho khách? Thấy ngay sự gia tăng trong vài ngày. Thêm PayPal? Thấy kết quả trong một tuần. Đây là
những thay đổi "gần giao dịch". Chúng diễn ra ngay trước khi tiền được trao tay, vì vậy
tác động của chúng rất dễ để quy kết.

**Từ bỏ giỏ hàng** là kẻ thù kinh điển ở đây. Các nhóm chi hàng triệu đô la cho nhắm mục tiêu lại qua email
và các cửa sổ bật lên (pop-up) khi có ý định thoát trang vì ROI sẽ hiển thị trên bảng điều khiển ngay lập tức.

### 9.2 Những thay đổi mang tính chiến lược (Dài hạn)

Những thay đổi về cấu trúc như
chuyển đổi sang passkey hoặc thúc đẩy việc sử dụng
ứng dụng gốc khó biện minh hơn trong một bản đánh giá hàng quý.

Quy mô là rào cản đầu tiên. Bạn cần khối lượng đủ lớn để thấy được sự gia tăng có ý nghĩa thống kê từ một
phương thức đăng nhập mới. Thời gian là rào cản thứ hai. Đăng nhập mạng xã hội hoặc
việc áp dụng passkey không diễn ra trong một đêm; nó
đòi hỏi hàng tháng trời để người dùng từ từ đăng ký. Việc lập ngân sách cho vấn đề này liên quan đến sự không chắc chắn. Có
bao nhiêu người dùng sẽ thực sự sử dụng phương thức này? là một câu hỏi khó trả lời khi bạn chưa xây dựng nó.

### 9.3 Sự thiên lệch trong đo lường

Điều này tạo ra **Sự thiên lệch trong đo lường** (Measurement Bias) - chúng ta quản lý những gì chúng ta có thể đo lường, và bỏ qua những gì
chúng ta không thể.

Các tập đoàn hành động một cách hợp lý trong phạm vi các động lực của họ. Nếu một Giám đốc Sản phẩm được khen thưởng vì
sự gia tăng chuyển đổi trong quý này, họ sẽ tối ưu hóa màu sắc của nút thanh toán, chứ không phải là
kiến trúc xác thực - đặc biệt nếu người đó không có thông tin sâu sắc về cách
xác thực có thể giúp cải thiện
tỷ lệ chuyển đổi. Họ sẽ tập trung vào sự sụt giảm
có thể đo lường được ở bước "Đặt hàng" hoặc các số liệu có thể đo lường ngay lập tức khác.

Amazon và Shopify chiến thắng vì họ bỏ qua sự thiên lệch này. Họ tối ưu hóa cho trò chơi dài hạn và
có các nhóm chuyên trách cung cấp khả năng quan sát (observability) đầy đủ về những gì cải thiện
tỷ lệ chuyển đổi, ngay cả trong các nhóm người dùng nhỏ
đủ lớn để có ý nghĩa thống kê, và họ có các công cụ để chứng minh điều đó. Họ
hiểu rằng sự tiện lợi mang tính cộng gộp, và rào cản của ngày hôm nay chính là một
khách hàng bị mất của ngày mai.

## 10. Phá vỡ sự thiên lệch: Khả năng quan sát (Observability)

Bạn không thể sửa những gì bạn không thể nhìn thấy. Chúng tôi đã xây dựng Corbado như một
nền tảng tình báo passkey dành riêng cho
mục đích này. Chúng tôi nhận ra rằng các hệ thống phân tích thương mại điện tử và xác thực đang nói những
ngôn ngữ khác nhau. Các nhóm tiếp thị theo dõi
Google Analytics; Các nhóm kỹ thuật theo dõi
nhật ký máy chủ (server logs). Không ai theo dõi những rào cản ở giữa.

Đối với các doanh nghiệp B2C lớn có các nhóm danh tính nội bộ, thách thức không chỉ là
việc triển khai passkey; mà là hiểu rõ về chúng. Bạn có thể có một IDP tùy chỉnh hoặc một ngăn xếp công nghệ phức tạp,
nhưng nếu không có khả năng quan sát chi tiết, bạn đang bay mù. Bạn cần biết nhiều
hơn là chỉ "họ có đăng ký không?" Bạn cần biết:

- **Tỷ lệ Xác thực Thành công**: Tốc độ và mức độ thành công của đăng nhập
  bằng passkey thực sự so sánh
  như thế nào với mật khẩu hoặc đăng nhập qua mạng xã hội?
- **Chi tiết Bỏ cuộc**: Có bao nhiêu người dùng đã bỏ qua thông báo nhắc nhở sinh trắc học? Tính năng tự động điền thất bại thường xuyên
  như thế nào?
- **Tác động Kinh doanh**: Sự khác biệt về doanh thu giữa một người dùng đã đăng nhập và một
  khách vãng lai là bao nhiêu?

Đây là cách Amazon và Shopify hoạt động. Họ theo dõi mọi chuyển động chuột, mọi sự tập trung vào trường nhập liệu
và mọi sự do dự. Họ coi xác thực không phải là một cổng bảo mật, mà là một
bước chuyển đổi.

Video sau đây minh họa cách Corbado hỗ trợ cách tiếp cận này: phân tích phễu đăng nhập
với sự nghiêm ngặt như đối với một phễu thương mại điện tử, phóng to vào từng
điểm quyết định xác thực.

[Watch on YouTube](https://www.youtube.com/watch?v=wnrXJzvBjsU)

Corbado mang lại mức độ thấu hiểu này cho ngăn xếp công nghệ hiện tại của bạn. Chúng tôi không thay thế IDP của bạn hoặc
việc triển khai hiện tại của bạn. Chúng tôi bổ sung thêm lớp khả năng quan sát cho phép các Giám đốc Sản phẩm
bảo vệ các dự án dài hạn bằng dữ liệu cứng, chứng minh rằng một thay đổi "kỹ thuật" như
WebAuthn có một đường dây trực tiếp tới doanh thu.

Biểu đồ bên dưới hình ảnh hóa khoảng trống về khả năng quan sát này giữa những gì các nhóm tiếp thị và kỹ thuật
thường nhìn thấy.

## 11. Tối ưu hóa Phễu Thương mại điện tử: Cây Giá trị (Value Tree)

"Cây giá trị" là một mô hình tư duy để hiểu cách các tối ưu hóa này kết hợp với nhau. Nó
tổ chức các can thiệp bằng khoảng cách của chúng đến giao dịch.

### 11.1 Gần Giao dịch (Quả hái tầm thấp - Low-hanging Fruit)

Những yếu tố này nằm ngay trước khi mua hàng. Chúng dễ đo lường và kiểm tra A/B với độ tin cậy
nhanh chóng.

| **Giai đoạn** | **Tối ưu hóa**                      | **Tác động Tiềm năng**                                                                                                                                                 |
| ------------- | ----------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Giỏ hàng**  | Thanh toán dành cho Khách           | **Loại bỏ nguyên nhân bỏ cuộc thứ 2** (24% người dùng rời đi do bị buộc tạo tài khoản theo [Baymard](https://baymard.com/blog/current-state-of-checkout-ux))           |
| **Thanh toán**| Phương thức Nhanh                   | **Tăng tỷ lệ chuyển đổi lên đến 50%** (Shop Pay vs thanh toán cho khách theo báo cáo của Shopify)                                                                      |
| **Trả tiền**  | Thẻ / Ví được Lưu sẵn               | **Loại bỏ 13% tỷ lệ từ bỏ** (người dùng rời đi do gặp phải rào cản thanh toán theo báo cáo của PayPal)                                                                 |

- **Phương thức Thanh toán**: Thêm PayPal hoặc Klarna có thể nâng cao chuyển đổi lên 5-15%. Theo
  PayPal, **13% người mua sắm** từ bỏ giỏ hàng chỉ vì phương thức thanh toán ưa thích của họ
  không có sẵn.
- **Thanh toán Nhanh**: Đối với những người dùng chọn nó, chuyển đổi tăng đáng kể.
  Shopify báo cáo rằng
  **[Shop Pay tăng mức độ chuyển đổi lên đến 50%](https://www.shopify.com/blog/shop-pay-checkout)**
  so với thanh toán cho khách.
- **Thanh toán dành cho Khách**: Loại bỏ nó là một thảm họa về chuyển đổi.
  **[24% tỷ lệ từ bỏ](https://baymard.com/blog/current-state-of-checkout-ux)** bị
  thúc đẩy trực tiếp bởi việc bắt buộc tạo tài khoản.

Như bạn có thể thấy, có vô số con số được trích dẫn bởi các nhà cung cấp thanh toán nhanh và
Shopify để làm nổi bật tự nhiên lợi ích riêng của họ. Mặc dù điều này không có nghĩa là họ
không chính xác, nhưng nếu không có bằng chứng thực tế hoặc khả năng quan sát xem những thay đổi nào mang lại hiệu ứng nào, sẽ rất
khó để điều hướng chiến lược mua sắm một cách hiệu quả.

### 11.2 Lớp Xác thực (Cây cầu - Bridge)

Đây là nơi việc đo lường trở nên phức tạp. Các hiệu ứng là sự pha trộn giữa mức tăng ngay lập tức và
tỷ lệ giữ chân dài hạn. Ở hầu hết các phễu có khối lượng lớn, chỉ có **\~15% người dùng đã được
xác thực**. Những người dùng này đi qua quá trình thanh toán với mức độ ma sát gần như bằng không. Khoảng **\~85% còn lại đối mặt với bức tường đăng nhập**, nơi **35-60% sẽ bỏ cuộc**. Đây là lý do tại sao xác thực sớm
rất quan trọng: tại điểm quyết định đòi hỏi sự cam kết cao này, tải lượng nhận thức phải ở mức tối thiểu.

```mermaid
graph TD
    A[Sản phẩm] --> B[Giỏ hàng]
    B --> C{Quyết định Xác thực}

    C -->|"~15% Đã Đăng nhập"| D1[Thanh toán - Không Rào cản]
    C -->|"~85% Chưa Đăng nhập"| D2[Đăng nhập / Đăng ký]

    D2 -->|"35-60% Bỏ cuộc"| X[Bị Bỏ rơi]
    D2 -->|"40-65% Hoàn tất Xác thực"| D3[Thanh toán]

    D1 --> E[Trả tiền]
    D3 --> E
    E --> F[Thành công]

    style C fill:#3b82f6,color:#fff
    style D2 fill:#f59e0b,color:#000
    style X fill:#ef4444,color:#fff
    style D1 fill:#22c55e,color:#fff
```

Tác động cộng gộp của việc khắc phục giai đoạn "giữa phễu" này là cực lớn. Đối với một doanh nghiệp
điển hình:

- Việc **cải thiện 10%** về mức độ thành công xác thực không chỉ cải thiện tỷ lệ đăng nhập.

- Nó chảy trực tiếp đến lợi nhuận cuối cùng, thường mang lại **mức tăng tổng doanh thu từ 3-5%
  sau khi các tối ưu hóa đầy đủ có hiệu lực**.

- **Đăng nhập Mạng xã hội**: Tăng tỷ lệ hoàn thành đăng ký lên 10-20%.

- **Passkey**: Có thể giảm một nửa số lần đăng nhập thất bại. Nếu 20 trong số 100 người dùng hiện đang bỏ
  cuộc khi cố gắng đăng nhập (quên mật khẩu, mệt mỏi với việc đặt lại), passkey có thể giảm con số đó xuống còn 10.
  Mất ít lượt đăng nhập hơn có nghĩa là hoàn thành nhiều đơn mua hàng hơn. Cần hàng tháng để đo lường khi mức độ áp dụng
  tăng lên, nhưng hiệu ứng cộng gộp đối với những người mua lại là vô cùng to lớn.

- **Tự động điền**: Điểm chuẩn ẩn. Nếu bạn không tốt hơn tính năng tự động điền của trình duyệt, bạn đang
  tạo thêm ma sát.

### 11.3 Trước Thanh toán (Nền tảng - Foundation)

Những yếu tố này có đòn bẩy dài hạn cao nhất nhưng khó quy kết nhất.

- **Ứng dụng Gốc (Native App)**: Sau khi được cài đặt, chi phí CAC trong tương lai tiến gần về mức 0.
- **Niềm tin Thương hiệu**: Không thể đo lường trực tiếp, nhưng đó là lý do duy nhất khiến Amazon có thể buộc bạn phải
  đăng nhập.
- **Thanh toán được Lưu**: Trạng thái kết thúc "một cú nhấp chuột".

### 11.4 Các tối ưu hóa nhân lên như thế nào

**Các tối ưu hóa riêng lẻ không cộng lại. Chúng nhân lên.** Ba cải tiến 10% riêng biệt
không mang lại cho bạn mức tăng 30%. Chúng mang lại tổng mức cải thiện \~33%. Amazon giành chiến thắng vì họ đã tối ưu hóa _mọi_ bước. Họ xếp chồng các hệ số nhân lên nhau. Điều này tạo ra một
tỷ lệ chuyển đổi mà các đối thủ không thể sánh kịp
chỉ bằng cách sửa chữa một phần trong phễu của họ. Các công ty giải quyết được vấn đề đo lường
sẽ có được lợi thế cộng gộp mở rộng theo từng năm.

Cây Giá trị hiển thị _những gì_ cần ưu tiên. Phần tiếp theo cung cấp một danh sách kiểm tra cụ thể
để thực thi trên lớp xác thực.

## 12. Danh sách kiểm tra Tối ưu hóa Xác thực

Trước khi tối ưu hóa xác thực, bạn cần hiểu nơi xảy ra ma sát. Hầu hết các cửa hàng
sử dụng Google Analytics hoặc các công cụ tương tự để
theo dõi sự sụt giảm của phễu, nhưng những công cụ này thiếu độ chi tiết để chẩn đoán _tại sao_ người dùng lại bỏ cuộc ở
bước xác thực. Hãy bắt đầu bằng cách thiết lập các KPI phân chia các đơn đặt hàng theo loại thanh toán
(Khách, Tài khoản, Nhanh), sau đó chia nhỏ phễu xác thực thành các bước có thể đo lường.

Danh sách kiểm tra dưới đây được thiết kế cho các cửa hàng tùy chỉnh có quy mô lớn chạy trên các nền tảng như
Salesforce, Adobe hoặc Magento. Các mục
được đánh dấu bằng **📊** yêu cầu khả năng quan sát chuyên dụng để đo lường hiệu quả và nên
được công cụ hóa trước hoặc trong quá trình triển khai.

### 12.1 Các quyết định cấp Phễu

Những lựa chọn chiến lược này có tác động cao nhất đến chuyển đổi và nên được quyết định trước
khi tiến hành bất kỳ công việc thiết kế UX nào.

| **Mục**                                | **Chi tiết Triển khai**                                                                                                                                                                                                                              | **📊** |
| :------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :----: |
| **Không ép buộc đăng nhập trước khi thanh toán** | Cho phép duyệt, thêm vào giỏ hàng, vận chuyển và chọn thanh toán mà không cần tài khoản. Chỉ yêu cầu xác thực đối với giá trị dành riêng cho tài khoản: lịch sử đơn hàng, đăng ký nhận tin, địa chỉ được lưu, điểm thưởng, phương thức thanh toán đã lưu. |   ✅   |
| **Thanh toán cho khách là mặc định**   | Đảm bảo nút "Đăng nhập" khả dụng nhưng không phải là đường dẫn chính. Hiển thị tính năng thanh toán dành cho khách trước tiên và nổi bật.                                                                                                            |   ✅   |
| **Tạo tài khoản là sau mua hàng**      | Sau khi thanh toán thành công: "Bảo mật tài khoản của bạn trong 10 giây" với phương thức một chạm (tạo passkey hoặc liên kết ma thuật). Điều này làm giảm tỷ lệ bỏ cuộc trong khi vẫn tăng mức độ tiếp nhận tài khoản.                               |   ✅   |
| **Đăng nhập cho khách hàng cũ phải nhanh** | Nếu bạn hiển thị xác thực ở bước thanh toán, thì nó phải có độ trễ thấp, ít bước nhất và tỷ lệ thành công cao. Tránh gửi người dùng đến một luồng "Tài khoản của tôi" riêng biệt làm mất đi ngữ cảnh thanh toán.                                   |   ✅   |

### 12.2 Trải nghiệm người dùng (UX) khi Đăng nhập & Đăng ký

Trải nghiệm đăng nhập là nơi tập trung phần lớn
ma sát xác thực. Hãy tối ưu hóa tốc độ
và giảm thiểu việc người dùng phải nhập thông tin.

| **Mục**                      | **Chi tiết Triển khai**                                                                                                                                                                                                                                                                                                                                                                                     | **📊** |
| :--------------------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :----: |
| **Cân nhắc sử dụng passkey** | Trước khi thêm passkey, hãy thiết lập các số liệu cơ bản cho các phương pháp xác thực hiện tại của bạn. Sau đó cung cấp passkey như một tùy chọn (không nhất thiết phải là tùy chọn chính) cho người dùng cũ trên các thiết bị được hỗ trợ. Khi các luồng được tối ưu hóa và bạn thấy tỷ lệ chuyển đổi cải thiện, hãy mở rộng sự nổi bật của passkey. Passkey chống lừa đảo và loại bỏ các bí mật được chia sẻ, nhưng việc áp dụng đòi hỏi phải theo dõi quá trình đăng ký. (Liên minh FIDO) |   ✅   |
| **Phương án dự phòng không mật khẩu** | Liên kết ma thuật qua email (hết hạn ngắn) là phương án dự phòng phổ quát đơn giản nhất. Coi SMS OTP là phương sách cuối cùng do chi phí và rủi ro hoán đổi SIM.                                                                                                                                                                                                                                            |   ✅   |
| **Đăng nhập Mạng xã hội**    | Cung cấp Đăng nhập bằng Google và Apple. Loại bỏ ma sát đăng ký và thường tự động xác minh email. Theo dõi tỷ lệ áp dụng cho từng nhà cung cấp.                                                                                                                                                                                                                                                             |   ✅   |
| **Giảm thiểu thao tác nhập liệu** | Bắt đầu đăng nhập chỉ bằng email (hoặc số điện thoại), sau đó chọn phương thức dựa trên tính hợp lệ (có sẵn passkey → liên kết ma thuật → dự phòng bằng mật khẩu).                                                                                                                                                                                                                                          |        |
| **Hỗ trợ tự động điền**      | Đảm bảo tất cả các trường được gắn thẻ đúng cách để trình duyệt và trình quản lý mật khẩu có thể tự động điền. Đặc biệt kiểm tra trên Safari và Chrome. Nếu luồng của bạn phá vỡ tính năng tự động điền, bạn đang thêm ma sát.                                                                                                                                                                              |   ✅   |
| **"Ghi nhớ Tôi" là mặc định**| Mặc định chọn hộp kiểm này, đặc biệt là trên thiết bị di động. Tỷ lệ đăng nhập lại sẽ cải thiện một cách đáng kể.                                                                                                                                                                                                                                                                                           |   ✅   |
| **Đăng xuất mềm (Soft logout)**| Thay vì đăng xuất hoàn toàn, hãy sử dụng thông báo "Bạn có phải là Max không?" cho phép người dùng xác thực lại nhanh chóng mà không cần bắt đầu lại từ đầu. Lưu email của người dùng vào localStorage và điền sẵn nó vào luồng đăng nhập để giảm thiểu ma sát nhập liệu.                                                                                                                                   |   ✅   |
| **Đánh dấu phương thức được dùng gần nhất** | Hiển thị một huy hiệu nhỏ trên phương thức đăng nhập mà người dùng đã sử dụng lần cuối trên thiết bị này (ví dụ: "Đã dùng lần trước"). Thao tác tra cứu localStorage đơn giản.                                                                                                                                                                                                              |        |
| **Liên kết tài khoản**       | Người dùng tạo các bản sao (mua với tư cách khách → đăng ký → đăng nhập mạng xã hội). Hãy xây dựng một luồng hợp nhất an toàn: "Chúng tôi đã tìm thấy một đơn hàng với email này. Bạn có muốn liên kết nó với tài khoản của bạn không?"                                                                                                                                                                     |        |

### 12.3 Liệt kê Tài khoản (Account Enumeration) & Sự tồn tại rõ ràng

Đây là nơi bảo mật và chuyển đổi xung đột trực tiếp với nhau. Giải pháp là phòng thủ theo lớp.

| **Mục**                                | **Chi tiết Triển khai**                                                                                                                                                                                                                                                                                | **📊** |
| :------------------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :----: |
| **Hãy rõ ràng về sự tồn tại của tài khoản** | Nói với người dùng "Chào mừng bạn quay lại, vui lòng đăng nhập" nếu một tài khoản có tồn tại. Lợi ích chuyển đổi lớn hơn nguy cơ liệt kê tài khoản đối với thương mại điện tử (không giống như hoạt động ngân hàng).                                                                                   |        |
| **Bảo vệ bằng tính năng phát hiện bot trước** | Thêm lớp bảo vệ khỏi bot (Cloudflare, reCAPTCHA) tại bước nhập email _trước khi_ tiết lộ trạng thái tài khoản. Điều này chặn các cuộc tấn công liệt kê ở quy mô lớn. Hãy theo dõi chính xác: bao nhiêu lần các thử thách được giải quyết âm thầm, bao nhiêu lần chúng chặn, và bao nhiêu lần người dùng phải hoàn thành một CAPTCHA hiển thị (điều này gây thêm rào cản). |   ✅   |
| **Giới hạn tỷ lệ các nỗ lực xác thực** | NIST yêu cầu giới hạn tỷ lệ cho các nỗ lực thất bại. Triển khai các phản hồi tăng dần: chặn mềm → CAPTCHA → chặn cứng. (NIST SP 800-63B)                                                                                                                                                                 |   ✅   |
| **Thông báo lỗi hữu ích**              | Tốt: "Email hoặc mật khẩu đó không chính xác." Tránh: "Không tìm thấy người dùng" khi đăng nhập. Đối với đăng ký, hãy hướng dẫn người dùng mà không rò rỉ quá nhiều thông tin.                                                                                                                         |        |

### 12.4 Hỗ trợ Mật khẩu (nếu bạn vẫn sử dụng Mật khẩu)

Ngay cả khi chuyển sang passkey, hầu hết các cửa hàng đều giữ mật khẩu như một phương án dự phòng. Nếu vậy, hãy tuân theo các hướng dẫn
hiện đại.

| **Mục**                          | **Chi tiết Triển khai**                                                                                                                                                                                                       | **📊** |
| :------------------------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :----: |
| **Không có các quy tắc phức tạp**| Tránh việc ép buộc sử dụng các ký tự đặc biệt hoặc các hỗn hợp ký tự. Chỉ tập trung vào độ dài. Theo dõi tần suất người dùng gửi các mật khẩu không vượt qua được bước xác thực và chuẩn hóa so với các nhà bán lẻ lớn (hầu hết đều sử dụng các yêu cầu độ dài đơn giản). (NIST SP 800-63B) |   ✅   |
| **Tối thiểu 8-15 ký tự**         | NIST khuyến nghị 15+ đối với mật khẩu yếu tố đơn (single-factor), 8+ nếu có MFA. Theo dõi tỷ lệ từ chối và tối ưu hóa độ dài tối thiểu để cân bằng giữa bảo mật và mức độ ma sát của người dùng.                              |   ✅   |
| **Không hết hạn định kỳ**        | Không bắt buộc phải thay đổi mật khẩu theo thời gian (rotation on a timer). Chỉ buộc thay đổi khi có bằng chứng về việc bị xâm phạm.                                                                                          |        |
| **Danh sách đen các mật khẩu bị rò rỉ** | So sánh với các danh sách mật khẩu bị rò rỉ/phổ biến đã biết tại thời điểm thiết lập và thay đổi.                                                                                                                             |        |
| **Cho phép Dán (Paste)**         | Cho phép dán vào các trường mật khẩu. Không phá vỡ các trình quản lý mật khẩu.                                                                                                                                                |        |

### 12.5 Khôi phục Tài khoản

Khôi phục là nơi các phễu bị rò rỉ tiền. Một người dùng thất vọng vì không thể đặt lại mật khẩu của họ
sẽ bỏ cuộc.

| **Mục**                             | **Chi tiết Triển khai**                                                                                                                                      | **📊** |
| :---------------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------- | :----: |
| **Loại bỏ các câu hỏi bảo mật**     | Hoàn toàn tránh việc xác thực dựa trên kiến thức (knowledge-based authentication). Nó vừa không an toàn lại vừa gây bực bội. (NIST SP 800-63B)               |        |
| **Khôi phục nhanh nhưng bị giới hạn tỷ lệ** | Khôi phục nên có ít bước nhất, nhưng phải được bảo vệ mạnh mẽ khỏi sự lạm dụng.                                                                              |   ✅   |
| **Step-up cho các tài khoản giá trị cao** | Đối với các tài khoản có giá trị vòng đời cao, đơn hàng lớn gần đây, hoặc vị trí địa lý bất thường, hãy yêu cầu bằng chứng khôi phục mạnh mẽ hơn (passkey, mã khôi phục, thiết bị đã được xác minh). |   ✅   |

### 12.6 Xác thực Bước đệm (Step-Up Authentication)

Bạn không muốn hiển thị các lời nhắc MFA ở khắp mọi nơi trong quá trình thanh toán. Bạn muốn step-up có mục tiêu dựa trên
rủi ro.

| **Mục**                               | **Chi tiết Triển khai**                                                                                                                                                                                                                             | **📊** |
| :------------------------------------ | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :----: |
| **Trình kích hoạt dựa trên rủi ro**   | Kích hoạt step-up khi: thiết bị mới, vị trí địa lý bất thường, IP đáng ngờ, hành vi dùng tập lệnh (scripted behavior), thất bại liên tục. ([OWASP Credential Stuffing Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Credential_Stuffing_Prevention_Cheat_Sheet.html)) |   ✅   |
| **Bảo vệ các hành động rủi ro cao**   | Yêu cầu step-up khi: thay đổi email/mật khẩu, sửa đổi địa chỉ giao hàng, thêm chi tiết thanh toán, xem toàn bộ thông tin công cụ thanh toán, đổi điểm thưởng.                                                                                       |   ✅   |
| **Ưu tiên các phương thức chống lừa đảo**| Sử dụng passkey cho step-up nếu có thể. Tránh SMS làm MFA chính. ([OWASP MFA Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Multifactor_Authentication_Cheat_Sheet.html))                                                            |        |
| **CAPTCHA chỉ khi đáng ngờ**          | Không trừng phạt tất cả người dùng. Chỉ kích hoạt CAPTCHA đối với các nỗ lực đáng ngờ và đo lường tỷ lệ giải quyết thành công để tránh làm tổn hại đến chuyển đổi.                                                                                  |   ✅   |

### 12.7 Tính liên tục của Phiên & Thanh toán

Quá trình xác thực làm hỏng giỏ hàng còn tệ hơn là không xác thực.

| **Mục**                                       | **Chi tiết Triển khai**                                                                                                                                                        | **📊** |
| :-------------------------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :----: |
| **HTTPS ở mọi nơi**                           | Bảo vệ toàn bộ phiên làm việc, không chỉ là bước trao đổi thông tin xác thực. ([OWASP Session Management](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html)) |        |
| **Cài đặt cookie an toàn**                    | Sử dụng cờ `Secure` (chỉ TLS) và `HttpOnly` (không có quyền truy cập JS) cho các cookie phiên.                                                                                 |        |
| **Tạo lại ID phiên (session ID) khi đổi đặc quyền** | Sau khi đăng nhập, xác thực lại, thay đổi vai trò và khôi phục tài khoản.                                                                                                      |        |
| **Không có ID phiên trong URL**               | Tránh các mã thông báo phiên (session token) dựa trên URL để ngăn chặn rò rỉ và việc cố định phiên (session fixation).                                                         |        |
| **Tính liên tục của giỏ hàng độc lập với tài khoản**| Phiên giỏ hàng ẩn danh phải tồn tại được qua các hành động xác thực. Khi đăng nhập, hãy hợp nhất các giỏ hàng một cách an toàn và mang tính xác định (deterministically).    |   ✅   |

### 12.8 Đo lường (Instrumentation) & KPIs

Nếu bạn không thể đo lường, bạn không thể tối ưu hóa nó. Đây là những số liệu quan trọng.

| **Số liệu**                     | **Cần theo dõi những gì**                                                                                                                                                                                                            | **📊** |
| :------------------------------ | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :----: |
| **Phân khúc phễu**              | Phân chia tất cả các số liệu đơn hàng theo loại thanh toán: Khách, Tài khoản (mới), Tài khoản (cũ), Nhanh (PayPal, Apple Pay, Shop Pay).                                                                                             |   ✅   |
| **Phân tích phương pháp xác thực**| Đối với mỗi đơn hàng được hoàn thành, hãy ghi lại phương thức xác thực nào đã được sử dụng (mật khẩu, passkey, mạng xã hội, liên kết ma thuật, khách).                                                                               |   ✅   |
| **Tỷ lệ xác thực thành công**   | Đây là KPI sao Bắc Đẩu (North Star KPI) của bạn. Đo lường Nỗ lực đăng nhập → Đăng nhập thành công, được phân chia theo phương thức (mật khẩu, passkey, mạng xã hội, liên kết ma thuật). Mỗi điểm phần trăm tăng lên có nghĩa là sẽ có thêm người dùng hoàn tất thanh toán. Hãy tối ưu hóa không ngừng. |   ✅   |
| **Hoàn thành đặt lại mật khẩu** | Bắt đầu đặt lại → Hoàn thành đặt lại → Đăng nhập thành công tiếp theo.                                                                                                                                                               |   ✅   |
| **Bỏ cuộc ở phần xác thực thanh toán**| Những người dùng chạm tới bước xác thực và rời đi so với những người dùng hoàn thành nó. So sánh với những người dùng thanh toán cho khách.                                                                                          |   ✅   |
| **Tỷ lệ tự động điền thành công**| Tần suất tự động điền của trình duyệt hoàn thành biểu mẫu so với việc nhập thủ công.                                                                                                                                                 |   ✅   |
| **Tỷ lệ thách thức step-up**    | Tần suất step-up được kích hoạt và tỷ lệ vượt qua/thất bại/bỏ cuộc là bao nhiêu.                                                                                                                                                     |   ✅   |
| **Khối lượng nhồi thông tin xác thực**| Các nỗ lực bị chặn, tính đa dạng IP, tỷ lệ thành công của các cuộc tấn công (nên ở mức \~0%).                                                                                                                                        |   ✅   |
| **Tỷ lệ dương tính giả**        | Người dùng hợp pháp bị chặn bởi bộ phận bảo vệ chống bot hoặc step-up. Điều này trực tiếp gây tốn kém doanh thu.                                                                                                                     |   ✅   |

### 12.9 Sự đánh đổi giữa Chuyển đổi và Bảo mật

Mỗi quyết định đều liên quan đến một sự đánh đổi. Dưới đây là cách điều hướng phổ quang cho một
cửa hàng quy mô lớn.

| **Quyết định**                | **Thiên hướng Chuyển đổi** | **Thiên hướng Bảo mật** | **Khuyến nghị Cân bằng**                                              |
| :---------------------------- | :------------------------- | :---------------------- | :-------------------------------------------------------------------- |
| **Yêu cầu đăng nhập để thanh toán** | Không bao giờ        | Luôn luôn               | Mặc định cho khách, đăng nhập tùy chọn, chỉ yêu cầu đối với các giá trị dành riêng cho tài khoản |
| **Nhắc nhở MFA**              | Không bao giờ              | Luôn luôn               | Step-up dựa trên rủi ro vào những lần đăng nhập đáng ngờ và các hành động rủi ro cao |
| **CAPTCHA**                   | Không bao giờ              | Luôn luôn               | Chỉ dành cho lưu lượng truy cập đáng ngờ, đo lường tác động đến chuyển đổi |
| **Chính sách mật khẩu**       | Ngắn và đơn giản           | Quy tắc phức tạp        | Mật khẩu dài, không có quy tắc thành phần, đưa vào danh sách đen các mật khẩu bị rò rỉ |
| **Khôi phục tài khoản**       | Rất dễ dàng                | Rất nghiêm ngặt         | Luồng cơ sở dễ dàng, step-up cho rủi ro, không có câu hỏi bảo mật |
| **Độ dài phiên (Session length)**| Rất dài                 | Rất ngắn                | Dài hơn trên các thiết bị tin cậy, step-up sau các sự kiện rủi ro |
| **Liệt kê tài khoản**         | Luôn luôn tiết lộ          | Không bao giờ tiết lộ   | Tiết lộ sau cổng bảo vệ khỏi bot                                      |

Vị trí mà một công ty nằm trên quang phổ này thường được thúc đẩy bởi văn hóa, địa điểm, luật pháp địa phương,
và sức mạnh của các nhóm bảo mật và tuân thủ. Điều này không có nghĩa là sự tuân thủ là
không quan trọng, mà là khẩu vị rủi ro khác nhau, và điều đó cần phải được tôn trọng. Điều quan trọng
là quyết định đó phải _có ý thức_: nếu bạn hy sinh chuyển đổi vì bảo mật, hãy biết bạn
đang hy sinh bao nhiêu.

## 13. Kết luận

Ma sát là kẻ thù. Sự tiện lợi là chìa khóa. Amazon, Shopify, và PayPal đang giành chiến thắng
bởi vì họ làm việc chăm chỉ trên mọi khía cạnh: những lợi ích rõ ràng trong ngắn hạn, nhưng cũng tham gia
vào các chiến lược dài hạn nhằm cung cấp
sự cải thiện tỷ lệ chuyển đổi trong tương lai,
nhờ đó tối ưu hóa sự lựa chọn giữa "dễ dàng" và "an toàn". Họ đã chuyển đổi ngành công nghiệp
từ thanh toán cổ điển sang thanh toán bằng một cú nhấp chuột với sinh trắc học và các đăng nhập bền vững.

Các rào cản đang dần sụp đổ. Chúng ta đang tiến tới một thế giới web nơi nút thanh toán là nút
_duy nhất_ bạn cần phải nhấn. Trong thời điểm mà hệ thống thanh toán tự hành (agentic checkout) là thứ mà mọi người
đang nói đến, việc thiết lập một thương hiệu và liên hệ trực tiếp với khách hàng thậm chí còn
quan trọng hơn. Cuộc chiến giành quyền sở hữu tài khoản khách hàng đang diễn ra sôi nổi.

Khi tối ưu hóa phễu thương mại điện tử, điều quan trọng là phải xem xét mọi thành phần: các mục tiêu
ngắn hạn và dài hạn. Trong khi xác thực và thanh toán đã không thay đổi trong một thập kỷ qua
và vẫn là một quá trình rất tĩnh, tiến về phía trước sẽ có thêm nhiều lựa chọn cho
sự tiện lợi. Khi người tiêu dùng bắt đầu học hỏi cách mới, dễ dàng hơn, xác thực thuận tiện
(bất kể bạn chọn phương thức nào) cần được tối ưu hóa liên tục; một khi người tiêu dùng đã quen
với phương thức này, các hệ thống đăng nhập cũ kỹ sẽ ngay lập tức làm mờ nhạt chất lượng thương hiệu của bạn.

Chuẩn mực đã thay đổi. Đã đến lúc phải bắt kịp.

## Câu hỏi thường gặp

### Làm thế nào Amazon duy trì được tỷ lệ chuyển đổi cao trong khi yêu cầu bắt buộc đăng nhập tài khoản?

Amazon bù đắp cho bức tường tài khoản kiên cố của mình bằng cách đảm bảo thanh toán một cú nhấp chuột không rào cản
bên trong hệ thống: phương thức thanh toán đã lưu, địa chỉ đã lưu và đăng nhập vĩnh viễn qua ứng dụng gốc.
Hầu hết các khách hàng của Amazon đều đã được xác thực khi họ truy cập, vì vậy bức tường tài khoản
hiếm khi kích hoạt sự bỏ cuộc thực tế. Niềm tin thương hiệu được xây dựng qua nhiều năm, chứ không phải các chiến thuật chuyển đổi
tại điểm thu hút khách hàng, mới là điều làm cho chiến lược này trở nên khả thi.

### Tại sao nhiều tối ưu hóa phễu mang lại nhiều hơn tổng của các cải tiến riêng lẻ của chúng?

Các tối ưu hóa phễu nhân lên thay vì cộng lại: ba cải tiến 10% riêng biệt mang lại
tổng mức tăng khoảng 33% thay vì 30%, bởi vì mỗi cải tiến được áp dụng cho
nhóm còn lại lớn hơn. Amazon chiến thắng bằng cách xếp chồng các hệ số nhân qua mọi bước của
phễu, tạo ra một tỷ lệ chuyển đổi mà các đối thủ không thể sánh kịp bằng cách chỉ sửa chữa một phần.

### Sự thiên lệch trong đo lường ngăn cản hầu hết các nhóm sản phẩm đầu tư vào các cải tiến xác thực là gì?

Các giám đốc sản phẩm được khen thưởng vì những mức tăng chuyển đổi hàng quý có xu hướng tối ưu hóa các số liệu dễ thấy
như nhắm mục tiêu lại người từ bỏ giỏ hàng hơn là kiến trúc xác thực. Việc áp dụng Passkey và
đăng nhập mạng xã hội cần nhiều tháng để thu hút sự đăng ký trước khi mức tăng có ý nghĩa thống kê
có thể đo lường được, làm cho nó trở nên khó biện minh trong các bản đánh giá hàng quý. Amazon và Shopify khắc phục
điều này bằng cách duy trì các nhóm chuyên trách về khả năng quan sát nhằm kết nối các quyết định xác thực
trực tiếp với doanh thu.

### Shop Pay của Shopify mang lại cho các cửa hàng độc lập lợi thế cạnh tranh như thế nào trước Amazon?

Shop Pay nhận diện người dùng quay lại qua hàng nghìn cửa hàng Shopify độc lập,
mang theo thông tin xác thực của họ như một hộ chiếu kỹ thuật số và loại bỏ việc nhập lại thông tin thanh toán và
chi tiết giao hàng. Điều này mang lại cho các nhà cung cấp nhỏ thông tin xác thực đã lưu ở cấp độ Amazon và hiệu ứng mạng
mà không yêu cầu họ phải xây dựng hạ tầng danh tính của riêng mình, đây là
lợi thế chiến lược cốt lõi mà Shopify cung cấp trước mô hình khu vườn có tường bao của Amazon.