GTIN, MPN і бренд у Merchant Center: що робити, якщо немає штрихкоду
У каталозі є артикул, назва й фотографія товару, але колонка зі штрихкодом порожня. Поставити всюди identifier_exists=no здається швидким рішенням. Спочатку потрібно встановити причину: виробник не призначав ідентифікатор чи продавець ще не отримав його дані.
Нижче — порядок перевірки для продавця й фахівця з товарних фідів: як розрізнити ключі, вибрати підтверджені значення та перевірити кілька позицій перед масовим оновленням. Приклади умовні; вони не є даними реального виробника.
Спочатку розділіть внутрішній ID, GTIN і MPN
g:id — ключ пропозиції у вашому джерелі даних. Він допомагає зберегти її зв’язок між оновленнями. SKU чи внутрішній артикул може виконувати цю роль у налаштованому процесі, але не стає через це штрихкодом виробника.
GTIN — стандартизований номер торгової одиниці. Для g:gtin беруть підтверджений код саме цього товару. MPN — номер деталі або моделі, призначений виробником; він розрізняє його продукцію. Brand — бренд товару, а не автоматично назва продавця. Зберігайте ці значення в окремих полях і не копіюйте один внутрішній артикул у всі три колонки.
Правила GTIN та MPN прямо радять не вгадувати значення. Універсальна підстановка на кшталт «назва магазину + порядковий номер» не підтверджує виробничого ідентифікатора.
Код невідомий чи справді не призначений?
| Що встановлено | Наступна дія |
|---|---|
| Є підтверджений GTIN потрібного варіанта | Передайте його в g:gtin; перевірте інші застосовні атрибути. |
| GTIN не призначено, але є справжні MPN і бренд | Використайте підтверджені g:mpn і g:brand. Відсутність GTIN не означає відсутності всіх UPI. |
| Призначених унікальних ідентифікаторів справді немає | Перевірте застосовність identifier_exists=no за правилами Google. |
| Дані ще не отримані або суперечать одне одному | Уточніть їх у виробника чи постачальника. Позначте позицію для розбору, не вигадуйте код. |
За документацією identifier_exists, значення no або false доречне, коли ви впевнені, що призначених UPI немає. Для текстових і XML-джерел підтримуються англійські yes, true, no, false. Українське «ні» не є заміною технічного значення.
Практично корисно вести окремий робочий статус «чекаємо уточнення». Він не є атрибутом Google. До нього можна додати джерело запиту, дату та конкретну невизначеність: наприклад, два номери для різних кольорів в одному рядку прайсу. Так невідомі дані не перетворяться на хибне твердження про відсутність коду.
Два XML-фрагменти з різним змістом
У першому вигаданому сценарії виробник не призначав GTIN, але підтвердив бренд ПрикладВиробник та MPN LAMP-A-BLUE. Внутрішній ID магазину зберігається окремо:
<item xmlns:g="http://base.google.com/ns/1.0">
<g:id>STORE-0012-BLUE</g:id>
<g:brand>ПрикладВиробник</g:brand>
<g:mpn>LAMP-A-BLUE</g:mpn>
<g:identifier_exists>yes</g:identifier_exists>
</item>У другому сценарії йдеться про умовний індивідуальний виріб без призначених GTIN, MPN і бренду. Після підтвердження цієї обставини фрагмент має інший зміст:
<item xmlns:g="http://base.google.com/ns/1.0">
<g:id>HANDMADE-0007</g:id>
<g:identifier_exists>no</g:identifier_exists>
</item>Перевіряйте конкретний варіант
Синя й помаранчева лампи можуть мати схожі назви, але код синьої не слід переносити на помаранчеву. Google окремо наголошує на правильному GTIN для кожного варіанта, зокрема кольору чи розміру. Код групи товарів також не замінює код окремої торгової одиниці.
Із MPN є нюанс: за правилами MPN різні варіанти зазвичай мають власні номери, але розміри одягу часто можуть мати спільний MPN. Не створюйте нові номери самостійно лише для того, щоб усі рядки відрізнялися.
Візьміть дві картки однієї моделі та складіть контрольну пару: фотографія упаковки → рядок постачальника → картка магазину → запис у фіді. Якщо ланцюжок розривається на будь-якому кроці, перевірте відповідність до масової операції. Збіг назв допомагає людині читати каталог, але не доводить тотожність варіантів.
Що доводить перевірка штрихкоду
Перевірка довжини та контрольної цифри виявляє частину помилок введення. Вона не встановлює, кому належить номер і який товар ним позначено. Навіть математично коректний код може бути кодом іншої комплектації.
У специфікації GTIN є також обмежені та купонні діапазони. Тому позитивний результат одного checksum-тесту не означає, що значення відповідає всім правилам Google. Для автоматичної первинної перевірки можна скористатися нашим офлайн XML-чекером: він перевіряє довжину й контрольну цифру переданого GTIN, але не його належність товару.
Перед масовим оновленням
- Збережіть вихідний файл і джерело підтвердження кодів. Для невідомих позицій залиште конкретне питання до постачальника.
- Виберіть кілька різних випадків: товар із GTIN, позицію з MPN без GTIN, виріб без призначених UPI та пару варіантів.
- Звірте поля у фактично сформованому XML. Правильна колонка в таблиці ще не доводить правильне зіставлення під час експорту.
- Переконайтеся, що внутрішні ID не змінилися, а підтверджений код потрапив до потрібної пропозиції.
- Після оновлення джерела перевірте актуальні повідомлення Merchant Center. Збережіть дату, ID позиції та зміст залишеної проблеми.
Зміна атрибутів не гарантує схвалення товару або рекламного акаунта. Якщо повідомлення лишилося, розбирайте конкретну пропозицію за її фактичними даними; не вимикайте ідентифікатори для решти каталогу навмання.
Базову структуру й технічні перевірки описано в чеклісті товарного XML-фіда. Якщо проблема стосується вже різних цін або залишків, перейдіть до розбору невідповідності ціни та наявності.
Готуєте каталог для власного магазину?
Перегляньте актуальні можливості платформи й створіть обліковий запис Shopcore. Вихідні коди виробника варто впорядкувати ще під час підготовки каталогу: так легше перевірити, які дані переходять до карток та зовнішніх джерел.