Phân tích sản phẩm 1 — Tổng quan & khung chỉ số

Từ báo cáo tài chính sang phân tích hành vi

Một ngân hàng số ra mắt tính năng "chuyển tiền bằng QR". Sau một tháng, ban lãnh đạo hỏi hai câu rất khác nhau. Phòng Tài chính hỏi: "Tổng giá trị giao dịch QR tháng này là bao nhiêu, tăng bao nhiêu phần trăm so với tháng trước?" — đó là câu hỏi BI báo cáo truyền thống. Phòng Sản phẩm hỏi: "Trong số khách mở màn hình QR, bao nhiêu phần trăm thực sự hoàn tất một giao dịch? Họ rơi rụng ở bước nào? Người dùng QR có quay lại tuần sau không?" — đó là câu hỏi của phân tích sản phẩm (product analytics).

Sự khác biệt không nằm ở công cụ mà ở đối tượng đo lường. BI truyền thống đo kết quả kinh doanh đã đông cứng thành số dư, doanh thu, dư nợ — thường tổng hợp theo ngày/tháng, phục vụ báo cáo quản trị. Product analytics đo hành vi người dùng theo từng bước tương tác với sản phẩm, để trả lời câu hỏi "tại sao" và "làm gì tiếp theo" nhằm cải thiện sản phẩm và thúc đẩy tăng trưởng.

Hai thế giới này không loại trừ nhau. Một team dữ liệu ngân hàng trưởng thành cần cả hai: BI để nắm "sức khỏe tài chính", product analytics để hiểu "vì sao khách dùng — hay bỏ — sản phẩm". Bài viết này mở đầu series, đặt nền cho các bài chuyên sâu về metric & North Star, funnel, cohort/retention và tiếp theo.

Dữ liệu sự kiện: nền tảng của phân tích hành vi

Nếu BI truyền thống dựng trên các bảng trạng thái (accounts, transactions), thì product analytics dựng trên luồng sự kiện (event stream). Mỗi khi người dùng làm một hành động — mở app, xem màn hình, bấm nút, hoàn tất một bước — một event được ghi lại. Mô hình dữ liệu hành vi tối giản gồm bốn thành phần:

• Event (sự kiện): cái gì đã xảy ra — một động từ ở dạng chuẩn hóa, ví dụ screen_view, qr_scan_started, transfer_completed, card_activated.
• User / entity (chủ thể): ai thực hiện — thường là user_id (khách đăng nhập) hoặc anonymous_id (khách chưa định danh). Ở ngân hàng, entity còn có thể là tài khoản, thẻ, khoản vay.
• Timestamp (mốc thời gian): khi nào — mốc thời gian chính xác đến giây/mili-giây, cho phép sắp xếp và tính khoảng cách giữa các bước.
• Properties (thuộc tính): bối cảnh — cặp key–value mô tả sự kiện (kênh: app/web, loại thẻ, số tiền, mã lỗi) và người dùng (phân khúc, thành phố, phiên bản app).

{
  "event": "transfer_completed",
  "user_id": "cust_88213",
  "timestamp": "2026-06-30T09:14:07+07:00",
  "properties": {
    "channel": "mobile_app",
    "method": "qr",
    "amount": 250000,
    "beneficiary_bank": "external",
    "app_version": "4.7.2"
  }
}

Từ bốn thành phần này, ta có thể tái dựng mọi hành trình người dùng: chuỗi sự kiện của một user_id sắp theo timestamp chính là "cuộn phim" họ đã trải qua trong app. Đây là điều bảng trạng thái không làm được: transactions cho biết đã có một lần chuyển tiền, nhưng không cho biết khách đã mở màn hình bao nhiêu lần rồi bỏ dở trước khi thành công.

Trong thực tế ngân hàng số, event thường sinh ra từ SDK tracking nhúng trong app (Firebase, Amplitude SDK) hoặc từ log backend, rồi đổ về data warehouse. Việc thiết kế taxonomy sự kiện (đặt tên event, chuẩn hóa property) là bước nền tảng — làm cẩu thả thì mọi phân tích phía sau đều lung lay. Bài thực hành ngân hàng sẽ đi sâu phần này.

AARRR — khung chỉ số tăng trưởng "pirate metrics"

Có event rồi, ta cần một bản đồ để biết đo cái gì. Khung phổ biến nhất là AARRR, còn gọi vui là "pirate metrics" (đọc lên nghe như tiếng cướp biển "Arrr!"), do Dave McClure đề xuất. Nó chia vòng đời tương tác của khách hàng thành năm giai đoạn, mỗi giai đoạn là một tầng phễu:

• Acquisition (Thu hút): làm sao khách biết đến và tải app? Đo lượt cài đặt, nguồn kênh (organic, quảng cáo, giới thiệu), chi phí thu hút (CAC).
• Activation (Kích hoạt): khách có trải nghiệm được "khoảnh khắc giá trị" lần đầu không? Với ngân hàng số, activation thường là mở tài khoản thành công hoặc hoàn tất giao dịch đầu tiên — không phải chỉ tải app rồi bỏ.
• Retention (Giữ chân): khách có quay lại không? Đây là giai đoạn quan trọng nhất — sản phẩm giữ chân kém thì mọi nỗ lực thu hút đều đổ sông.
• Referral (Giới thiệu): khách hài lòng có mời người khác không (mã giới thiệu, chia sẻ)?
• Revenue (Doanh thu): khách tạo giá trị tài chính thế nào — số dư, phí, dư nợ vay, sản phẩm bán chéo.

AARRR mạnh vì nó kết nối hành vi với tăng trưởng: mỗi tầng là một điểm rò rỉ có thể đo và tối ưu. Chi tiết cách dựng phễu và tính tỷ lệ chuyển đổi giữa các bước nằm ở bài funnel analysis.

North Star Metric & metric tree

AARRR cho ta nhiều chỉ số. Nhưng một tổ chức không thể tối ưu đồng thời hàng chục chỉ số mà không mất phương hướng. Đó là lý do có North Star Metric (NSM — chỉ số ngôi sao dẫn đường): một chỉ số duy nhất đại diện tốt nhất cho giá trị cốt lõi mà sản phẩm mang lại cho khách hàng, mà toàn team đồng lòng hướng tới.

North Star tốt phải: (1) phản ánh giá trị khách hàng nhận được, không chỉ tiền công ty thu; (2) tương quan với tăng trưởng dài hạn; (3) đội ngũ có thể tác động được. Ví dụ:

• Airbnb: số đêm được đặt (nights booked) — không phải doanh thu, mà là giá trị "được ở".
• Spotify: thời gian nghe nhạc.
• Ngân hàng số (minh họa): số khách hàng hoạt động thực hiện ít nhất 1 giao dịch tài chính mỗi tuần — vì đó là lúc app thực sự trở thành "ngân hàng chính" của khách, tiền đề cho mọi doanh thu bán chéo về sau.

Lưu ý: doanh thu thường không nên là North Star, vì nó là kết quả chậm và dễ khiến team tối ưu ngắn hạn (ép phí) làm hại trải nghiệm. North Star là chỉ số dẫn (leading), doanh thu là chỉ số theo sau (lagging).

North Star được phân rã thành metric tree — cây chỉ số phân biệt input metric (đầu vào, tác động được) và output metric (đầu ra, là kết quả):

Team không "kéo" trực tiếp North Star được — họ tác động vào các input metric (tăng tỷ lệ hoàn tất mở tài khoản, giảm lỗi giao dịch, thúc đẩy dùng thêm tính năng), và North Star chuyển động theo. Đây chính là logic được đào sâu ở bài metrics & North Star, và liên hệ chặt với nguyên tắc định nghĩa chỉ số nhất quán trong BI 4 — Metric & KPI.

Vòng đời người dùng & các câu hỏi sản phẩm điển hình

Ghép event, AARRR và North Star lại, ta có một ngôn ngữ chung để đặt câu hỏi theo từng chặng vòng đời người dùng:

Cùng một event stream, tùy câu hỏi mà ta lát cắt khác nhau — theo thời điểm gia nhập (cohort), theo thuộc tính khách (segment), theo chuỗi bước (funnel). Đó là lý do series này tách thành nhiều bài chuyên đề.

Quy trình phân tích sản phẩm

Phân tích sản phẩm không phải "chạy query rồi xuất số". Nó là một vòng lặp có kỷ luật, bắt đầu và kết thúc bằng quyết định, không phải bằng báo cáo:

1. Câu hỏi: bắt đầu bằng giả thuyết cụ thể, không phải "cho tôi xem dữ liệu". "Tôi nghi khách rơi rụng ở bước xác thực OTP khi mở tài khoản."
2. Đo: xác định event và chỉ số đo được câu hỏi đó (event otp_requested, otp_verified; chỉ số = tỷ lệ vượt qua).
3. Phân tích: áp dụng kỹ thuật phù hợp — funnel để thấy rơi rụng, cohort để thấy xu hướng, segmentation để thấy nhóm nào bị nặng.
4. Insight: dịch số thành hiểu biết có hành động được — "khách dùng Android bản cũ rớt OTP gấp 3 lần".
5. Hành động: thay đổi sản phẩm (sửa flow OTP cho bản cũ).
6. Thử nghiệm: đo tác động bằng A/B test trước khi kết luận nhân quả — tránh nhầm tương quan với nhân quả. Nguyên lý thống kê nằm ở A/B testing.

Điểm chốt: bước 6 khép vòng lặp. Không có thử nghiệm, ta chỉ đoán rằng thay đổi có ích.

Minh họa một chỉ số hành vi trên dữ liệu giao dịch

Sandbox của chúng ta là dữ liệu trạng thái ngân hàng (không có event stream đầy đủ), nhưng ta vẫn có thể minh họa một chỉ số hành vi kinh điển: số khách hoạt động theo tháng (Monthly Active Customers) — đếm số khách có ít nhất một giao dịch trong mỗi tháng, một xấp xỉ của "active user" dựa trên bảng transactions:

-- ▶ Chạy được
SELECT
    date_trunc('month', t.created_at)         AS thang,
    COUNT(DISTINCT c.id)                       AS khach_hoat_dong,
    COUNT(*)                                   AS so_giao_dich,
    ROUND(COUNT(*)::numeric / NULLIF(COUNT(DISTINCT c.id), 0), 2) AS gd_binh_quan_khach
FROM transactions t
JOIN accounts   a ON t.account_id = a.id
JOIN customers  c ON a.customer_id = c.id
GROUP BY date_trunc('month', t.created_at)
ORDER BY thang;

Câu này đi từ giao dịch → tài khoản → khách hàng (đúng khóa join transactions.account_id→accounts.id, accounts.customer_id→customers.id), rồi tổng hợp theo tháng. COUNT(DISTINCT c.id) là số khách hoạt động; tỷ số giao dịch/khách là một chỉ số engagement (mức độ gắn kết) thô. Đây chính là dạng số liệu mà, khi có event stream thật, ta sẽ thay transactions bằng bảng events và đo được nhiều hành vi tinh vi hơn (mở màn hình, bấm nút, hoàn tất bước).

Công cụ & quan hệ với data team

Có hai hướng triển khai product analytics, thường dùng song song:

• Nền tảng chuyên dụng (product analytics tools): Amplitude, Mixpanel, GA4 (Google Analytics 4). Ưu điểm: giao diện tự phục vụ cho PM (dựng funnel/cohort bằng vài cú click, không cần SQL), tính năng behavior sẵn có. Nhược: dữ liệu nằm ngoài warehouse, khó nối với dữ liệu tài chính lõi, chi phí theo số event.
• Tự dựng trên data warehouse: đổ event stream vào warehouse (BigQuery/Snowflake/Postgres), mô hình hóa bằng dbt, phân tích bằng SQL và BI. Ưu điểm: kiểm soát hoàn toàn, nối được với dữ liệu ngân hàng lõi (số dư, dư nợ), tuân thủ quản trị dữ liệu. Nhược: cần công sức kỹ thuật.

Với ngân hàng — dữ liệu nhạy cảm, ràng buộc tuân thủ — mô hình lai phổ biến: dùng tool cho tracking real-time và khám phá nhanh, đồng thời đổ event về warehouse để phân tích sâu và kết hợp dữ liệu lõi. Vai trò data team rất then chốt: định nghĩa taxonomy event, đảm bảo chất lượng tracking, xây bảng chỉ số nhất quán (single source of truth), trang bị năng lực phân tích cho PM. Product analytics không thay thế data engineer/analyst — nó là một lớp năng lực họ cung cấp.

Lộ trình series

Series đi từ nền tảng đến thực hành:

1. pa-01 (bài này) — Tổng quan & khung chỉ số.
2. pa-02 — Metric & North Star: định nghĩa chỉ số hành vi, metric tree.
3. pa-03 — Funnel analysis: đo rơi rụng qua từng bước.
4. pa-04 — Cohort & retention: giữ chân theo nhóm gia nhập.
5. pa-05 — Segmentation & RFM: phân khúc hành vi.
6. pa-06 — CLV & churn: giá trị vòng đời và dự báo rời bỏ.
7. pa-07 — Experimentation & growth: A/B test và tăng trưởng.
8. pa-08 — Thực hành ngân hàng: dựng pipeline event end-to-end.

Bài phân khúc còn liên hệ với phân tích & phân khúc trong loyalty.

Use case thực tế

Bối cảnh: NCB ra mắt tính năng chuyển tiền QR trên app. Sau 4 tuần, số giao dịch QR tuyệt đối tăng đều — báo cáo BI trông "đẹp". Nhưng team sản phẩm nghi có vấn đề trải nghiệm.

Áp dụng quy trình:

1. Câu hỏi: trong số khách mở màn hình QR, bao nhiêu hoàn tất giao dịch, và họ rớt ở đâu?
2. Đo: dựng phễu 4 event — qr_screen_open → qr_scan_success → amount_entered → transfer_completed.
3. Phân tích: phễu cho thấy 100% mở màn hình → 78% quét mã thành công → 71% nhập tiền → chỉ 42% hoàn tất. Rơi rụng lớn nhất (78%→? và bước cuối 71%→42%).
4. Insight: segment theo phiên bản app: khách Android bản < 4.5 hoàn tất chỉ 24%, so với 61% ở bản mới — nghi lỗi màn hình xác nhận trên bản cũ.
5. Hành động: fix màn hình xác nhận cho bản cũ + nhắc cập nhật app.
6. Thử nghiệm: A/B test bản fix trên 10% khách Android cũ. Sau 2 tuần, tỷ lệ hoàn tất nhóm test đạt 55% so với 26% nhóm control — chênh lệch có ý nghĩa thống kê. Rollout toàn bộ.

Giá trị: BI truyền thống chỉ thấy "QR tăng"; product analytics chỉ ra một nửa khách đang thất bại thầm lặng, khoanh vùng nguyên nhân, và chứng minh cách sửa mang lại +29 điểm phần trăm tỷ lệ hoàn tất — trực tiếp nâng North Star (khách giao dịch hoạt động).

Ghi nhớ

• Product analytics đo hành vi (event), BI truyền thống đo trạng thái/kết quả (state). Cả hai bổ sung, không thay thế nhau.
• Dữ liệu sự kiện = event + user/entity + timestamp + properties. Đây là nền tảng tái dựng hành trình người dùng; taxonomy event tốt là điều kiện tiên quyết.
• AARRR (Acquisition, Activation, Retention, Referral, Revenue) là bản đồ phễu tăng trưởng; mỗi tầng là một điểm rò rỉ đo và tối ưu được.
• North Star Metric là một chỉ số đại diện giá trị cốt lõi cho khách — nên là chỉ số dẫn (leading), không phải doanh thu; phân rã thành metric tree với input (tác động được) và output (kết quả).
• Quy trình: câu hỏi → đo → phân tích → insight → hành động → thử nghiệm (A/B), rồi lặp lại. Đóng vòng bằng experiment mới chứng minh được nhân quả.
• Công cụ: nền tảng chuyên dụng (Amplitude/Mixpanel/GA4) cho tự phục vụ nhanh, hoặc tự dựng trên warehouse để nối dữ liệu lõi và tuân thủ — ngân hàng thường dùng mô hình lai.
• Với ngân hàng số, product analytics giúp tăng gắn kết và bán chéo (thẻ, vay, tiết kiệm) bằng cách hiểu vì sao khách dùng — hay bỏ — từng tính năng.