Mở đầu — vì sao bài này quan trọng
Nếu bạn đã đi qua 49 bài trước, bạn đã nắm khá vững cách đo lường một sản phẩm số "truyền thống": funnel, retention, cohort, DAU/MAU, doanh thu. Nhưng khi sản phẩm của bạn có một chatbot, một tính năng "hỏi AI trả lời", một trợ lý viết nội dung hay một công cụ tóm tắt tài liệu — thì bộ đo lường quen thuộc bỗng thiếu hụt nghiêm trọng. Bạn sẽ gặp những câu hỏi mà Mixpanel hay Amplitude "mặc định" không trả lời được: Mỗi câu trả lời của AI tốn bao nhiêu tiền? Người dùng có hài lòng với câu trả lời đó không? Model có "bịa" (hallucinate) không? Trả lời chậm bao lâu thì người dùng bỏ đi?
Đây là vấn đề rất thực tế với thị trường Việt Nam năm 2026. Hàng loạt sản phẩm nội địa đã gắn LLM vào lõi: trợ lý ảo của ngân hàng, chatbot chăm sóc khách hàng của sàn thương mại điện tử, công cụ soạn thảo hợp đồng, gia sư AI cho học sinh. Điểm chung là chi phí vận hành không còn cố định như phần mềm thường — mỗi lần người dùng bấm "gửi", bạn trả một khoản tiền cho OpenAI, Anthropic, Google hoặc cho GPU tự host. Nếu PM không đo được chi phí và chất lượng ở cấp độ từng truy vấn, doanh nghiệp có thể "cháy túi" mà không hiểu vì sao, hoặc để sản phẩm mất niềm tin vì trả lời sai mà không ai phát hiện.
Bài này tập trung đúng vào những nhu cầu đo lường đặc thù của sản phẩm AI/LLM — phần mà Mixpanel, Amplitude cần được mở rộng bằng cách thiết kế event và property riêng. Chúng ta không nhắc lại funnel hay retention cơ bản; thay vào đó, tôi sẽ chỉ bạn cách "gắn thêm" bốn trục đo mới vào bộ công cụ analytics bạn đã có.
Khái niệm cốt lõi
Sản phẩm LLM khác sản phẩm thường ở chỗ nó không xác định (non-deterministic) và có chi phí biến đổi theo lượng dùng. Cùng một câu hỏi, hai lần hỏi có thể ra hai câu trả lời khác nhau; và mỗi câu trả lời tiêu tốn một lượng token khác nhau. Vì vậy, ngoài các event hành vi thông thường, bạn cần bổ sung một lớp đo lường riêng cho "chất lượng và chi phí của mỗi lượt tương tác AI".
Bốn trục đo đặc thù
1. Chi phí trên mỗi truy vấn (per-query cost). Đây là trục quan trọng nhất về mặt tài chính. LLM tính tiền theo token: token đầu vào (prompt) và token đầu ra (completion) có đơn giá khác nhau. Bạn cần ghi lại input_tokens, output_tokens, model và tính ra cost_usd cho mỗi lượt gọi. Có được số này, bạn mới trả lời được: ARPU đang dương hay âm sau khi trừ chi phí AI? Nhóm người dùng nào "đốt" tiền nhiều nhất?
2. Độ trễ (latency). Với sản phẩm AI, tốc độ phản hồi là trải nghiệm cốt lõi. Cần phân biệt hai chỉ số: time to first token (TTFT) — thời gian đến khi chữ đầu tiên hiện ra (quyết định cảm giác "AI có đang phản hồi không"), và total latency — tổng thời gian đến khi trả lời xong. Người dùng chịu đựng được TTFT dưới ~1 giây; quá lâu họ nghĩ hệ thống treo và bỏ đi.
3. Tỷ lệ ảo giác / sai lệch (hallucination / error rate). LLM đôi khi "bịa" thông tin nghe rất thuyết phục nhưng sai. Bạn không đo được tuyệt đối, nhưng có thể ước lượng qua nhiều tín hiệu: người dùng bấm "câu trả lời này sai", người dùng hỏi lại cùng nội dung, model trả về "tôi không biết", hoặc một bước kiểm định tự động (LLM-as-judge, kiểm tra nguồn trích dẫn). Mỗi tín hiệu là một property bạn gắn vào event.
4. Mức hài lòng trên mỗi câu trả lời (satisfaction per response). Khác với NPS đo cả sản phẩm, ở đây bạn đo từng phản hồi: nút thumbs up/down, sao đánh giá, hay tín hiệu ngầm như "người dùng copy câu trả lời", "hỏi tiếp câu liên quan" (tốt) so với "hỏi lại y hệt", "rời trang ngay" (xấu).
Mô hình event nên có
Trục xương sống là một event ai_response_generated phát ra mỗi khi hệ thống tạo xong một câu trả lời, kèm bộ property giàu thông tin:
ai_response_generated:
conversation_id, message_id
model (vd: "gpt-4o", "claude-sonnet", "gemini-flash")
feature (vd: "chat_ho_tro", "tom_tat_tai_lieu")
input_tokens, output_tokens
cost_usd
ttft_ms, total_latency_ms
retrieval_used (có dùng RAG không), sources_count
status ("success" | "refused" | "error" | "timeout")
Và một event phản hồi tách riêng vì nó xảy ra sau, do người dùng chủ động:
ai_response_feedback:
message_id, rating ("up" | "down"), reason, feature
Việc dùng chung message_id cho phép bạn nối hai event lại: một câu trả lời tốn 0,03 USD, trễ 4 giây, dùng model gpt-4o, và bị người dùng bấm thumbs-down vì "sai thông tin". Chính khả năng ghép này biến dữ liệu rời rạc thành insight hành động được.
Tình huống thực tế
Ví dụ 1 — Chatbot hỗ trợ của một sàn TMĐT (giả định: "ShopViet")
ShopViet ra mắt chatbot AI trả lời câu hỏi đơn hàng, chính sách đổi trả. Sau một tháng, hóa đơn OpenAI lên tới 9.000 USD — cao gấp ba dự toán. PM dựng một bảng phân tích trên Amplitude, group event ai_response_generated theo feature và tổng cost_usd. Phát hiện: 62% chi phí đến từ tính năng "tra cứu vận đơn", nơi họ nhét toàn bộ lịch sử đơn hàng (hàng nghìn token) vào mỗi prompt, trong khi người dùng chỉ cần trạng thái đơn mới nhất.
Họ sửa lại: chỉ đưa 3 đơn gần nhất vào context, và chuyển các câu hỏi đơn giản sang model rẻ hơn (gemini-flash) dựa trên một bước phân loại. Kết quả: chi phí trung bình mỗi truy vấn giảm từ 0,021 USD xuống 0,006 USD, tổng hóa đơn tháng sau còn 3.100 USD, trong khi tỷ lệ thumbs-up giữ nguyên 88%. Bài học: không đo per-query cost theo feature thì bạn không bao giờ biết tiền "chảy" đi đâu — và tối ưu mù quáng có thể làm hỏng trải nghiệm.
Ví dụ 2 — Gia sư AI cho học sinh (giả định: "HocTot AI")
HocTot AI cho học sinh cấp 2 hỏi bài. Đội ngũ tự hào retention tốt, nhưng giáo viên phản ánh AI "giải sai một số bài toán". Vấn đề: họ không có cách đo hallucination. PM thêm ba tín hiệu: nút "Đáp án này sai" (feedback tường minh), phát hiện học sinh gửi lại cùng đề bài trong vòng 2 phút (tín hiệu ngầm về không hài lòng), và một job chạy đêm dùng LLM-as-judge chấm lại 500 lời giải mẫu mỗi ngày, ghi judge_verdict vào event.
Kết quả cho thấy tỷ lệ sai ở môn Toán là 14% — cao đáng báo động — trong khi môn Văn chỉ 3%. Nhờ chia theo subject, họ định tuyến câu hỏi Toán qua model mạnh hơn kèm bước "tự kiểm tra lại phép tính", kéo tỷ lệ sai xuống 5%. Tỷ lệ học sinh gửi lại cùng đề bài giảm 40%. Bài học: hallucination là con số bạn phải chủ động dựng tín hiệu để đo; không tự nhiên có sẵn trong analytics, và nó phải được cắt lát theo ngữ cảnh (môn học, loại câu hỏi) mới hành động được.
Ví dụ 3 — Trợ lý soạn văn bản trong app ngân hàng (giả định khu vực Đông Nam Á)
Một ngân hàng số triển khai trợ lý AI tóm tắt điều khoản hợp đồng cho nhân viên. Latency trung bình 6 giây, họ nghĩ "chấp nhận được". Nhưng adoption thấp. PM đo TTFT riêng và phát hiện median TTFT là 3,8 giây — người dùng nhìn màn hình trắng gần 4 giây trước khi thấy chữ đầu tiên, nhiều người bỏ giữa chừng (status = "abandoned" khi họ đóng panel trước khi stream xong).
Đội kỹ thuật bật streaming (trả từng chữ thay vì chờ trọn câu) và thêm bước rút gọn tài liệu trước khi gọi model. TTFT xuống 0,9 giây. Tỷ lệ hoàn thành đọc câu trả lời tăng từ 51% lên 79%, và số lượt dùng hàng tuần tăng gấp đôi trong một tháng. Bài học: với sản phẩm AI, đo tổng latency thôi là chưa đủ — TTFT mới là thứ quyết định người dùng có "ở lại" hay không.
Hướng dẫn từng bước
Bước 1 — Xác định các "AI touchpoint" trong sản phẩm. Liệt kê mọi nơi LLM được gọi: chat, tóm tắt, gợi ý, tìm kiếm ngữ nghĩa. Mỗi điểm sẽ có một giá trị feature riêng để về sau cắt lát dữ liệu.
Bước 2 — Thiết kế event ai_response_generated với đầy đủ property. Bám sát mô hình ở trên. Lưu ý ghi cả model và model_version vì bạn sẽ đổi model theo thời gian, và cần so sánh chất lượng/chi phí giữa các phiên bản.
Bước 3 — Tính và ghi cost_usd ở server-side. Đừng tính chi phí ở client (dễ sai và có thể bị chỉnh sửa). Ở backend, sau khi nhận response từ API LLM, đọc usage.input_tokens và usage.output_tokens, nhân với bảng đơn giá theo model, ghi ra số USD. Gửi event qua server-side tracking để đảm bảo không mất dữ liệu.
Bước 4 — Đo latency ở hai mốc. Ghi timestamp lúc gọi API, lúc nhận token đầu tiên (TTFT), và lúc hoàn tất. Với sản phẩm streaming, TTFT là bắt buộc.
Bước 5 — Dựng cơ chế thu thập tín hiệu chất lượng. Tối thiểu có nút thumbs up/down gắn với message_id. Bổ sung tín hiệu ngầm: copy câu trả lời, hỏi lại trùng lặp, regenerate (bấm "tạo lại"). Nếu có ngân sách, thêm job LLM-as-judge chấm mẫu định kỳ.
Bước 6 — Dựng dashboard chuyên biệt cho AI. Gồm: chi phí theo ngày và theo feature, cost per active user, median/p95 TTFT và total latency, tỷ lệ thumbs-up, tỷ lệ regenerate, tỷ lệ status = error/refused. Chia mọi biểu đồ theo model và feature.
Bước 7 — Nối chất lượng với hành vi kinh doanh. Câu hỏi vàng: người dùng bấm thumbs-down có retention thấp hơn không? Feature AI nào tương quan với chuyển đổi trả phí? Đây là lúc trục AI gặp lại các trục analytics quen thuộc của bạn.
Lỗi thường gặp & mẹo
Lỗi 1 — Chỉ đo hành vi, quên đo chi phí. Rất nhiều đội gắn event "user_sent_message" nhưng không ghi token và cost. Đến khi hóa đơn về mới hốt hoảng. Ghi cost_usd ngay từ ngày đầu.
Lỗi 2 — Nhét toàn bộ nội dung prompt/response vào property. Cám dỗ lưu cả câu hỏi và câu trả lời dạng text dài vào Mixpanel/Amplitude. Điều này vừa đội chi phí lưu trữ, vừa vi phạm quyền riêng tư (nội dung người dùng có thể chứa thông tin nhạy cảm). Chỉ lưu metadata (độ dài, model, cost, rating); nếu cần lưu nội dung để phân tích, dùng hệ thống LLM observability riêng có kiểm soát truy cập, và tuân thủ PDPL (xem Bài 28).
Lỗi 3 — Gộp chung mọi model, mọi feature vào một con số. Trung bình cộng che giấu vấn đề. Luôn cắt lát theo model và feature.
Lỗi 4 — Coi thumbs-up là chân lý. Đa số người dùng không bấm gì. Tỷ lệ phản hồi tường minh thường dưới 5%. Kết hợp tín hiệu ngầm (regenerate, hỏi lại, thời gian đọc) để có bức tranh đầy đủ.
Mẹo — Chuẩn hóa "regenerate rate" và "refusal rate" thành hai chỉ số sức khỏe. Regenerate cao = câu trả lời đầu tiên không đủ tốt. Refusal cao (model từ chối trả lời) = prompt hoặc guardrail đang quá chặt, làm hỏng trải nghiệm.
Mẹo — Đặt ngân sách chi phí theo người dùng và cảnh báo. Dựng alert khi cost per user vượt ngưỡng, phát hiện sớm cả lạm dụng (abuse) lẫn rò rỉ chi phí do bug.
Bài tập thực hành
- Thiết kế event. Với một sản phẩm AI bạn chọn (chatbot, gia sư, trợ lý viết…), viết ra đặc tả đầy đủ cho event
ai_response_generatedvàai_response_feedback: liệt kê mọi property, kiểu dữ liệu, và ví dụ giá trị. Chỉ rõ property nào lấy ở client, property nào ở server.
- Tính chi phí. Cho model đơn giá 5 USD / 1 triệu token đầu vào và 15 USD / 1 triệu token đầu ra. Một truy vấn dùng 1.200 token đầu vào và 400 token đầu ra. Tính
cost_usd. Nếu sản phẩm có 50.000 truy vấn tương tự mỗi ngày, chi phí AI hàng tháng là bao nhiêu? Đề xuất hai cách giảm.
- Dựng dashboard giả lập. Phác thảo (trên giấy hoặc trong tool) một dashboard AI gồm tối thiểu 6 biểu đồ, mỗi biểu đồ ghi rõ: event nguồn, phép đo, và cách chia lát. Giải thích mỗi biểu đồ giúp trả lời câu hỏi kinh doanh nào.
- Đo hallucination. Liệt kê 4 tín hiệu (2 tường minh, 2 ngầm) bạn sẽ dùng để ước lượng tỷ lệ sai của một AI gia sư môn Toán, và mô tả cách gắn mỗi tín hiệu vào event.
Tóm tắt
Sản phẩm AI/LLM đặt ra bốn nhu cầu đo lường mà analytics truyền thống không tự có: chi phí trên mỗi truy vấn, độ trễ (đặc biệt TTFT), tỷ lệ ảo giác/sai lệch, và mức hài lòng trên từng câu trả lời. Cách giải quyết không phải là bỏ Mixpanel/Amplitude, mà là mở rộng chúng bằng một lớp event chuyên biệt — xương sống là ai_response_generated giàu metadata (model, token, cost, latency, status) cộng với ai_response_feedback nối qua message_id.
Ba tình huống thực tế cho thấy giá trị: ShopViet cắt hai phần ba chi phí nhờ đo cost theo feature; HocTot AI giảm sai môn Toán nhờ chủ động dựng tín hiệu hallucination; trợ lý ngân hàng tăng gấp đôi adoption nhờ đo và tối ưu TTFT. Nguyên tắc cốt lõi: ghi chi phí và chất lượng ngay từ ngày đầu, luôn cắt lát theo model và feature, kết hợp tín hiệu tường minh với tín hiệu ngầm, tôn trọng quyền riêng tư khi lưu nội dung, và cuối cùng — nối trục AI trở lại với retention và doanh thu để biến dữ liệu thành quyết định sản phẩm.