Success metrics là gì? Chốt chỉ số trước khi làm tính năng

Success metrics là gì, và vì sao phải chốt trước khi làm?

Success metrics (chỉ số thành công) là con số cho biết một tính năng có tạo ra thay đổi hành vi mà team mong đợi hay không. Nên chốt trước khi làm: một chỉ số chính, một đến hai chỉ số bảo vệ, kèm mốc hiện tại, mục tiêu, thời hạn và nguồn số.

Một tình huống minh họa. Bạn là PO của Bếp Xinh, một shop đồ bếp online giả định. Trong buổi backlog refinement, team bàn tính năng “điền sẵn địa chỉ đã lưu ở bước thanh toán” cho khách cũ. Trưởng nhóm kinh doanh nói: “Làm xong chắc chuyển đổi tăng.” Một bạn dev hỏi: “Vậy tăng bao nhiêu thì tính là thành công?” Không ai trả lời. Bạn ghi vào ticket: “Mục tiêu: tăng chuyển đổi.”

Sáu tuần sau ra mắt, buổi xem lại biến thành tranh luận. Kinh doanh nhìn doanh thu tháng, thấy tăng nhờ đợt khuyến mãi. Marketing nhìn số người vào trang, thấy giảm. Bạn nhìn tỷ lệ đặt hàng, thấy nhích nhẹ nhưng không biết thế là tốt hay chưa. Mỗi người chọn một con số, và con số nào cũng có lý.

Bài này đi qua một cách chốt chỉ số trước khi team bắt tay làm, để buổi xem lại sau ra mắt chỉ còn là việc mở một trang ghi chú và so số. Phần đọc kết quả sau khi ra mắt đã có ở bài đo lường tính năng, bài này tập trung vào phần chuẩn bị.

• Đo lường tính năng sau khi ra mắt

Vì sao chốt chỉ số thành công lại khó?

Ai cũng đồng ý là nên đo. Cái khó nằm ở chỗ khác.

• Mục tiêu bị dời sau khi có kết quả. Khi chưa chốt trước, sau ra mắt rất dễ chọn con số nào đang đẹp nhất. Người ta gọi đây là dời cột gôn: kết quả nào cũng có thể được kể thành thành công.
• Mỗi người hiểu “chuyển đổi” một kiểu. Có người chia cho số người vào trang, có người chia cho số người bắt đầu thanh toán. Cùng một chữ nhưng là hai con số khác nhau.
• Không có mốc hiện tại. Không biết trước khi làm là bao nhiêu thì không nói được sau khi làm là tốt hơn.
• Chưa có dữ liệu để đo. Nếu sự kiện cần đếm chưa được ghi lại, phải thêm vào phạm vi làm. Phát hiện ra điều này sau khi ra mắt thì đã muộn.
• Ngại đặt số cụ thể. Đặt mục tiêu nghe như tự hứa. Nhưng không có số thì cũng không có cách học được gì từ kết quả.

Chốt trước cũng giúp team thẳng hàng. Khi dev, designer và kinh doanh cùng nhìn một con số, các quyết định nhỏ trong lúc làm, như bỏ bớt một bước hay thêm một ô nhập, có chung một thước đo.

Cách đặt chỉ số thành công cho một tính năng

Bài viết đề xuất một chuỗi đơn giản: vấn đề, rồi hành vi mong đợi, rồi số đo, rồi mốc và mục tiêu, cuối cùng là nguồn số và cách quyết định. Mỗi mắt xích trả lời một câu hỏi, và mắt xích sau dựa vào mắt xích trước.

Bước 1, viết vấn đề và hành vi mong đợi thành hai câu. Vấn đề: “Khách cũ trên điện thoại bỏ dở ở bước nhập địa chỉ.” Hành vi mong đợi: “Sau khi có tính năng, khách cũ sẽ đi qua bước địa chỉ nhanh hơn và ít bỏ dở hơn.” Câu thứ hai nói về người dùng, không nói về màn hình. Nếu chưa viết được câu này, vấn đề còn mơ hồ, nên tìm hiểu thêm, ví dụ qua vài cuộc phỏng vấn người dùng.

Bước 2, chọn một chỉ số chính (primary metric). Đây là con số trả lời trực tiếp câu hành vi ở bước 1, và là con số duy nhất dùng để nói “thành công hay chưa”. Sau đó chọn một đến hai chỉ số bảo vệ (guardrail metric): những thứ có thể xấu đi khi team cố đẩy số chính. Microsoft Research mô tả guardrail là các khía cạnh của sản phẩm mà team không muốn bị giảm chất lượng, dù chúng không nhất thiết sẽ tốt lên, với ví dụ như thời gian tải trang hay tỷ lệ lỗi. Bài đo lường sau ra mắt gợi ý dùng hai hoặc ba số đo; ở đây hai hoặc ba số đó được chia vai: một số chính quyết định thành công, phần còn lại là số bảo vệ hoặc tín hiệu muộn để theo dõi.

Bước 3, ghi mốc hiện tại (baseline), mục tiêu (target) và thời hạn (time window). Mốc hiện tại lấy từ dữ liệu một khoảng thời gian gần đây, đủ dài để không bị một ngày bất thường làm lệch. Mục tiêu là con số cụ thể, không phải “tăng”. Thời hạn là khoảng thời gian đo và ngày xem lại. Nếu số người dùng trong khoảng đó quá ít, chênh lệch vài điểm có thể chỉ là dao động tự nhiên. Khi không chắc, hỏi người làm dữ liệu trước khi chốt. Nếu chưa có mốc hiện tại vì sự kiện cần đếm chưa được ghi, có hai cách: ghi dữ liệu vài tuần trước khi ra mắt để có mốc, hoặc bật tính năng dần cho một phần người dùng và so với nhóm chưa được bật trong cùng thời gian.

Bước 4, ghi nguồn số và cách quyết định. Nguồn số gồm: con số được đếm từ sự kiện nào, trong công cụ hay bảng dữ liệu nào, ai giữ. Cách quyết định là câu trả lời viết sẵn cho từng kết quả: đạt thì làm gì, tăng mà chưa đạt thì làm gì, gần như không đổi hoặc giảm thì làm gì, chỉ số bảo vệ vượt ngưỡng thì làm gì. Viết trước khi có kết quả là cách đơn giản nhất để không dời cột gôn.

Nhóm nghiên cứu của Google cũng đề xuất khung HEART kèm một quy trình nối mục tiêu sản phẩm với số đo. Bài đo lường sau ra mắt đã giải thích HEART và gợi ý số đo theo từng loại tính năng, bạn có thể dùng bảng ở đó để chọn số ở bước 2.

• Phỏng vấn người dùng: hỏi gì để có câu trả lời thật

Leading và lagging indicator khác nhau thế nào?

Nói ngắn: leading indicator (tín hiệu sớm) cho biết người dùng có dùng và dùng được tính năng không, đọc được sau vài tuần. Lagging indicator (tín hiệu muộn) cho biết điều đó có tạo ra kết quả kinh doanh không, như doanh thu hay mua lại, và cần chờ lâu hơn.

Khi chọn chỉ số chính cho một tính năng, bài viết gợi ý ưu tiên một tín hiệu sớm gắn sát hành vi, vì team tác động được và đọc được trong thời hạn hợp lý. Tín hiệu muộn vẫn nên ghi vào phiếu để theo dõi, nhưng không nên là con số duy nhất quyết định thành công của một tính năng nhỏ. Phần giải thích chi tiết và cách đọc hai loại này sau ra mắt nằm ở bài đo lường tính năng.

• Tín hiệu sớm và tín hiệu muộn khi đo tính năng

Funnel là gì, và người dùng rơi rụng ở đâu?

Một số tin tuyển PO có nhắc tới việc đọc funnel và cohort. Hai khái niệm này nghe như việc của người làm dữ liệu, nhưng ý cơ bản khá đơn giản.

Funnel (phễu) là một chuỗi bước người dùng cần đi qua để hoàn thành một việc, ví dụ: bắt đầu thanh toán, nhập địa chỉ, chọn cách trả tiền, đặt hàng. Theo tài liệu của Amplitude, funnel là một đường đi đã định sẵn trong sản phẩm, và người dùng được tính là đã chuyển đổi khi thực hiện đủ các sự kiện theo thứ tự đã định. Mỗi bước có một số người rơi lại. Nhìn funnel giúp bạn thấy người dùng rơi nhiều nhất ở bước nào, để biết nên sửa ở đâu.

Đọc bảng: trong 4.000 người bắt đầu thanh toán, 2.106 người đặt hàng, tức khoảng 52,7%. Bước nhập địa chỉ mất 1.400 người, nhiều hơn hẳn hai bước sau cộng lại. Đây là lý do tính năng điền sẵn địa chỉ nhắm vào bước 2, không phải bước 4.

Hai điều cần để ý khi đọc funnel. Thứ nhất, luôn hỏi tỷ lệ đang chia cho cái gì: “65%” ở đây là so với số người ở bước trước, khác với “52,7%” là so với điểm bắt đầu. Thứ hai, funnel chỉ cho biết người dùng rơi ở đâu, không cho biết vì sao. Muốn biết vì sao, cần xem ghi chú hỗ trợ khách hàng, quan sát hoặc nói chuyện với người dùng.

Cohort (nhóm người dùng) là một nhóm người có chung một đặc điểm hoặc cùng làm một chuỗi hành động. Mixpanel định nghĩa cohort theo đúng hai cách này. Một cách dùng là nhóm theo thời điểm: ví dụ, gom những người mua lần đầu trong cùng một tuần, rồi xem bao nhiêu phần trăm trong mỗi nhóm quay lại mua trong 30 ngày. So nhóm tuần này với nhóm tuần trước giúp bạn so cùng loại với cùng loại, thay vì gộp người mới và người cũ vào một con số chung. Với tính năng ở Bếp Xinh, “khách cũ trên điện thoại” chính là một cohort: chỉ số chính được đo trên đúng nhóm này.

Nếu bạn được cấp quyền đọc dữ liệu, đếm số người ở từng bước funnel là một trong những câu truy vấn đầu tiên đáng học.

• PO có cần biết SQL không?

Ví dụ chỉ số bảo vệ cho từng loại tính năng

Chỉ số bảo vệ trả lời câu hỏi: nếu team đẩy số chính lên bằng mọi giá, điều gì có thể hỏng? Bảng dưới là gợi ý của bài viết để bàn với team, không phải danh sách bắt buộc.

Chỉ số bảo vệ cần có ngưỡng, không cần mục tiêu tăng. Ví dụ: “tỷ lệ đơn hoàn vì sai địa chỉ không vượt 2%”. Nếu vượt ngưỡng, team dừng lại xem xét dù chỉ số chính đang đẹp.

Ví dụ: phiếu chỉ số cho tính năng điền sẵn địa chỉ

Quay lại Bếp Xinh. Đây là phiếu chỉ số team có thể chốt trong buổi refinement, dựa trên funnel ở trên. Shop và mọi con số đều là giả định để minh họa.

Thời hạn: đo bốn tuần sau khi bật cho toàn bộ khách cũ, xem lại vào một ngày đã ghi trong lịch. Nếu bốn tuần đó trùng một đợt sale lớn như 11.11 hoặc 12.12, ghi rõ vào phiếu, vì lượng khách và hành vi trong đợt sale có thể khác ngày thường.

Kiểm tra nhanh con số mục tiêu có hợp lý không. Nếu tỷ lệ qua bước địa chỉ lên 75% và hai bước sau vẫn giữ 90%, thì với cùng 4.000 người bắt đầu thanh toán: 3.000 người qua bước địa chỉ, 2.700 người chọn cách trả tiền, 2.430 người đặt hàng. Tức thêm 324 đơn trong bốn tuần so với 2.106 đơn hiện tại. Đây là phép tính trên giả định hai bước sau không đổi. Nó giúp kinh doanh thấy con số mục tiêu có ý nghĩa gì, nhưng tổng số đơn vẫn là tín hiệu muộn, không thay chỉ số chính.

Cách quyết định, viết sẵn trước khi có kết quả. Team chốt cùng người giữ dữ liệu rằng thay đổi dưới 2 điểm phần trăm, lên hay xuống, được tính là chưa đổi. Con số 2 điểm này cũng là giả định của ví dụ; với lượng người dùng của bạn, hãy hỏi người giữ dữ liệu mức nào là đủ để không nhầm với dao động.

• Chỉ số chính đạt 75% trở lên và hai chỉ số bảo vệ trong ngưỡng: giữ tính năng, cân nhắc bước tiếp như gợi ý địa chỉ cho khách mới.
• Chỉ số chính từ 67% đến dưới 75% (tăng ít nhất 2 điểm nhưng chưa đạt): tách funnel theo hệ điều hành hoặc theo số địa chỉ đã lưu để tìm nhóm còn rơi nhiều, rồi quyết định sửa tiếp hay dừng.
• Chỉ số bảo vệ vượt ngưỡng, ở bất kỳ mức nào của chỉ số chính: tạm tắt điền sẵn cho nhóm bị ảnh hưởng, tìm nguyên nhân trước khi bật lại, dù chỉ số chính đang tăng.
• Chỉ số chính từ trên 63% đến dưới 67% (thay đổi dưới 2 điểm, tính là chưa đổi): quay lại tìm hiểu vì sao khách rơi ở bước địa chỉ, có thể vấn đề không nằm ở việc gõ lại địa chỉ.
• Chỉ số chính từ 63% trở xuống (giảm từ 2 điểm trở lên): trước hết kiểm tra sự kiện “nhập xong địa chỉ” còn được ghi đúng không. Nếu dữ liệu đúng, tạm tắt điền sẵn và tìm hiểu vì sao khách rơi nhiều hơn trước khi bật lại.

Hai sự kiện “bắt đầu thanh toán” và “nhập xong địa chỉ” đã có sẵn, nên mới lấy được mốc 65%. Nhưng tính năng mới thay đổi chính bước đo: khi địa chỉ được điền sẵn, khách có thể đi tiếp mà không gõ gì, và sự kiện “nhập xong địa chỉ” có thể không còn được ghi. Vì vậy acceptance criteria của story nên có một dòng kiểm tra hai sự kiện này vẫn được ghi đúng, kể cả khi khách dùng địa chỉ điền sẵn, để QA kiểm cả phần dữ liệu chứ không chỉ phần giao diện. Nếu sự kiện ngừng được ghi, chỉ số chính sẽ giảm dù khách đi qua bước nhanh hơn.

• Acceptance criteria là gì? Cách viết để QA kiểm thử được

Chỉ số này đã đủ tốt chưa?

Trước khi ghi chỉ số vào tài liệu, đi qua năm câu hỏi dưới đây. Trả lời “có” thì đi tiếp. Trả lời “không” hoặc “chưa” thì làm việc ghi kèm câu đó rồi hỏi lại.

Khi báo cáo kết quả sau này, kể cả khi số được một công cụ AI tổng hợp giúp, hãy đối chiếu lại với đúng công thức và nhóm người dùng đã ghi trong phiếu.

• Số liệu do AI phân tích: kiểm tra gì trước khi báo cáo

Mẫu phiếu định nghĩa chỉ số trên một trang

Copy mẫu dưới đây vào tài liệu của team, điền trong buổi refinement và cho cả người giữ dữ liệu đọc. Phần mục tiêu của phiếu có thể dán thẳng vào mục “Mục tiêu và cách đo” trong tài liệu yêu cầu một trang.

Tính năng: [tên]
Người phụ trách: [tên PO] | Người giữ dữ liệu: [tên]
Ngày chốt: [ngày]

1. VẤN ĐỀ
[Ai] đang gặp [vấn đề gì], thấy ở [đâu, bằng chứng gì].

2. HÀNH VI MONG ĐỢI
Sau khi có tính năng này, [ai] sẽ [làm gì khác đi] để [đạt được gì].

3. CHỈ SỐ CHÍNH
Tên: [tên]
Cách tính: [tử số] chia [mẫu số]
Nhóm người dùng: [nhóm]
Mốc hiện tại: [số], lấy từ [khoảng thời gian]
Mục tiêu: [số cụ thể]

4. CHỈ SỐ BẢO VỆ (1 đến 2)
Tên: [tên] | Cách tính: [công thức] | Mốc hiện tại: [số] | Ngưỡng không vượt: [số]
Tên: [tên] | Cách tính: [công thức] | Mốc hiện tại: [số] | Ngưỡng không vượt: [số]

5. THỜI HẠN
Đo từ [ngày] đến [ngày]. Ngày xem lại: [ngày].
Sự kiện có thể làm lệch số trong thời gian đo: [sale, chiến dịch, thay đổi khác]

6. NGUỒN SỐ
Sự kiện hoặc bảng dữ liệu: [tên]
Công cụ: [tên]
Cần thêm việc ghi dữ liệu: [có / không, là gì]

7. TÍN HIỆU MUỘN ĐỂ THEO DÕI
[tên số, ví dụ tổng đơn hoặc tỷ lệ mua lại]

8. CÁCH QUYẾT ĐỊNH
Đạt mục tiêu, chỉ số bảo vệ trong ngưỡng: [làm gì]
Mức thay đổi tính là chưa đổi: dưới [số] điểm, chốt cùng người giữ dữ liệu
Tăng từ mức đó trở lên nhưng chưa đạt mục tiêu: [làm gì]
Thay đổi dưới mức đó, tính là chưa đổi: [làm gì]
Giảm từ mức đó trở lên: [kiểm tra dữ liệu, rồi làm gì]
Chỉ số bảo vệ vượt ngưỡng: [làm gì]

• PRD là gì? Cách viết tài liệu yêu cầu một trang

Những lỗi dễ mắc khi đặt chỉ số thành công

• Ghi “tăng chuyển đổi” mà không có số. Không có mốc và mục tiêu thì mọi mức tăng đều có thể gọi là thành công.
• Chọn chỉ số quá xa tính năng. Doanh thu tháng chịu ảnh hưởng của khuyến mãi, mùa vụ và quảng cáo. Một tính năng nhỏ khó tạo ra khác biệt đọc được trên con số đó.
• Đặt năm, sáu chỉ số chính. Khi có nhiều số, sau ra mắt dễ chọn số đang đẹp. Giữ một số chính, phần còn lại là bảo vệ hoặc theo dõi.
• Quên chỉ số bảo vệ. Tỷ lệ qua bước địa chỉ có thể tăng vì điền sẵn một địa chỉ cũ đã sai. Không đo đơn giao sai thì team không thấy được cái giá đó.
• Không hỏi người giữ dữ liệu trước. Có số trông rất hợp lý nhưng chưa được ghi lại ở đâu cả. Hỏi trước giúp đưa việc ghi dữ liệu vào phạm vi làm.
• Đổi mục tiêu sau khi có kết quả. Nếu thật sự cần đổi, ghi lý do và ngày đổi vào phiếu, và xem kết quả theo cả mục tiêu cũ lẫn mới.

Tóm tắt

• Success metrics là con số team chốt trước để biết tính năng có tạo ra thay đổi hành vi mong đợi hay không.
• Chuỗi cần chốt: vấn đề, hành vi mong đợi, một chỉ số chính, một đến hai chỉ số bảo vệ, mốc hiện tại, mục tiêu, thời hạn, nguồn số.
• Funnel cho biết người dùng rơi ở bước nào. Cohort giúp so cùng một nhóm người dùng với nhau.
• Chỉ số bảo vệ có ngưỡng, không cần tăng. Vượt ngưỡng thì dừng lại xem xét dù chỉ số chính đang đẹp.
• Viết sẵn cách quyết định cho từng kết quả trước khi ra mắt, để không dời cột gôn.

Mình đang soạn thêm các tình huống PO khác theo cùng khung này, kèm mẫu dùng ngay. Nếu bạn muốn nhận khi có bài mới, đăng ký bản tin bên dưới.

• Nhận bài mới qua email

Câu hỏi thường gặp

Success metrics là gì?

Success metrics, hay chỉ số thành công, là con số team chốt trước để biết một tính năng có tạo ra thay đổi mong đợi ở người dùng hay không. Mỗi chỉ số cần có cách tính, mốc hiện tại, mục tiêu, thời hạn và nguồn số.

Guardrail metric là gì?

Guardrail metric, hay chỉ số bảo vệ, là con số team không muốn bị xấu đi khi theo đuổi chỉ số chính, ví dụ thời gian tải trang, tỷ lệ lỗi hoặc tỷ lệ đơn giao sai. Nó không cần tăng, chỉ cần không vượt ngưỡng đã chốt.

Một tính năng nên có bao nhiêu chỉ số thành công?

Một chỉ số chính để trả lời câu hỏi có thành công không, cộng một đến hai chỉ số bảo vệ. Nhiều hơn thế thì dễ chọn con số đẹp nhất sau khi ra mắt.

Nguồn kiểm tra

• Google Research: Measuring the User Experience on a Large Scale (HEART)
• Amplitude: Build a funnel analysis
• Mixpanel: Cohorts
• Microsoft Research: Patterns of trustworthy experimentation, experiment stage

Bài liên quan

• Đo lường tính năng sau ra mắt: làm sao biết nó có ích?: Ra mắt chỉ là output. Bài này chỉ cách chốt hành vi mong đợi, số đo, mốc hiện tại, mục tiêu và thời hạn trước khi làm, rồi đọc kết quả để quyết định cải tiến, mở rộng, đo thêm hay gỡ.
• PO có cần biết SQL không?: Không cần thành data analyst. Nhưng bạn nên biết cách biến tò mò thành một câu hỏi có thể kiểm tra.
• Dùng Claude cho PO: việc nào giúp được, việc nào phải tự làm: AI soạn nháp rất nhanh. Bài này chỉ ra bốn lỗi cần soi và một checklist để kiểm tra trước khi tài liệu tới tay team.
• User story là gì? Cách viết cho người mới, kèm mẫu và ví dụ: Mẫu “Là…, tôi muốn…, để…” là phần dễ. Bài này chỉ cách chọn đúng người dùng, đúng vấn đề và cắt story đủ nhỏ, kèm ví dụ trước và sau.