Dựng bộ chỉ số cho một sản phẩm từ con số không

Mỗi lần vào một sản phẩm chưa có bộ chỉ số, mình đều bắt đầu bằng cùng một câu hỏi: nếu chỉ được xem một số mỗi tuần, số đó là gì?

Bài này là ghi chú cách mình dựng bộ chỉ số, viết theo thứ tự mình thật sự làm chứ không theo sơ đồ đẹp.

Bắt đầu từ hành vi, không từ dashboard

Trước khi mở SQL, mình viết ra chuỗi hành vi mà người dùng phải đi qua để nhận được giá trị. Với một sản phẩm đặt xe thì đó là: mở app → có kết quả tìm kiếm → đặt → được nhận → hoàn thành chuyến.

Chuỗi này quyết định mọi thứ phía sau. Nếu chọn sai bước “giá trị đã được nhận”, cả bộ chỉ số sẽ đo cái gì đó gần đúng nhưng lệch.

Chọn một chỉ số bắc cầu

Chỉ số bắc cầu (north star) không phải doanh thu, cũng không phải lượt mở app. Mình tìm số thoả ba điều kiện:

Tăng khi người dùng thật sự nhận được giá trị
Đội ngũ có thể tác động trong vòng một quý
Không thể tăng bằng cách làm sản phẩm ồn hơn

Với ví dụ trên, “chuyến hoàn thành mỗi người dùng hoạt động tuần” thoả cả ba. “Lượt tìm kiếm” thì không — nó tăng cả khi người dùng phải tìm lại vì lần đầu thất bại.

Viết định nghĩa trước khi viết query

Đây là bước hay bị bỏ. Mỗi chỉ số mình viết một khối định nghĩa bằng tiếng người:

Thành phần	Nội dung
Tên	Chuyến hoàn thành / WAU
Đơn vị đếm	Chuyến có trạng thái `finished`
Mẫu	Người dùng có ≥1 phiên trong 7 ngày
Cửa sổ	Tuần ISO, theo giờ địa phương
Loại trừ	Chuyến nội bộ, chuyến test, tài khoản staff

Khi định nghĩa nằm trên giấy, tranh luận chuyển từ “số của ai đúng” sang “định nghĩa nào hợp”.

Đặt guardrail ngay từ đầu

Một chỉ số chính đi kèm hai đến ba guardrail để không tối ưu một chỗ mà phá chỗ khác:

Tỉ lệ huỷ sau khi đặt
Thời gian chờ trung vị (p50) và p90
Tỉ lệ khiếu nại trên 1.000 chuyến

Nếu chỉ số chính tăng mà guardrail xấu đi, mình coi thí nghiệm là chưa kết luận, không phải thắng.

Kiểm tra bằng ba câu hỏi nhàm chán

Trước khi công bố, mình luôn chạy ba kiểm tra:

Đếm hai lần: query lại bằng đường khác, sai số dưới 1%?
Cắt lại thời gian: đổi cửa sổ tuần sang 14 ngày, trend còn giữ hướng?
Cắt theo mẫu: người dùng mới và cũ có cùng chiều không?

Ba câu này rẻ hơn rất nhiều so với việc rút lại một kết luận sau khi lãnh đạo đã quyết theo nó.

Bảo trì: phần không ai thích

Bộ chỉ số chết vì không ai chăm. Những việc mình giữ đều đặn:

Metric sống ở một nơi (semantic layer), dashboard chỉ tiêu thụ
Mỗi chỉ số có một người chịu trách nhiệm tên rõ ràng
Mỗi quý xoá chỉ số không ai dùng — số zombie làm loãng niềm tin

Bộ chỉ số tốt không phải bộ đầy đủ nhất, mà là bộ mà cả công ty còn dám tin sau một năm.

Điều mình vẫn làm sai

Mình vẫn hay dựng quá nhiều chỉ số ở giai đoạn đầu vì sợ thiếu. Kết quả là mất thời gian bảo trì những số chẳng dẫn tới quyết định nào. Lần sau mình sẽ bắt đầu với đúng một chỉ số chính, ba guardrail, và chịu đựng cảm giác thiếu trong vài tuần.