Bài 51 — Common Tracking Bugs + Debugging — Product Analytics Mixpanel and Amplitude

Mở đầu — vì sao bài này quan trọng

Có một sự thật phũ phàng mà bất kỳ Product Manager nào làm việc với analytics đủ lâu cũng sẽ va phải: dữ liệu sai còn nguy hiểm hơn không có dữ liệu. Khi bạn không có dữ liệu, bạn biết mình đang mù và sẽ cẩn thận. Nhưng khi bạn có một con số đẹp đẽ trên dashboard — funnel conversion 42%, retention D7 là 28% — bạn tin vào nó, ra quyết định dựa trên nó, thuyết trình cho CEO dựa trên nó. Nếu con số đó sai vì một lỗi tracking, cả một chuỗi quyết định phía sau đều sai theo. Đó là lý do vì sao debugging tracking không phải việc "của mấy bạn dev", mà là kỹ năng sống còn của PM làm analytics.

Trong các bài trước bạn đã học cách thiết kế event taxonomy (Bài 7), viết payload chuẩn (Bài 8) và triển khai tracking plan (Bài 30). Bài này khác hẳn: chúng ta không nói về việc thiết kế đúng, mà về việc chuyện gì xảy ra khi mọi thứ đã chạy nhưng số liệu vẫn "có mùi". Bạn sẽ học cách nhận diện các lớp lỗi tracking phổ biến nhất, cách dò tìm nguyên nhân gốc, và một quy trình debug có hệ thống để không phải đoán mò. Đây là phần rất thực tế — thứ mà ở Việt Nam nhiều team học được sau khi đã trả giá bằng vài tháng dữ liệu hỏng.

Khái niệm cốt lõi

Trước khi debug, bạn cần một bản đồ tư duy về nơi lỗi có thể phát sinh. Một event từ lúc người dùng hành động đến lúc hiện lên dashboard đi qua nhiều chặng: trigger (người dùng bấm nút) → handler (code bắt sự kiện) → SDK gọi track() → network request gửi lên server Mixpanel/Amplitude → ingestion (server nhận, xử lý) → hiển thị trên report. Lỗi có thể nằm ở bất kỳ chặng nào. Dưới đây là các nhóm lỗi phổ biến nhất theo kinh nghiệm thực chiến.

1. Event không bắn (Event not firing)

Đây là lỗi hay gặp nhất. Người dùng bấm nút "Thanh toán" nhưng event Checkout Started không xuất hiện. Nguyên nhân thường thuộc một trong các loại:

SDK chưa load xong: Code gọi mixpanel.track() chạy trước khi thư viện Mixpanel được tải, thường do đặt sai vị trí script hoặc do vấn đề bất đồng bộ. Sự kiện bị "nuốt" âm thầm.
Handler không gắn đúng: Nút được render lại (re-render) sau khi event listener đã gắn, nên click không kích hoạt gì. Rất phổ biến trong React/Vue khi component thay đổi.
Điều kiện chặn: Có if bao quanh lệnh track mà điều kiện không bao giờ đúng, hoặc return sớm.
Ad-blocker / trình chặn: Nhiều người dùng cài uBlock, Brave chặn domain của Mixpanel/Amplitude. Đây là lý do dữ liệu client-side luôn thiếu 10–25% so với thực tế.

2. Event bắn trùng (Double firing / duplicate events)

Ngược lại với trên: một hành động nhưng event được ghi 2–3 lần. Triệu chứng là conversion rate cao bất thường, DAU phình to. Nguyên nhân điển hình:

Handler bị gắn nhiều lần: Mỗi lần component re-render lại addEventListener mà không gỡ cái cũ, dẫn đến một click gọi handler N lần.
Trang được nạp lại logic tracking: Single Page App điều hướng qua lại khiến đoạn init chạy lặp.
Cả client và server cùng bắn: Team gắn tracking ở frontend rồi backend cũng gắn cho cùng một sự kiện mà không thống nhất.

3. Property sai (Wrong / missing / malformed properties)

Event bắn đúng số lượng nhưng thuộc tính bên trong sai. Đây là lớp lỗi âm thầm nhất vì tổng số event vẫn đúng, chỉ khi bạn breakdown theo property mới lộ ra:

Sai kiểu dữ liệu: price gửi lên là string "199000" thay vì number 199000, khiến bạn không thể tính tổng doanh thu.
Sai đơn vị: Chỗ gửi VND, chỗ gửi nghìn VND, chỗ quy đổi ra USD.
Property rỗng/null: plan_type bị undefined trên một luồng đăng ký nào đó.
Sai tên (naming drift): Sign Up và Signup và sign_up cùng tồn tại — thực chất là ba event khác nhau trong hệ thống.
Timezone: Timestamp gửi theo UTC nhưng team đọc theo giờ Việt Nam (UTC+7), làm lệch phân bố theo giờ và sai cả cohort theo ngày.

4. Lỗi định danh người dùng (Identity / aliasing issues)

Đây là lỗi khó nhất. Một người dùng bị đếm thành nhiều người, hoặc nhiều người gộp thành một, do gọi sai identify() / alias(). Hậu quả: retention và unique user hoàn toàn sai lệch. Ví dụ gọi alias() mỗi lần đăng nhập thay vì chỉ khi đăng ký, làm vỡ liên kết anonymous ID với user ID.

Tình huống thực tế

Ví dụ 1 — Sàn TMĐT "ShopViet" và cú double-firing đội conversion lên 1,8 lần

Một sàn thương mại điện tử tầm trung ở TP.HCM (gọi là ShopViet) chuyển frontend từ trang server-render sang React SPA. Sau đợt migrate, dashboard Amplitude báo funnel View Product → Add to Cart tăng vọt từ 18% lên 33% chỉ sau một tuần — trong khi doanh thu thực tế không nhúc nhích. PM ban đầu mừng rỡ, tưởng UX mới hiệu quả.

Khi đào sâu, họ dùng công cụ debug của Amplitude (Ingestion Debugger) và phát hiện mỗi lần bấm "Thêm vào giỏ", event Add to Cart bắn 2 lần, đôi khi 3 lần. Nguyên nhân: trong React, useEffect gắn tracking không có mảng dependency đúng, nên mỗi lần component re-render (do state thay đổi) lại đăng ký thêm một listener mới. Người dùng bấm một lần, nhưng có tới ba listener cùng chạy.

Bài học rút ra: khi một chỉ số nhảy vọt mà chỉ số kinh doanh tương ứng (doanh thu, đơn hàng) không đổi, gần như chắc chắn là lỗi tracking chứ không phải "phép màu sản phẩm". Luôn đối chiếu số analytics với nguồn sự thật độc lập (database đơn hàng, cổng thanh toán).

Ví dụ 2 — Fintech "PayFast" và property giá tiền kiểu string

Một startup ví điện tử giả định tên PayFast tracking event Transaction Completed với property amount. Trong Mixpanel, khi PM cố dựng report tổng giá trị giao dịch theo tuần thì con số ra bằng 0 hoặc báo lỗi không tính được. Lý do: dev gửi amount: "50000" dưới dạng chuỗi thay vì số, vì lấy trực tiếp từ input form mà quên ép kiểu.

Tệ hơn, có một luồng thanh toán qua QR gửi amount theo đơn vị đồng, còn luồng nạp tiền lại gửi theo nghìn đồng. Nên ngay cả sau khi sửa kiểu dữ liệu, tổng doanh thu vẫn sai lệch tới 1000 lần ở một số phân khúc. Họ phải chạy một đợt "data audit" đối chiếu 200 giao dịch mẫu giữa Mixpanel và database thật để tìm ra mọi điểm lệch đơn vị.

Bài học: chuẩn hóa kiểu dữ liệu và đơn vị ngay tại tầng gửi event, và ghi rõ trong tracking plan (ví dụ: "amount luôn là number, đơn vị VND, không phần thập phân"). Một dòng quy ước tiết kiệm hàng tuần điều tra.

Ví dụ 3 — App học tiếng Anh "EngGo" và người dùng bị nhân bản

EngGo, một app học ngôn ngữ giả định ở Hà Nội, thấy chỉ số MAU tăng đều nhưng retention D7 lại tụt thảm hại xuống dưới 5% — vô lý với một app học tập có thói quen hằng ngày. Khi điều tra, họ phát hiện mỗi lần người dùng mở app trên thiết bị mới hoặc sau khi xóa cache, hệ thống tạo một anonymous ID mới và không liên kết được với tài khoản cũ vì gọi identify() sai thời điểm.

Kết quả: một học viên thật bị đếm thành 3–4 "người dùng" khác nhau theo thời gian. MAU phồng lên giả tạo, còn retention vỡ vì hệ thống tưởng đó là người mới mỗi lần. Sau khi sửa logic identity — gọi identify() ngay sau đăng nhập và giữ nhất quán user ID xuyên suốt — MAU giảm 22% (về đúng thực tế) nhưng retention D7 nhảy lên 24%. Con số "xấu đi" nhưng là con số thật.

Bài học: lỗi identity không chỉ làm sai một chỉ số mà làm hỏng cả nhóm chỉ số liên quan đến người dùng duy nhất (unique users, retention, cohort). Đây là lỗi phải kiểm tra đầu tiên khi retention "có mùi".

Hướng dẫn từng bước

Đây là quy trình debug có hệ thống, đi từ gần nguồn nhất ra ngoài. Nguyên tắc vàng: debug theo đường đi của event, đừng nhảy cóc.

Bước 1 — Tái hiện và quan sát ở tầng trình duyệt. Mở DevTools của Chrome, vào tab Network, lọc theo domain của công cụ (ví dụ api.mixpanel.com hoặc api2.amplitude.com). Thực hiện hành động cần kiểm tra. Nếu bạn không thấy request nào bắn ra → lỗi thuộc nhóm "không firing". Nếu thấy nhiều request cho một hành động → nhóm "double firing".

Bước 2 — Kiểm tra nội dung payload. Bấm vào request, xem phần payload được gửi. Kiểm tra tên event có đúng chính tả, đúng casing không; các property có đủ, đúng kiểu, đúng đơn vị không. Đây là nơi bắt property sai.

Bước 3 — Dùng công cụ debug tích hợp. Mixpanel có Live View / Events hiển thị event thời gian thực; Amplitude có User Lookup và Ingestion Debugger. Bật debug mode của SDK (mixpanel.set_config({debug: true}) hoặc tương đương) để log ra console mỗi lần track. Đối chiếu những gì bạn gửi với những gì server nhận.

Bước 4 — Kiểm tra identity. Trong User Lookup, tìm chính tài khoản test của bạn. Xem có bao nhiêu distinct_id gắn với nó. Nếu một người test mà ra nhiều profile → lỗi identity.

Bước 5 — Đối chiếu với nguồn sự thật. Lấy một mẫu (ví dụ 50–100 sự kiện) và so với database backend hoặc log server. Tỷ lệ khớp bao nhiêu phần trăm? Chênh lệch có hệ thống (luôn thiếu) hay ngẫu nhiên?

Bước 6 — Cân nhắc server-side. Nếu client-side mất mát quá nhiều do ad-blocker (thường 10–25%), đây là lúc cân nhắc chuyển các event quan trọng như thanh toán sang server-side tracking (chủ đề Bài 35) để đảm bảo độ chính xác.

Bước 7 — Ghi lại và ngăn tái phát. Mỗi bug tìm được nên biến thành một quy tắc validation tự động hoặc một dòng trong tracking plan, để không ai lặp lại.

Lỗi thường gặp & mẹo

Debug trên production mà không tách môi trường. Luôn có một project/instance riêng cho staging. Dữ liệu test trộn vào production làm bẩn số liệu thật và khó tin tưởng dashboard.

Chỉ test happy path. Bug tracking hay ẩn ở các luồng phụ: thanh toán thất bại, đăng nhập bằng số điện thoại thay vì email, người dùng offline rồi online lại. Hãy test cả các nhánh này.

Quên ad-blocker khi so số. Đừng hoảng khi thấy analytics thấp hơn database ~15%. Đó thường là ad-blocker, không phải bug. Bug là khi chênh lệch bất thường (50%+) hoặc lệch có hệ thống theo một segment.

Không kiểm tra sau mỗi lần deploy. Mỗi lần đội frontend refactor, tracking có thể vỡ âm thầm. Đặt một "smoke test" cho các event quan trọng nhất chạy sau mỗi release.

Mẹo — dùng anomaly detection làm hệ thống báo động sớm. Cắm alert (Bài 42) để khi một event tăng/giảm đột ngột thì được cảnh báo. Đa số "bug tracking to" bắt đầu bằng một đường biểu đồ đứt gãy vào đúng ngày deploy.

Mẹo — kiểm tra timezone ngay từ đầu. Nếu phân bố sự kiện theo giờ có đỉnh vào 3–4 giờ sáng (giờ Việt Nam), rất có thể bạn đang đọc timestamp UTC. Lệch 7 tiếng chính là dấu hiệu.

Mẹo — dán nhãn phiên bản (library/SDK version) vào event. Khi bug xuất hiện, bạn biết ngay nó gắn với bản build nào, thu hẹp phạm vi điều tra rất nhanh.

Bài tập thực hành

Kiểm tra một funnel nghi ngờ. Chọn một funnel trong Mixpanel hoặc Amplitude mà bạn thấy con số "quá đẹp". Mở DevTools, tái hiện từng bước và xác minh mỗi event bắn đúng một lần với payload đúng. Ghi lại mọi điểm lệch.

Săn double-firing. Vào một trang của sản phẩm bạn đang làm, thực hiện một hành động chính (thêm giỏ hàng, gửi form). Đếm số request bắn ra trong tab Network. Nếu nhiều hơn một, hãy truy nguyên nguyên nhân trong code.

Audit property. Lấy một event quan trọng và liệt kê toàn bộ property của nó. Với mỗi property, ghi: kiểu dữ liệu mong đợi, đơn vị, giá trị mẫu thực tế. So với những gì đang thực sự được gửi. Bạn tìm thấy bao nhiêu điểm không khớp?

Kiểm tra identity. Tạo một tài khoản test mới, đăng nhập/đăng xuất vài lần, mở trên hai thiết bị. Sau đó tra trong User Lookup xem hệ thống ghi nhận bạn là một hay nhiều người dùng. Viết lại logic identify nếu bị nhân bản.

Viết checklist smoke-test. Soạn danh sách 5–7 event quan trọng nhất của sản phẩm và các bước kiểm tra nhanh cho mỗi cái, để chạy sau mỗi lần release.

Tóm tắt

Debugging tracking là kỹ năng bảo vệ chất lượng dữ liệu — nền móng cho mọi quyết định dựa trên số của một PM. Bốn nhóm lỗi phổ biến nhất cần thuộc lòng: event không bắn (SDK chưa load, handler sai, ad-blocker), event bắn trùng (handler gắn nhiều lần, client và server cùng bắn), property sai (sai kiểu, sai đơn vị, sai tên, lệch timezone), và lỗi identity (một người thành nhiều, hoặc ngược lại). Ba tình huống thực tế — ShopViet đội conversion vì double-firing, PayFast sai doanh thu vì property kiểu string và lệch đơn vị, EngGo vỡ retention vì identity — cho thấy một điều chung: khi số analytics mâu thuẫn với thực tế kinh doanh, hãy nghi ngờ tracking trước tiên.

Quy trình debug hiệu quả là đi theo đường đi của event: từ trình duyệt (Network tab) → payload → công cụ debug tích hợp → identity → đối chiếu nguồn sự thật → cân nhắc server-side. Và quan trọng nhất: mỗi bug tìm ra phải biến thành một quy tắc phòng ngừa. Dữ liệu sạch không phải trạng thái đạt được một lần, mà là kỷ luật duy trì liên tục sau mỗi lần deploy.