Продуктовият фийд за Google Merchant Center предава данни за отделните артикули: какво се продава, на кой адрес, на каква цена и с каква наличност. Ако файлът казва едно, а посетителят вижда друго, технически успешното подаване не решава проблема. Първата проверка е съответствието между записа, продуктовата страница и условията за покупка.
Това ръководство е за подготовка и проверка на данните. Не описва одобрен клиентски Merchant Center акаунт и не обещава показвания, безплатна реклама или приемане на всички артикули. Допустимостта зависи и от магазина, пазара, продуктовата категория и действащите правила.
Учебен фийд с три измислени артикула
Изтеглете примерния XML фийд. Той съдържа чаша и два размера на чанта, обозначени като учебни примери. Адресите са към example.invalid и не водят към реален магазин. Файлът е за разглеждане на структурата и локална проверка, не за подаване в Merchant Center.
В примера има идентификатор, заглавие, описание, адрес, изображение, наличност, цена и състояние. Двата размера имат общ item_group_id и различни id. Умишлено няма измислени GTIN номера, действаща доставка или твърдение за одобрение. Преди реална употреба се попълват всички приложими изисквания за действителните продукти и целевия пазар.
| id | Избран вариант | price | availability |
|---|---|---|---|
| DEMO-CUP | Примерна чаша | 8.00 EUR | in_stock |
| DEMO-BAG-S | Примерна чанта, малка | 15.00 EUR | in_stock |
| DEMO-BAG-L | Примерна чанта, голяма | 17.00 EUR | out_of_stock |
Идентификаторът свързва всички проверки
Използвайте постоянен код за един и същи артикул. Заглавието може да бъде редактирано, но не сменяйте id само защото сте пренаписали описанието. Иначе сравнението между стария запис и новия става трудно. SKU може да е подходящ източник, ако действително е уникален и устойчив.
Спецификацията на Google за id изисква отделен идентификатор за всеки продукт и вариант. В учебния пример DEMO-BAG-S и DEMO-BAG-L не могат да споделят едно id, защото имат различни размери, цени и наличности. Общото семейство се описва отделно.
За реален каталог направете проверка за повтарящи се кодове, празни стойности и кодове, които се различават само по главни букви. Не използвайте позицията на реда като единствен идентификатор: сортирането на таблицата би променило връзката. Не присвоявайте стар код на съвсем нов продукт.
Цената трябва да е за същия вариант
Най-честият въпрос при несъответствие е „Коя цена сравняваме?“. Проверете дали адресът от записа отваря точно избрания размер, а не обща страница с по-евтин вариант по подразбиране. В примера малката чанта е 15.00 EUR, а голямата — 17.00 EUR. Отварянето на грешния вариант би направило сравнението подвеждащо.
Изискванията за price описват сума и валута и съответствие с продуктовата страница и завършването на покупката. За пазари като ЕС подавайте цена с включен ДДС, когато той е приложим, съгласно същите изисквания на Google. Сравнявайте я с крайната продуктова цена на страницата и при покупка, не с вътрешна стойност без данъка. Не смесвайте цена на единичен артикул с цена на комплект. При намаление проверете кои стойности се подават и за какъв период важат, вместо да заменяте редовната цена с приблизителна отстъпка.
Когато търговецът промени цена, запишете последователността: обновен каталог, обновена страница, генериран файл и получен нов запис. Стар кеш или стар файл може да остави две различни версии едновременно. Коригирайте източника на разминаването, а не само отделния ред в акаунта, ако той ще бъде презаписан при следващото обновяване.
Наличността има собствена логика
Наличен продукт и продукт, който може да бъде поръчан за бъдеща доставка, не са автоматично едно и също състояние. Уточнете какво означава всяка стойност в магазина. Ако има предварителна поръчка или очаквана доставка, проверете приложимите полета и видимите условия. Не използвайте in_stock само за да избегнете предупреждение.
В учебния фийд голямата чанта е out_of_stock. Това е измислена стойност за упражнението. При реалния продукт сравнете склада, страницата, бутона за покупка и подадените данни. Ако вариантът е изчерпан, наличността на друг размер не трябва да го прави наличен във фийда.
Кои други полета не бива да се попълват по догадка
Общата продуктова спецификация описва задължителните и условните атрибути. Изискванията се различават според продукта и пазара. Проверете действителните идентификатори на производителя, марката, категорията и характеристиките на вариантите. Липсващ баркод не се заменя с произволно число, а липсваща информация не се прикрива с невярно твърдение, че идентификатор не съществува.
Изображението трябва да представя правилния продукт и да е достъпно на подадения адрес. Линк към страница за споделяне или файл зад вход не е равнозначен на директно изображение. При смяна на снимки проверете дали файлът и видимата страница показват същия вариант. За самото продуктово съдържание използвайте проверките на продуктовата страница.
Доставка и процес за покупка
Преди подаване уточнете обслужваните държави, валутите и действителните условия за доставка. Цената и срокът за конкретен район трябва да могат да се проверят според използваната конфигурация. Не копирайте универсално „безплатно“, когато има изключения по тегло или адрес.
Каталог, който приема само индивидуални запитвания с последваща оферта, изисква отделна проверка на допустимостта за избраното представяне в Google. Не превръщайте ориентировъчна цена в покупна цена във фийда. Наличието на XML файл не създава работеща поръчка и не заменя изискванията към търговеца.
Как се работи по конкретна грешка
- Запишете засегнатото id, съобщението и момента на проверката.
- Отворете точно подадения адрес и сравнете избрания вариант, цената и наличността.
- Проверете текущия източник на данни и последното му обновяване.
- Поправете първопричината: каталожна стойност, адрес, правило за вариант или генериране на файла.
- След обработка проверете отново същия артикул, вместо да приемате качването за окончателно одобрение.
Започнете с малък представителен набор, преди да включите целия каталог. Пазете таблица с код, открито разминаване, поправка и резултат от повторната проверка. Отделяйте приети данни, допустимост за показване, действителни показвания и покупки. Това са различни етапи и всеки изисква собствено доказателство.
Чести въпроси
Готов ли е примерният XML за подаване към Google?
Не. Той съдържа измислени артикули и неработещи адреси към example.invalid. Предназначен е за обучение и локална проверка на структурата.
Еднакво ли е id за всички варианти?
Не. Всеки отделен вариант има собствен устойчив идентификатор. Свързаните варианти могат да използват общ item_group_id, когато това съответства на продуктовите данни.
Успешното качване гарантира ли показвания?
Не. Обработката на файла, допустимостта на продуктите, действителните показвания и покупките са различни етапи. Всеки се проверява отделно.