Bài 4 — Tìm nguyên nhân khi metric thay đổi (root-cause với AI)

Bối cảnh & vấn đề của bạn

"DAU giảm 9% so với tuần trước!" — tin nhắn lúc 8h sáng. Áp lực dồn lên bạn. Nếu mò mẫm không hệ thống, bạn dễ kết luận vội ("chắc do mùa") hoặc lạc trong hàng chục biểu đồ. AI giúp bạn cấu trúc hóa cuộc điều tra: chia nhỏ metric theo chiều, loại trừ nguyên nhân, đề xuất giả thuyết.

AI giúp được gì

• Đề xuất cây phân rã (segmentation tree): metric giảm ở nền tảng nào, quốc gia nào, phiên bản app nào, nguồn traffic nào.
• Phân biệt thay đổi thật vs lỗi đo lường (tracking hỏng, deploy đổi tên event).
• Sinh giả thuyết theo khung: sản phẩm, kỹ thuật, mùa vụ, ngoại cảnh, dữ liệu.
• Viết truy vấn cho từng nhánh điều tra.

Sức mạnh thật sự của AI ở đây là giúp bạn KHÔNG bỏ sót hướng điều tra. Con người dưới áp lực thường bám vào giả thuyết đầu tiên nghĩ ra (thiên kiến xác nhận). AI có thể liệt kê một danh sách đầy đủ các chiều và giả thuyết để bạn không quên kiểm nhánh nào. Nhưng nhớ: AI đề xuất HƯỚNG, còn kết luận phải dựa trên dữ liệu thật bạn tự kiểm — không phải trên câu chuyện AI kể.

Ví dụ cụ thể

DAU giảm 9%. AI đề xuất phân rã: theo nền tảng → phát hiện chỉ iOS giảm (Android bình thường). Theo phiên bản → giảm mạnh ở bản 4.2.0 vừa release. Giả thuyết: bản 4.2.0 có bug làm crash hoặc đổi tên event app_open khiến tracking mất. Bạn kiểm log crash + so sánh số event trước/sau deploy → xác nhận tracking đổi tên. Vậy đây là lỗi đo lường, không phải user thật sự rời bỏ. Cực kỳ quan trọng: bạn suýt báo cáo sai.

Prompt mẫu — điều tra root-cause

Metric DAU giảm 9% tuần này (từ 110k xuống 100k).
Các chiều dữ liệu tôi có: platform (iOS/Android), country, app_version,
traffic_source, event_name.

Hãy:
1) Lập cây phân rã: nên cắt metric theo chiều nào TRƯỚC (ưu tiên chiều dễ giải thích lớn).
2) Với mỗi chiều, cho câu hỏi kiểm chứng + SQL mẫu (schema events(user_id,event_name,ts,platform,app_version,country)).
3) Liệt kê 5 giả thuyết theo nhóm: sản phẩm / kỹ thuật / tracking / mùa vụ / ngoại cảnh.
4) Với mỗi giả thuyết, nêu bằng chứng CẦN để xác nhận hoặc BÁC BỎ.
Luôn tách "thay đổi thật" khỏi "lỗi đo lường".

Các bước làm

• Xác nhận metric có thật sự thay đổi (kiểm ngưỡng nhiễu, so với dao động thường ngày).
• Loại trừ lỗi đo lường trước tiên: có deploy/đổi event/lỗi pipeline không?
• Nhờ AI lập cây phân rã, cắt theo từng chiều lớn.
• Đi theo nhánh có tín hiệu mạnh nhất; dừng khi tìm được chiều giải thích phần lớn thay đổi.
• Liệt kê giả thuyết, gắn bằng chứng cần có cho mỗi cái.
• Xác nhận bằng dữ liệu, không dừng ở "nghe hợp lý".
• Viết kết luận: nguyên nhân, độ chắc chắn, hành động đề xuất.

Template tái dùng — Ghi chú điều tra Root-Cause

[Metric & mức thay đổi]:
[Có phải nhiễu thường ngày không?]:
[Kiểm tra lỗi đo lường (deploy/tracking/pipeline)]:
[Phân rã theo chiều — chiều nào giải thích nhiều nhất]:
[Giả thuyết → bằng chứng ủng hộ → bằng chứng phản bác]:
[Kết luận + độ chắc chắn (cao/vừa/thấp)]:
[Hành động đề xuất]:

Sai lầm thường gặp

• Bỏ qua lỗi đo lường. Nhiều "biến động metric" thực ra là tracking hỏng. Nếu không kiểm bước này, bạn điều tra sai hướng hàng ngày trời.
• Nhầm tương quan với nhân quả. AI dễ đưa ra câu chuyện mạch lạc ("do chiến dịch marketing") mà thiếu bằng chứng nhân quả. Hỏi "bằng chứng nào bác bỏ giả thuyết này?".
• Ảo giác nguyên nhân. Nếu bạn không đưa dữ liệu thật, AI vẫn tự tin kể một nguyên nhân — hoàn toàn bịa. AI chỉ nên gợi ý HƯỚNG; kết luận phải dựa dữ liệu bạn kiểm.
• Dừng ở giả thuyết đầu tiên (thiên kiến xác nhận). Buộc mình liệt kê giả thuyết cạnh tranh.
• Phụ thuộc quá mức. Đừng dán kết luận của AI thẳng vào báo cáo cho lãnh đạo mà chưa tự xác minh — uy tín của bạn nằm ở con số đúng.

Kết bài: bạn điều tra có hệ thống. Bài 5 dạy kỹ năng sống còn: kiểm chứng số liệu để không báo cáo sai.