Làm sạch dữ liệu giao dịch để không tính sai tỷ lệ giữ chân

Làm sạch dữ liệu giao dịch giúp xác định chính xác khách nào thuộc nhóm ban đầu, giao dịch nào được tính và ai thực sự quay lại trong khoảng thời gian theo dõi. Đây là bước cần hoàn tất trước khi xây dựng Retention Rate, bảng cohort hoặc dữ liệu cho mô hình dự đoán.

Nguyên tắc xuyên suốt

Mỗi kết quả giữ chân cần truy ngược được về đúng khách hàng, đúng giao dịch hợp lệ và đúng khoảng thời gian quan sát.

1. Làm sạch dữ liệu giao dịch là gì?

1.1. Từ bản ghi nguồn đến giao dịch có thể phân tích

Data Cleaning là quá trình phát hiện và xử lý dữ liệu trùng lặp, thiếu, sai định dạng hoặc không nhất quán. Trong phân tích giao dịch, quá trình này còn cần các quy tắc nghiệp vụ để xác định đơn hàng hợp lệ.

Ví dụ, một đơn có thể xuất hiện nhiều lần vì hệ thống lưu các lần cập nhật trạng thái. Một khách có thể có hai mã ở website và cửa hàng. Một giao dịch lúc cuối tháng theo UTC có thể thuộc tháng tiếp theo theo giờ Việt Nam.

Người phân tích cần hiểu ý nghĩa của các bản ghi trước khi quyết định giữ, gộp, sửa hoặc loại khỏi phép tính.

1.2. Vì sao retention nhạy với chất lượng dữ liệu?

Giả sử mục tiêu là đo tỷ lệ khách mua trong tháng 1 tiếp tục mua trong tháng 2:

Retention Rate
= Số khách có đơn hợp lệ trong cả tháng 1 và tháng 2
  / Số khách có đơn hợp lệ trong tháng 1 × 100%

Phép tính phụ thuộc vào hai tập khách. Đơn thử nghiệm ở tháng 1 có thể làm tăng mẫu số. Đơn hủy ở tháng 2 có thể làm tăng số khách được ghi nhận là quay lại. Một người bị tách thành hai mã có thể khiến giao dịch ở hai tháng không được liên kết.

Vì vậy, cần kiểm tra cả nhóm khách ban đầu và giao dịch quay lại. Làm sạch có thể khiến tỷ lệ tăng hoặc giảm, tùy lỗi ban đầu nằm ở đâu.

2. Những lỗi thường làm sai tỷ lệ giữ chân

3. Quy trình làm sạch dữ liệu giao dịch

3.1. Bước 1 — Thống nhất định nghĩa đơn hợp lệ

Trước khi xử lý dữ liệu, hãy viết rõ giao dịch nào đủ điều kiện để được tính. Một bộ quy tắc có thể gồm:

• Trạng thái đơn: chọn đơn đã thanh toán, đã giao hoặc hoàn tất theo mục tiêu đo lường.
• Đơn thử nghiệm: nhận diện bằng cờ thử nghiệm hoặc danh sách tài khoản nội bộ đã xác minh.
• Đơn hủy: xác định cách xử lý đơn hủy toàn bộ và các trường hợp hủy một phần.
• Hoàn trả: quy định đơn hoàn toàn bộ hoặc hoàn một phần còn được tính là mua hợp lệ hay không.

Cần áp dụng cùng một định nghĩa cho nhóm gốc và nhóm quay lại, trừ khi bài toán chủ động yêu cầu hai hành vi khác nhau. Mọi khác biệt phải được ghi rõ trong tên chỉ số hoặc tài liệu đo lường.

3.2. Bước 2 — Xác định cấp độ của mỗi dòng

Data Grain mô tả một dòng đại diện cho điều gì. Dữ liệu nguồn có thể ở cấp đơn hàng, dòng sản phẩm hoặc sự kiện cập nhật đơn.

Ví dụ, đơn O101 có ba sản phẩm có thể xuất hiện trên ba dòng. Nếu dùng số dòng làm số đơn, khách có một lần đặt hàng sẽ bị ghi nhận thành ba lần.

Để phân tích mua lại theo đơn, hãy tạo tập dữ liệu có một dòng cho mỗi đơn hoặc sử dụng cách đếm khóa đơn riêng biệt phù hợp. Nếu mã đơn chỉ duy nhất trong từng hệ thống, cần kết hợp mã hệ thống nguồn với mã đơn.

3.3. Bước 3 — Xử lý bản ghi trùng và lịch sử cập nhật

Cần phân biệt hai trường hợp:

• Bản tải lặp: cùng một bản ghi bị nhập nhiều lần do quá trình đồng bộ hoặc chạy lại.
• Phiên bản cập nhật: cùng một đơn có nhiều bản ghi với trạng thái hoặc thông tin thay đổi theo thời gian.

Với bản tải lặp đã xác nhận, có thể giữ một bản. Với lịch sử cập nhật, cần chọn phiên bản theo mục tiêu báo cáo. Công cụ loại trùng cho phép chỉ định cột xác định trùng và bản ghi được giữ, nên quy tắc lựa chọn phải được xác định trước [1].

Lưu ý về thứ tự xử lý

Khi lập báo cáo theo trạng thái mới nhất, hãy chọn phiên bản đơn trước rồi mới lọc đơn hợp lệ. Lọc trạng thái Completed quá sớm có thể giữ lại phiên bản cũ của một đơn sau đó đã bị hủy.

3.4. Bước 4 — Chuẩn hóa mã khách hàng

Một khách có thể mua bằng tài khoản website, số điện thoại tại cửa hàng hoặc tài khoản trên ứng dụng. Nếu hệ thống có căn cứ liên kết các định danh này, hãy ánh xạ chúng về một mã khách dùng chung.

Quá trình chuẩn hóa cần lưu ý:

• Kiểu dữ liệu: giữ mã ở dạng phù hợp để bảo toàn các ký tự và số 0 ở đầu.
• Quy tắc gộp: xác minh căn cứ liên kết, đặc biệt khi số điện thoại hoặc email có thể được dùng chung.
• Giá trị thiếu: theo dõi riêng các đơn chưa nhận diện được người mua.
• Độ phủ nhận diện: đo tỷ lệ đơn có mã khách theo từng kênh và từng kỳ.

Nếu gộp mọi đơn thiếu mã vào một khách Unknown rồi tính mua lại, hệ thống sẽ coi giao dịch của nhiều người là lịch sử của một người. Với các đơn này, có thể giữ trong báo cáo doanh số và quản lý riêng phạm vi được dùng để tính retention.

3.5. Bước 5 — Chuẩn hóa thời gian

Hãy xác định múi giờ nguồn và múi giờ báo cáo trước khi lấy ngày hoặc tháng. Ví dụ, 18:00 UTC ngày 31/1 tương ứng 01:00 ngày 1/2 theo giờ Việt Nam.

Nên phân biệt các mốc:

• Thời điểm đặt đơn: dùng khi đo hành vi đặt hàng.
• Thời điểm thanh toán hoặc hoàn tất: dùng nếu đó là sự kiện được chọn trong định nghĩa.
• Thời điểm tiếp nhận dữ liệu: giúp phát hiện giao dịch đến trễ.

Chọn một mốc sự kiện nhất quán cho phép tính. Nếu thay đổi từ ngày đặt sang ngày hoàn tất giữa hai kỳ, đơn có thể chuyển kỳ và làm lệch kết quả so sánh.

3.6. Bước 6 — Kiểm tra lịch sử và thời gian theo dõi

Nếu dữ liệu chỉ bắt đầu từ tháng 1, giao dịch đầu tiên quan sát được trong tháng 1 có thể thuộc một khách đã mua từ năm trước. Khi chưa đủ lịch sử để xác minh, hãy ghi rõ đây là cohort theo lần mua đầu tiên quan sát được.

Ở phía cuối dữ liệu, cần kiểm tra khách đã có đủ cơ hội quay lại chưa. Người mua lần đầu ngày 25/3 chưa đủ 30 ngày theo dõi khi dữ liệu chốt hết ngày 31/3.

Với chỉ số mua lại trong 30 ngày, chỉ tính những khách có cửa sổ theo dõi đã hoàn tất. Các kỳ retention chưa hoàn tất cần được xử lý riêng khi tổng hợp [3].

4. Ví dụ trước và sau khi làm sạch

4.1. Dữ liệu giao dịch ban đầu

Giả sử cửa hàng đo tỷ lệ khách mua tháng 1 quay lại trong tháng 2. Dữ liệu hai tháng đã đầy đủ và bốn khách được nhận diện chính xác. Toàn bộ số liệu dưới đây là giả định.

4.2. Áp dụng quy tắc làm sạch

Trong ví dụ này, cửa hàng chọn đơn hoàn tất và loại đơn thử nghiệm. Kết quả xử lý từng khách như sau:

• Khách A: giữ một bản của đơn tháng 2 và ghi nhận quay lại.
• Khách B: giữ trong nhóm tháng 1, đơn hủy tháng 2 bị loại khỏi hành vi quay lại.
• Khách C: giữ trong nhóm tháng 1 và ghi nhận chưa quay lại ở tháng 2.
• Khách D: loại khỏi nhóm khách tháng 1 vì chỉ có đơn thử nghiệm.

4.3. So sánh kết quả

Tỷ lệ thay đổi vì loại đơn thử nghiệm ở mẫu số và đơn hủy ở tử số. Bản tải lặp của A làm tăng số dòng, nhưng không tăng số khách quay lại nếu phép tính đã đếm khách riêng biệt.

Điểm này giúp xác định đúng nguyên nhân chênh lệch. Mỗi lỗi cần được đối chiếu với cách tổng hợp thực tế để biết nó ảnh hưởng đến số dòng, số đơn, doanh thu hay số khách.

5. Những quyết định cần xử lý thận trọng

5.1. Không dùng giá trị đơn làm điều kiện duy nhất

Đơn bằng 0 có thể đến từ việc sử dụng điểm thưởng hoặc ưu đãi hợp lệ. Một bản ghi âm có thể là hoàn tiền được liên kết với đơn trước.

Hãy kiểm tra loại giao dịch, trạng thái và quan hệ với đơn gốc trước khi loại. Cách xử lý cần phù hợp với hành vi mà chỉ số muốn đo.

5.2. Kiểm tra dữ liệu sau phép nối bảng

Một đơn có hai dòng sản phẩm khi nối với bảng chi tiết sẽ xuất hiện hai lần. Nếu tiếp tục nối với nhiều sự kiện giao hàng, số dòng có thể tăng thêm.

Trước và sau phép nối, hãy so sánh số đơn riêng biệt và các tổng giá trị cần bảo toàn. Trong pandas, tham số validate của phép merge có thể kiểm tra quan hệ dự kiến như many-to-one [2].

5.3. Phân biệt báo cáo cập nhật và dữ liệu tại thời điểm dự đoán

Một đơn hoàn tất ngày 10/3 có thể bị hoàn trả ngày 20/3. Báo cáo cập nhật cuối tháng có thể xử lý lại đơn theo chính sách hoàn trả. Khi tái tạo thông tin cho dự đoán ngày 15/3, cần dùng những gì hệ thống biết tại ngày đó.

Nếu đưa thông tin hoàn trả ngày 20/3 vào dữ liệu đầu vào của dự đoán ngày 15/3, sẽ xảy ra Data Leakage. Vì vậy, dữ liệu phục vụ Machine Learning cần lưu hoặc tái tạo được lịch sử theo thời điểm.

5.4. Giữ dấu vết các bản ghi bị loại

Thay vì chỉ lưu bảng kết quả cuối, hãy ghi lại lý do loại, số lượng bị ảnh hưởng, thời điểm xử lý và phiên bản quy tắc. Khi chỉ số thay đổi, nhóm phân tích có thể kiểm tra mức thay đổi đến từ hành vi khách hay cách xử lý dữ liệu.

Dữ liệu nguồn
      |
      v
Kiểm tra cấu trúc và phiên bản
      |
      v
Chuẩn hóa khách hàng, thời gian và đơn hợp lệ
      |
      v
Đối chiếu số đơn và số khách
      |
      v
Tạo nhóm gốc và xác định khách quay lại
      |
      v
Tính Retention Rate và lưu dấu vết

6. Checklist trước khi công bố kết quả

1. Đã viết rõ hành vi mua và điều kiện đơn hợp lệ.
2. Đã xác định Grain và khóa đơn duy nhất.
3. Đã phân biệt bản tải lặp với lịch sử cập nhật.
4. Đã chuẩn hóa định danh và theo dõi tỷ lệ đơn có mã khách.
5. Đã thống nhất thời điểm sự kiện và múi giờ báo cáo.
6. Đã kiểm tra độ dài lịch sử và dữ liệu đến trễ.
7. Đã loại riêng các kỳ chưa đủ thời gian theo dõi.
8. Đã giữ khách chưa quay lại trong mẫu số của nhóm gốc.
9. Đã kiểm tra tác động của các phép nối bảng.
10. Đã đối chiếu một số khách từ dữ liệu nguồn đến kết quả cuối.

Một kết quả có thể kiểm tra lại cần đi kèm định nghĩa, phạm vi dữ liệu và dấu vết xử lý. Với mỗi khách được chọn để đối chiếu, người phân tích nên giải thích được giao dịch nào được giữ, giao dịch nào bị loại và vì sao khách nằm trong tử số hoặc mẫu số.

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

1. pandas. DataFrame.drop_duplicates. Tài liệu về lựa chọn cột xác định trùng và bản ghi được giữ lại. Đọc tài liệu xử lý bản ghi trùng.
2. pandas. DataFrame.merge. Tài liệu về nối bảng và kiểm tra quan hệ bằng tham số validate. Đọc tài liệu kiểm tra phép nối bảng.
3. Amplitude Docs. How the Retention Analysis chart calculates retention. Tài liệu về cách tính retention và xử lý các kỳ chưa hoàn tất. Đọc hướng dẫn tính Retention.

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

Để thực hành chuẩn hóa dữ liệu giao dịch, xây dựng chỉ số và trình bày báo cáo phân tích khách hàng, bạn có thể tham khảo các chương trình tại MCNA Technology School.