Bài 3 — Thiết kế sự kiện để dùng được nhiều năm

Lược đồ sự kiện là thứ khó sửa nhất

Đổi một dashboard mất một giờ. Đổi lược đồ sự kiện nghĩa là dữ liệu cũ không so được với dữ liệu mới, và bạn mất chuỗi lịch sử. Vì vậy đây là chỗ đáng bỏ công thiết kế trước.

Quy ước đặt tên: chọn một và giữ

Mẫu đơn giản và bền: đối tượng + hành động, ở thì quá khứ, chữ thường, nối bằng gạch dưới.

> order_placed, subscription_cancelled, report_exported

Ba quy tắc đi kèm:

• Không nhét ngữ cảnh vào tên. Không phải order_placed_mobile_vn mà order_placed với thuộc tính platform và country. Tên gộp ngữ cảnh sẽ bùng nổ thành hàng trăm sự kiện không phân tích được.
• Không đặt tên theo màn hình. Màn hình đổi, ý nghĩa nghiệp vụ thì không. checkout_button_clicked sẽ vô nghĩa sau lần thiết kế lại.
• Ghi lại quy ước ở một nơi ai cũng thấy, kèm ví dụ đúng và sai.

Thuộc tính: chỗ chứa mọi thứ có thể cần sau này

Mỗi sự kiện nên mang: ai (định danh người dùng), khi nào (mốc thời gian có múi giờ), ở đâu (nền tảng, phiên bản), và các thuộc tính nghiệp vụ mô tả sự kiện đó.

Nguyên tắc: ghi thuộc tính thô, không ghi thứ đã tính sẵn. Ghi amount và currency, đừng ghi amount_usd_converted — tỷ giá đổi, và bạn sẽ muốn tính lại.

Định danh người dùng: quyết định sớm hoặc trả giá lâu

Một người có thể xuất hiện trước khi đăng nhập (định danh ẩn danh) và sau khi đăng nhập (định danh thật). Nếu không nối hai định danh này ngay từ đầu, bạn sẽ không bao giờ đo được hành trình từ lần chạm đầu tiên tới lúc mua.

Đây là một trong số ít quyết định hạ tầng dữ liệu gần như không sửa được sau này với dữ liệu cũ.

Tránh bùng nổ sự kiện

Nhiều đội kết thúc với 400 loại sự kiện mà không ai hiểu hết. Ba cách kiểm soát:

• Một người duyệt trước khi thêm sự kiện mới.
• Mỗi sự kiện phải kèm câu hỏi nó trả lời. Không trả lời được thì không thêm.
• Rà soát hằng quý, gỡ sự kiện không ai truy vấn trong sáu tháng.

Sai lầm thường gặp

• Đặt tên theo màn hình thay vì theo nghiệp vụ.
• Nhét ngữ cảnh vào tên sự kiện.
• Ghi giá trị đã tính sẵn thay vì thuộc tính thô.
• Không nối định danh ẩn danh với định danh thật.

Checklist kết bài

• [ ] Tôi có quy ước đặt tên được ghi lại và áp dụng nhất quán.
• [ ] Sự kiện của tôi mang thuộc tính thô, không mang giá trị đã tính.
• [ ] Định danh ẩn danh và định danh thật đã được nối.
• [ ] Có cơ chế duyệt trước khi thêm sự kiện mới.

<!--les-append-->

Thuộc tính: thiếu một thuộc tính cũng tệ như thiếu cả sự kiện

Có order_placed nhưng không có thuộc tính payment_method nghĩa là bạn biết tổng số đơn và không bao giờ cắt được theo phương thức thanh toán — kể cả về sau, vì dữ liệu quá khứ không có.

Bộ thuộc tính tối thiểu cho mọi sự kiện:

Và với mỗi sự kiện, hỏi: ba tháng nữa tôi sẽ muốn cắt dữ liệu này theo chiều nào? Thêm thuộc tính đó ngay, vì thêm sau chỉ áp dụng cho dữ liệu tương lai.

Quy trình thêm sự kiện mới

Không có quy trình thì sau một năm bạn có 400 sự kiện, một nửa không ai nhớ nghĩa.

• Đăng ký trước khi cài — tên, mô tả một câu, thuộc tính, ai sở hữu, câu hỏi nào nó trả lời
• Có người duyệt — thường là một người trong đội dữ liệu
• Kiểm sau khi phát hành — sự kiện có thật sự bắn không, thuộc tính có đầy đủ không
• Rà hằng quý — sự kiện nào không được truy vấn lần nào trong 6 tháng thì cân nhắc bỏ

Bước 3 hay bị bỏ. Một sự kiện được cài nhưng bắn sai hoặc không bắn là loại lỗi im lặng nhất — không có cảnh báo, chỉ có dữ liệu trống ba tháng sau.

Sai lầm khó sửa nhất

Dòng cuối là tệ nhất: nó tạo ra một chuỗi số liệu trông liền mạch nhưng thực ra đo hai thứ khác nhau.

Làm ngay

Chọn ba sự kiện quan trọng nhất của bạn. Kiểm: chúng có đủ bộ thuộc tính tối thiểu không? Nếu thiếu, thêm ngay — mỗi ngày chậm là một ngày dữ liệu không cắt được. <!--/les-append-->

<!--case-append-->

Áp dụng vào Căng tin số

App chạy thử chỉ có một quầy, bốn tuần và chỉ sinh viên đăng nhập. Nhưng lược đồ sự kiện sẽ sống lâu hơn cái pilot đó rất nhiều. Nếu Chị Lan quyết mở thêm quầy phở/bún vào học kỳ sau, và cho giảng viên, nhân viên trường dùng app, thì dữ liệu học kỳ 2 phải còn so được với dữ liệu học kỳ sau. Đây là lúc rẻ nhất để làm đúng.

Bắt đầu từ tên. Nút lớn mà nhân viên quầy bấm khi một món hết rất dễ được ghi thành nut_het_mon_clicked, tức đặt tên theo màn hình. Lần thiết kế lại đầu tiên sẽ làm tên đó vô nghĩa. Tên theo nghiệp vụ thì bền: dish_sold_out. Tương tự cho cả vòng đời một đơn:

Thuộc tính counter trông thừa khi chỉ có quầy cơm. Thêm nó sau thì toàn bộ dữ liệu học kỳ 2 không có giá trị đó, và mọi so sánh giữa hai quầy phải dựa trên giả định "trước đây chỉ có quầy cơm". Một thuộc tính khác nên có ngay: user_type. Hôm nay nó luôn là sinh viên; khi giảng viên và nhân viên trường vào, bạn sẽ muốn tách 15% doanh thu đó ra mà không phải đoán.

Ghi thô, không ghi đã tính. Phân khúc "người tới muộn" tuần 4 được định nghĩa là người chọn khung nhận sau 12:15, chiếm 18% trong 205 đơn mỗi ngày. Nếu sự kiện ghi sẵn is_late = true, thì khi ai đó đề xuất đổi mốc thành 12:30, bạn không tính lại được quá khứ. Ghi pickup_slot_start, rồi định nghĩa "muộn" ở lớp chỉ số.

Định danh là chỗ không sửa được về sau. Trong 40 người bỏ ngang được hỏi, 11 người "chỉ xem còn món gì"; bảng "còn món" có khoảng 420 lượt xem mỗi ngày từ 11:45 đến 12:45. Nhiều người xem mà không đăng nhập. Nếu lượt xem ẩn danh không được nối với mã số sinh viên khi người đó đăng nhập, phễu 1.050 → 900 → 310 → 205 → 190 chỉ là năm con số rời, không phải một hành trình. Và khi giảng viên vào app mà không có mã số sinh viên, định danh phải là một mã nội bộ của app, còn mã số sinh viên chỉ là một thuộc tính gắn vào nó.

Kiểm sau khi phát hành. Tuần 1 có 3 lỗi in phiếu cho bếp và 5 lần nhân viên quên bấm "hết". Lần quên bấm là lỗi im lặng: không có sự kiện nào bắn, và dữ liệu nói rằng món chưa hết. Nhóm chỉ biết vì có người đứng ở quầy đối chiếu.

Thử ngay: viết phiếu đăng ký cho sự kiện dish_sold_out gồm tên, mô tả một câu, thuộc tính, người sở hữu và câu hỏi nó trả lời. Người sở hữu nên là ai: nhóm làm app hay Anh Tuấn, người quản lý nhân viên quầy? <!--/case-append-->