Zbieranie danych w zalogowanej sesji często wymaga wielu kont, a ograniczenia nie zawsze wynikają z samego skryptu. Rozdzielenie ryzyka powiązań na cechy urządzenia, wyjście sieciowe, stan sesji i rytm żądań ułatwia wskazanie zmiennych, które rzeczywiście można kontrolować.
Zbieranie danych e-commerce można ogólnie podzielić na dwa rodzaje: pobieranie publicznych stron niewymagających logowania oraz zbieranie danych w zalogowanej sesji, na przykład w celu przeglądania danych zaplecza konkurencji albo pobierania wyników wyświetlanych po personalizacji.
W pierwszym przypadku zwykle wystarczy kontrolować częstotliwość. Gdy drugi przypadek obejmuje wiele kont, o powodzeniu decyduje już nie tyle spryt skryptu, ile to, czy każde konto może funkcjonować niezależnie. Jeśli ta warstwa jest źle zorganizowana, ograniczenia i blokady wyglądają na losowe, a zmiana skryptu, obniżenie częstotliwości czy wymiana selektorów nie przynosi poprawy.
Skąd bierze się ryzyko
Platformy sprawdzają, czy kilka kont jest obsługiwanych przez tę samą stronę, poprzez krzyżowe porównywanie sygnałów: adresów sieciowych, cech przeglądarki i urządzenia, danych Cookie i sesji oraz wzorców działania. Duże podobieństwo w choć jednej kategorii może spowodować przypisanie kont do tego samego operatora.
Trzeba tu wyznaczyć wyraźną granicę. Logika wykrywania stale się zmienia, więc poleganie na doraźnych sztuczkach daje krótkotrwałe korzyści przy wysokim koszcie. Dlatego poniżej nie omawiamy sposobów obchodzenia kontroli ryzyka. Sensowniejsze pytanie brzmi: gdy znamy źródła ryzyka, które zmienne możemy kontrolować i utrzymywać stabilnie w długim okresie? To one decydują, czy kilka legalnie używanych kont będzie na siebie wzajemnie oddziaływać.
Cechy urządzenia i przeglądarki
Jednym z najłatwiejszych sposobów na stworzenie problemu jest otwarcie wielu okien na tym samym komputerze i zalogowanie w nich różnych kont. Nawet po wyczyszczeniu pamięci podręcznej lub użyciu trybu incognito okna nadal korzystają z tego samego środowiska systemowego i danych przeglądarki. Cechy wciąż się pokrywają, więc platforma widzi jedno urządzenie wielokrotnie zmieniające tożsamość.
Kontrolowalne podejście polega na zapewnieniu każdemu kontu własnego środowiska: jedno konto na jedno niezależne środowisko, z oddzielnymi fingerprintami, Cookies i pamięcią lokalną. Kluczowe jest trwałe przypisanie środowiska do konta, zamiast generowania losowego zestawu przy każdym uruchomieniu. Losowe kombinacje często są wewnętrznie niespójne: strefa czasowa, język, rozdzielczość i UA mogą do siebie nie pasować, przez co wyglądają bardziej nietypowo niż stabilna konfiguracja.
Ostatecznie stabilność wynika ze spójności, a nie z losowości.
Wyjście sieciowe
Wyjście powinno być przypisane do konta: jedno środowisko, jedno wyjście, a jego region powinien pasować do profilu konta, strefy czasowej i języka. Jeśli kilka kont ma oddzielne środowiska, ale współdzieli to samo wyjście, znaczna część wcześniejszej izolacji traci sens.
Wyjście powinno też pozostawać względnie stabilne. Częste zmiany regionu utrudniają wyjaśnienie sygnału lokalizacji konta. Przy wyborze wyjścia adresy mieszkaniowe zwykle bardziej przypominają zwykły ruch użytkowników niż adresy centrów danych. Warto też unikać adresów, które były już masowo używane, ponieważ mogą znajdować się pod dokładniejszą obserwacją.
Cookies i sesje
Stan sesji sam w sobie jest profilem tożsamości. Jeżeli kilka kont współdzieli te same Cookies lub pamięć lokalną, powstaje między nimi bezpośrednie połączenie niezależnie od tego, jak starannie rozdzielono pozostałe środowiska.
Sesji w nowym środowisku nie należy również od razu wykorzystywać z dużą intensywnością. Lepiej najpierw zbudować historię normalnego przeglądania, a potem stopniowo zwiększać obciążenie. Zasada ta działa także poza zbieraniem danych: posiadanie historii użycia bezpośrednio wpływa na to, jaką aktywność konto może rozsądnie wytrzymać.
Rytm żądań
Gęstość żądań jest sygnałem behawioralnym. Skrypty często mają charakterystyczną regularność: stałe odstępy między wejściami, stałą kolejność stron i brak działań niezwiązanych ze zbieraniem danych. Dodanie losowych wartości nie rozwiązuje tej regularności, ponieważ głównym problemem jest ogólna skala ruchu.
Kontrolowalnym kierunkiem jest utrzymywanie obciążenia w rozsądnym zakresie: rozłożenie godzin wykonywania zadań dla różnych kont, niewykorzystywanie wszystkich kont do maksimum w tym samym czasie, pozostawianie sensownych odstępów między stronami oraz rozdzielenie zadań o wysokim i niskim priorytecie. Granica jest prosta: zbieranie danych nie powinno wywierać presji na usługę docelową. Szybkość uzyskana kosztem zakłócenia jej działania nie jest uzasadnioną optymalizacją.
Dlaczego stałe środowisko dla konta jest stabilniejsze niż losowe zmiany
Motywacją losowych zmian jest wyglądanie inaczej przy każdym uruchomieniu, ale kontrole powiązań sprawdzają przede wszystkim, czy sygnały są stabilne między różnymi wymiarami i czy wzajemnie sobie nie przeczą. Jeśli konto dziś wychodzi z jednego miejsca, a jutro z innego, za każdym razem z inną kombinacją cech, sama ta niespójność staje się nietypowym sygnałem.
Stałe środowisko działa odwrotnie. Od momentu rejestracji konto zachowuje spójną tożsamość: stałe środowisko, stałe wyjście, pasującą strefę czasową i język oraz historię sesji budowaną stopniowo. Im dłużej trwa ta spójność, tym łatwiej aktywność przypomina zachowanie zwykłego użytkownika. Na tym polega wartość warstwy środowiska: na długoterminowej stabilności, a nie efektownych zmianach.
To wyjaśnia również, dlaczego skrypt zbierający dane nie powinien sam zarządzać instancjami przeglądarki. Środowiska muszą być planowane niezależnie, aby różnym kontom można było przypisywać własne środowiska; ich stan powinien być odczytywalny, aby wykrywać środowiska nietypowe i konta, które przestały działać; środowiska trzeba móc zwalniać, aby długotrwałe operacje nie gromadziły instancji-zombie; a ponowienia zadań często wymagają zmiany środowiska, co jest możliwe tylko przy niezależnym planowaniu. W takiej architekturze PurpleMark pełni rolę warstwy zasobów środowiska. Skrypt odpowiada za logikę zbierania, a tożsamość i zasoby pozostają w warstwie środowiska.
Granice zgodności
Poniższe zasady są ważniejsze niż wszystkie wcześniejsze optymalizacje.
Przestrzegaj warunków korzystania i zasad robots witryny docelowej. Wiele platform e-commerce wprost ogranicza zautomatyzowany dostęp w swoich regulaminach, dlatego przed rozpoczęciem trzeba sprawdzić, czy planowany sposób użycia jest dozwolony. Zbieraj wyłącznie publiczne informacje o produktach, cenach i zapasach i nie zbieraj danych osobowych. Nie obchodź technicznych zabezpieczeń. Jeśli napotkasz ochronę taką jak CAPTCHA lub szyfrowane interfejsy, zmień strategię zbierania albo poproś o zgodę, zamiast próbować je łamać. Kontroluj częstotliwość żądań niezależnie od liczby kont i nigdy nie zakłócaj normalnego działania usługi docelowej.
Założeniem tej dyskusji jest to, jak utrzymać wiele legalnych kont niezależnie i bez wzajemnych zakłóceń, a nie jak omijać zasady platformy. Pierwsze zagadnienie to higiena operacyjna; drugie jest czymś innym.
