Thiết kế dữ liệu cho phân tích giữ chân khách hàng: Cần những bảng và trường nào?

Với bài toán cơ bản như tính tỷ lệ mua lại hoặc lập bảng cohort, một bảng có một dòng cho mỗi đơn hàng có thể đủ, miễn là nhận diện được khách và có lịch sử phù hợp. Các bảng chi tiết sản phẩm, hoàn trả và tương tác phục vụ những câu hỏi mở rộng. Bài viết đi từ thiết kế tối thiểu đến cách xây dựng dữ liệu cho dashboard và Machine Learning.

1. Thiết kế dữ liệu bắt đầu từ câu hỏi phân tích

1.1. Chọn dữ liệu theo hành vi cần đo

Giả sử bạn muốn biết bao nhiêu khách mua thêm trong vòng 30 ngày sau đơn đầu. Bạn cần nối được các đơn của cùng một người, xác định thứ tự đặt đơn và biết mỗi người đã có đủ 30 ngày theo dõi hay chưa. Tên khách hàng, địa chỉ giao hàng và tên từng sản phẩm chưa cần thiết cho phép tính này.

1.2. Xác định Data Grain trước khi chọn trường

Data Grain mô tả một dòng trong bảng đại diện cho điều gì. Một dòng trong bảng đơn hàng có thể là một đơn. Một dòng trong bảng chi tiết đơn là một dòng sản phẩm. Một dòng trong bảng Snapshot có thể là trạng thái của một khách vào cuối một tháng.

Grain quyết định cách đếm và cách nối bảng. Nếu một bảng trộn dữ liệu cấp đơn với dữ liệu cấp dòng sản phẩm, số đơn và giá trị đơn có thể bị nhân lên khi tổng hợp. Kimball xem việc xác định Grain là bước đi trước lựa chọn các trường đo lường và chiều phân tích [1].

2. Bộ dữ liệu phân tích giữ chân khách hàng tối thiểu

2.1. Bảng Orders: một dòng cho mỗi đơn hàng

orders là bảng trung tâm cho các bài toán dựa trên giao dịch. Khóa đơn hàng phải duy nhất trong phạm vi phân tích. Nếu cửa hàng và website có thể cấp cùng một order_id, hãy dùng khóa ghép với hệ thống nguồn hoặc tạo một khóa đơn hàng dùng chung.

Chỉ cần các trường trên để tính nhiều chỉ số theo số đơn hoặc số khách. Hãy thêm sales_channel khi cần phân tích kênh, store_id khi cần phân tích cửa hàng và các trường giá trị khi cần phân tích doanh thu. Nếu dùng net_order_amount, cần ghi rõ số tiền đã trừ những khoản nào và đơn vị tiền tệ là gì.

2.2. Bảng Customers và mốc chốt dữ liệu

customers thường có một dòng cho mỗi customer_key. Bảng này hữu ích để lưu thuộc tính phân nhóm như ngày đăng ký hoặc loại thành viên, cũng như để đưa người đã đăng ký nhưng chưa mua vào một bài toán riêng. Nếu chỉ phân tích người đã mua và orders đã có mã khách ổn định, bạn có thể lấy tập khách trực tiếp từ bảng đơn.

Cần ghi thêm mốc chốt mà dữ liệu đã đầy đủ cho phạm vi đang đo. Ví dụ, nếu dữ liệu đầy đủ đến hết ngày 31/3, khách mua lần đầu ngày 25/3 chưa có đủ 30 ngày để đánh giá tỷ lệ mua lại 30 ngày. Ngày của đơn mới nhất nhìn thấy cũng có thể khác mốc dữ liệu đầy đủ, chẳng hạn khi một kênh chưa tải xong đơn hàng.

3. Những bảng mở rộng cần thêm khi nào?

3.1. Chọn bảng theo mục đích sử dụng

Trong Star Schema, Fact Table ghi nhận giao dịch hoặc sự kiện, còn Dimension Table cung cấp thuộc tính để lọc và phân nhóm. Ví dụ, bảng ngày và bảng khách có thể dùng chung để lọc các bảng giao dịch trong Power BI. Mỗi bảng giao dịch cần giữ Grain nhất quán [2].

3.2. Định danh khách đa kênh trước khi tính mua lại

Giả sử một người có mã WEB-125 trên website và POS-872 tại cửa hàng. Nếu hai mã được xác minh thuộc cùng một người, bảng ánh xạ sẽ đưa cả hai về cùng một customer_key. Khi đó, lần mua online rồi mua tại cửa hàng mới được ghi nhận là một khách quay lại ở cấp doanh nghiệp.

Với đơn không nhận diện được, có thể giữ đơn trong tổng doanh số và theo dõi riêng tỷ lệ đơn có mã khách. Khi tính retention, ghi rõ kết quả áp dụng cho tập khách nhận diện được. Nếu gán tất cả đơn ẩn danh cho cùng một mã rồi tính mua lại, hệ thống sẽ biến nhiều người khác nhau thành một người mua nhiều lần.

4. Ví dụ lỗi đếm trùng khi nối bảng

4.1. Một đơn có thể xuất hiện trên nhiều dòng

Giả sử khách C01 có đơn O101 trị giá 300.000 đồng trong tháng 1 và đơn O102 trị giá 150.000 đồng trong tháng 2. O101 có hai dòng sản phẩm, O102 có một dòng. Khi nối orders với order_items theo order_key, dữ liệu sẽ có dạng sau.

Nếu đếm dòng sau khi nối, bạn sẽ thấy 3 thay vì 2 đơn. Nếu cộng cột giá trị cả đơn trên từng dòng, bạn sẽ thu được 750.000 đồng thay vì 450.000 đồng. Với riêng tháng 1, đếm hai dòng sản phẩm của O101 còn có thể khiến C01 bị xếp nhầm vào nhóm đã mua hai lần.

4.2. Tính chỉ số ở đúng Grain

• Số đơn và doanh thu cấp đơn: tính từ bảng orders. Nếu đã nối xuống cấp dòng, có thể đếm khóa đơn riêng biệt. Với doanh thu cấp đơn, cần đưa dữ liệu về một dòng mỗi đơn trước khi cộng.
• Số lượng và doanh thu theo sản phẩm: tính từ order_items với quy tắc phân bổ giảm giá hoặc hoàn trả phù hợp.
• Ngành hàng ở đơn đầu: nếu muốn phân nhóm loại trừ nhau, đặt quy tắc chọn một ngành hàng, chẳng hạn ngành hàng có giá trị dòng cao nhất. Nếu cho một khách thuộc nhiều nhóm, ghi rõ các nhóm chồng lấn và tránh cộng số khách giữa các nhóm để suy ra tổng.

5. Tạo bảng phục vụ dashboard và Machine Learning

5.1. Bảng Customer Cohort và Customer Month

Với dashboard cohort, có thể tạo customer_cohort ở cấp một dòng mỗi khách, gồm customer_key, first_valid_order_at và cohort_month. Tạo thêm customer_month ở cấp một khách mỗi tháng, gồm activity_month, valid_order_count và các chỉ số giá trị nếu cần.

Đơn hàng hợp lệ đã gắn mã khách
               |
               +--> Customer Cohort
               |    Xác định nhóm gốc và quy mô ban đầu
               |
               +--> Customer Month
                    Đếm hoạt động theo khách và tháng
                              |
                              v
                    Bảng Retention theo tuổi cohort

Nếu customer_month chỉ có dòng cho tháng phát sinh đơn, hãy lấy mẫu số từ bảng nhóm gốc. Ví dụ, cohort có 100 khách nhưng chỉ 30 người có dòng giao dịch ở tháng kế tiếp thì Retention Rate là 30/100. Lấy 30 người có dòng hoạt động làm mẫu số sẽ làm tỷ lệ tăng sai thành 100%.

5.2. Bảng Snapshot và dữ liệu đúng thời điểm

Để huấn luyện mô hình dự đoán mua lại, có thể tạo customer_snapshot với một dòng cho mỗi cặp customer_key và as_of_at. Đặc trưng như recency_days hoặc orders_last_90_days phải được tính từ thông tin đã có tại mốc đánh giá. Nhãn như purchased_next_60_days được tạo từ giai đoạn sau mốc đó và chỉ hoàn tất khi đã quan sát đủ 60 ngày.

Thời điểm sự kiện và thời điểm dữ liệu có sẵn có thể khác nhau. Ví dụ, một đơn được đặt ngày 28/3 nhưng đến ngày 2/4 hệ thống mới nhận dữ liệu. Khi tái tạo dữ liệu đầu vào cho dự đoán cuối ngày 31/3, đơn này chưa có sẵn. Nếu nguồn thường gửi trễ hoặc cập nhật lại, hãy lưu thêm thời điểm tiếp nhận hoặc lịch sử phiên bản để tránh Data Leakage. Đây là mục đích của việc nối dữ liệu theo đúng thời điểm, hay Point-in-time Join [3].

Tương tự, nếu một đơn bị hoàn tiền sau ngày đánh giá, báo cáo lịch sử và mô hình có thể cần hai cách nhìn. Báo cáo có thể tính lại theo trạng thái cuối cùng. Mô hình phải dùng trạng thái mà hệ thống biết tại lúc dự đoán.

6. Kiểm tra dữ liệu trước khi công bố chỉ số

1. Kiểm tra khóa theo Grain. Bảng orders có đúng một dòng mỗi khóa đơn. Bảng customer_month có tối đa một dòng mỗi cặp khách và tháng.
2. Đối chiếu trước và sau khi nối. So số đơn riêng biệt và tổng giá trị ở cấp đơn để phát hiện mất dòng hoặc nhân bản dòng.
3. Đo độ phủ nhận diện. Theo dõi tỷ lệ đơn có mã khách theo kênh và theo kỳ. Tỷ lệ nhận diện thay đổi có thể ảnh hưởng đến số khách quay lại quan sát được.
4. Kiểm tra lịch sử và mốc chốt. Ghi rõ từ khi nào dữ liệu đủ tin cậy để xác định đơn đầu và đến ngày nào dữ liệu đã đầy đủ.
5. Đối chiếu thủ công vài trường hợp. Chọn khách có một đơn, khách mua qua hai kênh và khách có đơn hoàn trả. Kiểm tra từ dữ liệu nguồn đến cohort hoặc Snapshot để xác nhận quy tắc hoạt động như dự kiến.

Với dự án đầu tiên, hãy bắt đầu từ bảng orders và thử tái tạo hành trình của một khách từ đơn đầu đến đơn thứ hai. Nếu có thể giải thích vì sao từng đơn được tính, vì sao các đơn thuộc cùng một người và vì sao khách đủ thời gian theo dõi, bạn đã có nền tảng để mở rộng sang cohort, dashboard đa kênh và mô hình dự đoán.

7. Tài liệu tham khảo

1. Kimball Group. Grain. Tài liệu về cách xác định cấp độ chi tiết trước khi chọn trường cho bảng dữ liệu. Đọc hướng dẫn về Grain.
2. Microsoft Learn. Understand star schema and the importance for Power BI. Tài liệu về Fact Table, Dimension Table và các quan hệ trong mô hình Power BI. Đọc hướng dẫn về Star Schema.
3. Feast Documentation. Point-in-time joins. Tài liệu kỹ thuật về truy xuất đặc trưng lịch sử theo thời điểm của từng quan sát. Đọc hướng dẫn về Point-in-time Join.

8. Thực hành phân tích dữ liệu cùng MCNA

Nếu muốn thực hành chuẩn hóa dữ liệu đơn hàng, xây dựng mô hình dữ liệu và tạo báo cáo giữ chân, bạn có thể tham khảo các chương trình tại MCNA Technology School.

• Combo 5 khóa AI & Power BI
• Combo Python