Vì sao đo lường phải xong trước ngày ra mắt
Ba tuần sau khi ra mắt, lãnh đạo hỏi: "Tính năng mới có hiệu quả không?" Và đội phát hiện: sự kiện "đặt cả giỏ" có được ghi, nhưng không ghi giỏ có bao nhiêu món gợi ý và bao nhiêu món bị xoá; không phân biệt được đơn từ giỏ nhanh với đơn chọn tay; và nhóm không được bật tính năng thì không ai đánh dấu. Câu hỏi đơn giản nhất không có câu trả lời.
Đo lường không thể thêm sau. Dữ liệu của ba tuần đầu — giai đoạn quan trọng nhất — đã mất. Đó là lý do tracking plan phải được viết và review trước khi code tính năng, và được kiểm tra trên môi trường thử trước nấc rollout đầu tiên.
Hướng dẫn chi tiết: Viết tracking plan. Kỹ năng: Tracking Plan & Instrumentation.
Bắt đầu từ câu hỏi, không từ sự kiện
Sai lầm thường gặp là liệt kê mọi nút bấm và ghi lại hết. Kết quả là hàng trăm sự kiện không ai dùng, trong khi câu hỏi quan trọng vẫn không có dữ liệu. Thứ tự đúng là:
- Viết ra các câu hỏi mà readout cần trả lời
- Với mỗi câu hỏi, xác định chỉ số
- Với mỗi chỉ số, xác định sự kiện và thuộc tính cần có
- Chỉ ghi những sự kiện phục vụ một câu hỏi
| Câu hỏi readout | Chỉ số | Cần đo gì |
|---|---|---|
| Tiệm có đặt lại đều hơn không? | Tỉ lệ đặt lại trong 14 ngày, nhóm bật so với nhóm không bật | Mỗi đơn, kèm nhóm thử nghiệm của tiệm |
| Đơn có lớn hơn không? | Giá trị trung bình mỗi đơn | Giá trị đơn, nguồn đơn (giỏ nhanh hay chọn tay) |
| Chủ tiệm có tin gợi ý không? | Tỉ lệ món gợi ý được giữ lại | Số món gợi ý, số món bị xoá trước khi đặt |
| Có đặt nhầm không? | Tỉ lệ huỷ trong 15 phút | Sự kiện huỷ, thời gian từ lúc đặt |
| Nhà phân phối có ổn không? | Tỉ lệ đơn bị nhà phân phối huỷ | Trạng thái đơn từ phía nhà phân phối |
Tracking plan của "Nhập hàng nhanh"
| Sự kiện | Khi nào bắn | Thuộc tính | Phục vụ câu hỏi |
|---|---|---|---|
quick_cart_viewed | Chủ tiệm mở giỏ gợi ý | shop_id, items_suggested, cart_value, load_ms | Tin gợi ý; hiệu năng |
quick_cart_item_removed | Xoá một món khỏi giỏ gợi ý | shop_id, sku, position | Tin gợi ý |
quick_cart_ordered | Bấm "đặt cả giỏ" và đơn tạo thành công | shop_id, order_id, items_kept, items_removed, order_value | Giá trị đơn; tin gợi ý |
order_created (đã có) | Mọi đơn | Thêm source: quick_cart hoặc manual | Phân biệt nguồn |
order_cancelled (đã có) | Huỷ đơn | Thêm minutes_since_created, cancelled_by | Đặt nhầm; nhà phân phối |
quick_cart_error | Lỗi khi tạo đơn từ giỏ | shop_id, error_code, app_version, device_model | Tiêu chí rollback |
- Sửa sự kiện có sẵn thay vì tạo mới.
order_createdđã tồn tại; thêm thuộc tínhsourcerẻ hơn và giữ được so sánh với dữ liệu cũ. - Nhóm thử nghiệm phải được ghi. Mỗi tiệm được gắn nhãn đang ở nấc nào và có được bật hay không. Không có nhãn này, không thể so sánh nhóm bật với nhóm không bật — và mọi so sánh trước/sau sẽ lẫn với mùa vụ, khuyến mãi, ngày lễ.
Quy tắc đặt tên và thuộc tính
Tracking plan chỉ có ích nếu dữ liệu sạch. Một vài quy tắc tối thiểu:
- Tên sự kiện dạng
đối_tượng_hành_độngở thì quá khứ:quick_cart_ordered, không phảiclick_order_button - Ghi kết quả, không ghi thao tác: sự kiện bắn khi đơn tạo thành công, không phải khi nút được bấm
- Mỗi thuộc tính có kiểu dữ liệu và ví dụ giá trị
- Mỗi sự kiện có một người chịu trách nhiệm kiểm tra
Dashboard ra mắt: hai lớp
Phong dựng một dashboard có hai lớp, phục vụ hai mục đích khác nhau:
| Lớp | Mục đích | Chỉ số | Ai xem, khi nào |
|---|---|---|---|
| Sức khoẻ | Quyết định rollback | Tỉ lệ lỗi, đơn chờ, huỷ 15 phút, thời gian tải, cuộc gọi support | Người trực, mỗi giờ trong lúc rollout |
| Kết quả | Trả lời readout | Đặt lại 14 ngày, giá trị đơn, tỉ lệ giữ món gợi ý | PM, mỗi tuần |
Kiểm tra trước khi tin
Trước nấc 0, Hà và Phong cùng chạy một kịch bản: đặt 10 đơn thử trên staging, mỗi đơn xoá một số món khác nhau, rồi so số liệu trên dashboard với những gì đã làm. Lần đầu, items_removed luôn bằng 0 — app ghi giá trị trước khi người dùng xoá. Lỗi này được sửa trước khi có người dùng thật. Nếu phát hiện sau, toàn bộ câu hỏi "chủ tiệm có tin gợi ý không" sẽ không trả lời được.
Đưa bước kiểm tra này vào checklist sẵn sàng (bài 4) với bằng chứng là ảnh chụp dashboard khớp với kịch bản thử.
Làm ngay
Viết ba câu hỏi mà readout của tính năng bạn sắp ra mắt cần trả lời. Với mỗi câu, viết chỉ số và các sự kiện kèm thuộc tính cần có. Rồi mở công cụ analytics hiện tại và kiểm tra: những sự kiện đó đã tồn tại chưa, có đủ thuộc tính chưa, có ghi được nhóm bật/không bật không? Mỗi chỗ "chưa" là một ticket cần đưa vào sprint trước khi code tính năng.