Thông qua metadata, các trường tùy chỉnh và dữ liệu do extensions quản lý, cửa hàng thường lưu những ý nghĩa kinh doanh vượt ra ngoài mô hình Products, Customers, Orders, Categories hoặc nội dung tiêu chuẩn. Chúng có thể chỉ bổ sung thông tin tham khảo, nhưng cũng có thể quyết định cách cửa hàng hiển thị nội dung, lọc Products, áp dụng giá, phân quyền Customers, xử lý Orders, tính thuế, cá nhân hóa, kết nối hệ thống, lập báo cáo và tự động hóa quy trình.
Vì vậy, nhóm dữ liệu này khác về bản chất so với trường thông thường của các bản ghi. Tiêu đề Products, SKU hoặc email Customers thường có vị trí đích tương đối rõ. Trường ghi chú khả năng tương thích của Products, cờ phê duyệt bán buôn, quy tắc huy hiệu Products, ID ERP, giá trị mua hàng định kỳ do app quản lý hoặc bảng tùy chọn riêng của plugin thì không. Cùng một giá trị có thể dễ lưu nhưng khó hiểu và không thể tiếp tục phát huy tác dụng nếu Nền tảng đích dùng mô hình dữ liệu hoặc kiến trúc extensions khác.
Việc rà soát kỹ thuật cần trả lời năm câu hỏi: trường này là gì, đang được lưu ở đâu, hệ thống nào quản lý, chức năng nào sử dụng trường và Nền tảng đích có thể tiếp tục dùng trường theo cùng mục đích hay không. Chỉ thấy trường xuất hiện sau khi chuyển dữ liệu chưa đủ. Trường phải tiếp tục hỗ trợ đúng kết quả kinh doanh đã được xác định từ đầu.
Metadata và các trường tùy chỉnh mở rộng mô hình dữ liệu tiêu chuẩn
Metadata và các trường tùy chỉnh cho phép cửa hàng lưu thông tin không có sẵn trong trường tiêu chuẩn hoặc bổ sung bối cảnh cho các bản ghi hoặc loại dữ liệu hiện có.
Những trường hợp thường gặp gồm:
- thông số Products không phù hợp với trường có sẵn của nền tảng;
- huy hiệu, nhãn, ghi chú tương thích, hướng dẫn bảo quản, thông tin kích cỡ, bảo hành hoặc tuân thủ của Products;
- trường tùy chỉnh trên Categories dùng cho nội dung landing page, khối trưng bày, nội dung SEO hoặc cách menu hoạt động;
- trường của Customers liên quan đến phê duyệt bán buôn, VAT, cấp độ khách hàng thân thiết, trạng thái thành viên, loại tài khoản hoặc nhân viên bán hàng phụ trách;
- metadata của Orders dùng cho ghi chú giao hàng, điều phối xử lý đơn hàng, mua định kỳ, trả hàng, hóa đơn, rà soát gian lận hoặc báo cáo;
- giá trị tùy chọn dùng cho trình cấu hình Products, app cá nhân hóa, hệ thống đặt lịch hoặc quy trình Products có thể cấu hình;
- ID do ERP, CRM, PIM, POS, marketplace, hệ thống xử lý đơn hàng, vận chuyển, tự động hóa, analytics hoặc báo cáo sử dụng.
Một số metadata chỉ mô tả. Một số khác trực tiếp điều khiển hành vi. Sự khác biệt này rất quan trọng: metadata mô tả chủ yếu cần tiếp tục truy cập được, còn metadata điều khiển hành vi phải được theme, trang quản trị, app, quy tắc, quy trình và hệ thống liên quan hiểu đúng.
Các cấu trúc metadata thường gặp trong dữ liệu cửa hàng
Metadata có thể gắn với nhiều loại dữ liệu và cấu trúc bản ghi. Hình thức kỹ thuật phụ thuộc vào nội dung trường mô tả và cách nền tảng lưu dữ liệu tùy chỉnh.
| Nhóm dữ liệu | Metadata thường gặp | Chức năng phụ thuộc vào metadata |
|---|---|---|
| Products và biến thể | Thông số, huy hiệu, ghi chú tương thích, chất liệu, hướng dẫn bảo quản, ID nguồn, tài liệu tải xuống, giá trị trình cấu hình Products | Trang Products, bộ lọc, trưng bày, feed, các tích hợp, xử lý đơn hàng và hỗ trợ |
| Categories và collections | Nội dung đầu trang, nhãn menu, khối khuyến mãi, nội dung SEO, quy tắc landing page, cách sắp xếp, thiết lập hiển thị | Điều hướng, trang collections, trưng bày, SEO và theme |
| Customers | Loại Customers, trạng thái phê duyệt, thuế/VAT, cấp độ khách hàng thân thiết, vai trò B2B, ID công ty, nhân viên bán hàng, giá trị phân khúc | Quyền tài khoản, giá, khuyến mãi, cá nhân hóa, phân khúc, thuế và CRM |
| Orders | Ghi chú giao hàng, kênh nguồn, cờ gian lận, hướng dẫn xử lý đơn hàng, ID mua định kỳ, ID Orders bên ngoài, lời nhắn quà tặng | Xử lý đơn hàng, hỗ trợ, trả hàng, kế toán, vận chuyển, báo cáo và hệ thống phía sau |
| Đối tượng nội dung | Thuộc tính bài viết, thiết lập khối CMS, giá trị biểu mẫu, quan hệ trang, trường bản địa hóa | Hiển thị nội dung, điều hướng, tìm kiếm, bản địa hóa và quản lý chiến dịch |
| Bản ghi các tích hợp | ID ERP, ID marketplace, mã feed Products, mã kho, cờ tự động hóa | Đồng bộ, đối chiếu, báo cáo, xử lý đơn hàng và nhận diện bản ghi giữa các hệ thống |
Metadata không phải lúc nào cũng hiển thị cho khách hàng. Nhiều giá trị rủi ro cao nhất là các ID không hiển thị cho khách hàng nhưng được hệ thống vận hành sử dụng để nhận diện đúng bản ghi sau khi cửa hàng đổi nền tảng.
Cần phân biệt trường lưu thông tin và trường điều khiển hành vi
Một cách phân loại hữu ích là xác định trường chỉ lưu bối cảnh hay đang quyết định một chức năng của cửa hàng.
| Loại metadata | Vai trò | Rủi ro thường gặp |
|---|---|---|
| Metadata tham khảo | Giữ thông tin cho quản trị, hỗ trợ hoặc bảo đảm nội dung đầy đủ | Rủi ro thấp hơn nếu nhân viên vẫn truy cập được hoặc trường vẫn hiển thị đúng nơi cần thiết |
| Metadata hiển thị | Quyết định nội dung xuất hiện trên trang cửa hàng, email, nhãn, tab, huy hiệu hoặc khối nội dung | Rủi ro tăng khi theme hoặc mô hình nội dung đích không đọc được trường |
| Metadata tìm kiếm và lọc | Cung cấp dữ liệu cho bộ lọc, tiêu chí tìm kiếm, thứ hạng, khám phá Products hoặc quy tắc collections | Rủi ro tăng khi công cụ tìm kiếm dùng kiểu trường hoặc quy tắc lập chỉ mục khác |
| Metadata về điều kiện áp dụng | Kiểm soát quyền truy cập, khả năng nhìn thấy giá, giảm giá, thuế, quyền B2B hoặc phê duyệt quy trình | Rủi ro tăng khi mô hình vai trò, phân khúc, quyền hoặc nhóm Customers khác |
| Metadata vận hành | Hỗ trợ xử lý Orders, điều phối kho, hóa đơn, trả hàng, mua định kỳ, rà soát gian lận hoặc hỗ trợ | Rủi ro tăng khi đội ngũ hoặc hệ thống phía sau phụ thuộc vào đúng giá trị |
| Metadata các tích hợp | Kết nối bản ghi với ERP, CRM, PIM, POS, marketplace, analytics, vận chuyển hoặc tự động hóa | Rủi ro tăng khi ID bị đổi, mất, trùng hoặc gắn nhầm bản ghi |
Phân loại này tránh việc xem mọi các trường tùy chỉnh như nhau. Một ghi chú nội bộ phụ không cần mức rà soát giống trường đang quyết định giá bán buôn hoặc đối chiếu với ERP.
Các nền tảng lưu dữ liệu tùy chỉnh bằng những mô hình khác nhau
Có nền tảng dùng các trường tùy chỉnh gốc. Có nền tảng dùng metafields hoặc thuộc tính. Dữ liệu bổ sung cũng có thể nằm trong bảng plugin, bản ghi do app quản lý, JSON, cột cơ sở dữ liệu tùy chỉnh hoặc cấu hình riêng của theme.
| Mô hình nền tảng | Dữ liệu tùy chỉnh thường xuất hiện dưới dạng | Ý nghĩa kỹ thuật |
|---|---|---|
| Nền tảng SaaS sử dụng metafields | Cấu trúc namespace/key/value, trường có kiểu dữ liệu, trường do app sở hữu, giá trị theme đọc được | Có thể dễ lưu trường nhưng vẫn phải kiểm tra kiểu dữ liệu, quyền sở hữu, khả năng hiển thị và quyền truy cập của theme |
| Nền tảng dùng nhiều thuộc tính | Nhóm thuộc tính, phạm vi áp dụng của giá trị, danh sách tùy chọn, mô hình entity-attribute-value | Có thể hỗ trợ lọc và tổ chức trang quản trị, nhưng quan hệ với trường đích phụ thuộc vào kiểu và phạm vi thuộc tính |
| Nền tảng Open Source hoặc nền tảng phụ thuộc nhiều vào plugin | Bảng plugin, custom post meta, dữ liệu module, giá trị tuần tự hóa, cột tùy chỉnh, cấu hình extensions | Giá trị có thể nằm ngoài dữ liệu xuất tiêu chuẩn và cần được hiểu theo extensions đã tạo ra dữ liệu |
| Nền tảng doanh nghiệp hoặc composable | Custom objects, tài nguyên tùy chỉnh, phần mở rộng API, trường do PIM quản lý, ID do middleware quản lý | Hệ thống quản lý chính và quyền sở hữu quan trọng không kém việc chuyển trường |
| Cửa hàng kết nối marketplace | ID marketplace, trường riêng theo kênh, thuộc tính feed, metadata listing, trường tuân thủ | Giá trị có thể chỉ có ý nghĩa với một kênh và không hoàn toàn thuộc nền tảng cửa hàng |
| Cửa hàng Headless hoặc custom frontend | Trường CMS, thuộc tính API, cấu hình frontend, schema tùy chỉnh, nội dung do app cung cấp | Hành vi hiển thị phụ thuộc vào hợp đồng API và mã frontend, không chỉ bản ghi nền tảng |
Trường có tên material, customer_type hoặc external_id có thể mang vai trò khác nhau tùy nơi lưu: thuộc tính gốc, metafield tùy chỉnh, thiết lập app, ID ERP, trường plugin hoặc giá trị chỉ theme sử dụng. Tên trường không đủ để giải thích mục đích.
Kiểu dữ liệu, phạm vi áp dụng và quyền sở hữu quyết định trường có còn hữu ích
Dữ liệu tùy chỉnh không chỉ là một cặp tên và giá trị. Nhiều đặc tính kỹ thuật quyết định trường có thể tiếp tục phục vụ đúng mục đích sau khi đổi nền tảng.
| Đặc tính | Vì sao quan trọng |
|---|---|
| Kiểu trường | Văn bản, số, ngày, boolean, URL, tệp, danh sách, JSON, tham chiếu và rich text hoạt động khác nhau trong biểu mẫu, bộ lọc, API và theme |
| Phạm vi áp dụng | Giá trị có thể dùng toàn hệ thống hoặc riêng theo cửa hàng, ngôn ngữ, thị trường, kênh, nhóm Customers hay website |
| Bản ghi gắn với trường | Trường có thể thuộc Products, biến thể, Categories, Customers, Orders, công ty, đối tượng nội dung hoặc bản ghi tích hợp |
| Bên quản lý | Nền tảng, theme, app, plugin, module, mã tùy chỉnh hoặc hệ thống bên ngoài quyết định ai được đọc và cập nhật trường |
| Khả năng truy cập | Trường có thể chỉ hiển thị trong giao diện quản trị, xuất hiện trên cửa hàng, API, feed, chỉ mục tìm kiếm hoặc bị ẩn khỏi dữ liệu xuất chuẩn |
| Số lượng giá trị | Một giá trị, nhiều giá trị, danh sách có thứ tự, khối lặp, tham chiếu và đối tượng lồng nhau cần cấu trúc đích khác nhau |
| Quy tắc xác thực | Trường bắt buộc, lựa chọn được phép, định dạng và quan hệ phụ thuộc ảnh hưởng đến quá trình nhập và duy trì dữ liệu |
| Cách thay đổi theo thời gian | Có trường chỉ là ảnh chụp lịch sử; trường khác phải tiếp tục chỉnh sửa, đồng bộ hoặc tính lại sau khi vận hành |
Đây là lý do dữ liệu tùy chỉnh thường cần được thiết kế trước khi chuyển. Trường văn bản có thể được lưu lại dưới dạng văn bản, nhưng nếu Nền tảng đích cần một tham chiếu có kiểu, một lựa chọn dùng cho bộ lọc hoặc cấu hình để app đọc, việc sao chép giá trị sẽ không giữ được chức năng kinh doanh.
Dữ liệu do app và extensions quản lý thường không thể tách khỏi hệ thống đã tạo ra dữ liệu
App, plugin, module và extensions thường tạo một mô hình dữ liệu riêng cho trình cấu hình Products, mua hàng định kỳ, khách hàng thân thiết, Reviews, tìm kiếm nâng cao, giá B2B, nhãn Products, bundle, đề xuất Products, biểu mẫu, feed marketplace, đặt lịch, tài liệu tải xuống hoặc quy tắc giao hàng.
Dữ liệu đó có thể phụ thuộc vào:
- bảng cơ sở dữ liệu tùy chỉnh;
- ID riêng của app;
- bản ghi cấu hình;
- thiết lập tuần tự hóa hoặc JSON;
- snippet hoặc block trong theme;
- script frontend;
- quan hệ API;
- tác vụ theo lịch hoặc quy tắc tự động hóa;
- bản ghi được lưu trong hệ thống nhà cung cấp bên ngoài nền tảng.
Bản ghi có thể không còn ý nghĩa nếu tách khỏi extensions gốc. Cấu hình của trình tạo Products có thể chứa nhóm tùy chọn, điều kiện, khoản điều chỉnh giá, tệp Customers cung cấp và lựa chọn chỉ app đó hiểu. Bản ghi mua hàng định kỳ có thể gồm chu kỳ thanh toán, quyền ủy quyền của Customers, quan hệ với token thanh toán, trạng thái thử lại, trạng thái hủy và ID phía nhà cung cấp, nên không thể xử lý như dữ liệu Orders thông thường.
Câu hỏi kỹ thuật không chỉ là dữ liệu extensions có tồn tại hay không. Cần xác định Nền tảng đích có chức năng tương ứng, app thay thế, mô hình custom objects hoặc quy trình cấu hình sau khi chuyển để tiếp tục tạo ra hành vi cần thiết hay không.
các trường tùy chỉnh chỉ có giá trị khi chức năng sử dụng chúng còn hoạt động
Ảnh hưởng của dữ liệu tùy chỉnh thường chỉ lộ rõ khi một hành vi thay đổi.
| Hạng mục | Metadata hoặc dữ liệu extensions có thể ảnh hưởng như thế nào |
|---|---|
| Trang Products | Thông số, tab, huy hiệu, ghi chú tương thích, tệp tải xuống, tùy chọn trình cấu hình và thông báo riêng theo biến thể |
| Tìm kiếm và lọc | Thuộc tính dùng cho bộ lọc, tags, metafields, giá trị trong hệ thống phân loại, trường được lập chỉ mục và cấu hình công cụ tìm kiếm |
| Giá và khuyến mãi | Loại Customers, mức số lượng, cờ bán buôn, trường điều kiện áp dụng, quy tắc nhãn Products và điều kiện giảm giá từ extensions |
| Tài khoản Customers | Vai trò B2B, trạng thái phê duyệt, cấp độ khách hàng thân thiết, VAT, thành viên, quan hệ công ty và quyền truy cập |
| Checkout và xử lý Orders | Hướng dẫn giao hàng, giới hạn vận chuyển, lấy hàng tại điểm, giá trị mua định kỳ, các trường tùy chỉnh trên Orders và ID điều phối |
| Tích hợp | ID ERP, ID CRM, ID feed Products, mã kho, ID của mặt hàng đăng bán trên marketplace và mã tham chiếu middleware |
| Báo cáo và analytics | Trường ghi nhận nguồn đóng góp, ID kênh, trường nhân viên bán hàng, trạng thái tùy chỉnh và nhóm vận hành |
| Bản địa hóa và nhiều cửa hàng | Giá trị riêng theo ngôn ngữ, ghi đè theo store view, nội dung theo thị trường và quy tắc hiển thị theo kênh |
Vì vậy, metadata phải được rà soát theo tình huống sử dụng. Giá trị xuất hiện trong trang quản trị vẫn có thể không đạt yêu cầu nếu bộ lọc không lập chỉ mục, cửa hàng không hiển thị, quy tắc giá không đọc được hoặc hệ thống bên ngoài không còn nhận diện giá trị đó.
Nhiều trường cần được tái cấu trúc thay vì chỉ sao chép
Với cửa hàng phụ thuộc nhiều vào metadata, giá trị nguồn thường phải được chuyển sang cấu trúc mới để Nền tảng đích có thể sử dụng đúng.
Các cách tái cấu trúc thường gặp gồm:
- chuyển thuộc tính Products thành metafields hoặc các trường tùy chỉnh có kiểu dữ liệu;
- chuyển tags thành phân khúc Customers, nhóm hoặc quy tắc truy cập;
- chuyển cấu trúc tùy chọn riêng của plugin thành tùy chọn gốc, các trường tùy chỉnh hoặc mô hình của app thay thế;
- tách một trường nguồn thành nhiều trường đích;
- gộp nhiều giá trị nguồn thành một cấu trúc đích đã chuẩn hóa;
- chuyển giá trị văn bản thành danh sách lựa chọn để dùng cho bộ lọc;
- chuyển dữ liệu tuần tự hóa hoặc JSON thành các nhóm trường có thể đọc và duy trì;
- giữ ID bên ngoài trong khi thay đổi mô hình dữ liệu xung quanh;
- loại bỏ giá trị extensions đã lỗi thời và không còn mục đích trên hệ thống mới.
Quyết định phụ thuộc vào vai trò tương lai của trường. Nếu doanh nghiệp chỉ cần tham khảo lịch sử, chuyển giá trị có thể đã đủ. Nếu trường vẫn phải điều khiển hiển thị, quản trị, tìm kiếm, bộ lọc, điều kiện áp dụng, tự động hóa hoặc đồng bộ với hệ thống bên ngoài, cấu trúc đích phải được thiết kế quanh kết quả đó.
Những khác biệt nền tảng cần được kiểm tra riêng
Một số khác biệt thường ảnh hưởng trực tiếp đến metadata và các trường tùy chỉnh.
Trường có kiểu dữ liệu và trường văn bản tự do
Có nền tảng xác định chặt kiểu dữ liệu, nền tảng khác lưu giá trị tùy chỉnh dưới dạng văn bản tự do. Kiểu dữ liệu rõ giúp xác thực, lọc và dùng API tốt hơn nhưng có thể yêu cầu làm sạch hoặc chuẩn hóa giá trị nguồn.
Trường ở cấp Products và trường ở cấp biến thể
trường tùy chỉnh có thể thuộc Products chính trên nền tảng này nhưng thuộc từng biến thể trên nền tảng khác. Nếu giá trị điều khiển hành vi riêng theo kích thước, màu sắc hoặc SKU, gắn toàn bộ ở cấp Products chính sẽ quá rộng.
Nhóm thuộc tính và các trường tùy chỉnh dùng toàn hệ thống
Nền tảng dùng nhiều thuộc tính có thể tổ chức trường thành nhóm hoặc bộ thuộc tính; nền tảng khác dùng metafields hoặc các trường tùy chỉnh được định nghĩa toàn hệ thống. Sự khác biệt ảnh hưởng đến cách trang quản trị được tổ chức và khả năng nhân viên duy trì dữ liệu sau khi vận hành.
Trường do app quản lý và trường do doanh nghiệp quản lý
Một số trường được app tạo và kiểm soát. Chỉnh sửa bên ngoài app có thể không an toàn, và app thay thế có thể không sử dụng cùng cấu trúc.
Phạm vi theo store view, thị trường và ngôn ngữ
Một giá trị có thể khác theo ngôn ngữ, website, thị trường hoặc kênh. Nếu Nền tảng đích dùng mô hình phạm vi khác, trường có thể cần được nhân bản, hợp nhất hoặc thiết kế lại.
Trường được lập chỉ mục và trường không được lập chỉ mục
Trường có thể tồn tại nhưng không khả dụng cho tìm kiếm hoặc bộ lọc trên cửa hàng. Nếu trường hỗ trợ khách hàng tìm Products, cấu hình tìm kiếm và lọc trên Nền tảng đích quan trọng không kém giá trị của trường.
Lập danh mục metadata theo mục đích và phụ thuộc kỹ thuật
Danh mục metadata hữu ích phải ghi lại nhiều hơn tên trường, đồng thời mô tả mục đích kinh doanh và những chức năng phụ thuộc vào trường.
| Câu hỏi rà soát | Vì sao quan trọng |
|---|---|
| Trường thuộc bản ghi hoặc loại dữ liệu nào? | Quyền sở hữu của Products, biến thể, Categories, Customers, Orders, nội dung hoặc hệ thống ngoài ảnh hưởng đến quan hệ trường đích |
| Trường sử dụng kiểu dữ liệu nào? | Văn bản, số, ngày, boolean, danh sách, tệp, tham chiếu, JSON và rich text cần cách xử lý khác nhau |
| Trường chỉ lưu thông tin hay điều khiển hành vi? | Trường điều khiển hành vi cần kiểm thử sâu hơn |
| Trường được sử dụng ở đâu? | Admin, cửa hàng, API, feed, tìm kiếm, báo cáo hay hệ thống ngoài quyết định phạm vi kiểm thử |
| Ai cập nhật trường? | Nhân viên, app, các tích hợp, middleware hoặc tác vụ tự động có thể phụ thuộc vào quyền chỉnh sửa |
| Chức năng nào phụ thuộc vào trường? | Bộ lọc, giá, phân khúc, checkout, xử lý Orders, báo cáo hoặc các tích hợp có thể bị ảnh hưởng |
| Nền tảng đích có cấu trúc tương ứng không? | Trường gốc, metafield, thuộc tính, mô hình app, custom object hoặc không có cấu trúc tương ứng quyết định độ phức tạp |
| Có cần tái cấu trúc giá trị không? | Sao chép, chuyển đổi, chuẩn hóa, tách, gộp và loại bỏ là những yêu cầu khác nhau |
Danh mục nên có các bản ghi có ảnh hưởng lớn, không chỉ tổng số trường. Một bản ghi Products có tùy chọn tùy chỉnh phức tạp, một bản ghi Customers có quy tắc phê duyệt, một bản ghi Categories có nội dung landing page riêng và một bản ghi Orders có metadata vận hành thường cho thấy nhiều vấn đề hơn danh sách dài các trường văn bản đơn giản.
Ý nghĩa, quyền sở hữu và hành vi quyết định rủi ro
Khi metadata và extensions tham gia, rủi ro chủ yếu đến từ việc hiểu sai ý nghĩa, sai bên quản lý hoặc không tái tạo được hành vi.
Các điểm cần lưu ý gồm:
- tên trường có thể không đủ để xác định mục đích kinh doanh;
- một số trường nằm ngoài dữ liệu xuất tiêu chuẩn;
- dữ liệu do app quản lý có thể không còn sử dụng được nếu thiếu app gốc hoặc app thay thế tương thích;
- Nền tảng đích có thể lưu giá trị nhưng không cho theme, bộ lọc, API, feed hoặc báo cáo truy cập;
- ID bên ngoài phải tiếp tục gắn với đúng bản ghi;
- trường điều khiển hành vi cần được kiểm thử bằng kết quả trên cửa hàng và trong quy trình vận hành;
- giá trị tùy chỉnh có thể cần chuyển đổi, chuẩn hóa, chọn lọc hoặc xác định trường đích mới.
Phương án xử lý phải phù hợp với vấn đề cụ thể. Khi dữ liệu từ một trường nguồn phải được đưa sang loại trường khác trên Nền tảng đích, cần xác định rõ trường đích tương ứng và cách chuyển giá trị. Khi chỉ một số bản ghi có các trường tùy chỉnh cần được chuyển, cần xác định điều kiện chọn lọc. Dữ liệu của extensions, cách Custom Platform xử lý dữ liệu, quy tắc tùy chỉnh và cấu trúc không theo chuẩn cần được diễn giải riêng khi việc chuyển trường thông thường không giữ được ý nghĩa.
Kiểm thử metadata trong đúng bối cảnh sử dụng
Mục tiêu kiểm thử là xác nhận metadata tiếp tục hoạt động trong tình huống thực tế.
Mẫu ưu tiên nên gồm:
- Products có thông số tùy chỉnh, huy hiệu, ghi chú tương thích, tài liệu tải xuống hoặc trình cấu hình Products;
- biến thể có giá trị tùy chỉnh riêng theo SKU;
- Categories hoặc collections có nội dung landing page hoặc trường trưng bày riêng;
- Customers có trạng thái phê duyệt, khách hàng thân thiết, B2B, VAT, vai trò hoặc phân khúc;
- Orders có metadata xử lý đơn hàng, hóa đơn, mua định kỳ, trả hàng hoặc hỗ trợ;
- bản ghi liên kết với ERP, CRM, PIM, POS, marketplace, vận chuyển, tự động hóa hoặc báo cáo;
- trường đã được chuyển từ cấu trúc nguồn sang một cấu trúc mới trên Nền tảng đích.
Cần trả lời:
- Trường có xuất hiện đúng vị trí trong trang quản trị không?
- Cửa hàng có hiển thị hoặc ẩn giá trị đúng không?
- Tìm kiếm, bộ lọc, giá, phân khúc hoặc tự động hóa còn đọc được trường không?
- Hệ thống liên quan có nhận diện đúng ID đã chuyển không?
- Nhân viên có thể chỉnh sửa và duy trì trường sau khi chính thức vận hành không?
- Nếu trường đã được tái cấu trúc, cấu trúc mới có tiếp tục hỗ trợ đúng chức năng mà trường đó điều khiển không?
Hãy tập trung vào những mẫu phản ánh đúng các dạng dữ liệu phức tạp của cửa hàng. Ghi chú văn bản đơn giản ít quan trọng hơn trường đang điều khiển quyền hưởng giá, khả năng tìm Products, xử lý Orders hoặc các tích hợp.
Kết luận
Metadata, các trường tùy chỉnh và extensions thường lưu những dữ liệu và quy tắc đặc thù nhất của doanh nghiệp. Chúng có thể trông như các giá trị bổ trợ nhỏ, nhưng lại quyết định Products xuất hiện thế nào, Customers đủ điều kiện ra sao, giá được áp dụng như thế nào, Orders đi qua quy trình vận hành nào và hệ thống bên ngoài nhận diện bản ghi bằng cách nào.
Cách rà soát an toàn là tách trường chỉ dùng để tham khảo khỏi trường điều khiển chức năng của cửa hàng, xác định hệ thống quản lý từng giá trị và đánh giá Nền tảng đích có thể duy trì đúng ý nghĩa và chức năng thông qua trường gốc, thuộc tính, metafields, custom objects, app hay cách xử lý riêng. Không nên đánh giá kết quả chỉ bằng việc trường tùy chỉnh còn tồn tại. Cần xác nhận trường vẫn hỗ trợ đúng chức năng trên cửa hàng, trong quản trị, vận hành và các tích hợp.
Khi metadata thiết yếu với giá, khả năng hiển thị, bộ lọc, phân khúc, xử lý Orders hoặc quan hệ giữa các hệ thống, cần thiết kế cấu trúc đích trước khi triển khai. Nếu kết quả phụ thuộc vào chuyển đổi dữ liệu, hiểu cấu trúc extensions hoặc quy tắc tùy chỉnh, phải giao cho người có đủ chuyên môn xác định quan hệ trường, cách xử lý, ranh giới triển khai và kết quả cần kiểm tra khi nghiệm thu.
Câu hỏi thường gặp
Metadata có phải là trường tùy chỉnh không?
Metadata không phải lúc nào cũng là trường tùy chỉnh. trường tùy chỉnh thường là một trường bổ sung được định nghĩa và gắn với Products, Customers, Orders, Categories hoặc đối tượng nội dung. Metadata rộng hơn, có thể gồm các trường tùy chỉnh, giá trị do app quản lý, dữ liệu plugin, ID, cấu hình và thông tin bổ trợ khác làm rõ ý nghĩa của bản ghi.
Vì sao trường tùy chỉnh đã được chuyển nhưng chức năng vẫn ngừng hoạt động?
Việc giữ lại giá trị của trường không đồng nghĩa với việc chức năng phụ thuộc vào trường vẫn hoạt động. Trường có thể tồn tại trên Nền tảng đích nhưng theme, chỉ mục tìm kiếm, hệ thống lọc, quy tắc giá, app, quy trình, API hoặc hệ thống bên ngoài không còn đọc được trường đó.
các trường tùy chỉnh nào cần được ưu tiên rà soát?
Hãy ưu tiên trường đang điều khiển giá, khả năng hiển thị, điều kiện áp dụng, bộ lọc, phân khúc, xử lý Orders, thuế, mua định kỳ, trình cấu hình Products, thông tin đăng bán trên marketplace hoặc ID của hệ thống bên ngoài.
Cửa hàng có nhiều metadata có luôn cần thiết kế phương án xử lý riêng không?
Cửa hàng có nhiều metadata không phải lúc nào cũng cần thiết kế phương án xử lý riêng. Một số metadata có thể được chuyển sang trường đích tương ứng hoặc cấu hình sẵn nếu cấu trúc đích rõ ràng. Cần thiết kế cách xử lý riêng khi yêu cầu liên quan đến dữ liệu do extensions quản lý, cách Custom Platform xử lý dữ liệu, quy tắc tùy chỉnh, chuyển đổi dữ liệu, cấu trúc đặc thù hoặc chức năng cần thiết trên Nền tảng đích không thể được duy trì bằng việc chuyển trường thông thường.