Dữ liệu về lựa chọn Products quyết định cách khách hàng đi từ trang chi tiết đến đúng phiên bản có thể mua. Một chiếc áo không chỉ gồm bản ghi Products chính mà còn có thể có tùy chọn kích thước và màu sắc, nhiều SKU biến thể, tồn kho riêng theo từng biến thể, hình ảnh tương ứng, mức giá khác nhau, quy tắc xử lý đơn hàng và thông tin về phiên bản đã chọn cần được ghi lại trong Orders. Một chiếc laptop cho phép cấu hình, một bộ sản phẩm, một mặt hàng sản xuất theo yêu cầu hoặc một mặt hàng cá nhân hóa có thể cần cấu trúc dữ liệu phức tạp hơn nhiều dù khách hàng chỉ nhìn thấy một trang Products.
Thách thức kỹ thuật là các nền tảng thương mại điện tử không sử dụng cùng một mô hình để tạo ra quá trình lựa chọn Products. Có nền tảng coi mỗi tổ hợp có thể mua là một biến thể gắn với Products chính. Nền tảng khác có thể dùng Products có thể cấu hình, bảng tùy chọn, thuộc tính Products, tùy chọn tùy chỉnh, bundle, công cụ tạo tùy chọn do app quản lý hoặc các bản ghi riêng của extension. Vì vậy, cùng một catalog có thể hiển thị rất đơn giản trên cửa hàng nhưng trải nghiệm đó lại phụ thuộc vào nhiều cấu trúc dữ liệu khác nhau.
Biến thể và tùy chọn xác định mặt hàng khách hàng thực sự mua
Một biến thể thường đại diện cho một phiên bản của Products được bán và quản lý như một mặt hàng riêng. Doanh nghiệp thường dùng chính bản ghi biến thể để quản lý giá, tồn kho, xử lý đơn hàng, báo cáo và thông tin cần ghi nhận khi khách hàng mua. Trong nhiều catalog, mỗi biến thể mang SKU, barcode, lượng tồn kho, trọng lượng, hình ảnh tương ứng, địa điểm xử lý đơn hàng, trạng thái chịu thuế, trạng thái hoạt động và đôi khi cả mức giá riêng.
Tùy chọn là phần lựa chọn mà khách hàng nhìn thấy để đi đến một biến thể cụ thể hoặc điều chỉnh Products đang chọn. Các nhóm tùy chọn thường gặp gồm kích thước, màu sắc, chất liệu, bề mặt hoàn thiện, dung lượng, hương vị, số lượng trong gói, khu vực, chu kỳ đăng ký định kỳ hoặc kiểu dáng. Mỗi nhóm chứa các giá trị có thể chọn, chẳng hạn Small, Medium, Large, Black, Walnut, 128 GB hoặc Pack of 12.
Cần phân biệt hai khái niệm này vì tùy chọn mô tả cách khách hàng lựa chọn, còn biến thể thường là phiên bản được nhận diện và quản lý riêng trong bán hàng, tồn kho và Orders. Nếu một bản ghi Products có ba kích thước và bốn màu, trang cửa hàng có thể chỉ hiển thị hai nhóm tùy chọn nhưng catalog lại chứa mười hai bản ghi biến thể. Mỗi biến thể có thể có SKU, mức tồn kho, hình ảnh, giá, cách xử lý đơn hàng và bộ thông tin riêng cần được ghi lại khi phiên bản đó được mua.
Không phải lựa chọn nào của khách hàng cũng nên trở thành biến thể. Một số lựa chọn chỉ là thuộc tính mô tả, trường cá nhân hóa, lựa chọn add-on, thành phần của bộ sản phẩm hoặc dữ liệu cấu hình tùy chỉnh. Trường nhập nội dung thêu tên, ô chọn gói quà, add-on bảo hành và lựa chọn màu có thể cùng xuất hiện bên cạnh nút mua hàng, nhưng không nhất thiết thuộc cùng một mô hình dữ liệu.
Bản ghi Products chính, biến thể và Orders liên kết với nhau như thế nào
Trong mô hình dữ liệu, bản ghi Products chính lưu thông tin dùng chung của mặt hàng. Biến thể và tùy chọn xác định chính xác phiên bản khách hàng có thể mua, còn Orders ghi lại phiên bản cùng các lựa chọn đã được mua trong từng giao dịch. Bản ghi Products chính giữ tiêu đề, mô tả, loại Products, vị trí trong Categories, thương hiệu, nhóm thuế, media dùng chung, trường SEO và bối cảnh trưng bày; dữ liệu biến thể và tùy chọn nối phần thông tin chung đó với mặt hàng thực tế được bán.
Một cấu trúc lựa chọn Products thường gồm:
| Thành phần trong mô hình | Thông tin thường gặp | Ý nghĩa trong thực tế |
|---|---|---|
| Bản ghi Products chính | Tiêu đề, handle hoặc slug, mô tả, Categories, loại Products, nhà cung cấp hoặc thương hiệu, hình ảnh dùng chung, trường SEO | Xác định Products chính trên cửa hàng và bối cảnh trưng bày |
| Nhóm tùy chọn | Tên tùy chọn, thứ tự hiển thị, kiểu nhập liệu, các giá trị được phép | Xác định khách hàng cần chọn điều gì |
| Giá trị tùy chọn | Nhãn, mã giá trị, thứ tự sắp xếp, swatch, mã màu, media liên kết | Xác định lựa chọn cụ thể trong một nhóm tùy chọn |
| Bản ghi biến thể | SKU, barcode, giá, tồn kho, trọng lượng, hình ảnh, tình trạng còn hàng, dữ liệu xử lý đơn hàng, trạng thái chịu thuế, trạng thái hoạt động | Xác định phiên bản Products được bán và quản lý như một mặt hàng riêng |
| Tùy chọn tùy chỉnh hoặc trường điều chỉnh | Ô nhập văn bản, trường tải tệp, checkbox, ngày, số đo, mức giá của add-on, quy tắc xác thực | Bổ sung cách mua hàng mà không nhất thiết tạo ra một biến thể chuẩn |
| Thành phần bundle hoặc kit | Products thành phần, số lượng, trạng thái bắt buộc hoặc tùy chọn, quy tắc thay thế | Xác định một mặt hàng được ghép từ nhiều Products |
Mỗi nền tảng phân bổ trường dữ liệu cho Products chính, biến thể và tùy chọn theo cách khác nhau. Có hệ thống chỉ lưu giá trên biến thể. Ở hệ thống khác, bản ghi Products chính giữ giá cơ sở, còn trường điều chỉnh hoặc quy tắc tùy chọn thay đổi giá cuối cùng. Một số nền tảng gắn hình ảnh trực tiếp vào bản ghi biến thể. Nền tảng khác dựa vào quan hệ với gallery, cách theme xử lý lựa chọn hoặc app bên ngoài để đổi hình ảnh khi khách hàng chọn tùy chọn.
Cấu trúc này đặc biệt quan trọng khi cửa hàng sử dụng nhiều dữ liệu riêng theo biến thể. Nếu mọi biến thể có cùng giá, hình ảnh và cách quản lý tồn kho, việc xây dựng lại mô hình sẽ đơn giản hơn. Khi từng biến thể có lượng tồn kho, barcode, tuyến kho, hình ảnh, giá khuyến mãi, nhóm thuế hoặc mã marketplace riêng, dữ liệu của từng biến thể trở thành một phần thiết yếu của vận hành.
Các mối quan hệ quyết định dữ liệu lựa chọn có còn hoạt động đúng
Biến thể và tùy chọn hiếm khi hoạt động độc lập. Chúng liên quan đến cách duyệt catalog, tìm kiếm, bộ lọc, tồn kho, giỏ hàng, Orders, xử lý đơn hàng, phân tích và các hệ thống bên ngoài.
Tồn kho là một trong những mối quan hệ quan trọng nhất. Bản ghi Products chính có thể hiển thị là còn hàng, nhưng số lượng thực sự có thể mua thường được quản lý theo từng biến thể. Nếu Blue / Medium hết hàng còn Blue / Large vẫn có sẵn, cửa hàng phải thể hiện đúng trạng thái tại bước lựa chọn tương ứng. Mô hình tồn kho tại nhiều địa điểm còn phức tạp hơn vì cùng một biến thể có thể có số lượng khả dụng khác nhau theo kho, cửa hàng, trung tâm xử lý đơn hàng hoặc thị trường.
Orders cũng phụ thuộc vào cấu trúc variants. Một đơn hàng đã hoàn tất cần cho biết chính xác mặt hàng khách hàng đã mua, không chỉ tiêu đề của Products chính. SKU biến thể, giá trị tùy chọn, giá, thuế, phần giảm giá được phân bổ, dữ liệu xử lý đơn hàng và giá trị khách hàng nhập có thể đều cần được hiểu đúng để phục vụ hỗ trợ khách hàng, xử lý tại kho, trả hàng, phân tích và kế toán.
Tìm kiếm và bộ lọc cũng có thể phụ thuộc vào ranh giới giữa tùy chọn và thuộc tính. Tùy chọn màu có thể dùng để chọn biến thể, còn thuộc tính màu dùng để lọc Products. Một số nền tảng kết nối hai khái niệm này, trong khi nền tảng khác quản lý riêng. Khi mô hình thay đổi, cửa hàng có thể vẫn bán được Products nhưng bộ lọc không còn đưa ra kết quả đầy đủ, hoặc bộ lọc vẫn hoạt động nhưng quá trình chọn đúng biến thể để mua bị mất.
Các hệ thống bên ngoài thường dùng mã định danh riêng của từng biến thể. ERP, hệ thống kho, marketplace, POS, PIM, hệ thống đăng ký định kỳ và dịch vụ xử lý đơn hàng có thể nhận diện từng phiên bản Products được bán bằng SKU, barcode, mã biến thể, mã Products bên ngoài hoặc tổ hợp nhiều trường. Nếu sau khi di chuyển, các mã này bị gắn với Products chính hoặc một đối tượng khác thay vì đúng biến thể, các hệ thống liên quan có thể đọc sai tồn kho, Orders hoặc dữ liệu báo cáo.
Các nền tảng mô hình hóa lựa chọn Products theo những cách khác nhau
Các nền tảng thương mại điện tử phân tách Products chính, biến thể, tùy chọn, thuộc tính, Products có thể cấu hình, bundle và chức năng tùy chỉnh theo những cách khác nhau.
Nhiều nền tảng SaaS sử dụng một bản ghi Products chính, một số lượng giới hạn nhóm tùy chọn và danh sách biến thể được tạo từ các tổ hợp. Mô hình này dễ hiểu và phù hợp với catalog kích thước, màu sắc đơn giản, nhưng có thể giới hạn số nhóm tùy chọn, số biến thể, cách hiển thị tùy chọn hoặc chức năng tùy chỉnh ở cấp biến thể.
Một số nền tảng Open Source và Enterprise Platform có hệ thống loại Products phong phú hơn. Products có thể cấu hình đóng vai trò bản ghi chính, còn các bản ghi Products đơn giản là những phiên bản con được bán riêng. Grouped products, bundle, Products tải xuống, Products ảo và Products có tùy chọn tùy chỉnh có thể dùng các cấu trúc dữ liệu riêng. Vì vậy, cùng một lựa chọn trên cửa hàng có thể là biến thể ở nền tảng này nhưng trở thành quan hệ cấu hình, thành phần bundle hoặc tùy chọn tùy chỉnh ở nền tảng khác.
Một số nền tảng phụ thuộc nhiều vào thuộc tính. Nhóm thuộc tính, thuộc tính dùng chung, thuộc tính riêng theo Products, swatches, layered navigation và thuộc tính dùng để cấu hình có thể đồng thời quyết định cách lựa chọn hiển thị và việc lựa chọn đó có tạo ra một phiên bản được bán riêng hay không. Trong các hệ thống này, mô hình thuộc tính không chỉ mô tả Products mà còn có thể điều khiển cách tạo Products, lọc, trưng bày và so sánh.
Các cửa hàng phụ thuộc nhiều vào extension có thể dùng công cụ tạo tùy chọn, trình cấu hình Products, bảng dữ liệu tùy chỉnh, trường do app quản lý, dữ liệu cấu hình được tuần tự hóa hoặc quy tắc trong theme để tạo hành vi mua hàng ngoài mô hình Products cốt lõi. Giao diện cửa hàng vẫn có thể trông bình thường dù dữ liệu xuất Products tiêu chuẩn không thể hiện đầy đủ những cấu trúc bổ trợ tạo ra hành vi mua hàng đó.
Những trường hợp phức tạp dễ bị bỏ sót
Độ phức tạp của quá trình lựa chọn Products thường nằm trong những chi tiết khó nhận ra khi chỉ nhìn vào cách catalog hiển thị trên cửa hàng.
Một trường hợp là số lượng biến thể tăng quá lớn. Products có bốn nhóm tùy chọn có thể tạo ra hàng trăm hoặc hàng nghìn tổ hợp. Một số nền tảng giới hạn số biến thể mà một bản ghi Products chính có thể chứa. Ngay cả khi cho phép số lượng cao hơn, số lượng lớn tổ hợp biến thể vẫn có thể làm chậm quản trị, khiến trang Products rối hơn, làm việc cập nhật tồn kho phức tạp và tăng khối lượng xác thực.
Trường hợp khác là các tổ hợp không hợp lệ. Catalog có thể bán Black / Small, Black / Medium và White / Large, nhưng không phải mọi tổ hợp màu và kích thước đều tồn tại. Một số nền tảng chỉ lưu các biến thể hợp lệ. Nền tảng khác tạo toàn bộ tổ hợp rồi ẩn, vô hiệu hóa hoặc đánh dấu hết hàng cho những lựa chọn không có sẵn. Sự khác biệt này ảnh hưởng cả cấu trúc dữ liệu lẫn trải nghiệm khách hàng.
Hình ảnh theo biến thể cũng được xử lý khác nhau giữa các nền tảng. Có cửa hàng gắn hình ảnh trực tiếp vào biến thể. Có cửa hàng liên kết hình ảnh với swatch hoặc giá trị tùy chọn. Trường hợp khác phụ thuộc vào theme để thay đổi gallery khi khách hàng chọn tùy chọn, hoặc chỉ gắn toàn bộ hình ảnh với Products chính. Nếu quan hệ giữa giá trị tùy chọn và hình ảnh bị mất, Products vẫn có thể mua được nhưng khách hàng dễ hiểu sai phiên bản đang chọn.
Tùy chọn tùy chỉnh tạo ra một nhóm rủi ro khác. Nội dung khắc, tệp khách hàng tải lên, số đo, ngày, lựa chọn lắp đặt, lời nhắn tặng quà, lựa chọn bảo hành và thông số sản xuất theo yêu cầu có thể được lưu tách khỏi biến thể. Một số lựa chọn làm thay đổi giá nhưng không ảnh hưởng tồn kho. Một số ảnh hưởng đến cách xử lý đơn hàng nhưng không tạo SKU riêng. Một số cần được ghi lại trong chi tiết mặt hàng của Orders mà không nên tạo thành bản ghi Products riêng.
Bundle, kit và grouped products cần được hiểu theo đúng mô hình. Bundle có thể có trang Products riêng nhưng phụ thuộc vào Products thành phần và số lượng. Kit có thể được xử lý như một SKU dù gồm nhiều thành phần. Grouped products có thể cho phép khách hàng mua nhiều Products liên quan cùng lúc. Nếu tất cả đều bị chuyển thành biến thể đơn giản, tồn kho, thông tin mặt hàng trong Orders, giá và quy trình xử lý đơn hàng có thể không còn phản ánh đúng cách bán ban đầu.
Điều gì có thể thay đổi khi mô hình được xây dựng lại trên Nền tảng đích
Khi dữ liệu lựa chọn Products được xây dựng lại theo mô hình của nền tảng khác, giao diện trang Products chỉ phản ánh một phần kết quả. Câu hỏi quan trọng hơn là Nền tảng đích có tiếp tục thể hiện đúng cách bán hàng hay không.
Một số thay đổi có thể xảy ra:
| Thay đổi cấu trúc | Ảnh hưởng có thể xảy ra |
|---|---|
| Biến thể trở thành thuộc tính | Khách hàng vẫn nhìn thấy thông tin nhưng cửa hàng có thể mất khác biệt về SKU, tồn kho hoặc giá |
| Thuộc tính trở thành biến thể | Việc quản lý Products trở nên phức tạp không cần thiết và có thể tạo ra các tổ hợp không có ý nghĩa |
| Tùy chọn tùy chỉnh trở thành biến thể chuẩn | Trường cá nhân hóa hoặc trường dành cho add-on có thể bị biến thành mặt hàng cứng, có theo dõi tồn kho |
| Hình ảnh biến thể trở thành hình ảnh Products chính | Hình ảnh có thể không còn đổi đúng theo lựa chọn của khách hàng |
| Thành phần bundle trở thành Products độc lập | Thông tin mặt hàng trong Orders, xử lý đơn hàng hoặc trừ tồn kho có thể không còn đúng với cách vận hành của kit |
| Mã bên ngoài được chuyển sang sai cấp dữ liệu | ERP, POS, marketplace hoặc hệ thống kho có thể đồng bộ với sai mặt hàng |
Những thay đổi này không phải lúc nào cũng cho thấy quá trình di chuyển sai. Đôi khi cấu trúc cần được chuẩn hóa vì Nền tảng đích dùng mô hình khác. Doanh nghiệp cần xác định rõ những chức năng và kết quả phải tiếp tục đáp ứng yêu cầu. Khách hàng phải chọn và mua được đúng phiên bản; tồn kho phải được kiểm soát chính xác; Orders phải ghi đúng phiên bản Products đã mua; quy trình xử lý đơn hàng và báo cáo phải giữ đúng ý nghĩa; Products phải được trình bày rõ ràng.
Một phương án kỹ thuật phù hợp phải giữ đúng các chức năng quan trọng dù mô hình dữ liệu bên dưới thay đổi. Phương án có rủi ro là phương án giữ được số lượng bản ghi nhưng làm mất quan hệ giữa lựa chọn, định danh mặt hàng và ý nghĩa trong vận hành.
Nên chọn những Products nào để kiểm tra
Việc kiểm tra nên bắt đầu từ các bản ghi Products đại diện thay vì chỉ dựa vào tổng số Products. Bộ mẫu cần thể hiện các kiểu lựa chọn khác nhau đang tồn tại trong catalog.
Nên kiểm tra:
- Products có nhiều biến thể hoặc nhiều nhóm tùy chọn nhất;
- Products có giá, hình ảnh, trọng lượng, SKU, barcode hoặc tồn kho riêng theo biến thể;
- Products có một số tổ hợp không hợp lệ hoặc không có sẵn;
- Products có trường nhập văn bản, tải tệp, số đo, nội dung khắc hoặc dữ liệu cá nhân hóa;
- bundle, kit, grouped products, Products đăng ký định kỳ hoặc Products sản xuất theo yêu cầu;
- Products kết nối với ERP, POS, WMS, marketplace, PIM hoặc hệ thống xử lý đơn hàng;
- Products có doanh thu cao và cho phép cấu hình, nơi một lỗi nhỏ khi chọn mua có thể tạo ra vấn đề cho hỗ trợ khách hàng hoặc xử lý đơn hàng.
Với từng mẫu, quá trình rà soát cần trả lời các câu hỏi cụ thể. Bản ghi nào đại diện cho phiên bản Products được bán riêng? Trường nào thuộc Products chính? Trường nào thuộc biến thể? Lựa chọn nào chỉ dùng để hiển thị thông tin? Lựa chọn nào ảnh hưởng đến giá, tồn kho, xử lý đơn hàng hoặc Orders? Hành vi nào phụ thuộc vào extension, app, các trường tùy chỉnh hoặc quy tắc trong theme?
Cần đối chiếu cả cách hoạt động trên cửa hàng với dữ liệu trong trang quản trị. Một bản ghi Products có thể hiển thị đúng tùy chọn nhưng dữ liệu thực tế lại nằm trong bảng của extension. Products khác có bản ghi biến thể rõ ràng nhưng dựa vào mã trong theme để đổi hình ảnh. Hai trường hợp này cần hai phương án xử lý khác nhau.
Khi nào cần phân tích sâu cấu trúc lựa chọn Products
Cấu trúc lựa chọn Products cần được phân tích sâu khi ý nghĩa kinh doanh không thể suy ra chỉ từ tiêu đề Products hoặc số lượng bản ghi.
Thường cần rà soát sâu khi:
- Nền tảng nguồn và Nền tảng đích dùng mô hình loại Products khác nhau;
- giới hạn biến thể hoặc giới hạn nhóm tùy chọn ảnh hưởng đến catalog;
- Products phụ thuộc vào công cụ tạo tùy chọn, trình cấu hình, extension hoặc trường do app quản lý;
- hệ thống bên ngoài dùng mã định danh ở cấp biến thể;
- bundle, kit, grouped products hoặc Products đăng ký định kỳ phải tiếp tục hoạt động đúng;
- các trường tùy chỉnh quyết định giá, xử lý đơn hàng, điều kiện mua hoặc cách diễn giải thông tin mặt hàng trong Orders;
- lựa chọn Products ảnh hưởng đến bộ lọc, tìm kiếm, swatches, hình ảnh hoặc quy tắc trưng bày.
Trong các trường hợp này, kế hoạch di chuyển Products tiêu chuẩn có thể chưa đủ. Trước hết cần xác định hành vi lựa chọn nào thuộc dữ liệu cốt lõi của nền tảng, hành vi nào do extension hoặc cấu trúc tùy chỉnh quản lý, và chức năng nào nên được xây dựng lại theo cách khác trên Nền tảng đích.
Khi Nền tảng đích không thể thể hiện hành vi lựa chọn quan trọng bằng các trường chuẩn tương ứng, yêu cầu có thể cần liên kết trường hoặc quan hệ dữ liệu ở mức nâng cao, biến đổi giá trị, triển khai thêm trên Nền tảng đích hoặc thiết kế phương án di chuyển riêng. Quyết định phải dựa trên thông tin đã xác nhận về mô hình nguồn, kết quả bán hàng cần đạt và cách biểu diễn trên Nền tảng đích.
Kết luận
Biến thể và hệ thống tùy chọn tạo nên quá trình khách hàng chọn đúng phiên bản Products để mua. Chúng kết nối lựa chọn của khách hàng với định danh SKU, giá, tồn kho, hình ảnh, xử lý đơn hàng, Orders, báo cáo và các hệ thống bên ngoài.
Một quá trình di chuyển đạt yêu cầu phải làm nhiều hơn việc giữ lại Products. Quá trình đó phải duy trì đúng ý nghĩa của từng lựa chọn dẫn đến một phiên bản Products cụ thể và các mối quan hệ giúp lựa chọn đó hiển thị rõ trên cửa hàng, đồng thời tiếp tục vận hành chính xác sau khi khách hàng hoàn tất mua hàng. Cách chuẩn bị an toàn nhất là phân tích các cấu trúc lựa chọn Products đại diện trước khi chốt phương án, đặc biệt khi biến thể, thuộc tính, tùy chọn tùy chỉnh, bundle và mã định danh bên ngoài có liên quan với nhau.
Câu hỏi thường gặp
Biến thể Products có giống tùy chọn Products không?
Biến thể Products và tùy chọn Products là hai khái niệm khác nhau. Tùy chọn thường là các nhóm lựa chọn mà khách hàng nhìn thấy, chẳng hạn kích thước hoặc màu sắc. Biến thể là phiên bản Products được bán riêng, được xác định từ các lựa chọn đó và thường mang SKU, giá, tồn kho, hình ảnh cùng thông tin xử lý đơn hàng riêng.
Mọi thuộc tính Products có nên trở thành biến thể không?
Không phải mọi thuộc tính Products đều nên trở thành biến thể. Thuộc tính thường dùng để mô tả, lọc, so sánh hoặc tổ chức Products. Chỉ nên tạo biến thể khi thuộc tính đó xác định một phiên bản Products được bán riêng và cần SKU, giá, tồn kho hoặc cách quản lý riêng.
Vì sao việc di chuyển biến thể có thể phức tạp dù catalog có ít Products?
Catalog nhỏ vẫn có thể chứa cách lựa chọn Products phức tạp. Tùy chọn tùy chỉnh, tổ hợp không hợp lệ, tồn kho riêng theo biến thể, bundle, trình cấu hình hoặc sự phụ thuộc vào SKU bên ngoài có thể tạo ra nhiều rủi ro hơn số lượng Products cho thấy.
Nên kiểm tra gì trước tiên trong catalog có nhiều biến thể?
Bắt đầu với Products bán chạy, Products có nhiều tổ hợp tùy chọn quan trọng nhất, Products có giá hoặc tồn kho riêng theo biến thể và Products kết nối với hệ thống bên ngoài. Các mẫu này cho thấy sự khác biệt cấu trúc nhanh hơn so với Products đơn giản.
Khi nào dữ liệu lựa chọn Products cần cách xử lý riêng?
Có thể cần cách xử lý riêng khi hành vi quan trọng được lưu trong extension, app, các trường tùy chỉnh, trình cấu hình, bundle hoặc hệ thống bên ngoài thay vì các trường của Products và biến thể tiêu chuẩn.