Đưa dữ liệu sang Jumpseller không chỉ là ghép một cột ở Cửa hàng nguồn với một trường tương ứng ở Cửa hàng đích. Jumpseller tách Products cấp cha, các biến thể có thể bán, thông tin cá nhân hóa do khách hàng nhập, trường mô tả tùy chỉnh, quan hệ với Categories, điều hướng, tồn kho, danh tính Customers, lịch sử đơn hàng, nội dung storefront và dữ liệu tích hợp thành những quan hệ khác nhau. Trong khi đó, Nền tảng nguồn có thể lưu nhiều ý nghĩa nói trên trong cùng một hệ thống thuộc tính hoặc một bảng của extension.
Vì vậy, câu hỏi trung tâm không phải là giá trị nguồn có sao chép được hay không. Điều cần xác định là đối tượng nào trên Jumpseller phải sở hữu giá trị đó và quan hệ nào phải được giữ đúng. Kích thước và màu sắc có thể tạo thành biến thể có tồn kho riêng; nội dung khắc tên có thể chỉ là thông tin khách hàng nhập cho một lần mua; thương hiệu có thể là trường tùy chỉnh phục vụ lọc Products. Categories có thể tổ chức catalog mà không tự tái tạo menu cũ. Mã định danh bên ngoài vẫn có thể rất quan trọng dù khách hàng không bao giờ nhìn thấy.
Products là bản ghi catalog cấp cha, không phải toàn bộ đơn vị bán thực tế
Một bản ghi Products trên Jumpseller tạo ra danh tính catalog dùng chung cho một mặt hàng được chào bán. Bản ghi này có thể chứa tên, mô tả, hình ảnh, quan hệ Categories, trạng thái, giá mặc định, thiết lập tồn kho, thông tin SEO, tùy chọn, trường tùy chỉnh và dữ liệu merchandising khác. Tuy nhiên, khi các tùy chọn tạo thành biến thể, Products cấp cha không còn là nơi sở hữu toàn bộ giá trị thương mại của từng tổ hợp.
Các Nền tảng nguồn có thể phân tách Products cấp cha và đơn vị bán thực tế theo nhiều cách. Một nền tảng có thể lưu mỗi tổ hợp kích thước và màu sắc như một bản ghi Products độc lập. Nền tảng khác lưu một bản ghi Products với các SKU con. Trường hợp khác vẫn có Products cấp cha nhưng hình ảnh, giá vốn, tồn kho và phần điều chỉnh giá lại nằm trong một ma trận do app quản lý. Khi sang Jumpseller, dự án phải duy trì đúng quan hệ cha-con thay vì dàn phẳng mọi bản ghi về cùng một cấp.
| Mô hình catalog ở Cửa hàng nguồn | Cách diễn giải trên Jumpseller | Hệ quả đối với quan hệ dữ liệu |
|---|---|---|
| Mỗi kích thước và màu sắc là một bản ghi riêng | Một bản ghi Products cấp cha với các biến thể được tạo từ tùy chọn, khi các bản ghi thực chất cùng thuộc một nhóm merchandising | Mô tả dùng chung và Categories có thể nằm ở Products cấp cha, trong khi SKU, tồn kho, giá, trọng lượng và hình ảnh có thể thuộc từng biến thể. |
| Products cấp cha với các SKU con | Products cùng các tổ hợp biến thể | Mã định danh con hiện có phải tiếp tục gắn với đúng tổ hợp tùy chọn tương ứng. |
| Products đơn giản không có lựa chọn | Products sở hữu trực tiếp các giá trị thương mại của bản ghi đó | Không cần tạo lớp biến thể giả chỉ vì Nền tảng nguồn có một bảng thuộc tính. |
| Mặt hàng kỹ thuật số hoặc không cần vận chuyển | Products có ý nghĩa về giao nhận và tồn kho khác hàng vật lý | Tham chiếu giao sản phẩm, tệp và kỳ vọng vận chuyển phải được tách khỏi dữ liệu tồn kho thông thường. |
| Nhóm Products do app tạo | Bản ghi Products cùng các quan hệ do app sở hữu | Giá trị mô tả có thể phù hợp với trường tiêu chuẩn, nhưng quy tắc phát sinh hoặc bản ghi liên kết vẫn thuộc app nguồn hoặc một hệ thống đích khác. |
Trạng thái Products cũng mang ý nghĩa riêng. Các trạng thái như đang hoạt động, ẩn, bản nháp, lưu trữ, ngừng kinh doanh hoặc cho phép backorder ở Cửa hàng nguồn có thể không tương ứng trực tiếp với một trạng thái Jumpseller. Cách biểu diễn phía đích cần phân biệt khả năng hiển thị công khai, khả năng mua, tình trạng tồn kho và việc giữ Products theo mùa thay vì ép mọi trạng thái về hai lựa chọn bật hoặc tắt.
Tùy chọn, biến thể, thông tin khách hàng nhập và trường tùy chỉnh là các cấu trúc khác nhau
Tùy chọn Products trên Jumpseller có thể tạo ra biến thể thực, nhưng không phải mọi giá trị giống một “option” ở Cửa hàng nguồn đều nên đi vào lưới biến thể. Lựa chọn như kích thước hoặc màu sắc có thể tạo các tổ hợp với SKU, giá, tồn kho, trọng lượng, giá vốn và quan hệ hình ảnh riêng. Các loại nhập liệu khác có thể thu thập văn bản, lời nhắn dài, tệp hoặc lựa chọn bổ sung mà không tạo một tổ hợp cần quản lý tồn kho độc lập.
Trường tùy chỉnh của Products phục vụ mục đích khác. Chúng mô tả Products và có thể hỗ trợ khách hàng khám phá catalog khi được tổ chức dưới dạng giá trị lựa chọn phù hợp. Thương hiệu, chất liệu, nhóm hương, loại tương thích, mùa hoặc thông số kỹ thuật có thể nằm ở lớp này khi chúng không tạo ra một đơn vị bán độc lập.
| Ý nghĩa kinh doanh | Cấu trúc phù hợp trên Jumpseller | Không được làm mất |
|---|---|---|
| Kích thước hoặc màu sắc có tồn kho riêng | Tùy chọn Products tạo biến thể | Danh tính tổ hợp, SKU, tồn kho, giá, trọng lượng và quan hệ hình ảnh |
| Nội dung khắc tên, lời đề tặng hoặc lời nhắn ngắn | Trường văn bản do khách hàng nhập | Giá trị đã chọn phải đi cùng dòng hàng đã mua trong Orders, không trở thành mô tả dùng chung của Products cấp cha. |
| Hướng dẫn cá nhân hóa chi tiết | Vùng nhập văn bản dài | Nội dung tự do của người mua không được chuyển thành metadata catalog có thể tái sử dụng. |
| Hình ảnh hoặc tài liệu do người mua cung cấp | Trường tải tệp lên | Tham chiếu tệp thuộc ngữ cảnh giao dịch, không thuộc tồn kho. |
| Bao bì tùy chọn hoặc phần bổ sung có thu phí | Lựa chọn không tạo biến thể khi Jumpseller có cấu trúc phù hợp | Ảnh hưởng đến giá và giá trị đã chọn cho chi tiết mặt hàng trong Orders phải tách khỏi biến thể có tồn kho. |
| Thương hiệu, chất liệu, nhóm hương, lớp tương thích hoặc thông số | Trường tùy chỉnh của Products | Giá trị mô tả có thể hỗ trợ thông tin Products hoặc bộ lọc mà không làm tăng số biến thể. |
| Quy tắc configurator theo điều kiện | Quan hệ thuộc app hoặc hệ thống bên ngoài | Mối phụ thuộc, công thức và điều kiện hiển thị không tương đương với giá trị tùy chọn thông thường. |
Phân biệt đúng các cấu trúc này giúp tránh tạo biến thể quá mức. Nếu một catalog nguồn lưu màu sắc, kích thước, nội dung monogram, lựa chọn bảo hành và thông số kỹ thuật trong cùng một bảng thuộc tính, khi sang Jumpseller có thể cần tới bốn cách biểu diễn khác nhau. Đưa cả năm yếu tố vào lưới biến thể sẽ tạo ra các tổ hợp không phải đơn vị tồn kho thực. Ngược lại, biến tất cả thành trường mô tả sẽ làm mất khả năng lựa chọn và quản lý tồn kho của những biến thể thực sự.
Categories, điều hướng và bộ lọc tạo ra các quan hệ khám phá Products khác nhau
Categories trên Jumpseller tổ chức Products và có thể tạo cấu trúc cha-con. Mỗi Categories cũng có thể gắn với tên, mô tả, hình ảnh, thứ tự, thông tin SEO và quan hệ Products. Vì vậy, dữ liệu Categories rất quan trọng đối với cấu trúc catalog, nhưng bản ghi Categories không tự tái tạo toàn bộ hành trình điều hướng trên storefront.
Điều hướng có thể đưa Categories vào menu chính, menu Categories hoặc footer, đồng thời cho phép lồng các mục theo cách độc lập với quan hệ Products-Categories. Taxonomy ở Cửa hàng nguồn cũng có thể chứa nhóm merchandising nội bộ, collection chiến dịch, thương hiệu, facet tìm kiếm hoặc nhãn vận hành bị ẩn. Mỗi nhóm cần được xác định rõ ý nghĩa khi sang Jumpseller.
| Nhóm dữ liệu ở Cửa hàng nguồn | Đối tượng có thể sở hữu trên Jumpseller | Quyết định khi chuyển đổi |
|---|---|---|
| Nhóm Products ổn định lâu dài | Categories và quan hệ Products-Categories | Duy trì cấu trúc phân cấp và quan hệ thành viên như một phần của catalog. |
| Nhánh điều hướng chính | Mục điều hướng trỏ tới Categories hoặc một trang khác | Tách đường dẫn và vị trí menu khỏi việc Categories có tồn tại hay không. |
| Facet thương hiệu hoặc chất liệu | Trường tùy chỉnh của Products và quan hệ bộ lọc | Dùng giá trị mô tả khi mục đích là gom Products mà không tạo lựa chọn mua. |
| Facet kích thước hoặc màu sắc | Tùy chọn Products và quan hệ bộ lọc | Chuẩn hóa từ vựng tùy chọn để các lựa chọn tương đương có thể dùng chung bộ lọc. |
| Chiến dịch theo mùa | Categories, nội dung landing page, ngữ cảnh promotion hoặc liên kết trong theme | Chọn đúng đối tượng sở hữu chiến dịch thay vì mặc định biến chiến dịch thành taxonomy dài hạn. |
| Nhãn báo cáo nội bộ | Trường phục vụ back-office hoặc phân loại trong hệ thống bên ngoài | Không đưa mã nội bộ lên điều hướng storefront chỉ vì dữ liệu từng nằm trong bảng Categories. |
Bộ lọc của Jumpseller có thể sử dụng cả tùy chọn Products tạo biến thể và trường tùy chỉnh dạng lựa chọn. Vì vậy, tính nhất quán của cách đặt tên là một phần của mô hình dữ liệu. “Color”, “Colour” và “Finish” có thể cùng chỉ một khái niệm kinh doanh ở Cửa hàng nguồn nhưng trở thành ba bộ lọc khác nhau nếu được đưa sang như ba nhóm không liên quan. Ngược lại, hai giá trị có tên tương tự vẫn cần được giữ tách biệt nếu một giá trị tạo biến thể còn giá trị kia chỉ là mô tả.
Giá và tồn kho có thể thuộc Products, biến thể, ngữ cảnh Customers hoặc địa điểm
Giá và số lượng tồn kho không có ý nghĩa đầy đủ nếu chưa biết đối tượng nào sở hữu chúng. Products đơn giản có thể sở hữu một mức giá và một số lượng tồn kho. Với Products có biến thể, SKU, giá, giá vốn, trọng lượng, hình ảnh và tồn kho có thể thuộc từng tổ hợp. Giá dành riêng cho một nhóm Customers có thể tạo ra quan hệ khác giữa nhóm Customers và bảng giá. Giá theo số lượng lại bổ sung các ngưỡng mua thay vì làm thay đổi danh tính Products cơ bản.
Tồn kho cũng có thể gắn với địa điểm. Khi dữ liệu có tồn kho theo từng location, mô hình đích phải giữ đúng quan hệ giữa Products hoặc biến thể, địa điểm tồn kho, số lượng và trạng thái. Một tổng số lượng duy nhất không thể cho biết location nào có thể giao mặt hàng hoặc hệ thống tích hợp nào đang là nguồn dữ liệu có thẩm quyền.
| Giá trị thương mại | Chủ sở hữu có thể có | Vì sao quyền sở hữu quan trọng |
|---|---|---|
| Giá bán cơ bản | Products hoặc biến thể | Giá ở Products cấp cha không thể thay thế các mức giá khác nhau của từng tổ hợp thực. |
| Giá so sánh hoặc giá tham chiếu | Products hoặc biến thể | Giá tham chiếu phải gắn với cùng đơn vị bán đang sở hữu giá hiện hành. |
| Giá vốn | Products hoặc biến thể | Dữ liệu biên lợi nhuận sẽ sai nếu giá vốn của biến thể bị đưa lên Products cấp cha. |
| Mức giá theo số lượng | Products hoặc quan hệ giá | Ngưỡng số lượng và đơn giá phải đi cùng nhau. |
| Giá riêng theo Customers | Nhóm Customers và quan hệ bảng giá | Giá phụ thuộc vào phân loại người mua, không phải một trường Products áp dụng cho tất cả. |
| Tồn kho | Products hoặc biến thể tại một location | Số lượng phải gắn với đúng đơn vị bán và đúng địa điểm tồn kho. |
| Trạng thái tồn kho không giới hạn | Quy tắc khả dụng của Products hoặc biến thể | Giá trị trống hoặc bằng 0 không mặc định đồng nghĩa với tồn kho không giới hạn. |
Biến động tồn kho lịch sử cũng khác với tồn kho hiện tại. Orders có thể từng làm thay đổi tồn kho khi trạng thái đơn hàng thay đổi, nhưng một bản ghi Orders được import để lưu lịch sử chỉ là bằng chứng về giao dịch trước đây, không phải lệnh để lặp lại biến động tồn kho cũ. Cửa hàng đích cần giữ trạng thái tồn kho cuối cùng dự kiến và thông tin giao dịch trước đây trong Orders như hai nhóm dữ liệu riêng.
Customers, nhóm Customers, địa chỉ và quan hệ marketing cần giữ đúng ý nghĩa riêng
Bản ghi Customers trên Jumpseller đại diện cho danh tính tài khoản và thông tin liên hệ, nhưng hồ sơ Customers ở Cửa hàng nguồn có thể chứa nhiều yếu tố hơn tên và email. Địa chỉ, mã số thuế, thông tin doanh nghiệp, sự đồng ý nhận marketing, trạng thái tài khoản, ghi chú, phân khúc, mã CRM bên ngoài và quan hệ với nhóm Customers đều có thể thuộc các chủ sở hữu khác nhau.
| Thành phần tài khoản ở Cửa hàng nguồn | Ý nghĩa đích trên Jumpseller | Ranh giới quan hệ cần giữ |
|---|---|---|
| Tên và email | Danh tính Customers và thông tin liên hệ | Không tạo danh tính trùng lặp chỉ vì một bản ghi Customers gắn với nhiều Orders. |
| Địa chỉ thanh toán và giao hàng | Ngữ cảnh địa chỉ gắn với Customers hoặc dữ liệu đơn hàng trước đây | Địa chỉ tài khoản hiện tại và địa chỉ tại thời điểm giao dịch có thể khác nhau hợp lệ. |
| Thông tin doanh nghiệp hoặc thuế | Trường Customers, trường địa chỉ hoặc bản ghi doanh nghiệp bên ngoài | Giá trị phải thuộc đúng đối tượng sử dụng thông tin đó trong ngữ cảnh tài khoản hoặc giao dịch. |
| Nhóm Customers hoặc cấp bán buôn | Nhóm Customers cùng quan hệ giá hoặc quyền truy cập khi Jumpseller có cấu trúc phù hợp | Phân khúc thương mại không chỉ là một nhãn nếu phân khúc đó thay đổi giá hoặc điều kiện đủ. |
| Đồng ý nhận newsletter | Quan hệ marketing hoặc nền tảng marketing bên ngoài | Ý nghĩa và nguồn của sự đồng ý phải tách khỏi việc tài khoản tồn tại. |
| Số dư loyalty hoặc trạng thái thành viên | Bản ghi thuộc app hoặc hệ thống bên ngoài | Chỉ có bản ghi Customers không đủ để tái tạo quan hệ chương trình. |
| Mã định danh CRM hoặc ERP | Mã định danh bên ngoài ổn định | Mã phải tiếp tục gắn với đúng cá nhân hoặc doanh nghiệp mà hệ thống bên ngoài sử dụng. |
Dữ liệu mật khẩu cần được diễn giải riêng. Hash mật khẩu ở Cửa hàng nguồn có thể sử dụng cơ chế Jumpseller không thể tái sử dụng. Khi đó, danh tính Customers vẫn có thể được giữ đúng nhưng thông tin xác thực đăng nhập phải đi theo một quy trình truy cập tài khoản khác. Mô hình dữ liệu không được xem một địa chỉ email đã chuyển sang là bằng chứng rằng mật khẩu cũ cũng có thể chuyển nguyên trạng.
Orders lưu lại giao dịch tại thời điểm mua và tách khỏi cấu hình hiện tại của cửa hàng
Một bản ghi Orders trên Jumpseller tập hợp danh tính Customers hoặc khách mua không tạo tài khoản, các dòng hàng, biến thể đã chọn, giá trị tùy chọn do khách hàng nhập, địa chỉ, giá, giảm giá, thuế, phí vận chuyển, trạng thái thanh toán, trạng thái xử lý đơn hàng, ghi chú, mốc thời gian và tham chiếu bên ngoài. Các dữ liệu này tạo thành ảnh chụp lịch sử của giao dịch tại thời điểm mua.
Ảnh chụp đó phải được tách khỏi Products và cấu hình hiện tại. Chi tiết mặt hàng trong một bản ghi Orders cũ có thể tiếp tục giữ tên Products, SKU, lựa chọn đã mua và mức giá tại thời điểm giao dịch. Những thông tin này vẫn phải giữ đúng ngay cả khi Products đang hoạt động sau đó được đổi tên, đổi giá, vô hiệu hóa hoặc xóa. Phí vận chuyển lịch sử có thể cho biết khách hàng đã trả bao nhiêu nhưng không định nghĩa phương thức vận chuyển đang dùng. Tham chiếu thanh toán có thể phục vụ đối soát nhưng không cấu hình cổng thanh toán hiện tại.
| Thành phần Orders | Ý nghĩa lịch sử | Quan hệ cần giữ ở phía đích |
|---|---|---|
| Danh tính Products trong chi tiết mặt hàng của Orders | Mặt hàng được mua tại thời điểm đó | Giữ liên kết tới Products hoặc biến thể khi có thể, đồng thời giữ nguyên văn bản của giao dịch lịch sử. |
| Tùy chọn đã chọn và thông tin nhập tùy chỉnh | Lựa chọn của người mua cho dòng hàng đó | Giữ cùng chi tiết mặt hàng trong Orders ngay cả khi định nghĩa Products hiện tại thay đổi. |
| Giá, giảm giá và thuế | Ảnh chụp thương mại của giao dịch | Không tính lại lịch sử từ Products hoặc thiết lập thuế hiện tại. |
| Địa chỉ thanh toán và giao hàng | Địa chỉ tại thời điểm giao dịch | Tách khỏi các chỉnh sửa sau này trên hồ sơ Customers. |
| Trạng thái và tham chiếu thanh toán | Bối cảnh thanh toán lịch sử | Bản ghi Orders không sở hữu cấu hình cổng thanh toán hiện tại. |
| Trạng thái xử lý đơn hàng và tracking | Bối cảnh giao hàng lịch sử | Bản ghi Orders không định nghĩa quy tắc carrier hoặc kho hiện tại. |
| Kênh nguồn hoặc ID bên ngoài | Khóa phục vụ đối soát và tích hợp | Giữ mã khi một hệ thống khác dùng mã này để nhận diện Orders. |
Orders của khách mua không tạo tài khoản, Orders bị hủy, Orders mới xử lý một phần, Orders đã hoàn tiền và Orders có thông tin tùy chỉnh đều chứa những quan hệ mà một đơn hàng đã thanh toán đơn giản không thể hiện. Mô hình đích cần hỗ trợ các trạng thái đó mà không biến dữ liệu lịch sử thành cấu hình quy trình đang hoạt động.
CMS Pages, Blog Posts, URL và nội dung theme có các chủ sở hữu khác nhau
Nội dung storefront trên Jumpseller có thể bao gồm CMS Pages (Trang Hệ thống quản lý nội dung), Blog Posts, mô tả Products và Categories, mục điều hướng, banner, section của theme, hình ảnh, nội dung chính sách và thông tin SEO. Nền tảng nguồn có thể lưu tất cả trong cùng một page builder hoặc bảng nội dung, nhưng Jumpseller phân chúng cho những đối tượng khác nhau.
| Nội dung ở Cửa hàng nguồn | Cách diễn giải trên Jumpseller | Ranh giới quyền sở hữu |
|---|---|---|
| Nội dung giới thiệu, liên hệ, chính sách hoặc hướng dẫn | CMS Page | Nội dung trang ổn định và route của trang tách khỏi vị trí menu và bố cục theme. |
| Bài biên tập hoặc thông báo | Blog Post | Ngày xuất bản, bối cảnh tác giả, Categories hoặc tag, media và permalink có thể khác CMS Page. |
| Nội dung mô tả Products hoặc Categories | Mô tả thuộc đối tượng catalog | Nội dung thuộc Products hoặc Categories tương ứng, không phải một trang chung tách biệt. |
| Header, footer, banner hoặc section trang chủ | Nội dung thuộc theme hoặc điều hướng | Vị trí trình bày không đồng nghĩa với quyền sở hữu bản ghi kinh doanh bên dưới. |
| Meta title, meta description hoặc permalink | Quan hệ SEO và route của đối tượng sở hữu | Metadata phải tiếp tục gắn với Products, Categories, CMS Pages hoặc Blog Posts mà metadata mô tả. |
| Redirect hoặc đường dẫn cũ | Quan hệ định tuyến | URL cũ vẫn có giá trị ngay cả khi đối tượng đích nhận permalink mới. |
Code của theme có thể đọc dữ liệu Products, trường tùy chỉnh, Categories, menu và đầu ra của app, nhưng theme không sở hữu các bản ghi đó. Sao chép markup cũ không thay thế được việc chuyển đúng dữ liệu nền. Tương tự, chỉ sao chép phần thân nội dung mà bỏ qua liên kết, media, route và đối tượng sở hữu có thể tạo ra một trang tồn tại về mặt kỹ thuật nhưng không còn hoạt động đúng trong storefront.
App, API, webhook và mã định danh bên ngoài tạo thành lớp dữ liệu xung quanh storefront
Jumpseller có thể trao đổi dữ liệu với hệ thống bên ngoài qua app, API và webhook. Cửa hàng nguồn có thể dùng ERP làm chủ tồn kho, CRM để phân loại Customers, dịch vụ xử lý đơn hàng để quản lý trạng thái giao hàng, marketplace để quản lý listing hoặc app để quản lý subscription, booking, Reviews, loyalty, bundle hay cách cấu hình Products.
Những bản ghi này cần được phân loại theo quyền sở hữu, không phải theo việc chúng có hiển thị trên storefront hay không. Một giá trị xuất hiện trên trang Products có thể thực chất được quản lý trong PIM bên ngoài. Số lượng tồn kho nhìn thấy trên Jumpseller có thể được đồng bộ từ ERP. Nhãn Customers có thể được tạo từ CRM. ID listing trên marketplace có thể nhận diện một offer theo kênh chứ không phải Products cốt lõi.
| Bản ghi tích hợp | Chủ sở hữu có khả năng | Yêu cầu khi chuyển đổi |
|---|---|---|
| ID Products hoặc biến thể trong ERP | Quan hệ ERP và catalog | Giữ mã trên Products hoặc biến thể tương ứng mà quá trình đồng bộ sử dụng. |
| ID kho hoặc location | Hệ thống tồn kho hoặc xử lý đơn hàng | Giữ danh tính location tách khỏi một con số tồn kho đơn thuần. |
| ID Customers trong CRM | Quan hệ CRM-Customers | Không tạo một mã mới không liên quan cho cùng cá nhân hoặc doanh nghiệp. |
| ID listing trên marketplace | Listing của kênh bán hàng | Không nhầm listing với Products hoặc biến thể chính trong catalog. |
| Bản ghi subscription, booking hoặc loyalty do app tạo | Miền dữ liệu của app | Giữ rõ tham chiếu tới Products, Customers và Orders cấp cha. |
| Trạng thái đồng bộ webhook | Quy trình tích hợp | Xem timestamp, event ID và cursor là dữ liệu vận hành của tích hợp, không phải nội dung storefront. |
Một Cửa hàng đích có cấu trúc nhất quán không cần sao chép mọi bảng nguồn. Tuy nhiên, mọi mã định danh và quan hệ hỗ trợ quản lý catalog, duy trì Customers, đối soát lịch sử hoặc đồng bộ với hệ thống bên ngoài phải có chủ sở hữu rõ ràng.
Bản đồ chuyển đổi dữ liệu phải xác định ý nghĩa trước khi chọn nơi lưu
Có thể tóm tắt mô hình dữ liệu Jumpseller bằng một chuỗi quyết định về quyền sở hữu. Products cấp cha giữ thông tin merchandising dùng chung. Biến thể giữ các tổ hợp có thể bán. Thông tin do khách hàng nhập thuộc tương tác với Products và sau đó gắn với chi tiết mặt hàng trong Orders. Trường tùy chỉnh mô tả Products. Categories tổ chức quan hệ catalog. Điều hướng sở hữu vị trí menu. Customers giữ danh tính và bối cảnh tài khoản. Orders giữ ảnh chụp giao dịch lịch sử. App và hệ thống bên ngoài sở hữu các bản ghi cùng mã định danh chuyên biệt của chúng.
| Câu hỏi cần trả lời từ dữ liệu nguồn | Quyết định phía Jumpseller |
|---|---|
| Giá trị có tạo ra một mặt hàng được định giá hoặc quản lý tồn kho độc lập không? | Đưa vào cấp biến thể thay vì dùng như một trường mô tả tùy chỉnh. |
| Giá trị do người mua nhập cho một lần mua hàng phải không? | Giữ như thông tin khách hàng nhập và đi cùng chi tiết mặt hàng trong Orders. |
| Giá trị mô tả nhiều Products nhưng không tạo biến thể phải không? | Dùng trường tùy chỉnh hoặc quan hệ phân loại phù hợp. |
| Nhóm dữ liệu dùng để tổ chức Products hay điều khiển điều hướng? | Tách quan hệ Products-Categories khỏi vị trí menu. |
| Giá trị là cấu hình hiện tại hay thông tin lịch sử? | Tách catalog/cấu hình đang hoạt động khỏi ảnh chụp lịch sử trong Orders. |
| Hệ thống khác có dùng mã này làm khóa không? | Giữ mã trên đối tượng đích đại diện cho cùng đối tượng kinh doanh. |
| Bản ghi thuộc một app thay vì dữ liệu lõi Jumpseller phải không? | Duy trì quan hệ với app thay vì ép dữ liệu vào một trường tiêu chuẩn không liên quan. |
Giải quyết rõ các câu hỏi này giúp cửa hàng quản lý dữ liệu sau chuyển đổi một cách nhất quán. Cửa hàng đích phản ánh được mỗi bản ghi mang ý nghĩa gì, đối tượng nào sở hữu và bản ghi đó liên kết với phần còn lại của môi trường Jumpseller như thế nào.
Kết luận
Jumpseller thay đổi cách diễn giải dữ liệu bằng việc tách Products cấp cha, biến thể, thông tin khách hàng nhập, trường tùy chỉnh, Categories, bộ lọc, điều hướng, tồn kho, Customers, Orders, nội dung và các tích hợp thành những quan hệ riêng. Vì vậy, một bảng thuộc tính, bảng Customers hoặc bản ghi từ page builder ở Cửa hàng nguồn có thể cần nhiều đối tượng đích chứ không chỉ một phép ghép trường trực tiếp.
Một dự án chuyển đổi có cấu trúc tốt sẽ giữ đúng quyền sở hữu của từng giá trị. Products tiếp tục liên kết với các biến thể có thể bán thực sự; trường mô tả tách khỏi lựa chọn của người mua; Categories tách khỏi điều hướng; danh tính Customers tách khỏi dữ liệu chương trình thuộc app; Orders vẫn là ảnh chụp lịch sử; và mã định danh bên ngoài tiếp tục gắn với hệ thống cùng đối tượng đang phụ thuộc vào chúng.
Câu hỏi thường gặp
Tùy chọn Products và trường tùy chỉnh trên Jumpseller có giống nhau không?
Hai cấu trúc này phục vụ mục đích khác nhau. Tùy loại, tùy chọn Products có thể tạo biến thể hoặc thu thập dữ liệu do người mua nhập. Trường tùy chỉnh mô tả Products và có thể hỗ trợ bộ lọc khi được biểu diễn phù hợp. Một giá trị nên được phân loại dựa trên việc giá trị đó tạo đơn vị bán, thu thập lựa chọn cho một lần mua hay chỉ mô tả Products.
Khi nào một thuộc tính ở Cửa hàng nguồn nên trở thành biến thể trên Jumpseller?
Thuộc tính nên trở thành một phần của biến thể khi lựa chọn đó nhận diện một đơn vị bán thực có ý nghĩa thương mại hoặc tồn kho riêng, chẳng hạn SKU, giá, số lượng, trọng lượng, giá vốn hoặc quan hệ hình ảnh riêng. Giá trị mô tả và thông tin cá nhân hóa tự do nên nằm ngoài lưới biến thể.
Categories đã chuyển có tự động tái tạo menu cũ không?
Categories không tự động tái tạo menu cũ. Categories sở hữu quan hệ phân nhóm Products và cấu trúc phân cấp, trong khi điều hướng quyết định vị trí menu và cách trình bày route. Một nhóm Categories có thể tồn tại mà không xuất hiện trong menu chính, còn menu có thể chứa liên kết đến CMS Pages, Blog Posts, trang chiến dịch hoặc điểm đến khác.
Lịch sử đơn hàng nên liên kết với Products hiện tại như thế nào?
Lịch sử đơn hàng cần giữ thông tin chi tiết từng mặt hàng đã mua, tùy chọn đã chọn, giá, địa chỉ, trạng thái và tham chiếu bên ngoài. Khi có quan hệ đáng tin cậy với Products hoặc biến thể hiện tại, liên kết đó có thể được giữ lại; tuy nhiên, thay đổi catalog sau này không được viết lại những gì Orders đã ghi nhận tại thời điểm mua.
Dữ liệu của app nguồn sẽ được xử lý thế nào nếu Jumpseller không có trường tương ứng?
Bản ghi cần tiếp tục được phân loại theo app hoặc hệ thống bên ngoài thực sự sở hữu bản ghi. Các tham chiếu cấp cha và mã định danh ổn định có thể được giữ trong cấu trúc đích phù hợp, trong khi hành vi chuyên biệt vẫn tách khỏi trường Products, Customers hoặc Orders thông thường.
Một trường nguồn có thể được đưa đến các cấu trúc Jumpseller khác nhau tùy Products không?
Có thể. Một trường nguồn tên “Size”, “Type” hoặc “Status” có thể mang ý nghĩa kinh doanh khác nhau giữa các nhóm Products. Điểm đến phụ thuộc vào việc giá trị đó tạo biến thể, mô tả Products, kiểm soát khả dụng, thu thập thông tin khách hàng nhập, hỗ trợ bộ lọc hay thuộc một quy trình bên ngoài.