Customer 360 — 4 — Phân khúc khách hàng (RFM & hành vi)

Một chiến dịch email gửi cùng một ưu đãi "mở thẻ tín dụng, miễn phí năm đầu" cho toàn bộ cơ sở khách hàng sẽ lãng phí ở cả hai đầu: người đã có ba thẻ thấy phiền, người đang có nguy cơ rời bỏ thì chẳng được ai chăm sóc. Sau khi đã hợp nhất dữ liệu thành hồ sơ 360° (Customer 360 — tổng quan), bước tiếp theo để cá nhân hoá là chia khách thành các nhóm giống nhau — để nhắm đúng sản phẩm, đúng thông điệp, đúng thời điểm.

Bài này đi từ vì sao phân khúc → các cách phân khúc → RFM bằng SQL (trọng tâm, chạy được ngay trên sandbox) → nhắc ngắn về ML → và quan trọng nhất: từ phân khúc ra hành động.

1. Vì sao phải phân khúc?

Không thể đối xử với mọi khách hàng như nhau vì họ không giống nhau về giá trị, hành vi và nhu cầu. Phân khúc (segmentation) là việc chia cơ sở khách hàng thành các nhóm nội bộ tương đồng (khách trong cùng nhóm giống nhau) và khác biệt giữa các nhóm (nhóm này khác nhóm kia). Lợi ích cụ thể:

• Nhắm mục tiêu (targeting): chỉ gửi ưu đãi thẻ tín dụng cho nhóm có khả năng dùng, thay vì bắn đại trà → tỉ lệ phản hồi cao hơn, chi phí marketing thấp hơn.
• Cá nhân hoá thông điệp: khách VIP nhận lời cảm ơn và ưu đãi độc quyền; khách mới nhận hướng dẫn onboarding.
• Phân bổ nguồn lực: quan hệ khách hàng (RM) tập trung vào nhóm giá trị cao; nhóm đại chúng được phục vụ tự động qua kênh số.
• Quản trị rủi ro & giữ chân: phát hiện sớm nhóm có nguy cơ rời bỏ để can thiệp trước khi mất khách.

Phân khúc là cầu nối giữa dữ liệu và hành động kinh doanh — nó biến một hồ sơ 360° tĩnh thành đầu vào cho chiến dịch và cho gợi ý sản phẩm (Next Best Action).

2. Các cách phân khúc

Có nhiều trục để chia nhóm; ngân hàng thường kết hợp vài trục.

RFM là mô hình kinh điển và là lựa chọn khởi đầu tốt nhất cho hầu hết ngân hàng vì:

• Recency (R): khách gần đây nhất có giao dịch khi nào? Càng gần, càng "sống".
• Frequency (F): khách giao dịch bao nhiêu lần? Càng nhiều, càng gắn bó.
• Monetary (M): khách mang lại bao nhiêu tiền? (tổng giá trị giao dịch, số dư, hoặc lợi nhuận).

Ưu điểm RFM: tính hoàn toàn bằng SQL, dễ giải thích cho nghiệp vụ, không cần huấn luyện mô hình, chạy lại nhanh. Đây là lý do ta dành phần lớn bài cho RFM.

Với ngân hàng, M (Monetary) có thể định nghĩa nhiều cách tuỳ mục tiêu: tổng giá trị giao dịch (đo mức độ dùng dịch vụ), số dư huy động trung bình (đo tiền gửi), hay lợi nhuận đóng góp (đo giá trị thực). Trong bài này ta dùng tổng giá trị giao dịch vì bảng transactions có sẵn cột amount — nhưng nguyên tắc chấm điểm không đổi khi bạn thay bằng thước đo khác. Điều quan trọng là chọn một định nghĩa M nhất quán trước khi chạy để so sánh giữa các kỳ có ý nghĩa.

3. RFM bằng SQL — từng bước

Sandbox có ba bảng liên quan: customers (khách), accounts (tài khoản, customer_id trỏ về khách), transactions (giao dịch, account_id trỏ về tài khoản). Để tính RFM cho mỗi khách, ta gộp giao dịch của tất cả tài khoản của khách đó.

3.1. Bước 1 — Tính R/F/M thô cho mỗi khách

• R = số ngày kể từ giao dịch gần nhất → CURRENT_DATE - MAX(created_at)::date.
• F = số giao dịch → COUNT(t.id).
• M = tổng giá trị giao dịch → SUM(t.amount).

-- ▶ Chạy được
SELECT
  c.id,
  c.full_name,
  c.city,
  CURRENT_DATE - MAX(t.created_at)::date AS recency_days,
  COUNT(t.id)                            AS frequency,
  SUM(t.amount)                          AS monetary
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 monetary DESC
LIMIT 20;

Lưu ý về mốc thời gian cho R: dùng CURRENT_DATE thì kết quả thay đổi theo ngày chạy — tiện cho sản xuất nhưng khó tái lập. Khi cần mốc cố định (ví dụ chốt cuối tháng), thay bằng một hằng ngày:

-- ▶ Chạy được
SELECT
  c.id,
  c.full_name,
  DATE '2026-07-01' - MAX(t.created_at)::date AS recency_days,
  COUNT(t.id)                                 AS frequency,
  ROUND(SUM(t.amount)::numeric, 2)            AS monetary
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
ORDER BY recency_days ASC
LIMIT 20;

3.2. Bước 2 — Chấm điểm RFM bằng NTILE(5)

Giá trị thô khó so sánh (R tính bằng ngày, M tính bằng tiền). Ta chuẩn hoá về thang điểm 1–5 bằng NTILE(5) — hàm cửa sổ chia tập đã sắp xếp thành 5 nhóm (ngũ phân vị) đều nhau. Quy ước:

• R: recency nhỏ (mới giao dịch) → điểm cao. Sắp xếp recency_days ASC rồi NTILE, hoặc NTILE theo DESC của ngày. Ở đây ta cho R tăng dần rồi đảo: 6 - NTILE(5) để "mới nhất = 5".
• F, M: càng lớn càng tốt → NTILE theo ASC, nhóm cao nhất = 5.

-- ▶ Chạy được
WITH rfm AS (
  SELECT
    c.id,
    c.full_name,
    CURRENT_DATE - MAX(t.created_at)::date AS recency_days,
    COUNT(t.id)                            AS frequency,
    SUM(t.amount)                          AS monetary
  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
  id,
  full_name,
  recency_days,
  frequency,
  ROUND(monetary::numeric, 2) AS monetary,
  6 - NTILE(5) OVER (ORDER BY recency_days ASC) AS r_score,
  NTILE(5) OVER (ORDER BY frequency ASC)        AS f_score,
  NTILE(5) OVER (ORDER BY monetary  ASC)        AS m_score
FROM rfm
ORDER BY m_score DESC, f_score DESC
LIMIT 25;

Kết quả: mỗi khách có ba con số 1–5. Ví dụ (R=5, F=5, M=5) là khách lý tưởng; (R=1, F=1, M=1) gần như đã mất.

3.3. Bước 3 — Gộp thành phân khúc bằng CASE

Ba điểm rời rạc chưa "kể chuyện". Ta ghép chúng thành tên phân khúc dễ hiểu cho nghiệp vụ. Một cách phổ biến là dựa vào R (còn sống không) kết hợp F+M (giá trị & gắn bó):

-- ▶ Chạy được
WITH rfm AS (
  SELECT
    c.id,
    c.full_name,
    c.city,
    CURRENT_DATE - MAX(t.created_at)::date AS recency_days,
    COUNT(t.id)                            AS frequency,
    SUM(t.amount)                          AS monetary
  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
),
scored AS (
  SELECT
    id, full_name, city,
    6 - NTILE(5) OVER (ORDER BY recency_days ASC) AS r,
    NTILE(5) OVER (ORDER BY frequency ASC)        AS f,
    NTILE(5) OVER (ORDER BY monetary  ASC)        AS m
  FROM rfm
)
SELECT
  id, full_name, city, r, f, m,
  CASE
    WHEN r >= 4 AND (f + m) >= 8 THEN 'VIP / Vô địch'
    WHEN r >= 4 AND (f + m) >= 5 THEN 'Trung thành'
    WHEN r >= 4                  THEN 'Khách mới tiềm năng'
    WHEN r = 3  AND (f + m) >= 6 THEN 'Cần chú ý'
    WHEN r <= 2 AND (f + m) >= 7 THEN 'Nguy cơ rời (giá trị cao)'
    WHEN r <= 2                  THEN 'Ngủ đông / Đã mất'
    ELSE 'Trung bình'
  END AS segment
FROM scored
ORDER BY r DESC, (f + m) DESC
LIMIT 30;

3.4. Bước 4 — Đếm quy mô từng phân khúc

Trước khi hành động, phải biết mỗi phân khúc lớn cỡ nào và đóng góp bao nhiêu tiền — để ưu tiên. Bọc truy vấn trên vào một CTE và tổng hợp:

-- ▶ Chạy được
WITH rfm AS (
  SELECT
    c.id,
    CURRENT_DATE - MAX(t.created_at)::date AS recency_days,
    COUNT(t.id)                            AS frequency,
    SUM(t.amount)                          AS monetary
  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
),
scored AS (
  SELECT
    id, monetary,
    6 - NTILE(5) OVER (ORDER BY recency_days ASC) AS r,
    NTILE(5) OVER (ORDER BY frequency ASC)        AS f,
    NTILE(5) OVER (ORDER BY monetary  ASC)        AS m
  FROM rfm
)
SELECT
  CASE
    WHEN r >= 4 AND (f + m) >= 8 THEN 'VIP / Vô địch'
    WHEN r >= 4                  THEN 'Còn hoạt động'
    WHEN r <= 2 AND (f + m) >= 7 THEN 'Nguy cơ rời (giá trị cao)'
    ELSE 'Khác'
  END AS segment,
  COUNT(*)                        AS so_khach,
  ROUND(SUM(monetary)::numeric, 2) AS tong_gia_tri,
  ROUND(AVG(monetary)::numeric, 2) AS gia_tri_tb
FROM scored
GROUP BY 1
ORDER BY tong_gia_tri DESC;

3.5. Bước 5 — Xếp hạng khách theo M trong từng thành phố

Để chọn "top khách theo địa bàn" cho RM từng chi nhánh, dùng RANK()/ROW_NUMBER() phân vùng theo city:

-- ▶ Chạy được
WITH cust_value AS (
  SELECT
    c.id,
    c.full_name,
    c.city,
    SUM(t.amount) AS monetary
  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
)
SELECT
  city,
  full_name,
  ROUND(monetary::numeric, 2) AS monetary,
  RANK() OVER (PARTITION BY city ORDER BY monetary DESC) AS hang_trong_tp
FROM cust_value
ORDER BY city, hang_trong_tp;

Lưu ý: câu trên xếp hạng mọi khách trong mỗi thành phố. Muốn lọc "top 3 mỗi thành phố", nhiều người quen viết QUALIFY hang_trong_tp <= 3 — nhưng PostgreSQL không có QUALIFY (đó là cú pháp Snowflake/BigQuery). Trong PostgreSQL phải bọc thêm một lớp CTE rồi WHERE rn <= 3 — xem biến thể dưới đây (vẫn là một câu WITH đơn nên chạy được):

-- ▶ Chạy được
WITH cust_value AS (
  SELECT c.id, c.full_name, c.city, SUM(t.amount) AS monetary
  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
),
ranked AS (
  SELECT
    city, full_name,
    ROUND(monetary::numeric, 2) AS monetary,
    ROW_NUMBER() OVER (PARTITION BY city ORDER BY monetary DESC) AS rn
  FROM cust_value
)
SELECT city, full_name, monetary, rn
FROM ranked
WHERE rn <= 3
ORDER BY city, rn;

4. Phân khúc bằng ML (nhắc ngắn)

RFM chia nhóm theo luật do người đặt trên 3 chiều. Khi cần chia theo nhiều đặc trưng cùng lúc (tuổi, số sản phẩm, tỉ lệ dùng kênh số, biến động số dư, giờ giao dịch...) và ta không biết trước ranh giới nhóm, thì dùng clustering — điển hình là K-means:

1. Chuẩn hoá đặc trưng (scale) để các chiều so sánh được.
2. Chọn số cụm K (dùng elbow/silhouette).
3. Thuật toán tự gom khách thành K cụm sao cho trong cụm gần nhau, giữa cụm xa nhau.
4. Diễn giải từng cụm bằng đặc trưng trung bình → đặt tên nghiệp vụ.

Khi nào dùng ML thay RFM? Khi RFM quá thô (3 chiều không đủ phân biệt), khi có nhiều tín hiệu hành vi phong phú, hoặc khi muốn kết hợp với dự báo. Nhưng ML khó giải thích hơn và cần MLOps. Thực tế nhiều ngân hàng dùng cả hai: RFM cho báo cáo/chiến dịch nhanh, clustering cho phân tích sâu. Các đặc trưng RFM cũng là đầu vào tốt cho mô hình CLV & churn — xem Phân tích CLV & rời bỏ.

Một cạm bẫy thường gặp với clustering là để mô hình tự do rồi nhận về những cụm không thể diễn giải hay không hành động được — trái ngược hoàn toàn với mục tiêu ban đầu. Vì vậy dù dùng ML, vẫn cần bước con người đặt tên và kiểm chứng từng cụm bằng ngôn ngữ nghiệp vụ, đúng như khi gộp RFM bằng CASE. Sức mạnh của SQL/RFM nằm ở chỗ mọi quy tắc đều minh bạch và tái lập — cán bộ nghiệp vụ đọc câu CASE là hiểu ngay vì sao một khách rơi vào nhóm nào, điều rất khó với "hộp đen" K-means.

5. Từ phân khúc → hành động

Phân khúc vô nghĩa nếu không dẫn tới hành động. Mỗi phân khúc cần một chiến lược:

Luồng từ dữ liệu tới hành động:

Bảng gợi ý hành động này chính là đầu vào cho hệ gợi ý sản phẩm ở bài sau (Next Best Action): phân khúc thu hẹp ứng viên, mô hình xếp hạng chọn đề xuất tốt nhất.

6. Đo lường & cập nhật phân khúc

• Cập nhật định kỳ: RFM nên chạy lại hàng tuần/tháng vì hành vi thay đổi — một khách "nguy cơ rời" tháng này có thể "trung thành" tháng sau. Lưu snapshot theo kỳ để theo dõi dịch chuyển giữa các phân khúc (migration).
• Đo hiệu quả: so tỉ lệ phản hồi, doanh thu tăng thêm, tỉ lệ giữ chân giữa nhóm được nhắm mục tiêu và nhóm đối chứng (control group). Gắn với các KPI ở BI — Metrics & KPI.
• Tránh phân khúc quá vụn: chia 50 nhóm 12 khách thì không nhóm nào đủ lớn để làm chiến dịch, lại khó diễn giải. Giữ số phân khúc ở mức hành động được (thường 5–10). Ngũ phân vị RFM đã cho 125 tổ hợp (5×5×5) — luôn gộp lại thành ít nhóm nghiệp vụ.
• Kiểm tra cân bằng: NTILE chia đều theo số lượng, không theo giá trị; nếu M lệch mạnh (ít khách chiếm phần lớn tiền), cân nhắc chia theo ngưỡng tuyệt đối thay vì ngũ phân vị.

Use case thực tế

Bối cảnh NCB. Phòng phân tích cần chọn hai danh sách cho tháng 7/2026: (1) nhóm bán chéo thẻ tín dụng, (2) nhóm nguy cơ rời giá trị cao để RM gọi giữ chân. Cơ sở khách hàng được chấm RFM trên dữ liệu giao dịch 12 tháng.

Bước làm. Chạy truy vấn chấm điểm + gộp phân khúc (mục 3.3). Kết quả tổng hợp (minh hoạ):

Chọn nhóm bán chéo = phân khúc Trung thành (R cao, F+M cao, chưa có thẻ). Truy vấn thực chiến để lấy danh sách (chạy được):

-- ▶ Chạy được
WITH rfm AS (
  SELECT
    c.id, c.full_name, c.city,
    CURRENT_DATE - MAX(t.created_at)::date AS recency_days,
    COUNT(t.id)   AS frequency,
    SUM(t.amount) AS monetary
  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
),
scored AS (
  SELECT
    id, full_name, city, monetary,
    6 - NTILE(5) OVER (ORDER BY recency_days ASC) AS r,
    NTILE(5) OVER (ORDER BY frequency ASC)        AS f,
    NTILE(5) OVER (ORDER BY monetary  ASC)        AS m
  FROM rfm
)
SELECT id, full_name, city, r, f, m,
       ROUND(monetary::numeric, 2) AS monetary
FROM scored
WHERE r >= 4 AND (f + m) >= 7          -- Trung thành, còn hoạt động
ORDER BY monetary DESC
LIMIT 50;

Chọn nhóm nguy cơ rời = R thấp (lâu không giao dịch) nhưng F+M cao (từng rất giá trị) — đây là nhóm đáng cứu nhất:

-- ▶ Chạy được
WITH rfm AS (
  SELECT
    c.id, c.full_name, c.city,
    CURRENT_DATE - MAX(t.created_at)::date AS recency_days,
    COUNT(t.id)   AS frequency,
    SUM(t.amount) AS monetary
  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
),
scored AS (
  SELECT
    id, full_name, city, recency_days, monetary,
    6 - NTILE(5) OVER (ORDER BY recency_days ASC) AS r,
    NTILE(5) OVER (ORDER BY frequency ASC)        AS f,
    NTILE(5) OVER (ORDER BY monetary  ASC)        AS m
  FROM rfm
)
SELECT id, full_name, city, recency_days, r, f, m,
       ROUND(monetary::numeric, 2) AS monetary
FROM scored
WHERE r <= 2 AND (f + m) >= 8          -- lâu không GD nhưng từng giá trị cao
ORDER BY monetary DESC
LIMIT 50;

Diễn giải cho nghiệp vụ. Nhóm Trung thành có r=5, f=5, m=4: đang giao dịch đều, giá trị cao → xác suất mở thẻ tốt, gửi ưu đãi qua app + RM tư vấn. Nhóm Nguy cơ rời có r=1, f=4, m=5: 90+ ngày không giao dịch nhưng từng đóng góp lớn → RM gọi trực tiếp trong 7 ngày, kèm ưu đãi cá nhân hoá; đo tỉ lệ "kích hoạt lại" sau 30 ngày so nhóm đối chứng. Chỉ với vài truy vấn SQL, ta biến 10.000 khách vô danh thành hai danh sách hành động cụ thể — không cần mô hình ML nào.

Ghi nhớ

• Phân khúc = chia khách thành nhóm giống nhau để nhắm đúng sản phẩm/thông điệp; là cầu nối giữa Customer 360 và hành động.
• Các trục: giá trị, hành vi, vòng đời, nhân khẩu/địa lý; RFM là điểm khởi đầu tốt nhất vì tính hoàn toàn bằng SQL và dễ giải thích.
• RFM: R = ngày kể từ giao dịch gần nhất (nhỏ = tốt), F = số giao dịch, M = tổng giá trị. Tính bằng JOIN customers–accounts–transactions + MAX/COUNT/SUM.
• Chuẩn hoá điểm bằng NTILE(5); với R nhớ đảo chiều để "mới nhất = 5". Gộp thành phân khúc nghiệp vụ bằng CASE.
• PostgreSQL không có QUALIFY — muốn "top N mỗi nhóm" phải bọc ROW_NUMBER() trong CTE rồi WHERE rn <= N. Nhớ ép ::numeric trước ROUND(..., 2).
• ML (K-means) dùng khi cần nhiều đặc trưng và không biết trước ranh giới nhóm; thực tế thường kết hợp RFM + clustering. Đặc trưng RFM cũng nuôi mô hình CLV/churn.
• Mỗi phân khúc một chiến lược: VIP → giữ chân/nâng hạng, Trung thành → bán chéo, Nguy cơ rời → can thiệp khẩn, Ngủ đông → win-back.
• Cập nhật định kỳ, đo bằng nhóm đối chứng, và tránh phân khúc quá vụn (giữ 5–10 nhóm hành động được).

Nguồn tham khảo

• Arthur M. Hughes — Strategic Database Marketing (McGraw-Hill): tài liệu kinh điển giới thiệu và phổ biến mô hình RFM (Recency – Frequency – Monetary).
• Philip Kotler & Kevin Lane Keller — Marketing Management (Pearson): chương về phân khúc thị trường (market segmentation, targeting, positioning).
• scikit-learn Documentation — Clustering (K-means, silhouette)
• PostgreSQL Documentation — Window Function Calls (NTILE, RANK, ROW_NUMBER)
• PostgreSQL Documentation — Window Functions Tutorial