Vì sao event taxonomy và tracking plan quan trọng
Product analytics bắt đầu và kết thúc ở dữ liệu. Nếu dữ liệu bẩn, mọi biểu đồ funnel, retention, cohort bạn vẽ ra sau này đều là ảo tưởng đẹp đẽ. Event taxonomy (bộ từ vựng sự kiện) và tracking plan (kế hoạch gắn tracking) chính là nền móng quyết định bạn có tin được số của mình hay không.
Cái giá của việc thiếu kỹ năng này rất đắt. Một startup fintech ở TP.HCM từng có tới ba tên sự kiện cùng mô tả một hành động: click_pay, PaymentClicked, và btn_thanh_toan. Ba team gắn tracking khác nhau. Khi CEO hỏi tỷ lệ chuyển đổi thanh toán, ba người trả lời ba con số. Họ mất bốn tuần chỉ để thống nhất lại định nghĩa, trong khi đối thủ đã chạy xong hai vòng thử nghiệm. Dữ liệu sai không chỉ làm chậm, nó khiến PM ra quyết định sai với sự tự tin cao — điều nguy hiểm nhất.
Ngược lại, một tracking plan tốt biến analytics thành lợi thế cạnh tranh: câu hỏi mới trả lời trong vài phút, không cần chờ engineer gắn thêm sự kiện.
Bức tranh lớn
Ba khối kiến thức cốt lõi: sự kiện (event) mô tả một hành động, thuộc tính (property) mô tả ngữ cảnh của hành động đó, và thực thể người dùng (identity) gắn hành động với một con người. Một tracking plan là tài liệu sống liên kết ba khối này với câu hỏi kinh doanh.
graph TD A[Cau hoi kinh doanh] --> B[Event can do] B --> C[Ten su kien chuan hoa] C --> D[Thuoc tinh su kien] C --> E[Thuoc tinh nguoi dung] D --> F[Tracking plan] E --> F F --> G[Engineer gan code] G --> H[Kiem tra QA] H --> I[Du lieu tin cay]
Nguyên tắc đặt tên: dùng cấu trúc Object-Action, ví dụ Order Completed, Video Started, Course Enrolled. Object là danh từ, Action là động từ ở thì quá khứ. Nhất quán chữ hoa chữ thường, nhất quán ngôn ngữ (chọn tiếng Anh cho tên máy, tiếng Việt cho mô tả người đọc).
Ví dụ chi tiết
Sàn thương mại điện tử Chợ Xanh muốn đo hành trình mua hàng. Các bước:
Bước 1 — Liệt kê câu hỏi: Bao nhiêu người xem sản phẩm rồi thêm giỏ? Kênh nào chuyển đổi tốt? Người mua lần đầu khác người mua lại thế nào?
Bước 2 — Từ câu hỏi rút ra sự kiện: Product Viewed, Product Added, Checkout Started, Order Completed.
Bước 3 — Định nghĩa thuộc tính. Với Product Viewed: product_id, category, price, source_channel. Với Order Completed: order_value, payment_method (momo, vnpay, cod), item_count, is_first_order.
Bước 4 — Ghi vào bảng tracking plan. Mỗi dòng gồm: tên sự kiện, khi nào bắn, thuộc tính, kiểu dữ liệu, ví dụ giá trị, chủ sở hữu.
Bước 5 — Engineer gắn, QA kiểm bằng debug console. Chợ Xanh phát hiện Product Added bắn hai lần khi người dùng bấm nhanh — họ thêm chống trùng (debounce). Nhờ vậy khi vẽ funnel, tỷ lệ thêm giỏ không bị thổi phồng.
Kết quả: sau hai tuần, họ trả lời được câu hỏi kênh nào tốt (Facebook Ads chuyển đổi thấp hơn tìm kiếm tự nhiên 40%) và điều chỉnh ngân sách.
Lộ trình từng bước để làm chủ
graph LR A[Hoc dat ten Object Action] --> B[Lap danh sach su kien loi] B --> C[Thiet ke thuoc tinh] C --> D[Viet tracking plan mau] D --> E[Lam viec voi engineer] E --> F[QA va giam sat chat luong] F --> G[Bao tri va mo rong]
Bắt đầu nhỏ: chọn năm tới bảy sự kiện cốt lõi thay vì gắn tất cả. Sự kiện thừa gây nhiễu và tốn chi phí. Khi đã vững, mở rộng theo nhu cầu câu hỏi mới.
Thói quen và kỷ luật
| Nhịp | Thói quen |
|---|---|
| Hằng ngày | Kiểm tra dashboard chất lượng dữ liệu, tìm sự kiện lạ |
| Hằng tuần | Duyệt yêu cầu tracking mới, cập nhật plan |
| Hằng tháng | Rà soát sự kiện không ai dùng để xóa bớt |
| Mỗi tính năng | Viết tracking spec trước khi code |
Cần luyện tập gì (drills)
Drill 1: Lấy một app bạn đang dùng (ví dụ Grab), viết lại mười sự kiện theo chuẩn Object-Action kèm thuộc tính.
Drill 2: Cho một tracking plan có lỗi đặt tên lộn xộn, viết lại cho nhất quán và giải thích tại sao.
Drill 3: Thiết kế thuộc tính cho sự kiện Search Performed sao cho sau này trả lời được câu hỏi về từ khóa không có kết quả.
Checklist hành động tuần này
- [ ] Viết ra năm câu hỏi kinh doanh app của bạn cần trả lời
- [ ] Rút ra bảy sự kiện cốt lõi theo chuẩn Object-Action
- [ ] Định nghĩa thuộc tính cho từng sự kiện kèm ví dụ giá trị
- [ ] Tạo file tracking plan chia sẻ với engineer
- [ ] Kiểm tra thực tế ít nhất hai sự kiện bằng debug tool
Chỉ số và North Star
North Star cho kỹ năng này: tỷ lệ sự kiện có dữ liệu sạch, đúng định nghĩa, sẵn sàng phân tích.
| Chỉ số | Tốt | Xấu |
|---|---|---|
| Độ phủ tracking plan | Trên 90% sự kiện có tài liệu | Dưới 50% |
| Sự kiện trùng nghĩa | Không có | Nhiều bản sao |
| Thời gian trả lời câu hỏi mới | Dưới một ngày | Trên một tuần |
| Sự kiện chết không ai dùng | Dưới 10% | Trên 40% |
Dấu hiệu bạn đã thành thạo
Bạn nhìn một tính năng mới là tự viết được tracking spec trong mười lăm phút. Engineer hiếm khi hỏi lại. Khi có câu hỏi bất ngờ từ sếp, bạn trả lời bằng dữ liệu có sẵn thay vì xin gắn thêm sự kiện rồi chờ. Bạn cũng chủ động đề xuất xóa sự kiện thừa.
Cạm bẫy thường gặp
| Cạm bẫy | Thay bằng |
|---|---|
| Gắn mọi thứ có thể gắn | Chỉ gắn cái trả lời câu hỏi |
| Đặt tên tùy hứng theo từng dev | Chuẩn Object-Action thống nhất |
| Nhồi dữ liệu vào tên sự kiện | Đưa vào thuộc tính |
| Bỏ qua QA sau khi gắn | Kiểm tra debug trước khi tin số |
Chốt lại
- Tracking plan là nền móng, dữ liệu bẩn phá hỏng mọi phân tích về sau
- Dùng chuẩn Object-Action và tách ngữ cảnh vào thuộc tính
- Bắt đầu nhỏ với sự kiện cốt lõi, mở rộng theo câu hỏi thực tế
- QA và bảo trì liên tục quan trọng ngang việc gắn ban đầu
Template sẵn dùng: Tracking Plan / Event Taxonomy
| Sự kiện (event) | Khi nào kích hoạt | Thuộc tính (properties) | Loại | Chủ sở hữu | Trạng thái |
|---|---|---|---|---|---|
| signup_completed | Khi user hoàn tất đăng ký | method, source | Kích hoạt | PM | Đã triển khai |
| lesson_completed | Khi hoàn thành 1 bài | lesson_id, duration | Giá trị (North Star) | PM | Đang làm |
| — | — | — | — | — | — |
| — | — | — | — | — | — |
| — | — | — | — | — | — |
| — | — | — | — | — | — |
| — | — | — | — | — | — |