Target пов’язує акаунти за характеристиками пристрою, способами оплати, адресами доставки та поведінкою під час входу. У статті пояснено основні сигнали зв’язку та вимоги до середовища й даних акаунтів.
Target — друга за величиною роздрібна платформа у США після Walmart. Вона охоплює повсякденні товари, товари для дітей, одяг, електроніку та товари для дому. Велика база користувачів і стабільний трафік також роблять її привабливою для багатьох міжнародних команд, які вибудовують роботу з акаунтами.
Останніми роками контроль ризиків став суворішим і чутливо реагує на масові входи, незвичні пристрої та часті зміни платіжних адрес. Багато хто вважає, що проблем не буде, якщо акаунти не заважають один одному безпосередньо, але на практиці платформа аналізує цілий набір характеристик і оцінює їх у сукупності.
Платформа бачить не лише акаунт, а й набір характеристик пристрою та браузера
Cookies — лише один з елементів. Браузер також передає User-Agent, версію рушія, часовий пояс і мову, операційну систему, роздільну здатність екрана та список установлених шрифтів; на графічному рівні враховуються результати рендерингу Canvas, звіти WebGL і модель GPU; на рівні сховища — Cookies, LocalStorage та IndexedDB. Сукупності цих параметрів достатньо, щоб відрізнити один пристрій від іншого.
Якщо кілька акаунтів використовують один комп’ютер і один браузер, ці параметри значною мірою збігаються. Платформі не потрібно встановлювати, хто саме за екраном: узгоджений слід пристрою сам по собі може бути підставою для висновку про зв’язок акаунтів.
Три лінії сигналів: оплата, адреса та місце входу
Інформацію, пов’язану з ідентичністю, пояснити ще складніше, ніж дані пристрою. Адреса доставки, спосіб оплати та прив’язаний номер телефону зазвичай вважаються ключовими параметрами ідентичності. Якщо один акаунт повторно використовує ці дані іншого акаунта або змінює лише кілька символів, зв’язок усе одно може бути встановлений.
Місце входу — ще одна лінія сигналів. Можуть враховуватися регіон вихідної IP-адреси, тип провайдера — домашня мережа чи дата-центр — та відповідність регіону реєстрації акаунта. Швидкі переходи між країнами й кілька акаунтів з однієї підмережі є помітними сигналами.
Фіксується і ритм поведінки. Миттєві кліки, незмінний маршрут переходів та відсутність часу на сторінці в системі майже не відрізняються від дій за скриптом.
Чому кілька акаунтів легко об’єднуються в один висновок про зв’язок
Якщо розглядати всі ці сигнали разом, проблема стає очевидною: коли кілька акаунтів використовують одне середовище й схожу структуру даних, а також виконують подібні дії приблизно в один час, система перестає сприймати їх як незалежних користувачів і бачить кілька слідів однієї операції.
Тому зміна лише одного елемента мало що дає. Заміна IP при збереженні того самого середовища або зміна даних при збереженні шаблонної структури адреси залишають ознаки зв’язку.
На рівні середовища важливо не допускати перетинів
Для команд, яким справді потрібно працювати з кількома акаунтами, вимога до середовища проста: у кожного акаунта має бути окреме браузерне середовище, а відбиток, Cookies, локальне сховище та мережевий вихід не повинні перетинатися з іншими акаунтами. Стан входу, кеш і вихідні IP також не слід змішувати.
Інструменти, спеціально створені для ізоляції середовищ кількох акаунтів, наприклад PurpleMark, вирішують саме це завдання: браузерне середовище та мережеві налаштування кожного акаунта залишаються окремими, і не потрібно вручну пам’ятати, який комп’ютер відповідає якому акаунту.
У мережевого виходу є ще один момент, який легко пропустити: регіон і тип мають залишатися стабільними в довгостроковій перспективі. Акаунт, який постійно використовує вихід з одного регіону, більше схожий на звичайного користувача, ніж акаунт із частими перемиканнями. Масово повторно використовувані IP дата-центрів самі по собі є сигналом високого ризику.
Дані акаунта мають відповідати реальному суб’єкту
Проблема реєстраційних даних не в тому, наскільки вони випадкові, а в тому, чи відповідають вони реальному суб’єкту. Якщо той самий суб’єкт повторно використовує адресу доставки, спосіб оплати або контактні дані в кількох акаунтах, зміна способу написання не усуває зв’язок.
Також не рекомендується масово заповнювати форми дуже схожими даними: однаковими схемами імен, подібними назвами електронної пошти або адресами, що відрізняються лише кількома цифрами. Механізми порівняння схожості на платформі розраховані саме на такі комбінації, тому цілу групу акаунтів можуть обробити разом.
Нормальний ритм роботи природно містить варіативність
Нові акаунти на початковому етапі зазвичай спостерігаються уважніше, що є звичною практикою платформ. Але реальна поведінка людини природно містить паузи та варіативність: тривалість перегляду нерівномірна, маршрути не повторюються точно, а перед замовленням люди вагаються й порівнюють варіанти.
Тому практичніше не створювати розклад із точністю до хвилини, а дозволити поведінці акаунта відповідати реальним потребам бізнесу. У даних можна помітити різницю між діями, викликаними реальною потребою, і діями, створеними лише для заповнення шаблону.
Стабільність походить із самого бізнесу
Складність роботи з кількома акаунтами полягає не в тому, чи можна технічно все реалізувати, а в тому, чи вдасться зберігати стабільність у довгостроковій перспективі. Розділені середовища, дані, що відповідають реальному суб’єкту, і поведінка, заснована на реальній діяльності, створюють надійну основу. Якщо будь-який елемент тримається на штучних конструкціях або непотрібній активності, наслідки з часом можуть повернутися у вигляді обмежень акаунта.
