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 |
| — | — | — | — | — | — |
| — | — | — | — | — | — |
| — | — | — | — | — | — |
| — | — | — | — | — | — |
| — | — | — | — | — | — |
<!--case-append-->
Áp dụng vào Căng tin số
Khóa này dùng chung một ví dụ: Căng tin số, app đặt trước suất cơm ở Căng tin khu A của Đại học Ánh Dương, đã chạy thử bốn tuần ở quầy cơm. Bối cảnh đầy đủ, từ phỏng vấn tới user story, có trong lộ trình Từ người dùng tới user story.
Theo bài, tracking plan bắt đầu từ câu hỏi, không từ màn hình. Trước khi chạy thử, nhóm có bốn câu hỏi cần trả lời cuối tuần 4: người dùng rơi ở bước nào khi đặt; trả trước có giữ được tỉ lệ không tới lấy thấp không; bảng "còn món" có giúp người tới muộn không; nhân viên quầy có bấm "hết" kịp không. Từ đó mới rút ra sự kiện.
| Sự kiện | Khi nào bắn | Thuộc tính chính |
|---|---|---|
| App Opened | Mở app hoặc quay lại app | user_id, gio_mo |
| Menu Viewed | Màn thực đơn trong ngày hiện ra | is_after_cutoff, so_mon_con |
| Dish Selected | Chọn món vào suất | dish_id, quay, so_mon_man |
| Order Paid | Thanh toán thành công | order_id, pickup_slot, so_tien |
| Order Picked Up | Nhân viên nhập mã nhận món 4 số | order_id, phut_cho |
| Order Not Collected | Hệ thống đánh dấu sau 30 phút giữ suất | order_id, pickup_slot |
| Dish Sold Out Marked | Nhân viên bấm nút "hết" | dish_id, staff_id |
| Order Refunded | Anh Tuấn duyệt hoàn tiền | order_id, ly_do |
Tên theo Object-Action, động từ ở quá khứ. Viết Order Paid, không viết thanh_toan hay click_pay. Sự kiện ghi lại điều đã xảy ra, nên dùng quá khứ. Tên máy dùng tiếng Anh, còn cột mô tả viết tiếng Việt cho anh Tuấn và chị Lan đọc.
Đừng nhồi dữ liệu vào tên. Một lỗi rất dễ mắc là tạo Com Ga Selected, Ca Kho Selected cho từng món. Thực đơn đổi mỗi ngày, chốt lúc 16:00 hôm trước, nên sau một tháng bạn sẽ có hàng trăm tên sự kiện. Món phải nằm trong thuộc tính dish_id. Tương tự, is_after_cutoff trên Menu Viewed là một thuộc tính nhỏ nhưng đắt giá: nhờ nó, cuối tuần 4 nhóm đếm được bao nhiêu lượt xem thực đơn rơi vào sau giờ chốt 10:00, đúng chỗ phễu rò mạnh nhất.
Có sự kiện không do người dùng bấm. Order Not Collected do hệ thống bắn theo quy tắc giữ suất 30 phút của Cô Hạnh, và Dish Sold Out Marked do nhân viên quầy bấm. Thiếu hai sự kiện này, bạn không đo được tỉ lệ không tới lấy (14% ở tuần 1, 7% ở tuần 4) hay số lần quên bấm "hết".
QA trước khi tin số. Kiểm tra chéo đơn giản: tuần 4 có 205 đơn thanh toán mỗi ngày, tỉ lệ không tới lấy 7%, nên Order Picked Up phải ở quanh 190. Số khớp. Nếu Order Paid bắn hai lần khi mạng chậm và người dùng bấm lại, phép kiểm này sẽ lệch ngay. Tuần 1 còn 3 lỗi in phiếu cho bếp; một sự kiện Kitchen Ticket Failed (giả sử nhóm thêm sau) sẽ cho thấy lỗi đó sớm hơn là chờ Cô Hạnh kể.
Thử ngay: thiết kế sự kiện cho bảng "còn món", đặt tên theo Object-Action ở quá khứ, và chọn đủ thuộc tính để trả lời được câu "người tới sau 12:30 đã xem bảng có đi thẳng sang quầy khác không". <!--/case-append-->