Colectarea datelor în sesiune autentificată folosește adesea mai multe conturi, iar limitările nu sunt cauzate întotdeauna de script. Separarea riscului de asociere în caracteristici ale dispozitivului, ieșire de rețea, stare de sesiune și ritmul solicitărilor clarifică variabilele care pot fi controlate.
Colectarea datelor din comerțul electronic se împarte, în linii mari, în două categorii: colectarea paginilor publice care nu necesită autentificare și colectarea într-o sesiune autentificată, de exemplu pentru a vedea date din back-office-ul concurenților sau pentru a obține rezultate afișate după personalizare.
În primul caz, de obicei este suficientă controlarea frecvenței. Când al doilea caz implică mai multe conturi, succesul depinde mai puțin de cât de inteligent este scriptul și mai mult de capacitatea conturilor de a funcționa independent. Dacă acest strat nu este bine gestionat, limitările și blocările par aleatorii, iar modificarea scriptului, reducerea frecvenței sau schimbarea selectoarelor nu aduce îmbunătățiri.
De unde vine riscul
Platformele determină dacă mai multe conturi sunt operate de aceeași parte prin verificări încrucișate: adrese de rețea, caracteristici ale browserului și dispozitivului, date Cookie și de sesiune, precum și tipare de utilizare. O suprapunere mare într-o singură categorie poate face ca respectivele conturi să fie grupate sub același operator.
Aici trebuie trasată o limită clară. Logica de detectare este actualizată continuu, iar trucurile temporare folosite pentru a o contracara oferă beneficii scurte la un cost ridicat. De aceea, nu discutăm despre cum pot fi ocolite controalele de risc. Întrebarea utilă este alta: odată clarificate sursele de risc, ce variabile putem controla și menține stabile pe termen lung? Aceste variabile decid dacă mai multe conturi legitime ajung să se influențeze reciproc.
Caracteristicile dispozitivului și ale browserului
Una dintre cele mai predispuse la probleme configurații este deschiderea mai multor ferestre pe aceeași mașină și autentificarea în conturi diferite. Chiar dacă memoria cache este ștearsă sau este folosit modul incognito, ferestrele continuă să împartă același mediu de sistem și aceleași date ale browserului. Caracteristicile rămân suprapuse, iar platforma vede un singur dispozitiv care schimbă în mod repetat identitatea.
O abordare controlabilă este ca fiecare cont să aibă propriul mediu: un cont pentru fiecare mediu independent, cu amprente, Cookies și stocare locală separate. Esențial este ca mediul să rămână fix pentru cont, nu să fie generat aleatoriu la fiecare pornire. Combinațiile aleatorii sunt adesea contradictorii: fusul orar, limba, rezoluția și UA pot să nu se potrivească, ceea ce pare mai neobișnuit decât o configurație stabilă.
În esență, stabilitatea vine din consecvență, nu din aleatoriu.
Ieșirea de rețea
Ieșirea trebuie legată de cont: un mediu, o ieșire, iar regiunea ieșirii trebuie să se potrivească profilului contului, fusului orar și limbii. Dacă mai multe conturi au medii separate, dar folosesc aceeași ieșire, mare parte din izolarea anterioară își pierde efectul.
Și ieșirea trebuie să rămână relativ stabilă. Schimbările frecvente de regiune fac greu de explicat semnalul de localizare al contului. La alegerea ieșirii, adresele rezidențiale tind să semene mai mult cu accesul unui utilizator obișnuit decât adresele de centru de date. De asemenea, este bine să fie evitate adresele deja folosite intens, deoarece pot fi monitorizate mai atent.
Cookies și sesiuni
Starea sesiunii este, în sine, un profil de identitate. Dacă mai multe conturi împart aceleași Cookies sau aceeași stocare locală, se creează o legătură directă între ele, indiferent cât de bine sunt separate celelalte medii.
O sesiune într-un mediu nou nu ar trebui nici ea folosită imediat la intensitate mare. Este mai bine să se acumuleze întâi o perioadă de navigare normală, apoi volumul de sarcini să crească treptat. Principiul se aplică și în afara colectării de date: existența unui istoric de utilizare influențează direct câtă activitate poate susține în mod rezonabil un cont.
Ritmul solicitărilor
Densitatea solicitărilor este un semnal comportamental. Scripturile au adesea o regularitate tipică: intervale fixe între accesări, o ordine fixă a paginilor și nicio activitate în afara colectării. Adăugarea unor valori aleatorii nu rezolvă această regularitate, deoarece problema principală este volumul total.
Direcția controlabilă este menținerea volumului de lucru într-un interval rezonabil: decalarea orelor de execuție pentru conturi diferite, evitarea încărcării tuturor conturilor la maximum în același timp, păstrarea unor intervale rezonabile între pagini și separarea sarcinilor cu prioritate mare de cele cu prioritate mică. Limita este simplă: colectarea nu trebuie să pună presiune pe serviciul țintă. Orice viteză obținută cu prețul afectării acelui serviciu nu reprezintă o optimizare valabilă.
De ce un mediu fix pentru fiecare cont este mai stabil decât schimbarea aleatorie
Motivația schimbării aleatorii este ca aspectul să fie diferit de fiecare dată, însă verificările de asociere urmăresc dacă semnalele rămân stabile între dimensiuni și dacă se contrazic. Dacă un cont iese astăzi dintr-un loc și mâine din altul, de fiecare dată cu altă combinație de caracteristici, această inconsistență devine ea însăși un semnal anormal.
Un mediu fix urmează logica opusă. De la înregistrare, contul păstrează o identitate consecventă: mediu fix, ieșire fixă, fus orar și limbă compatibile și un istoric de sesiune care se acumulează treptat. Cu cât această consecvență durează mai mult, cu atât activitatea poate semăna mai ușor cu cea a unui utilizator normal. Aici este valoarea stratului de mediu: stabilitate pe termen lung, nu variații spectaculoase.
Aceasta explică și de ce scriptul de colectare nu ar trebui să gestioneze singur instanțele de browser. Mediile trebuie să poată fi programate independent pentru a atribui fiecărui cont un mediu dedicat; starea lor trebuie să poată fi interogată pentru a detecta medii anormale și conturi devenite invalide; mediile trebuie să poată fi eliberate pentru ca operațiunile de lungă durată să nu acumuleze instanțe zombie; iar reluarea unei sarcini de colectare necesită adesea schimbarea mediului, lucru posibil în mod corect doar când programarea este independentă. Într-o astfel de arhitectură, PurpleMark reprezintă stratul de resurse de mediu. Scriptul gestionează logica de colectare, iar identitatea și resursele sunt lăsate stratului de mediu.
Limitele de conformitate
Următoarele puncte sunt mai importante decât orice optimizare de mai sus.
Respectați termenii de utilizare și regulile robots ale site-ului țintă. Multe platforme de comerț electronic restricționează explicit accesul automatizat în termenii lor, așa că verificați înainte dacă utilizarea intenționată este permisă. Colectați numai informații publice despre produse, prețuri și stocuri și nu colectați informații personale. Nu ocoliți măsurile tehnice de protecție. Dacă întâlniți mecanisme precum CAPTCHA sau interfețe criptate, ajustați strategia de colectare sau solicitați autorizare în loc să încercați să le spargeți. Controlați frecvența solicitărilor indiferent de numărul de conturi și nu afectați niciodată funcționarea normală a serviciului țintă.
Premisa acestei discuții este cum pot rămâne independente mai multe conturi legitime fără să se interfereze reciproc, nu cum pot fi evitate regulile platformei. Prima situație ține de igiena operațională; a doua este cu totul altceva.
