Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn vừa dành ba tháng để đội kỹ thuật gắn tracking cho toàn bộ sản phẩm. Đến ngày bạn mở Mixpanel lên để trả lời một câu hỏi tưởng chừng đơn giản của CEO — "tuần này có bao nhiêu người mua hàng thành công?" — bạn phát hiện ra một cơn ác mộng. Trong hệ thống có tới bốn sự kiện khác nhau cùng nói về một chuyện: purchase, Purchase Completed, order_success, và checkout_done. Mỗi lập trình viên đặt tên theo cách của họ, mỗi màn hình gửi một biến thể. Không có sự kiện nào chứa đầy đủ số tiền, và cái thì để amount, cái thì để total_price, cái thì để revenue. Bạn không thể trả lời câu hỏi đó một cách chính xác. Toàn bộ dữ liệu ba tháng gần như vô dụng.
Đây không phải câu chuyện hiếm. Đây là điều xảy ra ở đa số các sản phẩm chưa từng thiết kế event taxonomy — tức là hệ thống phân loại và đặt tên sự kiện một cách có kỷ luật. Taxonomy tồi khiến việc phân tích trở nên bất khả thi, biến những công cụ đắt tiền như Amplitude hay Mixpanel thành kho chứa rác. Và điều đau đớn nhất: sửa lại tracking sau khi đã launch là một cực hình, vì bạn phải chờ code deploy, chờ người dùng cập nhật app, rồi mất hàng tuần để dữ liệu "sạch" tích lũy đủ để phân tích.
Bài học này dạy bạn cách thiết kế taxonomy đúng ngay từ đầu — nền tảng cho mọi phân tích funnel, retention, cohort mà bạn sẽ học ở các bài sau.
Khái niệm cốt lõi
Event taxonomy là gì?
Event taxonomy là bộ quy tắc thống nhất về việc bạn theo dõi cái gì và đặt tên như thế nào. Nó bao gồm ba thành phần: danh sách các sự kiện (events), cấu trúc thuộc tính (properties) đi kèm mỗi sự kiện, và quy ước đặt tên (naming convention) áp dụng nhất quán. Hãy hình dung taxonomy như "bảng chữ cái" chung mà mọi người trong công ty — PM, dev, data analyst — cùng dùng để nói về hành vi người dùng.
Mô hình Object–Action: xương sống của naming
Nguyên tắc đặt tên hiệu quả nhất, được cả Amplitude và Mixpanel khuyến nghị, là mô hình Object–Action: mỗi sự kiện mô tả một đối tượng và một hành động tác động lên đối tượng đó.
Ví dụ, thay vì đặt tên lộn xộn, bạn cấu trúc như sau:
Product Viewed(đối tượng: Product, hành động: Viewed)Product Added to CartOrder CompletedVideo PlayedVideo Paused
Product sẽ nằm cạnh nhau, dễ tìm, dễ hiểu, dễ mở rộng. Bất kỳ ai nhìn vào cũng đoán được sự kiện tiếp theo nên tên gì.Event vs. Property: khi nào tạo sự kiện mới, khi nào dùng thuộc tính
Đây là quyết định gây bối rối nhất cho người mới. Nguyên tắc vàng: dùng property để mô tả biến thể của cùng một hành động, chỉ tạo event mới khi hành động thực sự khác nhau.
Sai lầm điển hình là "bùng nổ sự kiện" (event explosion):
Clicked Blue ButtonClicked Red ButtonClicked Signup Button
Button Clicked với các property:Button Clicked
- button_color: "blue"
- button_text: "Đăng ký ngay"
- button_location: "homepage_header"
Vì sao điều này quan trọng? Vì hầu hết các gói của Amplitude/Mixpanel giới hạn số lượng event type (thường vài trăm đến 1.000). Nếu bạn tạo sự kiện riêng cho từng biến thể nhỏ, bạn sẽ chạm trần rất nhanh và mất khả năng phân tích chéo. Với property, bạn có thể lọc, nhóm (breakdown) linh hoạt sau này mà không cần re-track.
Naming convention: chọn một, giữ nguyên mãi mãi
Sự nhất quán quan trọng hơn "kiểu nào đúng". Bạn cần chốt sớm:
- Định dạng chữ:
snake_case(product_viewed) hayTitle Case(Product Viewed)? Mixpanel thường dùng Title Case cho event, snake_case cho property; Amplitude thường dùng Title Case với dấu cách. Chọn một và ghi vào tài liệu. - Thì của động từ: luôn dùng thì quá khứ hoàn thành —
Order Completed, không phảiComplete OrderhayCompleting Order. Sự kiện ghi lại một việc đã xảy ra. - Property đặt tên rõ nghĩa:
revenue_vndtốt hơnamount;signup_methodtốt hơntype.
Tại sao taxonomy tồi làm hỏng funnel và tốn tiền
Ba hệ quả trực tiếp mà bạn phải khắc cốt ghi tâm:
- Funnel vỡ: Funnel là chuỗi sự kiện có thứ tự. Nếu bước "thanh toán" khi thì bắn
purchasekhi thì bắnorder_success, funnel sẽ đếm thiếu, tỷ lệ chuyển đổi hiển thị sai — bạn có thể tưởng sản phẩm đang rò rỉ người dùng trong khi thực ra chỉ là dữ liệu lộn xộn. - Phân tích bất khả thi: Không thể segment, không thể so sánh, không thể tin con số.
- Đội chi phí: Nhiều công cụ tính tiền theo số event gửi lên (event volume). Sự kiện trùng lặp, sự kiện rác gửi hàng triệu lượt mỗi tháng khiến hóa đơn phình to mà không tạo giá trị.
Tình huống thực tế
Ví dụ 1 — Sàn TMĐT giả định "ShopViet": cơn ác mộng trùng lặp
ShopViet, một sàn thương mại điện tử với khoảng 200.000 người dùng hoạt động hàng tháng, triển khai Amplitude mà không có tracking plan. Ba nhóm — web, app iOS, app Android — làm việc độc lập. Kết quả: cùng hành động "hoàn tất đơn hàng", web gửi Order Completed, iOS gửi purchase_success, Android gửi Checkout Done.
Khi giám đốc tăng trưởng muốn tính doanh thu theo kênh, con số trên Amplitude chỉ khớp được 60% so với hệ thống backend. Tệ hơn, property tiền tệ không nhất quán: web gửi total: 350000 (đồng), iOS gửi total: 350 (nghìn đồng). Mọi báo cáo ARPU đều sai lệch.
Bài học rút ra: Taxonomy phải là hợp đồng chung xuyên nền tảng. Cùng một hành động của người dùng, dù xảy ra trên web hay mobile, phải bắn cùng một tên sự kiện với cùng cấu trúc property và cùng đơn vị. ShopViet cuối cùng phải làm lại toàn bộ, mất 6 tuần và bỏ đi 4 tháng dữ liệu cũ.
Ví dụ 2 — Startup fintech "PayNhanh": event explosion đốt ngân sách
PayNhanh, một ví điện tử giai đoạn đầu, có một dev nhiệt tình gắn tracking cực chi tiết. Mỗi nút bấm là một sự kiện riêng: Tap Home Tab, Tap Wallet Tab, Tap QR Button, Tap Send Money Button... Sau 8 tháng, họ có hơn 900 event type và gửi khoảng 40 triệu sự kiện/tháng.
Hai vấn đề nổ ra cùng lúc. Thứ nhất, họ sắp chạm giới hạn event type của gói và không thể thêm sự kiện quan trọng cho tính năng mới. Thứ hai, hóa đơn Mixpanel tăng vọt vì event volume. Khi PM muốn phân tích "người dùng bấm vào những tab nào nhiều nhất", họ phải cộng thủ công 12 sự kiện khác nhau vì mỗi tab là một event riêng.
Đội quyết định tái cấu trúc: gộp tất cả thành Tab Selected với property tab_name, và Button Tapped với property button_id + screen. Số event type giảm từ 900 xuống còn 120. Việc phân tích tab giờ chỉ là một biểu đồ với breakdown theo tab_name. Chi phí giảm khoảng 30% do loại bỏ event rác.
Bài học rút ra: Property là bạn của bạn. Mỗi khi định tạo sự kiện mới, hãy tự hỏi: "Đây có phải là một biến thể của hành động đã có không?" Nếu đúng, dùng property.
Ví dụ 3 — Ứng dụng học tập "EduBee": thiết kế đúng ngay từ đầu
EduBee là một app học tiếng Anh. Trước khi viết một dòng code tracking nào, PM và tech lead ngồi lại làm một tracking plan trên Google Sheet, thống nhất mô hình Object–Action. Họ định nghĩa các sự kiện lõi quanh vòng đời học viên: Lesson Started, Lesson Completed, Quiz Submitted, Subscription Purchased.
Mỗi sự kiện có bảng property rõ ràng — ví dụ Lesson Completed gồm lesson_id, lesson_level (beginner/intermediate/advanced), duration_seconds, completion_percent. Đơn vị tiền được chuẩn hóa là price_vnd. Mọi tên đều Title Case, động từ quá khứ.
Sáu tháng sau, khi cần xây dựng phân tích retention và tìm "aha moment", đội EduBee làm được gần như tức thì: chỉ cần lọc Lesson Completed với lesson_level = beginner trong tuần đầu. Không cần re-track, không cần dọn dữ liệu. Họ tiết kiệm được hàng tuần công sức so với ShopViet.
Bài học rút ra: Nửa ngày ngồi thiết kế taxonomy trước khi code tiết kiệm cho bạn hàng tháng dọn dẹp về sau. Đầu tư sớm là đầu tư rẻ nhất.
Hướng dẫn từng bước
Đây là quy trình thiết kế taxonomy bạn có thể áp dụng ngay cho sản phẩm của mình:
Bước 1 — Bắt đầu từ câu hỏi kinh doanh, không phải từ nút bấm. Liệt kê 10–15 câu hỏi mà PM/CEO thực sự muốn trả lời: "Bao nhiêu người hoàn tất onboarding?", "Doanh thu theo kênh?", "Tính năng nào được dùng nhiều nhất?". Taxonomy tồn tại để trả lời câu hỏi, không phải để ghi lại mọi cú click.
Bước 2 — Xác định các sự kiện lõi từ những câu hỏi đó. Mỗi câu hỏi thường ánh xạ tới một vài sự kiện. "Bao nhiêu người mua hàng?" → Order Completed. Ưu tiên các sự kiện dọc theo hành trình chuyển đổi chính (acquisition → activation → revenue).
Bước 3 — Áp mô hình Object–Action để đặt tên. Với mỗi sự kiện, xác định đối tượng và hành động. Viết ở thì quá khứ. Ghi vào cột "Event Name" trong tracking plan.
Bước 4 — Thiết kế property cho từng sự kiện. Tự hỏi: "Sau này tôi sẽ muốn cắt lát (segment) sự kiện này theo chiều nào?" Mỗi chiều đó là một property. Ghi rõ tên, kiểu dữ liệu (string/number/boolean), ví dụ giá trị, và đơn vị.
Bước 5 — Chốt naming convention và ghi thành tài liệu sống. Một Google Sheet hoặc công cụ chuyên dụng (Avo, Amplitude Data, Mixpanel Lexicon) làm nguồn chân lý duy nhất. Mọi dev tra cứu ở đây trước khi implement.
Bước 6 — Review với đội kỹ thuật trước khi code. Dev có thể chỉ ra sự kiện nào khó bắn, property nào không lấy được ở client. Sửa trên giấy rẻ hơn sửa trên production.
Bước 7 — Chuẩn hóa property dùng chung. Những property xuất hiện ở nhiều sự kiện (như platform, user_type, is_premium) nên có tên và kiểu thống nhất tuyệt đối.
Lỗi thường gặp & mẹo
Lỗi 1: Theo dõi mọi thứ "cho chắc". Nhiều đội bật auto-capture rồi gửi hàng nghìn sự kiện với niềm tin "sau này cần thì có sẵn". Thực tế, 90% dữ liệu đó không bao giờ được dùng, chỉ làm nhiễu và tốn tiền. Mẹo: Bắt đầu tinh gọn với các sự kiện lõi, mở rộng dần khi có câu hỏi thật.
Lỗi 2: Nhét quá nhiều nghĩa vào tên sự kiện. Ví dụ User Clicked Buy Button On Product Page From Mobile. Mẹo: Đưa bối cảnh (screen, platform, source) vào property, giữ tên sự kiện ngắn gọn ở mức hành động.
Lỗi 3: Đơn vị và kiểu dữ liệu không nhất quán. Tiền lúc là đồng, lúc là nghìn đồng; ngày lúc là chuỗi, lúc là timestamp. Mẹo: Ghi rõ đơn vị trong tên property (revenue_vnd) và cố định kiểu dữ liệu trong tracking plan.
Lỗi 4: Không có ai "sở hữu" taxonomy. Khi taxonomy là của chung mà không ai chịu trách nhiệm, nó nhanh chóng phân rã. Mẹo: Chỉ định một người (thường là PM hoặc data analyst) làm người gác cổng, mọi sự kiện mới phải được duyệt.
Lỗi 5: Đặt tên theo tiếng Việt có dấu hoặc trộn ngôn ngữ. Điều này gây lỗi kỹ thuật và khó lọc. Mẹo: Tên event và property luôn dùng tiếng Anh không dấu; giá trị (value) có thể là tiếng Việt nếu là nội dung người dùng.
Mẹo lớn cuối cùng: Hãy nghĩ về taxonomy như thiết kế một cơ sở dữ liệu — bạn không thể đổi schema tùy tiện sau khi đã có triệu dòng dữ liệu. Chậm mà chắc ở giai đoạn thiết kế.
Bài tập thực hành
- Sửa taxonomy tồi. Cho danh sách sự kiện lộn xộn sau, hãy tái cấu trúc theo mô hình Object–Action và chỉ ra property nào cần thêm:
blue_signup_clicked, Clicked Google Signup, user did register, login, Logged In With Facebook.- Viết tracking plan mini. Chọn một sản phẩm bạn biết (một app giao đồ ăn chẳng hạn). Liệt kê 5 câu hỏi kinh doanh, rồi thiết kế 5 sự kiện lõi với đầy đủ tên (Object–Action) và ít nhất 3 property mỗi sự kiện, kèm kiểu dữ liệu và đơn vị.
- Quyết định event hay property. Với mỗi tình huống, hãy quyết định nên tạo sự kiện mới hay dùng property, và giải thích: (a) người dùng chia sẻ nội dung qua Facebook vs. qua Zalo; (b) người dùng hoàn tất đơn hàng vs. hủy đơn hàng; (c) người dùng xem sản phẩm ở trang chủ vs. ở trang tìm kiếm.
Tóm tắt
Event taxonomy là nền móng của toàn bộ product analytics — không có nó, mọi funnel, retention, cohort ở các bài sau đều xây trên cát. Hãy ghi nhớ những nguyên tắc cốt lõi: dùng mô hình Object–Action ở thì quá khứ để đặt tên nhất quán; ưu tiên property thay vì tạo event mới để tránh event explosion, tiết kiệm chi phí và giữ khả năng phân tích linh hoạt; chuẩn hóa đơn vị và kiểu dữ liệu tuyệt đối, nhất là xuyên nền tảng web–mobile; và luôn bắt đầu từ câu hỏi kinh doanh, không phải từ mọi cú click.
Quan trọng nhất: thiết kế taxonomy trước khi viết code tracking, ghi thành tracking plan làm nguồn chân lý duy nhất, và chỉ định một người sở hữu nó. Nửa ngày kỷ luật ở giai đoạn thiết kế sẽ cứu bạn khỏi hàng tháng dọn dẹp và những quyết định sai lầm dựa trên dữ liệu bẩn về sau.