Công cụ product analytics

Công cụ product analytics là gì?

Đó là nơi các event của sản phẩm đi tới và trở thành số. Trên thị trường có nhiều công cụ — PostHog, GA4, Mixpanel, Amplitude là những cái tên hay gặp nhất. Giao diện và cách gọi khác nhau, nhưng bốn khả năng bên dưới thì công cụ nào cũng có, và một khi hiểu bốn khả năng đó bạn dùng được công cụ nào cũng vậy.

Hệ quả quan trọng nhất với BA/PO: công cụ không tự sinh ra dữ liệu. Nó chỉ có đúng những gì đã được track. Một công cụ mạnh trên một kho event nghèo vẫn không trả lời được câu hỏi của bạn — và ngược lại, phần lớn câu hỏi hằng ngày của một BA có thể tự trả lời trong mười phút, không cần nhờ ai, nếu event đã có sẵn.

Baseline — bạn hiểu

• Dữ liệu hành vi nằm trong một công cụ analytics (PostHog, GA4, Mixpanel — events, funnels, dashboards, session recording, experiments) và nó chỉ có những gì đã được track.
• Bốn khả năng đó trả lời bốn câu khác nhau; không lớp nào thay thế được lớp nào.
• Một con số trích ra khỏi công cụ chỉ có nghĩa khi đi kèm khoảng thời gian, bộ lọc và đơn vị đếm.

Working — bạn làm được

• Tự phục vụ: dựng funnel và biểu đồ cho khu vực của mình mà không phải nhờ dev hay data analyst.
• Xem session recording đằng sau con số, có phương pháp và đúng nhóm người dùng.
• Set up và đọc một experiment cơ bản, gồm cả việc chọn trước ngày dừng.

Cơ chế hoạt động

Ví dụ theo cấp độ

Cơ bản — Mở công cụ, tìm một event, đọc một con số

Tình huống: đội bạn đang dùng một công cụ product analytics. Bạn muốn biết nút "Thêm vào giỏ" được dùng bao nhiêu lần trong 7 ngày qua, và muốn tự làm thay vì nhắn cho dev.

Năm thao tác, đúng cho công cụ nào cũng vậy:

1. Mở danh mục event (thường nằm ở mục có tên Events, Data management hoặc Lexicon). Đây là danh sách mọi event công cụ đang nhận được. Không thấy add_to_cart ở đây thì dừng lại: nó chưa được track, và không có biểu đồ nào cứu được.
2. Tạo một biểu đồ mới và chọn event add_to_cart.
3. Đặt khoảng thời gian: 7 ngày gần nhất. Kiểm tra luôn múi giờ mà công cụ đang dùng — nhiều công cụ mặc định theo UTC, lệch 7 tiếng so với giờ Việt Nam.
4. Chọn đơn vị đếm: số lần (event count) hay số người (unique users). Đây là chỗ hai người đọc cùng một biểu đồ ra hai kết luận khác nhau.
5. Ghi lại con số kèm bối cảnh — bước này quan trọng ngang bốn bước trên.

Vì sao bước 4 quyết định: 1.240 lượt add_to_cart có thể là 1.240 người mỗi người thêm một sản phẩm, cũng có thể là 310 người mỗi người thêm bốn lần. Hai câu chuyện hoàn toàn khác nhau, cùng một con số hiển thị.

Cách ghi một con số để nó dùng được trong cuộc họp (copy được):

add_to_cart: 1.240 lượt / 812 người
Khoảng thời gian: 05/08 – 11/08 (giờ Việt Nam)
Bộ lọc: không có — toàn bộ nền tảng, cả web và app
Nguồn: biểu đồ "Add to cart 7 ngày", công cụ analytics của đội
Lấy lúc: 12/08 09:20

Học được: một con số không có ba thông tin đi kèm — khoảng thời gian, bộ lọc, đơn vị đếm — thì không so sánh được với bất kỳ con số nào khác, kể cả với chính nó ở tuần sau. Phần lớn tranh cãi "số của anh khác số của tôi" trong các buổi họp là do thiếu đúng ba dòng này, không phải do công cụ sai.

Trung bình — Tự dựng funnel 3 bước và đọc chỗ rơi nhiều nhất

Tình huống: bạn phụ trách luồng thanh toán và muốn biết khách rơi ở đâu, mà không phải chờ ai dựng báo cáo hộ.

Định nghĩa funnel — viết ra trước khi động vào công cụ:

Funnel: Thanh toán (web + app)
  Bước 1: checkout_started
  Bước 2: payment_method_selected
  Bước 3: order_placed
Cửa sổ hoàn tất: 1 giờ kể từ bước 1
Khoảng thời gian: 30 ngày gần nhất
Đếm theo: số người (unique users), không phải số lần

Kết quả bạn đọc được:

Ba điều phải đọc cho đúng:

1. Chỗ rơi lớn nhất nằm giữa bước 1 và bước 2: mất 5.900 người. Đoạn 2 sang 3 chỉ mất 400. Mọi nỗ lực tối ưu đoạn 2 sang 3 giỏi lắm mang lại thêm vài trăm người; sửa đúng chỗ 59% mới có ý nghĩa. Đây là toàn bộ giá trị của funnel: nó nói cho bạn biết nên tiêu công sức ở đâu.
2. "Cửa sổ hoàn tất" là thứ hay bị bỏ qua nhất. Đặt 1 giờ nghĩa là ai bắt đầu hôm nay và quay lại đặt hàng vào ngày mai đều bị đếm là đã rơi. Với hàng giá trị cao, khách thường so sánh vài ngày — cửa sổ 1 giờ vẽ ra bức tranh bi quan hơn thực tế. Đổi cửa sổ thành 7 ngày rồi so hai kết quả: phần chênh lệch chính là nhóm "khách suy nghĩ lâu", và cách xử lý cho nhóm đó khác hẳn (nhắc lại giỏ hàng, chứ không phải sửa nút).
3. Funnel không nói vì sao. Nó chỉ nói ở đâu. Mọi câu "chắc là do…" nói ra ở bước này đều là phỏng đoán.

Hai lát cắt gần như luôn đáng làm, mỗi cái mất thêm hai phút:

• Cắt theo nền tảng (web / iOS / Android). Rơi 59% ở web nhưng chỉ 30% ở app là một manh mối cụ thể hơn nhiều so với con số gộp.
• Cắt theo khách mua lần đầu và khách cũ. Khách cũ thường có sẵn địa chỉ và cách thanh toán, nên tỷ lệ rơi của họ mà cao thì đó là dấu hiệu của lỗi kỹ thuật chứ không phải của trải nghiệm.

Học được: funnel là công cụ khoanh vùng, không phải công cụ giải thích. Việc của bạn ở bước này là thu hẹp từ "luồng thanh toán kém" xuống "khách web, mua lần đầu, rơi ở đoạn từ bắt đầu thanh toán tới chọn cách thanh toán". Đó là câu duy nhất đủ hẹp để đi tiếp được.

Nâng cao — Từ "59% rơi ở bước 2" tới một experiment đọc được

Tình huống: funnel cho thấy 59% khách web rơi giữa bước 1 và bước 2. Bạn cần biết vì sao, rồi chứng minh cách sửa của mình có tác dụng thật.

Bước 1 — Xem session recording có phương pháp. Đừng mở ngẫu nhiên rồi xem vài phiên. Lọc đúng nhóm: có event checkout_started, không có payment_method_selected, nền tảng web, trong 7 ngày qua. Xem 10 phiên và ghi lại theo một bảng đơn giản — khách dừng ở chỗ nào trên màn hình, có cuộn lên cuộn xuống tìm gì không, có bấm vào thứ gì mà không có phản hồi không, dừng bao lâu trước khi thoát. Mười phiên đủ để một khuôn mẫu lộ ra; ba phiên thì chưa, năm mươi phiên thì lãng phí.

Điều bạn thấy: 7 trong 10 phiên cuộn lên cuộn xuống quanh dòng chữ "Phí vận chuyển: tính ở bước sau", dừng khoảng 20 giây rồi thoát.

Bước 2 — Viết giả thuyết thành một câu kiểm chứng được (copy được):

Giả thuyết: khách rời luồng thanh toán vì chưa biết tổng số tiền phải trả.
Thay đổi:  hiện phí vận chuyển ước tính ngay tại bước 1, dựa trên địa chỉ mặc định.
Dự đoán:   tỷ lệ đi từ bước 1 sang bước 2 tăng từ 41% lên ít nhất 46%.
Chỉ số chính:    tỷ lệ người đi từ checkout_started tới payment_method_selected.
Chỉ số bảo vệ:   tỷ lệ order_placed trên tổng số người vào luồng — không được giảm.
Đối tượng:       chỉ khách web, chia 50/50.
Ngày dừng:       01/09 — 20 ngày, là thời gian cần để mỗi nhánh đủ 2.000 người.
Người quyết định: [tên], đọc kết quả ngày 02/09.

Ngày dừng phải tính ra, không được ước chừng. Funnel ở phần trên cho 10.000 người vào luồng trong 30 ngày, tức khoảng 330 người mỗi ngày. Thử nghiệm này chỉ chạy trên khách web (khoảng 60% lưu lượng), rồi còn chia đôi hai nhánh:

330 người/ngày  x  60% khách web   =  khoảng 200 người/ngày vào thử nghiệm
200  /  2 nhánh                    =  khoảng 100 người mỗi nhánh mỗi ngày
2.000 người mỗi nhánh              =  khoảng 20 ngày, không phải 14

Mốc 14 ngày chỉ là mức sàn để phủ đủ cả ngày thường lẫn cuối tuần. Ở lưu lượng thật của luồng này, điều kiện quyết định là cỡ mẫu, và nó đẩy ngày dừng thêm gần một tuần. Biết điều đó trước khi bật là cách duy nhất để không bị hỏi "xong chưa" vào ngày thứ mười lăm — và cách duy nhất để trả lời câu đó mà không phải bịa.

Vì sao phải có chỉ số bảo vệ: hiện phí ship sớm hoàn toàn có thể khiến một số khách bỏ ngay từ đầu vì thấy tổng tiền cao. Nếu tỷ lệ bước 1 sang 2 tăng mà số đơn hàng cuối cùng lại giảm thì thay đổi này có hại, dù chỉ số chính rất đẹp. Đây là phần người mới hầu như luôn quên.

Bước 3 — Cái bẫy, gọi tên thẳng: đừng đọc kết quả experiment trước ngày dừng đã định. Sang ngày thứ hai, nhánh mới đang dẫn 47% so với 41% và cả phòng muốn chốt ngay. Con số ở ngày thứ hai gần như luôn dao động rất mạnh vì mẫu còn nhỏ; và nếu bạn cho phép mình dừng bất cứ lúc nào thì bạn sẽ luôn dừng đúng vào lúc nó đang đẹp.

Cái giá: bạn triển khai một thay đổi thực ra không có tác dụng, ăn mừng một lần, rồi ba tháng sau không ai hiểu vì sao tỷ lệ chung không nhúc nhích dù đã "cải thiện" năm lần. Tệ hơn cả con số: đội của bạn học được rằng thay đổi nào cũng thắng, và mất hẳn khả năng phân biệt một cải tiến thật với dao động ngẫu nhiên. Cái mất đó không có trong báo cáo nào.

Bốn dòng viết ra trước khi bật experiment, không phải sau:

• "Chạy tối thiểu 14 ngày để phủ đủ cả ngày thường lẫn cuối tuần, và tối thiểu 2.000 người mỗi nhánh. Ở lưu lượng hiện tại, điều kiện thứ hai mới là điều kiện quyết định: nó đẩy ngày dừng tới 01/09."
• "Không ra quyết định trước khi đạt cả hai mốc trên, kể cả khi chênh lệch trông rất lớn."
• "Ngày kết thúc và người ra quyết định được ghi vào ticket ngay lúc bật."
• "Chỉ có một chỉ số chính. Nếu phải nhìn năm chỉ số để tìm xem cái nào thắng thì đó không còn là kiểm chứng nữa."

Học được: bốn lớp trả lời bốn câu khác nhau — biểu đồ nói bao nhiêu, funnel nói rơi ở đâu, session recording nói vì sao, experiment nói sửa như vậy có thật sự tốt hơn không. Dùng nhầm lớp là nguồn gốc của hầu hết quyết định sai mang danh dữ liệu: đọc funnel rồi tự nghĩ ra lý do, hoặc xem ba session recording rồi coi đó là bằng chứng.

Áp dụng khi viết spec

Trước khi mang bất kỳ con số nào vào một cuộc họp hoặc một ticket, trả lời được bốn câu:

1. Con số này lấy từ event nào, trong khoảng thời gian nào, theo múi giờ nào?
2. Đang đếm số lần hay số người, và có bộ lọc nào đang bật?
3. Nó trả lời câu "bao nhiêu", "ở đâu" hay "vì sao"? Nếu bạn đang dùng nó để trả lời câu khác thì dừng lại.
4. Nếu đây là kết quả một thay đổi: chỉ số chính và ngày dừng đã được chọn trước khi bật chưa?

Câu hỏi nên hỏi dev

• "Đội mình đang dùng công cụ analytics nào, và tôi được cấp quyền xem ở đâu?"
• "Công cụ đang hiển thị theo múi giờ nào?"
• "Session recording có bị che các trường nhạy cảm không, và lưu được bao lâu?"
• "Chia nhánh experiment dựa trên gì — người dùng hay phiên? Một người quay lại có luôn rơi vào cùng một nhánh không?"
• "Có bao nhiêu experiment đang chạy cùng lúc trên cùng một màn hình?"
• "Người chặn quảng cáo hoặc trình duyệt chặn tracking làm mất bao nhiêu phần trăm event?"

Sai lầm thường gặp

• Trích một con số ra khỏi công cụ mà không ghi khoảng thời gian, bộ lọc và đơn vị đếm.
• Nhầm số lần với số người, rồi báo cáo con số lớn hơn.
• Để nguyên cửa sổ hoàn tất mặc định của funnel, rồi kết luận sai về khách suy nghĩ lâu.
• Xem ba session recording rồi coi đó là bằng chứng cho cả tập người dùng.
• Đọc kết quả experiment mỗi ngày và dừng ngay khi thấy đẹp.
• Không có chỉ số bảo vệ, nên triển khai một thay đổi làm tăng bước giữa mà giảm đơn hàng.
• Đổ lỗi cho công cụ khi không tìm thấy số, trong khi vấn đề là event chưa từng được track.
• Dựng dashboard hai mươi biểu đồ mà không biểu đồ nào dẫn tới một quyết định cụ thể.

Definition of done — dấu hiệu bạn đã đạt

• Bạn tự dựng được một funnel cho khu vực của mình trong mười phút, không cần nhờ ai.
• Mọi con số bạn đưa vào họp đều đi kèm khoảng thời gian, bộ lọc và đơn vị đếm.
• Bạn phân biệt được lúc nào cần funnel, lúc nào cần session recording, lúc nào phải chạy experiment.
• Mọi experiment bạn tham gia đều có chỉ số chính, chỉ số bảo vệ và ngày dừng được ghi trước lúc bật.

Đi sâu hơn

• Funnel & cohort analysis — đọc sâu hơn phần phễu và phần nhóm người dùng theo thời gian.
• Feature flag & A/B testing — thiết kế rollout và experiment cho đúng, ngoài phần đọc kết quả.
• Event tracking — nguồn dữ liệu của toàn bộ công cụ này; thiếu ở đó thì ở đây không có gì.