Cập nhật 06/10/2026 · Đội ngũ Onter
Product Feed WooCommerce cần mô tả đúng từng lựa chọn bán được, giữ mã sản phẩm ổn định và đồng bộ giá/tồn kho với trang đích. Với hàng nhiều size, màu hoặc model, lỗi thường nằm ở mapping variation và dữ liệu nguồn, chứ không chỉ ở định dạng XML.
Vì sao một sản phẩm cha chưa đủ dữ liệu để xuất feed?
Một áo có ba size và hai màu có thể có sáu lựa chọn khác nhau. Mỗi lựa chọn có thể có SKU, ảnh, giá hoặc tồn kho riêng. Nếu chỉ xuất sản phẩm cha với mức giá “từ”, người mua có thể mở một URL không chọn đúng biến thể hoặc thấy một mức giá khác. Cần xác định đầu ra nào đại diện cho item có thể mua, theo yêu cầu của kênh.
Trong WooCommerce, đội kỹ thuật nên làm việc với API/CRUD của sản phẩm và variation, thay vì đoán từ tên hiển thị hoặc truy vấn cột tùy chỉnh không được tài liệu hóa. Plugin xuất feed có thể hỗ trợ mapping, nhưng phải kiểm tra nó đọc giá khuyến mại, stock status và thuộc tính ở cấp nào. Cài plugin thành công không chứng minh feed đã đúng.
Lập bảng mapping trước khi chọn plugin
Ghi từng trường đầu vào, trường đầu ra, cấp dữ liệu và quy tắc fallback. Tên thương hiệu có thể đến từ taxonomy hoặc thuộc tính; mã nhà sản xuất có thể nằm trong custom field. Cần phân biệt thuộc tính dùng để chọn biến thể với mô tả bổ sung. “Chất liệu: cotton” có thể là thuộc tính chung; “Màu: xanh” có thể quyết định một variation cụ thể.
| Dữ liệu nguồn | Rule cần xác nhận | QA |
|---|---|---|
| SKU variation | Khóa ổn định cho từng item | Không trùng, không thay đổi sau mỗi lần xuất |
| Sản phẩm cha | Nhóm các biến thể cùng sản phẩm | Không gom model khác thành cùng nhóm |
| Giá đang bán | Đọc đúng variation và lịch khuyến mại | Khớp giá trên URL đích |
| Stock status | Phân biệt hết hàng, đặt trước và backorder | Khớp điều kiện mua thực tế |
| Ảnh và URL | Chọn đúng biến thể | Mở được, không đổi sang biến thể khác |
Item ID và group ID giải quyết hai việc khác nhau
Mỗi item cần một ID ổn định. Nhóm biến thể cần một ID chung khi kênh yêu cầu. Google dùng item_group_id cho các biến thể phù hợp với quy tắc của họ. Không dùng cùng ID item cho tất cả màu, và không gom các sản phẩm khác bản chất chỉ vì cùng danh mục. Các thuộc tính phân biệt biến thể cũng phải được gửi đầy đủ theo đặc tả.
Ví dụ minh họa: mã cha AO-01, các SKU AO-01-XANH-M và AO-01-XANH-L. Hai item giữ ID riêng, nhóm chung nếu đủ điều kiện, và URL/ảnh thể hiện màu xanh. Nếu size M hết hàng còn L vẫn bán, từng item phải thể hiện đúng tình trạng. Bảng này là ví dụ dữ liệu, không phải case khách hàng đã được Onter triển khai Shopping.
Không tự tạo GTIN để vượt lỗi thiếu dữ liệu
GTIN là mã nhận diện được cấp cho sản phẩm; SKU là mã nội bộ của cửa hàng. MPN là mã của nhà sản xuất. Khi catalog thiếu GTIN, hãy xác minh với nhà cung cấp và áp dụng rule identifier theo nhóm sản phẩm và yêu cầu của kênh. Không sao chép GTIN từ một sản phẩm gần giống hoặc ghép số từ SKU để làm đầy cột.
Với phụ tùng, cần tách mã sản phẩm đang bán khỏi danh sách mã OE/OEM tương thích. Một phụ tùng aftermarket tương thích nhiều mã không có nghĩa mỗi mã đều là MPN của thương hiệu đang bán. Giữ bảng provenance cho dữ liệu để người vận hành biết mã nào do hãng cung cấp, mã nào là tương thích và trường nào chưa xác minh.
Kiểm tra URL và schema của biến thể
URL đích phải dẫn đến đúng lựa chọn và khách có thể đặt mua theo giá gửi đi. Thử mở trên thiết bị chưa có cookie, không đăng nhập và sau khi xóa cache. Nếu trạng thái chọn biến thể chỉ tồn tại trong localStorage, máy đọc từ URL mới có thể thấy một lựa chọn khác. Cần sửa cơ chế URL/trang đích hoặc mapping để thông tin không phụ thuộc vào phiên của quản trị viên.
Google hướng dẫn dùng ProductGroup cùng các thuộc tính liên quan khi mô tả biến thể trong structured data. Không áp dụng máy móc một canonical chung cho mọi tình huống: chiến lược trang đơn và nhiều trang cần đối chiếu tài liệu Product variants. Schema và feed phải nói về cùng tập sản phẩm và cùng mức giá, dù tên trường khác nhau.
Chọn lịch cập nhật theo tốc độ thay đổi dữ liệu
Cửa hàng ít SKU vẫn có thể cần cập nhật nhanh nếu tồn kho thay đổi liên tục. Ngược lại, catalog lớn nhưng chỉ báo giá cần xác định rõ sản phẩm nào có giá mua được và phù hợp với chương trình Shopping. Trước khi đặt cron, đo thời gian tạo feed, dung lượng, giới hạn máy chủ và thời gian kênh tiếp nhận xử lý.
Nếu xuất toàn bộ catalog mất lâu, cân nhắc snapshot định kỳ cùng cập nhật theo sự kiện trong phạm vi tích hợp được hỗ trợ. Có lock tránh hai lần xuất ghi đè nhau, cơ chế ghi file tạm rồi thay thế và thông báo khi bản xuất mới thất bại. Giữ bản tốt gần nhất với dấu thời gian rõ ràng; không âm thầm giữ dữ liệu cũ mà báo đồng bộ thành công.
Checklist nghiệm thu feed WooCommerce
- Đếm riêng sản phẩm cha, variation, item hợp lệ và item bị loại
- Kiểm tra ID ổn định sau hai lần xuất cùng catalog
- Kiểm tra sản phẩm có sale, hết hạn sale, hết hàng và backorder
- Mở URL từng biến thể trong phiên mới và đối chiếu ảnh/giá
- Kiểm tra thuộc tính màu, size, model và đơn vị đo
- Kiểm tra lỗi encoding tiếng Việt, ký tự XML và đường dẫn ảnh
- Xác minh GTIN/MPN/brand theo nguồn, không sinh mã giả
- Đối chiếu schema, HTML và feed bằng cùng timestamp
- Kiểm tra log export, fetch/ingestion và trách nhiệm xử lý lỗi
Google feed có thể gửi nguyên trạng sang OpenAI không?
Không nên giả định. Dùng cùng nguồn catalog rồi mapping theo đặc tả và phương thức tích hợp đã được xác nhận. OpenAI hiện yêu cầu đối tác được chấp thuận để onboarding. Một feed Google hợp lệ không tự cấp quyền gửi feed hoặc checkout trong ChatGPT.
Nếu đang gặp price/availability mismatch, xem quy trình sửa lệch giá và tồn kho Merchant Center. Với nhu cầu triển khai mapping, export và QA, xem Product Feed & AI Shopping của Onter.
