Hôm trước đi dạy, tôi với Phú cuối giờ ngồi vỉa hè với nhau đến 11h30 đêm chỉ để nói câu chuyện làm sao để giúp em từng bước đưa tư duy event tracking bài bản vào phát triển ứng dụng VPBank Neo. Nói rát hết miệng!

Tháng 5 năm ngoái mẻ Thảo Chu cố lết đến lớp lúc bị công ty dí vì đến học phần "Measuring User Behavior" và "Product Analytic", con vợ Việt Anh cũm thế.

Lâu nữa thì ngồi với Cường - AI Lead @ TheCoach để review bộ event tracking cho sản phẩm mới của TheCoach đến 5h sáng...

Nhìu ca như thế lốm, nói chung các vợ iu luôn đánh giá product metrics & user behavior giúp họ loại bỏ bớt sự cảm tính khi phân tích & nhìn nhận hiệu quả công việc khách quan hơn.

Nhiều công ty hiện nay đã bắt đầu đưa Analytical Thinking thành một tiêu chí bắt buộc khi tuyển dụng Product Designer, User Researcher. Cuối 2025 UXCamp may mắn được lựa chọn là đơn vị cung cấp bộ đề tuyển dụng đầu vào cho một số công ty như thế.

Chi tiết tiêu chí Analytical Thinking được yêu cầu khi apply vào PvcomBank, Viettel Post, CharterTech và ABBank.

Vậy mà trong bài test đầu vào người tham dự - Product Analytic lại là điểm thấp nhất:

Trong Product Analytic chúng tôi test: Descriptive & Inferential Statistics, Hypothesis Testing, Break Down Metric, Active Use, CR, Retention, LTV, Define Event & Properties for Event Tracking, Calculation & Drawing Conclusion. Bài test không hề có các câu hỏi về công cụ như SQL, PowerBI hay các tool event tracking phổ biến. Chỉ thuần tư duy, hiểu biết về các chỉ số cơ bản, tính toán & nhận định.

Bài test mới được đưa vào bootcamp nhưng nhìn tình hình điểm số như này thì cũng quan ngại lắm!

I. Nguyên nhân điểm thấp?

2 nguyên nhân chính chúng tôi nhìn thấy trong khuôn khổ nghiên cứu người tham dự:

1. Công việc hiện tại đang không liên quan đến số.
2. Sản phẩm đặc thù và công ty chưa tập trung vào phân tích hiệu quả sản phẩm

1. Công việc hong liên quan.

Trước tiên phải nói tới scope of work và hiệu quả công việc của nhiều người không liên quan tới product metrics. Công việc không động vào thì không biết là dễ hiểu.

Doanh thu, lợi nhuận, tốc độ tăng trưởng, tỷ lệ chuyển đổi, tỷ lệ khách hàng quay lại, họ dùng cái gì nhiều, đến mức chi tiết hơn là thông tin cá nhân từng khách hàng... đều là những chỉ số cực kỳ nhạy cảm. Không phải ai muốn động vào cũng được! Nhiều analyst khi mới bước chân vào nghề cũng trầy trật đi xin dataset chuẩn để học phân tích.

Có đợt UXCamp khảo sát người tham dự, chỉ khoảng 10% là có làm số thường xuyên (Hàng tuần, hàng tháng). Gần 3/4 còn lại là không biết hoặc chưa từng làm! PM/PO làm mấy cái này thường xuyên hơn PD, nhưng cũng không ăn thua lắm.

Chúng tôi tò mò tỷ lệ này trên quy mô thị trường trông như nào?.

Nhiều bạn PD trả lời "performance của bạn không được đánh giá bằng product metrics" trong form đăng ký bootcamp.

2. Sản phẩm đặc thù và công ty chưa tập trung vào phân tích hiệu quả sản phẩm

Trò chuyện trên lớp, rất nhiều người muốn được tiếp cận, làm và hiểu về số liệu nhưng join vào công ty không có chủ trương ấy. Interview một số PM, nguyên nhân ở công ty không phân tích chỉ số vì công ty tăng trưởng nóng, ưu tiên phát triển tính năng mới nên chưa cần đến phân tích số liệu. Đến giai đoạn growth hoặc tối ưu mới cần phân tích.

Thu Hà - PM 5 YoE làm product chia sẻ:

"Công ty không có mindset làm data lắm, gần đây đã có mindset rồi nhưng action thì chưa ok. Cty ko có DA, có nhiều việc quan trọng hơn nên gần đây mới bắt đầu học."

Một số môi trường product ưu tiên phát triển kinh doanh, nên các báo cáo cũng xoay quanh những chỉ số này nhiều, ít các indicators thể hiện cho sản phẩm.

Một bạn chia sẻ công ty bạn làm gần đây mới bắt đầu đặt metric để đo lường hành vi người dùng.

Chi tiết về những thực trạng này, mời các vợ iu đọc bài "Công nhân nhà máy số".

Thực trạng là thế, vậy nếu tôi vẫn muốn nâng cấp analytical thinking thì sẽ phải làm gì?

II. Vấn đề & cách khắc phục

UXCamp sẽ tổng hợp các vấn đề phổ biến & cách khắc phục theo 6 bước phân tích số liệu sản phẩm nhé.

1. Xác định dữ liệu cần thu thập
2. Xác định phương pháp thu thập & công cụ thu thập
3. Thu thập dữ liệu
4. Phân tích
5. Trình bày
6. Kết luận & đề xuất

Các bước này xin phép không đề cập tới các yếu tố technical liên quan tới xây dựng, tối ưu cơ sở dữ liệu vì out-of-scope nhé các vợ iu.

1. Xác định dữ liệu cần thu thập

Nhìn chung việc xác indicator để đánh giá hiệu quả một feature không khó nhưng khi xác định những dữ liệu đi kèm để hỗ trợ cho việc đào sâu phân tích thì các vợ iu thường ú ớ.

Lưu ý:

• Xác định các dữ liệu cần thu thập ảnh hưởng nhiều bởi đặc thù sản phẩm và cách làm việc ở mỗi công ty.
• Một số hệ thống phát triển không tính tới việc phân tích, không có log cho mỗi lần cập nhật dữ liệu và thay đổi thuật toán khiến cho quá trình phân tích sâu hơn vào dữ liệu gặp nhiều khó khăn.
• Đối với những hệ thống không được thiết kế để lưu log, việc lưu log này sẽ được đẩy sang 3rd party thay vì thay đổi lại cấu trúc cơ sở dữ liệu của hệ thống.

Ví dụ 1: Hệ thống không ghi lại từng thời điểm dữ liệu được thay đổi mà chỉ lưu lần cuối cùng thôi. -> Khi này việc phân tích ảnh hưởng của từng lần thay đổi dữ liệu không thực hiện được vì không biết từ trước đến nay có bao nhiêu lần thay đổi, thay đổi gì, từ bao giờ và trong bao lâu.

Ví dụ 2: Hệ thống không phân loại người dùng theo từng cohort trong quá trình onboarding. Khi cần phân tích: "Cohorts nào chúng ta đang phục vụ tốt nhất" thì không làm được

...

2. Xác định phương pháp thu thập & công cụ thu thập

Vấn đề

1. Khó khăn khi xác định phương pháp thu thập dữ liệu. Thu thập trong hay ngoài hệ thống? Trong thì là trên hệ thống nào? Ngoài thì bằng cách nào?
2. Lựa chọn sai phương pháp thu thập dữ liệu đối với từng mục tiêu cụ thể.
3. Lựa chọn sai công cụ thu thập dữ liệu, ảnh hưởng tới performance của hệ thống và khả năng scale trong thời gian dài.

Lưu ý:

1. Database: Mỗi cách thiết kế cơ sở dữ liệu khác nhau sẽ ảnh hưởng tới dữ liệu có thể thu thập. Cần hiểu rõ CSDL gồm những bảng nào và mối quan hệ giữa các bảng đó.
2. Tools & Limitation: Mỗi công cụ thu thập dữ liệu đều có giới hạn của riêng mình. Khi đối mặt với các công cụ khác nhau, chúng ta thường không biết đâu là công cụ phù hợp nhất với bối cảnh doanh nghiệp. Việc xác định công cụ sử dụng ảnh hưởng đến việc thu thập dữ liệu. Những giới hạn thường thấy của các công cụ đo lường:

• Số lượng datapoint có thể thu thập / tháng
• Số monthly active user của hệ thống
• Độ dài tên data point
• Số lượng parameter
• Số lượng báo cáo được tạo...

3. Thu thập

Vấn đề:

1. Không biết dữ liệu cần phân tích được thu thập bằng cách nào?
2. Cần những dữ liệu nào? Loại dữ liệu là gì?
3. Chuẩn hóa tên gọi
4. Thiếu linh hoạt theo mỗi công cụ.

Quy trình thu thập sẽ quyết định:

a. Có đủ dữ liệu để phân tích không?

Nếu thiếu dữ liệu thì không thể phân tích hoặc việc phân tích phải thực hiện dựa trên các dữ kiện gián tiếp. Đã là gián tiếp thì tính chính xác sẽ không thể cao bằng trực tiếp.

b. Có phân tích đúng không?

Mỗi data-point là một ánh xạ thực tế, data-point mang ý nghĩa sai thì phân tích cũng sai.

Một ví dụ trong bootcamp về tầm quan trọng của việc làm rõ dữ liệu cần được thu thập khi nào.

c. Quy trình phân tích có nhanh chóng không?

Nếu các dữ liệu được thu thập chi tiết, đúng cách và đúng thời điểm thì quy trình phân tích sẽ rất hiệu quả. (Không cần join nhiều bảng, lọc nhiều trường hoặc thực hiện phép selection, projection nhiều...)

d. Có dễ maintain không?

Khi lượng data-point và báo cáo ngày một nhiều, phải maintain liên tục cũng trở thành một gánh nặng. Đặc biệt là trong những giai đoạn sản phẩm có thay đổi lớn (Revamp lại luồng, thay đổi lại UI, entry point...) thì việc tìm - cập nhật lại các báo cáo hiện có trên hệ thống rất mất thời gian. Việc thu thập dữ liệu trong thời gian đầu của sản phẩm cũng sẽ có những đặc điểm khác với những giai đoạn sau. Các con vợ để ý nhó!

Lưu ý:

• Xác định dữ liệu thu thập từ nguồn nào? trên tập đối tượng nào?
• Xác định dữ liệu cần thu thập là gì?
• Thu thập dữ liệu tại thời điểm nào?
• Đặt tên dữ liệu cần thu thập
• Loại dữ liệu cần thu thập.

Data requirement thực tế của Meezy.vn được thực hiện tại bootcamp Trong Gió.

Giai đoạn này bạn cần tìm hiểu:

• Cấu trúc của tracking requirement: Hiểu cấu trúc của một tài liệu yêu cầu gồm những gì?.
• Prioritizing data: Ưu tiên những data-point cần phải được thu thập trước.
• Data type: Loại dữ liệu của từng data-point là gì?
• Naming convention: Chuẩn hóa tên gọi.
• Trigger: Condition & Action để data-point được ghi nhận trên hệ thống.
• Event & Event properties: Các đặc điểm mô tả chi tiết cho một data-point. Từ đây sẽ giúp chúng ta phân tích trơn tru hơn ở bước sau.

Lưu ý 1: Nhiều hệ thống phức tạp, một user journey có thể lên tới cả trăm event cần xác định. Khi đó việc xác định data point cần nhất quán.

Lưu ý 2: Trường hợp một sản phẩm có rất nhiều team cùng phát triển, mỗi team đảm nhận một tính năng core bên trong và không đụng chạm vào nhau. Khi ấy việc đặt tên event cần thể hiện rõ scope tính năng mình đang tracking để tránh ảnh hưởng đến các team khác.

4. Phân tích

Vấn đề:

• Ngụy thống kê: Số nói một đằng, kết luận 1 kiểu. Số trên bề mặt một nghĩa, đào sâu lại một nghĩa khác.
• Thiếu kỹ năng phân tích số liệu trên tracking tools: Nhiều công ty chấp nhận dùng tool có UX tệ vì nó free, thao tác khù khoằm vô cùng.
• Chưa có điều kiện để làm các phân tích chuyên sâu: Đa số các bạn khi được phỏng vấn chia sẻ trên công ty chủ yếu các bạn phân tích số tổng, chưa pivot nó theo nhiều chiều hoặc nhìn chi tiết dữ liệu của từng nhóm người dùng.
• Quá nhiều số liệu không biết lấy cái nào?

Một chỉ số trên sản phẩm có rất nhiều ý nghĩa. Mỗi góc nhìn lại nói ra một ý nghĩa khác. Vẫn là chỉ số đó nhưng truyền vào đối số khác sẽ trả về kết quả khác, rất linh hoạt. Kể mọi người nghe câu chuyện này:

Tôi từng nhận được một báo cáo: "Những tính năng mang lại conversion rate mua premium cao nhất".

Cách tiếp cận vấn đề của phân tích này rất thông minh, nhưng phân tích không trả lời được câu hỏi then chốt: "Mua premium bao lâu sau khi dùng tính năng sẽ được tính vào CR?".

Một ví dụ thực tế trong bootcamp về mối tương quan giữa tỷ lệ hoàn thành và thời gian hoàn thành trong phân tích conversion rate

Lưu ý khi phân tích cần nằm rõ:

• Mục đích của phân tích?
• Cách thu thập dữ liệu & ý nghĩa của các data point mình đang có?
• Trước khi đưa kết luận vào báo cáo và trình bày, hãy đảm bảo số liệu được ghi nhận đúng và tính toán đúng.
• Quy trình phân tích không cẩn thận sẽ mắc phải Statistical Error / Fallacy. Toang!

Các lỗi thường gặp trong Product Analytic nói riêng và Statistical Error / Fallacy nói chung trong bootcamp.

5. Trình bày

Vấn đề

1. Nhiều báo cáo sản phẩm có nguyên bảng số liệu gốc mà không thể hiện sự ưu tiên, không thiết kế trình bày, không tổng hợp. Hãy tưởng tượng sếp bạn một ngày đối mặt với 20 cái báo cáo, và báo cáo nào cũng có format như thế!. Ôi đừng mà..
2. Lựa chọn sai hình thức trực quan hóa dữ liệu
3. Không có annotation (ghi chú) tại các thời điểm:
1. Thay đổi đặc tính của dữ liệu (phương pháp thu thập, tên dữ liệu, loại dữ liệu, kênh thu thập...)
2. Thời điểm release hoặc bắt đầu / kết thúc các marketing campaign...


Product Dashboard của Trương Thu Hương (PO @ Bộ Công An) xây dựng trong bootcamp

Lưu ý:

• Mỗi đồ thị có một ý nghĩa và mục đích sử dụng khác nhau. Hãy lựa chọn đúng.
• Mỗi số liệu trong một báo cáo đều có mức độ ưu tiên khác nhau. Hãy trình bày đúng, từ đó hỗ trợ tốt cho cả việc scan thông tin lẫn xem chi tiết.
• Mỗi một báo cáo không chỉ dừng lại ở số đang có, mà cần đi kèm một số lưu ý cho người đọc để họ nắm insight đúng hơn và hiểu về dữ liệu đang được trình bày hơn. Annotation đóng vai trò rất quan trọng trong chuyện này. Đừng bỏ qua.

6. Kết luận, đề xuất cải tiến

Vấn đề:

• Không biết sản phẩm đầu ra có hiệu quả không? Trên tiêu chí gì?
• Thiếu khách quan khi nhận định, ra quyết định & đặt mục tiêu.
• Phân tích rất nhiều số, nhưng không ra được kết luận gì cho sản phẩm.
• Không thể lý giải được tại sao chỉ số lại như thế?.

Một Head of Data tham gia bootcamp từng chia sẻ với tôi: "Em nắm rất nhiều số của doanh nghiệp, nhưng đọc số xong thì không biết next step cho sản phẩm sẽ là gì". Bối cảnh là bạn chuyển dịch dần từ vị trí Head of Data sang Head of PnL.

Bạn hỏi đúng đó, số thì nhiều nhưng chỉ dựa vào nó để quyết định cho product là chưa đủ. Các yếu tố trong Decision Making cần thêm tư duy sản phẩm, các dữ kiện định tính, rủi ro, nguồn lực và ... kinh nghiệm quyết định khi chưa đủ dữ kiện: đợi đủ số mới quyết định đôi khi là quá muộn.

Nhiều người thì lại thế này: Phân tích số xong thì sẽ dựa vào trực giác để đưa ra giả thuyết: Từ giả thuyết vấn đề đến giả thuyết giải pháp. Sau đó cải tiến thử và lại tiếp tục vòng lặp ấy. Cách làm này không sai, nhưng:

• 2 tầng giả thuyết (Giả thuyết vấn đề → giả thuyết giải pháp) sẽ dẫn đến tính đúng đắn trong kết luận không cao.
• Dễ tranh cãi nội bộ. 9 phương 10 hướng, ai chịu ai?
• Khó scale vì phụ thuộc lớn vào kinh nghiệm làm nghề.
• Tốn chi phí vì để trả lời cho mỗi câu hỏi trong hypothesis là một lần cải tiến, kéo theo hệ lụy chi phí phát triển tăng theo.
• Khó thuyết phục lãnh đạo. Đơn giản là mệnh đề của giả thuyết sẽ luôn bắt đầu bằng “Em nghĩ là...” =)).

UXCamp không phủ nhận cách làm này, nó đúng trong một số điều kiện môi trường và sản phẩm nhất định, nhưng có một cách làm khác bài bản hơn, đó là:

• Sử dụng nghiên cứu giải thích để tìm ra nguyên nhân.
• Kết hợp nhiều phương pháp đánh giá hiệu quả khác nhau theo từng quy mô. Không phải cái gì cũng phải chứng minh trên môi trường production.
• Kết hợp nhiều dữ liệu khác nhau để cùng nói về một vấn đề. Nếu đã có số trên hệ thống thì kết hợp với định tính từ survey / interview, Usability testing hoặc Observation... để hiểu rõ hơn các thực trạng đang có.

Tất nhiên rồi, để làm được những cái này, chúng ta cũng cần phải tuân theo các phương pháp và chuẩn mực nghiên cứu nói chung.

Kết

Analytical Thinking có thể học & luyện tập được. Quan trọng nhất là bạn cần đi đúng hướng ngay từ đầu. Chúc các vợ iu ngày càng sắc bén hơn trong những lập luận và quyết định của mình.

Thén kìuuuu