Lời hứa: mỗi sáng lúc 07:00, điện thoại của bạn hiện một bản tường thuật ngắn — doanh số hôm qua so với xu hướng tuần, khoản chi quảng cáo nào thực sự chuyển đổi, ba lô hàng kẹt lâu hơn SLA của hãng vận chuyển, và một điểm bất thường đáng để bạn chú ý. Không dashboard nào phải mở, không bảng tính nào phải refresh. Đây là tầng giám sát của hệ thống trọn gói, và ở quy mô SME nó cần ít hạ tầng hơn nhiều so với hầu hết nhà bán hàng tưởng.
Pipeline: nhàm chán một cách có chủ đích
- Thu nạp. Webhook Shopify truyền đơn hàng, hoàn tiền và sự kiện giao vận gần như thời gian thực; một lượt pull hàng đêm lấy lại vài ngày gần nhất qua API để lấp mọi khoảng trống. Sự kiện tracking của hãng vận chuyển, chi tiêu nền tảng quảng cáo, log chat và các đợt thanh toán đến theo cùng một khuôn mẫu: webhook nơi nào có, pull theo lịch làm lưới an toàn.
- Lưu trữ. Một instance Postgres duy nhất. Ở mức vài chục hay vài trăm đơn mỗi ngày, bạn không cần data lake, nền tảng streaming hay sản phẩm warehouse — Postgres là quá đủ, và sẽ vẫn đủ trong nhiều năm. Sự kiện thô đáp vào các bảng chỉ-ghi-thêm; các fact đã làm sạch, khử trùng lặp sống trong một bộ nhỏ các bảng đã mô hình hóa.
- Tầng metrics. Các SQL view (hoặc một nhúm model dbt) định nghĩa mỗi con số kinh doanh đúng một lần: tỷ lệ chuyển đổi, giá trị đơn trung bình, ROAS theo kênh, số lô hàng kẹt, tỷ lệ chat tự giải quyết.
- Kể chuyện. Một job theo lịch tính các metrics trong ngày, đóng gói thành các fact có cấu trúc, và yêu cầu một LLM viết câu chuyện buổi sáng quanh chúng — gửi qua email hoặc tin nhắn Zalo lúc 07:00.
Quy tắc vàng: AI kể chuyện, SQL tính toán
Trong thực tế: job bản tin render một khối JSON các metrics đã tính sẵn với nhãn, mức chênh lệch và mốc so sánh tường minh, và prompt chỉ thị model chỉ được tham chiếu những giá trị đó. Một bước hậu kiểm quét văn bản đã sinh tìm các con số không có trong đầu vào là khoản bảo hiểm rẻ — từ chối và tạo lại khi sai lệch.
Định nghĩa metrics một lần, ở một nơi
Trôi dạt định nghĩa metric là kẻ giết người thầm lặng của các dự án báo cáo. Dashboard Shopify đếm chuyển đổi một kiểu, nền tảng quảng cáo của bạn kiểu khác, bảng tính của bạn kiểu thứ ba — và cuộc họp thứ Hai tiêu tốn vào việc cãi nhau xem con số của ai đúng. Tầng metrics chấm dứt cuộc tranh cãi bằng cách trở thành định nghĩa duy nhất:
| Metric | Quyết định định nghĩa bạn phải nêu tường minh |
|---|---|
| Tỷ lệ chuyển đổi (CR) | Lấy session hay khách truy cập duy nhất làm mẫu số; đơn hàng tính vào ngày nào |
| Giá trị đơn trung bình (AOV) | Trước hay sau giảm giá; gồm hay không gồm phí vận chuyển |
| ROAS | Cửa sổ attribution; doanh thu do nền tảng báo cáo hay doanh thu mô hình hóa |
| Lô hàng kẹt | Bao nhiêu giờ không đổi trạng thái tracking, theo mức dịch vụ từng hãng vận chuyển |
| Chat tự giải quyết | Hội thoại được giải quyết không cần chuyển cho người thật, trong cửa sổ thời gian nào |
Hãy viết quyết định đó vào SQL và vào một dòng comment bên cạnh. Khi một công cụ khác không khớp với bản tin của bạn, định nghĩa view là trọng tài.
Lỗi múi giờ sống ở ranh giới ngày
Timestamp của Shopify đến theo giờ UTC; ngày kinh doanh của bạn chạy theo Asia/Ho_Chi_Minh (UTC+7). Mọi phép gộp theo ngày phải chuyển đổi múi giờ trước khi cắt về ngày, nếu không các đơn đặt từ nửa đêm đến 07:00 giờ địa phương sẽ âm thầm di cư sang nhầm ngày — và cú "sụt doanh số buổi tối" của hôm qua thực ra là một lỗi gom nhóm. Hãy chuẩn hóa: lưu timestamp bằng UTC, chỉ chuyển sang Asia/Ho_Chi_Minh ở tầng metrics, và kiểm thử ranh giới một cách tường minh với một đơn đặt lúc 23:55 giờ địa phương. Cùng kỷ luật đó áp dụng cho dữ liệu chi tiêu quảng cáo, thứ mà một số nền tảng báo cáo theo múi giờ cấu hình của tài khoản — hãy chuẩn hóa mọi thứ ngay khi thu nạp.
Webhook hỏng trong im lặng — backfill hàng đêm
Giao webhook ở đâu cũng chỉ là best-effort: các lần deploy làm rơi vài cái, sự cố nền tảng làm trễ cả loạt, một secret hết hạn từ chối dữ liệu cả ngày. Lượt pull hàng đêm lấy lại một cửa sổ trượt (ba đến bảy ngày) và upsert, nên khoảng trống tự lành. Upsert bất biến (idempotent) khóa theo ID đối tượng của nền tảng khiến việc phát lại an toàn — cùng nguyên tắc chi phối callback thanh toán trong bài viết về đối soát cổng thanh toán của chúng tôi. Nếu bản tin của bạn có lúc báo một con số 0 đáng ngờ, nghi phạm đầu tiên là một khoảng trống thu nạp, và đó là lý do bản tin cũng nên tự báo cáo độ tươi dữ liệu của mình theo từng nguồn.
Bất thường: cảnh báo thật sự, không cảnh báo liên tục
Một bản tin kêu cứu hão sẽ bị phớt lờ ngay tuần thứ hai. Mệt mỏi cảnh báo là lỗi thiết kế, không phải lỗi người dùng:
- So sánh với mốc chuẩn của cùng thứ trong tuần, không phải với hôm qua — Chủ nhật không phải thứ Hai.
- Dùng ngưỡng tỷ lệ với phương sai: một shop bốn mươi đơn mỗi ngày không nên bị báo động vì dao động ba đơn.
- Ẩn các nguyên nhân đã biết — đợt trầm lắng dịp Tết hay cú tăng vọt của chiến dịch do chính bạn lên lịch là bối cảnh, không phải bất thường.
- Giới hạn bản tin ở một nhúm mục được gắn cờ; mọi thứ khác có sẵn khi được hỏi, không bị đẩy tới.
Kênh gửi: đến gặp chính bạn ở nơi bạn vốn đã nhìn
Email vẫn dùng được, nhưng với đa số founder Việt Nam, bản tin hạ cánh tốt hơn dưới dạng tin nhắn Zalo — chính hạ tầng OA gửi cho khách hàng của bạn thông tin tracking cũng có thể gửi cho bạn những con số của mình (hướng dẫn tự động hóa Zalo). Các mục lô hàng kẹt link thẳng đến trang tracking của hãng vận chuyển; các hóa đơn lỗi link đến hàng đợi xem xét của pipeline hóa đơn điện tử. Bản tin không phải là một báo cáo — nó là cánh cửa trước mỗi ngày dẫn vào mọi hệ thống khác mà bạn đã tự động hóa.