Next-Cart

Khi dữ liệu được chuyển sang Squarespace, cần hiểu rằng nền tảng này kết hợp cấu trúc website Hosted với các bản ghi thương mại trong cùng một môi trường. Sự kết hợp này làm thay đổi ý nghĩa của dữ liệu khi chuyển đổi. Một bản ghi Products không chỉ là một dòng trong catalog: bản ghi đó thuộc một Store Page, có loại Products cụ thể, có thể chứa variants và thuộc tính, đồng thời được hiển thị thông qua cấu trúc nội dung và điều hướng của website. Một người mua có thể xuất hiện dưới dạng Contact, bản ghi Customers, người đăng ký, người quyên góp hoặc người dùng website tùy theo mối quan hệ tạo ra bản ghi. Orders lưu lại giao dịch, nhưng không trở thành cấu hình quyết định cách checkout, thanh toán, xử lý đơn hàng hoặc Taxes hoạt động trong tương lai.

Nhiệm vụ quan trọng nhất là giữ đúng những mối quan hệ giúp mỗi bản ghi tiếp tục có giá trị trong Squarespace. Dữ liệu Products phải gắn với loại Products, Store Page, variants, hình ảnh, URL và tồn kho. Dữ liệu Contacts phải phân biệt danh tính người mua, việc tham gia danh sách email, hoạt động quyên góp và quyền truy cập tài khoản. Bản ghi nội dung và SEO phải giữ đúng trang đích cùng các liên kết nội bộ, thay vì chỉ được chuyển như phần văn bản trang trí quanh cửa hàng.

Ý nghĩa thương mại bắt đầu từ website và Store Page

Squarespace không đặt một catalog tách rời bên cạnh một website không liên quan. Bản ghi thương mại nằm trong website, nơi khu vực quản lý trang, Store Pages, điều hướng, các bộ sưu tập nội dung, tên miền và URL quyết định Products được xuất bản và được khách hàng tìm thấy như thế nào. Mỗi bản ghi Products thuộc một Store Page duy nhất; khả năng hiển thị còn phụ thuộc đồng thời vào trạng thái Products và trạng thái Store Page.

Quy tắc sở hữu này đặc biệt quan trọng khi Nền tảng nguồn sử dụng nhiều catalog, collections, website hoặc kênh bán hàng. Không thể xác định đúng cách thể hiện một bản ghi Products cho đến khi Store Page đích được chọn. Vị trí Store Page không chỉ là lựa chọn trong menu, mà còn ảnh hưởng đến khả năng hiển thị và ý nghĩa URL của Products.

Giả định từ Cửa hàng nguồn Mối quan hệ trong Squarespace Ảnh hưởng khi chuyển đổi
Products tồn tại độc lập với website Mỗi bản ghi Products thuộc một Store Page trong website Squarespace Giữ danh tính Products cùng Store Page chịu trách nhiệm hiển thị bản ghi đó.
Gán Categories sẽ tự tái tạo điều hướng Cách nhóm Products, Store Page, tags, Categories và điều hướng website có liên quan nhưng không đồng nhất Chuyển cấu trúc phân loại riêng với menu và cách trình bày trang.
Một loại Products chung phù hợp với mọi sản phẩm hoặc dịch vụ Squarespace phân biệt Products vật lý, dịch vụ, gift card và Products tải xuống Loại Products quyết định variants, tồn kho, cách xử lý đơn hàng và mối quan hệ với tệp có thể sử dụng.
Customers đồng nghĩa với người đăng ký danh sách email Contacts có thể đại diện cho Customers, người đăng ký, người quyên góp và những mối quan hệ khác với website Giữ lý do bản ghi người dùng tồn tại ở hệ thống đích, không chỉ địa chỉ email.
Orders được nhập sẽ tái tạo toàn bộ hoạt động thương mại Orders giữ lịch sử và trạng thái giao dịch; chức năng tương lai vẫn được cấu hình ở nơi khác Tách hồ sơ giao dịch trước đây khỏi cấu hình thanh toán, Taxes, vận chuyển và thông báo.

Mối quan hệ giữa website và hoạt động thương mại cũng quyết định vị trí của mã định danh bên ngoài. ID Products nguồn có thể phải tiếp tục gắn với bản ghi Products hoặc variant trong Squarespace mà ERP sử dụng. ID trang nguồn có thể thuộc phạm vi nội dung thay vì thương mại. ID Customers trong CRM phải gắn với Contact mà CRM nhận diện, không phải với Orders chỉ vì ID đó xuất hiện lần đầu trong checkout.

Mỗi loại Products tạo ra một hệ quan hệ khác nhau

Squarespace hỗ trợ Products vật lý, dịch vụ, gift card và Products tải xuống. Đây không phải những nhãn chỉ dùng để trình bày. Loại Products quyết định bản ghi có thể có variants hay không, tồn kho được thể hiện như thế nào, cách xử lý đơn hàng mang ý nghĩa gì và những bản ghi bổ sung nào tham gia vào giao dịch.

Products vật lý có thể chứa variants và dữ liệu vận chuyển. Products dịch vụ cũng có thể dùng variants, chẳng hạn thời lượng hoặc cấp dịch vụ, nhưng cách hoàn thành dịch vụ khác với giao hàng vật lý. Products gift card có thể dùng variants cho từng mệnh giá. Products tải xuống liên kết Products với tệp kỹ thuật số và không hỗ trợ variants theo cùng cách.

Loại sản phẩm hoặc dịch vụ ở hệ thống nguồn Cách thể hiện trong Squarespace Mối quan hệ phải giữ đúng
Hàng hóa hữu hình Products vật lý Store Page, variants, SKU, giá, trọng lượng hoặc kích thước khi cần, tồn kho, hình ảnh, cách vận chuyển và URL.
Tư vấn, lớp học, trải nghiệm hoặc cấp dịch vụ Products dịch vụ Danh tính dịch vụ, cấp hoặc thời lượng của variant, giá, nội dung và hệ thống đặt lịch hoặc cung cấp dịch vụ khi được quản lý riêng.
Tín dụng cửa hàng hoặc chứng nhận quà tặng kỹ thuật số Products gift card Variants theo mệnh giá, mối quan hệ phát hành gift card, bối cảnh người mua và người nhận cùng ý nghĩa tài chính.
Tệp có thể tải xuống Products tải xuống cùng mối quan hệ DigitalGood Metadata Products, tệp đã mua, quyền nhận tệp và URL; không tự tạo một tập hợp variants không có thật.
Gói đăng ký định kỳ Products cùng mối quan hệ đăng ký và Orders Danh tính Products tách biệt với thanh toán định kỳ, quyền lợi và trạng thái gia hạn.
Gói quyên góp hoặc thành viên Khu vực quyên góp, membership hoặc chức năng Squarespace phù hợp thay vì Products thông thường khi cần Contacts, giao dịch, quyền truy cập và nội dung phải thuộc đúng chức năng chịu trách nhiệm trong Squarespace.

Nền tảng nguồn có thể thể hiện tất cả các loại trên dưới dạng Products, SKU hoặc loại Products tùy chỉnh. Khi chuyển sang Squarespace, cách tổ chức phải dựa trên chức năng ở hệ thống đích. Tệp khóa học có thể tải xuống, buổi tư vấn theo lịch và cuốn sách được giao có thể cùng có tên và giá, nhưng không dùng chung mối quan hệ xử lý đơn hàng hoặc cấu trúc bản ghi.

Thuộc tính, variants, hình ảnh và tồn kho của Products

Thuộc tính Products trong Squarespace xác định các giá trị như màu sắc hoặc kích thước, còn variants đại diện cho những tổ hợp thực sự có thể mua. Mỗi variant có thể có SKU, giá, số lượng tồn kho, kích thước và tập giá trị thuộc tính riêng. Hình ảnh nằm trong bộ sưu tập hình ảnh của Products và có thể được liên kết với variants.

Các lựa chọn ở Nền tảng nguồn phải được phân loại theo ảnh hưởng thương mại. Lựa chọn làm thay đổi SKU, giá, tồn kho, hình ảnh hoặc danh tính cần xử lý đơn hàng thường tương ứng với variant. Nội dung cá nhân hóa, dịch vụ tùy chọn, thành phần bundle hoặc cấu hình do ứng dụng tạo có thể không có cấu trúc variant tương ứng trong Squarespace. Biến mọi lựa chọn thành variant có thể tạo ra ma trận Products khó quản lý, trong khi chuyển variants thực sự thành văn bản sẽ làm mất danh tính SKU và tồn kho.

Cấu trúc lựa chọn ở hệ thống nguồn Thành phần chịu trách nhiệm trong Squarespace Ý nghĩa phải giữ lại
Tổ hợp kích thước và màu sắc có SKU cùng tồn kho Thuộc tính Products và ProductVariant Danh tính có thể mua, giá trị thuộc tính, SKU, giá, tồn kho và mối liên hệ hình ảnh.
Cấp dịch vụ hoặc thời lượng Variant của Products dịch vụ Lựa chọn dịch vụ có thể bán cùng mức giá hoặc khác biệt mô tả.
Mệnh giá gift card Variant của Products gift card Mệnh giá thực sự có thể mua.
Định dạng tệp tải xuống Thường là Products riêng hoặc mối quan hệ với tệp, không phải variant của Products tải xuống Đúng quyền nhận tệp và danh tính Products.
Khắc tên, văn bản tự nhập hoặc tệp người mua tải lên Dữ liệu nhập tùy chỉnh, biểu mẫu, chi tiết mặt hàng trong Orders hoặc extension được kết nối tùy theo chức năng được hỗ trợ Giá trị do Customers cung cấp phải tiếp tục gắn với giao dịch và hệ thống chịu trách nhiệm thực hiện.
Bundle hoặc configurator Mối quan hệ Products, phương án đơn giản hóa được chấp thuận hoặc cấu trúc do extension hay hệ thống ngoài quản lý Thành phần, SKU kết quả, giá, tồn kho và thông tin được lưu trong chi tiết mặt hàng của Orders phải có thể giải thích.

Tồn kho được quản lý theo variant. Squarespace Inventory API thể hiện InventoryItem như một variant của Products vật lý hoặc Products dịch vụ, đồng thời lưu trạng thái có theo dõi tồn kho hay không giới hạn, SKU và thông tin số lượng có thể bán. Vì vậy, số lượng được lưu ở cấp Products trên Nền tảng nguồn phải được đối chiếu với cấu trúc variants ở Nền tảng đích trước khi chuyển.

Giá trị tồn kho nguồn cũng cần một quyết định về hệ thống quản lý chính. Nếu Squarespace quản lý tồn kho, số lượng ban đầu phải phù hợp với từng variant đích. Nếu kho hoặc ERP tiếp tục quản lý số lượng, mối quan hệ cần duy trì là ProductVariant → mã tồn kho bên ngoài → đồng bộ tồn kho. Một số lượng được sao chép nhưng không có mã liên kết sẽ nhanh chóng lỗi thời khi hệ thống ngoài tiếp tục cập nhật.

Store Pages, Categories, tags, điều hướng và khả năng tìm Products

Store Pages sở hữu Products nhưng không thay thế mọi cấu trúc giúp khách hàng tìm Products ở hệ thống nguồn. Categories, tags, vị trí Store Page, liên kết điều hướng, summary blocks, tìm kiếm, trang nội dung và liên kết chiến dịch bên ngoài đều có thể dẫn khách hàng đến Products. Một collection nguồn có thể đại diện cho bộ phận catalog lâu dài, chiến dịch tạm thời, thương hiệu, kết quả lọc hoặc trang biên tập. Những ý nghĩa này phải được tách riêng.

Cấu trúc giúp tìm Products ở hệ thống nguồn Cách thể hiện phù hợp trong Squarespace
Bộ phận catalog lâu dài Categories dành cho Products hoặc cách nhóm Store Page lâu dài, tùy cấu trúc đích.
Thương hiệu Products Tag, mối quan hệ nội dung, quy ước đặt tên hoặc trường thông tin Products bên ngoài, tùy cách thương hiệu được sử dụng.
Collection theo mùa Categories, tag, trang được biên tập hoặc liên kết điều hướng tạm thời, không mặc nhiên là một loại Products lâu dài.
Thuộc tính dùng cho bộ lọc nhiều tiêu chí Thuộc tính variant, nội dung Products có cấu trúc, tag hoặc hệ thống tìm kiếm và lọc bên ngoài; không tự động trở thành Categories.
Liên kết điều hướng chính Liên kết trong điều hướng website đến Store Page, chế độ xem Categories, trang nội dung hoặc URL bên ngoài.
Trang đích SEO Trang hoặc Store Page kết nối Products, nội dung, URL, metadata và liên kết nội bộ.

Products API không cung cấp mọi mối quan hệ giữa Store Page và Categories theo cùng cách API này cung cấp bản ghi Products. Điều này càng cho thấy catalog và cách tổ chức website phải được xem là hai phần khác nhau. Mô hình đích cần chỉ rõ bản ghi nào quản lý phân loại Products và thành phần website nào quản lý cách khách hàng tìm thấy chúng.

Một bản ghi Products có thể được di chuyển chính xác nhưng vẫn gần như không thể tiếp cận nếu thuộc sai Store Page, bị ẩn hoặc không có đường dẫn điều hướng. Đây là lỗi trong mối quan hệ và cách công bố Products, không có nghĩa trường dữ liệu Products bị thiếu.

Contacts, Customers, người đăng ký, người quyên góp và quyền truy cập

Các chức năng thương mại và marketing của Squarespace có thể tạo ra nhiều ý nghĩa liên quan đến một người. Contacts có thể đại diện cho Customers, người đăng ký, người quyên góp và những người khác có mối quan hệ với website. Sổ địa chỉ và lựa chọn marketing thuộc về từng mối quan hệ đó. Mô hình Profiles cũ từng thể hiện các nhóm người dùng website tương tự, còn Contacts API hiện là nơi quản lý Contacts theo phạm vi rộng hơn.

Tài khoản Customers ở Nền tảng nguồn còn có thể chứa mật khẩu, nhóm Customers, vai trò B2B, số dư loyalty, thông tin thanh toán đã lưu, quyền membership, trạng thái đăng ký định kỳ, miễn Taxes hoặc thuộc tính CRM. Không nên dồn mọi ý nghĩa vào một bản ghi Contacts chỉ vì cùng địa chỉ email.

Mô hình danh tính ở hệ thống nguồn Quyết định về mối quan hệ trong Squarespace
Người mua đã đăng ký Danh tính Contact hoặc bản ghi Customers gắn với Orders, địa chỉ và chức năng tài khoản được hỗ trợ.
Người mua không đăng nhập khi checkout Danh tính người mua gắn với Orders; chỉ tạo Contact lâu dài khi mối quan hệ đích hỗ trợ điều đó.
Người đăng ký nhận email Contact cùng mối quan hệ với danh sách marketing và trạng thái đồng ý, tách khỏi lịch sử mua hàng khi cần.
Người quyên góp Contact cùng lịch sử quyên góp hoặc giao dịch, không tự động trở thành bản ghi Customers trong hoạt động thương mại.
Thành viên hoặc người dùng nội dung giới hạn quyền truy cập Contact hoặc người dùng website cùng mối quan hệ membership hay quyền truy cập; mật khẩu và quyền lợi không phải trường hồ sơ thông thường.
Người mua B2B hoặc tổ chức Contact cùng CRM hoặc hệ thống ngoài quản lý công ty, vai trò, giá, Taxes hoặc phê duyệt.
Hồ sơ trùng lặp ở hệ thống nguồn Chỉ hợp nhất khi thông tin xác nhận về danh tính, trạng thái đồng ý, địa chỉ và Orders cho thấy đó là cùng một người.

Email là dấu hiệu nhận diện quan trọng nhưng không phải duy nhất. Địa chỉ dùng chung, email đã thay đổi, Orders của khách mua không đăng nhập, lần nhập dữ liệu trùng lặp và Contacts của tổ chức có thể dẫn đến hợp nhất sai. ID CRM, ID Customers nguồn, địa chỉ và mối quan hệ với Orders có thể cần thiết để giữ đúng từng người cùng lịch sử tương ứng.

Trạng thái đồng ý nhận marketing phải tách khỏi danh tính người mua. Customers từng mua hàng không mặc nhiên là người đăng ký danh sách email, và người đăng ký có thể chưa từng mua hàng. Giữ bản ghi Contacts nhưng làm mất mối quan hệ giải thích lý do bản ghi tồn tại có thể gây nhầm lẫn trong vận hành và vấn đề về sự đồng ý.

Orders, giao dịch tài chính và thông tin về quá trình xử lý đơn hàng trước đây

Orders trong Squarespace có thể đại diện cho giao dịch một lần hoặc đơn hàng phát sinh từ đăng ký định kỳ. Bản ghi này chứa chi tiết mặt hàng, thông tin Customers, địa chỉ thanh toán và giao hàng, tổng tiền, giảm giá, Taxes, phí vận chuyển, trạng thái xử lý, trạng thái thanh toán, hoàn tiền và các thông tin liên quan khác. Dữ liệu giao dịch tài chính ghi lại các khoản thanh toán, hoàn tiền, phí và lỗi cổng thanh toán liên quan đến Orders hoặc hoạt động quyên góp.

Orders phải giữ thông tin Products hoặc variant đã mua tại thời điểm giao dịch, kể cả khi Products hiện tại thay đổi về sau. Chi tiết mặt hàng là ảnh chụp của giao dịch, không phải tham chiếu trực tiếp để nội dung catalog hiện tại ghi đè. Trạng thái thanh toán và hoàn tiền cho biết điều gì đã xảy ra về tài chính; thông tin xử lý và theo dõi cho biết giao dịch đã được thực hiện như thế nào. Orders được nhập hoặc lịch sử đơn hàng không quyết định bộ xử lý thanh toán, quy tắc vận chuyển, cấu hình Taxes, thông báo email hay kết nối kho đang sử dụng.

Thành phần trong Orders đã phát sinh Ý nghĩa cần giữ trong Squarespace
Số Orders nguồn Tham chiếu bên ngoài có thể truy vết để phục vụ Customers và đối soát.
Chi tiết Products hoặc variant đã mua Tiêu đề lúc mua, SKU, thuộc tính đã chọn, số lượng, giá và thông tin khác của mặt hàng trong giao dịch.
Địa chỉ thanh toán và giao hàng Thông tin của giao dịch đã xảy ra, không tự động trở thành địa chỉ tài khoản lâu dài nếu Contact không quản lý riêng.
Dòng giảm giá, Taxes và vận chuyển Giải thích tổng tiền của giao dịch đã xảy ra, không phải cấu hình giảm giá hoặc Taxes hiện tại.
Trạng thái thanh toán và giao dịch Thông tin tài chính gắn với Orders, không phải thông tin thanh toán có thể tái sử dụng.
Xử lý đơn hàng và theo dõi Thông tin về việc giao hàng hoặc cung cấp dịch vụ đã xảy ra, không phải định nghĩa phương thức xử lý hiện tại.
Trạng thái đăng ký định kỳ hoặc kế hoạch thanh toán Vòng đời Orders và các giao dịch liên quan phải tiếp tục gắn với hệ thống quản lý khoản thu trong tương lai.
Orders nhập từ kênh bán hàng bên thứ ba Lịch sử đơn hàng cùng mã định danh kênh ngoài và mối quan hệ với nguồn tạo giao dịch.

Squarespace có thể nhập Orders từ kênh bán hàng của bên thứ ba thông qua Commerce APIs, nhưng dữ liệu đơn hàng được nhập vẫn phải giữ nguồn và mã định danh ban đầu. Việc tạo một bản ghi Orders trong Squarespace không làm marketplace, nhà cung cấp thanh toán hoặc hệ thống xử lý đơn hàng nguồn mất vai trò sở hữu các tham chiếu lịch sử liên quan.

Mối quan hệ giữa trang, Blog Posts, media, URL và SEO

Website Squarespace có thể chứa trang thông thường, Store Pages, Blog Posts, mục trong collection, hình ảnh, tệp, liên kết điều hướng, URL Products, chế độ xem Categories, trường SEO, chuyển hướng, tên miền và dịch vụ được kết nối. Các bản ghi này tạo thành mạng lưới nội dung xung quanh catalog thương mại.

Mô tả Products nguồn thuộc về Products. Hướng dẫn mua hàng có thể là trang hoặc Blog Posts liên kết đến nhiều Products. Mô tả Categories có thể trở thành nội dung Store Page hoặc trang đích. Trang chiến dịch có thể tham chiếu Products nhưng không sở hữu dữ liệu Products. Media có thể được dùng chung giữa Products và nội dung, nhưng thứ tự hình ảnh, cách cắt ảnh, alt text, caption và liên kết nội bộ đều có ý nghĩa riêng trong website.

Tài sản website ở hệ thống nguồn Thành phần chịu trách nhiệm trong Squarespace
Tiêu đề, mô tả, hình ảnh, slug URL và dữ liệu SEO của Products Mối quan hệ giữa Products và Store Page.
CMS Pages về chính sách hoặc thông tin Trang Squarespace cùng nội dung, media, metadata và mối quan hệ điều hướng.
Blog Posts Mục trong blog collection cùng bối cảnh xuất bản, Categories hoặc tags, media, liên kết nội bộ và URL.
Hướng dẫn Products hoặc trang đích chiến dịch Trang hoặc content collection cùng tham chiếu Products và điều hướng.
Mục menu Mối quan hệ điều hướng website trỏ đến trang, Store Page, Products, anchor hoặc URL bên ngoài.
URL nguồn Đường dẫn đích cùng chuyển hướng nếu cấu trúc URL thay đổi.
Block giao diện hoặc mã tùy chỉnh Cấu hình trình bày website tham chiếu nội dung và bản ghi thương mại nhưng không trở thành nơi sở hữu các bản ghi đó.

Duy trì khả năng truy cập từ URL cũ phụ thuộc vào việc xác định đúng trang đích. Chuyển hướng phải nối đường dẫn nguồn với Products, Store Page, trang, Blog Posts hoặc đích thay thế chính xác. Không nên dùng chuyển hướng để che giấu việc chưa biết bản ghi nào thay thế trang nguồn. Liên kết nội bộ trong nội dung đã di chuyển cũng phải trỏ đến đúng đích thay vì giữ URL nguồn không còn sử dụng.

Extensions, API, các trường tùy chỉnh và hệ thống bên ngoài

Các Squarespace Commerce API tương ứng cung cấp quyền truy cập vào các tài nguyên Products, Inventory, Orders, Transactions, Contacts, Discounts và Websites, cùng webhooks. Dịch vụ được kết nối cùng extensions còn có thể quản lý Reviews, loyalty, đăng ký định kỳ, xử lý đơn hàng, kế toán, vận chuyển, marketing, đặt lịch, quyên góp, membership hoặc dữ liệu khác. Không nên coi bản ghi của ứng dụng nguồn là dữ liệu gốc của Squarespace chỉ vì có một extension đích cung cấp chức năng tương tự.

Nơi lưu và quản lý phù hợp phụ thuộc vào mục đích kinh doanh cùng vòng đời dữ liệu. ID kho của Products phải gắn với ProductVariant và mối quan hệ ERP. ID CRM của Contact phải gắn với Contact và CRM. ID Orders của marketplace phải gắn với Orders và kênh bán hàng. Quyền membership thuộc hệ thống membership, không phải một ghi chú chung trong Contacts.

Giá trị tùy chỉnh hoặc bên ngoài Nơi chịu trách nhiệm ở hệ thống đích
ID Products hoặc variant trong ERP Products hoặc ProductVariant cùng mối quan hệ ERP ở đúng cấp catalog.
Mã tồn kho bên ngoài ProductVariant cùng kho hoặc hệ thống tồn kho.
ID Contacts trong CRM Contacts cùng mối quan hệ CRM.
ID Orders trong marketplace Orders cùng mối quan hệ kênh bán hàng.
Bản ghi Reviews, loyalty hoặc đăng ký định kỳ Extension hoặc hệ thống ngoài cùng tham chiếu đến Products, Contacts hoặc Orders.
Kết quả từ configurator Products Products hoặc variant, cấu hình do extension quản lý và thông tin kết quả trong chi tiết mặt hàng của Orders.
Câu trả lời tùy chỉnh trong checkout Orders hoặc Contacts tùy mục đích kinh doanh, cùng biểu mẫu hoặc extension quản lý việc thu thập và hiển thị.
Bảng dữ liệu nguồn chưa được hỗ trợ Phải xác định bản ghi cha, mã liên kết lâu dài, vòng đời và hệ thống đích chịu trách nhiệm trước khi giữ lại giá trị.

Ranh giới này tránh hai lỗi phổ biến: ép mọi giá trị vào trường của Squarespace gần nhất và giữ dữ liệu ứng dụng nhưng không có hệ thống đích sử dụng. các trường tùy chỉnh chỉ hữu ích khi đội ngũ biết bản ghi nào sở hữu giá trị, hệ thống nào nhận diện giá trị đó và giá trị đó mô tả hoạt động thương mại hiện tại, dữ liệu quá khứ cần tham chiếu, nội dung hay cấu hình bên ngoài.

Các chuỗi quan hệ đại diện trong Squarespace

Chuỗi quan hệ cho thấy một khái niệm ở Nền tảng nguồn được tách thành những bản ghi thương mại, Contacts, nội dung và hệ thống ngoài nào trong Squarespace. Cách thể hiện này giúp nhìn rõ nơi chịu trách nhiệm và tránh để một trường được nhập phải mang nhiều ý nghĩa không tương thích. Chuỗi vẫn phải dễ hiểu sau khi Nền tảng nguồn không còn khả dụng, để mỗi tham chiếu Products, Contacts, Orders, URL và extension đều có bản ghi cha cùng hệ thống tiếp tục sử dụng.

Mô hình nguồn Chuỗi quan hệ tại hệ thống đích
Products thời trang có tồn kho theo kích thước và màu sắc Store Page → Products vật lý → thuộc tính → ProductVariants → hình ảnh hoặc SKU theo variant → InventoryItems.
Các gói tư vấn Store Page → Products dịch vụ → variants theo cấp hoặc thời lượng → nội dung → hệ thống đặt lịch hoặc cung cấp dịch vụ bên ngoài khi cần.
Tệp kỹ thuật số Store Page → Products tải xuống → DigitalGood → chi tiết mặt hàng trong Orders → Contact đã mua → quyền nhận tệp.
Người đăng ký email sau đó mua hàng Contact → mối quan hệ danh sách email và trạng thái đồng ý → lịch sử Customers hoặc Orders, không giả định hai mối quan hệ là một.
Giao dịch được nhập từ marketplace Orders → thông tin mặt hàng tại thời điểm mua → lịch sử giao dịch và xử lý đơn hàng → Contact → ID marketplace bên ngoài.
Nhóm Products nhạy cảm với SEO Store Page, Categories hoặc trang được biên tập → tham chiếu Products → điều hướng → URL đích → chuyển hướng từ đường dẫn nguồn.
Bản ghi membership hoặc quyên góp Contact → hệ thống membership hoặc quyên góp → lịch sử giao dịch hoặc quyền truy cập, tách khỏi trường của Products và Customers thông thường.

Những chuỗi này giúp duy trì rõ nơi quản lý Products, website, Contacts, Orders, nội dung và hệ thống bên ngoài. Chúng cũng cho thấy trường hợp một bản ghi nguồn kết hợp nhiều ý nghĩa nhưng Squarespace thể hiện thành các thành phần riêng.

Kết luận

Chuyển đổi mô hình dữ liệu sang Squarespace phụ thuộc vào mối quan hệ giữa bản ghi thương mại và website dùng để công bố chúng. Products thuộc Store Pages và từng loại Products; variants quản lý tổ hợp có thể bán cùng tồn kho; Contacts có thể mang ý nghĩa Customers, người đăng ký, người quyên góp và tài khoản; Orders giữ lịch sử giao dịch; trang, Blog Posts, URL và điều hướng quản lý khả năng tìm nội dung; extensions và hệ thống bên ngoài chịu trách nhiệm cho chức năng chuyên biệt.

Mô hình đích tốt phải giữ những mối quan hệ đó mà không nhầm dữ liệu được di chuyển với cách trình bày website hoặc cấu hình vận hành trong tương lai. Kết quả cần đạt là một website Squarespace có dữ liệu được liên kết rõ ràng. Products, Contacts, Orders, nội dung và bản ghi bên ngoài phải giữ đúng quan hệ để đội ngũ tiếp tục hiểu hệ thống nào sở hữu và sử dụng từng thông tin.

Câu hỏi thường gặp

Vì sao Store Page quan trọng với Products trong Squarespace?

Mỗi bản ghi Products trong Squarespace thuộc một Store Page, còn khả năng hiển thị phụ thuộc cả trạng thái Products và trạng thái Store Page. Vì vậy, dữ liệu Products và vị trí Store Page tạo thành một mối quan hệ đích, trong khi điều hướng website vẫn là thành phần riêng.

Mọi lựa chọn Products ở hệ thống nguồn có thể trở thành variant trong Squarespace không?

Không phải mọi lựa chọn Products ở hệ thống nguồn đều có thể trở thành variant trong Squarespace. Variant phù hợp khi lựa chọn tạo ra một tổ hợp có thể mua với SKU, giá, tồn kho, hình ảnh, kích thước hoặc ý nghĩa bán hàng riêng. Nội dung cá nhân hóa, bundle, tệp tải lên hoặc lựa chọn do ứng dụng quản lý có thể cần thành phần chịu trách nhiệm khác.

Contacts, Customers và người đăng ký trong Squarespace có phải cùng một loại bản ghi không?

Các mối quan hệ này có thể cùng thuộc một người nhưng không đồng nhất. Lịch sử Customers, trạng thái đồng ý nhận marketing, hoạt động quyên góp, sổ địa chỉ và quyền truy cập tài khoản phải tiếp tục được phân biệt, kể cả khi một Contact kết nối chúng.

Orders được di chuyển có tái tạo cách checkout hoạt động trong Squarespace không?

Orders được di chuyển không tái tạo cách checkout hoạt động trong Squarespace. Orders giữ bối cảnh giao dịch, chi tiết mặt hàng, thanh toán, hoàn tiền, địa chỉ và xử lý đơn hàng. Bộ xử lý thanh toán, cấu hình Taxes, phương thức vận chuyển, thông báo và các tích hợp xử lý đơn hàng hiện tại vẫn là cấu hình riêng.

Tồn kho Products nên được thể hiện như thế nào trong Squarespace?

Tồn kho phải gắn với ProductVariant đại diện cho phiên bản Products thực sự được bán. Nếu hệ thống tồn kho bên ngoài tiếp tục quản lý số lượng, variant còn cần mã liên kết lâu dài để đồng bộ sau lần chuyển dữ liệu ban đầu.

Dữ liệu do ứng dụng hoặc các trường tùy chỉnh quản lý nên được lưu ở đâu?

Dữ liệu phải tiếp tục gắn với Products, ProductVariant, Contacts, Orders, bản ghi nội dung, extension hoặc hệ thống ngoài chịu trách nhiệm cho mục đích kinh doanh tương ứng. Ghi chú chung không thể thay thế một mối quan hệ với bản ghi cha và mã định danh lâu dài đã được xác định.