Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn là PM của một ứng dụng fintech Việt Nam. Sáng thứ Hai, CEO nhắn: "Tuần rồi có bao nhiêu người hoàn tất KYC?". Bạn mở Amplitude, gõ tên event và... phát hiện có tới ba event khác nhau cùng nói về KYC: kyc_complete, KYCCompleted, và finish_verification. Cái do team Android bắn, cái do team iOS bắn, cái do bạn dev backend tự đặt tên. Kết quả: không có con số nào đáng tin, và bạn mất cả buổi chiều để đi hỏi từng người.
Đây chính là bức tranh của một tổ chức không có tracking plan, hoặc có mà không ai thực sự triển khai nó. Trong suốt khóa học, chúng ta đã học cách thiết kế event taxonomy (Bài 7), viết payload chuẩn (Bài 8), phân tích funnel, retention, cohort. Nhưng tất cả những phân tích tuyệt vời đó chỉ đáng tin khi dữ liệu đầu vào sạch và nhất quán. Và thứ đảm bảo điều đó, biến bản thiết kế trên giấy thành dữ liệu thật chảy vào Mixpanel/Amplitude, chính là việc triển khai tracking plan (implementing tracking plan).
Bài này không nói về việc thiết kế event (bạn đã học rồi), mà nói về việc biến tracking plan thành một tài liệu sống, một nguồn sự thật duy nhất (single source of truth) được thực thi trong toàn tổ chức — từ PM, dev, data analyst đến QA. Đây là kỹ năng phân biệt một PM "biết dùng công cụ analytics" với một PM "xây dựng được nền tảng dữ liệu cho cả công ty".
Khái niệm cốt lõi
Tracking plan là gì?
Tracking plan là một tài liệu có cấu trúc, liệt kê đầy đủ mọi event và property mà sản phẩm sẽ theo dõi, kèm theo định nghĩa rõ ràng cho từng cái. Nó trả lời được các câu hỏi:
- Chúng ta đang track những event nào? Mỗi event nghĩa là gì?
- Mỗi event có những property nào? Kiểu dữ liệu (data type) là gì? Bắt buộc hay tùy chọn?
- Ai là chủ sở hữu (owner) của event đó?
- Event này được bắn ở đâu (web, iOS, Android, server)?
- Trạng thái của nó (đang thiết kế, đã implement, đã deprecated)?
Ba vai trò của tracking plan
Thứ nhất — Source of truth (nguồn sự thật duy nhất). Khi có tranh cãi "event này track cái gì?", câu trả lời không nằm trong đầu một dev nào đó đã nghỉ việc, mà nằm trong tracking plan. Không có tài liệu này, kiến thức về dữ liệu trở thành "tribal knowledge" — tồn tại trong đầu vài người và biến mất khi họ rời đi.
Thứ hai — Hợp đồng giữa các bên (contract). Tracking plan là bản cam kết giữa PM (người cần số liệu), developer (người viết code bắn event), và data team (người phân tích). PM viết spec, dev implement đúng theo spec, data team dựa vào đó để build dashboard. Ai làm sai so với tracking plan là làm sai "hợp đồng".
Thứ ba — Công cụ quản trị chất lượng (governance). Tracking plan cho phép bạn kiểm soát việc thêm event mới, tránh tình trạng "event sprawl" — nơi mỗi tuần lại đẻ ra vài chục event rác không ai dùng.
Cấu trúc một tracking plan tối thiểu
Một dòng trong tracking plan thường gồm các cột sau:
| Trường | Ý nghĩa | Ví dụ |
|---|---|---|
| Event Name | Tên event, đặt theo convention thống nhất | Checkout Completed |
| Description | Event xảy ra khi nào | Khi user thanh toán thành công |
| Trigger | Hành động cụ thể kích hoạt | Nhấn nút "Đặt hàng", server trả 200 |
| Properties | Danh sách property + kiểu dữ liệu | order_value (number), payment_method (string) |
| Required? | Property bắt buộc hay không | order_value: bắt buộc |
| Platform | Nơi bắn event | Web, iOS, Android |
| Owner | Người chịu trách nhiệm | PM Growth |
| Status | Trạng thái vòng đời | Live / Proposed / Deprecated |
Naming convention — xương sống của tracking plan
Trước khi triển khai, bạn phải chốt một quy ước đặt tên và bắt buộc mọi người tuân theo. Ví dụ phổ biến là chuẩn "Object-Action" của Segment: Object Action, ví dụ Product Viewed, Order Completed, Signup Started. Chọn thì bằng thì quá khứ (Completed, không phải Complete), Title Case hay snake_case đều được — miễn là nhất quán tuyệt đối. Tracking plan chính là nơi convention này được viết ra và được thực thi.
Tình huống thực tế
Ví dụ 1: Sàn TMĐT giả định "Chợ Sạch" — từ hỗn loạn đến trật tự
Chợ Sạch là một startup TMĐT thực phẩm sạch ở TP.HCM, 25 người, dùng Mixpanel. Sau một năm, họ có 340 event trong Mixpanel. Khi PM mới vào, cô ấy làm một cuộc audit và phát hiện: chỉ 40 event thực sự được dùng trong dashboard, 300 event còn lại là rác. Tệ hơn, có 5 event khác nhau đều mô tả hành động "thêm vào giỏ": add_to_cart, AddToCart, cart_add, product_added_cart, them_gio_hang.
Nguyên nhân? Không hề có tracking plan. Mỗi dev khi làm feature mới tự nghĩ ra tên event.
Cách họ xử lý: Team dành 2 tuần làm một tracking plan trên Google Sheets, chốt convention Object Action Title Case. Họ gom 5 event "add to cart" thành một event chuẩn duy nhất Product Added, với property product_id, product_name, price, quantity, source (list/detail/search). Sau đó họ tạo quy trình: mọi event mới phải được duyệt trong tracking plan trước khi dev viết code.
Bài học rút ra: Tracking plan không chỉ giúp làm sạch quá khứ, mà quan trọng hơn là ngăn hỗn loạn trong tương lai. Việc gom event trùng lặp giúp báo cáo "tỉ lệ thêm giỏ → mua" của họ lần đầu tiên chính xác và các bên đồng thuận về con số.
Ví dụ 2: Ứng dụng gọi xe — tracking plan như hợp đồng cross-team
Một công ty gọi xe Đông Nam Á (bối cảnh tương tự Gojek/Be) có ba team riêng: Passenger App (iOS/Android), Driver App, và Web booking. Cùng một hành động "hoàn tất chuyến đi", ba team bắn ba property khác nhau: team Passenger dùng fare là số (45000), team Driver dùng fare là chuỗi ("45,000 VND"), team Web thì gọi là trip_amount.
Khi data team cố tính tổng doanh thu qua event, họ không thể SUM được vì kiểu dữ liệu lẫn lộn giữa số và chuỗi.
Cách họ xử lý: Họ đưa tracking plan vào công cụ chuyên dụng (Amplitude có tính năng Govern, Segment có Protocols). Trong tracking plan, họ định nghĩa cứng: event Trip Completed, property fare luôn là kiểu number, đơn vị VND, không format. Công cụ bật chế độ validation: bất kỳ event nào gửi lên mà fare là chuỗi sẽ bị đánh dấu "violation" và cảnh báo ngay cho team.
Bài học rút ra: Với sản phẩm đa nền tảng, tracking plan phải là hợp đồng được máy kiểm tra tự động (automated validation), chứ không thể tin vào việc con người tự giác. Một property sai kiểu dữ liệu có thể phá hỏng toàn bộ revenue analytics.
Ví dụ 3: MoMo — quản trị tracking plan ở quy mô lớn
Ở quy mô một siêu ứng dụng như MoMo, với hàng trăm feature (ví, thanh toán, vay, đầu tư, mini-app), số lượng event lên tới hàng nghìn. Không thể quản lý bằng một Google Sheet. Giả định về cách một tổ chức lớn tổ chức tracking plan: họ chia tracking plan theo domain (Payment, Lending, Wallet...), mỗi domain có một owner. Việc thêm event mới đi qua một quy trình pull request — giống như review code — nơi data governance team duyệt tên event, kiểm tra trùng lặp, và xác nhận property.
Bài học rút ra: Càng lớn, tracking plan càng cần phân quyền, phân domain, và tự động hóa quy trình duyệt. Nó chuyển từ "một file" thành "một quy trình vận hành". (Chủ đề Center of Excellence được đào sâu ở Bài 52, ở đây ta chỉ nhìn từ góc độ triển khai tracking plan.)
Hướng dẫn từng bước
Dưới đây là quy trình 7 bước để triển khai một tracking plan từ con số 0.
Bước 1 — Audit hiện trạng (nếu đã có dữ liệu). Trước khi viết mới, hãy xuất danh sách event hiện có trong Mixpanel/Amplitude. Đánh dấu event nào đang được dùng trong dashboard/report, event nào là rác. Đây là cơ sở để biết cái gì giữ, cái gì gom, cái gì bỏ.
Bước 2 — Chốt naming convention. Họp với dev và data team, thống nhất một quy ước duy nhất (khuyến nghị Object Action Title Case, property snake_case). Viết convention này ngay dòng đầu tiên của tracking plan. Đây là bước bị bỏ qua nhiều nhất nhưng lại quan trọng nhất.
Bước 3 — Xuất phát từ câu hỏi kinh doanh, không phải từ event. Đừng liệt kê "chúng ta có thể track gì". Hãy hỏi ngược: "Chúng ta cần trả lời những câu hỏi nào?" (tỉ lệ chuyển đổi funnel đăng ký? retention D7? doanh thu theo kênh?). Từ mỗi câu hỏi, suy ra event và property tối thiểu cần có. Cách này giúp bạn tránh track thừa.
Bước 4 — Viết spec cho từng event. Với mỗi event, điền đủ các cột: name, description, trigger, properties (kèm data type, required/optional, ví dụ giá trị), platform, owner. Đặc biệt chú ý data type — nguồn gốc của phần lớn bug analytics.
Bước 5 — Review chéo (cross-functional review). Cho dev đọc để đảm bảo họ hiểu và implement được, cho data team đọc để đảm bảo đủ dữ liệu phân tích. Đây là lúc "hợp đồng" được ký kết.
Bước 6 — Implement và validate. Dev bắn event theo đúng spec. Lý tưởng nhất là dùng công cụ validation (Amplitude Govern, Segment Protocols, hoặc Avo/RudderStack) để kiểm tra tự động dữ liệu thực tế có khớp tracking plan không. QA cũng nên có checklist test event dựa trên tracking plan.
Bước 7 — Duy trì như tài liệu sống. Đây là bước quyết định thành bại. Tracking plan chết ngay khi nó lỗi thời. Hãy đặt quy tắc: không event mới nào được lên production nếu chưa có trong tracking plan. Gắn việc cập nhật tracking plan vào Definition of Done của mỗi feature. Review tracking plan định kỳ hàng quý để deprecate event không dùng.
Lỗi thường gặp & mẹo
Lỗi 1 — Viết tracking plan xong rồi bỏ đó. Đây là cái chết phổ biến nhất. Tracking plan được làm hoành tráng lúc đầu, rồi ba tháng sau không ai cập nhật, và nó trở nên vô dụng. Mẹo: Gắn nó vào quy trình (Definition of Done, PR review), đừng dựa vào ý chí.
Lỗi 2 — Để dev tự đặt tên event lúc code. Khi tên event ra đời trong lúc viết code, convention sẽ vỡ ngay. Mẹo: Tên event phải được PM chốt trong tracking plan trước, dev chỉ copy y nguyên.
Lỗi 3 — Bỏ qua data type của property. order_value: "50.000đ" (chuỗi) và order_value: 50000 (số) trông giống nhau nhưng cái đầu khiến bạn không bao giờ tính được doanh thu. Mẹo: Trong tracking plan, luôn ghi rõ data type và một giá trị ví dụ. Số thì để số thuần, không format, không đơn vị.
Lỗi 4 — Track quá nhiều ngay từ đầu. Nhiều team cố track "mọi thứ có thể" và ngợp trong dữ liệu rác. Mẹo: Bắt đầu từ 20-30 event cốt lõi trả lời được các câu hỏi kinh doanh quan trọng nhất. Mở rộng dần.
Lỗi 5 — Không có owner cho event. Event không chủ thì không ai chịu trách nhiệm khi nó hỏng. Mẹo: Mỗi event bắt buộc có một owner rõ tên.
Mẹo nâng cao — Dùng công cụ chuyên dụng khi đủ lớn. Google Sheets ổn cho dưới 50 event. Khi vượt qua đó, cân nhắc Amplitude Govern, Segment Protocols, hoặc Avo — chúng cho phép validate tự động và tạo code snippet type-safe từ tracking plan, giảm sai sót do con người.
Mẹo — Versioning tracking plan. Khi event thay đổi (thêm property, đổi ý nghĩa), đừng sửa đè im lặng. Ghi lại thay đổi và version, để data team biết dữ liệu trước/sau mốc nào khác nhau.
Bài tập thực hành
Bài tập 1 — Viết mini tracking plan. Chọn một sản phẩm bạn quen (app giao đồ ăn, app đọc báo...). Viết tracking plan cho luồng đăng ký gồm 4 event: Signup Started, OTP Verified, Profile Completed, Signup Completed. Với mỗi event, điền đủ: description, trigger, ít nhất 3 property kèm data type và required/optional, platform, owner.
Bài tập 2 — Phát hiện violation. Dưới đây là 4 event thực tế được bắn lên. Chỉ ra chúng vi phạm tracking plan chuẩn (Object Action Title Case, price là number) ở điểm nào và sửa lại:
addToCartvớiprice: "150,000đ"Product_Viewedvớiprice: 150000checkout completevớitotal: nullPURCHASEvớiamount: 150000
Tóm tắt
Tracking plan là nguồn sự thật duy nhất cho toàn bộ hoạt động instrumentation của sản phẩm — cuốn từ điển định nghĩa mọi event và property, kèm data type, owner, platform, và trạng thái. Nó đóng ba vai trò: source of truth, hợp đồng giữa PM–dev–data, và công cụ governance chống event rác.
Điều làm nên hoặc phá vỡ một tracking plan không phải là lúc viết nó, mà là việc triển khai và duy trì nó như một tài liệu sống: chốt naming convention từ đầu, xuất phát từ câu hỏi kinh doanh, viết spec chặt chẽ (đặc biệt là data type), review chéo, validate tự động, và tuyệt đối không cho event nào lên production nếu chưa nằm trong plan.
Từ Chợ Sạch dọn 300 event rác, tới app gọi xe đồng bộ property fare, tới cách một siêu ứng dụng phân domain và duyệt event như review code — bài học chung là: dữ liệu sạch không tự nhiên mà có, nó là kết quả của kỷ luật triển khai tracking plan. Là PM, khi bạn xây dựng và duy trì được nền tảng này, mọi phân tích funnel, retention, revenue ở các bài sau mới thực sự đáng tin. Đó là công việc thầm lặng nhưng quyết định chất lượng của cả một tổ chức data-driven.