Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn là PM của một ứng dụng giao đồ ăn. Sếp hỏi: "Tuần trước có bao nhiêu người bỏ giỏ hàng ở bước thanh toán?" Bạn quay sang team data, và họ trả lời: "Không track được anh ơi, sự kiện đó hồi xưa không ai định nghĩa, dữ liệu lúc có lúc không, tên field thì mỗi người đặt một kiểu." Vậy là một câu hỏi tưởng đơn giản trở thành dự án hai tuần đào lại log.
Đây là cảnh tượng diễn ra hàng ngày ở rất nhiều công ty Việt Nam. Sản phẩm chạy ngon, code đẹp, nhưng dữ liệu hành vi người dùng thì hỗn loạn. Lý do gần như luôn giống nhau: không ai sở hữu việc thiết kế event tracking một cách có kỷ luật. Và đáng buồn là người duy nhất có đủ bối cảnh để làm việc này — vừa hiểu nghiệp vụ, vừa hiểu kỹ thuật, vừa biết câu hỏi kinh doanh nào quan trọng — chính là Technical PM.
Event tracking không phải việc "để team analytics lo". Nếu schema event được thiết kế cẩu thả, mọi phân tích phía sau đều sai: funnel sai, A/B test đọc nhầm, dashboard cho lãnh đạo lệch. Dữ liệu kém không chỉ vô dụng — nó nguy hiểm, vì nó khiến bạn tự tin ra quyết định dựa trên số liệu giả. Bài này dạy bạn cách thiết kế một hệ thống event tracking sạch, bền, có thể tin được — kỹ năng nền tảng cho mọi quyết định data-driven phía sau.
Khái niệm cốt lõi
Event là gì và cấu trúc của một event
Trong analytics, một event (sự kiện) là một hành động có ý nghĩa mà người dùng hoặc hệ thống thực hiện tại một thời điểm cụ thể. Ví dụ: "User Signed Up", "Product Added to Cart", "Order Placed", "Video Played". Mỗi event là một dòng dữ liệu mô tả: ai đã làm gì, khi nào, trong bối cảnh nào.
Một event chuẩn gồm bốn thành phần:
- Event name (tên sự kiện): mô tả hành động, ví dụ
Order Placed. - Properties (thuộc tính): các trường mô tả chi tiết event đó, ví dụ
total_amount,payment_method,item_count. - User identity (định danh người dùng): ai thực hiện —
user_id, hoặcanonymous_idnếu chưa đăng nhập. - Timestamp & context (thời gian và ngữ cảnh): thời điểm xảy ra, kèm thông tin môi trường như
platform,app_version,device.
Order Placed iOS và Order Placed Android thay vì một event Order Placed với property platform. Cách làm sai khiến bạn không bao giờ gộp số liệu lại được.Naming convention — quy ước đặt tên
Tên event và property phải nhất quán tuyệt đối trên toàn hệ thống. Nếu chỗ này gọi signup, chỗ kia Sign Up, chỗ khác user_registered, thì khi phân tích bạn phải gộp ba thứ tưởng khác nhau lại bằng tay. Hãy chọn một quy ước và ép cả công ty tuân theo:
- Event name: dùng định dạng Object + Action ở thì quá khứ, viết hoa đầu chữ —
Product Viewed,Order Placed,Coupon Applied. Cách này khiến danh sách event đọc lên như một cuốn nhật ký rõ ràng. - Property name: dùng
snake_casethống nhất —total_amount,payment_method,is_first_order. - Tránh viết tắt khó hiểu, tránh tên động (
button_3_clicked), tránh nhồi giá trị vào tên (order_placed_grab_pay).
Tracking plan — trái tim của event tracking
Tracking plan là tài liệu duy nhất, có thẩm quyền (single source of truth), định nghĩa mọi event mà sản phẩm được phép gửi đi. Nó giống như một hợp đồng giữa PM, engineer và data analyst. Mỗi dòng trong tracking plan mô tả đầy đủ một event:
Event: "Order Placed"
Trigger: User bấm nút "Xác nhận" trên màn hình checkout, sau khi
payment gateway trả về thành công
Properties:
- order_id (string, required) -- mã đơn duy nhất
- total_amount (number, required) -- tổng tiền, đơn vị VND
- currency (string, required) -- luôn là "VND"
- item_count (integer, required) -- số sản phẩm trong đơn
- payment_method (enum, required) -- momo | zalopay | cod | card
- is_first_order (boolean, required) -- đơn đầu tiên của user?
- coupon_code (string, optional) -- mã giảm giá nếu có
Owner: PM Growth
Tracking plan tốt phải chỉ rõ với mỗi event: tên, thời điểm trigger chính xác, danh sách property kèm kiểu dữ liệu (data type), required hay optional, giá trị hợp lệ với enum, và ai sở hữu. Đây chính là phần việc cốt lõi của Technical PM — không ai khác làm thay được, vì nó đòi hỏi hiểu cả nghiệp vụ lẫn cách hệ thống vận hành.
Identity — định danh người dùng xuyên suốt
Một thách thức lớn là nối hành vi của một người trước và sau khi họ đăng nhập. Trước đăng nhập, hệ thống chỉ biết họ qua anonymous_id (thường lưu trong cookie/device). Khi họ đăng nhập, ta cần một thao tác identify/alias để gắn anonymous_id đó với user_id thật. Nếu bỏ qua bước này, bạn sẽ thấy "hai người khác nhau" trong khi thực ra là một — funnel từ khách vãng lai đến khách mua hàng đứt gãy hoàn toàn.
Semantic versioning cho schema
Schema event không bất biến — nó sẽ thay đổi khi sản phẩm tiến hóa. Cần quy ước rõ đâu là thay đổi tương thích (thêm property optional mới — an toàn) và đâu là breaking change (đổi tên property, đổi kiểu dữ liệu, biến optional thành required — phá vỡ phân tích cũ). Với breaking change, không bao giờ sửa tại chỗ; hãy tạo event/property mới và cho cái cũ "nghỉ hưu" có kế hoạch.
Tình huống thực tế
Tình huống 1: ShopFast và thảm họa "checkout" ba phiên bản
ShopFast (sàn TMĐT giả định tại TP.HCM, khoảng 200.000 đơn/tháng) tăng trưởng nhanh và không có tracking plan. Trong vòng một năm, ba squad khác nhau triển khai tracking cho luồng thanh toán độc lập: team web gửi event checkout, team app iOS gửi Checkout Completed, team app Android gửi purchase_done. Tệ hơn, field tổng tiền lúc là amount (đơn vị VND), lúc là total (đơn vị nghìn đồng), lúc là value (có cả VAT, có cả không).
Khi CEO yêu cầu báo cáo tỷ lệ chuyển đổi checkout toàn nền tảng, team data mất ba tuần chỉ để "hòa giải" dữ liệu, và con số cuối cùng vẫn có sai số ước tính 15%. Quyết định tăng ngân sách marketing dựa trên con số đó suýt khiến công ty đốt nhầm tiền vào kênh không hiệu quả.
Bài học: Sự hỗn loạn không đến từ thiếu công cụ — ShopFast dùng đầy đủ Amplitude. Nó đến từ thiếu một tracking plan chung và thiếu người sở hữu. Sau sự cố, họ lập tracking plan tập trung do Technical PM duyệt, chuẩn hóa thành một event Order Placed duy nhất với property platform, và quy định mọi đơn vị tiền là VND nguyên. Báo cáo sau đó chạy trong vài phút.
Tình huống 2: GrabFood-style và sức mạnh của property thiết kế đúng
Một ứng dụng giao đồ ăn (kiểu GrabFood, bối cảnh Đông Nam Á) muốn hiểu tại sao tỷ lệ hủy đơn cao vào giờ cao điểm. Ban đầu họ chỉ track event Order Cancelled trơn, không property. Kết quả: biết được "có hủy", nhưng không biết vì sao.
Technical PM ngồi lại với team vận hành và thiết kế lại event với các property giàu ngữ cảnh: cancelled_by (user/driver/system), cancel_reason (enum: no_driver, long_wait, price_change...), wait_time_seconds, time_to_cancel_seconds, peak_hour (boolean). Chỉ sau hai tuần thu dữ liệu, họ phát hiện 60% lượt hủy giờ cao điểm có cancel_reason = no_driver và wait_time_seconds > 600. Insight này dẫn thẳng tới việc điều chỉnh thuật toán phân bổ tài xế giờ cao điểm.
Bài học: Một event nghèo property gần như vô dụng cho phân tích sâu. Giá trị thật nằm ở việc PM dự đoán trước những câu hỏi "vì sao" và nhúng sẵn ngữ cảnh vào property. Nhưng cũng phải cân bằng — đừng nhồi 50 property "phòng khi cần", vì mỗi property đều tốn chi phí triển khai, kiểm thử và bảo trì.
Tình huống 3: Fintech và bài học về dữ liệu nhạy cảm
Một startup fintech ở Hà Nội track event Loan Application Submitted và vô tư nhét cả số CMND/CCCD, số điện thoại đầy đủ, và số dư tài khoản vào property — gửi thẳng lên công cụ analytics bên thứ ba của nước ngoài. Khi rà soát tuân thủ theo Nghị định 13/2023 về bảo vệ dữ liệu cá nhân, đây trở thành rủi ro pháp lý nghiêm trọng: dữ liệu cá nhân nhạy cảm bị chuyển ra ngoài mà không có cơ sở hợp lệ.
Họ phải khẩn cấp gỡ các property này, hash định danh, và thiết lập quy tắc: tracking plan phải đánh dấu rõ property nào chứa PII (thông tin định danh cá nhân) và property đó có được phép rời hệ thống nội bộ hay không.
Bài học: Thiết kế schema không chỉ là chuyện phân tích, mà còn là chuyện tuân thủ và an toàn. Mỗi property thêm vào tracking plan, PM phải tự hỏi: "Trường này có phải PII không? Có thực sự cần cho phân tích không?" (Chủ đề privacy được đào sâu ở Bài 32 — ở đây bạn chỉ cần ghi nhớ rằng schema design và privacy luôn đi đôi.)
Hướng dẫn từng bước
Đây là quy trình thực tế để Technical PM xây dựng event tracking cho một tính năng mới:
- Bắt đầu từ câu hỏi kinh doanh, không phải từ event. Liệt kê những câu hỏi bạn muốn trả lời: "Tỷ lệ hoàn tất đăng ký là bao nhiêu?", "Người dùng rớt ở bước nào?", "Mã giảm giá nào hiệu quả nhất?". Mỗi câu hỏi sẽ chỉ ra event và property cần thiết. Đây là nguyên tắc vàng — đừng track mọi thứ chỉ vì có thể.
- Vẽ luồng người dùng và đánh dấu các điểm cần đo. Với luồng đăng ký chẳng hạn, các điểm đo là:
Signup Started,Email Entered,OTP Verified,Signup Completed. Đây chính là khung funnel của bạn.
- Định nghĩa từng event trong tracking plan. Với mỗi event, viết rõ trigger chính xác, danh sách property, kiểu dữ liệu, required/optional, giá trị enum hợp lệ, và đánh dấu PII. Dùng một spreadsheet hoặc công cụ chuyên dụng (Avo, Segment Protocols) làm nơi lưu trữ.
- Review chéo với engineer và data analyst. Engineer xác nhận tính khả thi kỹ thuật (property này lấy ở đâu trong code?). Analyst xác nhận đủ để trả lời câu hỏi kinh doanh. Vòng review này ngăn 80% lỗi trước khi viết một dòng code.
- Triển khai và xác thực (QA tracking). Sau khi engineer code xong, đừng tin ngay. Dùng debugger của công cụ analytics để bắn thử event và kiểm tra: tên đúng chưa, property đủ chưa, kiểu dữ liệu đúng chưa, có gửi nhầm hai lần không.
- Giám sát và lặp lại. Đặt cảnh báo cho "volume bất thường" (event đột nhiên giảm về 0 thường nghĩa là tracking bị hỏng sau một lần deploy). Định kỳ rà soát tracking plan, loại bỏ event không ai dùng.
Lỗi thường gặp & mẹo
Lỗi 1 — Track mọi click có thể. Nhiều team bật autocapture rồi gửi hàng nghìn loại event vô nghĩa. Kết quả là "data swamp": dữ liệu nhiều nhưng không tìm được gì. Mẹo: tracking plan nên tinh gọn, mỗi event phải gắn với ít nhất một câu hỏi kinh doanh thật.
Lỗi 2 — Đặt giá trị vào tên event. Order Placed Momo, Order Placed COD... khiến bạn không bao giờ tính được tổng đơn. Mẹo: giá trị luôn nằm trong property (payment_method), không nằm trong tên.
Lỗi 3 — Kiểu dữ liệu không nhất quán. total_amount lúc là số 150000, lúc là chuỗi "150,000đ". Phân tích number sẽ vỡ. Mẹo: khóa cứng kiểu dữ liệu trong tracking plan và validate ở tầng thu thập.
Lỗi 4 — Quên trạng thái khởi đầu của funnel. Chỉ track Signup Completed mà quên Signup Started thì không tính được tỷ lệ rớt. Mẹo: luôn track cả điểm bắt đầu và điểm kết thúc của mỗi luồng quan trọng.
Lỗi 5 — Sửa schema không kiểm soát. Một engineer đổi tên property cho "gọn" làm hỏng toàn bộ dashboard lịch sử. Mẹo: coi schema như API có hợp đồng — breaking change phải qua quy trình, tạo mới thay vì sửa tại chỗ.
Mẹo vàng: Đặt một property "kỹ thuật" chung cho mọi event ngay từ đầu — app_version, platform, tracking_version. Khi tracking lỗi, bạn sẽ biết ngay lỗi đến từ phiên bản app nào.
Bài tập thực hành
Bài tập 1 — Viết tracking plan cho luồng thật. Chọn một sản phẩm bạn đang dùng (ví dụ Shopee, Tiki). Lấy luồng "thêm vào giỏ và mua hàng", viết tracking plan đầy đủ cho tối thiểu 4 event: tên event (Object + Action), trigger chính xác, ít nhất 4 property mỗi event kèm kiểu dữ liệu, required/optional, và đánh dấu property nào là PII.
Bài tập 2 — Sửa lỗi schema xấu. Cho danh sách event sau: clicked_buy, BuyNow_iOS, purchase, order amount = "200.000 VND". Hãy chỉ ra mọi vấn đề về naming, cấu trúc và kiểu dữ liệu, rồi viết lại thành một schema sạch, nhất quán.
Bài tập 3 — Từ câu hỏi đến event. Sếp hỏi: "Tính năng tìm kiếm có hiệu quả không? Người dùng tìm xong có mua không?". Hãy liệt kê các câu hỏi con, rồi thiết kế những event và property tối thiểu đủ để trả lời, không thừa.
Tóm tắt
- Event tracking là nền móng của mọi quyết định data-driven. Schema xấu khiến mọi phân tích phía sau đều sai, và sai số liệu còn nguy hiểm hơn không có số liệu.
- Một event chuẩn gồm: tên, properties, identity, timestamp/context. Hành động là event, chi tiết là property — đừng nhầm lẫn hai thứ này.
- Naming convention nhất quán là bắt buộc: event theo Object + Action thì quá khứ, property theo snake_case, giá trị luôn nằm trong property chứ không trong tên.
- Tracking plan là single source of truth — hợp đồng giữa PM, engineer, analyst. Đây là phần việc cốt lõi mà Technical PM phải sở hữu.
- Luôn bắt đầu từ câu hỏi kinh doanh, không phải từ "track cho nhiều". Tinh gọn nhưng giàu ngữ cảnh.
- Coi schema như API có hợp đồng: quản lý phiên bản, tránh breaking change tùy tiện, và luôn đánh dấu PII để tuân thủ quy định bảo vệ dữ liệu.