Viết tracking plan trước khi code xong

Chuẩn bị trước

• Mô tả tính năng và luồng màn hình — bản thiết kế hoặc wireframe là đủ
• Chỉ số thành công của tính năng, và North Star hoặc chỉ số cấp trên mà nó đóng góp
• Danh sách event đang có và quy ước đặt tên của sản phẩm (hỏi đội data)
• Một bảng tính trống, mỗi event một dòng

Các bước

1. Bước 1 Viết câu hỏi readout trước khi nghĩ đến event

   Viết 3–5 câu bạn sẽ phải trả lời hai tuần sau ra mắt. Phủ đủ: bao nhiêu người thấy, bao nhiêu người thử, họ bỏ ở đâu, tính năng có tạo kết quả kinh doanh không, và có ăn mất của tính năng khác không. Bắt đầu từ màn hình ("có ba nút thì track ba nút") cho ra nhiều event mà không trả lời được câu nào.

   Ví dụ

   Bối cảnh (giả định): BếpVui là ứng dụng công thức nấu ăn với 600.000 người dùng hoạt động mỗi tháng, kiếm tiền từ đơn đi chợ giao trong 2 giờ qua siêu thị đối tác. Tính năng mới: Đi chợ theo thực đơn tuần — chọn 3–7 món, ứng dụng gộp nguyên liệu thành một danh sách, bỏ những thứ đã có trong bếp, đặt giao một lần. North Star của công ty: số đơn đi chợ hoàn thành mỗi tuần. PM Hà viết năm câu hỏi readout:

   1. Bao nhiêu người thấy và mở thực đơn tuần?
   2. Bao nhiêu người đi hết từ chọn món đến đặt đơn, và bỏ ở bước nào?
   3. Đơn từ thực đơn tuần có giá trị cao hơn đơn thường không?
   4. Người dùng có quay lại lập thực đơn tuần sau không?
   5. Tính năng có ăn mất đơn đi chợ theo từng món không?

2. Bước 2 Đổi mỗi câu hỏi thành một chỉ số có tử số và mẫu số

   Với mỗi câu, viết công thức: tử số, mẫu số, khung thời gian. Không viết được mẫu số nghĩa là câu hỏi chưa đủ rõ. Nối ít nhất một chỉ số với North Star hoặc chỉ số cấp trên — đó là con số người quyết sẽ hỏi đầu tiên. Câu hỏi về "ăn mất" cần một nhóm đối chứng; quyết từ bây giờ, không phải lúc readout.

   Ví dụ

   Câu	Chỉ số	Công thức
   1	Tỉ lệ mở	Người mở màn thực đơn tuần / người thấy lối vào, trong 14 ngày
   2	Tỉ lệ hoàn thành	Người đặt đơn từ thực đơn / người mở; phễu 4 bước: mở, thêm món, tạo danh sách, đặt
   3	Giá trị đơn	Giá trị trung bình đơn thực đơn tuần so với đơn thường, cùng tuần
   4	Quay lại	Người tạo danh sách ở tuần thứ 2 / người tạo ở tuần thứ 1
   5	Ăn mất	Đơn đi chợ mỗi người ở nhóm được bật so với nhóm giữ lại 10% chưa bật

   Câu 3 và câu 5 nối thẳng với North Star: chúng nói tính năng làm tăng số đơn, hay chỉ chuyển đơn từ chỗ này sang chỗ khác.

3. Bước 3 Liệt kê event cho từng phần của công thức

   Mỗi tử số và mẫu số cần một event, hoặc một property trên event đã có. Trước khi tạo event mới, xem danh sách event cũ: thêm property vào event cũ thường đáng giá hơn tạo event mới, vì nó giữ được khả năng so với dữ liệu trước ra mắt.

   Ví dụ

   Event	Mới hay có sẵn	Phục vụ câu
   meal_plan_entry_viewed	Mới	1
   meal_plan_opened	Mới	1, 2
   meal_plan_recipe_added	Mới	2
   meal_plan_list_generated	Mới	2, 4
   grocery_order_placed	Có sẵn — thêm property	2, 3, 5
   rollout_group (thuộc tính người dùng)	Có sẵn từ hệ thống feature flag	5

   Sáu dòng cho năm câu hỏi. Câu 4 không cần event riêng: tính được từ meal_plan_list_generated theo tuần.

4. Bước 4 Đặt tên, ghi thời điểm bắn chính xác và nơi bắn

   Theo quy ước của công ty; nếu chưa có, dùng đối_tượng_hành_động ở thì quá khứ, chữ thường, tiếng Anh không dấu. Ghi thời điểm bắn chính xác — lúc bấm hay lúc server xác nhận — vì hai thời điểm đó có thể chênh nhau nhiều. Event dính đến tiền hoặc trạng thái thật bắn từ server; phía ứng dụng mất event khi mạng yếu.

   Ví dụ

   Event	Bắn khi	Nơi bắn
   meal_plan_entry_viewed	Thẻ "Thực đơn tuần" hiện ≥ 50% trên màn hình chính	Ứng dụng
   meal_plan_opened	Màn thực đơn tuần tải xong	Ứng dụng
   meal_plan_recipe_added	Một món được thêm vào thực đơn	Ứng dụng
   meal_plan_list_generated	Server trả về danh sách nguyên liệu đã gộp	Server
   grocery_order_placed	Siêu thị đối tác xác nhận đơn — không phải lúc bấm "Đặt"	Server

   Mẹo: Ở BếpVui, lúc bấm "Đặt" và lúc đối tác xác nhận chênh nhau khoảng 8% vì hết hàng và thanh toán lỗi. Chọn sai thời điểm thì câu 3 sai theo.

5. Bước 5 Viết property có kiểu, giá trị cho phép và định danh

   Với mỗi property: tên, kiểu dữ liệu, giá trị cho phép. Chỉ thêm property dùng để chia nhóm cho câu hỏi đã viết. Ghi định danh: user_id, anonymous_id trước đăng nhập; với sản phẩm B2B thêm account_id. Không bao giờ gửi số điện thoại, email hay địa chỉ dạng thô vào công cụ phân tích.

   Ví dụ

   meal_plan_list_generated            (server)
     plan_id           string
     recipe_count      int, 1–7
     ingredient_count  int
     removed_owned     int — số nguyên liệu người dùng đánh dấu đã có
     Định danh: user_id                 Câu: 2, 4
   
   grocery_order_placed                (có sẵn — thêm 2 property)
     source            string: single_recipe, meal_plan, search, reorder
     plan_id           string, null nếu source khác meal_plan
     order_value_vnd   int (đã có)
     Định danh: user_id                 Câu: 2, 3, 5
   
   Không gửi: địa chỉ giao, số điện thoại — dùng address_id nội bộ.

6. Bước 6 Gạch event thừa và viết dòng "Không track"

   Đọc lại từng dòng và hỏi: event này phục vụ câu hỏi số mấy? Không có số thì gạch. Nếu ai muốn giữ, nhờ họ viết câu hỏi mà event đó trả lời. Cuối bảng, ghi rõ những gì cố ý không đo và lý do — để người sau không tưởng là bị quên.

   Ví dụ

   Designer muốn track mỗi lần vuốt danh sách món gợi ý và mỗi lần đổi khẩu phần. Không câu hỏi nào cần hai event đó; Hà gạch, và designer đồng ý khi thấy dòng "xem lại" bên dưới.

   Không track: vuốt danh sách gợi ý, đổi khẩu phần, mở chi tiết
   nguyên liệu. Lý do: không phục vụ câu 1–5.
   Xem lại nếu readout cho thấy người dùng bỏ nhiều ở bước thêm món.

7. Bước 7 Đưa tracking vào ticket và hẹn QA trước ngày ra mắt

   Mỗi event thành một dòng tiêu chí chấp nhận trong ticket tương ứng — ticket chưa qua dòng đó thì chưa xong. Hẹn data analyst QA trên staging: bắn đúng một lần, đúng kiểu, định danh đúng, khớp với cơ sở dữ liệu. Dựng dashboard readout bằng số liệu staging trước ngày ra mắt.

   Ví dụ

   Ticket "Tạo danh sách đi chợ từ thực đơn" có thêm dòng: Khi server trả về danh sách gộp, meal_plan_list_generated bắn đúng một lần với plan_id, recipe_count và removed_owned; tải lại màn hình không bắn lại. QA tracking hẹn ngày 18/11, ra mắt 25/11.

   Ngày QA, data phát hiện grocery_order_placed trên iOS thiếu plan_id khi người dùng sửa giỏ trước khi đặt. Sửa mất một ngày. Nếu phát hiện vào ngày readout, câu 3 và câu 5 sẽ không trả lời được.

Bạn xong khi

• Mỗi event phục vụ ít nhất một câu hỏi readout có số thứ tự
• Mỗi câu hỏi có chỉ số với tử số, mẫu số và khung thời gian; ít nhất một chỉ số nối với North Star
• Event dính đến tiền và trạng thái bắn từ server, thời điểm bắn ghi chính xác
• Property có kiểu và giá trị cho phép; không có dữ liệu cá nhân dạng thô
• Tracking nằm trong tiêu chí chấp nhận của ticket và đã có ngày QA trước ra mắt

Lỗi thường gặp

Tiếp theo

Kỹ năng Tracking Plan & Instrumentation có đủ phần QA tracking, định danh cho sản phẩm B2B và cách dựng dashboard readout. Nếu event, property, user_id còn mới với bạn, đọc Event tracking (khái niệm) trước. Để chọn chỉ số thành công và nối nó với North Star ngay từ đầu, xem Metrics & North Star. Tính năng tiếp theo, bắt đầu từ mẫu tracking plan trong kỹ năng Tracking Plan & Instrumentation.