Bối cảnh & vấn đề của bạn
Thứ Ba, 9h sáng. Cảnh báo: conversion checkout giảm từ 8.1% xuống 5.4% trong 3 ngày. Doanh thu ước tính mất ~15%/ngày. Sếp gọi họp khẩn lúc 11h. Bạn có 2 giờ để hiểu chuyện gì và đề xuất hành động. Đây là lúc gộp mọi kỹ năng đã học: truy vấn, phân rã, kiểm chứng, và trình bày. Ta đi qua toàn bộ quy trình như một buổi thực chiến.
Diễn tiến từng bước với AI
Bước 1 — Xác nhận thật hay nhiễu. Bạn hỏi AI lập truy vấn so sánh conversion 14 ngày, để thấy dao động nền. Kết quả: bình thường dao động ±0.4%; cú giảm 2.7 điểm là THẬT, vượt xa nhiễu.
Bước 2 — Loại lỗi đo lường. Bạn kiểm có deploy nào không. Có: bản web 3.7 lên đúng hôm bắt đầu giảm. Bạn nhờ AI so sánh số lượng event checkout_start và purchase trước/sau deploy — cả hai vẫn ghi nhận bình thường về số lượng → tracking KHÔNG hỏng. Vậy đây là thay đổi thật, không phải đo lường.
Bước 3 — Phân rã. Prompt:
Conversion checkout giảm 8.1%→5.4% từ ngày [X], sau deploy web 3.7.
Chiều dữ liệu: platform(web/ios/android), browser, country, payment_method.
Schema: events(user_id,event_name,ts,platform,browser,country,payment_method).
Hãy: lập cây phân rã ưu tiên, cho SQL từng nhánh (COUNT DISTINCT user),
và nêu bằng chứng cần để xác nhận/bác bỏ mỗi nhánh.
AI đề xuất cắt theo platform trước. Kết quả: chỉ web giảm, app không đổi. Cắt tiếp theo browser: giảm tập trung ở Safari. Cắt theo payment_method: bước chọn ví điện tử bị rớt.
Bước 4 — Giả thuyết & bằng chứng. Giả thuyết: bản web 3.7 làm nút thanh toán ví lỗi trên Safari. Bằng chứng cần: log lỗi JS trên Safari + funnel dừng ở bước chọn ví. Bạn kiểm: đúng, tỷ lệ rớt ở bước ví trên Safari tăng vọt.
Bước 5 — Kiểm chứng số liệu. Trước khi báo cáo, bạn nhờ AI giải thích lại SQL, tính lại conversion bằng cách độc lập (theo phiên thay vì theo user) — cùng cho ~5.4%. Sanity check: web Safari chiếm ~18% traffic, đủ để kéo tổng giảm 2.7 điểm. Con số nhất quán.
Bước 6 — Trình bày. Bạn nhờ AI viết tóm tắt điều hành 5 dòng: nguyên nhân (bug thanh toán ví trên Safari sau web 3.7), tác động (~15% doanh thu/ngày), độ chắc chắn (cao), hành động (rollback web 3.7 ngay + hotfix). Bạn tự đọc lại từng con số.
Template tái dùng — Playbook điều tra sự cố metric (2 giờ)
[0-15'] Xác nhận thật/nhiễu (so dao động nền)
[15-30'] Loại lỗi đo lường (deploy? tracking? pipeline?)
[30-75'] Phân rã theo chiều lớn → tìm segment giải thích chính
[75-95'] Giả thuyết + bằng chứng xác nhận/bác bỏ
[95-110'] Kiểm chứng chéo con số (phương pháp độc lập + sanity)
[110-120'] Viết tóm tắt: nguyên nhân | tác động | độ chắc | hành động
Các bước làm (rút gọn để nhớ)
- Thật hay nhiễu? 2. Đo lường có hỏng? 3. Phân rã tìm segment. 4. Giả thuyết + bằng chứng. 5. Kiểm chứng chéo. 6. Trình bày kèm độ chắc chắn & hành động.
Sai lầm thường gặp
- Nhảy vào giả thuyết yêu thích. Áp lực họp khẩn khiến bạn chốt vội "chắc do marketing". Giữ kỷ luật quy trình.
- Bỏ bước kiểm chứng vì gấp. Càng gấp càng dễ báo sai; một sanity check 5 phút cứu uy tín của bạn.
- Ảo giác dưới áp lực. Khi bạn hỏi dồn, AI có thể đưa nguyên nhân nghe rất thuyết phục nhưng không có bằng chứng. Luôn đòi bằng chứng dữ liệu.
- Không nêu độ chắc chắn. Báo cáo "chắc chắn do X" khi mới có tín hiệu sơ bộ là bẫy. Ghi rõ mức độ tin cậy.
- Phụ thuộc quá mức vào tóm tắt AI. Tóm tắt AI viết đẹp nhưng bạn ký tên; đọc lại từng số trước khi gửi lãnh đạo.