Thuộc tính Products và hệ thống lọc trên các nền tảng

Thuộc tính Products là các thông tin có cấu trúc giúp giải thích Products là gì, có thể được so sánh theo tiêu chí nào và khách hàng có thể thu hẹp một catalog lớn thành nhóm lựa chọn phù hợp ra sao. Tiêu đề Products có thể đủ với catalog nhỏ, nhưng cửa hàng lớn thường phụ thuộc vào các thuộc tính như chất liệu, màu sắc, kích thước, dung lượng, khả năng tương thích, điện áp, bề mặt hoàn thiện, thương hiệu, kiểu dáng, yêu cầu bảo quản, số lượng trong gói, chứng nhận, năm sản xuất hoặc mục đích sử dụng.

Hệ thống lọc biến những thông tin có cấu trúc đó thành cách khách hàng tìm Products phù hợp. Bộ lọc không chỉ là một thanh điều khiển hiển thị bên cạnh danh sách Products. Kết quả lọc còn phụ thuộc vào nơi lưu thông tin, việc các giá trị có được chuẩn hóa hay không, trường nào được phép dùng làm tiêu chí lọc, Categories nào cần bộ lọc nào và theme, công cụ tìm kiếm hoặc app có đọc các giá trị đó theo cùng một cách hay không.

Thách thức kỹ thuật là mỗi nền tảng thương mại điện tử tổ chức thuộc tính và bộ lọc khác nhau. Có nền tảng dùng thuộc tính Products gốc. Nền tảng khác có thể dựa vào tags, collections, metafields, trường trong hệ thống phân loại, tùy chọn Products, trường riêng theo Categories, dữ liệu bộ lọc do app quản lý hoặc quy tắc trong chỉ mục tìm kiếm. Vì vậy, cùng một đặc điểm kinh doanh có thể là trường so sánh ở cửa hàng này, tiêu chí lọc ở cửa hàng khác, tùy chọn biến thể ở nền tảng thứ ba và trường tùy chỉnh ở một hệ thống khác.

Thuộc tính giúp mô tả và phân loại Products như thế nào

Thuộc tính Products là đặc điểm có cấu trúc được gắn với một bản ghi Products, một dòng sản phẩm, biến thể, Categories hoặc hệ thống phân loại catalog. Thuộc tính giúp cửa hàng mô tả Products theo cách nhất quán để khách hàng, nhân viên, công cụ tìm kiếm, hệ thống báo cáo và các kênh bên ngoài có thể hiểu catalog mà không phải dựa hoàn toàn vào mô tả tự do.

Thuộc tính có thể phục vụ nhiều mục đích:

Một hệ thống thuộc tính tốt không chỉ là danh sách trường. Hệ thống đó còn xác định đặc điểm nào quan trọng, áp dụng cho nhóm Products nào, dùng kiểu dữ liệu gì, giá trị được đặt tên ra sao, có thể dùng lại hay không và cửa hàng có thể dùng dữ liệu đó để hỗ trợ khách hàng tìm Products hay không.

Một thuộc tính cần những thành phần dữ liệu nào

Dữ liệu thuộc tính thường chứa nhiều hơn nhãn hiển thị. Đằng sau một bộ lọc như Color: Black, nền tảng có thể lưu mã nội bộ, nhãn hiển thị, kiểu dữ liệu, mã giá trị, tên giá trị, phạm vi áp dụng, thứ tự sắp xếp, Categories liên quan, bản dịch và thiết lập cho phép lọc.

Một cấu trúc thuộc tính thường gồm:

Những chi tiết này quyết định thuộc tính có tiếp tục mang đúng ý nghĩa khi catalog mở rộng, khi khách hàng lọc Products, khi cửa hàng hỗ trợ nhiều ngôn ngữ hoặc khi dữ liệu Products được gửi sang các kênh bên ngoài hay không.

Kiểu dữ liệu đặc biệt quan trọng. Thuộc tính số như công suất, dung lượng lưu trữ hoặc kích thước màn hình không nên luôn được lưu dưới dạng văn bản. Văn bản có thể dễ đọc nhưng khó sắp xếp, so sánh, lọc theo khoảng, chuẩn hóa hoặc chuyển đổi đơn vị. Các giá trị 12, 12 in, 12 inches, 1 ft và 30.48 cm có thể mô tả cùng một đại lượng, nhưng nền tảng vẫn có thể coi chúng là các chuỗi không liên quan nếu dữ liệu chưa được chuẩn hóa.

Phân biệt thuộc tính với tùy chọn, biến thể, tags và các trường tùy chỉnh

Thuộc tính, tùy chọn, biến thể, tags và các trường tùy chỉnh có thể cùng xuất hiện trên trang Products nhưng không mang cùng ý nghĩa kỹ thuật.

Tùy chọn thường xác định những lựa chọn khách hàng cần thực hiện trên trang Products. Nếu lựa chọn tạo ra một phiên bản Products được bán riêng với SKU, giá, tồn kho, hình ảnh, barcode hoặc cách xử lý đơn hàng riêng, dữ liệu đó nên được lưu và quản lý trong cấu trúc biến thể hoặc cấu trúc tương đương. Thuộc tính thường dùng để mô tả hoặc phân loại Products, kể cả khi được dùng cho bộ lọc.

Tags thường là nhãn phân loại linh hoạt hơn. Chúng có thể dùng để nhóm Products, tạo collections, kích hoạt quy tắc trưng bày hoặc hỗ trợ bộ lọc đơn giản. Tuy nhiên, tags thường ít được kiểm soát hơn thuộc tính chính thức. Hệ thống tags có thể chứa giá trị trùng, cách viết không nhất quán, nhãn dùng cho quy trình nội bộ và nhiều mục đích kinh doanh lẫn trong cùng một trường. Tính linh hoạt này trở thành rủi ro khi tags được hiển thị trực tiếp thành bộ lọc cho khách hàng.

các trường tùy chỉnh, metafields hoặc trường của extension có thể lưu thông tin Products có cấu trúc ngoài mô hình thuộc tính chuẩn. Chúng có thể chứa dữ liệu tương thích, thông số kỹ thuật, nhãn, tài liệu tải xuống, thông tin bảo hành, giá trị dinh dưỡng, dữ liệu fitment hoặc mã định danh của các tích hợp. Một số các trường tùy chỉnh chỉ dùng để hiển thị. Trường khác có thể điều khiển bộ lọc, tìm kiếm, app, bảng so sánh hoặc feed bên ngoài.

Sự khác biệt kỹ thuật này rất quan trọng vì một giá trị có thể tồn tại nhưng không phục vụ đúng mục đích. Chất liệu nằm trong mô tả có thể hiển thị nhưng không dùng để lọc. Màu sắc lưu bằng tag có thể hỗ trợ collection đơn giản nhưng không liên kết với swatches. Kích thước lưu dưới dạng tùy chọn biến thể có thể hỗ trợ mua hàng nhưng không trở thành bộ lọc trên toàn Categories nếu nền tảng không lập chỉ mục giá trị tùy chọn. Metafield có thể chứa dữ liệu sạch nhưng vẫn không xuất hiện trong hệ thống lọc nếu chưa được cấu hình làm nguồn dữ liệu cho bộ lọc.

Nhóm thuộc tính và hệ thống phân loại theo từng Categories

Catalog lớn hiếm khi dùng cùng một danh sách thuộc tính cho mọi Products. Giày, laptop, chai rượu, phụ tùng ô tô và mỹ phẩm cần các trường mô tả khác nhau. Vì vậy, hệ thống thuộc tính thường phụ thuộc vào loại Products, nhóm thuộc tính, mẫu cấu trúc theo Categories hoặc hệ thống phân loại.

Nhóm thuộc tính xác định những trường cần có cho một dòng sản phẩm. Ngành thời trang có thể cần kích thước, màu sắc, chất liệu, kiểu dáng, chiều dài tay áo và hướng dẫn bảo quản. Thiết bị điện tử có thể cần kích thước màn hình, bộ nhớ, bộ xử lý, điện áp, kết nối, bảo hành và khả năng tương thích. Nội thất có thể cần chất liệu, bề mặt hoàn thiện, kích thước, tải trọng, loại phòng, yêu cầu lắp ráp và nhóm giao hàng.

Hệ thống phân loại quyết định Products được nhóm như thế nào và mỗi nhóm cần những thuộc tính nào. Marketplace và kênh quảng cáo thường áp dụng hệ thống phân loại riêng vì từng Categories yêu cầu bộ dữ liệu Products khác nhau. Feed Products có thể bị từ chối hoặc hoạt động kém nếu thiếu thuộc tính quan trọng, gắn sai nhóm hoặc lưu giá trị ở định dạng không được hỗ trợ.

Thuộc tính theo từng Categories đặc biệt quan trọng với bộ lọc. Cửa hàng không nên hiển thị bộ lọc chiều rộng lốp trong Categories mỹ phẩm, cũng không nên hiển thị loại da trong Categories điện tử. Hệ thống lọc tốt hiểu bối cảnh của từng Categories, chỉ đưa ra tiêu chí hỗ trợ quyết định mua và loại bỏ trường không liên quan để tránh làm danh sách bộ lọc rối hơn.

Khi Nền tảng nguồn và Nền tảng đích dùng hệ thống phân loại khác nhau, thuộc tính có thể cần được gán lại thay vì chuyển từng trường theo cách tương ứng trực tiếp. Trường dùng toàn catalog ở Nền tảng nguồn có thể trở thành trường riêng theo Categories ở Nền tảng đích. Nhóm thuộc tính tùy chỉnh có thể cần chuyển thành loại Products, metafield ở cấp collection, trường trong feed marketplace hoặc tiêu chí của chỉ mục tìm kiếm tùy theo kiến trúc đích.

Bộ lọc và tìm kiếm nhiều chiều sử dụng dữ liệu thuộc tính ra sao

Bộ lọc thu hẹp danh sách Products theo giá trị khách hàng chọn. Tìm kiếm nhiều chiều tạo ra các tiêu chí khám phá dựa trên tập Products đang hiển thị, thường kèm số lượng kết quả và các lựa chọn thu hẹp tiếp theo. Cả hai đều phụ thuộc vào dữ liệu có cấu trúc, nhưng cách vận hành có thể khác nhau đáng kể giữa các nền tảng.

Để bộ lọc hoạt động đúng, bốn phần sau phải phối hợp với nhau:

Thuộc tính có thể đã được lưu đúng trên Nền tảng đích nhưng trải nghiệm khách hàng vẫn không hoạt động đúng. Giá trị có thể đã có trong giao diện quản trị nhưng chưa được lập chỉ mục. Giá trị có thể được lập chỉ mục nhưng hiển thị thành nhiều nhãn trùng nghĩa. Bộ lọc có thể xuất hiện nhưng trả về kết quả thiếu vì một số Products lưu giá trị ở cấp biến thể còn Products khác lưu ở cấp bản ghi chính.

Tìm kiếm nhiều chiều phức tạp hơn vì chỉ mục tìm kiếm không nhất thiết dùng cùng mô hình với cơ sở dữ liệu Products. Nhà cung cấp tìm kiếm có thể gộp trường của Products, hợp nhất giá trị biến thể, tách từ trong văn bản, bỏ qua kiểu trường không hỗ trợ, giới hạn số giá trị hoặc yêu cầu cấu hình rõ ràng trước khi một trường được dùng để thu hẹp kết quả. Với cửa hàng phụ thuộc nhiều vào extension, cách bộ lọc hoạt động mà khách hàng nhìn thấy có thể do app tìm kiếm quản lý chứ không phải nền tảng cốt lõi.

Các nền tảng tổ chức dữ liệu khám phá Products theo những cách khác nhau

Mỗi nền tảng thương mại điện tử cung cấp dữ liệu dùng để tìm Products qua các cấu trúc riêng.

Một số nền tảng SaaS dùng tùy chọn Products, tags, loại Products, collections và metafields làm cấu trúc chính cho việc khám phá Products. Bộ lọc có thể phụ thuộc vào thiết lập tìm kiếm gốc, khả năng của theme, cấu hình tìm kiếm hoặc nguồn bộ lọc do app quản lý. Mô hình này hiệu quả với catalog tiêu chuẩn nhưng cần cấu hình cẩn thận nếu cửa hàng dựa vào nhiều thông số kỹ thuật, trường tương thích hoặc bộ lọc riêng theo Categories.

Một số nền tảng Open Source dùng thuộc tính chính thức, nhóm thuộc tính, layered navigation, thuộc tính dùng cho cấu hình và chỉ mục bộ lọc do extension quản lý. Các hệ thống này hỗ trợ dữ liệu Products phong phú nhưng đòi hỏi quy tắc quản trị thuộc tính rõ ràng hơn. Thuộc tính trùng, bộ giá trị không nhất quán, phạm vi áp dụng sai và mã thuộc tính bị dùng cho nhiều mục đích có thể làm cả trang quản trị lẫn quá trình tìm Products trở nên khó sử dụng.

Kiến trúc doanh nghiệp và composable có thể tách thông tin Products khỏi hệ thống tìm kiếm trên cửa hàng. PIM quản lý định nghĩa thuộc tính, nền tảng thương mại quản lý các phiên bản Products được bán riêng, công cụ tìm kiếm quản lý tiêu chí lọc, CMS quản lý các khối nội dung và connector marketplace quản lý trường riêng theo kênh. Trong môi trường này, di chuyển thuộc tính không chỉ là công việc của nền tảng thương mại mà còn là quyết định về kiến trúc dữ liệu và hệ thống quản lý chính.

Cửa hàng tập trung vào marketplace còn phải đáp ứng thêm yêu cầu riêng của từng kênh. Amazon, Google, eBay, Walmart và các kênh khác có thể yêu cầu thuộc tính theo Categories, nhãn feed, mã định danh Products, trường tuân thủ và giá trị chuẩn hóa không khớp hoàn toàn với bộ lọc nội bộ của cửa hàng. Một giá trị có thể cần thiết để Products đủ điều kiện xuất hiện trên marketplace dù khách hàng không bao giờ thấy giá trị đó trên cửa hàng chính.

Những trường hợp dễ bị bỏ sót

Vấn đề về thuộc tính và bộ lọc thường nằm trong những chi tiết không xuất hiện khi chỉ xuất dữ liệu Products theo cách đơn giản.

Một trường hợp thường gặp là cùng một giá trị có thể được lưu trên Products chính hoặc trên từng biến thể. Màu sắc có thể là tùy chọn biến thể với thời trang, thuộc tính Products với nội thất và tiêu chí lọc cho cả hai. Nếu Nền tảng đích chỉ lập chỉ mục thuộc tính ở cấp Products, giá trị ở cấp biến thể có thể không tạo ra bộ lọc mong đợi. Nếu Nền tảng đích gộp toàn bộ giá trị biến thể lên bản ghi Products chính, khách hàng có thể lọc được Products có màu đã chọn nhưng vẫn phải tự tìm đúng biến thể để mua.

Một trường hợp khác là danh sách giá trị được kiểm soát. Danh sách chuẩn giúp bộ lọc rõ ràng. Nếu thiếu kiểm soát, cùng một màu có thể xuất hiện dưới các tên Navy, Navy Blue, navy, Dark Blue và Midnight. Một số nền tảng coi đây là các giá trị khác nhau. Nền tảng khác chỉ có thể gộp chúng qua cấu hình thủ công hoặc quy tắc tìm kiếm. Quy tắc đặt và quản lý giá trị càng rõ ràng, bộ lọc càng hoạt động nhất quán và dễ dự đoán.

Thuộc tính cho phép nhiều lựa chọn cũng có thể gây vấn đề. Products có thể tương thích với nhiều mẫu thiết bị, thành phần, loại phòng, kích thước hoặc mục đích sử dụng. Một số nền tảng lưu giá trị thành mảng. Nền tảng khác dùng chuỗi phân tách bằng dấu phẩy, tags, bảng quan hệ, dữ liệu tuần tự hóa hoặc bản ghi do app quản lý. Mô hình lưu trữ ảnh hưởng đến bộ lọc, tìm kiếm, feed và báo cáo.

Bản địa hóa và phạm vi thị trường làm cấu trúc phức tạp hơn. Nhãn giá trị có thể được dịch trong khi mã giá trị nội bộ vẫn giữ nguyên. Ở mô hình quản lý lỏng lẻo hơn, mỗi ngôn ngữ có thể tạo một giá trị văn bản riêng. Nếu Red, Rouge và Rot bị coi là ba giá trị không liên quan, bộ lọc đa ngôn ngữ sẽ bị phân mảnh. Dữ liệu Products riêng theo thị trường cũng có thể quyết định bộ lọc nào được hiển thị ở từng khu vực.

Thuộc tính ẩn hoặc chỉ dùng nội bộ trong giao diện quản trị cần được xử lý thận trọng. Cửa hàng có thể dùng cờ nội bộ cho hoạt động mua hàng, nhóm nhà cung cấp, nhóm biên lợi nhuận, quy trình trưng bày, xử lý hàng nguy hiểm hoặc loại trừ kênh. Nếu các trường này bị đưa ra thành bộ lọc, khách hàng có thể bối rối hoặc nhìn thấy thông tin chỉ nên dùng nội bộ.

Điều gì có thể thay đổi khi dữ liệu thuộc tính được xây dựng lại

Khi thuộc tính được chuyển sang mô hình khác, giữ nguyên bản ghi không đồng nghĩa với giữ nguyên hành vi. Cửa hàng cần duy trì chức năng hữu ích của từng trường, không chỉ văn bản của giá trị.

Những thay đổi này có thể chấp nhận được nếu vẫn giữ đúng ý nghĩa kinh doanh. Cửa hàng có thể chủ động chuyển tags lộn xộn thành thuộc tính có cấu trúc để bộ lọc rõ ràng hơn. Thuộc tính hiếm khi dùng có thể được chuyển thành metafield ẩn. Đơn vị có thể được chuẩn hóa trước khi di chuyển để bộ lọc theo khoảng hoạt động tốt hơn trên Nền tảng đích.

Rủi ro xuất hiện khi sự thay đổi xảy ra ngoài dự kiến. Giá trị đã di chuyển có thể hiển thị nhưng không tìm kiếm được. Bộ lọc có thể xuất hiện nhưng trả về kết quả thiếu. Trường kỹ thuật có thể được giữ lại nhưng không còn kết nối với feed marketplace. Products có thể giữ văn bản thuộc tính nhưng mất quan hệ giữa nhóm thuộc tính, Categories và cách khách hàng tìm Products.

Chất lượng thuộc tính ảnh hưởng trực tiếp đến hành trình tìm Products

Chất lượng thuộc tính thể hiện trực tiếp qua cách khách hàng tìm Products. Catalog có thể chứa đầy đủ dữ liệu, nhưng nếu thuộc tính được tổ chức thiếu nhất quán, kết quả lọc vẫn có thể bỏ sót Products phù hợp, đưa vào quá nhiều lựa chọn không liên quan hoặc khiến khách hàng khó tin vào kết quả.

Giá trị trùng làm kết quả bị chia nhỏ. Nếu khách hàng lọc theo Black, Products gắn black, Blk hoặc Matte Black có thể bị loại khỏi kết quả dù vẫn thuộc nhóm cần tìm.

Đơn vị không nhất quán làm việc so sánh kém hữu ích. Bộ lọc dung lượng hoặc kích thước không giúp ích nếu một số Products dùng lít, số khác dùng mililit và phần còn lại dùng mô tả tự do.

Trường chứa quá nhiều loại thông tin tạo ra bộ lọc khó hiểu. Trường Material / Finish có thể chứa Oak - Natural, Oak / Walnut, Powder-coated steel và Leather, black. Khách hàng có thể cần hai tiêu chí riêng cho chất liệu và bề mặt hoàn thiện, trong khi trường nguồn đang gộp cả hai.

Khi dữ liệu chỉ được điền cho một phần Products, nhiều Products phù hợp có thể bị loại khỏi kết quả. Nếu chỉ một số Products trong Categories có giá trị cần thiết, kết quả lọc có vẻ đầy đủ nhưng thực tế lại loại bỏ nhiều Products phù hợp. Rủi ro này đặc biệt lớn với catalog kỹ thuật, tương thích, phụ tùng thay thế, B2B hoặc Products chịu quy định.

Bộ lọc không liên quan làm khách hàng khó tin vào kết quả. Hiển thị mọi thuộc tính toàn catalog trong mọi Categories có thể tạo danh sách dài mà khách hàng bỏ qua. Bộ lọc tốt cần có chọn lọc và phản ánh đúng những yếu tố ảnh hưởng đến quyết định trong từng Categories.

Nên kiểm tra những Categories và thuộc tính nào

Việc rà soát thuộc tính và bộ lọc nên dựa trên một số Categories đại diện, không chỉ tổng số Products.

Mẫu kiểm tra nên gồm:

• Categories có traffic cao, nơi bộ lọc ảnh hưởng trực tiếp đến khả năng khách hàng tìm và mua Products;
• dòng sản phẩm có nhiều thông số kỹ thuật;
• Categories mà khách hàng thường lọc theo khả năng tương thích, fitment, dung lượng, kích thước, chất liệu hoặc mục đích sử dụng;
• thuộc tính có nhiều giá trị hoặc cách viết không nhất quán;
• giá trị đáng lẽ là số nhưng đang được lưu thành văn bản;
• bộ lọc do app, nhà cung cấp tìm kiếm, module hoặc mã tùy chỉnh quản lý;
• giá trị đa ngôn ngữ hoặc theo từng thị trường;
• tags nội bộ hoặc trường ẩn không nên trở thành bộ lọc cho khách hàng;
• thuộc tính riêng theo marketplace hoặc kênh ảnh hưởng đến khả năng feed được chấp nhận.

Với mỗi mẫu, quá trình rà soát cần trả lời rõ: Trường nào chỉ dùng để mô tả? Trường nào cần tìm kiếm được? Trường nào nên trở thành bộ lọc? Trường nào phải giữ ẩn? Giá trị nào cần chuẩn hóa? Trường nào chỉ áp dụng cho một số Categories? Trường nào thuộc Products, biến thể, Categories hoặc hệ thống bên ngoài? Hành vi lọc nào phụ thuộc vào theme, app, chỉ mục tìm kiếm hoặc extension?

Cách kiểm tra tốt nhất là đối chiếu ba góc nhìn: dữ liệu trong giao diện quản trị, cách cửa hàng sử dụng dữ liệu và dữ liệu gửi ra bên ngoài. Giao diện quản trị cho biết giá trị được lưu ở đâu. Cửa hàng cho biết khách hàng có thể sử dụng giá trị đó như thế nào. Dữ liệu đầu ra cho biết marketplace, quảng cáo, PIM, công cụ tìm kiếm hoặc hệ thống báo cáo có tiếp tục nhận đúng thông tin hay không.

Khi nào cần phân tích sâu thuộc tính và bộ lọc

Dữ liệu thuộc tính và bộ lọc cần được phân tích sâu khi cửa hàng phụ thuộc vào dữ liệu có cấu trúc để khách hàng tìm Products, so sánh thông số hoặc đưa ra quyết định khác nhau theo từng Categories.

Thường cần rà soát sâu khi:

• bộ lọc quan trọng phụ thuộc vào các trường tùy chỉnh, metafields, app, module hoặc nhà cung cấp tìm kiếm;
• Nền tảng nguồn và Nền tảng đích dùng mô hình nhóm thuộc tính hoặc hệ thống phân loại khác nhau;
• giá trị ở cấp Products và cấp biến thể bị trộn lẫn;
• thuộc tính phải hỗ trợ feed marketplace, dữ liệu PIM hoặc chỉ mục tìm kiếm bên ngoài;
• giá trị cần chuẩn hóa, tách, gộp, chuyển đổi đơn vị hoặc làm sạch danh sách giá trị;
• cách bộ lọc hoạt động phụ thuộc vào Categories, nhóm Customers, thị trường, ngôn ngữ hoặc theme;
• thông số kỹ thuật có giá trị thương mại cao và không thể rút gọn thành trường văn bản đơn giản.

Khi cách liên kết thuộc tính ảnh hưởng đến việc khách hàng tìm Products, yêu cầu có thể cần xác định trường hoặc quan hệ dữ liệu đích ở mức nâng cao, chuẩn hóa giá trị, cấu hình bộ lọc trên Nền tảng đích hoặc thiết kế phương án di chuyển riêng. các trường tùy chỉnh và bộ lọc do extension quản lý chỉ nên được xử lý sau khi đã hiểu rõ mô hình thuộc tính và hành vi khách hàng cần có trên cửa hàng.

Kết luận

Thuộc tính Products và hệ thống lọc tạo nên kiến trúc dữ liệu phía sau quá trình khách hàng tìm Products. Chúng kết nối đặc điểm Products với cách duyệt Categories, tìm kiếm nhiều chiều, so sánh, trưng bày, feed bên ngoài và quyết định mua hàng.

Một quá trình di chuyển đạt yêu cầu phải làm nhiều hơn việc chuyển các giá trị thuộc tính. Quá trình đó cần duy trì đúng ý nghĩa, cấp sở hữu, kiểu dữ liệu, mức độ phù hợp với Categories, tính nhất quán của giá trị và cách hoạt động trên cửa hàng. Cách chuẩn bị an toàn nhất là phân tích mô hình thuộc tính trước khi chốt phương án, đặc biệt khi bộ lọc, tìm kiếm, các trường tùy chỉnh, tags, hệ thống phân loại hoặc feed bên ngoài quyết định cách khách hàng tìm và đánh giá Products.

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

Thuộc tính Products có giống bộ lọc Products không?

Thuộc tính Products và bộ lọc Products là hai khái niệm khác nhau. Thuộc tính là đặc điểm có cấu trúc của Products. Bộ lọc là công cụ giúp khách hàng thu hẹp kết quả và có thể sử dụng thuộc tính, tags, tùy chọn, metafields, trường trong chỉ mục tìm kiếm hoặc dữ liệu do app quản lý.

Mọi thuộc tính Products có nên trở thành bộ lọc trên cửa hàng không?

Không phải mọi thuộc tính Products đều nên trở thành bộ lọc trên cửa hàng. Chỉ những thuộc tính giúp khách hàng thu hẹp lựa chọn theo đúng bối cảnh Categories mới nên trở thành bộ lọc. Trường nội bộ, giá trị chỉ có ở một phần Products, tags nhiều nhiễu và thuộc tính toàn catalog không liên quan có thể làm trải nghiệm mua hàng kém rõ ràng.

Vì sao bộ lọc có thể hỏng dù dữ liệu thuộc tính vẫn còn?

Một giá trị xuất hiện trong giao diện quản trị chưa chắc đã dùng được cho bộ lọc. Giá trị đó có thể chưa được lập chỉ mục, chưa được cấu hình để cho phép lọc, nằm sai cấp sở hữu, bị trùng dưới nhiều nhãn hoặc thuộc theme, app hay công cụ tìm kiếm không đọc trường dữ liệu mới.

Thuộc tính khác tags như thế nào?

Thuộc tính thường có cấu trúc và quy tắc kiểm soát rõ hơn. Tags là nhãn linh hoạt dùng để nhóm Products, hỗ trợ quy trình, trưng bày hoặc tạo bộ lọc đơn giản. Tags dễ trở nên lộn xộn khi trộn mục đích nội bộ với ý nghĩa dành cho khách hàng.

Khi nào dữ liệu thuộc tính cần cách xử lý riêng?

Dự án có thể cần cách xử lý riêng khi thuộc tính không nằm trong cấu trúc tiêu chuẩn của nền tảng, chẳng hạn các trường tùy chỉnh, bảng extension, bản ghi do app quản lý, chỉ mục tìm kiếm hoặc cấu trúc PIM. Điều tương tự áp dụng khi giá trị phải được chuẩn hóa, tách, gộp hay biến đổi theo Categories để hỗ trợ đúng cách khách hàng tìm và thu hẹp lựa chọn Products trên Nền tảng đích.