Amazon оцінює зв’язки між обліковими записами за збігами в реєстраційних даних, характеристиках пристрою й браузера, мережевому виході, платежах і виплатах, а також у товарах та операційній поведінці. Для кількох магазинів кожну категорію потрібно ізолювати, бо один спільний елемент може зруйнувати всю схему розділення.
Під час одночасної роботи з кількома магазинами Amazon справжня проблема полягає не лише в тому, що один магазин може зіткнутися з труднощами. Значно гірше, якщо спільні ознаки з’єднають кілька магазинів у єдину мережу. Amazon не визначає зв’язок між обліковими записами за одним фактором. Платформа порівнює багато сигналів, і що більше з них збігається, то сильніше активність схожа на роботу одного й того самого оператора.
Умовно ці сигнали можна поділити на п’ять категорій: реєстраційні дані, характеристики пристрою й браузера, мережевий вихід, платежі та виплати, а також товари й операційна поведінка. Під час роботи з кількома магазинами кожна з цих п’яти категорій має бути незалежною; недостатньо ізолювати лише одну.
Рішення ґрунтується на накладанні сигналів
Платформа постійно збирає дані під час реєстрації, входу та подальшої роботи. Один окремий параметр зазвичай мало про що свідчить: якщо працівники двох компаній в одному місті входять у систему, саме по собі це нормально. Але ситуація змінюється, якщо одночасно збігаються електронна пошта, номер телефону, рахунок для виплат, параметри пристрою та адреса мережевого виходу.
Тому запобігання зв’язкам полягає не в пошуку прихованого налаштування, а в тому, щоб між п’ятьма категоріями інформації не було перетинів. Спільний елемент у будь-якій категорії може звести нанівець ізоляцію, створену в інших.
Реєстраційні дані найпростіше пропустити
Цей шар заповнюється вручну, тому його найпростіше випадково скопіювати. Електронна пошта, номер телефону, контактні дані, адреса повернення та відомості про юридичну особу магазину мають однозначно відповідати конкретному магазину.
Поширена помилка — використовувати один номер телефону для отримання кодів підтвердження кількох магазинів. У системі цей номер стає ниткою, що пов’язує магазини, і може показати зв’язок навіть раніше, ніж адреса мережевого виходу. Повністю однакова адреса повернення має схожий ефект.
Пристрої та браузери залишають сліди
Можуть фіксуватися cookies, кеш, локальне сховище, особливості canvas- і графічного рендерингу, список шрифтів, роздільна здатність та апаратні параметри.
Важлива і внутрішня узгодженість. Часовий пояс і мова, які повідомляє браузер, мають відповідати регіону мережевого виходу, налаштованому для магазину. Навіть окремі параметри, що суперечать один одному, утворюють неприродну комбінацію. Постійне перемикання між панелями кількох магазинів в одному браузері також важко справді розділити на рівні характеристик, навіть якщо щоразу очищати дані.
Мережевий вихід не можна налаштовувати абияк
Спільний мережевий вихід для кількох магазинів — один із найпряміших сигналів зв’язку. Часті зміни регіону виходу та повторювані схожі діапазони адрес одного провайдера також можуть враховуватися під час оцінювання.
Має значення і якість виходу. Діапазони адрес дата-центрів зазвичай мають нижчу репутацію, ніж residential-діапазони. Якщо група магазинів користується такими адресами, виникає ще одна спільна ознака.
Платежі та виплати можуть пов’язати дві юридичні особи
Рахунок для виплат має відповідати юридичній особі магазину й не перетинатися з іншими магазинами. Те саме стосується способу оплати, з якого списуються комісії.
Цей шар важливий, бо містить і дані про юридичну особу, і напрямок руху коштів. Якщо два магазини користуються однією карткою або одним рахунком для виплат, платформа бачить не лише технічну схожість, а й можливу спільність оператора бізнесу.
Збіги в товарах і робочому ритмі
Однаковий набір зображень товарів у кількох магазинах, дослівно скопійовані частини описів або повністю однакові внутрішні правила SKU створюють помітні шаблони повторення. Щонайменше основні частини зображень та описів слід переробити.
Поведінкові сигнали ще детальніші: час входу, ритм публікації товарів, темп відповідей і моменти обробки замовлень. Якщо кілька магазинів постійно роблять одне й те саме в один і той самий час, шаблон стає очевидним. Взаємні відгуки чи рекомендації між магазинами самі створюють структуру зв’язку, наслідки якої часто більші, ніж очікується.
Для кількох магазинів потрібна повна система ізоляції
Зберігати незалежність усіх п’яти категорій надто складно, щоб покладатися лише на пам’ять. Коли масштаб зростає, потрібна підтримка на рівні інструментів: групувати середовища за магазинами, окремо зберігати стан входу та параметри fingerprint кожного середовища, а права команди розподіляти за магазинами. Можливості PurpleMark для багатопрофільних середовищ розраховані саме на такі сценарії.
Кілька конкретних запитань
Чи можуть кілька магазинів використовувати одну бізнес-ліцензію? Це питання політики платформи. Вимоги відрізняються залежно від marketplace і можуть змінюватися з часом, тому орієнтуватися треба на актуальні правила платформи.
Чи достатньо змінити адресу мережевого виходу? Ні. Мережа — лише одна з п’яти категорій; середовище та дані облікового запису теж мають залишатися незалежними.
Чи можуть магазини відправляти товари один одному? Потрібна велика обережність. Перетини адрес відправлення та логістичної інформації також можуть використовуватися як сигнал зв’язку.
На практиці обхідного шляху немає: суть у тому, щоб одночасно зберігати незалежність усіх п’яти вимірів. Корисно зробити порівняльну таблицю: один рядок на кожен вимір, один стовпець на кожен магазин, а потім перевіряти кожну комірку на незалежність. Це значно надійніше, ніж покладатися на пам’ять.
