Khi lập kế hoạch mô hình dữ liệu cho BigCommerce, cần bắt đầu từ ý nghĩa của dữ liệu chứ không phải số lượng bản ghi. Products, Categories, Customers, Orders, CMS Pages, Blog Posts, redirects và các trường liên quan có thể mang tên quen thuộc, nhưng BigCommerce tổ chức commerce qua các cấu trúc riêng cho catalog, pricing, channels, Customers, content và các tích hợp. Những cấu trúc đó không nhất thiết hoạt động giống Nền tảng nguồn.
Cửa hàng có thể trông đầy đủ sau di chuyển dữ liệu nhưng vẫn sai về mặt thương mại. Lựa chọn Products có thể được đưa vào sai cấu trúc. đường dẫn Categories có thể tồn tại nhưng không duy trì cách khách hàng tìm Products. Customers có thể được chuyển nhưng mất bối cảnh pricing từng khiến bản ghi đó có giá trị. Redirects có thể hoạt động về kỹ thuật nhưng dẫn người mua đến trang không phù hợp. các trường tùy chỉnh và metafields có thể còn nguyên giá trị nhưng bị tách khỏi app, ERP, search, merchandising hoặc cách storefront hoạt động mà chúng từng hỗ trợ.
Cách an toàn hơn là xác định mỗi cấu trúc ở nguồn sẽ mang ý nghĩa gì trên BigCommerce trước khi chốt phạm vi di chuyển dữ liệu.
Vì sao ý nghĩa dữ liệu trên BigCommerce cần được rà soát riêng?
BigCommerce là một Nền tảng đích SaaS Hosted với các cấu trúc commerce đã được định nghĩa rõ. Cấu trúc này có thể giúp quản lý hệ thống nhất quán hơn sau di chuyển dữ liệu, nhưng đồng thời buộc dự án phải đưa ra nhiều quyết định cụ thể hơn về cách thể hiện dữ liệu. Nền tảng nguồn có thể cho phép options của Products, các trường cá nhân hóa, nhóm Customers, pricing rules, landing pages và chức năng do app quản lý chồng lấn với nhau. Trên BigCommerce, những vai trò đó thường cần được tách rõ hơn.
Câu hỏi không chỉ là một bản ghi ở nguồn có nơi để đưa vào BigCommerce hay không. Cần xác định cấu trúc đích có tiếp tục hỗ trợ đúng công dụng kinh doanh của bản ghi đó hay không.
| Phạm vi BigCommerce | Ý nghĩa cần xác nhận khi chuyển đổi |
|---|---|
| Lựa chọn Products | Lựa chọn ở nguồn nên trở thành variant, variant option, modifier, trường tùy chỉnh, metafield, cấu hình app hay một cấu trúc đích khác. |
| Cấu trúc Categories | Categories ở nguồn có tiếp tục hỗ trợ đúng cách tổ chức catalog, navigation, merchandising và discovery quan trọng với SEO hay không. |
| Bối cảnh pricing | Giá cơ bản, bulk rules, bảng giá, quy tắc theo nhóm Customers và tham chiếu hệ thống định giá bên ngoài có còn đúng ý nghĩa hay không. |
| Phạm vi channel | Products, Categories, pricing, content và URLs có thuộc đúng storefront hoặc channel hay không. |
| Customers và Orders | Danh tính Customers, bối cảnh tài khoản, quan hệ thuộc nhóm Customers, lịch sử đơn hàng và giá trị phục vụ vận hành có còn hữu ích hay không. |
| Content và routes | CMS Pages, Blog Posts, redirects và trang đích có duy trì đúng mục đích của khách hàng hay không. |
| Dữ liệu tùy chỉnh và do app quản lý | các trường tùy chỉnh, metafields, bản ghi do app sở hữu và định danh hệ thống bên ngoài cần mapping trực tiếp giữa các trường/filtering, tái cấu trúc dữ liệu hay thiết lập Cửa hàng đích. |
Cách rà soát này giúp tránh phê duyệt di chuyển dữ liệu chỉ vì bản ghi đã xuất hiện. Cần trả lời thêm: BigCommerce có đang lưu bản ghi đó trong cấu trúc tiếp tục hỗ trợ bán hàng, dịch vụ khách hàng, pricing, discovery và các tích hợp hay không?
Cấu trúc Products: Products, variants, options và modifiers
Cấu trúc Products trên BigCommerce cần được phân tích kỹ vì các Nền tảng nguồn sử dụng lựa chọn Products theo những cách khác nhau. Có cửa hàng dùng variants cho mọi lựa chọn. Có cửa hàng dùng custom các trường option, plugins, apps, công cụ cấu hình Products, bundle systems hoặc quy tắc trong theme. BigCommerce tách một số loại lựa chọn Products thành các vai trò khác nhau, và sự khác biệt này ảnh hưởng inventory, pricing, xử lý đơn hàng, hiển thị trên storefront và reporting.
Variant thường đại diện cho một phiên bản Products có thể bán riêng. Size, color, material, package, model, finish hoặc unit có thể thuộc cấu trúc variant khi lựa chọn đó làm thay đổi SKU, inventory, image, weight, price, khả năng bán hoặc xử lý đơn hàng. Variant options mô tả các chiều lựa chọn dùng để tạo ra các tổ hợp variants đó.
Modifiers có vai trò khác. Modifier có thể ghi nhận lựa chọn của khách hàng làm thay đổi trải nghiệm mua hàng mà không nhất thiết tạo ra một mặt hàng riêng có inventory độc lập. Ví dụ có thể gồm personalization text, engraving, gift messages, extras tùy chọn, file các trường tải tệp lên, warranty selections hoặc các hình thức tùy chỉnh không theo dõi tồn kho. Nếu lựa chọn ở nguồn được đưa vào sai cấu trúc, trang Products có thể trông đầy đủ nhưng vận hành lại sai.
| Lựa chọn Products ở nguồn | Cần hiểu thế nào trên BigCommerce? | Ý nghĩa có thể mất nếu phân loại sai |
|---|---|---|
| Size hoặc color có SKU và stock riêng | Có nên trở thành variant và variant option không? | Inventory và ý nghĩa của chi tiết mặt hàng trong Orders có thể bị sai. |
| Engraving hoặc gift message | Phù hợp hơn với modifier hay trường tùy chỉnh? | Nội dung khách hàng nhập có thể bị biến thành một option có inventory giả tạo. |
| Bundle hoặc kit | Đây là cấu trúc được hỗ trợ, do app quản lý hay cần quy tắc riêng? | Định giá, xử lý đơn hàng và tồn kho có thể không còn đúng. |
| Warranty hoặc trường tương thích | Đây là thông tin hiển thị, metadata Products hay chức năng do app quản lý? | Dữ liệu có thể còn dưới dạng text nhưng mất chức năng thương mại. |
| Trường upload hoặc quy trình cá nhân hóa | Có cần app phía đích hoặc tái cấu trúc dữ liệu không? | Products được chuyển nhưng hành trình mua hàng cũ không còn hoạt động. |
Bộ các bản ghi Products đại diện cần phản ánh các mô hình catalog thực tế. Một bản ghi Products đơn giản, một bản ghi Products có nhiều variants, một bản ghi Products phụ thuộc modifiers, một bundle và một bản ghi Products có dữ liệu tùy chỉnh cho biết nhiều hơn rất nhiều so với tổng số Products.
các trường tùy chỉnh, metafields và metadata của các trường tùy chỉnh của Products và metafields trên BigCommerce phục vụ các mục đích khác nhau và không nên được xem như hai nơi chứa dữ liệu có thể thay thế lẫn nhau. các trường tùy chỉnh của Products có thể lưu thông tin bổ sung của Products dùng cho storefront. Metafields là dữ liệu key-value phục vụ xử lý bằng chương trình, có thể gắn với các resources như Products, variants, Categories và brands; chúng hữu ích cho apps và các tích hợp nhưng không tự trở thành nội dung thông thường trên storefront hoặc giao diện quản trị.
Vì vậy, một attribute ở nguồn dù đều được gọi chung là “dữ liệu tùy chỉnh” vẫn có thể phục vụ các vai trò rất khác nhau:
| Mục đích dữ liệu ở nguồn | Câu hỏi về cấu trúc đích trên BigCommerce |
|---|---|
| Thông số cần hiển thị cho khách hàng | Nên trở thành trường của Products, trường tùy chỉnh, content có cấu trúc hay giá trị khác mà storefront có thể sử dụng? |
| Lựa chọn có thể mua | Có phải variant, variant option hoặc modifier thay vì metadata mô tả không? |
| Dữ liệu cho search hoặc filtering | Cấu trúc nào trên BigCommerce hoặc app nào thực sự sử dụng giá trị này để hỗ trợ discovery? |
| Tham chiếu vận hành nội bộ | Nên giữ ẩn trong metafield hay tiếp tục nằm ở hệ thống bên ngoài đang sở hữu dữ liệu? |
| Khóa ERP, PIM hoặc accounting | Resource nào sở hữu identifier và hệ thống kết nối sẽ tìm lại identifier đó bằng cách nào? |
| Hành vi do app quản lý | App đích có hỗ trợ import hay quy trình cần được thiết kế lại? |
Cấu trúc đích cần được chọn dựa trên công dụng, mức độ hiển thị và chủ thể quản lý. Đưa mọi source attribute vào các trường tùy chỉnh của Products có thể làm lộ dữ liệu nội bộ hoặc khiến storefront khó quản lý. Đưa mọi thứ vào metafields có thể giữ được giá trị nhưng không còn giao diện quản trị, theme hoặc app nào sử dụng chúng. Cách liên kết dữ liệu phù hợp phải ghi rõ thành phần sử dụng, quan hệ với resource và giá trị đó tiếp tục phục vụ khách hàng, vận hành, các tích hợp hay được loại khỏi phạm vi.
Categories, cây Categories, navigation và discovery
Chuyển Categories sang BigCommerce không nên được xem như sao chép cấu trúc thư mục. Categories, cây Categories, quan hệ Products-Categories, cấu trúc menu, cách khách hàng tìm Products trên storefront và các routes quan trọng với SEO đều có thể ảnh hưởng navigation. Một nhóm Categories ở nguồn có thể đồng thời là cách tổ chức trong giao diện quản trị, public landing page, nhóm merchandising, campaign grouping, menu entry, search filter hoặc SEO page.
Khi lập kế hoạch, cần tách các vai trò đó. Một nhóm Categories có thể cần trở thành một bản ghi Categories trên BigCommerce. Quan hệ menu có thể thuộc thiết lập storefront. Landing page có giá trị cao có thể cần giữ content hoặc có redirect plan. Cấu trúc giống collection ở nguồn có thể cần mapping, xây dựng lại thủ công, app hỗ trợ hoặc loại khỏi phạm vi.
| Cấu trúc ở nguồn | Câu hỏi khi chuyển sang BigCommerce |
|---|---|
| nhóm phân loại Products | Có nên trở thành Categories trên BigCommerce hoặc một vị trí trong cây Categories không? |
| Collection hoặc smart group | Đây là Categories, merchandising rule, nhu cầu thiết lập storefront hay yêu cầu tương đương app? |
| Navigation menu | Thuộc dữ liệu catalog hay phần thiết lập theme/storefront? |
| SEO landing page | Nên chuyển như content, bối cảnh Categories, redirect target hay xây dựng lại? |
| Campaign hoặc Categories tạm thời | Nên chuyển, loại bỏ, redirect hay để ngoài phạm vi? |
Với doanh nghiệp dùng nhiều storefronts hoặc phụ thuộc channels, ý nghĩa Categories còn phụ thuộc vào nơi Products được bán. Một nhóm Categories hữu ích ở storefront này có thể gây nhầm lẫn ở storefront khác. Vì vậy, quan hệ Products-Categories, naming, routes và redirect destinations cần được rà soát trong đúng ngữ cảnh bán hàng.
Pricing, nhóm Customers và bảng giá
Pricing là một trong những khác biệt quan trọng nhất của mô hình dữ liệu BigCommerce vì giá có thể tồn tại ở nhiều cấp. Cửa hàng nguồn có thể có giá cơ bản, sale prices, bulk pricing, giá theo nhóm Customers, wholesale tiers, giá theo khu vực, negotiated prices, bảng giá, rules do app quản lý hoặc hệ thống định giá bên ngoài.
Không nên làm phẳng tất cả thành một giá Products trừ khi doanh nghiệp thực sự muốn đơn giản hóa mô hình giá sau di chuyển dữ liệu. Bối cảnh pricing cần được xem như quan hệ giữa Products, Customers, groups, bảng giá, điều kiện quantity, storefronts, channels, apps và hệ thống bên ngoài.
| Nguồn tạo giá | Ý nghĩa cần duy trì |
|---|---|
| Giá cơ bản của Products | Giá bán mặc định. |
| Bulk pricing | Kỳ vọng giá theo số lượng. |
| Giá theo nhóm Customers | Quy tắc pricing theo phân khúc người mua hoặc wholesale. |
| Bảng giá | Ngữ cảnh giá có cấu trúc theo audience, channel hoặc business. |
| Định giá do app quản lý | Các quy tắc thương mại có thể tiếp tục thuộc app hoặc cần một hệ thống bên ngoài chịu trách nhiệm về định giá. |
| Hệ thống định giá bên ngoài | Duy trì identifiers và synchronization, không chỉ giá cuối cùng hiển thị. |
Products được chuyển có thể hiển thị đúng giá cơ bản nhưng vẫn sai với người mua wholesale, nhóm Customers, channel hoặc storefront theo khu vực. Những trường hợp nhạy cảm về giá cần được ghi rõ như tổ hợp Products hoặc variant, nhóm Customers, bảng giá và channel, thay vì suy ra từ giá cơ bản của Products.
Channels, storefronts và ngữ cảnh bán hàng
Cấu trúc channels và storefronts của BigCommerce có thể ảnh hưởng availability của Products, cách Categories được trình bày, currencies, site relationships, menus, pricing, redirects và trải nghiệm khách hàng. Vì vậy, channel context là một phần của mô hình dữ liệu, không chỉ là cài đặt triển khai.
Nền tảng nguồn có thể thể hiện quy tắc theo channel qua nhiều stores, websites, marketplaces, regions, language versions, domains, các tích hợp hoặc custom code. BigCommerce cần một cách hiểu rõ cho từng quan hệ: Products nào được gán cho channel nào, cây Categories nào hỗ trợ từng site, content và routes nào thuộc từng storefront, và mức giá hoặc quy tắc Customers nào áp dụng trong ngữ cảnh đó.
| Ý nghĩa ở nguồn | Quan hệ cần xác định trên BigCommerce |
|---|---|
| Storefront theo khu vực hoặc brand | Channel, site, domain, cây Categories, chủ thể quản lý nội dung và redirect destination. |
| Marketplace hoặc social channel | Products assignments, quyền sở hữu external listings, identifiers và trách nhiệm synchronization. |
| Catalog subset riêng theo store | Quan hệ Products-channel và cấu trúc Categories hiển thị ở storefront đó. |
| Giá riêng theo store | Bảng giá, nhóm Customers, channel context, hệ thống định giá bên ngoài hoặc một chủ thể quản lý khác đã được xác định. |
| Content hoặc navigation theo locale | Content thuộc storefront, theme configuration, translated content hoặc một lớp triển khai riêng. |
Products dùng chung có thể tiếp tục là một bản ghi chung trong khi assignments và cách trình bày khác nhau theo channel. Làm phẳng các quan hệ này có thể khiến giao diện quản trị trông đầy đủ nhưng storefront nhận sai assortment, đường dẫn Categories, bối cảnh giá hoặc redirect destination. Vì vậy, mapping cần lưu cả bản ghi dùng chung và từng quan hệ theo channel phải tiếp tục tồn tại.
Customers, tài khoản và lịch sử đơn hàng
Dữ liệu Customers và Orders cần được hiểu như bối cảnh thương mại và dịch vụ khách hàng. Một bản ghi Customers có thể chứa danh tính, addresses, trạng thái tài khoản, group assignment, custom attributes, consent, quan hệ Orders và kỳ vọng pricing. Một bản ghi Orders có thể lưu tên Products, SKUs, số lượng, giảm giá, thuế, vận chuyển, thông tin thanh toán, xử lý đơn hàng, nhãn thanh toán, ghi chú, hoàn tiền và external references.
Kế hoạch di chuyển dữ liệu cần xác định doanh nghiệp muốn lịch sử Customers và Orders tiếp tục hỗ trợ công việc nào. dịch vụ khách hàng, mua lại, wholesale access, tra cứu hỗ trợ, reporting, rà soát refunds và đối chiếu các tích hợp có thể cần mức độ chi tiết khác nhau.
Hệ thống tài khoản ở nguồn không nhất thiết tương đương trực tiếp với cách tài khoản hoạt động trên BigCommerce. Passwords, quan hệ thuộc nhóm Customers, dữ liệu loyalty, đăng ký định kỳ, quy trình báo giá, company accounts, các trạng thái phê duyệt tài khoản Customers hoặc external CRM references có thể cần rà soát riêng. Một số values có thể mapping trực tiếp. Một số phù hợp với mapping trực tiếp giữa các trường hoặc filtering. Một số cần tái cấu trúc dữ liệu hoặc Lộ trình chuyển đổi dành cho app. Một số khác cần thiết lập app trên Nền tảng đích hoặc nằm ngoài phạm vi di chuyển dữ liệu.
Orders cũng cần ranh giới tương tự. Dữ liệu đơn hàng trước đây phải tiếp tục đọc và sử dụng được cho đúng mục đích, nhưng cấu hình thanh toán đang hoạt động, cách checkout vận hành, cấu hình vận chuyển, thiết lập thuế, thông báo và quy trình xử lý đơn hàng thuộc phần thiết lập Cửa hàng đích.
Content, pages, Blog Posts, redirects và ý nghĩa của routes
Content và URL trên BigCommerce cần được xem như một phần của cách dữ liệu được thể hiện sau chuyển đổi vì pages, Blog Posts, redirects, Products paths, đường dẫn Categories và storefront destinations đều tác động đến niềm tin của khách hàng và continuity từ search. Redirect có thể hoạt động về kỹ thuật nhưng vẫn làm yếu hành trình khách hàng nếu URL Products, Categories hoặc content cũ bị đưa đến một trang quá chung hoặc không liên quan.
CMS Pages và Blog Posts cần được rà soát theo công dụng. Có pages phục vụ trust, policies, giới thiệu brand, hướng dẫn mua hàng, campaign traffic hoặc SEO discovery. Một số Blog Posts có thể mang long-tail search value hoặc hỗ trợ khách hàng hiểu Products. Một số pages ở nguồn không còn cần chuyển nhưng vẫn phải redirect đến điểm đến hữu ích.
| Loại content hoặc route | Quyết định khi chuyển đổi |
|---|---|
| URL Products | Duy trì hoặc redirect đến Products tương ứng gần nhất. |
| URL Categories | Duy trì ý định discovery khi có thể. |
| CMS Page | Di chuyển, xây dựng lại, gộp, redirect hoặc loại bỏ. |
| Blog Post | Duy trì nếu còn giá trị về traffic, giáo dục người mua, trust hoặc internal links. |
| Campaign page | Xác định campaign còn hoạt động, cần redirect hay nên loại bỏ. |
| Route riêng theo storefront | Xác nhận đúng storefront hoặc channel destination. |
Route identity thuộc mô hình dữ liệu BigCommerce vì redirects nối ý định ở nguồn với một trang đích có ích. Quan hệ redirect tốt duy trì hành trình khách hàng, không chỉ tạo ra một mapping kỹ thuật giữa hai URLs.
Apps, các tích hợp và dữ liệu hệ thống bên ngoài
Di chuyển sang BigCommerce thường giao nhau với nhiều hệ thống bên ngoài. ERP, PIM, CRM, accounting, tax, shipping, đăng ký định kỳ, personalization, search, Reviews, loyalty, warehouse, marketplace hoặc marketing systems có thể phụ thuộc vào identifiers và các trường tùy chỉnh mà một lần rà soát storefront thông thường không thấy được.
Câu hỏi về mô hình dữ liệu là BigCommerce có cần sở hữu dữ liệu, hiển thị dữ liệu, chuyển dữ liệu cho app, giữ lại để đối chiếu hay có thể bỏ qua vì quy trình sẽ được xây dựng lại. Đây là những kết quả khác nhau và cần xác định chủ thể chịu trách nhiệm riêng.
| Mối phụ thuộc bên ngoài | Nội dung cần xem xét khi chuyển sang BigCommerce |
|---|---|
| ERP hoặc accounting | IDs của Products, SKUs, tham chiếu Orders, IDs của Customers và tax/discount context. |
| PIM | Quyền sở hữu attributes, Products copy, images, variants và các trường tùy chỉnh. |
| CRM hoặc marketing | Danh tính Customers, consent, segmentation, lịch sử đơn hàng và custom attributes. |
| App đăng ký định kỳ hoặc loyalty | Bản ghi do app quản lý, hành vi và yêu cầu continuity. |
| Search hoặc merchandising app | Filter attributes, các trường tùy chỉnh, tags của Products, rules và ranking behavior. |
| Shipping hoặc tax system | External identifiers và hành vi liên quan đến checkout. |
Nếu dữ liệu đã có cấu trúc BigCommerce phù hợp, direct mapping hoặc filtering có thể đủ. Nếu dữ liệu do app sở hữu, do hệ thống bên ngoài kiểm soát hoặc phụ thuộc vào quan hệ không native, cần xác định app đích, hệ thống bên ngoài hoặc cách tái cấu trúc dữ liệu trước khi chốt source-to-target map.
Phạm vi dữ liệu BigCommerce cần được đánh giá theo công dụng kinh doanh
Phạm vi Di chuyển sang BigCommerce cần được đánh giá dựa trên cách dữ liệu sẽ được dùng sau chuyển đổi. Products, Customers, Orders, Categories, CMS Pages, Blog Posts và redirects có thể có đích đến thông thường, nhưng ý nghĩa của chúng vẫn có thể phụ thuộc vào cấu trúc lựa chọn Products, cây Categories, channel assignments, nhóm Customers, bảng giá, các trường tùy chỉnh, metafields, apps và external identifiers.
Một bản đồ chuyển đổi hữu ích cần phân biệt những kết quả sau:
| Kết quả mapping | Ý nghĩa trên BigCommerce |
|---|---|
| Bản ghi và quan hệ native | Ý nghĩa ở nguồn phù hợp với Products, variant, modifier, Categories, Customers, Orders, bản ghi nội dung, redirect hoặc quan hệ được hỗ trợ khác trên BigCommerce. |
| Cấu hình storefront hoặc channel | Bản ghi đã tồn tại, nhưng cách sử dụng phụ thuộc vào channel assignments, cây Categories, sites, themes, menus, pricing context hoặc cấu hình Cửa hàng đích khác. |
| Quyền sở hữu của app hoặc các tích hợp | Dữ liệu tiếp tục do ERP, PIM, CRM, đăng ký định kỳ, loyalty, search hoặc hệ thống kết nối khác sở hữu và cần stable cross-system identifier. |
| Transformation dữ liệu theo mục đích cụ thể | Cấu trúc ở nguồn phải được tổ chức lại vì ý nghĩa không khớp với bản ghi hoặc quan hệ có sẵn ở đích. |
| Loại bỏ, lưu trữ hoặc thiết kế lại | Giá trị đã lỗi thời, trùng lặp, gắn với quy tắc đã ngừng sử dụng hoặc không còn chủ thể kinh doanh chịu trách nhiệm sau chuyển đổi. |
Mô hình này giữ trọng tâm ở việc chuyển đúng ý nghĩa thay vì nhầm số lượng bản ghi lớn với mô hình dữ liệu BigCommerce có thể sử dụng. Phạm vi tốt phải giải thích mỗi ý nghĩa quan trọng ở nguồn sẽ trở thành gì, quan hệ nào duy trì ý nghĩa đó, ai chịu trách nhiệm sau khi cửa hàng đi vào hoạt động và phần nào được chủ động giữ bên ngoài Cửa hàng đích.
Kết luận
Khác biệt mô hình dữ liệu của BigCommerce quan trọng vì các bản ghi sau di chuyển dữ liệu chỉ có giá trị khi được đặt trong đúng cấu trúc thương mại. Products, variants, modifiers, Categories, nhóm Customers, bảng giá, channels, Customers, Orders, CMS Pages, Blog Posts, redirects, các trường tùy chỉnh, metafields, apps và external identifiers cần được đánh giá theo cách doanh nghiệp sẽ sử dụng chúng sau khi cửa hàng đi vào hoạt động.
Một kế hoạch BigCommerce tốt không chỉ duy trì sự tồn tại của dữ liệu mà còn phải duy trì đúng cách dữ liệu được sử dụng. Trước khi chốt mô hình đích, cần tách bản ghi native khỏi cấu hình theo channel/storefront, values do các tích hợp quản lý, yêu cầu tái cấu trúc dữ liệu và những kỳ vọng được chủ động loại khỏi phạm vi.
Câu hỏi thường gặp
Vì sao options của Products quan trọng khi chuyển sang BigCommerce?
Options có thể đại diện cho nhiều ý nghĩa kinh doanh khác nhau. Một số lựa chọn nên trở thành variants, một số phù hợp hơn với modifiers, một số là các trường tùy chỉnh và một số phụ thuộc vào apps hoặc quy tắc riêng. Nếu phân loại sai, trang Products có thể trông đầy đủ nhưng tồn kho, định giá, xử lý đơn hàng hoặc cách khách hàng lựa chọn lại hoạt động sai.
các trường tùy chỉnh và metafields trên BigCommerce có đủ cho mọi dữ liệu tùy chỉnh ở nguồn không?
Hai cấu trúc này có thể lưu một số dữ liệu bổ sung, nhưng không tự tái tạo hành vi của Nền tảng nguồn. Bản ghi do app quản lý, định danh hệ thống bên ngoài, quy tắc riêng của Products và transformations tùy chỉnh có thể cần tái cấu trúc dữ liệu, di chuyển dữ liệu dành cho app hoặc thiết lập Cửa hàng đích.
Categories trên BigCommerce có tự duy trì navigation ở nguồn không?
Categories không tự bảo đảm navigation giữ nguyên. Cây Categories, menu structure, SEO landing pages và bối cảnh storefront/channel cần được rà soát riêng. bản ghi Categories có thể tồn tại trong khi hành trình tìm Products vẫn phụ thuộc vào navigation phía đích, channel context, content hoặc redirects.
Bảng giá và nhóm Customers nên ảnh hưởng đến kế hoạch di chuyển dữ liệu như thế nào?
Hai cấu trúc này cần được xem như các quan hệ thương mại, không phải các trường độc lập. giá Products có thể trông đúng nhưng nhóm Customers, bảng giá, quantity rule hoặc storefront condition vẫn cần được xác thực riêng.
Dữ liệu do app hoặc các tích hợp sở hữu nên được thể hiện trên BigCommerce thế nào?
Trước tiên cần xác định hệ thống nào tiếp tục làm nguồn dữ liệu quyết định. Chỉ giữ trường, metafield hoặc external identifier trên BigCommerce khi app hoặc các tích hợp đích thực sự sử dụng giá trị đó. Hợp đồng đăng ký định kỳ, số dư loyalty, search rules, marketplace state và các bản ghi tương tự nên đi theo data path được app đích hỗ trợ thay vì bị làm phẳng thành các trường của Products hoặc Customers chung chung.
Làm thế nào để duy trì đúng ý nghĩa catalog theo channel trên BigCommerce?
Cần xác định Products, prices, Categories, content và visibility rules nào thuộc từng channel trước khi mapping. Bản ghi dùng chung có thể tiếp tục dùng chung, nhưng các khác biệt theo channel không nên bị làm phẳng nếu chúng thay đổi những gì người mua nhìn thấy hoặc cách đội ngũ vận hành.