Ánh xạ dữ liệu khi chuyển nền tảng eCommerce: Cách trường tùy chỉnh, biến thể và SKU luôn được liên kết đúng

Ánh xạ dữ liệu trong quá trình chuyển nền tảng eCommerce xác định dữ liệu từ cửa hàng nguồn sẽ nằm ở đâu trên nền tảng mới, cách giữ nguyên ý nghĩa của dữ liệu và những bản ghi nào cần tiếp tục liên kết với nhau. Khi được thiết lập đúng, một biến thể vẫn thuộc đúng sản phẩm, SKU vẫn gắn với đúng mặt hàng có thể bán và đơn hàng vẫn liên kết với đúng khách hàng.

Với chủ cửa hàng, điều đó tạo ra sự yên tâm rất thực tế: khách có thể chọn đúng kích cỡ họ muốn, kho nhận đúng mã hàng và bộ phận chăm sóc khách hàng vẫn hiểu được một đơn hàng cũ. Danh mục có thể trông đầy đủ nhưng chỉ cần một trong những mối liên kết này sai, hoạt động phía sau vẫn có thể gặp vấn đề. Vì vậy, ánh xạ nên được kiểm tra kỹ trước Full Migration.

Ánh xạ dữ liệu thực sự kết nối những gì?

Mỗi nền tảng đều có một schema, tức cấu trúc dùng để tổ chức sản phẩm, khách hàng, đơn hàng và các trường dữ liệu. Hai cửa hàng có thể hiển thị cùng một trang sản phẩm nhưng lưu thông tin theo cách rất khác ở bên dưới. Ánh xạ giúp nối các cấu trúc đó theo kết quả bạn muốn đạt được.

Ba khái niệm sau giúp quá trình này dễ hiểu hơn:

Ánh xạ trường dữ liệu: chọn nơi một giá trị sẽ được lưu ở cửa hàng đích, chẳng hạn mã tham chiếu nhà cung cấp hoặc mã số thuế của khách hàng.

Ánh xạ mối quan hệ: giữ nguyên liên kết giữa các bản ghi, chẳng hạn giữa sản phẩm và các biến thể hoặc giữa khách hàng và đơn hàng của họ.

Chuyển đổi dữ liệu: thay đổi một giá trị theo quy tắc đã thống nhất, chẳng hạn đổi trọng lượng từ gam sang kilôgam.

Những quyết định này cần nằm trong cùng một kế hoạch di chuyển nhưng chúng giải quyết các vấn đề khác nhau. Chuyển giá trị “500” vào trường trọng lượng không tự biến nó thành 0,5 kg. Tương tự, sao chép ID sản phẩm vào một đơn hàng không tạo ra mối liên kết hợp lệ nếu nền tảng đích cấp ID khác.

Theo dõi một sản phẩm xuyên suốt quá trình di chuyển

Hãy hình dung một cửa hàng đồ outdoor bán áo khoác Trail Jacket với hai màu và ba kích cỡ. Biến thể màu navy, size M có SKU TJ-NV-M, số lượng tồn kho riêng và barcode riêng. Sản phẩm còn có trường hướng dẫn chăm sóc, trong khi mỗi biến thể có một mã nhà cung cấp riêng.

Quá trình di chuyển phải giữ đúng thông tin nào thuộc về toàn bộ sản phẩm và thông tin nào chỉ thuộc về một tổ hợp cụ thể. Nếu mã nhà cung cấp của từng biến thể bị chuyển lên sản phẩm cha, mọi kích cỡ có thể cùng trỏ tới một mặt hàng của nhà cung cấp.

Dưới đây là một kế hoạch ánh xạ minh họa. Các nhãn mô tả kết quả mong muốn, không phải cam kết rằng những trường này đều có sẵn trên mọi cặp nền tảng.

Với một dự án từ WooCommerce sang Shopify, hãy bắt đầu bằng dữ liệu được hỗ trợ cho đúng cặp nền tảng đó. WooCommerce cho phép các variation có giá, tồn kho và hình ảnh riêng; mô hình product variant của Shopify cũng liên kết từng tổ hợp có thể bán với thông tin sản phẩm và tồn kho. Giao diện cửa hàng có thể trông tương tự nhưng vẫn cần kiểm tra kỹ trường dữ liệu và các mối quan hệ.

Biến thể và SKU được giữ liên kết như thế nào?

Biến thể đại diện cho một tổ hợp có thể bán. SKU là mã định danh nghiệp vụ gắn với một mặt hàng. Internal ID xác định một bản ghi bên trong một hệ thống cụ thể. Nếu coi ba loại thông tin này là một, việc đối sánh rất dễ sai.

Giữ sản phẩm cha và từng tổ hợp có thể bán tách biệt

Với Trail Jacket, “Navy / Medium” phải tiếp tục thuộc đúng sản phẩm cha, cùng mức giá, tồn kho, hình ảnh và barcode chính xác. Một bước kiểm tra tốt sẽ theo dõi chính tổ hợp đã chọn từ trang sản phẩm tới đơn hàng. Chỉ đếm đủ sáu biến thể đã nhập chưa thể chứng minh các thuộc tính của chúng là đúng.

Cũng cần phân biệt biến thể với các trường cá nhân hóa. Nội dung khắc tên hoặc ghi chú giao hàng có thể mô tả một giao dịch mua nhưng không đại diện cho một mặt hàng tồn kho riêng. Nếu chuyển mọi tùy chọn thành biến thể, cấu trúc danh mục có thể thay đổi và tạo ra những tổ hợp cửa hàng chưa từng bán.

Kiểm tra SKU có đủ tin cậy để dùng làm khóa đối sánh hay không

SKU có thể giúp đối sánh bản ghi khi chúng được điền đầy đủ, duy nhất trong phạm vi đã thống nhất và ổn định. SKU sẽ kém tin cậy hơn nếu sản phẩm cha và các sản phẩm con dùng chung một mã, hai cửa hàng nguồn tái sử dụng cùng mã hoặc các sản phẩm cũ không có SKU.

• Tìm SKU bị thiếu hoặc trùng ở cả cấp sản phẩm và biến thể.
• Giữ nguyên định dạng có ý nghĩa, gồm số 0 ở đầu, dấu câu và chữ hoa/chữ thường.
• Thống nhất cách bản ghi nguồn sẽ đối sánh với các mặt hàng đã có sẵn ở cửa hàng đích.
• Ghi lại các ngoại lệ thay vì tự động đổi tên những mã đang được hệ thống tồn kho hoặc fulfillment sử dụng.

Khi SKU không phải khóa an toàn, quá trình di chuyển cần một phương thức đối sánh khác được hỗ trợ hoặc một quy tắc tùy chỉnh đã thống nhất. Bảng đối chiếu ID từ nguồn sang đích có thể giữ nguyên mối quan hệ ngay cả khi nền tảng đích tạo internal ID mới.

Quan trọng: Giữ nguyên SKU không tự động kết nối lại ERP, hệ thống kho hoặc feed marketplace. Hãy kiểm tra từng tích hợp đang dùng mã định danh nào và kiểm thử kết nối riêng.

Trường tùy chỉnh nên được đưa vào đâu?

Hãy bắt đầu từ mục đích của trường dữ liệu rồi mới chọn nơi lưu. Hướng dẫn chăm sóc là văn bản để đọc. Mã nhà cung cấp là mã định danh. Mã số thuế của khách hàng có thể phục vụ một quy trình nghiệp vụ. Đưa cả ba vào trường mô tả có thể giữ nguyên ký tự nhưng khiến dữ liệu khó sử dụng về sau.

Với mỗi trường tùy chỉnh, hãy xác nhận bốn điểm:

• Phạm vi sở hữu: trường này thuộc về sản phẩm, biến thể, khách hàng, đơn hàng hay dòng đơn hàng?
• Kiểu dữ liệu: cửa hàng đích nên lưu dưới dạng văn bản, số, ngày, đúng/sai hay tham chiếu?
• Ý nghĩa: đơn vị, giá trị cho phép, giá trị trống và định dạng có được hiểu nhất quán không?
• Cách sử dụng: theme, app, bộ lọc hoặc tích hợp nào cần đọc trường này?

Ví dụ, mã nhà cung cấp như 00127 nên được lưu như một mã định danh thay vì mặc định coi đó là số lượng. Nếu không, việc chuyển đổi số có thể làm mất các số 0 ở đầu. Nếu một trường nguồn chứa nhiều giá trị, hãy xác định nền tảng đích có chấp nhận danh sách hay cần một cấu trúc khác được hỗ trợ.

Một trường cũng có thể di chuyển thành công nhưng không xuất hiện trên storefront. Việc lưu trữ, hiển thị, lọc và hành vi của app cần được kiểm tra riêng. Hướng dẫn của chúng tôi về metadata, trường tùy chỉnh và extension giải thích rõ những khác biệt này; bài viết về cách tổ chức trường tùy chỉnh và quy trình quản lý tài khoản cũng cho thấy chúng quan trọng thế nào với cửa hàng bán buôn.

Trước khi chốt thiết kế trường dữ liệu, hãy gửi cho Next-Cart một bản ghi thông thường và một ví dụ khó. Việc cho thấy giá trị nguồn cùng kết quả bạn cần sẽ hữu ích hơn nhiều so với yêu cầu chung chung như “chuyển tất cả trường tùy chỉnh”.

Danh mục, khách hàng và đơn hàng cũng cần được ánh xạ

Danh mục: giữ đúng vị trí và cách điều hướng mong muốn

Một chiếc áo khoác có thể đồng thời thuộc Outerwear và Winter Essentials. Hãy quyết định các membership đó và cấu trúc danh mục cha-con cần hiển thị thế nào ở cửa hàng đích. Kiểm tra cả vị trí của sản phẩm lẫn sự tồn tại của từng danh mục. Nếu nền tảng đích tổ chức collection theo cách khác, một quy tắc rõ ràng hữu ích hơn việc chỉ ghép theo tên danh mục.

Khách hàng: bảo vệ danh tính và bối cảnh nghiệp vụ

Email, địa chỉ thanh toán, mã số thuế và phân loại tài khoản của khách hàng phục vụ các mục đích khác nhau. Hãy thống nhất chính sách đối sánh trước khi gộp bản ghi. Việc nhiều cửa hàng dùng chung một địa chỉ email tự thân không có nghĩa các tài khoản doanh nghiệp đó được phép gộp.

Với khách hàng bán buôn, group label hoặc trường thuế đã di chuyển cũng cần được kiểm tra với cấu hình tài khoản và giá ở nền tảng đích. Chỉ lưu được giá trị không có nghĩa quy trình từng sử dụng giá trị đó đã được tái tạo.

Đơn hàng: giữ nguyên ý nghĩa của giao dịch gốc

Một đơn hàng liên kết khách hàng với mặt hàng đã mua, số lượng, giá, thuế, giảm giá và thông tin vận chuyển. Các giá trị lịch sử nên phản ánh giao dịch ban đầu thay vì âm thầm được tính lại theo danh mục hiện tại.

Hãy chuẩn bị cho đơn hàng khách vãng lai, sản phẩm đã xóa và biến thể đã ngừng bán. Khi không thể tái tạo liên kết với sản phẩm đang hoạt động, cần xác định cách giữ lại chi tiết dòng đơn hàng lịch sử được hỗ trợ. Hãy kiểm tra đơn hàng như một nhân viên chăm sóc khách hàng: bạn có thể biết khách đã mua gì và hiểu được tổng tiền không?

Làm sao kiểm tra ánh xạ trước khi go-live?

Dùng Demo Migration để kiểm tra các bản ghi đại diện, sau đó lặp lại những bước kiểm tra liên quan sau Full Migration và bất kỳ lần chạy bổ sung nào đã được phê duyệt. Nếu mẫu demo không có một edge case quan trọng, hãy sắp xếp kiểm tra thêm trước khi coi yêu cầu đó đã được chứng minh.

Tạo một bộ dữ liệu kiểm thử nhỏ, chủ động bao gồm những bản ghi khó:

• Một sản phẩm có nhiều biến thể, hình ảnh khác nhau và trường tùy chỉnh riêng cho từng biến thể.
• Một SKU bị thiếu hoặc trùng và một mã định danh có số 0 ở đầu.
• Một sản phẩm thuộc nhiều danh mục và một khách hàng có các trường dữ liệu doanh nghiệp.
• Một đơn hàng có giảm giá, một đơn hàng khách vãng lai và một đơn hàng chứa mặt hàng đã ngừng bán.

Với mỗi ví dụ, hãy ghi lại giá trị nguồn, kết quả mong muốn ở đích, kết quả thực tế và mọi sai lệch. So sánh ba lớp: số lượng bản ghi, giá trị trường và mối quan hệ. Giải thích chênh lệch số lượng do lọc, gộp hoặc tái cấu trúc đã được phê duyệt; đừng mặc định tổng số bằng nhau đồng nghĩa dữ liệu chính xác.

Kết thúc bằng kiểm tra hành vi. Chọn một biến thể, xem thông tin hiển thị, thêm vào giỏ hàng và xác minh mặt hàng tạo ra. Kiểm tra lịch sử đơn hàng của khách hàng khi phù hợp và thử các tích hợp đang sử dụng mã định danh đã di chuyển. Những bước này nối độ chính xác trong cơ sở dữ liệu với hoạt động hằng ngày của cửa hàng.

Trước khi nghiệm thu: Hãy xử lý các sai lệch quan trọng, kiểm thử lại bản ghi bị ảnh hưởng và lưu các quy tắc ánh xạ đã được phê duyệt cùng ghi chú dự án. Nếu quy tắc thay đổi sau đó, hãy xem xét tác động lên dữ liệu đã di chuyển trước khi chạy migration lần nữa.

Khi nào ánh xạ cần Custom Migration?

Có trường tùy chỉnh không đồng nghĩa mọi dự án đều cần kỹ thuật tùy chỉnh. Câu hỏi quyết định là kết quả bạn cần có nằm trong hành vi được hỗ trợ của Migration Path đã chọn và các Add-ons áp dụng hay không.

Advanced Data Mapping của Next-Cart đưa các trường nguồn được hỗ trợ tới những vị trí tương thích. Data Transformation xử lý các thay đổi giá trị được hỗ trợ. Những trường và thao tác khả dụng phụ thuộc vào migration đang hoạt động, vì vậy hãy xác nhận yêu cầu cụ thể trước khi chọn Add-on.

Standard Migration phù hợp với phần việc được hỗ trợ mà bạn tự quản lý. Managed Migration bổ sung việc thực thi do Next-Cart đảm nhiệm trong phạm vi được hỗ trợ. Không dịch vụ nào nên được hiểu là cam kết tái tạo mọi hành vi của app hoặc cơ sở dữ liệu tùy chỉnh.

Custom Migration phù hợp để xem xét khi dự án cần trích xuất chưa được hỗ trợ, logic đối sánh riêng, mối quan hệ bất thường hoặc quy tắc tùy biến. Ví dụ gồm gộp nhiều danh mục nguồn theo quy tắc riêng của doanh nghiệp hoặc chuyển dữ liệu do app quản lý sang một cấu trúc đích khác.

Hãy chuẩn bị bản ghi mẫu, kết quả đích mong muốn, quy tắc đối sánh và chuyển đổi, các hệ thống liên quan cùng tiêu chí nghiệm thu rõ ràng. Nhờ đó, đội ngũ có cơ sở cụ thể để đánh giá tính khả thi và xác định phạm vi công việc.

Tạo nền tảng dữ liệu rõ ràng cho cửa hàng mới

Ánh xạ tốt giúp giữ nguyên ý nghĩa của danh mục và lịch sử khách hàng khi bạn đổi nền tảng. Khi cấu trúc sản phẩm, mã định danh, trường tùy chỉnh và mối quan hệ giao dịch được xem xét cùng nhau, đội ngũ sẽ dễ phát hiện vấn đề và phê duyệt kết quả hơn.

Sẵn sàng kiểm tra dữ liệu cửa hàng? Hãy yêu cầu Demo với Next-Cart và mang theo các bản ghi đại diện để cùng xem xét. Nếu muốn hiểu thêm về các hệ thống phía sau một dự án di chuyển, hãy khám phá các bài viết eCommerce Technology của chúng tôi.