DHDataHọc
QuizLesson 8/86 min read+10 XP

Bài tập: thiết kế phân tích

Bạn sẽ học được

  • Áp dụng toàn bộ chương vào một tình huống thực tế.
  • Viết lại yêu cầu mơ hồ thành câu hỏi đo được.
  • Kiểm tra hạt dữ liệu và định nghĩa chỉ số trước khi tính.
  • Nhận diện nhiễu và đề xuất cách kiểm chứng.
  • Trình bày kết luận trung thực với người ra quyết định.

Đề bài

Bạn là người phân tích dữ liệu ở một ứng dụng học trực tuyến. Giám đốc sản phẩm nhắn:

"Tháng trước chúng ta ra mắt tính năng luyện tập theo lộ trình. Nhóm dùng tính năng này có tỷ lệ giữ chân 60%, nhóm không dùng là 45%. Tuần sau họp, tôi muốn tung thông báo cho toàn bộ người dùng. Cậu xác nhận giúp con số này và chuẩn bị slide."

Dữ liệu bạn có:

  • users(id, created_at, plan)
  • events(user_id, event_name, occurred_at)
  • subscriptions(user_id, started_at, ended_at)
  • practice_sessions(user_id, lesson_id, started_at, completed_at)

Hãy trả lời năm câu hỏi dưới đây trước khi mở slide.

Câu 1 — Viết lại yêu cầu thành câu hỏi đo được

Yêu cầu gốc thiếu đối tượng, thời gian, định nghĩa và hành động. Một bản viết lại:

Trong số người dùng hoạt động trong tháng 9/2025, những người có ít nhất một phiên luyện tập hoàn thành trong 14 ngày đầu sau khi tính năng ra mắt có tỷ lệ còn hoạt động ở ngày thứ 30 cao hơn nhóm không dùng bao nhiêu điểm phần trăm? Chênh lệch có còn sau khi kiểm soát thâm niên tài khoản và gói dịch vụ không?

Vì sao cần từng phần:

  • Đối tượng: người dùng hoạt động trong tháng 9, không phải toàn bộ tài khoản từng đăng ký.
  • Thời gian: 14 ngày đầu và mốc 30 ngày — nếu không chốt, mỗi người hiểu một cửa sổ.
  • Định nghĩa "dùng": có phiên hoàn thành, không chỉ mở trang.
  • Kiểm soát: thâm niên và gói dịch vụ là hai biến gây nhiễu rõ ràng.
  • Hành động: nếu chênh lệch còn sau kiểm soát, mới cân nhắc mở rộng.

Câu 2 — Kiểm tra hạt và định nghĩa

Ba điểm phải chốt trước khi tính:

Khái niệmĐịnh nghĩa chọnVì sao
"Dùng tính năng"Có ít nhất một practice_session có completed_at trong 14 ngày đầuMở trang không phải dùng thật
"Còn hoạt động"Có ít nhất một event bất kỳ trong ngày 30–37Tránh phụ thuộc đúng một ngày
HạtMột người dùngGhép theo user_id, không theo email

Nếu không chốt, cùng một câu hỏi có thể ra 60% hoặc 38% tùy cách đếm. Con số 60% trong tin nhắn chưa kèm định nghĩa nên chưa kiểm chứng được.

Câu 3 — Nhiễu nào có thể tạo ra chênh lệch?

Ba ứng viên:

  1. Thâm niên tài khoản. Người dùng mới có thể hào hứng thử tính năng và cũng dễ rời bỏ hơn. Hoặc ngược lại: tài khoản lâu năm quen sản phẩm nên giữ chân cao.
  2. Tự chọn (self-selection). Người dùng chủ động thử tính năng vốn đã gắn bó hơn. Tính năng không tạo ra giữ chân; nhóm gắn bó mới dùng tính năng.
  3. Gói dịch vụ. Người trả phí có nhiều động lực học và cũng dễ tiếp cận tính năng mới.

Ngoài ra, thông báo toàn bộ có thể gây phản ứng ngược: người không quan tâm nhận thông báo sẽ tắt thông báo hoặc rời đi.

Câu 4 — Thiết kế kiểm chứng

Không thể quay lại quá khứ để chia nhóm ngẫu nhiên, nhưng có thể:

  • Ghép cặp: mỗi người dùng tính năng ghép với một người cùng gói, cùng thâm niên (±7 ngày), cùng mức hoạt động 14 ngày trước đó nhưng không dùng.
  • So sánh xu hướng: vẽ tỷ lệ hoạt động theo tuần của hai nhóm trong 6 tuần trước và sau khi ra mắt. Nếu hai đường song song trước đó và tách ra sau, bằng chứng mạnh hơn.
  • Thí nghiệm tương lai: chia ngẫu nhiên 50/50 khi tung thông báo, đo ở ngày 30. Đây là cách duy nhất trả lời chắc chắn.

Với quyết định "tung cho toàn bộ", thí nghiệm tương lai còn giúp đo tác động thật của thông báo, không chỉ của tính năng.

Câu 5 — Viết kết luận cho giám đốc

Một bản kết luận trung thực:

Nhóm dùng tính năng có tỷ lệ còn hoạt động ở ngày 30 là 60% (n = 180), nhóm không dùng là 45% (n = 820). Chênh lệch 15 điểm phần trăm, khoảng tin cậy 95% khoảng 7–23 điểm. Tuy nhiên nhóm dùng tính năng có thâm niên trung bình cao hơn 4 tháng và tỷ lệ gói trả phí cao hơn 18 điểm. Sau khi ghép cặp theo hai yếu tố này, chênh lệch còn khoảng 6 điểm (khoảng 0–12), chưa đủ chắc chắn. Đề xuất: tung thông báo theo thí nghiệm 50/50 trong bốn tuần, đo lại ở ngày 30 trước khi mở rộng toàn bộ.

Bản này nói rõ: con số, cỡ mẫu, khoảng bất định, nhiễu đã kiểm soát, và bước tiếp theo. Nó không từ chối yêu cầu — nó đổi cách làm để câu trả lời đáng tin.

Tự kiểm tra

1. Vì sao không nên dùng luôn 60% và 45% trong slide? Vì chưa có định nghĩa, chưa kiểm tra hạt, và hai nhóm khác nhau về thâm niên/gói. Con số có thể đúng về số học nhưng sai về kết luận.

2. "Dùng tính năng" nên định nghĩa thế nào? Có ít nhất một phiên luyện tập hoàn thành trong cửa sổ đã chốt, không chỉ mở trang hay bắt đầu phiên.

3. Nếu ghép cặp làm chênh lệch về 0, kết luận là gì? Chưa có bằng chứng tính năng tạo ra khác biệt; chênh lệch ban đầu có thể do chọn mẫu. Không có nghĩa tính năng vô dụng — chỉ là dữ liệu quan sát không đủ.

4. Vì sao đề xuất thí nghiệm 50/50 thay vì tung toàn bộ? Vì chỉ thí nghiệm ngẫu nhiên mới tách được tác động của thông báo khỏi nhóm người tự chọn dùng tính năng.

5. Chỉ số bảo vệ nên là gì? Tỷ lệ tắt thông báo và tỷ lệ huỷ gói trong 30 ngày sau khi tung.

6. Nếu mẫu nhỏ, nên báo cáo thế nào? Kèm n và khoảng tin cậy; tránh kết luận "hơn/kém" khi khoảng tin cậy chồng lên nhau.

Lỗi thường gặp

Triệu chứngNguyên nhânCách sửa
Báo cáo hai con số không định nghĩaDùng nguyên yêu cầuViết đặc tả chỉ số trước
Kết luận nhân quả từ quan sátBỏ qua tự chọnGhép cặp hoặc thí nghiệm
Slide không ai quyết đượcKhông có hành độngNêu rõ đề xuất và bước tiếp theo
Bỏ qua rủi ro thông báoKhông có guardrailĐo tỷ lệ tắt thông báo, huỷ gói
Chênh lệch nhỏ bị thổi phồngMẫu nhỏBáo khoảng tin cậy
Dữ liệu trước/sau không so đượcThiếu nhóm đối chứngThêm nhóm so sánh

Tóm tắt

  • Viết lại yêu cầu thành câu hỏi có đối tượng, chỉ số, thời gian, ngưỡng, hành động.
  • Chốt định nghĩa và hạt trước khi tính.
  • Kiểm tra thâm niên, gói dịch vụ và tự chọn trước khi kết luận.
  • Ghép cặp hoặc thí nghiệm để kiểm chứng; thí nghiệm là chuẩn mạnh nhất.
  • Báo cáo kèm n, khoảng bất định, nhiễu và bước tiếp theo.

Use ← → to move between lessons