Збір даних в авторизованій сесії часто потребує кількох акаунтів, а обмеження не завжди спричинені самим скриптом. Поділ ризику пов’язування на характеристики пристрою, мережевий вихід, стан сесії та ритм запитів допомагає чітко побачити змінні, які справді можна контролювати.
Збір даних в електронній комерції загалом можна поділити на два типи: збір загальнодоступних сторінок без входу в акаунт і збір в авторизованій сесії, наприклад для перегляду внутрішніх даних конкурентів або отримання результатів, що відображаються після персоналізації.
У першому випадку зазвичай достатньо контролювати частоту. Коли другий тип роботи охоплює кілька акаунтів, успіх залежить уже не стільки від складності скрипту, скільки від того, чи можуть ці акаунти існувати незалежно один від одного. Якщо цей рівень налаштовано погано, обмеження та блокування виглядають випадковими, а зміна скрипту, зниження частоти чи заміна селекторів не дають покращення.
Звідки виникає ризик
Платформи визначають, чи керує кількома акаунтами одна сторона, за допомогою перехресної перевірки сигналів: мережевих адрес, характеристик браузера й пристрою, даних Cookie та сесії, а також моделей використання. Значний збіг хоча б в одній категорії може призвести до того, що акаунти будуть об’єднані як такі, що належать одному оператору.
Тут важливо провести чітку межу. Логіка виявлення постійно оновлюється, тому тимчасові прийоми для протидії їй дають короткий ефект за високої ціни. Нижче не йдеться про те, як обходити контроль ризиків. Корисніше інше питання: коли джерела ризику зрозумілі, які змінні ми можемо контролювати й зберігати стабільними в довгостроковій перспективі? Саме вони визначають, чи впливатимуть кілька легітимних акаунтів один на одного.
Характеристики пристрою та браузера
Один із найпроблемніших варіантів — відкрити на одному комп’ютері кілька вікон і ввійти в них під різними акаунтами. Навіть після очищення кешу або в режимі інкогніто ці вікна продовжують використовувати те саме системне середовище й дані браузера. Характеристики все одно перетинаються, тому платформа бачить один пристрій, який знову й знову змінює ідентичність.
Керований підхід — надати кожному акаунту власне середовище: один акаунт на одне незалежне середовище, з окремими fingerprint, Cookies і локальним сховищем. Головне — закріпити це середовище за акаунтом, а не генерувати випадковий набір під час кожного запуску. Випадкові комбінації часто суперечливі: часовий пояс, мова, роздільна здатність і UA можуть не узгоджуватися, через що така конфігурація виглядає незвичніше за стабільну.
Отже, стабільність походить із послідовності, а не з випадковості.
Мережевий вихід
Вихід має бути прив’язаний до акаунта: одне середовище, один вихід, а регіон виходу повинен відповідати профілю акаунта, часовому поясу та мові. Якщо середовища розділені, але кілька акаунтів використовують один і той самий вихід, значна частина попередньої ізоляції втрачає сенс.
Вихід також має залишатися відносно стабільним. Часті зміни регіону роблять сигнал місцезнаходження акаунта важким для пояснення. Під час вибору виходу адреси житлових мереж зазвичай більше схожі на звичайний користувацький доступ, ніж адреси дата-центрів. Також варто уникати адрес, які вже масово використовувалися, оскільки вони можуть перебувати під пильнішим спостереженням.
Cookies і сесії
Стан сесії сам по собі є профілем ідентичності. Якщо кілька акаунтів використовують ті самі Cookies або локальне сховище, між ними виникає прямий зв’язок незалежно від того, наскільки добре розділені інші середовища.
Сесію в новому середовищі також не варто відразу використовувати з високою інтенсивністю. Краще спочатку накопичити історію звичайного перегляду, а потім поступово збільшувати обсяг завдань. Цей принцип працює й поза збором даних: наявність історії використання безпосередньо впливає на те, яку активність акаунт може розумно витримувати.
Ритм запитів
Щільність запитів — це поведінковий сигнал. Скрипти часто мають характерну регулярність: фіксовані інтервали звернень, незмінний порядок сторінок і відсутність будь-яких дій поза збором даних. Додавання випадкових значень саме по собі не усуває таку регулярність, тому що головна проблема полягає в загальному обсязі.
Керований напрям — утримувати навантаження в розумних межах: розносити час виконання для різних акаунтів, не завантажувати всі акаунти на максимум одночасно, залишати розумні інтервали між сторінками та розділяти завдання високого й низького пріоритету. Межа проста: збір даних не повинен створювати тиск на цільовий сервіс. Будь-яка швидкість, отримана ціною погіршення його роботи, не є виправданою оптимізацією.
Чому фіксоване середовище для акаунта стабільніше за випадкове перемикання
Мета випадкового перемикання — щоразу виглядати інакше, однак перевірки пов’язування оцінюють, чи залишаються сигнали стабільними в різних вимірах і чи не суперечать вони один одному. Якщо акаунт сьогодні виходить з одного місця, а завтра з іншого, і щоразу набір характеристик змінюється, така непослідовність сама стає аномальним сигналом.
Фіксоване середовище працює за протилежною логікою. Від моменту реєстрації акаунт має сталу ідентичність: фіксоване середовище, фіксований вихід, узгоджені часовий пояс і мову та історію сесії, що поступово накопичується. Що довше зберігається ця послідовність, то легше активності бути схожою на поведінку звичайного користувача. Саме в цьому цінність шару середовища: довгострокова стабільність, а не ефектні зміни.
Це також пояснює, чому скрипт збору не повинен сам керувати екземплярами браузера. Середовища мають незалежно плануватися, щоб різним акаунтам можна було призначати власні середовища; їхній стан має бути доступним для перевірки, щоб виявляти аномальні середовища та недійсні акаунти; середовища треба мати змогу звільняти, щоб тривала робота не накопичувала зомбі-екземпляри; а під час повторної спроби виконання завдання збору часто потрібно змінити середовище, що можливо лише за незалежного планування. У такій архітектурі PurpleMark є шаром ресурсів середовища. Скрипт відповідає за логіку збору, а ідентичність і ресурси передаються шару середовища.
Межі дотримання правил
Наступні пункти важливіші за всі згадані вище оптимізації.
Дотримуйтеся умов використання та правил robots цільового сайту. Багато платформ електронної комерції прямо обмежують автоматизований доступ у своїх умовах, тому до початку роботи перевірте, чи дозволений запланований спосіб використання. Збирайте лише загальнодоступну інформацію про товари, ціни та запаси й не збирайте персональні дані. Не обходьте технічні заходи захисту. Якщо трапляються CAPTCHA або зашифровані інтерфейси, змініть стратегію збору або попросіть дозвіл замість спроби зламати захист. Контролюйте частоту запитів незалежно від кількості акаунтів і ніколи не заважайте нормальній роботі цільового сервісу.
Передумова цього обговорення — як кільком легітимним акаунтам залишатися незалежними й не заважати один одному, а не як обходити правила платформи. Перше належить до операційної гігієни; друге — зовсім інше питання.
