Cách biến dữ liệu sử dụng sản phẩm thành báo cáo mức độ áp dụng tính năng (2026)

Một tệp xuất dữ liệu sử dụng là một danh sách dài các sự kiện: ID người dùng, tên sự kiện, mốc thời gian, và có thể thêm một vài thuộc tính. Trong khi đó, báo cáo mức độ chấp nhận tính năng chỉ là một con số phần trăm duy nhất. Khoảng cách giữa hai điều này nằm ở ba quyết định, chứ không phải là một công thức toán học.

Những người dùng nào nằm ở mẫu số. Hành động nào được tính là đã sử dụng tính năng. Và bạn đang đo lường trong khung thời gian nào.

Thay đổi bất kỳ yếu tố nào trong số đó và con số sẽ dịch chuyển hàng chục điểm phần trăm. Báo cáo trông vẫn có vẻ chính xác, và đó chính là vấn đề.

Hướng dẫn này sẽ đề cập đến những việc cần thống nhất trước tiên, ba phương án thực hiện thủ công, và điểm hạn chế của từng phương án.

Những gì bạn cần chuẩn bị trước khi bắt đầu

Bạn cần các hàng dữ liệu ở cấp độ sự kiện, chứ không phải một bản tóm tắt được tổng hợp sẵn. Mỗi hàng tương ứng với một sự kiện, đi kèm với mã định danh người dùng và mốc thời gian.

Bạn cần tên sự kiện thực sự đại diện cho tính năng đó. Việc này hiếm khi đơn giản như lý thuyết, bởi hầu hết các tính năng đều kích hoạt nhiều sự kiện khác nhau. Con số về mức độ chấp nhận tính năng chỉ thực sự chuẩn xác khi việc ánh xạ này được thực hiện tốt.

Bạn cũng cần biết ai là người có thể sử dụng tính năng đó. Nếu tính năng này chỉ được triển khai thử nghiệm (feature flag) cho một nhóm nhỏ tài khoản, thì tất cả những người còn lại không được tính vào mẫu số.

Một bước kiểm tra nhanh ban đầu sẽ giúp bạn tiết kiệm hàng giờ đồng hồ sau đó. Hãy đếm số lượng người dùng duy nhất trong tệp xuất dữ liệu và so sánh với số lượng người dùng hoạt động thực tế mà bạn đã biết. Nếu hai con số này chênh lệch lớn, tệp xuất dữ liệu có thể đã bị lọc theo một cách nào đó mà bạn chưa nhận ra.

Ba quyết định làm thay đổi con số

Mẫu số. Toàn bộ người dùng đã đăng ký, người dùng hoạt động hàng tháng, hay chỉ những người dùng đủ điều kiện sử dụng tính năng. Những lựa chọn này sẽ tạo ra ba tỷ lệ phần trăm khác nhau từ cùng một tập hợp sự kiện. Mọi chỉ số chấp nhận tính năng đều là một phân số, vì vậy hãy xác định rõ cả tử số và mẫu số trước khi bạn thực hiện bất kỳ phép tính nào.

"Đủ điều kiện" thường là lựa chọn khách quan nhất cho một tính năng mới ra mắt. "Toàn bộ người dùng đã đăng ký" là con số mang lại kết quả thấp nhất nhưng lại dễ bảo vệ nhất dưới góc độ thận trọng.

Thế nào là "đã sử dụng". Kích hoạt sự kiện một lần, hai lần, hay kích hoạt trong hai phiên truy cập riêng biệt. Một lượt nhấp chuột duy nhất trong quá trình hướng dẫn sử dụng không được coi là đã chấp nhận tính năng, và hầu hết các đội ngũ đều phải rút ra bài học này một cách xương máu.

Hãy chọn một ngưỡng cụ thể và ghi rõ vào báo cáo. Sử dụng hai lần vào hai ngày khác nhau là một quy tắc phổ biến và dễ thuyết phục.

Khung thời gian. Mức độ chấp nhận không phải là một thời điểm tức thời. Đó là tỷ lệ người dùng đủ điều kiện thực hiện hành động đó trong một khoảng thời gian, vì vậy khoảng thời gian này là một phần bắt buộc của định nghĩa.

Dưới đây là một chi tiết tinh tế đã được ghi chép lại mà bạn nên biết trước khi áp dụng phương pháp của một công cụ nào đó. Tài liệu về tỷ lệ giữ chân của Amplitude giải thích cách thức tính toán của họ. Công cụ này "tính toán dữ liệu giữ chân bằng cách so sánh ngày diễn ra sự kiện bắt đầu với ngày diễn ra sự kiện quay lại mà bạn đã chỉ định."

Khoảng thời gian chỉ áp dụng cho sự kiện đầu tiên. Amplitude nêu rõ rằng "người dùng không nhất thiết phải kích hoạt sự kiện quay lại trong khoảng thời gian đó để xuất hiện trong phân tích."

Đó là một cách xử lý hợp lý nhưng lại khiến nhiều người ngạc nhiên. Một bảng tính lọc cả hai sự kiện trong cùng một khung thời gian sẽ không cho ra kết quả khớp với công cụ này, và thực tế là không có bên nào sai cả.

Cách thực hiện thủ công

Tùy chọn 1: Đếm số lượng người dùng duy nhất, sau đó chia tỷ lệ

Hãy bắt đầu bằng việc loại bỏ trùng lặp, vì số lượng sự kiện thô không đại diện cho số người dùng thực tế. Hãy trích xuất danh sách người dùng duy nhất bằng hàm UNIQUE.

Sau đó, đếm xem có bao nhiêu người dùng trong số đó đã kích hoạt sự kiện của tính năng, bằng cách sử dụng hàm COUNTIFS với tên sự kiện và giới hạn ngày. Chia con số này cho số lượng người dùng đủ điều kiện của bạn.

Hãy để hai kết quả đếm này ở các ô hiển thị rõ ràng thay vì lồng chúng vào cùng một công thức. Chắc chắn sẽ có ai đó hỏi mẫu số là gì, và bạn sẽ muốn chỉ ngay vào con số đó.

Hạn chế lớn nhất là phương pháp này chỉ cho bạn một con số chung chung mà không có thông tin chi tiết. Bạn biết 18% đã chấp nhận tính năng nhưng không hề biết họ là ai.

Tùy chọn 2: Xây dựng bảng gắn thẻ ở cấp độ người dùng

Mỗi hàng tương ứng với một người dùng đủ điều kiện, mỗi cột trả lời cho một câu hỏi: Họ có kích hoạt sự kiện không, bao nhiêu lần, và vào bao nhiêu ngày khác nhau.

Giờ đây bạn có thể phân mảnh dữ liệu. Tỷ lệ chấp nhận theo gói dịch vụ, theo nhóm đăng ký (cohort), theo quy mô tài khoản, hoặc theo việc họ đã hoàn thành quy trình làm quen (onboarding) hay chưa.

Đây là lúc chỉ số chấp nhận tính năng chuyển từ dạng báo cáo thông thường sang dạng có thể đưa ra hành động thực tế. Con số trung bình 18% đã che giấu sự thật rằng tỷ lệ ở người dùng mới là 40% còn người dùng từ năm ngoái chỉ là 4%.

Khoảng cách đó chính là phát hiện quan trọng. Hướng dẫn của chúng tôi về phân tích cohort giải thích lý do tại sao con số trung bình lại thay đổi mỗi khi lượng đăng ký biến động, ngay cả khi hành vi của người dùng không hề thay đổi.

Giới hạn ở đây là dung lượng dữ liệu và các liên kết bảng (joins). Một tệp xuất dữ liệu hàng triệu dòng cộng với một bảng tài khoản sẽ vượt quá giới hạn xử lý mượt mà của các công thức thông thường.

Tùy chọn 3: Duy trì một tab định nghĩa bên cạnh các con số

Hãy ghi lại tên sự kiện, ngưỡng kích hoạt, khung thời gian, mẫu số và những ai đủ điều kiện.

Đây là điều giúp báo cáo có thể so sánh được vào tháng tới. Nhưng đây cũng là tab thường bị bỏ qua nhất khi ai đó cần con số gấp trong vòng mười phút.

Hạn chế là việc ghi chép lại định nghĩa không đồng nghĩa với việc áp dụng nó một cách tự động. Ai đó vẫn sẽ phải thiết lập lại năm bộ lọc tương tự trong mỗi chu kỳ báo cáo.

Hạn chế chung. Cả ba phương án đều giả định rằng tên các sự kiện đã được chuẩn hóa sạch sẽ. Khi cùng một hành động được kích hoạt dưới ba cái tên khác nhau sau một đợt tái cấu trúc mã nguồn (refactor), công việc thực sự lại là đối chiếu và hợp nhất chúng trước khi bắt đầu bất kỳ phép tính nào.

Những điểm khiến phương pháp thủ công bị trì trệ

Báo cáo đầu tiên chỉ mất một buổi sáng. Nhưng đến báo cáo thứ tư sẽ mất nhiều thời gian hơn, bởi vì khi đó định nghĩa ban đầu đã âm thầm bị thay đổi.

Tên sự kiện thay đổi khi sản phẩm thay đổi. Việc đổi tên trong mã nguồn sẽ tạo ra một cú sụt giảm thẳng đứng trên biểu đồ của bạn, trông không khác gì việc người dùng đang từ bỏ tính năng đó. Đó là lý do tại sao một biểu đồ chấp nhận tính năng cuối cùng lại phản ánh một sự thay đổi về mã nguồn thay vì quyết định của khách hàng.

Những thay đổi trong quá trình triển khai (rollout) sẽ làm sai lệch mẫu số. Khi tính năng tiếp cận 100% số tài khoản, tỷ lệ chấp nhận có vẻ như bị sụt giảm, chỉ vì số lượng người dùng đủ điều kiện đã tăng lên gấp ba lần.

Ngoài ra còn có một lỗi đếm dữ liệu tồn tại lâu nhất. Việc cộng dồn số lượng sự kiện thay vì đếm số lượng người dùng duy nhất sẽ thổi phồng tỷ lệ chấp nhận mỗi khi có một nhóm nhỏ người dùng tích cực (power users) liên tục sử dụng tính năng đó.

Còn một trở ngại nữa chỉ xuất hiện khi sát thời hạn báo cáo. Khi ai đó hỏi "con số đó có tốt không?", một tỷ lệ phần trăm đơn lẻ không thể trả lời được, và việc xây dựng một báo cáo so sánh đối chiếu lại trở thành một dự án thứ hai.

Cách xây dựng báo cáo với Powerdrill Bloom

Bước 1: Tải lên tệp xuất dữ liệu sử dụng của bạn

Tải lên tệp xuất sự kiện, hoặc cả tệp sự kiện và tệp tài khoản cùng lúc. Powerdrill Bloom sẽ phân tích cấu trúc các cột ngay khi tải lên, giúp phát hiện các tên sự kiện không nhất quán và ID người dùng bị thiếu trước khi bất kỳ tỷ lệ phần trăm nào được tính toán.

Bước 2: Mô tả định nghĩa bằng ngôn ngữ tự nhiên

Hãy nêu ra các quy tắc thay vì tự mình thiết lập chúng. Xác định tên sự kiện, ngưỡng kích hoạt, khung thời gian và những người dùng nào đủ điều kiện.

Sau đó, hãy đặt những câu hỏi giúp phát hiện các bẫy dữ liệu. Hỏi xem có tên sự kiện nào trông giống như bị trùng lặp gần hết hay không. Hỏi xem có bao nhiêu người dùng duy nhất đã kích hoạt sự kiện so với tổng số sự kiện được kích hoạt, và tỷ lệ chấp nhận tính năng khác nhau như thế nào theo từng tháng đăng ký.

Bước 3: Xuất biểu đồ, báo cáo hoặc slide trình bày

Trích xuất xu hướng chấp nhận tính năng, bảng phân tích theo phân khúc, hoặc một slide chứa cả con số thực tế lẫn định nghĩa đi kèm.

Tại sao cách này vượt trội hơn việc xây dựng lại báo cáo trong mỗi chu kỳ

	Phương pháp thủ công	Powerdrill Bloom
Loại bỏ trùng lặp người dùng từ các sự kiện	Tạo các cột phụ trợ trong mỗi tệp	Yêu cầu đếm số lượng người dùng duy nhất
Phân tách theo cohort hoặc gói dịch vụ	Liên kết bảng và xây dựng lại bảng dữ liệu	Yêu cầu phân tích chi tiết
Sự kiện bị đổi tên sau khi phát hành phiên bản mới	Chỉ phát hiện ra trên biểu đồ sau đó	Được cảnh báo ngay khi tải lên
Thay đổi nhóm đối tượng đủ điều kiện	Tính toán lại mẫu số	Nêu quy tắc mới

Hàng thứ ba chính là nơi quyết định độ chính xác của báo cáo. Một sự kiện bị đổi tên và một sự sụt giảm thực tế trông hoàn toàn giống nhau trên biểu đồ đường, và chỉ một trong hai trường hợp đó mới cần đến sự can thiệp từ phía sản phẩm.

Các sai lầm thường gặp

Đếm số lượng sự kiện thay vì số lượng người dùng. Mười nghìn sự kiện từ hai trăm người không phải là mức độ chấp nhận tính năng. Hãy luôn loại bỏ trùng lặp trước tiên.

Sử dụng toàn bộ người dùng đã đăng ký làm mẫu số cho một tính năng đang thử nghiệm giới hạn. Nếu chỉ có một phần ba số tài khoản có thể nhìn thấy tính năng đó, thì hai phần ba còn lại không phải là những người không chấp nhận tính năng. Họ đơn giản là không đủ điều kiện.

Coi một lượt nhấp chuột duy nhất là đã chấp nhận tính năng. Một sự kiện đơn lẻ trong quá trình làm quen chỉ là sự tiếp cận ban đầu. Hãy yêu cầu việc sử dụng lặp lại vào các ngày khác nhau nếu bạn muốn con số đó thực sự có ý nghĩa.

So sánh tỷ lệ trung bình gộp chung qua các tháng. Người dùng mới và người dùng hiện tại có tỷ lệ chấp nhận khác nhau, vì vậy sự thay đổi trong cơ cấu người dùng sẽ tự động làm dịch chuyển con số này. Hãy phân tách theo cohort trước khi đưa ra kết luận.

Bỏ qua việc đổi tên sự kiện. Một đợt tái cấu trúc mã nguồn có thể tạo ra một cú sụt giảm trông giống như việc người dùng rời bỏ dịch vụ (churn). Hãy kiểm tra từ điển sự kiện trước khi bạn đi sâu vào nghiên cứu hành vi của người dùng.

Sao chép khung thời gian của một công cụ mà không tìm hiểu cách hoạt động của nó. Các khung thời gian giữ chân được ghi chép trong tài liệu thường chỉ áp dụng bộ lọc ngày cho sự kiện đầu tiên, vì vậy một bảng tính lọc cả hai sự kiện sẽ cho ra kết quả không khớp.

Báo cáo tỷ lệ phần trăm mà không đính kèm định nghĩa. Con số sẽ trở nên vô nghĩa nếu thiếu mẫu số và ngưỡng kích hoạt. Hãy đưa cả hai yếu tố này lên biểu đồ, giống như cách một bảng điều khiển KPI chất lượng dán nhãn cho các chỉ số của mình.

Kết luận

Xác định nhóm đối tượng đủ điều kiện, thiết lập ngưỡng sử dụng, cố định khung thời gian và loại bỏ trùng lặp người dùng trước khi thực hiện phép chia. Bốn bước này sẽ biến tỷ lệ phần trăm chấp nhận tính năng thành một chỉ số có giá trị thực tiễn mà đội ngũ sản phẩm có thể hành động dựa vào đó.

Điều khiến việc này trở nên tốn kém là định nghĩa phải duy trì được tính nhất quán trước những thay đổi của sản phẩm. Việc đổi tên sự kiện và mở rộng phạm vi triển khai đều làm thay đổi con số mà không cần ai tác động vào báo cáo.

Nếu đó là những gì chu kỳ báo cáo của bạn đang gặp phải, hãy dùng thử Powerdrill Bloom với tệp xuất dữ liệu sử dụng của bạn. Ngoài ra, hãy tham khảo hướng dẫn của chúng tôi về cách xây dựng biểu đồ giữ chân cohort, danh sách tổng hợp các công cụ AI cho phân tích sản phẩm, và trang trợ lý CSV AI.

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

Chấp nhận tính năng (feature adoption) là gì?

Đó là tỷ lệ người dùng đủ điều kiện đã sử dụng một tính năng trong một khung thời gian xác định, được đo lường bằng số lượng người dùng duy nhất chứ không phải số lượng sự kiện. Định nghĩa này chỉ có giá trị nếu mẫu số và ngưỡng sử dụng được nêu rõ.

Làm thế nào để tính toán chỉ số này từ tệp xuất sự kiện?

Hãy đếm số lượng người dùng duy nhất đã kích hoạt sự kiện của tính năng trong khung thời gian của bạn, sau đó chia cho số lượng người dùng đủ điều kiện. Hãy loại bỏ trùng lặp trước tiên, vì một người dùng có thể tạo ra hàng trăm sự kiện.

Mẫu số nên là toàn bộ người dùng hay người dùng hoạt động?

Hãy sử dụng nhóm đối tượng đủ điều kiện, tức là những người dùng thực sự có thể tiếp cận tính năng đó. Việc sử dụng toàn bộ người dùng đã đăng ký sẽ tạo ra một con số quá thận trọng và phản ánh thấp hơn thực tế mức độ chấp nhận đối với một tính năng đang được thử nghiệm giới hạn.

Khung thời gian đo lường nên kéo dài bao lâu?

Đủ dài cho một chu kỳ sử dụng thông thường, ví dụ như hàng tuần đối với các sản phẩm sử dụng hàng ngày và hàng tháng đối với các sản phẩm sử dụng định kỳ. Hãy giữ cố định khung thời gian này giữa các báo cáo, vì việc thay đổi nó sẽ làm thay đổi con số kết quả.

Tại sao con số của tôi lại khác với công cụ phân tích?

Thường là do khung thời gian hoặc quy tắc loại bỏ trùng lặp. Các phép tính tỷ lệ giữ chân được ghi chép trong tài liệu thường chỉ áp dụng bộ lọc ngày cho sự kiện đầu tiên, điều mà một bảng tính được thiết lập bộ lọc cho cả hai sự kiện sẽ không thể tái tạo chính xác được.