Checklist tracking: kiểm thiết lập đo sau mỗi lần phát hành để số liệu không hỏng lặng lẽ

Bốn tầng cần kiểm, theo thứ tự

Bảng dưới đây xếp bốn tầng theo thứ tự kiểm, từ nơi hay hỏng nhất tới nơi ít hỏng nhất. Kiểm theo thứ tự này thì phần lớn sự cố lộ ra ở tầng đầu và bạn dừng được sớm.

Tầng thứ tư cần chờ nên hay bị bỏ, nhưng nó là tầng duy nhất phát hiện được các lỗi ở phía xử lý dữ liệu chứ không phải phía trình duyệt. Đặt lịch nhắc sau một ngày là cách rẻ nhất để không quên.

Khi nào phải kiểm, và kiểm sâu tới đâu

Không phải thay đổi nào cũng cần kiểm hết bốn tầng. Bảng dưới đây gợi ý mức kiểm tương ứng với từng loại thay đổi, để việc kiểm không trở thành gánh nặng khiến người phát hành bỏ luôn cả checklist sau vài lần.

Dòng thứ ba là dòng hay bị đánh giá thấp nhất. Đổi một trường trong biểu mẫu nghe như việc nhỏ, nhưng nó là nguyên nhân phổ biến nhất khiến sự kiện chuyển đổi ngừng bắn mà không ai biết.

Ví dụ một lần hỏng và cách phát hiện

Ví dụ dưới đây mô tả một dạng sự cố rất hay gặp và cách nó lộ ra. Số dùng ở đây là giả định để minh hoạ mức thiệt hại, nhưng dạng sự cố thì có thật và lặp lại thường xuyên.

Sự cố im lặng

Đây là một sự cố không báo lỗi mà vẫn làm sai số liệu. Sau khi phát hành bản mới vào thứ tư tuần 1, số chuyển đổi ghi nhận tụt từ 34 xuống 9 rồi 8. Trong khi đó bản ghi thật trong hệ thống bán hàng vẫn là 31, 29 và 33. Số thật giữ nhịp, chỉ có số đo hỏng.

• Ngày phát hành bản mới: Thứ tư tuần 1
• Số chuyển đổi tuần 1: 34
• Số chuyển đổi tuần 2: 9
• Số chuyển đổi tuần 3: 8
• Số bản ghi thật trong hệ thống bán hàng: 31, 29, 33

Bản ghi thật giữ nguyên nhịp trong khi số chuyển đổi đo được tụt 76%. Nguyên nhân là trang cảm ơn đổi đường dẫn, còn điều kiện bắn sự kiện vẫn trỏ vào đường dẫn cũ.

Ba tuần dữ liệu chuyển đổi hỏng và không lấy lại được. Nếu có bước đối chiếu hằng tuần với hệ thống bán hàng thì sự cố lộ ra sau bảy ngày thay vì hai mươi mốt ngày.

Chi phí của việc phát hiện muộn

Phần này quy sự cố ra tiền, để thấy phát hiện muộn tốn bao nhiêu. Dữ liệu hỏng trong 21 ngày. Một quyết định đã được đưa ra dựa trên dữ liệu sai, là cắt ngân sách một kênh. Số bị cắt nhầm là 18.000.000 VND, trong khi kênh đó thật ra vẫn chạy tốt, chỉ là sự kiện không còn được ghi nhận.

• Số ngày dữ liệu hỏng: 21
• Quyết định đã ra dựa trên dữ liệu đó: cắt ngân sách một kênh
• Ngân sách bị cắt nhầm: 18.000.000 VND

Kênh bị cắt thực ra vẫn đang chạy tốt, chỉ là sự kiện của nó không còn được ghi nhận.

Thiệt hại không nằm ở dữ liệu mất mà nằm ở quyết định sai dựa trên dữ liệu đó. Đây là lý do việc kiểm mười lăm phút có giá trị cao hơn nhiều so với thời gian nó tốn.

Bốn lỗi khiến việc kiểm không có tác dụng

Ba lỗi đầu làm việc kiểm bỏ sót đúng chỗ hay hỏng nhất. Lỗi thứ tư thì làm việc kiểm bị bỏ hẳn chỉ sau vài tuần, và đó là kết cục phổ biến nhất của mọi checklist được viết ra mà không ai cắt bớt cho vừa sức.

1. Chỉ kiểm trên máy tính. Phần lớn lưu lượng đến từ điện thoại, và nhiều lỗi chỉ xuất hiện trên đó.

   Sửa: Kiểm luồng chính trên điện thoại thật, không chỉ dùng chế độ mô phỏng của trình duyệt.

2. Kiểm bằng chế độ xem trước của trình quản lý thẻ. Chế độ đó bỏ qua một số điều kiện, và sự kiện chạy được ở đó vẫn có thể chết ở bản thật.

   Sửa: Kiểm thêm một lần trên bản thật sau khi đã phát hành.

3. Không đối chiếu với hệ thống bán hàng. Sự kiện vẫn bắn nhưng bắn sai chỗ hoặc bắn trùng, và chỉ đối chiếu mới lộ ra.

   Sửa: So tổng số chuyển đổi với số bản ghi thật mỗi tuần, theo dõi tỷ lệ lệch.

4. Checklist quá dài. Danh sách bốn mươi mục sẽ bị bỏ ngay từ lần phát hành thứ ba.

   Sửa: Giữ khoảng mười bốn mục, chia theo mức kiểm để việc nhỏ chỉ cần vài mục.

Dấu hiệu sớm của thiết lập đo hỏng

Bảng dưới đây liệt kê bốn dấu hiệu xuất hiện trước khi con số trở nên vô lý hẳn. Nhận ra chúng sớm chính là khác biệt giữa việc mất ba ngày dữ liệu và việc mất ba tuần dữ liệu, mà dữ liệu không thu được thì không có cách nào truy hồi lại.

Checklist làm được ngay

Mười bốn mục dưới đây là checklist đầy đủ, dùng cho lần phát hành lớn. Với thay đổi nhỏ thì chỉ cần chạy các mục thuộc tầng một và tầng hai theo bảng mức kiểm ở phần trên, và việc đó mất khoảng năm phút chứ không phải mười lăm phút.

• Mở trang chủ, kiểm mã đo có tải trên bản thật, không phải bản xem trước.
• Mở trang dịch vụ chính, kiểm tương tự.
• Điền và gửi biểu mẫu liên hệ trên máy tính, xem sự kiện có bắn.
• Điền và gửi biểu mẫu liên hệ trên điện thoại thật, xem sự kiện có bắn.
• Bấm số điện thoại trên điện thoại, xem sự kiện có bắn.
• Mở kênh chat, xem sự kiện có bắn.
• Kiểm tên sự kiện có đúng quy ước đặt tên đã chốt.
• Kiểm tham số nguồn có được giữ qua các bước chuyển trang.
• Kiểm trang cảm ơn có đúng đường dẫn mà điều kiện bắn đang trỏ tới.
• Kiểm không có mã đo nào bị gắn hai lần.
• Kiểm bộ lọc IP nội bộ vẫn còn hiệu lực.
• Sau 24 giờ, kiểm các sự kiện có xuất hiện trong báo cáo chuẩn.
• So tổng chuyển đổi tuần này với số bản ghi thật, ghi lại tỷ lệ lệch.
• Ghi ngày kiểm và kết quả vào nhật ký, kèm tên bản phát hành.

Câu hỏi thường gặp

Bốn câu dưới đây tập trung vào việc làm sao để checklist này thật sự được chạy, vì viết một checklist ra thì dễ, còn duy trì cho nó được chạy đều mới là phần khó, và đó cũng là phần quyết định toàn bộ giá trị của công cụ này.

Ai nên chạy checklist này?

Người phát hành bản mới, không phải người làm marketing. Lý do là việc kiểm phải gắn liền với hành động phát hành để nó không bị quên; nếu để bên khác kiểm thì luôn có độ trễ và luôn có những lần bị bỏ qua.

Có tự động hoá được không?

Được một phần. Các mục kiểm mã có tải và kiểm gắn trùng có thể tự động bằng công cụ giám sát. Nhưng các mục điền biểu mẫu thật trên điện thoại thì nên giữ thủ công, vì chính khâu đó hay hỏng nhất và cũng khó mô phỏng đúng nhất.

Bao lâu nên đối chiếu với hệ thống bán hàng?

Mỗi tuần một lần là đủ để phát hiện sự cố trong vòng bảy ngày. Ghi lại tỷ lệ lệch qua các tuần thành một chuỗi số: chính sự thay đổi đột ngột của tỷ lệ lệch mới là tín hiệu, chứ không phải giá trị tuyệt đối của nó.

Website nhỏ có cần làm không?

Càng cần, vì website nhỏ có ít dữ liệu nên mất vài tuần là mất một phần đáng kể của cả chuỗi. Với website nhỏ thì rút gọn xuống sáu mục quan trọng nhất, và chỉ chạy khi có thay đổi chạm vào biểu mẫu hoặc bố cục.

Đọc tiếp trên danhnolan

Năm bài dưới đây bổ vào phần thiết lập đo và phần dùng số liệu sau khi đã kiểm xong. Bài thứ nhất là chỗ định nghĩa bộ sự kiện chính mà checklist này đi kiểm, nên đọc nó trước sẽ giúp bạn biết mục nào trong danh sách áp cho sự kiện nào.

• Key events trong GA4: bộ sự kiện chính mà checklist này kiểm sau mỗi lần phát hành
• UTM là gì và cách gắn đúng: phần tham số nguồn hay bị mất khi chuyển trang
• Micro event và macro event trong GA4: quy ước đặt tên sự kiện mà mục thứ bảy đi kiểm
• Checklist khi đổi domain, slug hoặc theme: danh sách rộng hơn cho lần phát hành lớn, gồm cả phần SEO
• Checklist nghiệm thu website WordPress: kiểm trước khi bàn giao, gồm cả phần thiết lập đo