Ohne Entwicklerkonto an die Daten
Teil 3 der Serie „Hinter der Karte" — wie Bewertungen ohne Konsolen-Zugang ins System kommen, und warum ein nächtlicher Lauf gegen das Vergessen der Stores kämpft
Kurzfassung
Zwei Hürden verhindern normalerweise, dass jemand die Bewertungen einer fremden App auswertet: das Entwicklerkonto, das nur der App-Besitzer besitzt — und das kurze Gedächtnis der Stores selbst, die alte Bewertungen aus ihren öffentlichen Antworten verschwinden lassen. Dieser Artikel zeigt, wie YelmeAtlas beide Hürden umgeht: eine einzelne Eingabezeile, die selbst erkennt, welcher Store gemeint ist, und ein nächtlicher Archivierungslauf, der Bewertungen sichert, bevor der Store sie vergisst — mit einer klaren Regel für den Ausfallfall: eine hängende App darf niemals die Historie aller anderen kosten.
1. Diagnose: zwei getrennte Hürden
Hürde 1 — das Entwicklerkonto ist an Besitz gebunden. Google Play Console und Apple App Store Connect verlangen beide ein Konto, das an die jeweilige App gebunden ist. Wer die eigene App auswerten will, kommt irgendwann hinein. Wer die Bewertungen einer fremden App sehen will — der Konkurrenz, eines Referenzprodukts, einer App vor einer Kaufentscheidung — bekommt über diesen Weg grundsätzlich keinen Zugang. Das ist keine Lücke in der jeweiligen Plattform, sondern deren Design.
Hürde 2 — die Stores vergessen aktiv. Selbst mit Zugriff auf die öffentlichen Bewertungsendpunkte gilt: Apples öffentlicher Feed zeigt nur die neuesten rund 500 Bewertungen je Storefront. Bei einer vielbesprochenen App sind das gemessen rund zwölf Tage Geschichte — alles davor ist nicht „verspätet abrufbar", sondern schlicht weg. Wer nicht regelmäßig nachsieht, verliert Bewertungen unwiederbringlich, nicht nur langsam.
2. Bisherige Lösungsansätze und ihre Grenzen
- Das offizielle Entwicklerkonto nutzen. Funktioniert nur für die eigene App — jede Auswertung der Konkurrenz bleibt unmöglich.
- Einmalig exportieren. Löst Hürde 1 für die eigene App, aber nicht Hürde 2: ein einmaliger Export ist am Tag danach schon wieder veraltet, und die zwölf Tage sind trotzdem irgendwann vorbei.
- Ein Drittanbieter-Werkzeug mit eigenem Entwicklerzugang mieten. Existiert (Sensor Tower u. ä.), aber zu Preisen, die für ein Konto pro Monat oft im fünfstelligen Jahresbereich liegen — für eine einzelne App-Kennung, die man eintippt.
3. Der Ansatz von YelmeAtlas
Das Prinzip: eine Eingabezeile statt zwei Formulare. Der Nutzer tippt eine einzige App-Kennung — egal aus welchem Store — und das System erkennt selbst, wohin die Anfrage geht. Dahinter läuft, unabhängig vom Login, jede Nacht ein Sammellauf, der jede beobachtete App erneut abfragt, bevor die zwölf Tage bei Apple verstreichen.
4. Der Algorithmus im Detail
sequenceDiagram
participant N as Nutzer
participant R as Store-Weiche
participant P as Google Play
participant A as App Store
N->>R: "com.spotify.music" ODER "id324684580"
R->>R: Nur Ziffern? (Apples eigene Link-Form "id…")
alt rein numerisch
R->>A: Anfrage an Apple
else reverse-domain
R->>P: Anfrage an Google Play
end
Note over R: Nutzer nennt den Store nie selbst
Die Store-Weiche. Google Play identifiziert Apps über einen Reverse-Domain-Namen (com.spotify.music), der App Store über eine rein numerische Kennung (324684580) — beide Formen sind niemals verwechselbar. Die Weiche prüft nur eine Sache: Ist die Eingabe (nach dem Entfernen von Apples eigenem „id"-Präfix, das aus jedem App-Store-Link kopiert werden kann) rein numerisch? Dann Apple. Sonst Google Play. Der Nutzer muss den Store nie selbst benennen — er tippt einfach, was in der Adresszeile des Stores steht.
flowchart TD
T["Timer: jede Nacht, 04:00 Uhr ± 30 Min Streuung"] --> L["Für jede beobachtete App"]
L --> F{"Abruf erfolgreich?"}
F -->|ja| S["Bis zu 1.000 Bewertungen<br/>dedupliziert gespeichert"]
F -->|nein, z. B. Store-Ausfall| E["Fehler protokolliert,<br/>NUR diese eine App übersprungen"]
S --> W["Nächste App"]
E --> W
W --> L
Der nächtliche Sammellauf. Ein systemd-Timer startet den Lauf einmal täglich, mit einer bewussten Zeitstreuung von ±30 Minuten (damit nicht jeder Kunde exakt zur selben Sekunde denselben Store belastet) und Persistent=true (verpasste Läufe — etwa nach einem Server-Neustart — holen sich selbst nach, statt einfach zu verfallen). Jede beobachtete App wird einzeln abgefragt; ein hängender Store-Aufruf für eine App darf niemals die Historie aller anderen kosten — ein Fehlschlag wird protokolliert, die Liste läuft weiter.
Die Dopplung, die keine Dopplung ist. Jede Bewertung hat eine eindeutige, vom Store vergebene Kennung. Beim Speichern gilt: taucht diese Kennung schon auf, wird der neue Eintrag stillschweigend verworfen, nie überschrieben. Das macht den täglichen Lauf idempotent — dieselbe Bewertung zweimal abzurufen kostet nichts außer ein bisschen Netzwerkzeit, erzeugt aber nie einen doppelten Eintrag.
5. Ein gemessenes Beispiel
Bei einer vielbesprochenen App zeigt Apples öffentlicher Feed rund 500 Bewertungen je Storefront — gemessen entspricht das rund zwölf Tagen Geschichte. Ohne einen Lauf, der öfter als alle zwölf Tage nachsieht, wäre jede ältere Bewertung schlicht nicht mehr abrufbar. Der tägliche Rhythmus liegt bewusst weit innerhalb dieses Fensters — nicht, weil täglich nötig wäre, sondern weil die Kosten eines verpassten Tages (unwiederbringlicher Verlust) höher sind als die Kosten eines täglichen Abrufs (eine Netzwerkanfrage).
6. Grenzen der Methode
- Die Store-Weiche funktioniert, weil die beiden ID-Formate sich niemals überschneiden — für einen dritten Store müsste die Regel neu gedacht werden, nicht einfach erweitert.
- Der nächtliche Lauf sammelt bis zu 1.000 Bewertungen je App und Nacht — das deckt normale Update-Zyklen ab, ist aber kein Ersatz für einen Echtzeit-Stream bei extrem viel-diskutierten Einzelereignissen.
- Ein Ausfall wird geloggt und übersprungen, nicht automatisch nachgeholt innerhalb derselben Nacht — die nächste Nacht übernimmt, solange die App weiterhin beobachtet wird.
7. Fazit
Zwei kleine, unauffällige Entscheidungen lösen ein Problem, das auf den ersten Blick nach viel mehr Technik verlangt: eine simple Formprüfung erspart dem Nutzer, den Store zu kennen — und ein täglicher, fehlertoleranter Lauf verhindert, dass Geschichte einfach verschwindet, während niemand zusieht. Keine der beiden Lösungen ist kompliziert. Beide beruhen darauf, das eigentliche Problem präzise zu benennen, bevor man es löst: nicht „wie bekomme ich mehr Daten", sondern „wie verliere ich keine, die ich schon hatte."
Der nächste Teil nutzt genau dieses Archiv: wie aus einer täglich wachsenden Liste von Bewertungen eine Beschwerdequote und die Tage wird, die tatsächlich einen zweiten Blick verdienen. → Teil 4: Die Beschwerdequote und die auffälligen Tage (folgt)