Mở đầu — vì sao bài này quan trọng
Bạn đã đi qua 59 bài học. Bạn biết JOIN, biết window function, biết CTE, biết cohort, funnel, RFM, churn. Nhưng có một sự thật phũ phàng mà mình muốn nói thẳng với bạn ngay từ đầu: biết viết query không có nghĩa là biết làm phân tích.
Trong thực tế đi làm, không ai đưa cho bạn một câu hỏi gọn gàng kiểu "viết query tính doanh thu theo tháng". Thay vào đó, sếp bạn — một CMO bận rộn, sắp họp leadership — gửi tin nhắn Slack lúc 4 giờ chiều: "Em ơi, tình hình khách hàng quý 1 thế nào? Chị cần báo cáo trước thứ Hai." Câu hỏi mơ hồ, deadline gấp, kỳ vọng cao. Đó mới là công việc thật của một Business Analyst.
Bài Capstone này tồn tại để ráp toàn bộ kỹ năng rời rạc của bạn thành một luồng làm việc end-to-end — từ lúc nhận câu hỏi mơ hồ, đến lúc đặt một slide rõ ràng lên bàn họp. Bạn sẽ thấy SQL chỉ chiếm khoảng 40% giá trị; 60% còn lại nằm ở việc đặt đúng câu hỏi, chọn đúng số liệu, và kể được câu chuyện. Đây là bài quan trọng nhất khóa, vì nó mô phỏng chính xác những gì sẽ phân biệt bạn — một BA giỏi — với một người chỉ biết "chạy số".
Khái niệm cốt lõi
Một dự án phân tích end-to-end gồm những giai đoạn nào?
Hãy hình dung một quy trình 6 bước. Mỗi bước là một "cửa ải" mà nhiều BA mới hay bỏ qua, dẫn đến báo cáo lạc đề:
- Làm rõ yêu cầu (Scoping) — Biến câu hỏi mơ hồ của stakeholder thành các câu hỏi phân tích cụ thể, đo được.
- Hiểu dữ liệu (Data understanding) — Biết bảng nào có gì, dữ liệu có sạch không, khoảng thời gian nào đáng tin.
- Khám phá & truy vấn (Exploration) — Viết query, kiểm tra giả thuyết, tìm tín hiệu.
- Tổng hợp số liệu (Metrics) — Chốt các con số cốt lõi sẽ đưa vào báo cáo.
- Kể chuyện (Storytelling) — Sắp xếp số liệu thành một narrative có insight và đề xuất hành động.
- Trình bày & bảo vệ (Delivery) — Đưa cho stakeholder, trả lời chất vấn, ghi lại giả định.
Đề bài Capstone của chúng ta
> "Phân tích sức khỏe khách hàng e-commerce VN trong Q1 2026" — CMO yêu cầu báo cáo trước họp leadership.
Đây là kiểu yêu cầu điển hình: chữ "sức khỏe khách hàng" (customer health) nghe rất kêu nhưng không có định nghĩa rõ. Việc đầu tiên của BA không phải mở SQL editor, mà là dịch nó. "Sức khỏe khách hàng" thường gồm các trục:
- Acquisition — Có bao nhiêu khách mới? Tăng hay giảm so với Q4?
- Retention — Khách cũ có quay lại mua không?
- Monetization — Mỗi khách đem về bao nhiêu (AOV, LTV)?
- Risk — Tỷ lệ churn, tỷ lệ khách ngủ đông (dormant) ra sao?
Schema mô phỏng
Giả sử bạn làm cho "ShopViet" — một sàn e-commerce VN giả định kiểu Tiki/Shopee. Bạn có quyền read-only vào 3 bảng chính:
customers (customer_id, signup_date, city, channel)orders (order_id, customer_id, order_date, status, gross_amount, discount, net_amount)order_items (order_id, sku, category, qty, unit_price)
2026-01-01 đến 2026-03-31, có dữ liệu Q4 2025 để so sánh.Tình huống thực tế
Tình huống 1: Cái bẫy "doanh thu tăng nhưng sức khỏe giảm"
Tại ShopViet, BA tên Linh nhận đề bài trên. Cô chạy query đầu tiên rất nhanh:
SELECT SUM(net_amount) AS revenue_q1
FROM orders
WHERE order_date BETWEEN '2026-01-01' AND '2026-03-31'
AND status = 'completed';
Kết quả: doanh thu Q1 đạt 48 tỷ, tăng 18% so với Q4. Linh định báo cáo luôn "khách hàng khỏe mạnh, doanh thu tăng 18%". May là cô dừng lại và tách doanh thu theo khách mới vs khách cũ:
SELECT
CASE WHEN c.first_order_date >= '2026-01-01'
THEN 'new' ELSE 'returning' END AS cohort,
SUM(o.net_amount) AS revenue,
COUNT(DISTINCT o.customer_id) AS buyers
FROM orders o
JOIN (
SELECT customer_id, MIN(order_date) AS first_order_date
FROM orders WHERE status = 'completed'
GROUP BY customer_id
) c ON o.customer_id = c.customer_id
WHERE o.order_date BETWEEN '2026-01-01' AND '2026-03-31'
AND o.status = 'completed'
GROUP BY 1;
Phát hiện gây sốc: 92% mức tăng doanh thu đến từ khách mới được kéo về bằng voucher giảm giá sâu, trong khi doanh thu từ khách cũ giảm 7%. Nói cách khác, ShopViet đang "đốt tiền marketing" để mua khách mới, còn nền tảng khách trung thành thì đang xói mòn.
Bài học: Một con số tổng (top-line) luôn che giấu câu chuyện thật. BA giỏi luôn hỏi "con số này được tạo nên từ đâu?" trước khi kết luận. Nếu Linh báo cáo "doanh thu tăng 18%, mọi thứ ổn", cô đã vô tình giúp công ty lao nhanh hơn vào vực.
Tình huống 2: Khi stakeholder hỏi một đằng, dữ liệu trả lời một nẻo
Một BA tại Be Group (ride-hailing) được CEO hỏi: "Tại sao tài xế khu vực Thủ Đức rời nhiều thế?". Anh BA này lao vào viết churn query cho tài xế Thủ Đức. Nhưng khi làm bước data understanding trước, anh phát hiện cột region được điền tay, và "Thủ Đức" bị nhập thành 6 biến thể: "Thu Duc", "TĐ", "Q.Thủ Đức", "TP Thủ Đức"... Nếu anh lọc region = 'Thủ Đức' thì bỏ sót 40% dữ liệu, ra kết luận sai hoàn toàn.
Anh phải chuẩn hóa trước bằng CASE WHEN / pattern matching, rồi mới phân tích. Kết quả thật: churn không cao bất thường ở Thủ Đức; vấn đề thực sự là một đối thủ vừa tung chương trình thưởng ở toàn TP.HCM.
Bài học: Đừng tin tên cột và giá trị dữ liệu là sạch. Giai đoạn data understanding (bước 2) tưởng nhàm chán nhưng cứu bạn khỏi báo cáo sai. Một con số sai trình lên leadership có thể khiến công ty ra quyết định tốn hàng tỷ đồng.
Tình huống 3: Báo cáo đúng nhưng vô dụng vì không có "so what"
BA tại một ví điện tử kiểu MoMo trình một dashboard tuyệt đẹp: 14 biểu đồ, churn rate, retention curve, LTV theo cohort. Giám đốc nhìn 10 giây rồi hỏi: "Vậy chị cần làm gì?". BA ấp úng vì cả báo cáo chỉ mô tả (descriptive), không có đề xuất (prescriptive).
Một báo cáo tốt phải dẫn từ số → insight → hành động. Ví dụ thay vì nói "retention tháng 2 là 31%", hãy nói: "Retention tháng 2 chỉ 31%, thấp hơn benchmark ngành (45%); nguyên nhân chính là nhóm khách đến từ kênh affiliate giá rẻ (retention chỉ 12%). Đề xuất: cắt 30% ngân sách affiliate, dồn sang kênh organic có retention 52%."
Bài học: Stakeholder không trả lương cho bạn để mô tả thực tại; họ trả lương để bạn giúp họ ra quyết định. Mỗi số liệu trong báo cáo nên trả lời được câu hỏi "vậy thì sao?".
Hướng dẫn từng bước
Đây là quy trình bạn áp dụng cho đề bài ShopViet. Hãy làm theo đúng thứ tự.
Bước 1 — Scoping: dịch yêu cầu mơ hồ thành câu hỏi đo được. Viết ra giấy (hoặc nhắn lại CMO để xác nhận) 4–5 câu hỏi cụ thể:
- Q1 có bao nhiêu khách mua hàng (active buyers), so với Q4?
- Tỷ lệ khách mới / khách quay lại là bao nhiêu?
- AOV và doanh thu/khách thay đổi thế nào?
- Retention tháng-qua-tháng trong quý ra sao?
- Bao nhiêu % khách có dấu hiệu churn?
Bước 2 — Data understanding. Trước khi phân tích, chạy các query "thăm dò sức khỏe dữ liệu":
-- Kiểm tra khoảng thời gian thật sự có dữ liệu
SELECT MIN(order_date), MAX(order_date), COUNT(*) FROM orders;-- Kiểm tra giá trị status để biết lọc gì
SELECT status, COUNT(*) FROM orders GROUP BY status;
-- Kiểm tra NULL / âm trong cột tiền
SELECT
SUM(CASE WHEN net_amount IS NULL THEN 1 ELSE 0 END) AS null_amt,
SUM(CASE WHEN net_amount < 0 THEN 1 ELSE 0 END) AS neg_amt
FROM orders;
Ghi lại mọi điều bất thường: đơn cancelled/refunded cần loại khỏi doanh thu, đơn test của nội bộ cần lọc, v.v.
Bước 3 — Xây các metric cốt lõi bằng CTE. Dùng CTE để query dễ đọc, dễ kiểm tra. Ví dụ tính metric tổng quan Q1:
WITH q1_orders AS (
SELECT * FROM orders
WHERE order_date BETWEEN '2026-01-01' AND '2026-03-31'
AND status = 'completed'
)
SELECT
COUNT(DISTINCT customer_id) AS active_buyers,
COUNT(*) AS total_orders,
ROUND(SUM(net_amount), 0) AS revenue,
ROUND(SUM(net_amount) / COUNT(*), 0) AS aov,
ROUND(SUM(net_amount)
/ COUNT(DISTINCT customer_id), 0) AS revenue_per_buyer
FROM q1_orders;
Bước 4 — Phân tích retention (cohort). Áp dụng kỹ thuật cohort bạn học ở Bài 29:
WITH first_month AS (
SELECT customer_id,
DATE_FORMAT(MIN(order_date), '%Y-%m') AS cohort_month
FROM orders WHERE status='completed'
GROUP BY customer_id
),
activity AS (
SELECT DISTINCT customer_id,
DATE_FORMAT(order_date, '%Y-%m') AS active_month
FROM orders WHERE status='completed'
)
SELECT f.cohort_month, a.active_month,
COUNT(DISTINCT a.customer_id) AS active_customers
FROM first_month f
JOIN activity a ON f.customer_id = a.customer_id
GROUP BY 1, 2
ORDER BY 1, 2;
Bước 5 — Phát hiện churn. Định nghĩa churn rõ ràng (ví dụ: khách từng mua nhưng không có đơn nào trong 60 ngày gần nhất). Ghi định nghĩa này vào báo cáo — vì "churn" mỗi công ty hiểu một kiểu.
Bước 6 — Tổng hợp & kể chuyện. Gom 5–6 số liệu quan trọng nhất (không phải tất cả), sắp theo cấu trúc: Tình hình → Vấn đề → Nguyên nhân → Đề xuất. Mỗi số đi kèm một câu "so what".
Bước 7 — Trình bày. Một slide tiêu đề nói thẳng kết luận (ví dụ: "Doanh thu tăng nhưng nền khách trung thành đang xói mòn — cần điều chỉnh chiến lược voucher"), 2–3 biểu đồ hỗ trợ, một slide đề xuất hành động. Đính kèm phụ lục query để người khác tái lập được (reproducibility).
Lỗi thường gặp & mẹo
- Lao vào SQL trước khi hiểu câu hỏi. Đây là lỗi số một. Dành 20 phút làm rõ scope tiết kiệm cho bạn 2 ngày làm lại. Luôn xác nhận lại với stakeholder bằng văn bản.
- Quên loại đơn không hợp lệ. Tính doanh thu mà gộp cả đơn
cancelled,refunded, hay đơn test nội bộ là sai kinh điển. Luôn có mệnh đềstatus = 'completed'(hoặc tương đương) và lọc đơn test. - Đếm trùng vì JOIN nở dòng. Khi JOIN
ordersvớiorder_items, một đơn nhiều item sẽ bị nhân lên. Tính doanh thu cấp đơn thì dùngCOUNT(DISTINCT order_id)và đừngSUM(net_amount)sau khi đã JOIN xuống cấp item. - Không cố định khung thời gian. "Q1" của bạn và "Q1" của người khác có thể lệch nếu một người dùng
order_date, người kia dùngsignup_date. Ghi rõ định nghĩa. - Báo cáo chỉ có mô tả, thiếu "so what". Mỗi con số phải dẫn tới một insight và (lý tưởng) một đề xuất.
- Mẹo dùng số làm tròn khi trình bày. CMO không cần "48.327.119.450 đồng"; hãy nói "≈48,3 tỷ". Độ chính xác giả tạo làm loãng thông điệp.
- Mẹo ghi lại giả định (assumptions). Cuối báo cáo luôn có mục "Giả định & giới hạn": định nghĩa churn, đơn nào bị loại, khoảng thời gian. Đây là dấu hiệu của một BA chuyên nghiệp và bảo vệ bạn khi bị chất vấn.
- Mẹo sanity-check số tổng. Trước khi trình, kiểm tra: tổng doanh thu các cohort có bằng doanh thu tổng không? Số khách mới + khách cũ có bằng tổng active buyers không? Nếu lệch, có bug ở đâu đó.
Bài tập thực hành
Dùng schema ShopViet (hoặc bất kỳ dataset e-commerce nào bạn có), hoàn thành một mini-capstone:
- Scoping (viết tay, không SQL): Viết ra 5 câu hỏi phân tích cụ thể mà bạn sẽ trả lời cho đề bài "sức khỏe khách hàng Q1". Mỗi câu phải đo được bằng một metric.
- Data understanding: Viết 3 query thăm dò: khoảng thời gian dữ liệu, phân bố
status, và kiểm tra NULL/giá trị âm ở cột tiền. Ghi lại ít nhất 2 điều cần lưu ý. - Metrics tổng quan: Viết một query (dùng CTE) trả về cho Q1: active buyers, total orders, revenue, AOV, revenue per buyer. Lặp lại cho Q4 2025 và tính % thay đổi.
- Tách khách mới vs khách cũ: Tái hiện phân tích ở Tình huống 1 — doanh thu và số người mua theo nhóm new/returning. Nhận xét: tăng trưởng đến từ đâu?
- Retention: Xây bảng cohort retention theo tháng cho 3 cohort (tháng 1, 2, 3). Tính retention rate tháng kế tiếp.
- Churn: Định nghĩa churn của riêng bạn (ghi rõ tiêu chí), rồi viết query đếm số và tỷ lệ khách churn cuối Q1.
- Storytelling (quan trọng nhất): Viết một đoạn báo cáo 200 từ theo cấu trúc Tình hình → Vấn đề → Nguyên nhân → Đề xuất, kèm đúng 3 số liệu chủ chốt và 1 đề xuất hành động cụ thể cho CMO.
Tóm tắt
Capstone không phải để bạn khoe đã biết bao nhiêu hàm SQL, mà để chứng minh bạn biết biến một câu hỏi kinh doanh mơ hồ thành một quyết định rõ ràng. Hãy nhớ ba điều cốt lõi:
- Quy trình quan trọng hơn cú pháp. Scoping → data understanding → exploration → metrics → storytelling → delivery. Bỏ qua bước đầu và bước cuối là nguyên nhân khiến phần lớn báo cáo thất bại.
- Mỗi con số phải có "so what". Số tổng luôn che giấu câu chuyện thật; hãy bóc tách (theo cohort, theo kênh, theo new/returning) cho tới khi tìm ra insight có thể hành động.
- BA giỏi được nhớ vì câu chuyện, không vì query. Người ta sẽ quên CTE bạn viết, nhưng nhớ slide bạn nói "chúng ta đang đốt tiền mua khách mới trong khi mất dần khách trung thành — và đây là việc cần làm."