Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn vừa được tuyển vào làm Growth PM tại một startup fintech Việt Nam. Tuần đầu tiên, sếp hỏi: "Tỷ lệ user hoàn tất bước xác thực eKYC là bao nhiêu phần trăm?" Bạn mở Amplitude lên và phát hiện ác mộng: có sự kiện tên kyc_done, lại có KYC Completed, rồi verify_success, ekyc_finish — tất cả do các lập trình viên khác nhau đặt ở những thời điểm khác nhau, mỗi cái gắn ở một bước khác nhau trong luồng, và không ai biết chắc cái nào đúng. Bạn không thể trả lời câu hỏi đơn giản nhất về sản phẩm.
Đây không phải tình huống hiếm. Trong thực tế, phần lớn các đội Growth không thất bại vì thiếu công cụ phân tích — họ có Mixpanel, Amplitude, GA4 đầy đủ. Họ thất bại vì dữ liệu đầu vào hỗn loạn. Và gốc rễ của sự hỗn loạn đó là thiếu một thứ tưởng chừng rất "kỹ thuật" nhưng thực ra là trách nhiệm cốt lõi của Growth PM: Event Taxonomy (hệ thống phân loại và đặt tên sự kiện) và Tracking Plan (kế hoạch theo dõi).
Nếu bạn coi mọi quyết định growth đều dựa trên dữ liệu, thì taxonomy chính là ngữ pháp của ngôn ngữ dữ liệu. Sai ngữ pháp, mọi câu phân tích đều vô nghĩa. Bài này dạy bạn cách thiết kế hệ thống đặt tên sự kiện nhất quán và xây dựng một tracking plan có thể sống được nhiều năm — nền móng mà tất cả các bài về A/B test, funnel, cohort phía sau đều dựa vào.
Khái niệm cốt lõi
Event Taxonomy là gì
Event (sự kiện) là một hành động được ghi nhận khi user tương tác với sản phẩm: nhấn nút, xem màn hình, hoàn tất thanh toán. Mỗi event mang theo properties (thuộc tính) — những thông tin mô tả bối cảnh của hành động đó.
Taxonomy là bộ quy tắc thống nhất để đặt tên và tổ chức tất cả các event đó, sao cho bất kỳ ai trong công ty — PM, data analyst, marketer, engineer — đọc tên event đều hiểu chính xác nó nghĩa là gì mà không cần hỏi.
Hãy hình dung taxonomy như cách thư viện phân loại sách. Nếu mỗi thủ thư tự đặt mã sách theo ý mình, không ai tìm được gì. Taxonomy chuẩn hóa "mã sách" cho dữ liệu hành vi.
Quy ước đặt tên: Object_Action hoặc Verb_Noun
Đây là trái tim của taxonomy. Quy ước phổ biến và bền vững nhất là cấu trúc Đối tượng + Hành động, viết theo mẫu Noun_Verb hoặc Verb_Noun. Quan trọng là chọn một mẫu và tuyệt đối nhất quán trên toàn hệ thống.
Ví dụ theo mẫu Object_Action:
Signup_Completed(đăng ký hoàn tất)Item_Added(thêm sản phẩm vào giỏ)Checkout_Failed(thanh toán thất bại)Subscription_Cancelled(hủy gói)
- Snake_case nhất quán: dùng dấu gạch dưới ngăn cách, không trộn lẫn
camelCase,kebab-casehay khoảng trắng.Item_Added, không phảiitemAddedhayItem Added. - Danh từ số ít:
Item_Added, không phảiItems_Added. Một event ghi nhận một hành động; số lượng được thể hiện trong property nhưitem_count: 3, không nhét vào tên. - Động từ ở thì quá khứ: event ghi nhận điều đã xảy ra, nên dùng
Completed,Added,Viewed,Failed— không dùngCompletehayAdding. Điều này giúp tên event đọc như một sự thật lịch sử. - Tránh tên chung chung:
Button_Clickedgắn cho mọi nút trên app là vô dụng — bạn sẽ có hàng triệu event không phân biệt được. Hãy đặt tên theo ý nghĩa nghiệp vụ:Cart_Cleared,Filter_Applied.
Phân biệt Event và Property
Một sai lầm kinh điển: nhét quá nhiều thông tin vào tên event. Quy tắc vàng:
- Event = loại hành động (số lượng nên giới hạn, thường vài chục đến vài trăm).
- Property = chi tiết của hành động đó (linh hoạt, nhiều bao nhiêu cũng được).
Product_Viewed_Shoes, Product_Viewed_Shirts, Product_Viewed_Hats.
Đúng: một event Product_Viewed với property category: "shoes".Lý do: nếu mỗi danh mục là một event riêng, bạn không thể trả lời "tổng lượt xem sản phẩm" mà phải cộng tay từng cái, và mỗi khi thêm danh mục mới lại phải code thêm event. Với property, bạn break-down thoải mái trong công cụ phân tích.
Có hai loại property cần phân biệt:
- Event properties: thuộc về riêng lần event đó (
payment_method: "momo",amount: 250000). - User properties: thuộc về user, tồn tại xuyên suốt (
plan_type: "premium",signup_date,city: "HCM").
Tracking Plan là gì
Nếu taxonomy là quy tắc, thì Tracking Plan là bản hợp đồng cụ thể: một tài liệu sống (thường là Google Sheet, Notion, hoặc công cụ chuyên dụng như Avo, Segment Protocols) liệt kê từng event sẽ được theo dõi, kèm:
- Tên event (đúng chuẩn taxonomy)
- Mô tả: event này nghĩa là gì, kích hoạt khi nào
- Danh sách property và kiểu dữ liệu (string, number, boolean)
- Giá trị hợp lệ cho property dạng enum (ví dụ
payment_methodchỉ nhận:momo,zalopay,vnpay,card) - Nền tảng kích hoạt (web, iOS, Android)
- Trạng thái: đang đề xuất / đã triển khai / deprecated
- Người sở hữu
Tình huống thực tế
Ví dụ 1: Sàn TMĐT và cơn ác mộng "event sinh đôi"
Một sàn thương mại điện tử tầm trung tại Việt Nam (giả định, quy mô khoảng 2 triệu user) phát triển nhanh trong 18 tháng. Mỗi khi một feature team ra tính năng mới, engineer tự gắn event theo ý mình. Kết quả sau một năm rưỡi: trong Amplitude có hơn 1.200 event, trong đó tồn tại add_to_cart, AddToCart, cart_add, và Item_Added — tất cả ghi nhận cùng một hành động nhưng ở các phiên bản app khác nhau.
Khi đội Growth muốn tính tỷ lệ chuyển đổi từ "thêm giỏ" sang "đặt hàng", họ phải hợp nhất 4 event lại bằng tay, và phát hiện hai trong số đó còn gắn sai vị trí (kích hoạt khi user xem sản phẩm chứ không phải thêm giỏ). Con số conversion rate báo cáo cho ban lãnh đạo suốt 6 tháng đã sai khoảng 15%.
Diễn giải: Không ai cố ý làm sai. Vấn đề là thiếu một taxonomy chuẩn và thiếu cơ chế review trước khi gắn event. Mỗi engineer là một "phương ngữ" riêng.
Bài học: Taxonomy phải được định nghĩa trước, và mọi event mới phải qua một bước review (dù chỉ 5 phút) đối chiếu với tracking plan. Chi phí dọn dẹp một taxonomy hỏng lớn hơn rất nhiều chi phí thiết lập nó đúng từ đầu.
Ví dụ 2: Startup SaaS B2B và bài học "property cứu cả hệ thống"
Một startup SaaS quản lý nhân sự (giả định) phục vụ doanh nghiệp Đông Nam Á ban đầu định nghĩa các event rất chi tiết: Report_Exported_PDF, Report_Exported_Excel, Report_Exported_CSV. Khi marketing muốn biết "tổng số lần export báo cáo theo từng gói khách hàng", họ phải cộng ba event và không thể lọc theo plan vì plan không nằm trong event.
Đội Growth PM tái cấu trúc lại: gộp thành một event duy nhất Report_Exported với các property format: "pdf" | "excel" | "csv", report_type, và dựa vào user property plan_type đã có sẵn. Ngay lập tức, họ trả lời được hàng loạt câu hỏi: gói Enterprise export nhiều gấp 4 lần gói Basic, và 80% là định dạng Excel — một insight dẫn tới việc ưu tiên cải thiện tính năng xuất Excel.
Diễn giải: Sức mạnh phân tích không nằm ở số lượng event, mà ở việc mô hình hóa đúng event và property. Một event "mỏng" cộng property phong phú linh hoạt hơn nhiều so với hàng chục event "dày".
Bài học: Khi định nghĩa event, hãy hỏi: "Cái gì là hành động (event), cái gì là biến thể của hành động (property)?" Biến thể luôn nên là property.
Ví dụ 3: Ví điện tử và tracking plan như hợp đồng kỹ thuật
Một ví điện tử (giả định theo phong cách MoMo/ZaloPay) chuẩn bị ra mắt tính năng "đầu tư tích lũy". Trước khi viết một dòng code, Growth PM ngồi với data team và engineer lập tracking plan trong Notion. Họ định nghĩa trước 12 event cho toàn bộ luồng: Invest_Onboarding_Started, Invest_RiskProfile_Submitted, Invest_Fund_Selected, Invest_Deposit_Completed, Invest_Withdrawal_Requested...
Mỗi event ghi rõ property, ví dụ Invest_Deposit_Completed có amount (number), fund_id (string), payment_source (enum: wallet, bank), is_first_deposit (boolean). Engineer triển khai đúng theo bản này. Ngày tính năng lên production, dashboard funnel đã sẵn sàng chạy ngay, không phải chờ "bổ sung tracking sau".
Diễn giải: Vì tracking plan được làm trước, dữ liệu sạch ngay từ ngày đầu. So với cách làm phổ biến (ra tính năng trước, gắn tracking sau khi sếp hỏi số liệu), họ tiết kiệm hàng tuần và tránh mất dữ liệu của giai đoạn launch — giai đoạn quý giá nhất.
Bài học: Tracking plan không phải việc làm sau, mà là một phần của định nghĩa tính năng. "No tracking plan, no merge."
Hướng dẫn từng bước
Đây là quy trình xây dựng event taxonomy và tracking plan từ đầu:
Bước 1 — Bắt đầu từ câu hỏi nghiệp vụ, không từ event. Đừng liệt kê "tôi cần track cái gì". Hãy hỏi: "Tôi cần trả lời những câu hỏi nào về sản phẩm?" Ví dụ: tỷ lệ activation là bao nhiêu, user rớt ở bước nào trong onboarding, kênh nào mang user retention cao nhất. Mỗi câu hỏi sẽ chỉ ra event nào thực sự cần.
Bước 2 — Vẽ các luồng quan trọng (critical user journeys). Liệt kê những hành trình cốt lõi: đăng ký, onboarding, hành vi tạo giá trị chính (core action), thanh toán. Mỗi bước trong luồng tương ứng một event tiềm năng.
Bước 3 — Chốt quy ước đặt tên. Quyết định: dùng Object_Action, snake_case, danh từ số ít, động từ quá khứ. Viết quy ước này thành một trang tài liệu ngắn mà cả team đồng thuận. Đây là "hiến pháp" — khó sửa, ai cũng phải theo.
Bước 4 — Định nghĩa từng event và property trong tracking plan. Với mỗi event: tên, mô tả, điều kiện kích hoạt, danh sách property + kiểu dữ liệu + giá trị hợp lệ. Phân biệt rõ event property và user property.
Bước 5 — Giữ số lượng event tinh gọn. Một sản phẩm khỏe mạnh thường chỉ cần 30–80 event cốt lõi, không phải hàng nghìn. Nếu băn khoăn có nên tạo event riêng, hãy hỏi: đây có phải hành động khác biệt thật sự, hay chỉ là một property?
Bước 6 — Review và phê duyệt. Trước khi engineer code, PM + data analyst review tracking plan. Mọi event mới sau này cũng phải qua bước này (governance).
Bước 7 — Triển khai, kiểm thử (QA) và xác thực. Sau khi code, dùng công cụ debug (Mixpanel/Amplitude có chế độ live event, hoặc tool như Avo Inspector) để xác nhận event bắn đúng tên, đúng property, đúng thời điểm trước khi lên production.
Bước 8 — Duy trì. Tracking plan là tài liệu sống. Đánh dấu event deprecated thay vì xóa, ghi version, và định kỳ (mỗi quý) rà soát event "chết".
Lỗi thường gặp & mẹo
Lỗi 1 — Đặt tên không nhất quán. Trộn User_SignedUp với login_success với Page View. Mẹo: viết quy ước ra giấy, đưa vào checklist code review, và lý tưởng nhất là dùng công cụ tự động kiểm tra tên event (linter) trong CI.
Lỗi 2 — Nhồi thông tin vào tên event. Video_Played_Mobile_Premium_Vietnam. Mẹo: nếu tên có hơn 3–4 thành phần, gần như chắc chắn bạn đang nhét property vào tên. Tách ra: Video_Played + device, plan, country.
Lỗi 3 — Tracking sau khi launch. Ra tính năng rồi mới gắn event khi sếp hỏi số. Mẹo: biến tracking plan thành một phần bắt buộc của "Definition of Done" cho mọi tính năng.
Lỗi 4 — Bùng nổ số lượng event. Mỗi engineer tự thêm event tùy ý, sau một năm có nghìn event vô dụng. Mẹo: chỉ định một "data owner" duyệt mọi event mới; ưu tiên property thay vì event mới.
Lỗi 5 — Quên giá trị property bị bỏ trống hoặc sai kiểu. amount lúc là number, lúc là string "250000 VND". Mẹo: chốt kiểu dữ liệu trong tracking plan và validate ở tầng client trước khi gửi.
Lỗi 6 — Không có giá trị enum cố định. payment_method nhận momo, Momo, MOMO, mo mo. Mẹo: liệt kê danh sách giá trị hợp lệ và chuẩn hóa (lowercase) ngay tại nguồn.
Mẹo vàng: Tên event tốt là tên mà một người mới vào công ty đọc lên hiểu ngay mà không cần giải thích. Nếu phải mở tài liệu mới hiểu, tên đó chưa đủ tốt.
Bài tập thực hành
- Thiết kế taxonomy cho một luồng. Chọn một sản phẩm bạn quen thuộc (ví dụ app gọi xe). Vẽ luồng "đặt chuyến xe" từ mở app đến hoàn tất. Đặt tên 6–8 event theo chuẩn
Object_Action, snake_case, danh từ số ít, động từ quá khứ.
- Phân tách event và property. Cho danh sách event "xấu" sau, hãy gộp lại dùng property:
Ride_Booked_Bike,Ride_Booked_Car,Ride_Booked_Premium,Ride_Cancelled_ByUser,Ride_Cancelled_ByDriver. Viết lại thành tối đa 2 event với các property phù hợp.
- Lập tracking plan mini. Với 3 event quan trọng nhất từ bài 1, tạo một bảng (Google Sheet) gồm cột: tên event, mô tả, điều kiện kích hoạt, property, kiểu dữ liệu, giá trị hợp lệ, nền tảng. Đánh dấu rõ đâu là event property, đâu là user property.
- Phản biện. Tìm trong một app bạn đang dùng (hoặc dự án của bạn) một event mà bạn nghi ngờ được đặt tên kém. Giải thích nó vi phạm nguyên tắc nào và đề xuất tên mới.
Tóm tắt
- Event Taxonomy là bộ quy tắc đặt tên và tổ chức sự kiện nhất quán; Tracking Plan là tài liệu sống cụ thể hóa quy tắc đó thành hợp đồng giữa PM và Engineer.
- Quy ước cốt lõi: cấu trúc
Object_Action(ví dụSignup_Completed), snake_case nhất quán, danh từ số ít, động từ thì quá khứ. - Phân biệt rõ event (loại hành động, giữ tinh gọn) và property (chi tiết của hành động, linh hoạt). Biến thể luôn là property, không phải event mới.
- Xây từ câu hỏi nghiệp vụ đi xuống, không từ "track cái gì" đi lên. Giữ số event trong khoảng vài chục, không phải hàng nghìn.
- Làm tracking plan trước khi code, đưa nó vào Definition of Done, và duy trì governance để tránh hỗn loạn.
- Taxonomy sạch là nền móng cho mọi thứ phía sau: funnel, cohort, A/B test, attribution. Dữ liệu rác từ đầu thì mọi phân tích đều rác.