Tracking Plan & Instrumentation

Vì sao phải đo trước khi ra mắt, không phải sau

Trang này là bản thực hành của kỹ năng "Event tracking (khái niệm)". Nếu bạn chưa quen event và property là gì, đọc bài đó trước; ở đây giả định bạn đã biết, và đi vào cách viết, kiểm và dùng một tracking plan thật.

Event không đo ngược được quá khứ. Nếu ngày ra mắt chưa có event, hai tuần đầu — thời điểm có nhiều người thử nhất và nhiều điều để học nhất — sẽ mất vĩnh viễn. Không có cách nào lấy lại, dù đội data giỏi đến đâu.

Dòng cuối thường bị quên: rollout theo nấc cho bạn một nhóm đối chứng miễn phí — người chưa được bật. Nếu không đo từ nấc đầu tiên, khi lên 100% bạn mất nó mãi mãi.

Ai làm việc này? Ở công ty có đội data, PM viết câu hỏi và chỉ số, data analyst cùng viết tracking plan, engineer cài đặt. Ở công ty nhỏ hơn, PM hoặc BA viết cả plan. Dù ở đâu, người sở hữu tracking plan là người sẽ phải trả lời câu hỏi "tính năng này có hiệu quả không" — thường là PM.

Từ chỉ số thành công xuống từng event

Sai lầm phổ biến nhất là bắt đầu từ màn hình: "màn hình này có ba nút, track cả ba". Làm vậy bạn sẽ có rất nhiều event và không trả lời được câu nào. Bắt đầu từ câu hỏi bạn sẽ phải trả lời sau ra mắt, rồi đi ngược xuống.

• Bước 1 — Viết các câu hỏi readout. "Bao nhiêu người thấy tính năng? Bao nhiêu người thử? Họ bỏ ở bước nào? Ai dùng lại sau 7 ngày? Nó có ăn mất của tính năng khác không?"
• Bước 2 — Mỗi câu hỏi thành một chỉ số, có công thức: tử số là gì, mẫu số là gì.
• Bước 3 — Mỗi phần của công thức cần một event, với những property cần để chia nhóm.
• Bước 4 — Gạch những event không phục vụ câu hỏi nào. Nếu ai đó muốn giữ, yêu cầu họ viết câu hỏi mà event đó trả lời.

Ví dụ (giả định): một sàn thương mại điện tử thêm tính năng "Mua chung" — rủ bạn bè cùng mua để được giá thấp hơn.

Để ý dòng cuối: nó không cần event mới, chỉ cần thêm property vào 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 đó.

Viết tracking plan: đặt tên, property, định danh, nơi bắn

Tracking plan là một bảng, mỗi event một dòng. Nó là hợp đồng giữa PM, data và engineer: engineer cài đúng như bảng, data dựng dashboard dựa trên bảng, và không ai phải đoán tên event lúc 10 giờ tối trước readout.

Quy ước đặt tên. Chọn một kiểu và giữ nó ở mọi nơi. Kiểu phổ biến và dễ đọc là đối_tượng_hành_động ở thì quá khứ, chữ thường, gạch dưới: group_buy_created, invite_sent, order_placed. Quy tắc đi kèm:

• Tên event và property bằng tiếng Anh không dấu, kể cả khi đội nói tiếng Việt — công cụ phân tích và câu SQL xử lý dấu kém, và người mới dễ gõ sai.
• Một hành động, một event; khác nhau thì dùng property. Không tạo buy_button_red_clicked và buy_button_blue_clicked — tạo buy_button_clicked với property variant.
• Không đưa giá trị thay đổi vào tên event: không có step_3_completed, chỉ có onboarding_step_completed với step_number.
• Không bao giờ gửi dữ liệu cá nhân dạng thô — số điện thoại, CCCD, email — vào công cụ phân tích. Dùng mã định danh nội bộ.

Về định danh với sản phẩm B2B: với SaaS, người trả tiền là công ty, không phải từng người dùng. Mọi event cần cả user_id lẫn account_id; nếu không, bạn sẽ biết 400 người đã dùng tính năng mà không biết đó là 400 người ở 3 công ty hay ở 200 công ty — hai câu chuyện hoàn toàn khác nhau.

Mẫu tracking plan — bản trắng và ví dụ đã điền

Bản trắng, dán vào bảng tính của bạn — mỗi event một dòng:

TRACKING PLAN — [Tính năng] — Chủ: [tên] — Phiên bản: [ngày]
Câu hỏi readout: 1) ...  2) ...  3) ...

Event | Bắn khi (chính xác) | Nơi bắn | Property: kiểu, giá trị cho phép | Định danh | Phục vụ câu hỏi số | Trạng thái

Ví dụ đã điền (giả định): một phần mềm SaaS kế toán cho doanh nghiệp nhỏ thêm tính năng "Xuất hoá đơn điện tử hàng loạt". Câu hỏi readout: (1) bao nhiêu công ty thử, (2) bao nhiêu lần xuất thành công, lỗi chủ yếu ở đâu, (3) công ty dùng có giảm thời gian xuất hoá đơn không, (4) có công ty nào quay lại xuất từng tờ không.

TRACKING PLAN — Xuất hoá đơn hàng loạt — Chủ: PM Hoá đơn — v1.1

1. bulk_invoice_started
   Bắn khi: người dùng bấm "Xuất hàng loạt" và màn hình chọn hoá đơn mở ra
   Nơi bắn: web client
   Property: entry_point (string: invoice_list, dashboard_banner, menu)
   Định danh: user_id, account_id      Câu hỏi: 1

2. bulk_invoice_submitted
   Bắn khi: server nhận yêu cầu xuất hợp lệ
   Nơi bắn: server
   Property: batch_id (string), invoice_count (int, 1–500),
             template_type (string: standard, vat, sales)
   Định danh: user_id, account_id      Câu hỏi: 1, 2

3. bulk_invoice_completed
   Bắn khi: server nhận phản hồi cuối cùng từ nhà cung cấp hoá đơn điện tử
   Nơi bắn: server
   Property: batch_id, invoice_count, success_count (int), failed_count (int),
             top_error_code (string, null nếu không lỗi), duration_seconds (int)
   Định danh: user_id, account_id      Câu hỏi: 2, 3

4. invoice_issued   (event có sẵn — chỉ thêm property)
   Property mới: issue_mode (string: single, bulk), batch_id (null nếu single)
   Câu hỏi: 3, 4

Không track: hover, mở/đóng bộ lọc, cuộn danh sách — không phục vụ câu hỏi nào.
QA: data analyst kiểm trên staging trước ngày 20/9.

Ba điều đáng học từ ví dụ: event quan trọng (2, 3) bắn từ server vì liên quan trạng thái thật; câu hỏi 4 được trả lời bằng một property thêm vào event cũ chứ không phải event mới; và có hẳn một dòng "Không track" — ghi ra điều bạn cố ý không đo cũng quan trọng như ghi điều bạn đo.

QA tracking — kiểm như kiểm tính năng

Tracking hỏng là tracking hỏng âm thầm: không có màn hình lỗi, không có khách phàn nàn. Bạn chỉ phát hiện vào ngày readout, khi con số trông vô lý. Vì vậy tracking cần tiêu chí chấp nhận và được QA như mọi phần khác của tính năng.

Đưa tracking vào tiêu chí chấp nhận của ticket: "Khi người dùng bấm Xuất hàng loạt, event bulk_invoice_started bắn một lần với entry_point đúng." Ticket chưa qua dòng này thì chưa xong, giống như chưa qua kiểm thử chức năng.

Sau ra mắt, kiểm lại trong 48 giờ đầu: so số event với số thật ở cơ sở dữ liệu. Lệch dưới 5% với event phía client thường chấp nhận được; lệch lớn hơn cần tìm nguyên nhân trước khi dùng số để quyết định.

Dashboard cho readout ra mắt

Dashboard ra mắt không phải dashboard tổng của công ty. Nó trả lời đúng các câu hỏi readout, theo thứ tự, và nên dựng xong — với số liệu thử từ staging — trước ngày ra mắt.

Khối cuối cùng hiếm ai làm và cứu được rất nhiều readout. Một biểu đồ nhỏ đếm số event mỗi ngày sẽ cho bạn biết ngay khi một bản cập nhật ứng dụng làm hỏng tracking — trước khi bạn trình bày một con số sai cho ban lãnh đạo.

Lỗi thường gặp

Luyện kỹ năng này trong tuần này

• Chọn tính năng sắp ra mắt gần nhất và viết 4–5 câu hỏi readout. Đi ngược xuống chỉ số và event theo bảng ở trên. Bạn vừa có bản nháp tracking plan.
• Mở công cụ phân tích của công ty, liệt kê 20 event được bắn nhiều nhất. Có bao nhiêu kiểu đặt tên khác nhau? Có event nào không ai biết dùng để làm gì?
• So số đơn hoặc số đăng ký của hôm qua giữa công cụ phân tích và cơ sở dữ liệu. Lệch bao nhiêu? Bạn có biết vì sao không?
• Thêm một dòng tracking vào tiêu chí chấp nhận của ticket bạn viết tuần này, và nhờ QA kiểm dòng đó như mọi dòng khác.
• Dựng một biểu đồ "số event mỗi ngày" cho ba event quan trọng nhất của sản phẩm. Lần tới tracking hỏng, bạn sẽ là người đầu tiên biết.