Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn vừa chi 200 triệu đồng cho một chiến dịch quảng cáo, kéo được 50.000 người vào ứng dụng, nhưng cuối tháng chỉ có 800 người trở thành khách hàng trả tiền. Câu hỏi đắt giá nhất lúc này không phải là "làm sao kéo thêm người vào", mà là "49.200 người kia đã biến mất ở đâu, và vì sao?". Đó chính xác là câu hỏi mà funnel analysis (phân tích phễu chuyển đổi) sinh ra để trả lời.
Trong cả khóa học này, bạn đã gặp khái niệm funnel ở góc độ tư duy (Bài 5 — AARRR) và sẽ học sâu về công cụ phân tích nói chung ở Bài 47 (analytics stack). Nhưng Bài 50 tập trung vào một thứ rất cụ thể và thực dụng: công cụ phân tích phễu — cách dựng phễu trong Mixpanel/Amplitude/GA4, cách đọc đúng ba tín hiệu quan trọng nhất mà một phễu tiết lộ, và cách biến những con số đó thành quyết định sản phẩm. Đây là kỹ năng "cơm áo gạo tiền" của Growth PM: gần như mọi cuộc họp tăng trưởng đều mở đầu bằng một biểu đồ phễu.
Một Growth PM giỏi nhìn vào phễu không chỉ thấy "tỷ lệ chuyển đổi 1,6%", mà thấy được câu chuyện: bước nào người dùng rơi rụng nhiều bất thường, họ mất bao lâu để đi từ bước này sang bước kia, và nhóm người dùng nào hành xử khác nhóm còn lại. Ba tín hiệu đó là xương sống của bài học hôm nay.
Khái niệm cốt lõi
Funnel là gì và công cụ funnel làm gì cho bạn
Funnel là một chuỗi các bước (steps) có thứ tự mà bạn kỳ vọng người dùng đi qua để đạt một mục tiêu. Ví dụ phễu mua hàng của một sàn thương mại điện tử: Xem sản phẩm → Thêm vào giỏ → Bắt đầu thanh toán → Nhập địa chỉ → Thanh toán thành công.
Công cụ funnel analysis (Mixpanel, Amplitude, GA4 Funnel exploration, PostHog...) lấy dữ liệu sự kiện (events) mà sản phẩm đã ghi nhận, rồi tính cho bạn: ở mỗi bước có bao nhiêu người, bao nhiêu phần trăm chuyển sang bước kế tiếp (step conversion), và bao nhiêu phần trăm hoàn thành toàn bộ phễu (overall conversion). Điều khiến công cụ này mạnh hơn một bảng tính Excel là ba khả năng: tự động ghép sự kiện theo từng người dùng, đo thời gian giữa các bước, và cắt lát (segment) theo bất kỳ thuộc tính nào.
Phễu tiết lộ điều gì — ba tín hiệu
1. Drop-off step — bước người dùng rời đi. Đây là tín hiệu đầu tiên và rõ ràng nhất. Bạn nhìn vào step conversion giữa từng cặp bước liền kề và tìm điểm sụt giảm bất thường. Lưu ý quan trọng: đừng so tỷ lệ tuyệt đối giữa các bước với nhau (bước thanh toán luôn nhỏ hơn bước xem sản phẩm — điều đó là tự nhiên), mà hãy so step-to-step conversion với một chuẩn (benchmark) hợp lý của ngành hoặc với chính lịch sử của bạn. Một bước rớt từ 80% xuống 35% trong khi các bước khác đều trên 70% chính là "lỗ thủng" cần điều tra.
2. Time between steps — thời gian giữa các bước, dấu hiệu của ma sát (friction). Hai phễu có cùng tỷ lệ chuyển đổi 40% nhưng một phễu hoàn thành trong 2 phút, phễu kia mất 3 ngày — đó là hai câu chuyện hoàn toàn khác nhau. Thời gian dài bất thường giữa hai bước thường ám chỉ người dùng phải rời đi làm việc khác (tìm mã giảm giá, hỏi ý kiến, chờ duyệt) hoặc gặp rào cản kỹ thuật. Công cụ tốt cho bạn xem median time to convert (thời gian trung vị) chứ không phải trung bình — vì vài người mất 30 ngày sẽ kéo lệch số trung bình một cách vô nghĩa.
3. Segment differences — sự khác biệt giữa các nhóm. Đây là nơi giá trị thật của công cụ nằm ở. Một phễu tổng 1,6% có thể che giấu sự thật rằng người dùng iOS chuyển đổi 4% còn Android chỉ 0,5%; hoặc người đến từ Facebook chuyển đổi tệ gấp ba lần người đến từ tìm kiếm. Cắt lát theo nền tảng, theo nguồn (channel), theo thiết bị, theo quốc gia, theo phiên bản app... sẽ biến một con số trung bình vô hồn thành một danh sách giả thuyết có thể hành động.
Conversion vs Conversion-over-time, và window
Hai chế độ phễu bạn cần phân biệt. Conversion thuần túy: trong toàn bộ tập người dùng, bao nhiêu phần trăm đi hết phễu. Conversion over time: tỷ lệ chuyển đổi thay đổi thế nào qua từng ngày/tuần — hữu ích để phát hiện một bản cập nhật vừa làm hỏng bước nào đó.
Một tham số dễ bị bỏ quên nhưng cực kỳ quan trọng là conversion window — khoảng thời gian tối đa để một người được tính là "hoàn thành phễu". Nếu bạn đặt window 1 giờ cho một sản phẩm B2B mà quyết định mua thường mất 2 tuần, tỷ lệ chuyển đổi sẽ thấp giả tạo. Ngược lại, window 30 ngày cho một thao tác đáng lẽ xong trong 1 phiên sẽ thổi phồng con số. Window phải khớp với hành vi thực tế của sản phẩm.
Ordered vs unordered funnel
Phễu có thứ tự (ordered) yêu cầu người dùng làm đúng tuần tự A→B→C. Phễu không thứ tự (unordered) chỉ cần họ làm cả ba việc trong window, bất kể trình tự. Chọn sai loại sẽ ra số sai: ví dụ với onboarding mà người dùng có thể bật thông báo trước hoặc sau khi tạo hồ sơ, ép thứ tự cứng sẽ khiến bạn tưởng có drop-off trong khi thực ra không có.
Tình huống thực tế
Tình huống 1 — Sàn TMĐT Việt Nam và "lỗ thủng" ở bước nhập địa chỉ
Một đội tăng trưởng tại một sàn thương mại điện tử ở TP.HCM dựng phễu checkout trên Amplitude: Thêm vào giỏ (100%) → Bắt đầu thanh toán (62%) → Nhập địa chỉ (58%) → Chọn vận chuyển (24%) → Đặt hàng thành công (21%). Nhìn lướt qua, ai cũng đổ lỗi cho bước thanh toán "21% là thấp".
Nhưng khi đọc đúng theo step-to-step, đội phát hiện điểm bất thường nằm ở chặng Nhập địa chỉ → Chọn vận chuyển: rớt từ 58% xuống 24%, tức mất gần 60% người ngay tại đó, trong khi các bước khác đều mượt. Họ bật thêm chỉ số median time và thấy chặng này mất tới 4 phút — quá lâu cho một thao tác chọn phương thức ship. Cắt lát theo thiết bị, bức tranh lộ ra: trên màn hình điện thoại Android nhỏ, danh sách phí vận chuyển bị một banner khuyến mãi che mất, người dùng loay hoay cuộn tìm nút. Sau khi sửa layout, chặng đó tăng từ 24% lên 41%, kéo overall conversion từ 21% lên 33%.
Bài học: Đừng nhìn con số cuối phễu rồi đổ lỗi cho bước cuối. Tìm chặng có step-conversion sụt mạnh nhất, rồi dùng time between steps và segment để truy nguyên nhân gốc.
Tình huống 2 — App gọi xe và bẫy conversion window
Một startup gọi xe/giao đồ ăn tại Đông Nam Á (tạm gọi là "Zoom Delivery") báo cáo phễu activation: Mở app → Tìm nhà hàng → Đặt đơn đầu tiên chỉ đạt 9%, khiến cả công ty hoảng. Khi PM kiểm tra cấu hình phễu trên Mixpanel, anh phát hiện conversion window đang để mặc định 1 giờ. Thực tế nhiều người mở app buổi sáng để xem, rồi tối mới đặt đơn — toàn bộ nhóm này bị tính là "rớt phễu".
Nới window lên 7 ngày, con số thật là 23%. Quan trọng hơn, khi xem conversion-over-time, đội thấy median time-to-first-order là 1,8 ngày. Điều này thay đổi chiến lược: thay vì cố ép đặt đơn trong phiên đầu, họ thiết kế một chuỗi nhắc nhở trong 48 giờ đầu và đẩy đúng nhóm "đã tìm nhà hàng nhưng chưa đặt".
Bài học: Một tham số cấu hình sai (window) có thể vẽ ra một cuộc khủng hoảng không tồn tại — hoặc che giấu một vấn đề có thật. Luôn đặt window khớp với chu kỳ quyết định thực tế của người dùng.
Tình huống 3 — SaaS B2B và con số trung bình lừa dối
Một công ty SaaS quản lý bán hàng phục vụ doanh nghiệp Việt báo overall trial-to-paid conversion 5%, tưởng như cả sản phẩm có vấn đề. PM cắt lát phễu theo quy mô đội đăng ký (số ghế trong tài khoản trial). Kết quả: tài khoản 1 người chuyển đổi 1,2%; tài khoản 2–5 người chuyển đổi 6%; tài khoản trên 5 người chuyển đổi 19%. Con số trung bình 5% bị kéo xuống bởi rất nhiều tài khoản cá nhân đăng ký "xem cho biết".
Phát hiện này định hình lại toàn bộ growth: đội tập trung onboarding và sales-assist cho nhóm nhiều ghế (vốn chuyển đổi cao và giá trị lớn), đồng thời tự động hóa hoàn toàn nhóm 1 người. Chỉ riêng việc đọc đúng segment, không cần thêm tính năng nào, đã giúp họ phân bổ nguồn lực hiệu quả hơn hẳn.
Bài học: Một con số tổng luôn là trung bình của nhiều nhóm rất khác nhau. Segment difference thường là tín hiệu giàu hành động nhất mà phễu cung cấp.
Hướng dẫn từng bước
Đây là quy trình dựng và đọc một phễu mà bạn có thể áp dụng ngay trên Mixpanel, Amplitude hay GA4 (tên menu khác nhau nhưng logic giống nhau).
Bước 1 — Định nghĩa câu hỏi trước, không phải dựng phễu trước. Viết ra: "Tôi đang muốn hiểu vì sao người dùng không hoàn thành [hành động X]?". Câu hỏi quyết định bước đầu và bước cuối của phễu.
Bước 2 — Chọn các bước (events) có ý nghĩa. Mỗi bước phải là một event đã được tracking đúng (việc này thuộc về tracking plan — Bài 49). Đừng nhồi quá nhiều bước: 3–6 bước là vùng dễ đọc nhất. Quá nhiều bước khiến mỗi chặng rớt ít, khó tìm thủ phạm.
Bước 3 — Chọn ordered hay unordered, và đặt conversion window. Mặc định dùng ordered cho luồng tuyến tính (checkout, onboarding tuần tự). Đặt window bằng cách quan sát hành vi thật: nếu chưa biết, để rộng rồi xem median time để hiệu chỉnh lại.
Bước 4 — Đọc step-to-step conversion, khoanh vùng drop-off lớn nhất. Tìm chặng có tỷ lệ rớt cao bất thường so với các chặng khác. Đây là nghi phạm số một.
Bước 5 — Bật chỉ số thời gian (time to convert) cho chặng nghi vấn. Median time dài bất thường = ma sát hoặc rào cản kỹ thuật. Ghi lại giả thuyết.
Bước 6 — Cắt lát theo 2–3 thuộc tính quan trọng nhất. Bắt đầu với nền tảng (iOS/Android/Web), nguồn (channel), và phiên bản app. Tìm nhóm nào lệch hẳn so với trung bình.
Bước 7 — Chuyển phát hiện thành giả thuyết có thể kiểm chứng. Ví dụ: "Người dùng Android rớt ở bước chọn ship vì banner che nút → nếu bỏ banner trên Android, step conversion tăng." Giả thuyết này sau đó đi vào quy trình A/B test (các bài về thử nghiệm).
Bước 8 — Lưu phễu và theo dõi theo thời gian. Đặt phễu lên dashboard, bật conversion-over-time để phát hiện sớm khi một bản release làm hỏng chuyển đổi.
Lỗi thường gặp & mẹo
Lỗi 1 — So sánh tỷ lệ tuyệt đối giữa các bước. "Bước thanh toán chỉ 20%!" — đương nhiên, vì nó ở cuối phễu. Luôn đọc step-to-step conversion, không phải tỷ lệ so với bước đầu.
Lỗi 2 — Bỏ quên conversion window. Như tình huống Zoom Delivery, window sai làm sai toàn bộ kết luận. Luôn kiểm tra tham số này đầu tiên khi một con số trông "quá tệ" hoặc "quá đẹp".
Lỗi 3 — Chỉ nhìn con số tổng, không segment. Trung bình là kẻ nói dối lịch sự. Một phễu chưa cắt lát là một phễu chưa đọc xong.
Lỗi 4 — Dùng trung bình thay vì trung vị cho thời gian. Vài outlier 30 ngày sẽ thổi phồng average. Median phản ánh trải nghiệm của người dùng điển hình.
Lỗi 5 — Nhồi quá nhiều bước. Phễu 12 bước khiến mỗi chặng rớt 5–10%, không thể tìm ra thủ phạm. Tách thành nhiều phễu nhỏ tập trung hơn.
Lỗi 6 — Tin phễu khi tracking sai. Nếu một event bị bắn thiếu hoặc bắn trùng, phễu sẽ nói dối bạn rất thuyết phục. Trước khi tin một drop-off lạ, hãy kiểm tra event đó có được ghi nhận đúng không.
Mẹo: Khi tìm thấy drop-off, hãy xem session replay (nếu công cụ hỗ trợ) của vài chục người rớt ở đúng bước đó. Mười phút xem người thật loay hoay thường cho insight nhanh hơn cả giờ nhìn biểu đồ.
Mẹo: Luôn ghi chú "annotation" lên dashboard mỗi lần release. Khi conversion-over-time đổi đột ngột, bạn biết ngay bản nào gây ra.
Bài tập thực hành
- Dựng một phễu thật. Chọn một sản phẩm bạn đang làm (hoặc một app bạn dùng quen). Viết ra phễu 4–5 bước cho một hành động cốt lõi. Định nghĩa rõ event của mỗi bước, chọn ordered/unordered, và đề xuất conversion window hợp lý kèm lý do.
- Săn drop-off. Giả sử phễu cho ra: 100% → 70% → 66% → 30% → 27%. Chỉ ra chặng có vấn đề nhất và viết hai giả thuyết về nguyên nhân (một về UX, một về kỹ thuật).
- Bài tập segment. Một phễu tổng có overall conversion 10%. Liệt kê 4 thuộc tính bạn sẽ cắt lát đầu tiên cho sản phẩm của bạn, và giải thích vì sao mỗi thuộc tính đó có khả năng tiết lộ sự khác biệt lớn.
- Bẫy window. Mô tả một sản phẩm mà conversion window mặc định (1 giờ) sẽ cho ra kết luận sai, và đề xuất window đúng kèm cách bạn xác minh nó bằng median time-to-convert.
Tóm tắt
Funnel analysis là công cụ nền tảng giúp Growth PM trả lời câu hỏi đắt giá nhất: người dùng rời đi ở đâu và vì sao. Một phễu tốt tiết lộ ba tín hiệu — drop-off step (chặng rớt nhiều bất thường), time between steps (thời gian dài báo hiệu ma sát), và segment differences (nhóm nào hành xử khác). Để đọc đúng, hãy luôn dùng step-to-step conversion thay vì tỷ lệ tuyệt đối, đặt conversion window khớp hành vi thực, dùng median thay vì average cho thời gian, và không bao giờ dừng lại ở con số trung bình mà phải cắt lát. Cuối cùng, phễu không phải đích đến — nó là cỗ máy sinh giả thuyết. Mỗi drop-off bạn tìm ra là một giả thuyết chờ được kiểm chứng bằng thử nghiệm, và đó chính là vòng lặp khiến tăng trưởng diễn ra một cách có kỷ luật.