Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng team của bạn vừa dốc ba tháng công sức để ship một tính năng mới: "Đặt lịch giao hàng theo khung giờ". Sếp hỏi: "Tính năng đó có ai dùng không? Có đáng để bảo trì tiếp không? Có nên đầu tư thêm không?". Nếu bạn chỉ trả lời được bằng cảm tính — "Chắc là có anh, em thấy vài khách khen" — thì bạn đang đứng ở vị trí rất yếu. Ngược lại, nếu bạn mở dashboard và nói "12% người dùng đã thử tính năng trong 30 ngày, nhưng chỉ 3% dùng lại lần hai, và nhóm dùng lại có retention D30 cao hơn 18 điểm phần trăm so với nhóm không dùng" — thì bạn đang nói ngôn ngữ của một PM ra quyết định dựa trên dữ liệu.
Đó chính là lý do Feature Adoption + Usage Analytics (phân tích mức độ chấp nhận và sử dụng tính năng) là một trong những kỹ năng bản lề của nghề Product. Trong khóa học này, bạn đã học về funnel, retention, activation. Bài 18 tập trung vào một câu hỏi rất cụ thể và thực dụng: từng tính năng cụ thể trong sản phẩm đang được đón nhận và sử dụng như thế nào? Đây là góc nhìn "micro" — soi vào từng feature — khác với các bài về retention tổng thể (Bài 10) hay engagement toàn sản phẩm như DAU/MAU (Bài 17).
Việc đo lường adoption tốt giúp bạn làm ba việc sống còn: (1) chứng minh giá trị của khoản đầu tư kỹ thuật, (2) phát hiện tính năng "chết yểu" để khai tử (sunset) và giải phóng nguồn lực, và (3) cải thiện tính năng dựa trên hành vi thực tế thay vì phỏng đoán. Chúng ta sẽ học cách làm điều này bằng Mixpanel và Amplitude — hai công cụ trọng tâm của khóa.
Khái niệm cốt lõi
Adoption vs Usage — hai mặt của một đồng xu
Nhiều người dùng lẫn lộn hai khái niệm này. Hãy phân biệt rõ:
- Adoption (chấp nhận): trả lời câu hỏi "Có bao nhiêu người bắt đầu dùng tính năng?". Đây là câu chuyện về độ phủ, về việc người dùng có khám phá và thử tính năng hay không.
- Usage (sử dụng): trả lời câu hỏi "Những người đã dùng thì dùng sâu và thường xuyên đến mức nào?". Đây là câu chuyện về độ gắn bó, tần suất, cường độ.
Bộ chỉ số adoption cốt lõi
Có bốn chỉ số nền tảng bạn phải nắm:
1. Adoption Rate (Tỷ lệ chấp nhận). Công thức cơ bản:
Adoption Rate = Số user đã dùng feature / Tổng số user đủ điều kiện dùng
Điểm mấu chốt nằm ở mẫu số: "đủ điều kiện dùng" (eligible users), không phải tổng toàn bộ user. Nếu tính năng "Xuất hóa đơn VAT" chỉ dành cho tài khoản doanh nghiệp, thì mẫu số phải là số tài khoản doanh nghiệp, không phải toàn bộ người dùng. Đây là lỗi tính sai phổ biến nhất khiến con số adoption bị pha loãng và mất ý nghĩa.
2. Breadth (Độ rộng): bao nhiêu phần trăm user dùng tính năng — chính là adoption rate ở trên, đo độ phủ.
3. Depth (Độ sâu): trong số người dùng, họ dùng bao nhiêu lần, dùng bao nhiêu khía cạnh của tính năng. Ví dụ: một người dùng tính năng "Bộ lọc nâng cao" có thể chỉ dùng 1 tiêu chí lọc, hoặc kết hợp 5 tiêu chí — depth khác nhau hoàn toàn.
4. Time-to-Adopt (Thời gian đến khi chấp nhận): mất bao lâu kể từ khi user có thể tiếp cận tính năng cho tới khi họ thực sự dùng lần đầu. Con số này càng ngắn thì tính năng càng dễ khám phá.
Ba tầng của một feature adoption "khỏe mạnh"
Một khung tư duy hữu ích là chia adoption thành ba tầng, giống một cái phễu thu nhỏ:
- Awareness / Exposure: user nhìn thấy điểm vào của tính năng (thấy nút, thấy banner, thấy menu).
- Activation / First Use: user dùng lần đầu — bấm vào và hoàn thành hành động cốt lõi.
- Repeat / Habitual Use: user quay lại dùng lần hai, lần ba, biến nó thành thói quen.
Feature Adoption Matrix — công cụ ra quyết định
Đây là khung phân loại kinh điển do John Cutler phổ biến, ghép Breadth (trục ngang: % user dùng) với Frequency/Depth (trục dọc: dùng thường xuyên đến đâu), tạo ra bốn ô:
- Core (rộng + thường xuyên): tính năng xương sống — bảo vệ và tối ưu, đừng phá.
- Adopted (rộng nhưng ít lặp lại): nhiều người thử, ít người gắn bó — cần tăng depth, tìm lý do quay lại.
- Niche (hẹp nhưng thường xuyên): ít người dùng nhưng ai dùng thì nghiện — cân nhắc tăng khám phá, hoặc chấp nhận đây là tính năng cho phân khúc chuyên biệt.
- Rarely used (hẹp + hiếm): ứng viên số một để khai tử (sunset).
Tình huống thực tế
Ví dụ 1: Tính năng "chết yểu" ở một ví điện tử Việt Nam
Một ví điện tử tại Việt Nam (gọi là "PayViet" cho ẩn danh) ra mắt tính năng "Hũ tiết kiệm mục tiêu" — cho phép người dùng tạo các hũ tiết kiệm theo mục tiêu như "Du lịch Đà Nẵng", "Mua điện thoại". Team engineering đầu tư 2 sprint.
Sau 6 tuần, PM mở Amplitude và dựng một biểu đồ: adoption rate trên nhóm eligible (user đã KYC, có số dư > 0) chỉ đạt 4,2%. Đào sâu hơn bằng phễu ba tầng, họ phát hiện: 38% người dùng nhìn thấy banner (exposure ổn), nhưng chỉ 4,2% tạo hũ đầu tiên, và trong số đó chỉ 11% nạp tiền vào hũ lần thứ hai. Rớt cực mạnh ở tầng activation.
Xem session và khảo sát, họ hiểu ra: người dùng thấy hấp dẫn nhưng ngại "khóa tiền" vì lo cần rút gấp. Bài học rút ra: adoption thấp không phải lúc nào cũng do người dùng không biết — ở đây exposure cao mà activation thấp, chỉ thẳng vào rào cản tâm lý/UX. PayViet đã thêm tùy chọn "rút bất cứ lúc nào không phí" và adoption tăng lên 9%. Nếu chỉ nhìn con số 4,2% tổng rồi vội khai tử, họ đã bỏ lỡ cơ hội cứu tính năng.
Ví dụ 2: "Viên ngọc ẩn" ở một nền tảng SaaS quản lý bán hàng
Một startup SaaS ở TP.HCM cung cấp phần mềm quản lý bán hàng cho các shop nhỏ. Họ có tính năng "Báo cáo lời lỗ tự động". PM ban đầu định cắt vì adoption rate chỉ 6%. Nhưng khi phân tích depth trong Mixpanel bằng cách phân khúc theo cohort, bức tranh đảo ngược: nhóm 6% đó có retention D90 là 71%, so với 34% của nhóm không dùng. Họ cũng có ARPU cao hơn gấp đôi.
Rõ ràng đây là ô Niche trong ma trận adoption — hẹp nhưng cực kỳ dính. Bài học: đừng bao giờ ra quyết định sunset chỉ dựa trên breadth. Phải chéo (cross-reference) adoption với retention và doanh thu. Team quyết định không cắt, mà làm ngược lại: đưa báo cáo lời lỗ thành điểm bán hàng chính trong onboarding. Sáu tháng sau adoption lên 22% và trở thành tính năng "câu khách" của gói trả phí.
Ví dụ 3: Đo depth để định hướng roadmap ở một app gọi xe
Một hãng gọi xe khu vực Đông Nam Á (bối cảnh giả định kiểu Grab/Gojek) ra tính năng "Đặt xe theo lịch" (schedule ride). Adoption breadth đạt 15% — con số ổn. Nhưng PM muốn biết nên đầu tư tiếp vào đâu, nên họ đo depth: trong nhóm đã dùng, 60% chỉ đặt lịch cho sân bay, và 90% đặt trong khung 5-9h sáng.
Insight này cực kỳ giá trị: tính năng đang bị dùng cho một use case rất hẹp (đi sân bay buổi sáng). Bài học: đo depth và phân tích ngữ cảnh sử dụng (dùng cho việc gì, khi nào) quan trọng ngang việc đếm số lượt dùng. Thay vì làm nhiều tính năng phụ dàn trải, team dồn lực tối ưu đúng luồng "đặt xe đi sân bay buổi sáng" — thêm gợi ý điểm đón sân bay, nhắc đặt trước từ tối hôm trước — và nâng usage lên đáng kể mà chi phí phát triển thấp.
Hướng dẫn từng bước
Đây là quy trình chuẩn để đo adoption cho một tính năng, áp dụng được cả trên Mixpanel lẫn Amplitude.
Bước 1 — Định nghĩa "dùng tính năng" bằng một event rõ ràng. Trước khi đo, phải trả lời: hành động nào chứng tỏ user thực sự dùng tính năng, không chỉ vô tình lướt qua? Với "Hũ tiết kiệm", đó không phải là saving_banner_viewed mà là saving_jar_created. Chọn event đại diện cho giá trị cốt lõi của tính năng.
Bước 2 — Xác định mẫu số "eligible users". Ai là người đủ điều kiện dùng? Dựng một cohort trong Amplitude/Mixpanel lọc đúng nhóm này (ví dụ: account_type = business, hoặc user đã ở app đủ 7 ngày). Đây là bước quyết định độ chính xác của adoption rate.
Bước 3 — Dựng phễu ba tầng. Tạo funnel: feature_viewed → feature_first_used → feature_used_again (trong cửa sổ 14 hoặc 30 ngày). Phễu này cho bạn biết user rớt ở đâu (discoverability, activation, hay giá trị).
Bước 4 — Đo depth bằng frequency và property breakdown. Trong Mixpanel dùng "Insights" đếm số lần trung bình mỗi user thực hiện event; trong Amplitude dùng biểu đồ "frequency". Đồng thời breakdown theo event property (ví dụ filter_type, ride_purpose) để hiểu họ dùng khía cạnh nào.
Bước 5 — Chéo với retention và doanh thu. Tạo hai cohort: "đã adopt feature" và "chưa adopt", rồi so sánh retention curve và ARPU giữa hai nhóm. Đây là bước biến adoption thành lập luận về giá trị kinh doanh.
Bước 6 — Đặt tính năng vào Adoption Matrix và ra quyết định. Dựa trên breadth × depth cùng dữ liệu retention, phân loại Core / Adopted / Niche / Rarely used và đưa ra hành động: tối ưu, đẩy khám phá, tăng depth, hay sunset.
Bước 7 — Dựng dashboard theo dõi liên tục. Đừng đo một lần rồi thôi. Tạo dashboard cố định với adoption rate, phễu ba tầng, và depth theo thời gian để phát hiện xu hướng (đặc biệt sau mỗi lần release).
Lỗi thường gặp & mẹo
Lỗi 1 — Lấy mẫu số sai (dùng tổng user thay vì eligible user). Đây là lỗi phổ biến nhất. Nó khiến adoption rate của một tính năng B2B hoặc tính năng theo phân khúc bị pha loãng, trông thảm hại một cách oan uổng. Luôn hỏi: "Ai thật sự có thể dùng cái này?".
Lỗi 2 — Nhầm exposure với usage. Đếm feature_viewed rồi bảo "80% user dùng tính năng" là sai bản chất. Nhìn thấy ≠ sử dụng. Hãy neo adoption vào event thể hiện hành động có ý nghĩa.
Lỗi 3 — Chỉ đo breadth, bỏ qua depth. Như ví dụ SaaS ở trên, chỉ nhìn "6% dùng" mà không đo độ dính sẽ dẫn tới quyết định sunset sai lầm. Luôn đo cả hai chiều.
Lỗi 4 — Đo adoption ngay sau khi release rồi vội kết luận. Adoption cần thời gian để ngấm (time-to-adopt). Đo ở tuần đầu tiên thường cho con số thấp giả tạo. Hãy cho tính năng ít nhất 2-4 tuần và theo dõi đường cong, đừng chỉ chụp một điểm.
Lỗi 5 — Không phân biệt user mới và user cũ. User mới có thể chưa từng thấy giao diện cũ nên adopt tính năng mới dễ hơn; user cũ đã có thói quen nên chậm hơn. Tách hai nhóm để tránh kết luận nhiễu.
Mẹo — Dùng "power user curve" (đường cong L28). Thay vì chỉ nhìn trung bình, vẽ histogram số ngày dùng tính năng trong 28 ngày. Một tính năng khỏe có "nụ cười" ở bên phải (một nhóm dùng gần như mỗi ngày). Đây là cách nhìn depth trực quan mà cả Mixpanel lẫn Amplitude đều hỗ trợ.
Mẹo — Gắn adoption vào định nghĩa "feature success" ngay từ khâu spec. Trước khi build, hãy viết rõ: "Tính năng thành công nếu đạt X% adoption trên eligible users và Y% repeat trong 30 ngày". Có mục tiêu định lượng trước giúp việc đánh giá sau này khách quan, không cãi nhau bằng cảm tính.
Bài tập thực hành
- Chọn một tính năng trong sản phẩm bạn đang làm (hoặc một app bạn dùng hằng ngày như Shopee, MoMo, Grab). Viết ra: event nào đại diện cho "thực sự dùng tính năng"? Ai là "eligible users"?
- Thiết kế phễu ba tầng cho tính năng đó: đặt tên ba event tương ứng exposure → first use → repeat use, và chọn cửa sổ thời gian (7/14/30 ngày) phù hợp.
- Phác thảo Adoption Matrix: giả sử tính năng có breadth 12% và trung bình mỗi user dùng 1,3 lần/tháng — nó rơi vào ô nào? Đề xuất một hành động cụ thể.
- Tình huống ra quyết định: một tính năng có adoption 5% nhưng nhóm dùng nó có retention D30 cao hơn 20 điểm. Bạn sẽ sunset hay giữ? Viết 3-4 câu lập luận, có nhắc tới việc chéo dữ liệu.
- (Nâng cao) Nếu có tài khoản Mixpanel/Amplitude thử nghiệm, hãy dựng thật một dashboard gồm adoption rate (với mẫu số eligible), phễu ba tầng, và so sánh retention giữa nhóm adopt và không adopt.
Tóm tắt
Feature Adoption + Usage Analytics là kỹ năng giúp bạn trả lời chính xác câu hỏi "tính năng này có đáng không?" bằng dữ liệu thay vì cảm tính. Hãy nhớ những điểm cốt lõi sau:
- Phân biệt Adoption (bao nhiêu người bắt đầu dùng) với Usage (dùng sâu và thường xuyên ra sao) — một tính năng cần cả hai.
- Bốn chỉ số nền tảng: Adoption Rate (nhớ lấy mẫu số eligible users), Breadth, Depth, và Time-to-Adopt.
- Dùng phễu ba tầng (exposure → first use → repeat) để định vị chính xác vấn đề nằm ở discoverability, activation hay giá trị.
- Adoption Matrix (breadth × depth) biến số liệu thành quyết định: Core, Adopted, Niche, hay Rarely used.
- Luôn chéo adoption với retention và doanh thu trước khi ra quyết định sunset — như ví dụ "viên ngọc ẩn" cho thấy, breadth thấp không có nghĩa là vô giá trị.
- Đo liên tục qua dashboard, cho tính năng đủ thời gian ngấm, và đặt mục tiêu adoption ngay từ khâu spec.