Customer 360 — 1 — Cái nhìn 360° về khách hàng

Một khách hàng bị từ chối nâng hạn mức thẻ, trong khi cùng lúc đang gửi tiết kiệm 2 tỷ và trả nợ vay mua nhà đúng hạn suốt 5 năm. Vấn đề không phải quyết định sai — mà là bộ phận thẻ không nhìn thấy phần còn lại của mối quan hệ. Dữ liệu về cùng một con người nằm rải rác ở core banking, hệ thống thẻ, hệ thống vay, CRM và kênh số, mỗi nơi biết một mảnh và không nơi nào biết toàn cảnh.

Customer 360 ra đời để giải quyết đúng bài toán này: hợp nhất mọi mảnh dữ liệu về một khách thành một hồ sơ thống nhất, luôn cập nhật. Đây là bài mở đầu series "Customer 360 & Cá nhân hoá ngân hàng" — đặt nền khái niệm, giá trị, thách thức và kiến trúc trước khi các bài sau đi sâu vào từng trụ cột.

1. Customer 360 là gì?

Customer 360 (còn gọi là Single Customer View — SCV, hay unified customer profile) là việc hợp nhất toàn bộ dữ liệu về một khách hàng — tài khoản, giao dịch, kênh tương tác, sản phẩm sở hữu, hồ sơ định danh, lịch sử phục vụ — thành một hồ sơ duy nhất, nhất quán và cập nhật, thay cho tình trạng dữ liệu rời rạc theo silo sản phẩm.

Từ khoá là hợp nhất (unify), không phải sao chép. Một khách thường có:

• Dữ liệu định danh (identity): họ tên, CCCD/hộ chiếu, số điện thoại, email, địa chỉ.
• Dữ liệu sở hữu (holdings): tài khoản thanh toán, tiết kiệm, thẻ tín dụng/ghi nợ, khoản vay, sản phẩm bảo hiểm/đầu tư.
• Dữ liệu hành vi (behavioural): giao dịch chuyển khoản, chi tiêu thẻ, đăng nhập mobile app, click, lịch sử tra cứu.
• Dữ liệu tương tác (engagement): cuộc gọi tổng đài, ticket khiếu nại, chiến dịch marketing đã nhận, tư vấn tại quầy.
• Dữ liệu suy diễn (derived): phân khúc, điểm tín dụng, CLV (giá trị vòng đời), xác suất rời bỏ (churn).

Kết quả cuối cùng là một golden record — bản ghi "vàng" đại diện cho khách, được ghép từ nhiều nguồn, đã khử trùng lặp và giải quyết mâu thuẫn. Golden record không thay thế hệ thống nguồn; nó là lớp hợp nhất ngồi bên trên để phân tích và phục vụ.

Phân biệt nhanh: Customer 360 là khái niệm/năng lực (nhìn toàn diện một khách). CDP (Customer Data Platform) là một loại nền tảng công nghệ thường dùng để hiện thực hóa nó cho mục đích marketing/kênh. Không nhất thiết phải mua CDP mới có được Customer 360.

2. Vì sao khó ở ngân hàng?

Bán lẻ, viễn thông cũng làm Customer 360, nhưng ngân hàng khó hơn hẳn vì bốn đặc thù:

1. Dữ liệu phân mảnh sâu. Một ngân hàng điển hình có core banking (tài khoản, sổ cái), hệ thống thẻ (card management system) thường của nhà cung cấp khác, hệ thống vay/LOS, CRM, kho dữ liệu số (mobile/internet banking), hệ thống chiến dịch. Mỗi hệ thống có mô hình dữ liệu, mã khách và chu kỳ cập nhật riêng.

2. Nhiều định danh (multiple identifiers). Cùng một người có thể là CIF number ở core, một card_holder_id ở hệ thống thẻ, một lead_id ở CRM, một user_id ở app. Ghép chúng lại chính xác là bài toán identity resolution — chủ đề của bài 2.

3. Chất lượng dữ liệu lệch. Tên viết hoa/thường khác nhau, địa chỉ nhập tay, số điện thoại thiếu mã vùng, CCCD 9 số cũ lẫn 12 số mới. Không xử lý chất lượng thì hợp nhất sẽ ghép nhầm hoặc bỏ sót (xem Data Quality).

4. Yêu cầu thời gian thực (real-time). Nhiều tình huống — chống gian lận, gợi ý ngay trên app, cảnh báo giao dịch — cần hồ sơ được cập nhật trong mili-giây tới vài giây, không thể chờ batch qua đêm.

Cộng thêm ràng buộc tuân thủ và quyền riêng tư: dữ liệu ngân hàng là dữ liệu nhạy cảm, việc hợp nhất và dùng chúng phải tôn trọng consent (sự đồng ý) và quy định (xem bài 7 và Privacy Compliance).

3. Vì sao Customer 360 là nền cho ngân hàng dữ liệu?

Customer 360 không phải một dự án marketing đơn lẻ — nó là lớp nền mà nhiều năng lực dữ liệu khác đứng trên. Giá trị trải rộng khắp ngân hàng:

Điểm mấu chốt: cùng một hồ sơ 360 phục vụ cả marketing (bán chéo) lẫn rủi ro (chấm điểm) lẫn tuân thủ (giám sát). Đầu tư một lần, nhiều đơn vị dùng chung — đó là lý do nó xứng đáng là nền tảng.

4. Các trụ cột (định hướng series)

Series này bóc tách Customer 360 thành các trụ cột, mỗi trụ cột một bài:

• Hợp nhất danh tính — ghép nhiều định danh về một khách (matching, survivorship).
• Tích hợp dữ liệu / CDP — đưa dữ liệu từ core, thẻ, vay, kênh số về một chỗ; mô hình hồ sơ.
• Phân khúc — chia khách thành nhóm để hành động (RFM, hành vi, giá trị).
• NBA / gợi ý — chọn hành động/sản phẩm tốt nhất kế tiếp cho từng khách.
• Cá nhân hoá realtime — phục vụ nội dung cá nhân hoá ngay trong luồng tương tác.
• Riêng tư & consent — quản trị đồng ý, mục đích sử dụng, quyền của khách.
• Thực hành ngân hàng — ráp mọi thứ vào một chương trình cụ thể.

consent (riêng tư) không phải việc "làm sau" — nó là ràng buộc xuyên suốt mọi bước, nên trong sơ đồ nó tác động ngược vào tích hợp, NBA và cá nhân hoá.

5. Kiến trúc tổng quan

Kiến trúc Customer 360 luôn có ba tầng logic: nguồn → hợp nhất → phục vụ.

Golden record ở giữa là trái tim của kiến trúc: hồ sơ đã khử trùng lặp, chọn giá trị "sống sót" (survivorship) từ nhiều nguồn, gắn kèm thuộc tính suy diễn.

Batch vs Realtime

Không phải mọi thứ cần realtime. Thực tế thường là kiến trúc hai tốc độ (two-speed):

Nguyên tắc: đưa vào realtime chỉ những thuộc tính thực sự cần realtime; phần còn lại để batch cho rẻ và ổn định.

CDP vs Data Warehouse / Lakehouse

Một nhầm lẫn phổ biến là "phải mua CDP". Ba lựa chọn kiến trúc thường gặp:

• Data Warehouse / Lakehouse: kho phân tích tập trung (ví dụ lakehouse). Mạnh cho BI, mô hình hoá, batch. Không tối ưu cho kích hoạt realtime ra kênh.
• CDP: nền tảng chuyên gom dữ liệu khách hàng, hợp nhất danh tính và kích hoạt (activation) sang kênh marketing. Mạnh về realtime/segment/campaign, nhưng thường hạn chế về phân tích sâu và quản trị dữ liệu doanh nghiệp.
• Composable / warehouse-native CDP: dùng lakehouse làm nguồn sự thật, thêm lớp activation lên trên — xu hướng được nhiều ngân hàng chọn vì tránh sao chép dữ liệu nhạy cảm và tận dụng quản trị sẵn có.

Với ngân hàng, dữ liệu vốn đã tập trung ở lakehouse để phục vụ rủi ro và báo cáo, nên hướng warehouse-native thường hợp lý hơn CDP tách rời. Chi tiết ở bài 3.

6. Minh hoạ một hồ sơ 360

Một hồ sơ 360 (minh hoạ) của khách "Nguyễn Văn A" khi ghép các mảnh lại:

{
  "customer_id": "CIF00012345",
  "identity": { "full_name": "Nguyễn Văn A", "city": "Hà Nội", "kyc_level": "full" },
  "holdings": {
    "accounts": 2, "cards": 1, "loans": 1,
    "total_balance_vnd": 2150000000
  },
  "behaviour": {
    "txn_last_30d": 84, "avg_txn_amount_vnd": 3200000,
    "app_logins_30d": 41, "last_login": "2026-07-12"
  },
  "derived": {
    "segment": "Affluent - Active",
    "churn_risk": "low", "next_best_action": "offer_wealth_advisory"
  }
}

Ba lớp holdings, behaviour, derived chính là thứ silo đơn lẻ không bao giờ có đủ. Trên schema sandbox (bảng customers, accounts, transactions), ta có thể dựng một phiên bản đơn giản của "holdings + behaviour": đếm số tài khoản, số giao dịch và tổng số dư mỗi khách.

-- ▶ Chạy được
SELECT
  c.id,
  c.full_name,
  c.city,
  COUNT(DISTINCT a.id)                         AS so_tai_khoan,
  COUNT(t.id)                                  AS so_giao_dich,
  ROUND(COALESCE(SUM(a.balance), 0)::numeric, 2) AS tong_so_du
FROM customers c
LEFT JOIN accounts a     ON a.customer_id = c.id
LEFT JOIN transactions t ON t.account_id = a.id
GROUP BY c.id, c.full_name, c.city
ORDER BY tong_so_du DESC
LIMIT 20;

Đây chính là "hình hài phôi thai" của golden record: mỗi dòng là một khách, gom số liệu từ nhiều bảng nguồn. Lưu ý phải JOIN customers mới có tên khách (bảng accounts/transactions không chứa tên), và ép ::numeric trước ROUND hai tham số vì SUM/AVG có thể trả double precision.

Một phép tổng hợp toàn danh mục — giá trị giao dịch bình quân và số khách có phát sinh:

-- ▶ Chạy được
SELECT
  ROUND(AVG(t.amount)::numeric, 2)  AS gia_tri_gd_binh_quan,
  COUNT(*)                          AS tong_so_gd,
  COUNT(DISTINCT a.customer_id)     AS so_khach_co_gd
FROM transactions t
JOIN accounts a ON a.id = t.account_id;

7. Đo lường giá trị (KPI)

Một chương trình Customer 360 phải chứng minh được giá trị bằng số, nếu không nó chỉ là "dự án dữ liệu" tốn kém. Các KPI cốt lõi (xem thêm Metrics & KPI):

Nguyên tắc đo lường: luôn có nhóm chứng (control/holdout) để đo uplift thực, tránh quy công cho những chuyển đổi vốn dĩ sẽ xảy ra.

Use case thực tế

Bối cảnh NCB. Dữ liệu khách trước đây nằm rời ở core banking, hệ thống thẻ, hệ thống vay và CRM. Đội số hoá muốn xây hồ sơ 360 để cá nhân hoá app và bán chéo — cụ thể là gợi ý đúng sản phẩm cho đúng khách thay vì đẩy ưu đãi đại trà.

Cách làm (các bước chính):

1. Gom nguồn: đưa dữ liệu core (tài khoản, giao dịch), thẻ, vay và log app về lakehouse theo batch hằng ngày, riêng sự kiện app đẩy near-real-time.
2. Hợp nhất danh tính: dùng CCCD + số điện thoại + họ tên chuẩn hoá để ghép các định danh về một CIF (chi tiết bài 2).
3. Dựng golden record: mỗi khách một hồ sơ với holdings + hành vi 90 ngày + thuộc tính suy diễn (phân khúc, churn).
4. Kích hoạt: đẩy phân khúc và NBA sang app và tổng đài; đặt nhóm holdout để đo uplift.

Số liệu ước lượng (minh hoạ, không phải số công bố): một chương trình quy mô này thường đặt mục tiêu match rate ~90–95%, giảm bản ghi trùng lặp từ hàng chục phần trăm xuống dưới ~2%, và kỳ vọng cross-sell conversion tăng theo bội số so với chiến dịch đại trà (từ dưới 1% lên vài phần trăm ở nhóm được cá nhân hoá).

Giá trị: một hồ sơ dùng chung cho marketing (bán chéo), rủi ro (chấm điểm toàn diện, dẫn Scoring) và giám sát gian lận (dẫn AML).

Thách thức thực tế:

• Chất lượng dữ liệu nguồn kém khiến ghép sai/sót — phải đầu tư Data Quality trước.
• Consent và mục đích sử dụng: không phải dữ liệu nào cũng được dùng cho marketing; phải gắn cờ mục đích ngay từ tầng hợp nhất (bài 7).
• Đồng bộ realtime tốn kém — chỉ realtime hoá phần cần thiết.
• Sở hữu và quản trị: ai chịu trách nhiệm golden record khi nhiều đơn vị cùng dùng.

Ghi nhớ

• Customer 360 = hợp nhất mọi dữ liệu về một khách thành MỘT hồ sơ thống nhất, cập nhật (golden record), thay cho silo sản phẩm.
• Ở ngân hàng khó vì bốn thứ: dữ liệu phân mảnh, nhiều định danh, chất lượng lệch, yêu cầu realtime — cộng ràng buộc riêng tư/tuân thủ.
• Nó là nền tảng dùng chung: cùng một hồ sơ phục vụ cá nhân hoá, bán chéo (NBA), giữ chân, chấm điểm rủi ro và phát hiện gian lận.
• Kiến trúc ba tầng: nguồn → hợp nhất (identity resolution → golden record) → phục vụ (BI / chiến dịch / realtime API / rủi ro).
• Chọn batch cho phần rẻ và ổn định, realtime chỉ cho phần thực sự cần; ưu tiên hướng warehouse/lakehouse-native hơn là CDP tách rời khi dữ liệu đã tập trung.
• Consent là ràng buộc xuyên suốt, không phải việc làm sau cùng.
• Đo bằng số: match rate, độ đầy đủ hồ sơ, tỉ lệ trùng lặp, freshness, và nhất là cross-sell conversion / uplift có nhóm chứng.
• Các trụ cột tiếp theo: danh tính, tích hợp/CDP, phân khúc, NBA, realtime, riêng tư.

Nguồn tham khảo

• DAMA International — DAMA-DMBOK: Data Management Body of Knowledge (2nd Edition) — chương Master and Reference Data Management (nền lý thuyết cho golden record, survivorship, MDM).
• DAMA International — DAMA-DMBOK, chương Data Quality (cơ sở cho chuẩn hoá và làm sạch trước khi hợp nhất).
• Nghị định 13/2023/NĐ-CP về bảo vệ dữ liệu cá nhân (khung pháp lý về consent và mục đích sử dụng dữ liệu khách hàng tại Việt Nam).
• Luật Các tổ chức tín dụng và các quy định của Ngân hàng Nhà nước Việt Nam về bảo mật thông tin khách hàng.
• Gartner — Customer Data Platform (CDP) Market Guide (khái niệm CDP, hợp nhất danh tính và activation).