Cấu trúc catalog là kiến trúc dữ liệu quyết định Products được tổ chức như thế nào để khách hàng duyệt, cửa hàng trưng bày, menu dẫn đường, landing page giới thiệu nội dung và hệ thống hỗ trợ khách hàng tìm Products. Một bản ghi Products có thể được lưu đầy đủ và chính xác trong giao diện quản trị nhưng khách hàng vẫn khó tìm thấy nếu quan hệ với Categories, thành viên collection, đường dẫn menu, vị trí sắp xếp hoặc bối cảnh landing page không được thể hiện đúng.
Catalog thương mại điện tử không phải lúc nào cũng là một cây Categories đơn giản. Nền tảng này có thể dùng Categories lồng nhau với quan hệ cha con. Nền tảng khác có thể dùng collections tạo thủ công, collections tự động, tags Products, trường taxonomy, liên kết menu, loại Products, landing page từ page builder hoặc quy tắc trưng bày dựa trên tìm kiếm. Hai cửa hàng có thể tạo trải nghiệm tương tự cho khách hàng nhưng dùng mô hình dữ liệu hoàn toàn khác ở phía sau.
Khi rà soát catalog về mặt kỹ thuật, cần tách từng thành phần để kiểm tra. Phạm vi gồm đối tượng dùng để nhóm Products, quan hệ giữa Products và nhóm, đường dẫn khách hàng dùng để duyệt catalog, nội dung gắn với trang Categories hoặc collection, quy tắc đưa Products vào nhóm và cách sắp xếp Products trên trang.
Cấu trúc catalog tạo ra hành trình duyệt Products như thế nào
Cấu trúc catalog sắp xếp Products thành những hành trình duyệt có ý nghĩa. Nhờ đó, khách hàng có thể đi từ nhu cầu chung đến nhóm Products cụ thể, chẳng hạn Women > Shoes > Running Shoes, Electronics > Laptops > Gaming Laptops hoặc Replacement Parts > Refrigerator Parts > Water Filters.
Cấu trúc catalog thường hỗ trợ nhiều hơn menu điều hướng và có thể ảnh hưởng đến landing page của Categories, breadcrumb, liên kết nội bộ, trang đích SEO, Products nổi bật, quy tắc trưng bày, khả năng tìm Products, phân loại trên marketplace, báo cáo và cách nhân viên duy trì catalog.
Một catalog có thể gồm nhiều đối tượng dữ liệu và thành phần hiển thị:
| Thành phần catalog | Nội dung được đại diện | Hoạt động bị ảnh hưởng |
|---|---|---|
| Categories hoặc collection | Nhóm Products dùng cho duyệt catalog hoặc trưng bày | Trang Categories, danh sách Products, bộ lọc và quá trình tìm Products |
| Hệ thống phân cấp cha con | Quan hệ giữa nhóm rộng và nhóm chi tiết hơn | Độ sâu menu, breadcrumb, hành trình duyệt và cấu trúc URL |
| Quan hệ gán Products | Liên kết giữa Products với Categories hoặc collection | Khả năng Products xuất hiện trong trang duyệt |
| Mục menu | Liên kết điều hướng đến Categories, collection, trang nội dung hoặc URL bên ngoài | Cách khách hàng đi đến các trang catalog |
| Đường dẫn breadcrumb | Hành trình hoặc vị trí phân cấp được hiển thị | Khả năng định hướng, liên kết nội bộ và mức độ rõ ràng khi điều hướng |
| Nội dung Categories | Văn bản, hình ảnh, banner, metadata, khối nội dung hoặc nội dung landing page | SEO, trưng bày và khả năng giải thích nhóm Products |
| Quy tắc sắp xếp và hiển thị | Thứ tự thủ công, cách sắp xếp mặc định, vị trí nổi bật hoặc xếp hạng tự động | Products nào được khách hàng nhìn thấy trước |
| Quy tắc đưa Products vào nhóm | Điều kiện tự động thêm Products | Collections tự động, Categories thông minh, nhóm theo mùa và công việc duy trì catalog |
Các thành phần này có thể được kết nối chặt trong một nền tảng nhưng tách rời ở nền tảng khác. Đây là lý do không thể đánh giá kết quả di chuyển catalog chỉ bằng số lượng Categories.
Một nhóm catalog được tạo từ những bản ghi và mối quan hệ nào
Một bản ghi Categories, collection hoặc nhóm catalog thường có bản ghi riêng. Bản ghi đó có thể lưu mã nội bộ, tên, slug, tham chiếu đến nhóm cha, đường dẫn, trạng thái, thứ tự sắp xếp, mô tả, hình ảnh, trường SEO, thiết lập hiển thị, quy tắc gán Products và cờ kiểm soát khả năng xuất hiện trên cửa hàng.
Một cấu trúc nhóm catalog thường gồm:
| Trường dữ liệu | Chức năng thường gặp | Lý do cần quan tâm |
|---|---|---|
| Mã nội bộ | Định danh ổn định trong hệ thống | Giữ quan hệ gán Products và các tham chiếu được kết nối |
| Tên | Nhãn dùng trong giao diện quản trị hoặc hiển thị cho khách hàng | Ảnh hưởng đến giao diện, menu và khả năng nhân viên nhận diện nhóm |
| Slug hoặc handle | Định danh dùng cho URL | Ảnh hưởng đến URL trang và tham chiếu từ menu hoặc liên kết |
| Mã nhóm cha | Xác định Categories cha hoặc nhóm cấp cao hơn | Tạo hệ thống phân cấp và độ sâu khi duyệt |
| Đường dẫn hoặc cấp | Lưu vị trí đầy đủ trong hệ thống phân cấp | Hỗ trợ breadcrumb, sắp xếp và menu lồng nhau |
| Trạng thái hoặc khả năng hiển thị | Bật, tắt, ẩn hoặc xuất bản nhóm | Quyết định khách hàng có thể truy cập trang hay không |
| Vị trí sắp xếp | Kiểm soát thứ tự nhóm hoặc thứ tự Products | Ảnh hưởng đến menu và ưu tiên trưng bày |
| Mô tả và nội dung | Giải thích Categories hoặc cung cấp nội dung landing page | Hỗ trợ SEO, nhu cầu mua hàng và bối cảnh cho khách hàng |
| Hình ảnh hoặc banner | Đại diện trực quan cho nhóm | Ảnh hưởng đến lưới Categories và thiết kế landing page |
| Tiêu đề và mô tả SEO | Metadata hiển thị trong tìm kiếm | Hỗ trợ cách trang xuất hiện trên công cụ tìm kiếm |
| Quan hệ gán Products | Liên kết Products với nhóm | Quyết định Products nào xuất hiện trong danh sách |
| Quy tắc đưa vào nhóm | Tự động chọn Products theo điều kiện | Vận hành smart collections hoặc Categories động |
| Tham chiếu menu | Kết nối nhóm với hệ thống điều hướng | Quyết định khách hàng có thể đi đến trang theo cách tự nhiên hay không |
Quan hệ gán Products thường được lưu tách khỏi bản ghi nhóm. Quan hệ nhiều nhiều cho phép một bản ghi Products thuộc nhiều Categories hoặc collections. Mô hình giới hạn mỗi Products ở một danh mục duy nhất có thể yêu cầu xác định Categories chính. Mô hình dựa trên quy tắc có thể không lưu từng quan hệ trực tiếp mà tự đưa Products vào nhóm theo loại Products, tag, nhà cung cấp, thương hiệu, thuộc tính, giá, tồn kho hoặc ngày phát hành.
Cần phân biệt quan hệ được lưu trực tiếp với quan hệ được tính từ quy tắc. Categories tĩnh chứa liên kết Products rõ ràng. Collection động được tạo lại từ điều kiện. Categories dựa trên tìm kiếm phụ thuộc vào chỉ mục tìm kiếm. Landing page do extension quản lý có thể hiển thị Products thông qua block, widget, module hoặc lệnh gọi API thay vì quan hệ Categories gốc.
Categories, collections và hệ thống phân loại không phải lúc nào cũng cùng một mô hình
Các nền tảng tổ chức catalog rất khác nhau.
Một số nền tảng dùng cây Categories làm cấu trúc chính. Categories cha chứa Categories con, Categories con chứa các cấp sâu hơn và Products được gán vào một hoặc nhiều nút. Mô hình này thường gặp ở cửa hàng có catalog lớn, phụ tùng thay thế, Products B2B, Products kỹ thuật hoặc menu theo nhiều cấp. Hệ thống phân cấp rõ ràng nhưng đòi hỏi kiểm soát chặt độ sâu, tên nhóm, quan hệ cha con và cách gán Products.
Nền tảng khác tập trung vào collections. Collection có thể trông giống trang Categories trên cửa hàng nhưng được tạo thủ công, tự động, dựa trên tags, loại Products hoặc điều kiện. Collections linh hoạt cho việc trưng bày mà không bắt buộc một cây phân cấp cứng. Đổi lại, quan hệ cha con, menu và breadcrumb có thể cần cấu hình riêng.
Ngoài Categories và collections, catalog còn có thể dùng một hệ thống phân loại riêng để kiểm soát cách nhóm Products và những thuộc tính cần có cho từng nhóm. Hệ thống này có thể thuộc nền tảng, marketplace, PIM hoặc được duy trì riêng cho feed và quảng cáo. Phân loại Products không nhất thiết trùng với điều hướng trên cửa hàng. Products có thể được xếp vào một nhóm để khách hàng duyệt nhưng dùng nhóm khác cho Google Shopping, feed marketplace, hoạt động mua hàng hoặc báo cáo.
Cùng một khái niệm kinh doanh có thể được thể hiện theo nhiều cách:
| Khái niệm kinh doanh | Cách nền tảng có thể biểu diễn |
|---|---|
| Giày chạy bộ | Categories con, collection, smart collection, loại Products, nhóm tags, nhóm trong hệ thống phân loại hoặc landing page |
| Products thanh lý | Collection thủ công, collection tự động, nhóm theo quy tắc giá, trang dựa trên tags hoặc chiến dịch trưng bày |
| Lõi lọc thay thế | Đường dẫn Categories sâu, hệ thống phân loại theo khả năng tương thích, kết quả tìm kiếm nhiều chiều hoặc dòng sản phẩm do PIM quản lý |
| Products mới | Collection tự động theo ngày xuất bản, tags, ngày phát hành hoặc quy tắc trưng bày |
| Trang thương hiệu | Categories, collection, trang nhà cung cấp, landing page, kết quả tìm kiếm hoặc trang do app tạo |
Quá trình di chuyển có thể giữ nguyên nhãn nhưng thay đổi cách tổ chức dữ liệu và hành vi của nhóm. Điều đó có thể chấp nhận được nếu cách biểu diễn mới vẫn hỗ trợ cùng hành trình duyệt. Rủi ro xuất hiện khi cây Categories được chuyển thành collections không còn quan hệ phân cấp, smart collection trở thành nhóm tĩnh hoặc landing page của Categories chỉ còn danh sách Products đơn giản.
Navigation, menu và breadcrumb cần được kiểm tra như các cấu trúc riêng
Một nhóm catalog có thể tồn tại mà không xuất hiện trong menu cửa hàng. Menu có thể liên kết đến trang không phải Categories gốc. Breadcrumb có thể được tạo từ hệ thống phân cấp, đường dẫn menu, URL, quan hệ gán Products, quy tắc theme hoặc app.
Sự tách biệt này quan trọng vì khách hàng trải nghiệm catalog qua cách điều hướng, không phải qua bản ghi trong cơ sở dữ liệu. Categories có thể được di chuyển đúng dưới dạng bản ghi nhưng đường dẫn từng đưa khách hàng đến trang đó vẫn có thể bị mất.
Menu thường có cấu trúc dữ liệu riêng. Một mục menu có thể gồm nhãn, đích liên kết, mục menu cha, vị trí, thiết lập hiển thị, phạm vi thị trường hoặc ngôn ngữ, biểu tượng, hình ảnh, badge, bố cục mega menu và tham chiếu đến custom blocks. Mega menu còn có thể chứa liên kết Categories, Products nổi bật, hình ảnh, khối quảng bá hoặc submenu được sắp xếp thủ công.
Breadcrumb cũng được tạo khác nhau giữa các nền tảng. Có nền tảng dựa vào cây Categories. Nền tảng khác dùng đường dẫn menu, collection chính của Products, URL hoặc quy tắc theme. Products thuộc nhiều Categories có thể cần một đường dẫn chính để hiển thị breadcrumb. Nếu không có quan hệ ưu tiên, breadcrumb dễ thiếu nhất quán hoặc dẫn sai bối cảnh.
Khi lập kế hoạch cho catalog, cần kiểm tra riêng từng thành phần:
| Thành phần cần kiểm tra | Câu hỏi kỹ thuật cần trả lời |
|---|---|
| Nhóm catalog | Categories, collection hoặc nhóm trong hệ thống phân loại có tồn tại không? |
| Quan hệ Products | Products có được gắn với đúng nhóm không? |
| Điều hướng | Khách hàng có đi đến nhóm qua đúng đường dẫn menu không? |
| Breadcrumb | Cửa hàng có hiển thị đúng hành trình và bối cảnh không? |
| Landing page | Trang nhóm có giữ đúng nội dung và cách trưng bày Products không? |
Catalog chỉ hoạt động đúng khi cả năm thành phần phối hợp với nhau.
Products có thể xuất hiện ở nhiều vị trí trong catalog
Quan hệ gán Products quyết định Products xuất hiện ở đâu. Với catalog đơn giản, một bản ghi Products có thể chỉ thuộc duy nhất một danh mục. Trong phần lớn cửa hàng trưởng thành, Products xuất hiện ở nhiều bối cảnh: thương hiệu, ngành hàng, nhóm giảm giá, collection theo mùa, nhóm tương thích, đường dẫn phụ tùng thay thế, hướng dẫn quà tặng, bundle hoặc trang chiến dịch.
Khả năng xuất hiện ở nhiều vị trí phụ thuộc vào nền tảng. Có nền tảng cho phép Products thuộc không giới hạn Categories. Nền tảng khác dùng collections, tags, loại Products, trường nhà cung cấp, kênh bán hàng hoặc các trường tùy chỉnh. Một số hỗ trợ Categories chính cho canonical path và breadcrumb. Nền tảng khác coi mọi quan hệ nhóm là ngang nhau.
Sự khác biệt này ảnh hưởng đến nhiều hoạt động:
| Cách gán Products | Ảnh hưởng có thể xảy ra |
|---|---|
| Products thuộc nhiều Categories | Products xuất hiện trong nhiều hành trình duyệt, nhưng canonical path và breadcrumb có thể cần quy tắc riêng |
| Products được gán vào Categories chính | Hệ thống phân cấp rõ hơn nhưng số bối cảnh duyệt bị hạn chế nếu không có quan hệ phụ |
| Products được gán bằng tags hoặc quy tắc | Dễ duy trì hơn nhưng kết quả phụ thuộc vào chất lượng tags và độ chính xác của điều kiện |
| Products xuất hiện nhờ tìm kiếm hoặc quy tắc của app | Linh hoạt khi hiển thị nhưng dữ liệu Categories gốc có thể không đủ để tái tạo hành vi |
| Products bị ẩn trên một kênh nhưng hiển thị trên kênh khác | Catalog của cửa hàng, marketplace, B2B và từng khu vực có thể khác nhau |
Products có doanh thu cao vẫn có thể mất giá trị thương mại dù bản ghi được di chuyển chính xác nếu Products đó biến mất khỏi một hành trình duyệt quan trọng. Kiểm tra tổng số Products không phát hiện được vấn đề này nếu mẫu xác thực không bao gồm Categories tạo doanh thu cao và Products xuất hiện ở nhiều nhóm.
Phân biệt nhóm tĩnh, nhóm động và smart collections
Nhóm catalog có thể là tĩnh hoặc động. Nhóm tĩnh lưu quan hệ Products cụ thể. Nhóm động tự đưa Products vào khi Products đáp ứng điều kiện.
Điều kiện của nhóm động có thể dựa trên:
- tags Products;
- loại Products;
- nhà cung cấp hoặc thương hiệu;
- giá hoặc trạng thái giảm giá;
- tình trạng còn hàng;
- ngày xuất bản hoặc ngày phát hành;
- giá trị thuộc tính;
- giá trị biến thể;
- nhóm Customers hoặc thị trường;
- metafields hoặc các trường tùy chỉnh của Products;
- quy tắc do app quản lý;
- điều kiện trong chỉ mục tìm kiếm.
Smart collections và Categories tự động giúp giảm công việc duy trì thủ công nhưng tạo thêm phụ thuộc kỹ thuật. Nhóm không chỉ là tên Categories. Nhóm còn gồm bộ điều kiện và mô hình dữ liệu Products phải tiếp tục đáp ứng những điều kiện đó.
Collection động như Summer Dresses Under $100 có thể phụ thuộc vào loại Products, tag mùa, giới tính, Categories, giá, tồn kho và trạng thái xuất bản. Nếu một trường đổi mô hình trên Nền tảng đích, collection có thể thiếu Products hoặc đưa vào quá nhiều Products. Categories từng tự cập nhật có thể trở thành nhóm tĩnh sau khi di chuyển nếu Nền tảng đích không thể thể hiện cùng bộ điều kiện.
Nhóm động cần được kiểm tra kỹ hơn nhóm tĩnh vì lỗi có thể xuất hiện muộn. Collection có thể trông chính xác trong ngày chính thức vận hành nhưng không tự thêm Products mới về sau nếu quy tắc không được xây dựng lại hoặc duy trì đúng.
Trang Categories có thể phụ thuộc vào nội dung ngoài danh sách Products
Trang Categories thường chứa nhiều nội dung hơn danh sách Products. Landing page của Categories có thể gồm phần giới thiệu, nội dung SEO, banner, video nhúng, hướng dẫn mua hàng, FAQ, liên kết nội bộ, Categories con nổi bật, băng chuyền Products, ô khuyến mãi hoặc các section từ page builder.
Nội dung này có thể được lưu ở nhiều nơi:
| Loại nội dung | Nơi có thể lưu |
|---|---|
| Mô tả Categories | Trường Categories gốc, mô tả collection, CMS block, metafield, trường tùy chỉnh |
| Banner | Hình ảnh Categories, theme section, page-builder block, thư viện media, dữ liệu app |
| Metadata SEO | Trường SEO gốc, trường plugin hoặc module, CMS, thiết lập theme |
| Products nổi bật | Vị trí thủ công trong Categories, module trưng bày, Products block, quy tắc app |
| Nội dung hướng dẫn mua | CMS page, khối nội dung Categories, bài viết blog, mẫu page builder |
| Liên kết nội bộ | HTML trong mô tả, menu blocks, theme sections, dữ liệu module tùy chỉnh |
Vì vậy, một trang có thể trông như Categories nhưng về kỹ thuật lại phụ thuộc vào CMS, thiết lập theme, các trường tùy chỉnh hoặc extension. Nếu không nhận diện các thành phần này, Categories có thể chỉ được di chuyển thành trang liệt kê Products và mất nội dung từng giúp trang phục vụ khách hàng.
Đây cũng là ranh giới cần giữ rõ giữa Phần 6 và các chủ đề SEO ở Phần 2. Trọng tâm kỹ thuật ở đây không phải chiến lược chuyển hướng URL, mà là nội dung Categories được lưu ở đâu và phụ thuộc vào cấu trúc nào. Kế hoạch URL và redirect thuộc phần SEO, còn kiến trúc dữ liệu phía sau trang Categories thuộc phạm vi catalog.
Quy tắc sắp xếp và trưng bày ảnh hưởng đến Products khách hàng thấy trước
Trang Categories và collections thường phụ thuộc vào quy tắc hiển thị. Products có thể được sắp xếp theo bảng chữ cái, ngày mới nhất, giá, doanh số, thứ tự thủ công, tình trạng còn hàng, điểm tìm kiếm, biên lợi nhuận hoặc quy tắc của app.
Dữ liệu trưng bày có thể gồm:
- vị trí Products được sắp xếp thủ công trong Categories;
- cờ Products nổi bật;
- Products được ghim;
- Products được ưu tiên quảng bá;
- Products bị loại khỏi nhóm;
- quy tắc sắp xếp riêng theo Categories;
- khả năng hiển thị theo nhóm Customers;
- khả năng hiển thị theo thị trường hoặc kênh;
- thứ tự dựa trên tồn kho;
- xếp hạng do app quản lý;
- quy tắc ưu tiên hoặc hạ thấp Products trong công cụ tìm kiếm.
Những dữ liệu này dễ bị bỏ sót vì ban đầu không trông giống một phần của cấu trúc catalog. Categories có thể chứa đúng Products nhưng đưa chúng ra theo thứ tự không phù hợp. Với Categories có traffic cao, thứ tự Products có thể ảnh hưởng đến doanh thu, chiến lược thanh lý, mùa vụ và khả năng khách hàng tìm Products.
Khi Nền tảng nguồn và Nền tảng đích dùng mô hình trưng bày khác nhau, dự án có thể cần chuyển danh sách vị trí thủ công, xây dựng lại quy tắc collection, tái tạo thiết lập ưu tiên trong tìm kiếm hoặc chấp nhận một cách sắp xếp mới. Quyết định phụ thuộc vào mức độ cửa hàng dựa vào cách sắp xếp Products đã được hoạch định.
Mỗi nhóm nền tảng tạo ra một kiểu phụ thuộc catalog khác nhau
Các nhóm nền tảng tạo ra những thách thức catalog khác nhau.
Nền tảng SaaS thường tách collections, menu điều hướng, tags Products và theme sections. Mô hình này có thể đơn giản hóa quản trị nhưng tạo khoảng cách giữa đối tượng dữ liệu và đường dẫn trên cửa hàng. Collection có thể tồn tại mà không nằm trong menu. Tags có thể điều khiển collection tự động. Theme hoặc app có thể quyết định cách trang collection hiển thị bộ lọc, banner và Products blocks.
Nền tảng Open Source thường cung cấp cây Categories sâu hơn, nhóm thuộc tính, module và quan hệ ở cấp cơ sở dữ liệu. Chúng có thể hỗ trợ hệ thống phân cấp và cách catalog hoạt động phức tạp, nhưng cửa hàng có thể phụ thuộc vào extension, bảng tùy chỉnh, hệ thống URL rewrite hoặc phần chỉnh sửa theme không nằm trong bản ghi Categories tiêu chuẩn.
Nền tảng doanh nghiệp và B2B có thể quản lý catalog theo nhóm Customers, bảng giá, tài khoản doanh nghiệp, kênh bán hàng, khu vực, hợp đồng hoặc quy trình phê duyệt. Products có thể tồn tại toàn cục nhưng chỉ xuất hiện trong một số catalog dành cho từng Customers. Vì vậy, Categories có thể liên quan đến quyền truy cập, cấu trúc tài khoản, vai trò người mua hoặc giá theo hợp đồng.
Cửa hàng kết nối marketplace hoặc dựa vào PIM có thể duy trì một hệ thống duyệt cho cửa hàng và một hệ thống phân loại khác cho kênh bên ngoài. PIM có thể quản lý taxonomy, thuộc tính, dòng sản phẩm và quan hệ Categories, trong khi cửa hàng chỉ nhận dữ liệu đã xuất bản. Khi đó, kế hoạch chuyển đổi cần xác định hệ thống nào thực sự quản lý mô hình catalog.
Điều gì có thể thay đổi khi mô hình catalog được xây dựng lại
Cấu trúc catalog có thể thay đổi theo những cách không thể hiện qua số lượng bản ghi.
| Thay đổi cấu trúc | Ảnh hưởng có thể xảy ra |
|---|---|
| Hệ thống Categories nhiều cấp được chuyển thành collections không còn quan hệ phân cấp | Khách hàng mất hệ thống phân cấp, breadcrumb và hành trình thu hẹp lựa chọn |
| Categories tĩnh trở thành collections động | Dễ duy trì hơn về sau nhưng độ chính xác của quy tắc trở nên quyết định |
| Collections động trở thành nhóm tĩnh | Ngày chính thức vận hành có thể trông đúng nhưng việc thêm Products mới về sau phải làm thủ công |
| Nội dung Categories trở thành văn bản mô tả đơn giản | Bố cục landing page, liên kết nội bộ và khối quảng bá có thể mất |
| Menu được xây dựng lại riêng | Categories vẫn tồn tại nhưng đường dẫn khách hàng mong đợi có thể thiếu |
| Quan hệ Products được tính lại từ tags | Products thuộc nhóm nào phụ thuộc vào độ nhất quán của tags và thiết kế quy tắc |
| Thứ tự Products thủ công bị mất | Categories chứa đúng Products nhưng cách trưng bày không còn hỗ trợ mục tiêu bán hàng |
| Categories chính không được duy trì | Breadcrumb, canonical path và báo cáo có thể thiếu nhất quán |
Không phải mọi thay đổi đều sai. Chuyển đổi nền tảng có thể là cơ hội đơn giản hóa cây Categories lộn xộn, hợp nhất Categories trùng hoặc thay nhóm thủ công bằng nhóm dựa trên quy tắc. Điều quan trọng là đây phải là quyết định kiến trúc đã được cân nhắc, không phải hệ quả xảy ra ngoài dự kiến.
Nên kiểm tra những hành trình duyệt Products nào
Việc kiểm tra catalog nên bắt đầu từ các hành trình duyệt đại diện, không phải toàn bộ danh sách Categories.
Mẫu rà soát nên gồm:
- đường dẫn Categories tạo doanh thu cao;
- trang Categories hoặc collection có nhiều traffic tự nhiên;
- đường dẫn phân cấp sâu với nhiều cấp cha con;
- Products thuộc nhiều Categories hoặc collections;
- smart collections hoặc Categories tự động;
- trang Categories có nội dung landing page;
- trang có thứ tự Products thủ công, vị trí nổi bật hoặc quy tắc trưng bày;
- cấu trúc menu, mega menu và cách breadcrumb hoạt động;
- catalog theo nhóm Customers, B2B, thị trường hoặc kênh;
- cấu trúc catalog do PIM, ERP, nhà cung cấp tìm kiếm, app, module hoặc mã tùy chỉnh quản lý.
Với từng mẫu, cần đối chiếu cấu trúc dữ liệu và cách hoạt động trên cửa hàng. Nhóm có tồn tại không? Products có được gán đúng không? Khách hàng có đi đến trang qua menu không? Breadcrumb có hợp lý không? Trang có giữ đúng nội dung và mục tiêu trưng bày không? Nhóm có tiếp tục tự cập nhật nếu trước đây dựa trên quy tắc không? Nền tảng đích có giữ cùng hệ thống phân cấp hay đã chuyển sang một mô hình khác?
Quá trình rà soát cũng cần xác định quyền quản lý. Nếu hệ thống phân cấp catalog được duy trì trong PIM, ERP, feed marketplace hoặc module quản trị tùy chỉnh, nền tảng cửa hàng có thể không phải nơi quản lý chính. Chỉ giữ dữ liệu trên cửa hàng chưa chắc duy trì được quy trình vận hành.
Khi nào cấu trúc catalog cần phân tích sâu
Cấu trúc catalog cần được phân tích sâu khi cách khách hàng duyệt Products phụ thuộc vào nhiều yếu tố ngoài bản ghi Categories tiêu chuẩn.
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 Categories, collections hoặc taxonomy khác nhau;
- cửa hàng có cây phân cấp sâu, Products thuộc nhiều Categories hoặc cần Categories chính;
- trang Categories có rich content, CMS blocks, banner, bố cục page builder hoặc cấu trúc liên kết nội bộ;
- smart collections, nhóm tự động, quy tắc tìm kiếm, tags, thuộc tính hoặc quy tắc app quyết định Products được đưa vào nhóm;
- thứ tự thủ công, Products nổi bật, Products được ghim hoặc quy tắc trưng bày ảnh hưởng đến doanh thu;
- menu, mega menu, breadcrumb hoặc quy tắc theme tách khỏi bản ghi Categories;
- catalog theo nhóm Customers, B2B, thị trường, kênh hoặc hợp đồng ảnh hưởng đến khả năng hiển thị;
- PIM, ERP, marketplace hoặc hệ thống tìm kiếm quản lý một phần mô hình phân loại catalog.
Khi mô hình catalog không thể được thể hiện bằng cách chuyển trực tiếp Categories hoặc collections, dự án cần xác định rõ cách Nền tảng đích sẽ thể hiện hệ thống phân cấp, điều hướng, các trường tùy chỉnh, menu, nội dung landing page và quyền quản lý của hệ thống bên ngoài. Mọi phương án di chuyển riêng phải gắn với kết quả catalog cụ thể đó.
Kết luận
Cấu trúc catalog là cách Categories, collections, hệ thống phân loại, quan hệ Products, menu, breadcrumb, landing page, quy tắc sắp xếp và cách trưng bày phối hợp để đưa khách hàng từ nhu cầu ban đầu đến Products phù hợp.
Một quá trình chuyển đổi nền tảng đạt yêu cầu phải làm nhiều hơn việc giữ lại tên Categories. Quá trình đó cần duy trì những quan hệ và hành vi làm catalog hoạt động đúng: hệ thống phân cấp, đường dẫn truy cập, cách gán Products, nhóm động, nội dung hỗ trợ và thứ tự trưng bày. Cách chuẩn bị tốt nhất là kiểm tra catalog dưới dạng các hành trình duyệt cùng những mối phụ thuộc kỹ thuật, thay vì giả định rằng bản ghi Categories đã đại diện cho toàn bộ trải nghiệm catalog.
Câu hỏi thường gặp
Categories và collections có giống nhau không?
Categories và collections không phải cùng một cấu trúc. Chúng có thể trông giống nhau trên cửa hàng nhưng dùng mô hình dữ liệu khác nhau. Categories thường thể hiện hệ thống phân cấp. Collections có thể được tạo thủ công, dựa trên quy tắc, tags hoặc theme. Cấu trúc đích phù hợp phụ thuộc vào hành vi cửa hàng cần duy trì.
Vì sao Categories có thể tồn tại nhưng vẫn không xuất hiện trong menu?
Bản ghi Categories và menu thường được quản lý riêng. Categories hoặc collection có thể đã có trong giao diện quản trị nhưng không được liên kết với menu, mega menu, breadcrumb hoặc cấu trúc landing page mà khách hàng sử dụng.
Nhóm catalog tĩnh và động khác nhau như thế nào?
Nhóm tĩnh lưu quan hệ Products cụ thể. Nhóm động tự đưa Products vào khi Products đáp ứng điều kiện như tags, loại Products, nhà cung cấp, giá, tồn kho, giá trị thuộc tính hoặc ngày xuất bản. Với nhóm động, cần duy trì bộ quy tắc chứ không chỉ tên nhóm.
Vì sao quan hệ Products với Categories vẫn quan trọng khi toàn bộ Products đã được di chuyển?
Khách hàng không duyệt các bản ghi Products độc lập mà tìm Products qua Categories, collections, kết quả tìm kiếm và menu. Products đã di chuyển vẫn có thể mất khả năng tiếp cận khách hàng nếu không còn xuất hiện trong hành trình duyệt quan trọng.
Khi nào hệ thống phân cấp catalog cần cách xử lý riêng?
Có thể cần cách xử lý riêng khi hệ thống phân cấp phụ thuộc vào dữ liệu extension, menu tùy chỉnh, quy tắc động, nội dung page builder, PIM hoặc ERP bên ngoài, catalog theo từng Customers hoặc mô hình nguồn không thể thể hiện trực tiếp trên Nền tảng đích.