Wie Mobile App Scraping tatsächlich funktioniert

App Scraping ist kein Bildschirmauslesen. Wie Versionsdrift, Standort- und Sprachparameter und das Identitätsproblem die Erfassung prägen.

Mobile App Scraping heißt nicht, Text von einem Bildschirm abzulesen. Die App ist selbst ein Client: Jeden Preis, jede Liste und jede Lieferschätzung, die sie anzeigt, hat sie zuvor von einem Dienst angefordert und dann gezeichnet. Aufgabe der Erfassung ist nicht, den Bildschirm nachzuahmen, sondern die Antwort zu verstehen.

Diese Unterscheidung entscheidet alles Weitere. Ein Ansatz, der den Bildschirm liest, bricht bei jeder Oberflächenänderung und bleibt auf das beschränkt, was angezeigt wird. Ein Ansatz auf der Dienstebene erreicht auch Felder, die nie dargestellt werden — Lagerbestände, Kampagnenkennungen, Ranking-Scores — also meist genau die Felder, die die Entscheidung tragen.

Zwei Ansätze und ihre Kosten

Oberflächenautomatisierung. Die App auf einem realen oder virtuellen Gerät ausführen und die Screens durchlaufen. Intuitiv aufzusetzen, teuer zu skalieren: Jede Beobachtung kostet Gerätesekunden, ein Redesign bricht den gesamten Ablauf, und die Daten sind nur so reich wie das Angezeigte.

Die Dienstebene. Die Schnittstelle verstehen, mit der die App spricht, und die Daten dort bereits strukturiert entnehmen. Aufwendiger im Aufbau, ungleich günstiger in der Skalierung und von Anfang an typisiert.

Reale Systeme nutzen beides. Die Dienstebene trägt das Volumen; die Oberflächenautomatisierung bleibt zur Verifikation — denn gemessen werden soll am Ende die Zahl, die der Nutzer sieht, und bestätigen kann das nur der Bildschirm.

Der Vertrag ändert sich, und niemand sagt es an

Beim Web Scraping bricht eine Layoutänderung meist laut: Ein Selektor greift nicht, ein Feld kommt leer, ein Fehlerzähler steigt. App-seitig bricht es leise. Ein Feld wird umbenannt, ein Kampagnentyp kommt unter neuem Code zurück, eine Liste liefert standardmäßig weniger Einträge — und die Erfassung läuft weiter, misst nur etwas anderes.

Das einzige Gegenmittel ist Schemavalidierung: feldweise prüfen, ob jede Antwort die erwarteten Felder, Typen und plausiblen Wertebereiche trägt. Ein Preis von null ist kein Fehler, sondern eine gültige Zahl; zum Fehler macht ihn, dass dasselbe Feld gestern fünfzehn lieferte. Dieselbe Disziplin haben wir für Erfassungs-Engines in warum ein Scraper nicht reicht beschrieben.

App-Versionen legen sich auf dieses Problem. Ein Teil der Nutzer bleibt auf älteren Ständen, der Dienst beantwortet beide, und zwei Versionen können auf dieselbe Frage verschieden antworten. Welche Version Ihre Erfassung abbildet, muss eine geschriebene Entscheidung sein und kein Zufall.

Standort, Sprache und Plattform sind Parameter

App-seitig liefert dieselbe Anfrage mit anderen Koordinaten, anderer Sprache oder anderer Plattform eine andere Antwort. Das ist kein Detail, sondern die Definition der Abdeckung.

"Wir erfassen diese App" ist damit ein unvollständiger Satz. Abdeckung ist die Menge der Paare aus App, Region und Sprache; eine Plattform in zehn Städten zu erfassen ist das Zehnfache, und der Erfassungsplan wird entsprechend gebaut. Eine Reihe, die die Regionsachse nicht fixiert, misst still eine andere Stadt, sobald die Quelle ihren Standardwert ändert.

Identität: das Produkt der App ist nicht das Produkt des Webs

Apps führen eigene Produktkennungen, und die passen weder zu denen der Website noch zu denen Ihres Katalogs. Dasselbe Produkt steht auf jeder Plattform unter anderem Namen, anderer Schreibweise des Gewichts und anderer Gebindedefinition.

App-Daten müssen also nach der Erfassung zugeordnet werden, sonst ist kein Vergleich möglich. Wie das funktioniert, haben wir in wie funktioniert Produktzuordnung beschrieben. Im App-Kanal ist es etwas schwerer, weil ein Barcode meist fehlt und über Name, Gewicht, Marke und Bild entschieden werden muss.

Skalierung, Takt und Lücken

App-Daten verfallen schnell. Lieferschätzungen bewegen sich in zehn Minuten, Bestände innerhalb einer Stunde, das Ranking über den Tag. Der Takt ist deshalb keine Präferenz, sondern die Bedingung dafür, dass die Daten überhaupt brauchbar sind.

Je höher der Takt, desto teurer ein Ausfall. In einer täglich erfassten Reihe fällt eine Tageslücke nicht auf; in einer alle fünfzehn Minuten erfassten liegt dieselbe Lücke mitten in der Spitze, die Sie messen wollten. Warum Aktualität eine Zusage sein muss, haben wir in Datenaktualität ist ein SLA begründet.

Wo wir die Grenze ziehen

Nicht alles, was app-seitig erfassbar wäre, wird erfasst. Unser Rahmen ist die kommerzielle Information, die eine App offen bereitstellt: Preis, Katalog, Verfügbarkeit, Lieferbedingungen, Kampagnen und Ranking.

Was darüber hinausgeht, bleibt außen vor. Es werden keine personenbezogenen Daten erhoben, keine privaten Inhalte hinter Nutzerkonten angesteuert und keine Volumina gefahren, die die Infrastruktur einer Plattform belasten. Diese Grenzen sind keine technische Einschränkung, sondern die Voraussetzung dafür, dass die Daten im Unternehmenskontext nutzbar sind — ein Datensatz, den eine Rechtsabteilung nicht vertreten kann, ist unbrauchbar, so reich er auch sei.

Von der rohen Antwort zum Datensatz

Die Erfassung ist die halbe Arbeit. Eine Antwort ist nicht auswertbar, bevor sie normalisiert, ihre Einheiten und Währungen vereinheitlicht, ihre Identitäten zugeordnet und ihre Zeitstempel auf einen Standard gebracht sind. Diese Umwandlung haben wir allgemein in von rohem HTML zu KI-fertigen Daten beschrieben; im App-Kanal ist der Input kein HTML, die Schritte sind dieselben.

Fazit

Mobile App Scraping ist ein Vertragsproblem, kein Bildschirmproblem. Eine Erfassung, die ihr Schema validiert, ihre Version bewusst wählt, Region und Sprache in die Abdeckungsdefinition schreibt, Identität zuordnet und ihre Grenzen zieht, liefert belastbare Daten. Ohne das entsteht in regelmäßigen Abständen gesammelte Unsicherheit.

Das System hinter unserer Arbeit an Mobile App Scraping beruht auf diesen Schritten — dieselbe Architektur läuft von Liefer- und Quick-Commerce-Apps bis zur Auslastung von Ladestationen.