Як продавати на Amazon з кількома акаунтами продавця

Політика Amazon щодо множинних акаунтів продавця проста на папері: один акаунт на продавця, якщо тільки немає явного письмового дозволу на другий. На практиці все складніше. Легітимні причини для кількох акаунтів існують — окремі бренди, різні категорії товарів, різні юридичні особи — і Amazon дійсно робить винятки. Проблема не в самій політиці. Проблема в тому, що більшість продавців, які намагаються вести кілька акаунтів, потрапляють під блокування не через те, що продають, а через те, як їхні акаунти пов'язані між собою.

У цьому гайді — операційна сторона питання: що Amazon реально відстежує, як вибудувати акаунти так, щоб вони не впали разом, і де ізоляція оточень вписується в мультиакаунтну схему.

Чому Amazon взагалі пов'язує акаунти

Система спостереження Amazon за продавцями обширна. При кожному вході платформа збирає дані браузерного відбитка, IP-адресу, ідентифікатори пристрою та поведінкові патерни. Ці сигнали порівнюються між усіма акаунтами, що торкаються однієї інфраструктури.

Два акаунти зі спільним IP виглядають пов'язаними. Два акаунти, що входять з одного браузерного профілю, — пов'язані по факту: Amazon бачить ідентичні параметри відбитка і вважає їх однією людиною незалежно від імені на акаунті. Перетин платіжних методів, спільний номер телефону або один банківський рахунок на кілька акаунтів продавця запустять ревʼю майже миттєво.

Суть проблеми в тому, що Amazon перевіряє не тільки ваші дані — він картує оточення, з якого ці дані приходять. Ось чому стандартна порада «просто використай інший email» настільки безкорисна. Email — останнє, на що вони дивляться.

Законні підстави для кількох акаунтів

Перш ніж переходити до інфраструктури, потрібно розуміти: кейс має бути обґрунтованим. Amazon дозволяє кілька акаунтів за певних умов:

Окремі юридичні особи. Якщо ви керуєте двома по-справжньому різними бізнес-структурами — різні LLC або ТОВ, різні ІПН, різні платіжні рахунки — Amazon швидше схвалить другий акаунт. Бізнеси мають бути незалежно верифікованими, а не просто різними назвами на одному банківському рахунку.

Різні бренд-портфоліо. Продавці з відчутно різними брендами — особливо тими, що працюють з різними сегментами покупців або категоріями товарів — мають вагоміший аргумент. Бренд професійного аудіообладнання і окремий бренд дитячих іграшок — це чистий поділ, на відміну від двох схожих магазинів.

Явний дозвіл Amazon. Якщо є легітимний кейс, можна запросити дозвіл напряму через Seller Central. Це не гарантія, але схвалена дворакаунтна операція має принципово інший профіль ризику, ніж несанкціонована.

Без однієї з цих підстав ведення кількох акаунтів є порушенням політики, яким би якісним не було розділення оточень. Ізоляція знижує ризик виявлення — вона не змінює суть дій.

Структура акаунтів: що має бути окремим

Якщо законна підстава є, операційна структура має величезне значення. Кожному акаунту потрібен власний повний стек ідентичності:

• Окрема юридична особа (LLC, ТОВ, ФОП)
• Окремий банківський рахунок і платіжний метод
• Окремий номер телефону для верифікації та 2FA
• Окрема email-адреса та історія адрес
• Окремі дані для входу в Seller Central

Ніщо з цього не може збігатися. Спільний номер телефону між двома акаунтами — достатній привід для ревʼю за ознакою пов'язаності. Маркетплейсна логіка Amazon побудована на тому, що цілісність акаунта оцінюється комплексно: одна спільна точка даних здатна розкрити весь зв'язок.

Саме тому купівля прогрітого акаунта або отримання акаунта продавця від когось іншого несе в собі ризик: разом із ним ви успадковуєте чужу історію, пов'язані дані та минулі порушення.

Ізоляція оточень: те, що більшість продавців упускає

Чисті юрособи і роздільні дані — це половина справи. Друга половина — браузерне оточення: той шар, який Amazon не бачить із ваших документів, але зчитує при кожному вході.

Браузерний відбиток. Кожна браузерна сесія випромінює відбиток: GPU-рендерер, Canvas-хеш, встановлені шрифти, геометрія екрана, hardware concurrency, navigator-властивості. Два акаунти з ідентичними відбитками флагуються як один оператор незалежно від реєстрації бізнесу за ними. Цифровий відбиток — саме те, через що мультиакаунтинг у спільному браузері так стабільно детектується.

IP-адреса. У кожного акаунта має бути виділений проксі — резидентний або мобільний, ніяких датацентрових. Резидентні проксі, прив'язані до гео білінгової країни зареєстрованої сутності, — найчистіший варіант. Спільні IP між акаунтами або IP, що вже засвітилися на Amazon, створюють миттєвий ризик.

Ізоляція кукі. Сесії мають бути повністю розділені. Ізоляція кукі на рівні браузерного профілю гарантує, що сесії входу, трекінгові кукі та дані сесій Amazon з одного акаунта не потраплять до іншого. Це важливіше, ніж очікує більшість продавців: відстеження сесій Amazon є персистентним і активно перехресно перевіряє дані.

Окремий профіль для кожного акаунта. На практиці — один браузерний профіль на один акаунт продавця, з власним постійним відбитком, власним проксі та власним сховищем кукі. Керувати цим вручну через кілька акаунтів без спеціалізованих інструментів ненадійно вже при масштабі більше двох.

Керування сесіями без перехресного забруднення

Навіть при добре вибудованих профілях більшість зв'язок відбувається через операційні помилки. Патерни, через які продавців ловлять:

Вхід у два акаунти з одного профілю. Навіть один раз. Навіть «просто перевірити». Історія сесії записується в цей профіль, і відбиток тепер пов'язаний з обома акаунтами.

Перемикання акаунтів без перемикання оточень. Закрити вкладку і відкрити нову в тому самому браузерному вікні не змінює відбиток, кукі та IP. Перемикання оточення має бути повним — інший профіль, інша проксі-сесія.

Спільні пристрої серед членів команди. Співробітник підтримки, який обробляє повернення для двох різних акаунтів продавця зі свого особистого ноутбука, щойно пов'язав ці акаунти. Командний доступ має керуватися через призначені профілі, а не через спільні логіни на особистих пристроях.

Резервне копіювання і відновлення. При переїзді на нову машину або відновленні налаштувань акаунта перенесення браузерних даних зі старого оточення може повернути старі відбитки. Експорт та імпорт кукі мають відбуватися на рівні профілю, а не на рівні браузера, щоб оточення залишалися чистими.

Базові принципи керування мультиакаунтами працюють тут незалежно від платформи — механіка ізоляції сесій однакова що для акаунтів продавця, що для профілів у соцмережах.

Що відбувається, коли акаунт потрапляє під флаг

Процес блокування в Amazon для пов'язаних акаунтів зазвичай іде за одним сценарієм: спочатку флагується один акаунт, що запускає ревʼю пов'язаних. Якщо зв'язок очевидний — однаковий IP, однаковий відбиток, однаковий платіжний метод — всі пов'язані акаунти блокуються одночасно.

Апеляції можливі, але складні. Amazon вимагає документального підтвердження того, що акаунти — дійсно окремі операції: різні реєстрації бізнесу, різні банківські виписки, різні фізичні адреси. Якщо в їхніх логах видно і зв'язок на рівні оточення, одного документального підтвердження корпоративного розділення не вистачить.

З точки зору проксі та конфігурації профілів — це аргумент на користь інвестицій у нормальну ізоляцію з самого початку, а не її вибудовування після блокування. Ретроспективно розділити акаунти, які вже були пов'язані в системі Amazon, значно складніше, ніж спочатку зробити все правильно.