Für Datenerfassung im eingeloggten Zustand werden oft mehrere Konten benötigt, und Drosselungen liegen häufig nicht am Skript allein. Teilt man das Verknüpfungsrisiko in Gerätemerkmale, Netzwerkausgang, Sitzungsstatus und Anfragerhythmus auf, werden die steuerbaren Variablen deutlich klarer.
Die Datenerfassung im E-Commerce lässt sich grob in zwei Arten einteilen: das Erfassen öffentlicher Seiten ohne Anmeldung und die Erfassung im eingeloggten Zustand, etwa um Backend-Daten von Wettbewerbern einzusehen oder Ergebnisse nach einer personalisierten Darstellung abzurufen.
Bei der ersten Art reicht es meist, die Frequenz im Griff zu behalten. Sobald bei der zweiten Art mehrere Konten beteiligt sind, entscheidet nicht mehr in erster Linie, wie clever das Skript ist, sondern ob die Konten unabhängig voneinander bestehen können. Ist diese Ebene schlecht umgesetzt, wirken Drosselungen und Sperren zufällig; Änderungen am Skript, eine niedrigere Frequenz oder andere Selektoren bringen dann kaum Verbesserung.
Woher kommt das Risiko?
Plattformen prüfen über mehrere Signale, ob verschiedene Konten von derselben Stelle betrieben werden: Netzwerkadressen, Browser- und Gerätemerkmale, Cookie- und Sitzungsdaten sowie Nutzungsmuster. Eine starke Überschneidung in nur einer dieser Kategorien kann dazu führen, dass Konten demselben Betreiber zugeordnet werden.
Hier ist eine klare Grenze wichtig. Erkennungslogik wird laufend weiterentwickelt; kurzfristige Tricks dagegen liefern nur kurz Nutzen und verursachen hohe Kosten. Deshalb geht es im Folgenden nicht darum, Risikokontrollen zu umgehen. Sinnvoller ist die Frage: Welche Variablen können wir, nachdem die Risikoquellen geklärt sind, kontrollieren und langfristig stabil halten? Diese Variablen bestimmen, ob sich mehrere legitime Konten gegenseitig beeinflussen.
Geräte- und Browsermerkmale
Eine besonders fehleranfällige Konstellation ist, auf demselben Rechner mehrere Fenster zu öffnen und sich dort mit verschiedenen Konten anzumelden. Selbst nach dem Leeren des Caches oder im Inkognitomodus teilen diese Fenster weiterhin dieselbe Systemumgebung und Browserdaten. Die Merkmale überschneiden sich also weiter, und die Plattform sieht ein Gerät, das wiederholt zwischen Identitäten wechselt.
Steuerbar ist, jedem Konto eine eigene Umgebung zu geben: ein Konto pro unabhängiger Umgebung, mit getrennten Fingerprints, Cookies und lokalem Speicher. Entscheidend ist, diese Umgebung dauerhaft an das Konto zu binden, statt bei jedem Start eine zufällige Kombination zu erzeugen. Zufällige Kombinationen widersprechen sich oft selbst: Zeitzone, Sprache, Auflösung und UA passen nicht zusammen und wirken dadurch auffälliger als eine stabile, unveränderte Konfiguration.
Kurz gesagt: Stabilität entsteht durch Konsistenz, nicht durch Zufall.
Netzwerkausgang
Der Ausgang sollte an das Konto gebunden sein: eine Umgebung, ein Ausgang, und die Region des Ausgangs sollte zu Kontoprofil, Zeitzone und Sprache passen. Sind die Umgebungen zwar getrennt, teilen mehrere Konten aber denselben Ausgang, wird ein großer Teil der vorherigen Isolation wieder aufgehoben.
Auch der Ausgang sollte relativ stabil bleiben. Häufige Regionswechsel machen das Standortsignal des Kontos schwer erklärbar. Bei der Auswahl wirken Adressen aus privaten Netzen in der Regel eher wie normaler Nutzerzugriff als Rechenzentrumsadressen. Gleichzeitig sollte man Adressen vermeiden, die bereits sehr stark genutzt wurden, weil solche Adressen selbst schon genauer überwacht werden können.
Cookies und Sitzungen
Der Sitzungsstatus ist selbst eine Art Identitätsakte. Teilen mehrere Konten dieselben Cookies oder denselben lokalen Speicher, entsteht eine direkte Verbindung zwischen ihnen, ganz gleich, wie sauber die übrigen Umgebungen getrennt sind.
Eine Sitzung in einer neuen Umgebung sollte außerdem nicht sofort mit hoher Intensität genutzt werden. Sinnvoll ist zunächst eine Phase normalen Browsings, aus der sich Nutzungshistorie aufbaut, bevor die Aufgabenmenge schrittweise erhöht wird. Diese Erfahrung gilt auch außerhalb der Datenerfassung: Ob ein Konto eine Nutzungshistorie besitzt, beeinflusst direkt, wie viel Aktivität es verkraften kann.
Anfragerhythmus
Die Dichte von Anfragen ist ein Verhaltenssignal. Skripte haben oft ein typisches gleichmäßiges Muster: feste Abstände zwischen Zugriffen, eine feste Seitenreihenfolge und keinerlei Verhalten außerhalb der Erfassung. Diese Gleichförmigkeit lässt sich nicht einfach durch Zufallswerte lösen, denn das eigentliche Problem liegt im Gesamtvolumen.
Steuerbar ist vor allem, die Aufgabenmenge in einem vernünftigen Rahmen zu halten: Ausführungszeiten verschiedener Konten versetzen, nicht alle Konten gleichzeitig voll auslasten, sinnvolle Abstände zwischen Seiten lassen und Aufgaben mit hoher und niedriger Priorität trennen. Die Grenze ist klar: Die Erfassung darf den Zielservice nicht belasten. Geschwindigkeit, die nur durch eine Beeinträchtigung des fremden Dienstes gewonnen wird, ist keine tragfähige Optimierung.
Warum eine feste Umgebung pro Konto stabiler ist als zufälliges Wechseln
Die Idee hinter zufälligem Wechseln ist, jedes Mal anders auszusehen. Bei Verknüpfungsprüfungen zählt jedoch, ob die Signale über verschiedene Dimensionen hinweg stabil sind und ob sie einander widersprechen. Wenn ein Konto heute von einem Ort und morgen von einem anderen ausgeht und die Merkmalskombination jedes Mal wechselt, ist diese Inkonsistenz selbst ein Auffälligkeitssignal.
Eine feste Umgebung folgt der entgegengesetzten Logik. Seit der Registrierung besitzt das Konto eine gleichbleibende Identität: eine feste Umgebung, einen festen Ausgang, passende Zeitzone und Sprache sowie eine Sitzungshistorie, die sich langsam aufbaut. Je länger diese Konsistenz besteht, desto leichter lässt sich die Aktivität als die eines normalen Nutzers einordnen. Genau darin liegt der Wert der Umgebungsebene: langfristige Stabilität statt auffälliger Variation.
Das erklärt auch, warum das Erfassungsskript Browserinstanzen nicht selbst verwalten sollte. Umgebungen müssen unabhängig planbar sein, damit verschiedenen Konten eigene Umgebungen zugewiesen werden können; ihr Zustand muss abfragbar sein, damit fehlerhafte Umgebungen und ungültige Konten erkannt werden; Umgebungen müssen freigegeben werden können, damit im Dauerbetrieb keine Zombie-Instanzen entstehen; und bei Wiederholungsversuchen einer Erfassungsaufgabe ist oft ein Wechsel der Umgebung nötig, was nur bei unabhängiger Planung sauber funktioniert. In einer solchen Architektur bildet PurpleMark die Ebene für Umgebungsressourcen. Das Skript kümmert sich um die Erfassungslogik, während Identität und Ressourcen an die Umgebungsebene delegiert werden.
Compliance-Grenzen
Die folgenden Punkte sind wichtiger als jede zuvor genannte Optimierung.
Beachten Sie die Nutzungsbedingungen und die robots-Regeln der Zielseite. Viele E-Commerce-Plattformen beschränken automatisierte Zugriffe ausdrücklich in ihren Bedingungen; prüfen Sie daher vorab, ob die geplante Nutzung erlaubt ist. Erfassen Sie nur öffentlich zugängliche Produkt-, Preis- und Bestandsinformationen und keine personenbezogenen Daten. Umgehen Sie keine technischen Schutzmaßnahmen. Treffen Sie auf Schutzmechanismen wie CAPTCHAs oder verschlüsselte Schnittstellen, passen Sie die Erfassungsstrategie an oder holen Sie eine Genehmigung ein, statt die Schutzmaßnahme zu brechen. Begrenzen Sie die Anfragerate unabhängig von der Anzahl der Konten und beeinträchtigen Sie niemals den normalen Betrieb des Zielservices.
Voraussetzung dieser Diskussion ist, dass mehrere legitime Konten unabhängig voneinander bleiben und sich nicht gegenseitig stören, nicht dass Plattformregeln umgangen werden. Ersteres ist betriebliche Hygiene; Letzteres ist etwas anderes.
