Bài 6, Giữ dữ liệu sạch theo thời gian: taxonomy nâng cao và data quality

Ở bài 5, Nhà Gọn đã có taxonomy sạch: một tên order_completed gọn gàng với các parameter đúng. Nhưng đây là sự thật ít ai nói: taxonomy sạch lúc mới dựng không khó. Giữ nó sạch sau một năm, khi đội đông lên, người mới thêm sự kiện không theo quy ước, giá trị thuộc tính viết mỗi lúc một kiểu, đó mới là phần khó. Bài này về cách chống cho hệ thống khỏi rữa dần.

Nó thuộc Tầng B của lộ trình, tức là phần "đo sâu". Nếu doanh nghiệp bạn còn nhỏ và tracking mới chạy, có thể lướt nhanh bài này rồi quay lại khi số sự kiện vượt quá vài chục. Nhưng đọc trước một lần để biết cái gì sẽ hỏng thì luôn có lợi.

---

#Vì sao taxonomy sụp khi lớn lên

Khi bạn có 15 sự kiện và một người quản, mọi thứ trong đầu bạn. Khi có 80 sự kiện và bốn người thêm bớt, trí nhớ không đủ nữa. Ba triệu chứng sụp phổ biến, và Nhà Gọn gặp cả ba sau khi thuê thêm một bạn marketing và một đơn vị chạy ads:

• Thuộc tính trùng lặp. Bạn marketing tạo channel, đơn vị ads tạo kenh, một bạn khác viết sales_channel. Ba tên cho một khái niệm, và giờ không báo cáo nào gộp được số theo kênh.
• Giá trị viết tự do. Cùng kênh Shopee, chỗ ghi shopee, chỗ ghi Shopee, chỗ ghi shopee_mall. Cắt theo kênh ra ba dòng thay vì một.
• Đổi nghĩa âm thầm. Ai đó đổi định nghĩa order_completed từ "máy chủ xác nhận" sang "khách bấm nút" mà không ghi lại, thế là số đơn tháng đó phình lên vì tính cả đơn thanh toán lỗi, và biểu đồ so với tháng trước sai mà không ai biết.

---

#Sáu chiều của chất lượng dữ liệu

Để biết dữ liệu có sạch không, cần một khung thay vì cảm giác. Sáu chiều cần theo dõi:

Chiều	Câu hỏi	Ví dụ lỗi ở Nhà Gọn
Đầy đủ	Có thiếu sự kiện hay thuộc tính không	30% đơn thiếu value do webhook Shopee không gửi tiền
Chính xác	Số có khớp nguồn thật không	Doanh thu GA4 lệch sổ kế toán 12%
Nhất quán	Tên và giá trị có đồng nhất không	shopee và Shopee lẫn lộn
Kịp thời	Dữ liệu về đúng lúc không	Đơn từ TikTok Shop về trễ một ngày
Hợp lệ	Đúng kiểu và khoảng không	value âm do đơn hoàn tiền
Duy nhất	Có bị đếm trùng không	Một đơn đếm hai lần khi khách tải lại trang xác nhận

Ba chiều đầu (đầy đủ, chính xác, nhất quán) là nơi phần lớn lỗi thực tế nằm. Chiều chính xác đặc biệt quan trọng với doanh nghiệp Việt: nếu doanh thu trong công cụ đo lệch với sổ kế toán như trường hợp Nhà Gọn lệch 12%, mọi quyết định ngân sách dựa trên nó đều đáng ngờ.

---

#Coi mỗi sự kiện quan trọng như code cần kiểm tra

Cách thực tế nhất để giữ chất lượng là tự động hóa việc phát hiện lỗi, thay vì đợi tới lúc nhìn báo cáo thấy số kỳ lạ. Với mỗi sự kiện quan trọng, đặt vài luật kiểm tra. Đây là bảng luật của Nhà Gọn, bạn chép cấu trúc này:

Kiểm tra	Ngưỡng bình thường	Cảnh báo khi	Đối chiếu với
Số đơn mỗi ngày	60 tới 200	ra ngoài khoảng	nội bộ
Tỷ lệ đơn thiếu value	dưới 1%	từ 1% trở lên	không
Độ tươi order_completed	có trong 24 giờ	vắng quá 24 giờ	không
Số đơn GA4 so với sổ bán hàng	lệch dưới 3%	lệch quá 3%	sổ bán hàng

GA4 có tính năng cảnh báo tự động cho các luật đơn giản như "số đơn giảm quá nửa so với hôm qua". Với kiểm tra phức tạp hơn thì cần tới kho dữ liệu, phần đó thuộc Tầng C và series sau. Điểm cốt lõi ở đây là tư duy: tracking hỏng âm thầm còn nguy hiểm hơn tracking không có, vì bạn vẫn ra quyết định, chỉ là dựa trên số sai. Một dashboard theo dõi sức khỏe tracking, tách riêng khỏi dashboard kinh doanh, đáng để dựng.

---

#Đừng gắn UTM cho link nội bộ

Đây là một lỗi cụ thể nhưng phá hoại âm thầm, nên tách ra nói riêng. UTM là các nhãn bạn gắn vào link để đánh dấu nguồn traffic, và bài 7 sẽ nói kỹ. Nhưng có một quy tắc thuộc về chất lượng dữ liệu: chỉ gắn UTM cho link từ ngoài dẫn vào site, không bao giờ gắn cho link nội bộ trong chính site.

Lý do: khi khách bấm một link nội bộ có gắn UTM, công cụ đo tưởng đây là một phiên mới đến từ nguồn mới, và ghi đè nguồn thật ban đầu. Khách của Nhà Gọn vốn đến từ quảng cáo Facebook, bấm một banner nội bộ "ưu đãi khách cũ" có gắn UTM, thế là bị tính thành đến từ "banner", và công lao của Facebook biến mất. Việc quy nguồn hỏng từ gốc.

Muốn đo click banner hay CTA quảng bá nội bộ, dùng một sự kiện riêng, ví dụ promotion_click kèm thuộc tính vị trí và mã chương trình. Đo được click nội bộ mà không đụng tới nguồn traffic.

---

#Vòng đời một event và dọn rác định kỳ

Taxonomy sạch không phải trạng thái, nó là một quá trình. Mỗi event nên đi qua một vòng đời có kiểm soát, thay vì được thêm vào rồi bỏ mặc:

Đề xuất (có câu hỏi kinh doanh không?) → duyệt vào tracking plan
→ gán người sở hữu + đăng ký parameter → gắn → kiểm tra → chạy
→ GIÁM SÁT → rà soát định kỳ (còn dùng? còn đúng?) → gỡ nếu chết

Hai mắt xích hay bị bỏ là giám sát và rà soát định kỳ. Nhà Gọn đặt lịch rà soát taxonomy mỗi quý: mở báo cáo, liệt kê event nào có 0 lượt dùng trong bất kỳ báo cáo nào ai thật sự đọc, và cân nhắc gỡ. Sau hai quý họ gỡ được 11 event thừa tích lại từ thời thử nghiệm, và báo cáo nhẹ hẳn.

Khi phát hiện nhiều lỗi cùng lúc, đừng sửa dàn trải. Xếp ưu tiên theo mức ảnh hưởng: lỗi chạm vào sự kiện quan trọng hoặc doanh thu, tần suất cao, thì sửa ngay; lỗi ở event phụ, hiếm gặp, đưa vào danh sách chờ. Với Nhà Gọn, purchase thiếu value được sửa trong ngày vì nó làm sai mọi báo cáo doanh thu, còn một event search thỉnh thoảng thiếu search_term thì để lại xử lý sau.

#Trước khi sang bài 7

1. Lập sổ đăng ký parameter từ tracking plan hiện có, gộp các thuộc tính trùng, khóa danh sách giá trị cho các thuộc tính phân loại.
2. Thêm cột người sở hữu và ngày rà soát vào tracking plan.
3. Đặt bảng luật chất lượng cho các sự kiện quan trọng nhất, và tạo ít nhất một cảnh báo tự động trong GA4.
4. Rà lại xem còn UTM nào đang gắn nhầm trên link nội bộ không.

Nhắc tới UTM, đó chính là chủ đề bài 7. Chúng ta vừa nói không được gắn UTM ở đâu, bài sau nói cách gắn đúng ở nơi cần: làm sao để báo cáo nguồn traffic của Nhà Gọn không biến facebook, Facebook, và FB thành ba kênh khác nhau, và làm sao biết chính xác kênh nào mang về khách thật.