Phân tích sản phẩm 6 — CLV & Churn

Hai câu hỏi tiền bạc của product analytics

Ở pa-04 — Cohort & Retention ta đo có bao nhiêu khách ở lại. Nhưng giữ chân chỉ có nghĩa khi biết giữ ai đáng giá và ai sắp rời — hai câu hỏi tiền bạc của bài này:

• CLV (Customer Lifetime Value) — khách này đáng bao nhiêu? Tổng giá trị một khách mang lại suốt vòng đời quan hệ.
• Churn — khách này sắp rời chưa? Xác suất và thời điểm khách ngừng tạo giá trị.

Ghép hai câu hỏi ra một bảng ưu tiên: dồn nguồn lực vào khách giá trị cao đang có rủi ro rời bỏ cao, thay vì chăm đều mọi người. Đây là nơi analytics chuyển thẳng thành lợi nhuận.

Customer Lifetime Value (CLV / LTV)

CLV (còn gọi LTV — Lifetime Value) là tổng giá trị ròng (theo lợi nhuận biên, không phải doanh thu gộp) mà một khách dự kiến mang lại suốt thời gian còn là khách. "Suốt vòng đời" là điểm mấu chốt: một giao dịch lẻ nói rất ít, tổng đóng góp qua nhiều năm mới cho biết khách đó quan trọng thế nào.

Vì sao CLV quan trọng: nó định hướng chi phí thu hút

CLV không phải con số để ngắm — nó là trần ngân sách cho thu hút và giữ chân. Ghép với CAC (Customer Acquisition Cost — chi phí thu hút một khách) ra tỷ số quan trọng nhất của kinh tế sản phẩm:

LTV : CAC

• LTV:CAC ≈ 3:1 thường được coi là vùng khỏe mạnh: mỗi đồng bỏ ra thu hút khách sinh ~3 đồng giá trị vòng đời.
• < 1:1 là lỗ: trả nhiều hơn giá trị khách mang lại → mô hình không bền, càng scale càng cháy tiền.
• > 5:1 nghe tốt nhưng thường nghĩa là đang chi quá ít cho tăng trưởng — bỏ lỡ cơ hội mở rộng; nên tăng chi acquisition.

Chỉ số đi kèm là CAC payback period — bao lâu giá trị tích lũy bù lại chi phí thu hút. Ngân hàng số chấp nhận payback dài (12–24 tháng) vì quan hệ khách kéo dài nhiều năm.

CLV còn quyết định ai đáng đầu tư giữ chân: khách CLV cao xứng đáng ưu đãi đắt tiền (RM chăm riêng, miễn phí dịch vụ); khách CLV thấp thì mọi chi phí giữ chân vượt giá trị họ mang lại đều là lỗ.

Cách tính: lịch sử vs dự đoán

Có hai họ phương pháp, khác nhau ở chỗ nhìn về quá khứ hay tương lai:

Historic CLV đơn giản là cộng dồn lợi nhuận biên các giao dịch đã qua của khách — chính là thứ SQL bên dưới xấp xỉ được từ dữ liệu thật.

Công thức dự đoán đơn giản

Khi chưa cần mô hình phức tạp, hai công thức xấp xỉ được dùng phổ biến.

(1) Từ ARPU và tuổi thọ khách:

CLV ≈ ARPU × Tuổi thọ trung bình (customer lifespan)

trong đó ARPU (Average Revenue Per User) là doanh thu/lợi nhuận biên trung bình mỗi khách mỗi kỳ, và tuổi thọ là số kỳ trung bình khách còn ở lại.

(2) Từ margin và tỷ lệ giữ chân (mô hình vòng đời hình học, gắn thẳng với retention ở pa-04):

CLV ≈ margin_mỗi_kỳ × ( retention_rate / (1 − retention_rate) )

Cầu nối trực giác: nếu retention mỗi kỳ là r, thì tuổi thọ kỳ vọng = 1 / (1 − r) (kỳ vọng của phân phối hình học). Ví dụ retention tháng 90% → tuổi thọ ≈ 10 tháng; retention 95% → ≈ 20 tháng. Đây là lý do vì sao cải thiện retention vài điểm phần trăm lại làm CLV nhảy vọt — mối quan hệ là phi tuyến. Bản có chiết khấu thời gian dùng r / (1 + i − r) với i là lãi suất chiết khấu, tránh cộng dồn giá trị tương lai xa như ngang giá trị hiện tại.

Mô hình nâng cao (khái quát)

Với sản phẩm non-contractual (không hợp đồng, khách tự do đến/đi không "hủy" rõ ràng — đúng như ngân hàng), chuẩn công nghiệp là bộ đôi BG/NBD + Gamma-Gamma:

• BG/NBD (Beta-Geometric / Negative Binomial Distribution) mô hình hóa khách sẽ giao dịch bao nhiêu lần nữa (tần suất) và khả năng còn "sống" hay đã âm thầm bỏ đi — chỉ cần ba đặc trưng: recency, frequency, tuổi khách (T).
• Gamma-Gamma mô hình hóa giá trị tiền trung bình mỗi giao dịch, độc lập với tần suất.

Nhân kỳ vọng số giao dịch tương lai (BG/NBD) với giá trị trung bình mỗi giao dịch (Gamma-Gamma) ra predictive CLV từng khách, giữ nền tảng xác suất và dễ giải thích. Hướng thay thế là ML (gradient boosting/deep learning) hồi quy trực tiếp CLV từ hàng trăm đặc trưng — mạnh hơn khi dữ liệu lớn nhưng khó diễn giải. Feature engineering thường tựa vào mlops-03 — Feature Store để tái dùng giữa training và serving.

CLV trong ngân hàng: khó hơn nhiều

CLV ngân hàng không giống thương mại điện tử vì giá trị không nằm ở "giá trị giỏ hàng":

• Nhiều sản phẩm cùng lúc: một khách có tài khoản thanh toán, tiết kiệm, thẻ tín dụng, khoản vay, bảo hiểm. CLV phải cộng dồn giá trị theo quan hệ tổng thể, không chỉ một dòng sản phẩm.
• Nguồn thu đa dạng, phần lớn không phải "giao dịch": lãi ròng (chênh lệch lãi cho vay − huy động trên số dư), phí (dịch vụ, thường niên thẻ, chuyển tiền), và giá trị số dư (tiền gửi rẻ để cho vay lại). Một khách để 500 triệu tiết kiệm có thể "im lặng" nhưng CLV cực cao — điều mà đếm giao dịch bỏ sót.
• Vòng đời rất dài: quan hệ tính bằng chục năm; cross-sell (bán chéo vay/thẻ) là phần lớn CLV.

Hệ quả: ngân hàng ưu tiên customer-level relationship value — tổng hợp lãi + phí + giá trị số dư qua tất cả sản phẩm — hơn CLV theo giao dịch đơn thuần. SQL bên dưới chỉ xấp xỉ phần giao dịch (proxy) — giới hạn của dữ liệu sandbox.

Churn: mặt kia của giá trị

Churn (rời bỏ) là phần bù của retention (xem pa-04): trong một kỳ, retention_rate + churn_rate = 1. Churn quan trọng vì mỗi khách churn là một CLV bị mất — nó nối trực tiếp về tiền.

Định nghĩa churn trong ngân hàng: khó vì hiếm khi "đóng hẳn"

Với sản phẩm hợp đồng (contractual — như thuê bao Netflix) churn rõ ràng: khách bấm hủy. Ngân hàng ngược lại — khách rất hiếm khi đóng hẳn tài khoản (thủ tục phiền, còn liên kết trả lương/hóa đơn), họ chỉ âm thầm ngừng dùng. Vì thế phải định nghĩa churn "ngầm" / silent churn theo hành vi:

• Ngừng hoạt động: không giao dịch nào trong ≥ N ngày (ví dụ ≥90 ngày).
• Giảm số dư / rút dần tiền: số dư trung bình tụt sâu → dấu hiệu chuyển tiền đi nơi khác.
• Chuyển sang ngân hàng khác: lương về tài khoản khác, giao dịch chuyển sang ví/ngân hàng đối thủ.

Ngưỡng N chọn theo phân bố khoảng cách giữa các giao dịch của khách active (ví dụ percentile 90 của gap) — không đặt tùy tiện. Định nghĩa quá chặt báo churn oan; quá lỏng phát hiện muộn.

Churn rate và voluntary vs involuntary

Churn rate trong kỳ = số khách churn / số khách đầu kỳ (đếm distinct khách). Cần phân biệt hai loại vì cách xử lý khác hẳn:

Involuntary churn thường bị bỏ quên nhưng dễ cứu nhất — chỉ cần quy trình vận hành tốt (nhắc gia hạn thẻ, retry thanh toán) là kéo lại được đáng kể mà không cần ưu đãi tốn kém.

Churn prediction: từ mô tả sang dự báo (ML)

Đo churn đã xảy ra là hồi tố; giá trị thật nằm ở dự báo khách nào sắp churn để can thiệp trước. Đây là bài toán phân loại nhị phân (churn / không churn trong cửa sổ tới, ví dụ 90 ngày).

Dấu hiệu cảnh báo sớm (early warning signals)

Trước khi churn hẳn, hành vi thường phát tín hiệu:

• Giảm tần suất giao dịch: từ 20 giao dịch/tháng xuống 3.
• Giảm số dư: rút dần, số dư trung bình tụt.
• Khiếu nại / liên hệ hỗ trợ tăng (đặc biệt chưa được giải quyết).
• Hết sản phẩm chính: tất toán khoản vay, đóng thẻ, sổ tiết kiệm đáo hạn không tái tục — mất "mỏ neo" giữ khách.
• Ngừng dùng kênh số: không đăng nhập app, tắt thông báo.

Feature và mô hình

Từ các tín hiệu trên dựng feature cho mô hình — thường là biến hành vi trên nhiều cửa sổ thời gian:

• Recency/Frequency/Monetary (nền RFM — xem cách xây RFM ở loyalty-06 — Analytics & Segmentation).
• Xu hướng (trend): tỷ lệ số dư/số giao dịch tháng này so với trung bình 3 tháng trước (biến delta bắt được "đang tụt").
• Đặc điểm quan hệ: số sản phẩm đang giữ, tenure (tuổi khách), có lương về hay không.
• Tín hiệu dịch vụ: số khiếu nại, số lần liên hệ hỗ trợ.

Mô hình phân loại phổ biến: logistic regression (dễ giải thích, làm baseline), gradient boosting (XGBoost/LightGBM) (thường thắng về độ chính xác trên dữ liệu bảng), hoặc mạng nơ-ron cho chuỗi hành vi. Đầu ra là churn risk score (điểm rủi ro churn ∈ [0,1]) cho từng khách. Vòng đời huấn luyện–triển khai–giám sát (drift khi hành vi khách đổi) theo chuẩn MLOps — xem mlops-06 — Monitoring & Drift; và với dữ liệu khách nhạy cảm phải tuân gov-07 — Privacy & Compliance.

Từ điểm rủi ro tới hành động

Điểm rủi ro chỉ có giá trị nếu nối tới hành động:

Điểm mấu chốt: đo hiệu quả can thiệp bằng nhóm đối chứng (giữ một phần khách rủi ro cao không nhận ưu đãi) — nếu không, không biết chiến dịch thực sự giảm churn hay chỉ tốn tiền cho người dù sao cũng ở lại. Đây là tư duy A/B testing của pa-07 — Experimentation.

Ma trận CLV × rủi ro churn: nơi ra quyết định

CLV và churn ghép lại thành công cụ ưu tiên mạnh nhất — ma trận giá trị × rủi ro. Không thể chăm mọi khách như nhau; ma trận này chỉ ra dồn nguồn lực vào đâu:

• CLV cao + rủi ro cao (góc trên-phải): giữ bằng mọi giá. Đây là nhóm sinh lời nhất đang lung lay — xứng đáng can thiệp đắt tiền (RM gọi trực tiếp, ưu đãi lãi suất, miễn phí). Bỏ lỡ một khách ở đây là mất một CLV lớn.
• CLV cao + rủi ro thấp (trên-trái): nuôi dưỡng. Đang tốt — đừng làm phiền bằng ưu đãi thừa; tập trung cross-sell và giữ hài lòng để họ ở lại lâu hơn.
• CLV thấp + rủi ro cao (dưới-phải): tự động hóa. Chăm bằng kênh chi phí thấp (email, push); không đổ ưu đãi tốn kém vì chi phí giữ dễ vượt giá trị mang lại.
• CLV thấp + rủi ro thấp (dưới-trái): để yên / cân nhắc để rời. Đôi khi để một khách chi phí-cao-giá-trị-thấp rời đi lại tốt cho lợi nhuận.

Đo lường & hành động: với mỗi ô, retention campaign được thiết kế riêng theo giá trị và rủi ro, và luôn đo bằng nhóm đối chứng để biết giảm churn thực và giá trị giữ lại được có vượt chi phí chiến dịch không (ROI của retention).

SQL: xấp xỉ CLV, phát hiện churn ngầm, xếp hạng giá trị

Sandbox có customers, accounts, transactions. Ta xấp xỉ CLV theo giao dịch (proxy — nhớ rằng CLV ngân hàng thật còn gồm lãi/phí/số dư, không có trong dữ liệu này), phát hiện khách im lặng làm proxy churn, và xếp hạng khách theo giá trị.

Query 1 — CLV lịch sử xấp xỉ mỗi khách

Với mỗi khách: tổng giá trị giao dịch, giá trị trung bình, số giao dịch, và số tháng hoạt động (khoảng cách giữa giao dịch đầu và cuối) — proxy cho tuổi thọ. Nối transactions → accounts → customers vì transactions không có customer_id:

-- ▶ Chạy được
SELECT
    c.id                                             AS customer_id,
    c.full_name,
    c.city,
    COUNT(t.id)                                      AS txn_count,
    ROUND(SUM(ABS(t.amount))::numeric, 0)            AS total_value,
    ROUND(AVG(ABS(t.amount))::numeric, 0)            AS avg_txn_value,
    MIN(t.created_at)::date                          AS first_txn,
    MAX(t.created_at)::date                          AS last_txn,
    (EXTRACT(YEAR  FROM MAX(t.created_at)) - EXTRACT(YEAR  FROM MIN(t.created_at))) * 12
      + (EXTRACT(MONTH FROM MAX(t.created_at)) - EXTRACT(MONTH FROM MIN(t.created_at))) + 1
                                                     AS active_months
FROM customers c
JOIN accounts a     ON a.customer_id = c.id
JOIN transactions t ON t.account_id  = a.id
GROUP BY c.id, c.full_name, c.city
ORDER BY total_value DESC;

ABS(t.amount) để cả giao dịch ghi nợ/ghi có đều tính là "giá trị luân chuyển" (proxy). active_months = chênh lệch tháng giữa giao dịch đầu và cuối, cộng 1 để tháng duy nhất cũng đếm là 1. Ép ::numeric trước ROUND. total_value / active_months chính là ARPU xấp xỉ mỗi khách — nền cho công thức CLV ≈ ARPU × tuổi thọ.

Query 2 — Dấu hiệu churn: khách im lặng (không giao dịch N tháng gần nhất)

So MAX(created_at) của mỗi khách với NOW(). Khách có giao dịch cuối cách nay lâu = churn ngầm. Ở đây gắn cờ theo số tháng im lặng:

-- ▶ Chạy được
WITH last_activity AS (
    SELECT
        c.id                     AS customer_id,
        c.full_name,
        MAX(t.created_at)        AS last_txn
    FROM customers c
    JOIN accounts a     ON a.customer_id = c.id
    JOIN transactions t ON t.account_id  = a.id
    GROUP BY c.id, c.full_name
)
SELECT
    customer_id,
    full_name,
    last_txn::date                                                   AS last_txn,
    ROUND(EXTRACT(EPOCH FROM (NOW() - last_txn)) / 86400.0)          AS days_silent,
    CASE
        WHEN NOW() - last_txn > INTERVAL '6 months'  THEN 'churned'
        WHEN NOW() - last_txn > INTERVAL '3 months'  THEN 'at_risk'
        ELSE 'active'
    END                                                             AS churn_status
FROM last_activity
ORDER BY last_txn ASC;

NOW() - last_txn cho khoảng cách tới hiện tại; so với INTERVAL để gắn nhãn active / at_risk / churned — đây là silent churn theo ngưỡng im lặng. days_silent quy về số ngày để tiện xếp hạng. Danh sách at_risk chính là đầu vào cho chiến dịch giữ chân sớm.

Query 3 — Xếp hạng khách theo giá trị bằng NTILE

Chia khách thành 5 nhóm giá trị bằng nhau (NTILE(5)) theo tổng giá trị giao dịch — quintile 5 là nhóm giá trị cao nhất. Đây là trục CLV của ma trận giá trị × rủi ro:

-- ▶ Chạy được
WITH cust_value AS (
    SELECT
        c.id                        AS customer_id,
        c.full_name,
        SUM(ABS(t.amount))          AS total_value,
        COUNT(t.id)                 AS txn_count
    FROM customers c
    JOIN accounts a     ON a.customer_id = c.id
    JOIN transactions t ON t.account_id  = a.id
    GROUP BY c.id, c.full_name
)
SELECT
    customer_id,
    full_name,
    ROUND(total_value::numeric, 0)                                   AS total_value,
    txn_count,
    NTILE(5) OVER (ORDER BY total_value)                            AS value_quintile,
    ROUND((100.0 * PERCENT_RANK() OVER (ORDER BY total_value))::numeric, 1)    AS value_percentile
FROM cust_value
ORDER BY total_value DESC;

NTILE(5) OVER (ORDER BY total_value) gán mỗi khách vào một trong 5 nhóm giá trị (1 = thấp nhất, 5 = cao nhất). PERCENT_RANK() cho vị trí phần trăm liên tục để cắt ngưỡng linh hoạt (ví dụ top 10%). Nhóm quintile 5 chính là "khách VIP" cần ưu tiên giữ chân — ghép với churn_status của Query 2 (theo customer_id) sẽ dựng được ma trận CLV × rủi ro trong thực tế.

Use case thực tế

Bối cảnh: Quý 2/2026, NCB Digital muốn tối ưu ngân sách giữ chân 8 tỷ đồng cho mảng khách hàng ưu tiên. Đội product analytics dựng bảng CLV × rủi ro churn (số minh hoạ).

Bước 1 — Xếp giá trị: chạy Query 3, chia khách thành 5 quintile theo giá trị quan hệ (tổng hợp lãi + phí + số dư, không chỉ giao dịch). Quintile 5 (top 20%) đóng góp ~68% lợi nhuận — quy tắc 80/20 rõ rệt.

Bước 2 — Chấm rủi ro churn: mô hình gradient boosting cho churn risk score. Feature mạnh nhất theo importance: số dư giảm >40% so trung bình 3 tháng, tất toán sản phẩm chính (khoản vay/sổ tiết kiệm đáo hạn), và giảm tần suất đăng nhập app.

Bước 3 — Ghép ma trận (minh hoạ):

Bước 4 — Dồn lực và đo: dồn phần lớn ngân sách vào ô CLV cao × rủi ro cao (1.200 khách). Với LTV:CAC giữ chân, chi ưu đãi ~5 triệu/khách để bảo vệ CLV 45 triệu là 9:1 — thừa đáng. Chạy chiến dịch với nhóm đối chứng 10% (không nhận ưu đãi): sau 3 tháng, nhóm được chăm churn 8% so với nhóm đối chứng 21% → giảm churn tuyệt đối 13 điểm, giữ lại ~140 khách × 45 triệu CLV = ~6,3 tỷ giá trị bảo toàn, vượt xa chi phí ~6 tỷ ưu đãi + vận hành. Ngược lại, ô CLV thấp × rủi ro cao chỉ nhận email tự động — nếu đổ ưu đãi vào đây thì chi phí giữ vượt CLV 3–4 triệu, lỗ chắc.

Ghi nhớ

• CLV/LTV = tổng giá trị (lợi nhuận biên) một khách mang lại suốt vòng đời; nó là trần ngân sách cho thu hút và giữ chân, cân qua LTV:CAC (~3:1 khỏe mạnh; <1 lỗ; >5 chi quá ít).
• Historic CLV cộng dồn đóng góp đã qua (đơn giản, chắc chắn); predictive CLV dự báo tương lai (quyết định cho khách mới) — mô hình chuẩn cho non-contractual là BG/NBD + Gamma-Gamma, hoặc ML.
• Công thức xấp xỉ: CLV ≈ ARPU × tuổi thọ và CLV ≈ margin × r/(1−r); tuổi thọ ≈ 1/(1−retention) → cải thiện retention vài điểm làm CLV nhảy vọt (phi tuyến).
• CLV ngân hàng khó hơn: nhiều sản phẩm, thu từ lãi + phí + giá trị số dư — dùng giá trị quan hệ tổng thể, không chỉ giao dịch (khách để số dư lớn có thể "im" nhưng CLV cao).
• Churn ngân hàng = churn ngầm/silent (hiếm đóng hẳn tài khoản): ngừng hoạt động ≥N ngày, giảm số dư, chuyển sang ngân hàng khác. Phân biệt voluntary (cải thiện sản phẩm/giá) vs involuntary (nhắc gia hạn, retry — dễ cứu nhất).
• Churn prediction là bài toán phân loại: tín hiệu sớm (giảm tần suất/số dư, khiếu nại, hết sản phẩm chính) → feature (RFM, trend, quan hệ) → churn risk score → hành động giữ chân; luôn đo bằng nhóm đối chứng.
• Ma trận CLV × rủi ro churn: CLV cao × rủi ro cao giữ bằng mọi giá; cao × thấp nuôi dưỡng/cross-sell; thấp × cao tự động hóa chi phí thấp; thấp × thấp để yên. Dồn lực đúng ô, đo ROI retention.