Trong quá trình triển khai hệ thống data cho khách hàng của Elton Data, mình vô tình thấy thêm một điều thú vị đó là nhờ dữ liệu đổ về tự động, không làm tay nữa, nên tình cờ phát hiện ra những vấn đề trong khâu vận hành mà trước đó khi vận hành thủ công không phát hiện ra. Đây là một số bài học mà mình nhận thấy, chia sẻ với các bạn để mọi người thấy là data có sức mạnh không chỉ ở việc cung cấp insights, mà còn có thể cho bạn biết một số vấn đề có thể xảy ra nữa.
Data SKU không thống nhất giữa các bộ phận, các hệ thống
Ví dụ, một sản phẩm Sạc dự phòng có mã SKU là 00043764810. Tuy nhiên, trong hệ thống sales bị lưu SKU thành sac-du-phong, hệ thống kho vận thì lại lưu đúng mã 00043764810, trong khi báo cáo thủ công của nhân sự chịu trách nhiệm về marketing lại dùng tên “Sạc dự phòng”. Khi bắt đầu scale lên, báo cáo muốn chạy tự động, sếp lớn nhất muốn theo dõi doanh thu của từng SKU, chi phí marketing đã chi cho từng SKU (từ ads, chi phí cho influencer, cho đến chi phí quảng cáo offline nhập thủ công) và tính toán hiệu quả của việc chi tiền. Thế là đứt gánh, vì không có một “key” chung giữa các hệ thống (thường chính là mã SKU hoặc barcode sản phẩm) nên việc ráp dữ liệu từ các nguồn khác nhau không thể được thực hiện.
Và chỉ khi bắt tay vào xây dựng hệ thống data thì vấn đề này mới trở thành painpoint cần giải quyết, còn trước đó nhân sự báo cáo thủ công thì hiếm khi cần liên kết nhiều chỉ số với nhau nên doanh nghiệp chưa hành động sớm.
Vấn đề này thực ra có thể giải quyết đơn giản lắm:
- Hệ thống quảng cáo như Facebook Ads, Google Ads, TikTok Ads: đặt tên campaign theo cấu trúc có chứa mã SKU, ví dụ: <BRAND>|tên campaign|<Mã SKU>|các thông tin khác cần track
- Hệ thống bán hàng và vận hành, kho vận: đảm bảo nhập đủ thông tin sản phẩm, trường SKU code phải được nhập đúng, có quy trình duyệt khi lên listing sản phẩm
- Các sàn thương mại điện tử: điền mã SKU vào mục Seller SKU của từng sàn, và cũng phải đảm bảo nhập đúng
- Các file Excel / Google Sheets nhập thủ công: đảm bảo mọi dòng chi phí đều có cột SKU, và điền mã SKU vào
Không nên dùng tên, vì tên sản phẩm có thể thay đổi, chưa kể mỗi nền tảng sẽ có yêu cầu đặc trưng về tên để hiển thị cho người dùng nữa. SKU code mới là cái cố định, bất biến.
Sau đó bạn có thể dùng các công cụ như Elton Data kéo hết về data warehouse, sau đó thoải mái ghép nối các dữ liệu này với nhau để tạo ra bức tranh hoàn chỉnh về doanh thu, chi phí và nhiều mặt nhất có thể về tổ chức của mình. Bên dưới là 1 ví dụ về template mà mình đang cung cấp free cho khách hàng của Elton.
Báo cáo phân bổ sai chi phí cho các page và ads account
Khách X của mình làm trong mảng bán hàng điện tử, họ chạy ads nhiều cho các fanpage của mình. Có một vài nhân sự sẽ chịu trách nhiệm cho từng page, và mỗi page sẽ được phân bổ ngân sách chạy ads trong tháng. Nhân sự sẽ dựa vào ngân sách này mà điều chỉnh kế hoạch và nội dung cho phù hợp. Trước đây việc báo cáo Số tiền đã chi ứng với Fanpage nào chỉ dựa vào tên campaign, và tất nhiên những thứ mà con người làm thủ công thì hoàn toàn có thể bị sai.
Trong quá trình dùng dashboard dựng lên từ data Facebook Ads mà Elton kéo về, nhân sự quản lý phát hiện vấn đề là số phân bố bị lệch so với bình thường, và lệch cũng khá nhiều. Sau đó phát hiện ra rằng khi chạy ads, nhân sự cấp dưới đã chạy cho fanpage A nhưng vẫn đặt tên campaign là dành cho fanpage B do nhầm lẫn, trong khi dashboard tự động thì lấy số từ API trả về để biết creative nào - ad nào ứng với page nào => Nhờ vậy phát hiện ra vấn đề. Việc này ảnh hưởng tới budget của các fanpage cũng như báo cáo hiệu quả khi tính Tỉ lệ Số tiền quảng cáo / Doanh thu của kênh.
Phần này chỉnh lại là lấy số từ dashboard là xong, còn tên thì giờ có thể dùng để đặt cho các mục đích khác, ví dụ như đặt tên mã SKU để phân biệt quảng cáo nào là chạy cho mã hàng nào. Việc xác định số liệu ứng với fanpage thì đã có data tự động lo.
Phát hiện đơn hàng bị xóa trên hệ thống bán hàng
Cũng là khách trên, khi làm dashboard theo dõi doanh thu, mọi thứ đều ok cho tới 1 ngày phát hiện ra doanh thu lệch, số lượng đơn hàng sinh ra trong kỳ cũng lệch. Check kỹ hơn thì phát hiện thấy trong data warehouse đã có data của 7 đơn hàng, nhưng xem lại trên hệ thống bán hàng (Nhanh.vn) thì lại không thấy các đơn này. Do vẫn còn mã đơn hàng, người thực hiện đơn hàng nên dễ dàng truy lại được ai là người xử lý đơn, và phát hiện ra bạn đã thực hiện việc Xóa đơn hàng do sai sót thay vì chuyển trạng thái sang Hủy như quy trình đã định của công ty.
Trường hợp này thì không có vấn đề gì lớn, nhưng trước đây mình đã từng gặp trường hợp nhân viên xóa đơn hàng để giấu sai sót lớn của họ. Lại thêm hệ thống database cũ thiết kế hard delete (huhuhuhuhu) nên data mất đi hẳn. May mà data đã từng sync lên data warehouse theo dạng không-bao-giờ-xóa nên biết được vấn đề. Sau đó tiến hành fix từ cả team dev lẫn từ quy trình luôn.
Phát hiện bất thường trong mã referral
Đây là một bài toán rất điển hình của các đơn vị triển khai chương trình giới thiệu bạn bè. Một khi đã có chương trình referral, mỗi người giới thiệu sẽ có một mã giới thiệu (Referral code) để sử dụng. Và gần như chắc chắn là chương trình khi đã triển khai thì sẽ có tình trạng lạm dụng mã này để trục lợi cho một cá nhân cụ thể, chẳng hạn như để tích điểm nhiều cho 1 account, người sở hữu sẽ tạo nhiều account giả (acc clone) từ 1 mã referral, hoặc tạo theo nhóm. Đây là những tình huống mà các công ty có referral thường phải cân nhắc, từ đó bổ sung điều kiện để được ghi nhận referral thành công cho chặt chẽ và hạn chế tối thiểu thiệt hại do lạm dụng.
Và với kinh nghiệm của mình, chỉ cần một dashboard đơn giản theo dõi tình trạng giới thiệu của các referral là đã có thể phát hiện được một phần các tình trạng lạm dụng và vi phạm chính sách khuyến mãi. Ngoài ra, một số kỹ thuật phát hiện điểm bất thường (anomaly detection) cũng có thể được đưa vào để phát hiện tự động. Và muốn có dashboard hay có anomaly detection, chắc chắn phải có một nền tảng data vững chắc.
Dựa trên các trải nghiệm thú vị này, mình tin rằng data có thể giúp được cho các doanh nghiệp rất nhiều không chỉ trong việc rút ngắn thời gian theo dõi số, chuẩn bị báo cáo, dashboard, mà còn có thể giúp phát hiện thấy các điểm bất thường trong quy trình làm việc, từ đó điều chỉnh, tối ưu thêm. Data đẹp là thế đó.