Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn là UX researcher tại một fintech ở TP.HCM. Product Manager bước vào phòng và hỏi: "Người dùng thích tính năng nào hơn — chuyển tiền miễn phí, hay lãi suất tiết kiệm cao, hay giao diện đẹp?". Bạn làm một khảo sát, hỏi thẳng: "Bạn đánh giá mức độ quan trọng của mỗi yếu tố sau từ 1 đến 5". Kết quả trả về: gần như tất cả đều 5/5. Miễn phí? Quan trọng. Lãi suất cao? Quan trọng. Giao diện đẹp? Cũng quan trọng. Bảo mật? Cực kỳ quan trọng.
Bạn vừa gặp phải căn bệnh kinh niên của khảo sát tự đánh giá (self-report rating): khi mọi thứ đều miễn phí về mặt tâm lý, người ta muốn tất cả. Không ai phải trả giá cho câu trả lời của họ, nên họ nói "tôi muốn mọi thứ tốt nhất". Dữ liệu đó vô dụng cho việc ra quyết định, vì đời thực không cho bạn có tất cả — bạn luôn phải đánh đổi (trade-off).
Đây chính là lý do Conjoint Analysis tồn tại. Thay vì hỏi người dùng họ coi trọng cái gì, ta buộc họ lựa chọn giữa các gói sản phẩm không hoàn hảo — mỗi gói mạnh mặt này, yếu mặt kia. Qua hàng loạt lựa chọn ép buộc đó, ta suy ngược ra được giá trị thật sự (mà chính người dùng cũng không tự nhận thức được) mà họ gán cho từng thuộc tính. Đây là một trong những kỹ thuật survey định lượng mạnh nhất, được dùng để định giá, thiết kế danh mục tính năng, và mô phỏng thị phần — những quyết định trị giá hàng tỷ đồng. Nắm được nó, bạn nâng vai trò researcher từ "người thu thập ý kiến" lên "người dự đoán hành vi".
Khái niệm cốt lõi
Conjoint Analysis là gì
Conjoint Analysis (phân tích kết hợp) là một phương pháp khảo sát định lượng đo lường mức độ người dùng coi trọng từng thuộc tính (attribute) và từng cấp độ (level) của sản phẩm, bằng cách buộc họ đưa ra các lựa chọn đánh đổi giữa những phương án trọn gói. Tên gọi "conjoint" đến từ "considered jointly" — người dùng đánh giá các thuộc tính cùng nhau trong một gói hoàn chỉnh, chứ không tách rời từng cái.
Ý tưởng nền tảng: giá trị của một sản phẩm là tổng giá trị của các phần cấu thành nó. Nếu tôi biết bạn chọn gói A (rẻ nhưng giao hàng chậm) thay vì gói B (đắt nhưng giao nhanh), tôi suy ra được bạn định giá "giao nhanh" đáng bao nhiêu tiền với bạn. Lặp lại hàng chục lựa chọn như vậy với hàng trăm người, ta tính ra được con số định lượng cho mỗi cấp độ.
Ba khái niệm phải nắm
Attribute (thuộc tính): đặc điểm của sản phẩm mà bạn muốn nghiên cứu. Ví dụ với một app gọi xe: giá cước, thời gian chờ xe, loại xe, chính sách hủy chuyến.
Level (cấp độ): các giá trị cụ thể trong mỗi thuộc tính. Thuộc tính "thời gian chờ" có thể có các level: 3 phút, 7 phút, 12 phút. Thuộc tính "giá cước" có thể có: 25.000đ, 35.000đ, 50.000đ.
Part-worth utility (giá trị thành phần): con số điểm số mà mô hình tính ra cho mỗi level, thể hiện mức độ hấp dẫn của level đó. Đây là output cốt lõi. Từ part-worth, ta tính tiếp ra attribute importance (mức độ quan trọng tương đối của mỗi thuộc tính, thường biểu diễn dạng %), và willingness to pay (sẵn sàng chi trả — quy đổi giá trị của một tính năng ra tiền).
Các loại Conjoint chính
Không phải chỉ có một kiểu conjoint. Bạn cần chọn đúng loại cho câu hỏi của mình:
- Choice-Based Conjoint (CBC) — phổ biến nhất hiện nay. Người dùng xem 3-4 gói sản phẩm đặt cạnh nhau và chọn cái họ sẽ mua (có thể chọn "không mua cái nào"). Rất giống hành vi mua sắm thật, nên độ hiệu lực cao.
- Adaptive Conjoint Analysis (ACA) — câu hỏi thích ứng theo câu trả lời trước đó, phù hợp khi có nhiều thuộc tính (7+).
- MaxDiff (Maximum Difference Scaling) — kỹ thuật họ hàng, người dùng chọn "quan trọng nhất" và "kém quan trọng nhất" trong một nhóm. Rất tốt để xếp hạng ưu tiên nhiều tính năng.
Vì sao nó thắng khảo sát rating truyền thống
Khảo sát rating hỏi thái độ (attitude), Conjoint đo hành vi lựa chọn (revealed preference). Điểm khác biệt sống còn:
- Có ràng buộc đánh đổi — không thể chọn "tất cả đều tốt nhất".
- Giảm thiên kiến social desirability — người dùng không thể nói cho hay; họ chỉ chọn gói.
- Cho ra con số có thể mô phỏng — bạn có thể xây "market simulator": nếu ra mắt gói X với cấu hình này, bao nhiêu % người dùng sẽ chọn nó thay vì đối thủ.
Tình huống thực tế
Ví dụ 1 — Gói cước của một nhà mạng (bối cảnh Việt Nam)
Một nhà mạng lớn (giả định gọi là VietTel-X) muốn thiết kế gói data mới cho nhóm sinh viên. Đội marketing tranh cãi: giảm giá hay tăng dung lượng data hay tặng thêm ưu đãi TikTok/YouTube? Ai cũng có "cảm giác" riêng.
Researcher chạy một CBC với 4 thuộc tính:
- Giá/tháng: 50k, 70k, 90k, 120k
- Data: 4GB/ngày, 6GB/ngày, không giới hạn
- Ưu đãi mạng xã hội: không / miễn phí data TikTok + YouTube
- Cam kết: trả từng tháng / cam kết 6 tháng
Bài học: nếu chỉ hỏi rating, "giá rẻ" sẽ đứng đầu (ai chả muốn rẻ). Conjoint tiết lộ rằng nhóm này thực sự bị chi phối bởi trải nghiệm mạng xã hội. Nhà mạng ra mắt gói với ưu đãi mạng xã hội làm điểm bán chính thay vì đua giá, giữ được biên lợi nhuận.
Ví dụ 2 — App giao đồ ăn định giá phí giao hàng (Đông Nam Á)
Một nền tảng giao đồ ăn kiểu Grab/ShopeeFood muốn hiểu người dùng đánh đổi giữa phí giao hàng và thời gian chờ như thế nào, để tối ưu thuật toán ghép đơn. Họ chạy CBC với các thuộc tính:
- Phí giao: 0đ, 15.000đ, 25.000đ
- Thời gian giao: 20 phút, 35 phút, 50 phút
- Đánh giá quán: 4.0 sao, 4.5 sao, 4.8 sao
Bài học: Conjoint không chỉ nói "cái nào quan trọng", nó vẽ ra hình dạng của sở thích. Nền tảng dùng thông tin này để tinh chỉnh: khi hệ thống dự đoán đơn sẽ giao quá 40 phút, tự động áp mã giảm phí giao để bù đắp — giữ tỷ lệ hoàn tất đơn.
Ví dụ 3 — Cạm bẫy thuộc tính không thực tế (bài học về sai lầm)
Một startup SaaS B2B ở Singapore làm conjoint cho công cụ quản lý dự án. Họ đưa vào thuộc tính "giá" với các level từ 5 USD đến 200 USD/user/tháng, và thuộc tính "tính năng AI" với level "có/không". Kết quả: mọi người chọn gói rẻ nhất + đầy đủ tính năng nhất — một tổ hợp mà công ty không bao giờ có thể cung cấp có lãi.
Vấn đề: họ để các level tồn tại những combo phi thực tế (5 USD mà lại có full AI), và người dùng "học" được rằng cứ chọn cực đoan. Sau khi họ áp prohibition (cấm các tổ hợp bất khả thi) và thu hẹp dải giá về vùng thực tế (20–80 USD), kết quả trở nên hữu dụng và WTP cho AI hiện ra rõ ràng ở mức ~22 USD/user.
Bài học: thiết kế thuộc tính/level cẩu thả sẽ cho ra dữ liệu rác. Dải giá phải bao quanh vùng thị trường thật; các tổ hợp phi lý phải bị cấm.
Hướng dẫn từng bước
Bước 1 — Xác định quyết định kinh doanh cần trả lời. Đừng bắt đầu bằng "tôi muốn làm conjoint". Bắt đầu bằng: "Tôi cần biết nên định giá gói Pro ở mức nào" hoặc "Nên ưu tiên phát triển tính năng nào trước". Conjoint chỉ đáng công sức khi có quyết định đánh đổi thật.
Bước 2 — Chọn thuộc tính (4–6 là lý tưởng). Quá ít thì không đủ insight; quá nhiều (7+) làm người trả lời quá tải và chất lượng dữ liệu tụt. Mỗi thuộc tính phải: liên quan đến quyết định, độc lập tương đối với nhau, và có thể hành động được (bạn thực sự kiểm soát được nó).
Bước 3 — Định nghĩa level cho mỗi thuộc tính (3–5 level/thuộc tính). Level phải cụ thể, khả thi, và bao trùm dải thực tế. Với giá, đặt các mốc quanh giá thị trường hiện tại, đừng để dải quá rộng.
Bước 4 — Thiết kế experimental design. Bạn không thể cho người dùng xem tất cả tổ hợp (chúng có thể lên tới hàng nghìn). Phần mềm (Sawtooth Software, Conjoint.ly, hoặc Qualtrics Conjoint) sẽ tạo một fractional factorial design — chọn tập con các gói vừa đủ để ước lượng part-worth một cách thống kê. Đây là lúc bạn khai báo prohibitions.
Bước 5 — Xác định cỡ mẫu. Quy tắc ngón tay cái cho CBC: tối thiểu ~300 người cho phân tích tổng thể; nếu cần phân tích theo phân khúc (ví dụ so sánh sinh viên vs người đi làm), cần ~200 mỗi phân khúc. Mỗi người thường trả lời 8–12 choice task.
Bước 6 — Chạy khảo sát. Kèm màn hình giới thiệu ngắn giải thích cách làm, có "none option" (không chọn gói nào) để mô phỏng cả trường hợp người dùng bỏ đi.
Bước 7 — Phân tích. Phần mềm dùng mô hình như Hierarchical Bayes (HB) để ước lượng part-worth cho từng cá nhân, không chỉ trung bình. Từ đó tính attribute importance (%), willingness to pay, và quan trọng nhất là xây market simulator.
Bước 8 — Mô phỏng và trình bày. Dùng simulator để chạy kịch bản: "Nếu ta ra mắt gói này với giá này, so với đối thủ, dự báo share of preference là bao nhiêu?". Đây là output giá trị nhất mang đến bàn ra quyết định.
Lỗi thường gặp & mẹo
Nhồi quá nhiều thuộc tính. Trên 6 thuộc tính, người trả lời chuyển sang chiến lược đơn giản hóa (chỉ nhìn giá) và dữ liệu mất chất. Nếu có nhiều yếu tố cần xếp hạng, dùng MaxDiff thay vì conjoint.
Dải level phi thực tế. Để giá chạy từ 0 tới trên trời khiến người dùng luôn chọn rẻ nhất. Neo các level quanh thực tế thị trường.
Quên prohibitions. Nếu không cấm các tổ hợp bất khả thi, mô hình có thể tạo ra gói "rẻ nhất + xịn nhất" và làm sai lệch ước lượng.
Level không cân bằng về mặt tâm lý. Nếu một thuộc tính có level cực đoan gây chú ý (ví dụ "MIỄN PHÍ" viết hoa), nó thu hút ánh nhìn không tương xứng. Giữ cách trình bày trung tính, đồng đều.
Nhầm importance với ưu tiên tuyệt đối. Attribute importance phụ thuộc vào dải level bạn chọn. Nếu bạn để giá chạy dải rất rộng, giá sẽ tự động trông "quan trọng" hơn. Importance là tương đối với thiết kế, không phải chân lý phổ quát.
Mẹo — luôn có "none option". Cho phép người dùng chọn "tôi sẽ không mua cái nào" phản ánh thực tế thị trường và giúp bạn ước lượng nhu cầu tuyệt đối, không chỉ nhu cầu tương đối giữa các gói.
Mẹo — pilot trước. Chạy thử với 20–30 người để kiểm tra người dùng có hiểu nhiệm vụ không, thời gian hoàn thành có hợp lý không (lý tưởng dưới 8–10 phút), trước khi tung ra cỡ mẫu lớn.
Mẹo — kể chuyện bằng simulator, không phải bằng bảng số. Stakeholder không quan tâm part-worth utility là 1.34 hay 0.87. Họ quan tâm "gói A sẽ lấy 40% thị phần, gói B lấy 25%". Trình bày bằng kịch bản mô phỏng.
Bài tập thực hành
Bài tập 1 — Thiết kế thuộc tính. Chọn một sản phẩm bạn quen thuộc (app học tiếng Anh, dịch vụ đặt phòng, ví điện tử). Liệt kê 5 thuộc tính phù hợp cho một CBC và 3–4 level cho mỗi thuộc tính. Kiểm tra: các level có bao trùm dải thực tế không? Có cặp tổ hợp nào bất khả thi cần cấm không?
Bài tập 2 — Đọc kết quả. Giả sử conjoint cho một app tiết kiệm ra kết quả importance: Lãi suất 45%, Uy tín ngân hàng đối tác 30%, Giao diện 15%, Ưu đãi giới thiệu 10%. Đội thiết kế muốn dồn 3 tháng làm lại giao diện. Bạn phản biện thế nào dựa trên dữ liệu này? Insight nào bạn sẽ ưu tiên?
Bài tập 3 — Willingness to pay. Nếu part-worth cho thấy chuyển từ "giao 50 phút" sang "giao 20 phút" tăng giá trị tương đương với việc giảm 20.000đ phí giao, hãy giải thích bằng lời con số này nghĩa là gì cho quyết định định giá phí giao hàng theo khung giờ cao điểm.
Bài tập 4 — Chọn phương pháp. Với mỗi tình huống, quyết định dùng CBC, MaxDiff, hay khảo sát rating thường: (a) xếp hạng ưu tiên 15 tính năng cho roadmap; (b) định giá gói subscription mới; (c) đo mức độ hài lòng chung với sản phẩm hiện tại.
Tóm tắt
Conjoint Analysis giải quyết căn bệnh gốc của khảo sát tự đánh giá: khi không có đánh đổi, người dùng nói họ muốn mọi thứ. Bằng cách buộc người dùng chọn giữa các gói không hoàn hảo, ta suy ngược ra part-worth utility — giá trị định lượng thật mà họ gán cho từng cấp độ của từng thuộc tính, kể cả khi chính họ không tự nhận thức được.
Những điểm cốt lõi cần nhớ: bắt đầu từ một quyết định kinh doanh thật; giữ 4–6 thuộc tính, mỗi thuộc tính 3–5 level nằm trong dải thực tế; dùng Choice-Based Conjoint vì nó gần hành vi mua thật nhất; luôn có "none option" và prohibitions; cần cỡ mẫu đủ (~300+); và giá trị lớn nhất của phương pháp nằm ở market simulator cho phép dự báo thị phần theo kịch bản. Ba ví dụ — gói cước nhà mạng, phí giao đồ ăn, và startup SaaS mắc bẫy level phi thực tế — cho thấy conjoint không chỉ trả lời "cái gì quan trọng" mà còn tiết lộ hình dạng sở thích và quy đổi giá trị ra tiền. Đây là công cụ đưa researcher từ vai trò thu thập ý kiến lên vai trò dự đoán hành vi và định hướng chiến lược sản phẩm.