ETL là gì? Quy trình đưa dữ liệu marketing về một hệ thống chung

ETL là gì? ETL là viết tắt của Extract – Transform – Load: trích xuất dữ liệu từ các hệ thống nguồn, biến đổi (chuẩn hoá, làm sạch, gộp) cho thống nhất, rồi nạp vào một nơi lưu trữ chung — thường là data warehouse hoặc, ở quy mô nhỏ, một bảng tính tổng hợp. Chuỗi các bước này chạy tự động theo lịch thường được gọi là data pipeline (đường ống dữ liệu).

Trong marketing, ETL giải quyết một vấn đề rất đời thường: mỗi nền tảng quảng cáo, mỗi công cụ bán hàng ghi dữ liệu theo cách riêng — tên cột khác, định dạng ngày khác, múi giờ khác, cách đặt tên chiến dịch khác. Không có bước biến đổi ở giữa, mọi phép cộng trừ giữa các nguồn đều đáng ngờ. Điều nên biết ngay: nếu mỗi tuần bạn xuất tệp từ ba nền tảng, sửa tên cột rồi dán vào một bảng chung, thì bạn đang làm ETL bằng tay. Bài này giúp bạn làm việc đó có hệ thống, dù là tay hay tự động.

ETL, ELT và reverse ETL: ba chiều của dòng dữ liệu

Nhiều kho dữ liệu hiện đại đủ mạnh để nạp dữ liệu thô vào trước rồi biến đổi sau (ELT) — lợi thế là giữ được bản gốc, khi đổi quy tắc chỉ cần chạy lại phép biến đổi. Với người làm marketing, khác biệt này ít quan trọng hơn nguyên tắc chung: dữ liệu phải được chuẩn hoá trước khi đem đi phân tích, và phải giữ được bản gốc để đối chiếu. Chiều ngược lại — lấy kết quả từ kho đẩy ra CRM hay nền tảng quảng cáo — là reverse ETL, một bài toán riêng với rủi ro riêng.

Cần chuẩn bị gì

• Đích đến đã xác định: một kho dữ liệu hay một bảng tính tổng hợp, kèm cấu trúc cột đích mong muốn.
• Quy ước đặt tên chiến dịch dùng chung — phần lớn công sức biến đổi là để sửa những gì quy ước tốt đã có thể ngăn từ đầu. Xem UTM tracking.
• Quyền truy cập vào từng nguồn: quyền xuất báo cáo, hoặc quyền API nếu tự động hoá.
• Từ điển dữ liệu tối thiểu: mỗi cột đích nghĩa là gì, đơn vị gì, lấy từ cột nào ở nguồn.
• Quy định về dữ liệu cá nhân: cột nào được phép chuyển, cột nào phải loại bỏ hoặc che trước khi nạp, cân nhắc theo Nghị định 13/2023/NĐ-CP về bảo vệ dữ liệu cá nhân.

Quy trình ETL cho dữ liệu marketing 6 bước

Bước 1. Xác định hệ thống nguồn

Lập danh sách nguồn cần kéo và với mỗi nguồn ghi rõ: dữ liệu gì (chi phí, lượt nhấp, lead, đơn hàng), mức chi tiết (theo ngày, theo chiến dịch, theo mẫu quảng cáo), cách lấy (xuất tệp, API, kết nối dựng sẵn), và nguồn đó giữ lịch sử bao lâu. Chỉ kéo những gì phục vụ câu hỏi đã chốt. Kéo “mọi thứ cho chắc” làm đường ống nặng, dễ vỡ và kéo theo dữ liệu cá nhân không cần thiết.

Bước 2. Trích xuất theo lịch phù hợp

Báo cáo marketing hằng tuần thì trích xuất hằng ngày là đủ; không cần thời gian thực. Có hai cách lấy: toàn bộ (kéo lại cả khoảng thời gian mỗi lần) và tăng dần (chỉ kéo phần mới). Một lưu ý riêng của dữ liệu quảng cáo: số liệu những ngày gần nhất có thể còn thay đổi vì chuyển đổi được ghi nhận trễ, nên cách an toàn là mỗi lần kéo lại vài ngày gần nhất và ghi đè, thay vì chỉ kéo đúng một ngày hôm qua rồi đóng sổ.

Bước 3. Chuẩn hoá tên trường và kiểu dữ liệu

Đây là chữ T trong ETL, và là nơi tốn công nhất. Những thứ cần chuẩn hoá thường gặp: tên cột (Amount spent, Cost, Chi phí → chi_phi), định dạng ngày (dd/mm/yyyy lẫn mm/dd/yyyy là lỗi kinh điển), múi giờ (tài khoản quảng cáo đặt múi giờ khác nhau thì “ngày 1” không cùng là một ngày), tiền tệ và dấu phân cách hàng nghìn, chữ hoa chữ thường và dấu tiếng Việt trong tên chiến dịch, và giá trị phân loại như kênh: “fb”, “Facebook”, “FB Ads” phải về cùng một giá trị.

Mỗi quy tắc biến đổi nên được viết ra thành bảng ánh xạ (giá trị gốc → giá trị chuẩn) thay vì sửa tay từng ô. Khi có giá trị mới không nằm trong bảng, đường ống nên đánh dấu “chưa phân loại” chứ không tự đoán.

Bước 4. Loại trùng và kiểm tra khoá

Mỗi bảng đích cần một khoá xác định duy nhất một dòng: với chi phí quảng cáo thường là ngày + mã chiến dịch; với đơn hàng là mã đơn. Kiểm tra khoá không trùng (một đơn không bị nạp hai lần khi chạy lại đường ống), không rỗng, và khoá nối giữa các bảng thật sự khớp — mã chiến dịch trong bảng đơn hàng phải có trong bảng chiến dịch. Loại trùng hồ sơ khách từ nhiều nguồn là bài toán khó hơn nhiều, gọi là identity resolution; đừng giải nó bằng một quy tắc so tên đơn giản trong ETL.

Bước 5. Nạp vào kho đích

Nạp sao cho chạy lại không sinh ra dữ liệu trùng: ghi đè theo khoá (cập nhật nếu đã có, thêm nếu chưa có) thay vì cứ nối thêm dòng. Tách lớp dữ liệu thô (giữ nguyên như nguồn) và lớp đã chuẩn hoá, để khi phát hiện quy tắc biến đổi sai, bạn sửa quy tắc và tính lại từ bản thô thay vì phải kéo lại từ nguồn — nhất là khi nguồn không còn giữ dữ liệu cũ.

Bước 6. Theo dõi lỗi và độ trễ

Đường ống sẽ hỏng: mật khẩu hết hạn, quyền bị thu hồi, nền tảng đổi tên cột. Điều nguy hiểm không phải là hỏng mà là hỏng mà không ai biết. Tối thiểu cần: cảnh báo khi một lần chạy thất bại; kiểm tra số dòng và tổng chi phí so với ngày trước; một ô “dữ liệu cập nhật đến ngày nào” hiển thị ngay trên dashboard. Người đọc báo cáo cần biết số liệu mới đến đâu trước khi kết luận.

Ví dụ thực hành: chuẩn hoá tên chiến dịch từ ba nền tảng

Ví dụ giả định: một trung tâm tiếng Anh chạy quảng cáo trên ba nền tảng cho khoá IELTS mùa hè, và lead từ form website được ghi vào bảng tính. Trước khi cộng chi phí và lead theo chiến dịch, dữ liệu trông như sau:

Ba tên chiến dịch khác nhau được ánh xạ về một mã chung nhờ bảng ánh xạ viết tay. Dòng cuối cho thấy giới hạn của ETL: nếu bảng lead chỉ ghi “quảng cáo”, không quy tắc nào suy ra được chiến dịch. Cách sửa không nằm ở đường ống mà ở nguồn: gắn UTM đúng cho link quảng cáo và để form tự ghi lại. Trung tâm cũng thống nhất múi giờ báo cáo, vì một tài khoản quảng cáo đặt múi giờ khác làm chi phí lệch sang ngày hôm sau. Ví dụ này minh hoạ cách ra quyết định, không phải kết quả thực tế của một khách hàng.

AI giúp được gì trong ETL

• Đề xuất bảng ánh xạ từ danh sách giá trị gốc (tên chiến dịch, nguồn lead) — người phụ trách duyệt từng dòng.
• Viết nháp công thức, truy vấn hoặc đoạn mã biến đổi, kèm giải thích để người kỹ thuật kiểm tra.
• Phát hiện điểm bất thường khi bạn đưa bảng tổng hợp: ngày thiếu, giá trị lạ, số liệu tăng giảm đột ngột.
• Soạn tài liệu mô tả đường ống: nguồn, lịch chạy, quy tắc, người chịu trách nhiệm.
• Không làm được: AI có thể ánh xạ sai một cách rất tự tin — gộp hai chiến dịch khác nhau vì tên na ná. Mọi quy tắc biến đổi phải có người duyệt, và không đưa dữ liệu cá nhân của khách vào công cụ AI khi không cần thiết.

Sai lầm thường gặp

• Sửa tay trực tiếp trên bảng tổng hợp: tuần sau nạp lại là mất hết chỗ sửa.
• Không giữ bản thô: phát hiện quy tắc sai thì không còn gì để tính lại.
• Nối thêm dòng mỗi lần chạy thay vì ghi đè theo khoá, sinh dữ liệu trùng.
• Bỏ qua múi giờ và định dạng ngày, chi phí lệch ngày, so sánh tuần sai.
• Dùng ETL để chữa lỗi nguồn: quy ước đặt tên kém thì bảng ánh xạ phình mãi không hết.
• Không có cảnh báo, đường ống dừng từ tuần trước mà dashboard vẫn “đẹp”.

Câu hỏi thường gặp