Phân tích & phân khúc khách hàng cho loyalty

Series đã dựng xong phần nền: tổng quan loyalty giải thích vì sao ngân hàng làm loyalty, hạng & quyền lợi chỉ cách phục vụ khác biệt theo giá trị, và kiến trúc dữ liệu mô tả dữ liệu chảy về đâu. Bài này trả lời câu hỏi tiếp theo, cũng là câu quan trọng nhất về mặt kinh doanh: có dữ liệu rồi thì dùng để quyết định gì?

Một chương trình loyalty không được đo lường chỉ là cỗ máy phát điểm và tiêu ngân sách. Phân tích loyalty là lớp biến hành vi khách hàng thành hành động có mục tiêu: nhắm đúng ưu đãi, tăng ROI ngân sách, giữ nhóm giá trị cao và can thiệp sớm với nhóm sắp rời bỏ. Bài viết đi qua sáu khối: vì sao phân tích, RFM, CLV, churn, đo hiệu quả chương trình, và cá nhân hoá & chiến dịch; kết bằng use case giữ chân nhóm at-risk và phần ghi nhớ.

Quy ước: các khối text là minh hoạ logic/dữ liệu. Các khối SQL được đánh dấu "▶ Chạy được trong SQL Builder" là câu SELECT/WITH đơn, chạy trên sandbox PostgreSQL với schema mẫu ở cuối phần đầu. Trong schema mẫu ta coi transactions như giao dịch chi tiêu để minh hoạ RFM — thực tế bạn sẽ thay bằng bảng chi tiêu thẻ.

1. Vì sao phân tích loyalty

Ngân sách loyalty là hữu hạn: mỗi điểm, mỗi ưu đãi hoàn tiền, mỗi voucher đều là chi phí thực. Không phân tích, ngân hàng rải đều ngân sách cho mọi khách — vừa lãng phí với nhóm ít giá trị, vừa không đủ "đánh động" nhóm giá trị cao đang bị đối thủ chào mời. Phân tích loyalty phục vụ bốn mục tiêu:

• Nhắm đúng ưu đãi. Thay vì gửi cùng một ưu đãi cho toàn bộ tệp, ta gửi ưu đãi phù hợp với hành vi từng nhóm. Khách hay ăn nhà hàng nhận ưu đãi F&B; khách sắp rời bỏ nhận ưu đãi giữ chân mạnh hơn.
• Tăng ROI. Khi biết nhóm nào phản hồi tốt, ta dồn ngân sách vào nơi tạo incremental spend (chi tiêu tăng thêm nhờ ưu đãi), cắt ngân sách ở nơi khách "vẫn sẽ chi tiêu dù không có ưu đãi".
• Giữ khách giá trị cao. Nhóm champions/VIP đóng góp phần lớn doanh thu (quy luật Pareto). Mất một khách nhóm này tốn kém hơn nhiều so với mất chục khách nhỏ.
• Giảm churn. Nhận diện sớm khách đang giảm hoạt động và can thiệp trước khi họ rời hẳn — rẻ hơn nhiều so với giành lại khách đã mất.

Toàn bộ chuỗi này khép thành một vòng lặp: dữ liệu → phân khúc/dự báo → hành động → đo lại. Sơ đồ dưới đây minh hoạ luồng đó.

Vòng lặp này chỉ chạy được nếu có nền dữ liệu đủ tốt. Trong thực tế các bảng phân tích dưới đây được dựng trong kho/lakehouse — BigQuery làm nơi lưu và tính, dbt để mô hình hoá và kiểm thử dữ liệu, Looker để dựng dashboard loyalty. Các câu SQL trong bài chạy trên Postgres sandbox, nhưng logic chuyển sang BigQuery gần như nguyên vẹn.

Schema mẫu (dùng cho các câu SQL bên dưới)

customers(id, full_name, city, created_at date)
accounts(id, customer_id, account_no, balance, currency)
transactions(id, account_id, amount, kind, created_at timestamp)
employees(id, name, department_id, salary, hired_at date)
departments(id, name)

Quan hệ khoá cần nhớ khi join: transactions.account_id → accounts.id, và tên khách lấy từ customers.full_name qua accounts.customer_id → customers.id. Không có cột customer_name — sai cột là câu SQL sẽ lỗi.

2. RFM — Recency, Frequency, Monetary

RFM là kỹ thuật phân khúc kinh điển, dễ hiểu và cực kỳ hiệu quả, dựa trên ba câu hỏi về hành vi giao dịch:

• Recency (R): khách chi tiêu gần đây đến mức nào? Càng gần, càng "nóng".
• Frequency (F): khách chi tiêu thường xuyên thế nào? Số lần giao dịch trong kỳ.
• Monetary (M): khách chi tiêu bao nhiêu tổng cộng?

Ba con số thô này chưa so sánh được giữa các khách. Bước then chốt là chấm điểm tương đối bằng cách chia tệp thành các nhóm bằng nhau — thường dùng ntile (NTILE(4) hoặc NTILE(5)). Mỗi khách nhận điểm 1–4 (hoặc 1–5) cho từng chiều, điểm cao = tốt hơn. Lưu ý điểm dễ sai: với Recency, số nhỏ hơn (mới hơn) là tốt hơn, nên khi chấm điểm phải đảo chiều so với F và M.

2.1. RFM thô

Trước tiên tính ba chỉ số thô theo từng khách. Ở đây recency_days là số ngày kể từ giao dịch gần nhất tới hôm nay.

▶ Chạy được trong SQL Builder

SELECT
    c.id                                        AS customer_id,
    c.full_name,
    MAX(t.created_at)::date                     AS last_txn_date,
    CURRENT_DATE - MAX(t.created_at)::date       AS recency_days,
    COUNT(*)                                     AS frequency,
    SUM(t.amount)                               AS monetary
FROM transactions t
JOIN accounts  a ON t.account_id = a.id
JOIN customers c ON a.customer_id = c.id
GROUP BY c.id, c.full_name
ORDER BY monetary DESC;

Kết quả cho ba trụ cột R/F/M ở dạng thô: ngày giao dịch gần nhất, số lần, tổng tiền. Đây là đầu vào để chấm điểm.

2.2. Chấm điểm RFM bằng NTILE

Bước tiếp theo là biến số thô thành điểm 1–4 để so sánh khách với nhau. NTILE(4) chia tệp thành 4 nhóm bằng nhau theo thứ tự sắp xếp. Với F và M, sắp tăng dần thì nhóm 4 = cao nhất = tốt nhất. Với R, ta muốn recency_days nhỏ được điểm cao, nên sắp recency_days giảm dần (DESC) rồi lấy ntile, khi đó nhóm 4 rơi vào khách mới nhất.

▶ Chạy được trong SQL Builder

WITH rfm AS (
    SELECT
        c.id                                    AS customer_id,
        c.full_name,
        CURRENT_DATE - MAX(t.created_at)::date   AS recency_days,
        COUNT(*)                                 AS frequency,
        SUM(t.amount)                           AS monetary
    FROM transactions t
    JOIN accounts  a ON t.account_id = a.id
    JOIN customers c ON a.customer_id = c.id
    GROUP BY c.id, c.full_name
)
SELECT
    customer_id,
    full_name,
    recency_days,
    frequency,
    monetary,
    NTILE(4) OVER (ORDER BY recency_days DESC) AS r_score,
    NTILE(4) OVER (ORDER BY frequency)         AS f_score,
    NTILE(4) OVER (ORDER BY monetary)          AS m_score
FROM rfm
ORDER BY m_score DESC, f_score DESC, r_score DESC;

Mỗi khách giờ có bộ ba điểm, ví dụ R=4, F=4, M=4 (bộ ba tốt nhất) hay R=1, F=1, M=1 (kém nhất trên cả ba chiều).

2.3. Diễn giải segment

Từ điểm R/F/M, ta ánh xạ sang nhãn segment dễ hiểu cho đội kinh doanh. Không có bảng chuẩn quốc tế duy nhất, nhưng cách gọi phổ biến gồm:

• Champions (R cao, F cao, M cao): mua gần đây, thường xuyên, chi nhiều. Nhóm quý nhất — thưởng, cross-sell, biến thành đại sứ.
• Loyal / Potential Loyalist (F, M khá, R chưa cao nhất): trung thành, đáng đầu tư để nâng lên Champions.
• At-Risk / Cannot Lose Them (F, M từng cao nhưng R thấp): khách giá trị đang nguội đi — ưu tiên giữ chân.
• Hibernating / Lost (R, F, M đều thấp): ngủ đông hoặc gần như đã mất — chiến dịch "đánh thức" chi phí thấp, kỳ vọng khiêm tốn.

Ánh xạ có thể làm ngay trong SQL bằng CASE trên điểm ntile:

▶ Chạy được trong SQL Builder

WITH rfm AS (
    SELECT
        c.id AS customer_id, c.full_name,
        CURRENT_DATE - MAX(t.created_at)::date AS recency_days,
        COUNT(*) AS frequency, SUM(t.amount) AS monetary
    FROM transactions t
    JOIN accounts  a ON t.account_id = a.id
    JOIN customers c ON a.customer_id = c.id
    GROUP BY c.id, c.full_name
),
scored AS (
    SELECT
        customer_id, full_name, recency_days, frequency, monetary,
        NTILE(4) OVER (ORDER BY recency_days DESC) AS r,
        NTILE(4) OVER (ORDER BY frequency)         AS f,
        NTILE(4) OVER (ORDER BY monetary)          AS m
    FROM rfm
)
SELECT
    full_name, r, f, m,
    CASE
        WHEN r >= 3 AND f >= 3 AND m >= 3 THEN 'Champions'
        WHEN f >= 3 AND m >= 3            THEN 'At-Risk / Cannot Lose'
        WHEN r >= 3                       THEN 'Recent / Promising'
        ELSE                                  'Hibernating / Lost'
    END AS segment
FROM scored
ORDER BY m DESC, f DESC;

Trong ngân hàng, RFM thường được tính riêng theo kênh chi tiêu (thẻ tín dụng, thẻ ghi nợ, ví) vì hành vi mỗi kênh khác nhau, và cửa sổ thời gian (ví dụ 12 tháng gần nhất) nên cố định để so sánh giữa các kỳ.

3. CLV — Customer Lifetime Value

RFM nhìn hiện trạng; CLV nhìn tương lai: một khách dự kiến mang lại bao nhiêu giá trị trong suốt vòng đời quan hệ với ngân hàng. CLV là thước đo để trả lời câu hỏi ngân sách: đáng chi bao nhiêu để có/giữ một khách?

3.1. Ước lượng đơn giản

Công thức nền tảng, dễ giải thích:

CLV ≈ Giá trị TB mỗi giao dịch × Tần suất giao dịch × Vòng đời khách

Ví dụ: khách chi trung bình 2 triệu/giao dịch, 30 giao dịch/năm, gắn bó 6 năm → doanh số vòng đời ≈ 2tr × 30 × 6 = 360 triệu. Đây là doanh thu, chưa phải lợi nhuận. Nhân thêm biên lợi nhuận (margin) để ra giá trị lợi nhuận: nếu ngân hàng lãi ~3% trên doanh số đó thì phần đóng góp là ~10,8 triệu. Với ngân hàng, nguồn giá trị đa dạng hơn bán lẻ: phí interchange từ chi tiêu thẻ, chênh lệch lãi (NIM) trên số dư, phí dịch vụ, thu nhập từ cross-sell (vay, bảo hiểm).

Ta có thể tính một proxy CLV thô ngay trên schema mẫu: ước "vòng đời tính đến nay" bằng số năm kể từ customers.created_at, và tần suất bằng số giao dịch chia số năm đó.

▶ Chạy được trong SQL Builder

SELECT
    c.id AS customer_id,
    c.full_name,
    SUM(t.amount)                                          AS total_spend,
    COUNT(*)                                               AS txn_count,
    ROUND(AVG(t.amount), 0)                                AS avg_txn_value,
    GREATEST(EXTRACT(YEAR FROM AGE(CURRENT_DATE, c.created_at)), 1) AS tenure_years,
    ROUND(
        SUM(t.amount)
        / GREATEST(EXTRACT(YEAR FROM AGE(CURRENT_DATE, c.created_at)), 1),
        0
    )                                                      AS spend_per_year
FROM transactions t
JOIN accounts  a ON t.account_id = a.id
JOIN customers c ON a.customer_id = c.id
GROUP BY c.id, c.full_name, c.created_at
ORDER BY spend_per_year DESC;

AGE() cho khoảng cách thời gian, EXTRACT(YEAR ...) lấy số năm; GREATEST(..., 1) tránh chia cho 0 với khách mới trong năm. spend_per_year là mẫu số giá trị hằng năm — nhân với vòng đời kỳ vọng sẽ ra CLV dự phóng.

3.2. Hướng nâng cao

Công thức nhân đơn giản giả định khách chi đều mãi mãi — không đúng. Cách tinh chỉnh:

• Chiết khấu dòng tiền: giá trị tương lai đáng giá ít hơn hiện tại, nên chia dòng tiền các năm sau cho hệ số chiết khấu.
• Xác suất còn hoạt động: thay "vòng đời cố định" bằng tỷ lệ giữ chân (retention rate) — CLV theo mô hình margin / churn_rate, hoặc mô hình xác suất (BG/NBD, Pareto/NBD) cho khách phi hợp đồng.
• CLV dự đoán bằng mô hình: dùng đặc trưng hành vi dự phóng giá trị, tính trong kho dữ liệu.

CLV nối trực tiếp với bài hạng & quyền lợi: ngân sách quyền lợi mỗi hạng nên tỷ lệ với CLV của nhóm khách hạng đó, để "chi phí quyền lợi < giá trị khách mang lại" luôn đúng.

4. Churn — dự báo và giữ chân

4.1. Định nghĩa churn trong ngân hàng

Trong ngân hàng, tài khoản hiếm khi bị đóng hẳn — khách thường churn âm thầm: ngừng dùng thẻ, rút gần hết số dư, chuyển giao dịch sang ngân hàng khác nhưng vẫn để tài khoản "ngủ". Vì thế churn thường định nghĩa theo hành vi, không phải theo trạng thái đóng tài khoản:

• Không có giao dịch chi tiêu trong N tháng (ví dụ 90 ngày).
• Số dư/doanh số giảm quá một ngưỡng so với trung bình trước đó.
• Ngừng dùng sản phẩm chủ lực (thẻ tín dụng không phát sinh dư nợ).

Định nghĩa này chính là Recency trong RFM ở góc nhìn cảnh báo. Ta có thể liệt kê khách "im lặng" ngay trên schema mẫu.

▶ Chạy được trong SQL Builder

SELECT
    c.full_name,
    MAX(t.created_at)::date                   AS last_txn_date,
    CURRENT_DATE - MAX(t.created_at)::date      AS days_since_last_txn,
    CASE
        WHEN CURRENT_DATE - MAX(t.created_at)::date > 90 THEN 'CHURN RISK'
        WHEN CURRENT_DATE - MAX(t.created_at)::date > 30 THEN 'Cooling down'
        ELSE 'Active'
    END AS churn_flag
FROM transactions t
JOIN accounts  a ON t.account_id = a.id
JOIN customers c ON a.customer_id = c.id
GROUP BY c.full_name
ORDER BY days_since_last_txn DESC;

4.2. Dấu hiệu sớm và mô hình dự báo

Chờ đến khi khách "im lặng 90 ngày" thường là quá muộn. Dấu hiệu sớm hữu ích hơn: tần suất giao dịch giảm dần, số dư trung bình đi xuống, ngừng dùng một sản phẩm, giảm đăng nhập app, khiếu nại tăng. Từ các đặc trưng này, ngân hàng dựng mô hình dự báo churn — thường là phân loại nhị phân trả về xác suất rời bỏ. Đội đã có kho dữ liệu có thể huấn luyện ngay trong BigQuery (BQML) trên bảng đặc trưng RFM/hành vi; LLM hỗ trợ diễn giải nguyên nhân hoặc soạn thông điệp giữ chân, nhưng phần chấm điểm rủi ro nên là mô hình định lượng, có thể kiểm chứng.

4.3. Hành động giữ chân

Điểm churn chỉ có giá trị khi gắn với hành động phân tầng theo giá trị khách (kết hợp với CLV/RFM):

• Giá trị cao + rủi ro cao (Cannot Lose Them): chuyên viên gọi trực tiếp, ưu đãi giữ chân mạnh, rà soát trải nghiệm.
• Giá trị TB + rủi ro cao: ưu đãi tự động (bonus điểm, hoàn tiền có điều kiện) qua app/email.
• Giá trị thấp + rủi ro cao: chiến dịch chi phí thấp, hoặc chấp nhận để đi nếu chi phí giữ vượt giá trị.

5. Đo hiệu quả chương trình

Loyalty tốn tiền, nên phải chứng minh được nó tạo ra giá trị vượt chi phí. Các chỉ số cốt lõi:

• Redemption rate (tỷ lệ đổi thưởng): tỷ lệ điểm/ưu đãi đã được đổi. Quá thấp → khách không thấy giá trị, chương trình "chết"; quá cao → chi phí quyền lợi lớn. Cần một khoảng hợp lý.
• Breakage: phần điểm phát ra nhưng không bao giờ được đổi (hết hạn, khách bỏ quên). Breakage là "khoản dự phòng được giải phóng" về mặt kế toán, nhưng breakage quá cao là dấu hiệu chương trình kém hấp dẫn.
• Engagement: tỷ lệ khách chủ động tương tác (mở app xem điểm, tham gia ưu đãi), số khách hoạt động (active members) so với tổng thành viên.
• Incremental spend: đây là chỉ số khó và quan trọng nhất — chi tiêu tăng thêm nhờ chương trình, không phải tổng chi tiêu. Đo bằng nhóm đối chứng (control group): giữ một nhóm khách tương đương không nhận ưu đãi, so sánh chênh lệch chi tiêu với nhóm được ưu đãi (test). Chênh lệch chính là incremental. Không có control group thì mọi tăng trưởng đều dễ bị quy nhầm cho chương trình.
• Điểm/CLV theo hạng: theo dõi điểm phát ra và CLV trung bình theo từng hạng để kiểm tra "chi phí quyền lợi < giá trị khách" ở từng bậc.

Ta có thể dựng nhanh một bảng đo theo hạng bằng ntile trên tổng chi tiêu (giả lập "hạng" từ M), rồi tổng hợp:

▶ Chạy được trong SQL Builder

WITH per_customer AS (
    SELECT
        c.id AS customer_id,
        SUM(t.amount) AS monetary,
        COUNT(*)      AS frequency
    FROM transactions t
    JOIN accounts  a ON t.account_id = a.id
    JOIN customers c ON a.customer_id = c.id
    GROUP BY c.id
),
banded AS (
    SELECT
        customer_id, monetary, frequency,
        NTILE(4) OVER (ORDER BY monetary) AS spend_band
    FROM per_customer
)
SELECT
    spend_band,
    COUNT(*)                        AS customers,
    ROUND(AVG(monetary), 0)         AS avg_spend,
    ROUND(AVG(frequency), 1)        AS avg_frequency,
    SUM(monetary)                   AS total_spend
FROM banded
GROUP BY spend_band
ORDER BY spend_band DESC;

spend_band = 4 là nhóm chi tiêu cao nhất — trong thực tế đây là nhóm cần theo dõi sát nhất vì đóng góp phần lớn total_spend.

6. Cá nhân hoá & chiến dịch

Phân khúc và điểm dự báo chỉ tạo giá trị khi biến thành ưu đãi đúng người, đúng lúc.

• Next-Best-Offer (NBO): với mỗi khách, chọn ưu đãi tiếp theo tốt nhất dựa trên hành vi và xác suất phản hồi — thay vì gửi cùng một ưu đãi cho tất cả. NBO là điểm gặp giữa phân khúc (RFM/CLV) và mô hình dự báo phản hồi.
• Card-linked offers theo hành vi: ưu đãi gắn thẳng vào thẻ, tự động hoàn tiền/tặng điểm khi khách chi tiêu tại nhóm ngành hàng phù hợp thói quen của họ (xem thêm phần card-linked offers trong bài hạng & quyền lợi). Ví dụ khách hay chi F&B nhận ưu đãi nhà hàng.
• A/B test: trước khi triển khai rộng, chia ngẫu nhiên hai (hoặc nhiều) phiên bản ưu đãi/thông điệp, đo phiên bản nào cho incremental cao hơn. A/B test là cơ chế bảo vệ ngân sách khỏi phỏng đoán.
• Vòng lặp đo → hành động: mỗi chiến dịch phải có mục tiêu đo được (redemption, incremental spend, retention của segment mục tiêu), đo xong nạp kết quả trở lại làm đặc trưng cho lần phân khúc/dự báo sau — đúng vòng lặp ở sơ đồ mục 1.

7. Use case thực tế — chiến dịch giữ chân nhóm at-risk

Bối cảnh. Một ngân hàng bán lẻ nhận thấy chi tiêu thẻ tín dụng đi ngang, nghi có nhóm khách giá trị đang nguội dần. Câu hỏi: ai đang nguội, và nên làm gì?

Bước 1 — phân khúc RFM. Đội dữ liệu chạy RFM trên 12 tháng chi tiêu thẻ (logic như mục 2.2), tính điểm bằng NTILE(5). Họ lọc nhóm At-Risk / Cannot Lose Them: F ≥ 4 và M ≥ 4 (từng chi nhiều, thường xuyên) nhưng R ≤ 2 (đã lâu không chi). Đây là nhóm giá trị cao đang rời đi — nguy hiểm nhất.

Bước 2 — xếp ưu tiên theo CLV. Trong nhóm at-risk, sắp theo CLV giảm dần để chuyên viên gọi trước những khách đáng giữ nhất; phần còn lại nhận ưu đãi tự động.

Bước 3 — thiết kế A/B test. Chia nhóm at-risk thành ba:

• Control: không nhận gì (đo churn tự nhiên).
• Test A: tặng x2 điểm cho chi tiêu 60 ngày tới.
• Test B: hoàn tiền 3% cho chi tiêu tại ngành hàng khách hay dùng (card-linked, cá nhân hoá).

Bước 4 — đo sau 60–90 ngày. So incremental spend và retention rate của Test A/B với Control. Giả sử Test B (card-linked cá nhân hoá) cho retention cao hơn Control 8 điểm phần trăm và incremental spend dương vượt chi phí hoàn tiền → thắng.

Bước 5 — nhân rộng & khép vòng. Chuẩn hoá Test B thành playbook cho at-risk, đưa điểm churn + segment vào bảng phân tích chạy hằng tháng trên kho dữ liệu, và nạp kết quả chiến dịch trở lại làm đặc trưng — vòng lặp đo → hành động → đo lại lại tiếp tục.

Điểm mấu chốt: không có control group thì không kết luận được ưu đãi có thực sự tạo giá trị, hay khách vẫn sẽ chi tiêu dù sao.

Ghi nhớ

• Phân tích loyalty là để quyết định, không phải để báo cáo. Mọi chỉ số đều phải dẫn tới một hành động: nhắm ưu đãi, giữ chân, điều chỉnh ngân sách.
• RFM trả lời "khách đang thế nào" bằng ba chiều Recency/Frequency/Monetary; chấm điểm tương đối bằng NTILE, nhớ đảo chiều Recency (mới hơn = điểm cao).
• CLV trả lời "khách đáng giá bao nhiêu trong tương lai"; công thức đơn giản = giá trị TB × tần suất × vòng đời, nâng cao thì thêm margin, chiết khấu và tỷ lệ giữ chân. CLV định cỡ ngân sách quyền lợi theo hạng.
• Churn trong ngân hàng thường là giảm hoạt động âm thầm, không phải đóng tài khoản; nhận diện dấu hiệu sớm và can thiệp phân tầng theo giá trị.
• Incremental spend đo bằng control group là chỉ số thật của hiệu quả; redemption/breakage/engagement bổ trợ nhưng không thay thế được.
• Cá nhân hoá + A/B test biến phân khúc thành ưu đãi đúng người, và bảo vệ ngân sách khỏi phỏng đoán.
• Toàn bộ chạy trên nền dữ liệu (BigQuery + dbt + Looker); các câu SQL trong bài minh hoạ logic trên Postgres sandbox và chuyển sang BigQuery gần như nguyên vẹn.