Phân tích sản phẩm 3 — Phân tích phễu (Funnel)

Phễu: nơi người dùng rơi rụng

Một app ngân hàng số có 100.000 người tải app trong tháng, nhưng chỉ 32.000 người phát sinh giao dịch đầu tiên. 68% biến mất ở đâu đó giữa hai mốc này — và câu hỏi triệu đô là: rơi ở bước nào? Rơi ở màn hình đăng ký? Ở khâu định danh eKYC? Ở lúc chờ duyệt hồ sơ? Nếu chỉ nhìn hai con số đầu-cuối, bạn biết có vấn đề nhưng không biết chữa ở đâu.

Phân tích phễu (funnel analysis) giải quyết đúng bài toán này. Phễu là một chuỗi bước có thứ tự mà người dùng đi qua để tới một mục tiêu (đăng ký → kích hoạt → giao dịch đầu tiên → giao dịch lặp lại). Với mỗi bước, ta đo tỷ lệ chuyển đổi (conversion rate) — bao nhiêu phần trăm người ở bước trước đi tiếp — và tỷ lệ rớt (drop-off rate) — bao nhiêu phần trăm rơi rụng. Hình dung như một cái phễu vật lý: rộng ở miệng, hẹp dần xuống đáy, và nhiệm vụ của nhà phân tích là tìm chỗ phễu thắt lại đột ngột — đó là điểm nghẽn (bottleneck) đáng sửa nhất.

Bài này nối tiếp pa-02 — Chọn chỉ số đúng: nếu North Star cho biết "đo cái gì", phễu cho biết "hỏng ở đâu trên đường tới cái đó". Nó cũng là bước chẩn đoán trước khi thiết kế thử nghiệm cải thiện ở pa-07.

Cấu trúc một phễu

Một phễu được định nghĩa bởi bốn thành phần:

1. Các bước (steps): danh sách sự kiện có ý nghĩa, theo thứ tự. Ví dụ: mở app → đăng ký → hoàn tất eKYC → tài khoản được duyệt → giao dịch đầu tiên.
2. Tập người vào phễu (population): ai được tính vào miệng phễu. Thường là "tất cả người thực hiện bước 1 trong khoảng thời gian T".
3. Đơn vị đếm: distinct user, không phải event. Một người mở app 10 lần vẫn chỉ tính là 1 ở bước 1. Đây là lỗi phổ biến nhất — đếm event làm phễu phình sai lệch.
4. Cửa sổ chuyển đổi (conversion window): khoảng thời gian tối đa cho phép người dùng đi từ bước đầu tới bước cuối (hoặc giữa hai bước liền kề). Ví dụ "hoàn tất eKYC trong vòng 24 giờ sau khi đăng ký".

Sơ đồ trên là phễu onboarding minh hoạ. Nhìn ngay ra: bước eKYC rớt 36% — cao nhất phễu (28.000 người), đó là điểm nghẽn số một cần tối ưu, không phải khâu duyệt hay kích hoạt.

Các loại phễu

Không phải mọi phễu giống nhau. Trước khi tính, phải chọn đúng loại:

Về cửa sổ thời gian, có hai kiểu:

• Không giới hạn (unbounded): tính mọi người từng đi qua đủ các bước, bất kể mất bao lâu. Đơn giản nhưng dễ thổi phồng conversion (người đăng ký hôm nay, một năm sau mới giao dịch vẫn tính là "đã chuyển đổi").
• Có conversion window: chỉ tính người hoàn tất trong T ngày/giờ. Phản ánh đúng trải nghiệm thực và cho phép so sánh công bằng giữa các cohort. Chọn window theo bản chất nghiệp vụ: onboarding thường 7 ngày; giao dịch đầu tiên có thể 30 ngày.

Quy tắc: phễu để tối ưu trải nghiệm luôn nên có conversion window. Phễu unbounded chỉ dùng để đo trần lý thuyết.

Ba chỉ số cốt lõi của phễu

1. Overall conversion (chuyển đổi tổng)

Tỷ lệ người đi từ bước đầu tới bước cuối:

overall_conversion = distinct_user(bước cuối) / distinct_user(bước đầu)

Trong ví dụ trên: 32.000 / 100.000 = 32%. Đây là con số "sức khoẻ" tổng của phễu, dùng để so sánh theo thời gian và giữa các phân khúc.

2. Step conversion (chuyển đổi từng bước)

Tỷ lệ chuyển từ bước i sang bước i+1:

step_conversion(i) = distinct_user(bước i+1) / distinct_user(bước i)
drop_off(i) = 1 - step_conversion(i)

Đây là chỉ số hành động được nhất: nó chỉ đích danh bước nào đang giết chết phễu. Lưu ý overall conversion = tích của các step conversion (nếu phễu ordered chặt): 0,78 × 0,64 × 0,88 × 0,91 × 0,80 ≈ 0,32.

3. Time-to-convert (thời gian chuyển đổi)

Phân bố thời gian người dùng cần để đi qua một bước (hoặc toàn phễu). Đừng dùng trung bình — dùng trung vị (median) và các phân vị (p50, p90) vì phân bố này thường lệch phải rất mạnh (đa số nhanh, một đuôi dài rất chậm). Time-to-convert dài bất thường ở một bước là dấu hiệu ma sát (chờ duyệt thủ công, chờ OTP, chờ đối chiếu eKYC).

Phân tích phễu: đọc ra insight

Có phễu rồi, phân tích theo bốn hướng:

1. Xác định bước rớt nhiều nhất. Sắp xếp các bước theo drop-off giảm dần. Bước rớt cao nhất (theo tỷ lệ, và cũng cân nhắc theo số tuyệt đối) là ứng viên tối ưu số một. Trong ngân hàng số, khâu này thường là eKYC — nơi khách phải chụp CMND/CCCD, chụp selfie, chờ đối chiếu.

2. So sánh phễu theo phân khúc. Cùng một phễu, cắt theo:

• Kênh thu hút: khách từ quảng cáo có rớt eKYC nhiều hơn khách được giới thiệu không?
• Thiết bị/OS: Android vs iOS, máy đời cũ camera kém có rớt eKYC cao hơn (chụp ảnh mờ)?
• Thời gian/cohort: phễu của khách tháng 6 so với tháng 5 — sau khi đổi luồng eKYC, conversion có cải thiện? Đây gọi là cohort of funnel: so sánh phễu giữa các nhóm khách vào theo từng kỳ.

Phân khúc thường lộ ra sự thật mà con số tổng che giấu: conversion tổng 32% có thể là "iOS 45%, Android đời cũ 18%" — và lúc đó bài toán trở nên rất cụ thể.

3. Phễu ngược (reverse funnel). Thay vì hỏi "ai rớt", hỏi "những người thành công đã đi con đường nào?". Xuất phát từ nhóm đã đạt mục tiêu, truy ngược các bước họ đã qua, tìm hành vi/đặc điểm chung của người thắng. Ví dụ phát hiện: 90% khách giao dịch đều đã bật thông báo đẩy trong 24 giờ đầu → giả thuyết "bật thông báo sớm thúc đẩy kích hoạt".

4. Từ insight tới giả thuyết tới thử nghiệm. Phân tích phễu chẩn đoán, không tự nó chữa. Quy trình: tìm bước nghẽn → đặt giả thuyết ("khách bỏ eKYC vì nhập tay quá nhiều trường") → thiết kế thay đổi (OCR tự điền) → A/B test đo tác động lên step conversion đó. Xem pa-07 — Thử nghiệm & tăng trưởng và stat-07 — A/B testing cho phần đo lường chặt chẽ.

SQL: mô phỏng phễu từ dữ liệu thật

Sandbox không có bảng event chi tiết, nhưng ta mô phỏng các bước phễu bằng dữ liệu trạng thái sẵn có — đây chính là kỹ thuật thực chiến khi chưa có event tracking: dùng bảng customers, accounts, transactions để dựng phễu "vòng đời khách hàng". Định nghĩa các bước:

• Bước 1 — Đăng ký: khách có bản ghi trong customers.
• Bước 2 — Mở tài khoản: khách có ≥1 accounts.
• Bước 3 — Giao dịch đầu tiên: khách có ≥1 transactions (amount ≠ 0).
• Bước 4 — Khách hoạt động (giao dịch lặp lại): khách có ≥2 giao dịch giá trị.

Query 1 — Phễu tổng: đếm distinct khách qua từng bước và tính conversion

Dùng EXISTS để đếm distinct khách (không đếm event), tránh bội số do một khách nhiều tài khoản/giao dịch:

-- ▶ Chạy được
WITH steps AS (
    SELECT
        c.id AS customer_id,
        EXISTS (SELECT 1 FROM accounts a
                WHERE a.customer_id = c.id)                       AS has_account,
        EXISTS (SELECT 1 FROM accounts a
                JOIN transactions t ON t.account_id = a.id
                WHERE a.customer_id = c.id AND t.amount <> 0)     AS has_txn,
        (SELECT COUNT(*) FROM accounts a
                JOIN transactions t ON t.account_id = a.id
         WHERE a.customer_id = c.id AND t.amount <> 0) >= 2       AS is_active
    FROM customers c
)
SELECT
    COUNT(*)                                                        AS s1_registered,
    COUNT(*) FILTER (WHERE has_account)                             AS s2_has_account,
    COUNT(*) FILTER (WHERE has_txn)                                 AS s3_first_txn,
    COUNT(*) FILTER (WHERE is_active)                               AS s4_active,
    ROUND(100.0 * COUNT(*) FILTER (WHERE has_account)
          / NULLIF(COUNT(*), 0), 1)                                AS conv_s1_s2_pct,
    ROUND(100.0 * COUNT(*) FILTER (WHERE has_txn)
          / NULLIF(COUNT(*) FILTER (WHERE has_account), 0), 1)     AS conv_s2_s3_pct,
    ROUND(100.0 * COUNT(*) FILTER (WHERE is_active)
          / NULLIF(COUNT(*) FILTER (WHERE has_txn), 0), 1)         AS conv_s3_s4_pct,
    ROUND(100.0 * COUNT(*) FILTER (WHERE is_active)
          / NULLIF(COUNT(*), 0), 1)                                AS overall_conv_pct
FROM steps;

Kết quả một dòng cho toàn cảnh phễu: số khách còn lại ở mỗi bước, step conversion giữa các bước liền kề, và overall conversion. Nhìn cột nào tụt mạnh nhất là ra bước nghẽn. Chú ý mọi phép chia đều bọc NULLIF(..., 0) để không lỗi chia 0 khi một bước rỗng, và nhân 100.0 (numeric) trước khi ROUND để ép kiểu đúng.

Query 2 — Drop-off tường minh từng bước (định dạng "báo cáo phễu")

Trình bày phễu theo chiều dọc — mỗi bước một dòng, kèm số người, tỷ lệ so với đỉnh phễu, và drop-off so với bước liền trước dùng LAG():

-- ▶ Chạy được
WITH per_customer AS (
    SELECT c.id AS customer_id,
           (SELECT COUNT(*) FROM accounts a
            WHERE a.customer_id = c.id)                            AS n_accounts,
           (SELECT COUNT(*) FROM accounts a
            JOIN transactions t ON t.account_id = a.id
            WHERE a.customer_id = c.id AND t.amount <> 0)          AS n_txns
    FROM customers c
),
funnel AS (
    SELECT 1 AS step_no, 'S1_dang_ky'      AS step, COUNT(*) AS users FROM per_customer
    UNION ALL
    SELECT 2, 'S2_mo_tai_khoan', COUNT(*) FROM per_customer WHERE n_accounts >= 1
    UNION ALL
    SELECT 3, 'S3_giao_dich_dau', COUNT(*) FROM per_customer WHERE n_txns >= 1
    UNION ALL
    SELECT 4, 'S4_hoat_dong',     COUNT(*) FROM per_customer WHERE n_txns >= 2
)
SELECT step_no, step, users,
       ROUND(100.0 * users
             / NULLIF(MAX(users) OVER (), 0), 1)                  AS pct_of_top,
       ROUND(100.0 * (LAG(users) OVER (ORDER BY step_no) - users)
             / NULLIF(LAG(users) OVER (ORDER BY step_no), 0), 1)  AS drop_off_pct
FROM funnel
ORDER BY step_no;

Cột drop_off_pct là thứ nhà phân tích đọc đầu tiên: dòng nào có drop-off lớn nhất chính là điểm nghẽn. MAX(users) OVER () lấy số ở đỉnh phễu (bước 1) làm mẫu số cho pct_of_top, còn LAG() so với bước ngay trước để ra tỷ lệ rớt từng chặng.

Query 3 — Phễu theo phân khúc (cohort of funnel)

So sánh conversion theo thành phố (đại diện cho phân khúc/kênh trong thực tế) để thấy nhóm nào rớt nhiều nhất — đây là bước "so sánh phễu theo phân khúc" ở phần lý thuyết:

-- ▶ Chạy được
WITH per_customer AS (
    SELECT c.id AS customer_id, c.city,
           EXISTS (SELECT 1 FROM accounts a
                   WHERE a.customer_id = c.id)                     AS has_account,
           EXISTS (SELECT 1 FROM accounts a
                   JOIN transactions t ON t.account_id = a.id
                   WHERE a.customer_id = c.id AND t.amount <> 0)   AS has_txn
    FROM customers c
)
SELECT
    COALESCE(city, '(khong ro)')                                   AS segment,
    COUNT(*)                                                        AS registered,
    COUNT(*) FILTER (WHERE has_account)                            AS with_account,
    COUNT(*) FILTER (WHERE has_txn)                                AS with_txn,
    ROUND(100.0 * COUNT(*) FILTER (WHERE has_txn)
          / NULLIF(COUNT(*), 0), 1)                               AS overall_conv_pct
FROM per_customer
GROUP BY city
HAVING COUNT(*) >= 5
ORDER BY overall_conv_pct DESC NULLS LAST;

Cột overall_conv_pct xếp các phân khúc từ chuyển đổi cao xuống thấp. Trong thực tế, thay city bằng kênh thu hút hoặc loại thiết bị để tìm phân khúc "rò rỉ" nhất. HAVING COUNT(*) >= 5 loại các nhóm quá nhỏ khiến tỷ lệ nhiễu — một lưu ý quan trọng khi phân khúc phễu.

Bẫy thường gặp và lưu ý

Điểm cần khắc cốt: phễu là mô hình đơn giản hoá. Hành trình thật hiếm khi thẳng — khách có thể bỏ dở eKYC rồi quay lại ngày hôm sau, mở tài khoản trước khi hoàn tất định danh, hay nhảy bước. Phễu vẫn cực kỳ hữu ích như công cụ định vị điểm nghẽn, miễn là bạn hiểu nó là xấp xỉ chứ không phải bản đồ chính xác từng người.

Use case thực tế

Bối cảnh: App NCB có phễu onboarding mở tài khoản. Tháng 6/2026, đội product analytics dựng phễu 6 bước cho cohort 100.000 khách tải app (số minh hoạ):

Chẩn đoán: overall conversion 32%. Bước rớt nặng nhất là eKYC (36%) — 28.000 người bỏ cuộc. Phân khúc theo thiết bị lộ ra: iOS conversion eKYC 74%, Android đời cũ chỉ 51% (ảnh selfie/CMND mờ, đối chiếu thất bại). Time-to-convert eKYC có p90 = 6 phút — quá dài, khách nản.

Giả thuyết & thử nghiệm: đội đặt 2 giả thuyết — (a) thêm OCR tự điền trường từ ảnh CMND giảm ma sát nhập tay; (b) hướng dẫn chụp ảnh theo khung + kiểm tra chất lượng ảnh tại chỗ giảm tỷ lệ đối chiếu hỏng. Chạy A/B test trên bước eKYC (xem pa-07). Nhánh có OCR + hướng dẫn chụp nâng step conversion eKYC từ 64% lên 77%, kéo overall conversion phễu từ 32% lên 38% — thêm ~6.000 khách kích hoạt mỗi 100.000 lượt tải.

Mở rộng: cùng khung này, đội dựng thêm phễu mở thẻ tín dụng (đề nghị → nộp hồ sơ thu nhập → thẩm định → duyệt hạn mức → kích hoạt thẻ → chi tiêu đầu tiên) và phễu vay (đăng ký khoản vay → định danh → chấm điểm tín dụng → duyệt → giải ngân). Mỗi phễu có điểm nghẽn riêng: phễu thẻ thường nghẽn ở thẩm định thu nhập, phễu vay nghẽn ở chấm điểm/duyệt — và phễu ngược cho thấy khách được duyệt nhanh thường đã có lịch sử giao dịch dày, gợi ý ưu tiên pre-approve nhóm khách hiện hữu.

Ghi nhớ

• Phễu = chuỗi bước tới mục tiêu; đo conversion (đi tiếp) và drop-off (rớt) từng bước để tìm điểm nghẽn.
• Bốn thành phần: các bước có thứ tự, tập người vào phễu, đếm distinct user (không phải event), và conversion window.
• Loại phễu: ordered vs any-order; có vs không giới hạn thời gian. Phễu tối ưu trải nghiệm luôn nên có conversion window.
• Ba chỉ số: overall conversion (đầu→cuối), step conversion / drop-off (từng chặng, hành động được nhất), time-to-convert (dùng median/p90, không dùng trung bình).
• Phân tích: tìm bước rớt cao nhất → so sánh theo phân khúc/kênh/thiết bị/cohort → phễu ngược tìm đường người thắng → giả thuyết → A/B test.
• Bẫy: đếm event, survivorship bias, bỏ window, giả định tuyến tính, so cohort chưa chín, trung bình time-to-convert.
• Ngân hàng số: phễu onboarding/eKYC thường nghẽn ở bước eKYC (ảnh mờ, nhập tay nhiều); còn có phễu mở thẻ và vay với điểm nghẽn riêng.
• Phễu là mô hình xấp xỉ để định vị nghẽn, không phải bản đồ chính xác từng hành trình.