ASIN Creation і brand authorization: що перевірити українському продавцю перед appeal

11 травня у Seller Forums продавці знову обговорювали notices про створення ASIN для Brand Registered products без brand authorization: частина команд пише про десятки policy records, запити на LOA або invoices і плутанину між Add Products, ASIN creation та Brand Registry ролями. Це не треба подавати як доказ раптового нового правила для всіх. Джерелом правди залишається конкретний notice у вашому Seller Central.

Для українських Amazon-продавців і команд у Східній Європі ризик особливо неприємний: закупівля може бути реальною, товар може бути оригінальним, але Amazon може перевіряти не тільки походження товару. Питання може бути в тому, хто створив branded ASIN, хто має право змінювати brand attribute, чи є approval від brand owner і чи не змішали ви каталоговий дозвіл з доказом автентичності.

Коротка відповідь: спочатку визначте, що саме перевіряє Amazon

ASIN Creation notice часто виглядає як звичайна listing deactivation, але логіка може бути іншою. Amazon може тестувати catalog authority, Brand Registry relationship, seller approval, product identity, GTIN/UPC, variation fit або authenticity evidence. Якщо відповісти одним загальним Plan of Action, рев'юер може не побачити найважливіший факт: чому саме ваш акаунт мав право створити або контролювати цей branded ASIN.

• Якщо notice згадує ASIN Creation Policy, 5461, Catalog Authorization або Brand Registered product, почніть з каталогу і права на створення ASIN.
• Якщо Amazon просить invoices за 365 днів, перевіряйте не лише дату і кількість, а й supplier authority, buyer name, адреси, SKU/model match і зв'язок з брендом.
• Якщо є LOA, вона має показувати, кого бренд уповноважив, на які товари, marketplace, строк, legal entity і тип дії: selling, listing creation, distribution або Brand Registry role.
• Якщо ви тільки додали offer до існуючого ASIN, а notice говорить про ASIN creation, зафіксуйте історію дій: Add Products, feed submission, batch ID, created-by signal, case IDs і дату першого policy record.

Зберіть доказовий пакет до першої відповіді

У офіційному поясненні Amazon щодо Error Code 5461 наголошується на реальних фото товару й упаковки, brand name, manufacturer, UPC/EAN/JAN або GTIN exemption, product category, title, description, feed batch ID і посиланні на сторінку товару у бренду або іншого retailer. Для української команди це означає: не перекладайте весь тягар на один PDF від постачальника.

• Фото: товар у руках або на столі, передня і задня сторона, упаковка, barcode/GTIN, brand name, модель, розмір, колір і package quantity.
• Каталог: ASIN, SKU, parent/child structure, brand field, manufacturer, GTIN exemption status, feed processing report і всі recent edits.
• Джерело: invoices, payment proof, supplier website, relationship with brand owner, distributor status і листування про право продавати або створювати listing.
• Brand authorization: LOA, reseller authorization, Brand Registry selling role або інший approval, який прямо збігається з legal entity у Seller Central.
• FBA exposure: shipment IDs, stranded inventory, removal eligibility, sellable units і ризик, що listing removal заблокує inventory action.

Розділіть три маршрути: каталог, IP і автентичність

Найчастіша помилка - доводити все одразу. Якщо Amazon каже, що проблема у створенні branded ASIN, справа ближча до ASIN/listing deactivation. Якщо rights owner скаржиться на використання бренду, фото, trademark або контент, підключається intellectual property. Якщо Amazon сумнівається, чи товар справжній або чи supplier verifiable, це вже authenticity або supply-chain route.

• Для catalog route поясніть, яку дію зробила команда: створення нового ASIN, додавання offer, зміна brand field, варіація або feed update.
• Для IP route покажіть, чи є rights-owner permission, чи використовувалися protected images/copy, і чи сторінка не вводила покупця в оману.
• Для authenticity route покажіть traceability: хто продав товар, як supplier пов'язаний з брендом, які quantity match і чому документ можна перевірити.
• Не називайте notice помилкою Amazon, якщо не можете показати альтернативну хронологію дій і документів.

Що зробити з активними offer, FBA inventory і старими cases

Поки notice відкритий, не варто масово видаляти listing, створювати duplicate ASIN або відкривати десять cases з однаковим текстом. Так можна втратити історію, погіршити FBA inventory route і зробити Account Health dashboard менш зрозумілим. Краще скласти контрольний список по кожному affected ASIN.

• Позначте ASIN, де є open policy record, active appeal button, reinstated status або pending review.
• Окремо випишіть ASIN, де listing active, але policy record ще не зник з Account Health.
• Не створюйте нову сторінку для того самого branded product, доки не зрозуміло, чи Amazon забороняє саме creation path.
• Якщо FBA inventory ризикує застрягнути, збережіть shipment, inventory і removal screenshots до будь-яких правок.
• Після відповіді ведіть case log: case ID, дата, який документ подано, що саме Amazon прийняв або відхилив.

Практичний висновок: ASIN Creation notice треба вести як вузьку діагностику каталогу і brand authorization, а не як універсальну апеляцію про чесний бізнес. Якщо головне питання - право створити або контролювати branded ASIN, починайте з маршруту ASIN/listing deactivation. Якщо в notice видно IP або authenticity шар, розділіть його окремо, перш ніж ще одна відповідь закріпить неправильну теорію справи.