Сбор данных в авторизованной сессии часто требует нескольких аккаунтов, а ограничения далеко не всегда связаны с самим скриптом. Если разделить риск связывания на характеристики устройства, сетевой выход, состояние сессии и ритм запросов, становится понятнее, какие переменные действительно можно контролировать.
Сбор данных в электронной коммерции можно условно разделить на два типа: сбор общедоступных страниц без входа в аккаунт и сбор в авторизованной сессии, например для просмотра внутренних данных конкурентов или получения результатов, отображаемых после персонализации.
В первом случае обычно достаточно контролировать частоту. Когда второй тип работы включает несколько аккаунтов, успех зависит уже не столько от сложности скрипта, сколько от того, могут ли эти аккаунты существовать независимо друг от друга. Если этот уровень настроен плохо, ограничения и блокировки выглядят случайными, а изменение скрипта, снижение частоты или замена селекторов не дают улучшения.
Откуда возникает риск
Платформы определяют, управляются ли несколько аккаунтов одной стороной, с помощью перекрёстной проверки сигналов: сетевых адресов, характеристик браузера и устройства, данных Cookie и сессии, а также моделей поведения. Сильное совпадение хотя бы в одной категории может привести к тому, что аккаунты будут объединены как принадлежащие одному оператору.
Здесь важно провести границу. Логика обнаружения постоянно обновляется, поэтому попытки противодействовать ей временными приёмами дают краткий эффект при высокой цене. Ниже не рассматривается обход систем контроля риска. Полезнее другой вопрос: когда источники риска понятны, какие переменные мы можем контролировать и сохранять стабильными в долгосрочной перспективе? Именно они определяют, будут ли несколько легитимных аккаунтов влиять друг на друга.
Характеристики устройства и браузера
Один из самых проблемных вариантов — открыть на одном компьютере несколько окон и войти в них под разными аккаунтами. Даже после очистки кэша или в режиме инкогнито эти окна продолжают использовать одну системную среду и данные браузера. Характеристики по-прежнему пересекаются, и платформа видит одно устройство, которое постоянно меняет идентичность.
Управляемый подход — выделить каждому аккаунту собственную среду: один аккаунт на одну независимую среду, с раздельными fingerprint, Cookies и локальным хранилищем. Главное — закрепить эту среду за аккаунтом, а не создавать случайный набор при каждом запуске. Случайные комбинации часто внутренне противоречивы: часовой пояс, язык, разрешение и UA могут не соответствовать друг другу, поэтому такая конфигурация выглядит необычнее стабильной.
Иными словами, стабильность возникает из последовательности, а не из случайности.
Сетевой выход
Сетевой выход должен быть привязан к аккаунту: одна среда, один выход, при этом регион выхода должен соответствовать профилю аккаунта, часовому поясу и языку. Если среды разделены, но несколько аккаунтов используют один и тот же выход, большая часть предыдущей изоляции теряет смысл.
Выход также должен оставаться относительно стабильным. Частая смена региона делает сигнал местоположения аккаунта трудно объяснимым. При выборе выхода адреса жилых сетей обычно больше похожи на обычный пользовательский доступ, чем адреса центров обработки данных. Стоит также избегать адресов, которые уже использовались в больших объёмах, поскольку они могут находиться под более пристальным наблюдением.
Cookies и сессии
Состояние сессии само по себе является профилем идентичности. Если несколько аккаунтов используют одни и те же Cookies или локальное хранилище, между ними возникает прямая связь, независимо от того, насколько хорошо разделены остальные среды.
Сессию в новой среде также не следует сразу использовать с высокой интенсивностью. Сначала лучше накопить историю обычного просмотра, а затем постепенно увеличивать объём задач. Этот принцип работает и за пределами сбора данных: наличие истории использования напрямую влияет на то, какую активность аккаунт может разумно выдерживать.
Ритм запросов
Плотность запросов — это поведенческий сигнал. Скрипты часто отличаются характерной регулярностью: фиксированными интервалами обращений, неизменным порядком страниц и отсутствием действий вне сбора данных. Добавление случайных значений само по себе не устраняет такую регулярность, потому что основная проблема заключается в общем объёме.
Управляемое направление — держать нагрузку в разумных пределах: разносить время выполнения для разных аккаунтов, не загружать все аккаунты на максимум одновременно, оставлять разумные интервалы между страницами и разделять задачи высокого и низкого приоритета. Граница проста: сбор данных не должен создавать нагрузку на целевой сервис. Любая скорость, достигнутая ценой ухудшения его работы, не является оправданной оптимизацией.
Почему фиксированная среда для аккаунта стабильнее случайного переключения
Мотив случайного переключения — каждый раз выглядеть иначе, однако проверки связи оценивают, остаются ли сигналы стабильными в разных измерениях и не противоречат ли они друг другу. Если аккаунт сегодня выходит из одного места, а завтра из другого, и каждый раз набор характеристик меняется, такая непоследовательность сама становится аномальным сигналом.
Фиксированная среда следует противоположной логике. С момента регистрации у аккаунта есть постоянная идентичность: фиксированная среда, фиксированный выход, согласованные часовой пояс и язык и постепенно накапливаемая история сессии. Чем дольше сохраняется эта последовательность, тем легче активности выглядеть как поведение обычного пользователя. В этом и состоит ценность слоя среды: долгосрочная стабильность вместо эффектных изменений.
Это также объясняет, почему скрипт сбора не должен сам управлять экземплярами браузера. Среды должны независимо планироваться, чтобы разным аккаунтам можно было назначать собственные среды; их состояние должно быть доступно для проверки, чтобы выявлять аномальные среды и недействительные аккаунты; среды должны освобождаться, чтобы длительная работа не накапливала зомби-экземпляры; а при повторной попытке выполнения задачи сбора часто требуется сменить среду, что возможно только при независимом планировании. В такой архитектуре PurpleMark выступает слоем ресурсов среды. Скрипт отвечает за логику сбора, а идентичность и ресурсы передаются слою среды.
Границы соблюдения правил
Следующие пункты важнее любых перечисленных выше оптимизаций.
Соблюдайте условия использования и правила robots целевого сайта. Многие платформы электронной коммерции прямо ограничивают автоматизированный доступ в своих условиях, поэтому до начала работы нужно убедиться, что предполагаемый способ использования разрешён. Собирайте только общедоступные сведения о товарах, ценах и запасах и не собирайте персональные данные. Не обходите технические меры защиты. Если встречаются CAPTCHA или зашифрованные интерфейсы, корректируйте стратегию сбора или запрашивайте разрешение вместо попыток взломать защиту. Контролируйте частоту запросов независимо от числа аккаунтов и не мешайте нормальной работе целевого сервиса.
Предпосылка этой статьи — то, как нескольким легитимным аккаунтам оставаться независимыми и не мешать друг другу, а не то, как обходить правила платформы. Первое относится к операционной гигиене; второе — совсем другой вопрос.
