Luyên thuyên

Corporate Training

Ngụy thống kê: nguyên nhân, ví dụ

Có một bạn ứng viên chia sẻ: bạn cải tiến 1 feature giúp NPS tăng từ âm điểm lên 3 mấy, 4 chục điểm. CHỈ SAU 1 LẦN RELEASE!!

Có lần phỏng vấn 1 Product Designer từng làm Sapo. Bạn sharing có lần cải tiến 1 feature tại Sapo giúp NPS tăng từ âm điểm lên 3 mấy, 4 chục điểm. CHỈ SAU 1 LẦN RELEASE!

"Vãii", trong đầu tôi lúc đấy có 2 kịch bản: "Tuyển ngay" hoặc con vợ này luyên thuyên.


Trong đời tôi chưa từng thấy điểm NPS tăng kinh khủng như thế trong một lần cải tiến, vậy nên tôi sẽ hỏi kỹ hơn. 1 hồi sau bạn chia sẻ feature v1 release cho all users, còn v2 thì chỉ release cho những người dùng v1 tích cực nhất. Thế mà con vợ lại so sánh NPS của all users v1 với NPS của hàng tuyển v2. Phét lác thật!



Việc so sánh điểm NPS của người dùng v2 với v1 trong trường hợp này là bất hợp lý. Nếu so sánh điểm NPS của v2 với điểm của những người đó khi sử dụng V1 (tức power users v1 và v2) thì sẽ hợp lý hơn, nhưng không.


Tình huống trên dính vào sampling bias - một trong những bias phổ biến của ngụy thống kê (statistical fallacy).


Sampling bias

"Drawing a conclusion about a population based on a sample that is biased, or chosen in order to make it appear the population on average is different than it actually is."


---


Statistical fallacy

"A statistical fallacy is an error in statistical reasoning where statistical data is misused, misinterpreted, or presented in a biased way to support a misleading or incorrect conclusion"



Bên trên là một ví dụ rất gần gũi và quen thuộc khi nói về Ngụy thống kê, ngoài ra nguyên nhân của ngụy thống kê còn nhiều cái khác.


Trong survey thì:

  • Chọn loại câu hỏi sai,
  • Đặt câu hỏi mơ hồ không rõ ràng
  • Thiên vị nhóm đối tượng,
  • Phân tích trong khi cấu trúc sample không đầy đủ...



Trong product analytic:


  • Đặt trigger sai,
  • Shọn số sai,
  • Chọn timeframe phân tích sai,
  • Sử dụng điều kiện sai hay diễn giải sai,
  • Trình bày sai thì cũng đều đứt...



Kể cho các con vợ 1 ví dụ khác trong product analytic cho dễ hiểu:


Có một cốp của cốp bank yêu cầu ưu tiên luồng chuyển khoản đến người thụ hưởng vì số liệu chỉ ra số lượng giao dịch chuyển khoản đến người đã lưu cao gấp 10 lần chuyển khoản đến người mới.


Quái lạ, nghe rất chi là phản trực giác. Tại quen biết, tôi xin mở quả dashboard nội bộ lên để select theo 1 chiều khác thì số nó lại ra khác. bảo cốp check lại xem chứ nhìn theo 2 aspects khác nhau mà số khác nhau tức là mâu thuẫn rồi. Cốp mất nửa tiếng ngồi soi. Hóa ra cái để ghi nhận là chuyển đến người thụ hưởng được trigger khi người dùng view màn chứ không phải khi họ chọn người thụ hưởng.



Cái này thì phân tích chẳng có vấn đề gì, lỗi tại ông đánh máy.


Để các bảnh khi phỏng vấn ứng viên hay đơn giản là phản biện nhau trong công việc thì nhớ hỏi kỹ:

  • Số được lấy bằng phương pháp gì?
  • Lấy từ tập người nào? Tiêu chí lấy là gì? Cấu trúc?
  • Thu thập trong bao lâu? Phương pháp thu thập?
  • Số liệu là gì? Phản ánh điều gì?
  • Sâu hơn thì hỏi các bước từ lấy số đến phân tích.


Chỉ cần 1 bước trong này hẹo thôi là đã có cơ sở reject kết luận cuối cùng dòiii.

Chúc các con vợ có số có má, chứ đừng "Số? Má!!!" nhé.

Luyên thuyên

Corporate Training

Ngụy thống kê: nguyên nhân, ví dụ

Có một bạn ứng viên chia sẻ: bạn cải tiến 1 feature giúp NPS tăng từ âm điểm lên 3 mấy, 4 chục điểm. CHỈ SAU 1 LẦN RELEASE!!

Có lần phỏng vấn 1 Product Designer từng làm Sapo. Bạn sharing có lần cải tiến 1 feature tại Sapo giúp NPS tăng từ âm điểm lên 3 mấy, 4 chục điểm. CHỈ SAU 1 LẦN RELEASE!

"Vãii", trong đầu tôi lúc đấy có 2 kịch bản: "Tuyển ngay" hoặc con vợ này luyên thuyên.


Trong đời tôi chưa từng thấy điểm NPS tăng kinh khủng như thế trong một lần cải tiến, vậy nên tôi sẽ hỏi kỹ hơn. 1 hồi sau bạn chia sẻ feature v1 release cho all users, còn v2 thì chỉ release cho những người dùng v1 tích cực nhất. Thế mà con vợ lại so sánh NPS của all users v1 với NPS của hàng tuyển v2. Phét lác thật!



Việc so sánh điểm NPS của người dùng v2 với v1 trong trường hợp này là bất hợp lý. Nếu so sánh điểm NPS của v2 với điểm của những người đó khi sử dụng V1 (tức power users v1 và v2) thì sẽ hợp lý hơn, nhưng không.


Tình huống trên dính vào sampling bias - một trong những bias phổ biến của ngụy thống kê (statistical fallacy).


Sampling bias

"Drawing a conclusion about a population based on a sample that is biased, or chosen in order to make it appear the population on average is different than it actually is."


---


Statistical fallacy

"A statistical fallacy is an error in statistical reasoning where statistical data is misused, misinterpreted, or presented in a biased way to support a misleading or incorrect conclusion"



Bên trên là một ví dụ rất gần gũi và quen thuộc khi nói về Ngụy thống kê, ngoài ra nguyên nhân của ngụy thống kê còn nhiều cái khác.


Trong survey thì:

  • Chọn loại câu hỏi sai,
  • Đặt câu hỏi mơ hồ không rõ ràng
  • Thiên vị nhóm đối tượng,
  • Phân tích trong khi cấu trúc sample không đầy đủ...



Trong product analytic:


  • Đặt trigger sai,
  • Shọn số sai,
  • Chọn timeframe phân tích sai,
  • Sử dụng điều kiện sai hay diễn giải sai,
  • Trình bày sai thì cũng đều đứt...



Kể cho các con vợ 1 ví dụ khác trong product analytic cho dễ hiểu:


Có một cốp của cốp bank yêu cầu ưu tiên luồng chuyển khoản đến người thụ hưởng vì số liệu chỉ ra số lượng giao dịch chuyển khoản đến người đã lưu cao gấp 10 lần chuyển khoản đến người mới.


Quái lạ, nghe rất chi là phản trực giác. Tại quen biết, tôi xin mở quả dashboard nội bộ lên để select theo 1 chiều khác thì số nó lại ra khác. bảo cốp check lại xem chứ nhìn theo 2 aspects khác nhau mà số khác nhau tức là mâu thuẫn rồi. Cốp mất nửa tiếng ngồi soi. Hóa ra cái để ghi nhận là chuyển đến người thụ hưởng được trigger khi người dùng view màn chứ không phải khi họ chọn người thụ hưởng.



Cái này thì phân tích chẳng có vấn đề gì, lỗi tại ông đánh máy.


Để các bảnh khi phỏng vấn ứng viên hay đơn giản là phản biện nhau trong công việc thì nhớ hỏi kỹ:

  • Số được lấy bằng phương pháp gì?
  • Lấy từ tập người nào? Tiêu chí lấy là gì? Cấu trúc?
  • Thu thập trong bao lâu? Phương pháp thu thập?
  • Số liệu là gì? Phản ánh điều gì?
  • Sâu hơn thì hỏi các bước từ lấy số đến phân tích.


Chỉ cần 1 bước trong này hẹo thôi là đã có cơ sở reject kết luận cuối cùng dòiii.

Chúc các con vợ có số có má, chứ đừng "Số? Má!!!" nhé.

Luyên thuyên

Corporate Training

Ngụy thống kê: nguyên nhân, ví dụ

Có một bạn ứng viên chia sẻ: bạn cải tiến 1 feature giúp NPS tăng từ âm điểm lên 3 mấy, 4 chục điểm. CHỈ SAU 1 LẦN RELEASE!!

Có lần phỏng vấn 1 Product Designer từng làm Sapo. Bạn sharing có lần cải tiến 1 feature tại Sapo giúp NPS tăng từ âm điểm lên 3 mấy, 4 chục điểm. CHỈ SAU 1 LẦN RELEASE!

"Vãii", trong đầu tôi lúc đấy có 2 kịch bản: "Tuyển ngay" hoặc con vợ này luyên thuyên.


Trong đời tôi chưa từng thấy điểm NPS tăng kinh khủng như thế trong một lần cải tiến, vậy nên tôi sẽ hỏi kỹ hơn. 1 hồi sau bạn chia sẻ feature v1 release cho all users, còn v2 thì chỉ release cho những người dùng v1 tích cực nhất. Thế mà con vợ lại so sánh NPS của all users v1 với NPS của hàng tuyển v2. Phét lác thật!



Việc so sánh điểm NPS của người dùng v2 với v1 trong trường hợp này là bất hợp lý. Nếu so sánh điểm NPS của v2 với điểm của những người đó khi sử dụng V1 (tức power users v1 và v2) thì sẽ hợp lý hơn, nhưng không.


Tình huống trên dính vào sampling bias - một trong những bias phổ biến của ngụy thống kê (statistical fallacy).


Sampling bias

"Drawing a conclusion about a population based on a sample that is biased, or chosen in order to make it appear the population on average is different than it actually is."


---


Statistical fallacy

"A statistical fallacy is an error in statistical reasoning where statistical data is misused, misinterpreted, or presented in a biased way to support a misleading or incorrect conclusion"



Bên trên là một ví dụ rất gần gũi và quen thuộc khi nói về Ngụy thống kê, ngoài ra nguyên nhân của ngụy thống kê còn nhiều cái khác.


Trong survey thì:

  • Chọn loại câu hỏi sai,
  • Đặt câu hỏi mơ hồ không rõ ràng
  • Thiên vị nhóm đối tượng,
  • Phân tích trong khi cấu trúc sample không đầy đủ...



Trong product analytic:


  • Đặt trigger sai,
  • Shọn số sai,
  • Chọn timeframe phân tích sai,
  • Sử dụng điều kiện sai hay diễn giải sai,
  • Trình bày sai thì cũng đều đứt...



Kể cho các con vợ 1 ví dụ khác trong product analytic cho dễ hiểu:


Có một cốp của cốp bank yêu cầu ưu tiên luồng chuyển khoản đến người thụ hưởng vì số liệu chỉ ra số lượng giao dịch chuyển khoản đến người đã lưu cao gấp 10 lần chuyển khoản đến người mới.


Quái lạ, nghe rất chi là phản trực giác. Tại quen biết, tôi xin mở quả dashboard nội bộ lên để select theo 1 chiều khác thì số nó lại ra khác. bảo cốp check lại xem chứ nhìn theo 2 aspects khác nhau mà số khác nhau tức là mâu thuẫn rồi. Cốp mất nửa tiếng ngồi soi. Hóa ra cái để ghi nhận là chuyển đến người thụ hưởng được trigger khi người dùng view màn chứ không phải khi họ chọn người thụ hưởng.



Cái này thì phân tích chẳng có vấn đề gì, lỗi tại ông đánh máy.


Để các bảnh khi phỏng vấn ứng viên hay đơn giản là phản biện nhau trong công việc thì nhớ hỏi kỹ:

  • Số được lấy bằng phương pháp gì?
  • Lấy từ tập người nào? Tiêu chí lấy là gì? Cấu trúc?
  • Thu thập trong bao lâu? Phương pháp thu thập?
  • Số liệu là gì? Phản ánh điều gì?
  • Sâu hơn thì hỏi các bước từ lấy số đến phân tích.


Chỉ cần 1 bước trong này hẹo thôi là đã có cơ sở reject kết luận cuối cùng dòiii.

Chúc các con vợ có số có má, chứ đừng "Số? Má!!!" nhé.