Scraping von App Store- und Google Play-Daten über verschiedene Länder hinweg

App-Store-Daten wirken auf den ersten Blick simpel. Eine App hat einen Rang, eine Bewertung, einen Preis, eine Beschreibung. Prüft man dieselbe App dann aus einem anderen Land, sind all diese Zahlen anders, denn die mobilen Stores sind kein einheitlicher Katalog. Sie sind eine Reihe nationaler Storefronts, jede mit eigenen Ranglisten, eigener Preisgestaltung, eigener Verfügbarkeit und eigenen Bewertungen in ihrer eigenen Sprache. Was man aus dem eigenen Büro sieht, ist eine Storefront von weit über hundert, und sie als das globale Bild zu behandeln, ist der häufigste Fehler in der Mobile-Market-Intelligence.

Das macht die Erhebung von App-Store-Daten zu einem Geografieproblem, bevor es ein Scraping-Problem ist. Hier folgt, was Teams erheben, warum die Storefront, in der man landet, davon abhängt, woher die Anfrage scheinbar kommt, und wie residential Proxies es ermöglichen, jeden Markt so zu lesen, wie es ein lokaler Nutzer tun würde.

Was Mobile-Teams erheben

Die nützlichen Daten teilen sich in einige Familien. Ranglisten kommen zuerst: die Position einer App in Kategorie- und Gesamtcharts sowie ihre Platzierung in der Store-Suche für ein bestimmtes Keyword, beides wird pro Storefront berechnet und ändert sich täglich. Metadaten folgen, also Titel, Untertitel, Beschreibung, Screenshots und Release-Notes, die pro Markt lokalisiert sind und das Rohmaterial dafür liefern, zu verstehen, wie ein Wettbewerber sich in jeder Region positioniert. Dann die Preisgestaltung, einschließlich des Kaufpreises und der In-App-Käufe, die je nach Markt und Währung variieren, statt einer einzigen zum Kurs umgerechneten Zahl.

Verfügbarkeit ist wichtiger, als man erwarten würde: Eine App kann in einem bestimmten Land schlicht nicht gelistet sein, sei es aus Verlagsentscheidung oder aus regulatorischen Gründen, und zu wissen, wo ein Wettbewerber präsent ist und wo nicht, ist für sich genommen ein strategisches Signal. Bewertungen und Rezensionen runden das Bild ab, da sowohl die Bewertungszahl als auch der Rezensionstext storefront-spezifisch sind, und die Beschwerden in einem Markt oft ganz anders aussehen als in einem anderen. Rund um all das liegen Release-Kadenz und redaktionelle Platzierung, also die Aufzeichnung, wer Updates liefert und wer hervorgehoben wird, ebenfalls pro Land.

Warum die gesehene Storefront von der IP bestimmt wird

Beide Stores leiten Nutzer zu einer nationalen Storefront weiter, und diese Weiterleitung wird größtenteils davon bestimmt, woher die Verbindung scheinbar stammt, verstärkt durch die Geräte-Lokalisierung und, bei den Web-Endpunkten, durch explizite Länderparameter, die nicht immer alles abdecken, was ein echter lokaler Nutzer sehen würde. Der praktische Effekt ist, dass eine Anfrage aus einem Land die Antwort dieses Landes auf jede gestellte Frage liefert: seine Ranglisten, seine Preise, seine Verfügbarkeit, seine Rezensionen.

Die Erhebung von einem einzigen Standort aus liefert also die Sicht einer Storefront, egal wie viele Apps man abdeckt. Man kann eine japanische Rangliste nicht aus einer deutschen ableiten, und man kann nicht erkennen, dass eine App in einem Markt nicht verfügbar ist, indem man einen Markt betrachtet, in dem sie verfügbar ist. Um eine Storefront zu lesen, muss die Anfrage aus ihrem Inneren kommen.

Ein residential Proxy mit Country-Targeting tut genau das, indem er jede Anfrage in den Markt platziert, dessen Storefront man lesen möchte, dasselbe legitime Geo-Targeting, das genutzt wird, um beliebige regional variierende öffentliche Daten zu erreichen. Bemerkenswert, und anders als bei Einzelhandels- und Reisefällen: App-Storefronts sind national, sodass Country-Targeting hier die richtige Granularität ist und City-Level-Targeting meist nichts bringt. Die präsentierte Sprache und Lokalisierung sollte zum Land passen, aus dem man austritt, damit die Storefront die lokalisierten Metadaten liefert, die ein lokaler Nutzer tatsächlich lesen würde.

Skalierung: Apps mal Länder mal täglich

Das Volumen dieser Arbeitslast entsteht durch Multiplikation und nicht durch eine einzelne schwere Abfrage. Ein paar Hundert Apps, die über dreißig oder vierzig Storefronts hinweg verfolgt werden, täglich aktualisiert, mit zusätzlich geschichteten Keyword-Rang-Checks, summiert sich zu einer Anfragenzahl, die bei zu wenigen Adressen sofort Rate-Limits pro IP auslöst. Store-Endpunkte drosseln aggressiv, und eine gedrosselte Antwort ist nicht nur eine Verzögerung, sie ist ein Loch in einer täglichen Zeitreihe, das man später nicht nachträglich füllen kann.

Die Antwort ist Verteilung: die Checks über den Pool verteilen, sodass jede Adresse innerhalb der Limits bleibt, während der aggregierte Durchsatz skaliert, was die Load-Balancing-Logik hinter jedem Hochvolumen-Collector ist und wofür unbegrenzte gleichzeitige Verbindungen da sind. Wer sich fragt, wie viel Verteilung das in der Praxis bedeutet, findet die Überlegung dazu unter wie viele Proxy-IPs man tatsächlich braucht, und die kurze Antwort lautet, dass es von der Rate pro Storefront abhängt, nicht von einer plakativen Pool-Zahl.

Eine echte Storefront zurückbekommen

Store-Web-Endpunkte sind geschützt, und Adressbereiche von Rechenzentren werden hart behandelt, weil automatisierte Erhebungen gegen sie ständig vorkommen. Was man von einer markierten Adresse zurückbekommt, ist oft keine klare Blockierung, sondern etwas, das für die Datenqualität schlimmer ist: eine gedrosselte Antwort, eine generische Seite oder ein Teilergebnis, das wie Daten aussieht, aber keine sind. Das ist das Fehlerbild, gegen das man gestalten muss, denn es verfälscht einen Datensatz still und leise.

Residential Proxies leiten jede Anfrage über eine echte, heimische Verbindung, sodass ein Check wie ein gewöhnlicher Nutzer aussieht, der eine Store-Seite aus seinem eigenen Land öffnet, und eine saubere Adresse mit gutem Ruf liefert die echte Storefront, während eine markierte herausgefordert oder abgespeist wird. Die IP ist notwendig, aber nicht ausreichend, also sollte man die Anfragen sinnvoll takten und die Signale, die Blockierungen auslösen, beachten, statt einen Endpunkt zu bombardieren, nur weil er zufällig antwortet.

Sticky Sessions für paginierte Lesevorgänge

Die meisten Storefront-Checks sind Einzelanfragen und sollten rotieren. Die Ausnahme ist alles, was paginiert, und in dieser Arbeitslast betrifft das größtenteils Rezensionen. Das Durchgehen mehrerer Rezensionsseiten für eine App in einem Land ist eine Sequenz, und wenn sich die Austrittsadresse darunter ändert, kann man inkonsistente Reihenfolgen, wiederholte Einträge oder einen Reset auf die erste Seite bekommen. Eine Sticky Session hält eine Adresse für diesen Durchgang, damit die Paginierung kohärent bleibt, dann beginnt die nächste App oder das nächste Land eine neue Session. Beim breiten täglichen Durchlauf rotieren, innerhalb eines paginierten Lesevorgangs sticky bleiben.

Die Zeitreihe ehrlich halten

Ranglisten sind eine Zeitreihe, und eine Zeitreihe ist nur so gut wie ihre Lücken. Ein fehlender Tag in einem Land ist ein Tag, über den man nicht urteilen kann, also sollte man die Zuverlässigkeit der Erhebung als Teil des Datenqualitätsproblems behandeln und nicht als Ops-Hygiene. Die Pipeline überwachen pro Storefront, denn eine Erfolgsrate, die in einem Markt still absinkt, ist zunächst eine verzerrte Trendlinie, bevor sie irgendetwas anderes ist, und es lohnt sich zu prüfen, dass das Zurückgekommene tatsächlich eine Storefront ist und keine generische oder gedrosselte Seite. Das ist dieselbe Disziplin, die laufendes Preismonitoring und Verfügbarkeits-Tracking brauchen, und das erhobene Ergebnis speist dieselbe Art von Alternative-Data-Analyse.

Verantwortungsvoll erheben

Die ehrlichen Grenzen, und sie sind hier wichtig. Beide Plattformen veröffentlichen offizielle Reporting-APIs für die eigenen Apps, und das ist die richtige Quelle für die eigenen Leistungsdaten: strukturiert, korrekt und innerhalb der Nutzungsbedingungen. Öffentliche Storefront-Erhebung dient der Wettbewerbs- und Marktintelligenz, den Dingen, die keine API über die App eines anderen preisgibt, und sie sollte sich auf öffentliche Daten beschränken, die jeder Besucher in diesem Land sehen kann, innerhalb der Nutzungsbedingungen und Robots-Richtlinien jeder Plattform, mit einer höflichen Anfragerate.

Zwei Punkte verdienen es, klar ausgesprochen zu werden. Rezensionsdaten sind nutzergenerierte Inhalte, die personenbezogene Informationen enthalten können, also sollten sie gemäß den geltenden Datenschutzregeln behandelt werden, und es sollten keine Profile einzelner Rezensenten erstellt werden. Und dies ist reine Messung: Ranglistendaten zu erheben ist Marktforschung, während der Versuch, Ranglisten, Installationszahlen oder Rezensionen zu beeinflussen, Manipulation ist, gegen die Regeln jeder Plattform verstößt und nichts ist, wofür Proxies eingesetzt werden sollten. Die Storefront zu lesen ist die Aufgabe; sie anzufassen nicht.

Ein minimaler Lesevorgang pro Land

Das Targeting steckt im Benutzernamen am Gateway, sodass das Festlegen einer Storefront ein einziges Feld ist. Den Sprach-Header an den zu lesenden Markt anpassen:

import requests

MARKETS = ["us", "gb", "de", "jp", "br"]

def storefront(country, lang):
    proxy = f"http://customer-USERNAME-country-{country}:PASSWORD@p.shifter.io:443"
    r = requests.get(
        "https://apps.example-store.com/app/id123456789",
        proxies={"http": proxy, "https": proxy},
        timeout=20,
        headers={"Accept-Language": lang},
    )
    r.raise_for_status()
    return r.text            # parse rank, price, availability, metadata

for country in MARKETS:
    html = storefront(country, "en-US" if country in ("us", "gb") else None)
    record(country, html)    # one row per storefront per day

Denselben Lesevorgang über jeden verfolgten Markt ausführen, um das Bild pro Storefront aufzubauen, paginierte Rezensions-Lesevorgänge auf ihrer eigenen Sticky Session halten und nach einem festen täglichen Zeitplan sampeln, damit die Reihe über Länder hinweg vergleichbar ist. Die allgemeinen Client-Muster übertragen sich aus dem Leitfaden zur Nutzung residential Proxies mit Python, und der rezensionsspezifische Blickwinkel wird in Überwachung von Kundenbewertungen behandelt.

Das Fazit

Eine App hat keinen Rang, keinen Preis, keine Bewertung. Sie hat in jeder nationalen Storefront eine andere, und jede davon ist nur aus dem Inneren dieses Landes lesbar. Das macht Länderabdeckung zur Kernanforderung der Mobile-Market-Intelligence, und es macht die Erhebung von einem einzigen Standort zur Garantie für ein unvollständiges und irreführendes Bild. Residential Proxies lösen genau das: Country-Targeting, um jede Storefront so zu lesen, wie es ein lokaler Nutzer tut, ein großer Pool, um einen täglichen Durchlauf über viele Apps und Märkte zu verteilen, ohne Rate-Limits auszulösen, saubere heimische Adressen, damit das Zurückkommende eine echte Storefront ist und kein gedrosselter Platzhalter, und Sticky Sessions für die paginierten Lesevorgänge. Offizielle APIs für die eigenen Apps nutzen, Wettbewerbserhebung auf öffentliche Daten und innerhalb der Nutzungsbedingungen jeder Plattform beschränken, und niemals vom Messen der Charts zum Versuch übergehen, sie zu bewegen.

Diese Erhebungsschicht ist das, was residential Proxies bieten, ein großer Pool echter, heimischer IPs mit Country-Targeting und Sticky Sessions dort, wo eine Sequenz eine braucht. Die Preisgestaltung pro GB passt gut zu dieser Arbeitslast, da Storefront-Checks klein und häufig sind und die Kosten den tatsächlich abgerufenen Daten folgen statt der Anzahl beobachteter Märkte.