Phân tích sản phẩm 8 — Thực hành ngân hàng số

Ghép mọi thứ lại: phân tích một app ngân hàng số

Bảy bài trước dạy từng công cụ riêng lẻ. Bài này là bài thực hành tổng kết: đặt tất cả vào bối cảnh một sản phẩm thật — app ngân hàng số của NCB, nơi khách mở tài khoản, xác thực bằng eKYC, chuyển tiền, quẹt thẻ, gửi tiết kiệm, vay tiêu dùng. Câu hỏi trung tâm không phải "công cụ nào hay", mà "ở mỗi chặng của hành trình khách hàng, nên hỏi gì và dùng phương pháp nào để trả lời".

Một sai lầm phổ biến của team phân tích non tay là đo cái dễ đo thay vì đo cái quan trọng: đếm lượt cài app, số click, số màn hình xem — những con số vô hại nhưng không lái được quyết định. Bài này đi ngược lại: xuất phát từ hành trình khách và giá trị kinh doanh, rồi mới chọn phương pháp và số liệu phục vụ nó.

Bản đồ hành trình khách hàng số ↔ phương pháp

Hành trình khách trên app ngân hàng chia thành sáu chặng. Mỗi chặng có câu hỏi phân tích đặc trưng và một phương pháp chủ lực (nối lại các bài trước):

Đọc bản đồ theo bảng:

Quy tắc vàng: không có phương pháp "vạn năng". Funnel giỏi soi một chuỗi bước tuyến tính (eKYC), nhưng vô dụng để đo giữ chân dài hạn — đó là việc của cohort. Segmentation chỉ nhóm khách, không nói khách nào sắp rời — đó là việc của churn model. Chọn đúng công cụ cho đúng câu hỏi là kỹ năng cốt lõi của người phân tích sản phẩm.

Hệ thống đo: North Star và metric tree

Trước khi dựng dashboard, phải thống nhất North Star Metric (NSM) — một con số duy nhất phản ánh giá trị mà sản phẩm mang lại cho khách và cho ngân hàng (xem pa-02). Với app ngân hàng, NSM tốt không phải "số tài khoản mở" (dễ thổi phồng, không phản ánh giá trị) mà là thứ gắn với hành vi tạo giá trị lặp lại, ví dụ:

NSM đề xuất: Số khách hoạt động theo tuần có giao dịch giá trị (WAU-Value) — khách thực hiện ít nhất một giao dịch tài chính (chuyển tiền, thanh toán, quẹt thẻ) trong tuần.

Từ NSM, khai triển thành metric tree (cây chỉ số) — bẻ NSM thành các nhánh input mà đội ngũ tác động được:

Đi kèm NSM luôn phải có guardrail metric (chỉ số bảo vệ) — thứ không được xấu đi khi chạy tăng trưởng. Trong ngân hàng, guardrail đặc biệt nghiêm ngặt:

Nguyên tắc: một thí nghiệm/thay đổi chỉ được coi là "thắng" khi cải thiện NSM MÀ KHÔNG làm xấu guardrail. Đây là điểm khác biệt lớn nhất giữa product analytics ngân hàng và một app giải trí — ta không được "tối ưu engagement bằng mọi giá".

Xây dựng năng lực: từ event đến dashboard

Phân tích tốt cần hạ tầng tốt. Ba lớp năng lực cần dựng:

1. Event tracking và taxonomy

Event (sự kiện) là bản ghi một hành động của khách trên app (transaction_completed, ekyc_step_submitted...). Taxonomy (bộ khung đặt tên) là quy ước đặt tên và cấu trúc sự kiện — không có nó, dữ liệu hành vi thành đống rác không dùng được. Nguyên tắc thiết kế event:

• Đặt tên object_action nhất quán: account_opened, card_activated, loan_offer_viewed. Không trộn openAccount, Account Open, acc_opened.
• Property (thuộc tính) chuẩn hoá: mỗi event mang các trường như customer_id, session_id, timestamp, channel, product_type. Giá trị enum cố định (không tự do gõ).
• Tránh over-tracking: chỉ track sự kiện phục vụ một câu hỏi phân tích cụ thể. Track "mọi click" tạo chi phí lưu trữ và nhiễu.
• Versioning: khi đổi nghĩa event, thêm version hoặc event mới, đừng âm thầm đổi — sẽ vỡ mọi báo cáo lịch sử.

Với dữ liệu tài chính, luôn tách event hành vi (click, xem màn) khỏi event giao dịch (bản ghi tài chính có nguồn từ core banking). Event hành vi có thể mất mát; bản ghi giao dịch phải chính xác tuyệt đối và đối soát được.

2. Mô hình dữ liệu hành vi trên warehouse/lakehouse

Event đổ về warehouse/lakehouse (kho phân tích — xem data-engineering-07) rồi mô hình hoá thành bảng dùng được cho phân tích. Kiến trúc điển hình theo lớp: raw event → bảng sự kiện làm sạch → bảng tổng hợp theo khách/ngày (fact), gắn với dimension khách/sản phẩm/kênh. Cách tổ chức này để mọi dashboard đọc từ một nguồn nhất quán, tránh mỗi báo cáo tự tính một kiểu (single source of truth — xem gov-02).

3. Dashboard sản phẩm ba tầng

Không dựng một dashboard "cho tất cả" — mỗi đối tượng cần góc nhìn riêng (nguyên tắc thiết kế dashboard: xem viz-05):

Lý tưởng nhất là hạ tầng self-service (tự phục vụ): analyst nghiệp vụ tự truy vấn theo metric đã định nghĩa sẵn trong semantic layer, không phải chờ data team viết SQL từng lần (xem bi-04).

Dashboard sản phẩm mini (SQL chạy được)

Dưới đây là ba truy vấn dựng một dashboard sản phẩm mini ngay trên sandbox. Sandbox không có bảng event thật, nên ta minh hoạ bằng dữ liệu ngân hàng có sẵn (customers, accounts, transactions): coi mỗi giao dịch là proxy cho "hành vi giá trị", mỗi khách là một người dùng. Ý tưởng chuyển thẳng sang bảng event thật khi có.

(1) Khách hoạt động và tăng trưởng theo tháng — proxy cho NSM: mỗi tháng có bao nhiêu khách phát sinh giao dịch, và tăng trưởng so tháng trước.

-- ▶ Chạy được
WITH monthly AS (
    SELECT
        date_trunc('month', t.created_at)::date  AS month,
        COUNT(DISTINCT a.customer_id)            AS active_customers,
        SUM(t.amount)                            AS txn_value
    FROM transactions t
    JOIN accounts a ON a.id = t.account_id
    GROUP BY date_trunc('month', t.created_at)
)
SELECT
    month,
    active_customers,
    txn_value,
    active_customers - LAG(active_customers) OVER (ORDER BY month)  AS mom_change,
    ROUND(
        100.0 * (active_customers - LAG(active_customers) OVER (ORDER BY month))
        / NULLIF(LAG(active_customers) OVER (ORDER BY month), 0)::numeric, 1
    )  AS mom_growth_pct
FROM monthly
ORDER BY month;

(2) Giá trị giao dịch theo phân khúc khách — nối pa-05: chia khách theo tổng số dư (proxy cho phân khúc giá trị), xem mỗi phân khúc đóng góp bao nhiêu giá trị giao dịch. Đây là câu hỏi bán chéo: nhóm nào giá trị cao nên ưu tiên chào tín dụng.

-- ▶ Chạy được
WITH cust_balance AS (
    SELECT
        c.id                     AS customer_id,
        COALESCE(SUM(a.balance), 0) AS total_balance
    FROM customers c
    LEFT JOIN accounts a ON a.customer_id = c.id
    GROUP BY c.id
),
segmented AS (
    SELECT
        customer_id,
        CASE
            WHEN total_balance >= 500000000 THEN 'A. Cao (>=500tr)'
            WHEN total_balance >= 100000000 THEN 'B. Trung (100-500tr)'
            WHEN total_balance > 0          THEN 'C. Thap (<100tr)'
            ELSE 'D. Khong so du'
        END AS segment
    FROM cust_balance
)
SELECT
    s.segment,
    COUNT(DISTINCT s.customer_id)   AS num_customers,
    COUNT(t.id)                     AS num_txns,
    ROUND(COALESCE(SUM(t.amount), 0)::numeric, 0)  AS txn_value,
    ROUND(
        COALESCE(SUM(t.amount), 0)::numeric
        / NULLIF(COUNT(DISTINCT s.customer_id), 0), 0
    )  AS value_per_customer
FROM segmented s
LEFT JOIN accounts a     ON a.customer_id = s.customer_id
LEFT JOIN transactions t ON t.account_id = a.id
GROUP BY s.segment
ORDER BY s.segment;

(3) Top khách theo giá trị giao dịch — danh sách khách giá trị cao để đội quan hệ khách hàng ưu tiên chăm sóc/giữ chân (nối pa-06).

-- ▶ Chạy được
SELECT
    c.id                              AS customer_id,
    c.full_name,
    c.city,
    COUNT(t.id)                       AS num_txns,
    ROUND(SUM(t.amount)::numeric, 0)  AS total_txn_value,
    ROUND(
        SUM(t.amount)::numeric / NULLIF(COUNT(t.id), 0), 0
    )  AS avg_txn_value
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_txn_value DESC
LIMIT 20;

Ba truy vấn này là khung dashboard growth thu nhỏ: một ô xu hướng NSM, một ô đóng góp theo phân khúc, một bảng khách trọng điểm. Khi có bảng event thật, thay transactions bằng bảng sự kiện hành vi là ra dashboard sản phẩm đầy đủ.

Công cụ: mua ngoài hay tự dựng?

Có hai hướng dựng năng lực product analytics:

Với ngân hàng Việt Nam, yếu tố chủ quyền và tuân thủ dữ liệu thường lấn át. Gửi dữ liệu hành vi tài chính của khách ra một SaaS nước ngoài dễ vướng quy định về dữ liệu cá nhân (NĐ13) và an toàn thông tin ngành ngân hàng. Mô hình phổ biến và an toàn là tự dựng trên warehouse/lakehouse nội bộ, dùng lớp BI (Metabase/Superset/Power BI) làm giao diện — chấp nhận khởi động chậm hơn để đổi lấy kiểm soát. Nếu dùng công cụ ngoài, tối thiểu phải ẩn danh/giả danh dữ liệu nhạy cảm trước khi gửi.

Ràng buộc và đạo đức ngân hàng

Product analytics ngân hàng vận hành trong khung pháp lý và đạo đức chặt hơn nhiều app thường:

• Quyền riêng tư dữ liệu hành vi (NĐ13/2023/NĐ-CP): dữ liệu hành vi khách là dữ liệu cá nhân — thu thập phải có cơ sở pháp lý, thông báo mục đích, cho khách quyền truy cập/xoá. Không dùng dữ liệu ngoài mục đích đã báo (xem gov-07).
• Không thao túng, không dark pattern: không thiết kế giao diện lừa khách vay nhiều hơn nhu cầu, bật dịch vụ phí ẩn, hay khó huỷ. Tăng NSM bằng dark pattern là vi phạm đạo đức và rủi ro pháp lý.
• Cross-sell có trách nhiệm: chào tín dụng phải xét khả năng trả nợ, không đẩy vay cho người không đủ năng lực chỉ vì mô hình dự báo họ "sẽ nhấn nút".
• Tuân thủ AML/KYC: mọi phân tích không được làm suy yếu quy trình phòng chống rửa tiền và định danh khách hàng.
• Kiểm soát truy cập dữ liệu: analyst chỉ được xem dữ liệu ở mức cần thiết, có phân quyền và nhật ký (xem gov-06).

Phối hợp giữa các bên

Product analytics chỉ tạo tác động khi bốn bên phối hợp, mỗi bên một vai:

• Product sở hữu câu hỏi và quyết định; đặt bài toán, ưu tiên.
• Data dựng metric chuẩn, chạy phân tích, huấn luyện churn/CLV model, giữ single source of truth.
• Marketing biến phân khúc thành chiến dịch (chào thẻ nhóm A, winback nhóm ngủ đông).
• Compliance duyệt mọi hành động chạm dữ liệu cá nhân và chào sản phẩm tín dụng — không phải rào cản mà là điều kiện để làm bền vững.

Các use case tổng hợp có tác động

Ghép phương pháp lại, đây là những bài toán tạo giá trị rõ ràng:

Checklist năng lực phân tích sản phẩm

Team product analytics ngân hàng "đủ chín" khi trả lời "có" cho hầu hết:

• Đã chốt North Star Metric phản ánh giá trị, không phải vanity metric.
• Có metric tree và guardrail (gian lận, khiếu nại, tuân thủ) gắn với NSM.
• Có event taxonomy chuẩn, versioned, tách event hành vi khỏi bản ghi giao dịch.
• Dữ liệu hành vi mô hình hoá trên warehouse/lakehouse, một nguồn sự thật.
• Dashboard ba tầng (điều hành/growth/vận hành) có người dùng thật.
• Dùng đủ bộ phương pháp: funnel, cohort, segmentation/RFM, CLV/churn, experimentation.
• Mọi thay đổi lớn được A/B test với guardrail, không quyết theo cảm tính.
• Tuân thủ NĐ13, kiểm soát truy cập, không dark pattern.
• Quy trình phối hợp Product–Data–Marketing–Compliance rõ ràng.

Use case thực tế

Bối cảnh: Quý 2/2026, app NCB có tỷ lệ hoàn tất eKYC thấp và nhiều khách mở tài khoản xong "ngủ đông". Ban lãnh đạo giao đội product analytics: tăng số khách hoạt động có giao dịch giá trị (NSM) mà không tăng khiếu nại và giữ nợ xấu ổn định.

Các bước (minh hoạ số liệu):

1. Chốt NSM và guardrail — NSM = khách hoạt động có giao dịch giá trị/tuần. Guardrail: khiếu nại/1000 GD, tỷ lệ hồ sơ eKYC đạt chuẩn, tỷ lệ giao dịch nghi ngờ gian lận. (pa-02)
2. Funnel eKYC — dựng phễu năm bước, phát hiện 38% khách rớt ở bước chụp giấy tờ do hướng dẫn khó. Đây là điểm rò lớn nhất. (pa-03)
3. A/B test — nhóm treatment nhận màn hình hướng dẫn chụp mới. Tỷ lệ vượt bước tăng có ý nghĩa thống kê, guardrail eKYC đạt chuẩn không xấu đi → rollout. (pa-07)
4. Cohort retention — cohort sau cải thiện eKYC có retention M1 cao hơn cohort trước, xác nhận khách vào "sạch" ở lại tốt hơn. (pa-04)
5. Segmentation + winback — nhóm khách mở TK nhưng chưa giao dịch 30 ngày (dormant) nhận chiến dịch nudge có kiểm soát; một phần giao dịch trở lại. (pa-05)
6. CLV + churn cho giữ chân — chấm điểm rời bỏ, đội quan hệ khách hàng ưu tiên gọi nhóm CLV cao + điểm churn cao, giảm rời bỏ ở nhóm sinh lợi nhất. (pa-06)

Kết quả: NSM tăng qua hai chặng độc lập (nhiều khách hoàn tất eKYC hơn + khách cũ giữ chân tốt hơn), guardrail không xấu, mọi hành động chạm dữ liệu cá nhân được Compliance duyệt trước. Đây chính là 8 bài của series chạy như một cỗ máy.

Tổng kết series: bản đồ 8 bài

Series "Phân tích sản phẩm & tăng trưởng" khép lại với bản đồ tổng:

Đọc theo thứ tự, tám bài đi từ "đo gì" → "phân tích ra sao" → "hành động thế nào" → "ghép lại vận hành". Mỗi công cụ có chỗ đứng; sức mạnh nằm ở biết dùng đúng công cụ cho đúng câu hỏi tại đúng chặng của hành trình khách.

Ghi nhớ

• Xuất phát từ hành trình khách và giá trị kinh doanh, không phải từ công cụ. Mỗi chặng (thu hút→eKYC→kích hoạt→gắn kết→bán chéo→giữ chân) có câu hỏi và phương pháp riêng.
• Không có phương pháp vạn năng: funnel cho onboarding, cohort cho gắn kết, RFM cho bán chéo, CLV/churn cho giữ chân, experimentation để cải thiện.
• North Star phản ánh giá trị (khách hoạt động có giao dịch giá trị), không phải vanity metric; luôn đi kèm guardrail gian lận/khiếu nại/tuân thủ.
• Năng lực = event taxonomy chuẩn + mô hình dữ liệu hành vi trên warehouse + dashboard ba tầng + self-service.
• Ngân hàng Việt Nam thường tự dựng trên warehouse nội bộ vì chủ quyền và tuân thủ dữ liệu (NĐ13) lấn át tốc độ khởi động của SaaS ngoài.
• Đạo đức là ràng buộc cứng: quyền riêng tư dữ liệu hành vi, không dark pattern, cross-sell có trách nhiệm, tuân thủ AML/KYC.
• Tác động cần bốn bên: Product đặt câu hỏi, Data dựng phân tích, Marketing hành động, Compliance bảo vệ.
• Cả tám bài của series chạy như một cỗ máy — biết dùng đúng công cụ cho đúng câu hỏi tại đúng chặng.