Zwei Apps, ein Blick

Teil 6 der Serie „Hinter der Karte" — wie zwei Apps nebeneinander ausgewertet werden, ohne dass für die zweite ein eigenes Konto nötig wäre

Kurzfassung

„Ist unsere Beschwerdequote schlecht, oder ist das einfach die ganze Branche?" ist eine Frage, die sich ohne Vergleichszahl nicht beantworten lässt — und für die eigene wie für die Konkurrenz-App gilt dieselbe strukturelle Hürde aus Teil 3: kein Entwicklerkonto für eine fremde App. Dieser Artikel zeigt, wie der Vergleich zweier Apps im Dashboard funktioniert: zwei unabhängige, fehlertolerante Abfragen, ein einziger Satz, der den Unterschied in Worten benennt — nie nur in Farbe.

1. Diagnose: eine Zahl allein hat keinen Maßstab

30 % Beschwerdequote — ist das viel? Wenig? Ohne Vergleichswert bleibt jede einzelne Kennzahl kontextlos. Genau dieselbe Zahl kann in einer Branche mit notorisch unzufriedenen Nutzern (Streaming, Mobilfunk) normal sein und in einer anderen (produktivitätsorientierte Nischen-Apps) ein deutliches Warnsignal. Ohne einen Referenzwert lässt sich diese Einordnung nicht treffen — und der naheliegendste Referenzwert ist die eigene Konkurrenz.

Die strukturelle Hürde bleibt dieselbe wie in Teil 3: Wer die Beschwerdequote der Konkurrenz sehen will, bekommt über die offiziellen Entwicklerkonsolen grundsätzlich keinen Zugang — die Bewertungen sind zwar öffentlich, aber niemand macht sie standardmäßig vergleichbar.

2. Bisherige Lösungsansätze und ihre Grenzen

Marktforschungsberichte kaufen. Teuer, selten aktuell, selten auf die eigene, kleine Nische zugeschnitten.
Die Konkurrenz-App manuell installieren und ein Gefühl entwickeln. Nicht messbar, nicht wiederholbar, nicht mit einer Zahl belegbar.
Ein Werkzeug mit eigenem Entwicklerzugang mieten — löst das Problem nur für die eigene App, nie für die der Konkurrenz (siehe Teil 3).

3. Der Ansatz von YelmeAtlas

Das Prinzip: zwei vollständig unabhängige Einzel-Auswertungen, in einem Blick zusammengeführt. Es gibt keine gesonderte „Vergleichs-Engine" — derselbe Mechanismus, der eine einzelne App auswertet (Teile 2–5 dieser Serie), läuft zweimal parallel, für zwei App-Kennungen gleichzeitig. Der einzige neue Teil ist die Zusammenführung zu einem Satz.

4. Der Algorithmus im Detail

flowchart TD
    A["Nutzer trägt zwei App-Kennungen ein"] --> B1["Auswertung App A<br/>(unabhängiger Aufruf)"]
    A --> B2["Auswertung App B<br/>(unabhängiger Aufruf)"]
    B1 --> C{"Beide fertig?"}
    B2 --> C
    C --> D["Ein Satz: Differenz in Worten<br/>nie nur in Farbe"]
    B1 -.-> W1["Beide Apps auf die Merkliste —<br/>ab jetzt sammelt auch die<br/>Konkurrenz-App Historie"]
    B2 -.-> W1

Zwei unabhängige Aufrufe, absichtlich nicht gekoppelt. Würde man beide Abfragen technisch aneinanderketten (etwa: „warte auf beide, dann zeige irgendetwas"), würde ein Store-Ausfall bei App A auch die Antwort für App B kosten — obwohl B völlig unabhängig verfügbar gewesen wäre. Die beiden Läufe sind deshalb bewusst getrennte Pipelines: Ein Fehlschlag auf einer Seite hat keinen Einfluss auf die andere.

Der Vergleichssatz. Sobald beide Seiten geantwortet haben, entsteht genau ein Satz über beide Spalten hinweg. Bei Gleichstand:

„Gleichstand: beide bei {Quote} % Beschwerden."

Bei einem Unterschied, wörtlich aus der Übersetzungsdatei:

„{Schlechtere App} liegt {Differenz} Punkte schlechter: {höhere Quote} % gegen {niedrigere Quote} % bei {bessere App}."

Die Regel dahinter ist bewusst: der Unterschied wird immer in Worten benannt, nie nur über eine Farbe transportiert — eine rote Kachel allein sagt nicht, wie viel schlechter, und ist für niemanden mit Farbfehlsichtigkeit verlässlich lesbar.

Der Nebeneffekt, der keiner bleibt. Sobald zwei Apps verglichen werden, landen beide automatisch auf der Merkliste — auch die, die man nicht selbst besitzt. Ab diesem Moment sammelt der nächtliche Archivierungslauf aus Teil 3 auch für die Konkurrenz-App Geschichte. Ein Vergleich, der nächsten Monat wiederholt wird, zeigt dann eine echte Entwicklung statt derselben Momentaufnahme von heute. Dieser Nebeneffekt ist bewusst so gebaut, dass ein Fehlschlag dabei (etwa wegen eines erschöpften Testzeitraums) niemals die eigentliche Vergleichsantwort kostet — er läuft im Hintergrund, still, und darf scheitern, ohne dass der Nutzer etwas davon merkt.

5. Ein gemessenes Beispiel

Zwei Apps mit 44 % und 8 % Beschwerdequote im selben Fenster ergeben den Satz: „App A liegt 36 Punkte schlechter: 44 % gegen 8 % bei App B." Eine einzelne Zahl — 44 % — wirkt beunruhigend oder harmlos, je nachdem, was man erwartet. Im Vergleich mit 8 % wird sofort klar, in welche Richtung die Einordnung geht.

6. Grenzen der Methode

Der Vergleich funktioniert für genau zwei Apps gleichzeitig, nicht für eine ganze Kategorie — eine Auswertung über viele Wettbewerber hinweg ist ein anderes, größeres Problem.
Themen werden zwischen den beiden Apps nicht automatisch einander zugeordnet — verglichen werden Kennzahlen (Quote, Verlauf), nicht, ob „Werbung" bei App A dasselbe Gewicht hat wie bei App B. Das bewusst zu vermeiden verhindert einen falschen Eindruck von Gleichheit zwischen Themen, die inhaltlich unterschiedlich sind.
Die erste Auswertung eines neu verglichenen Wettbewerbers zeigt nur den aktuellen Stand — die Entwicklung über die Zeit entsteht erst mit wiederholten Vergleichen, sobald das nächtliche Archiv gewachsen ist.

7. Fazit

Der Wettbewerbsvergleich braucht keine neue Auswertungslogik — er braucht nur die Erlaubnis, dieselbe Logik zweimal parallel laufen zu lassen, ohne dass ein Fehlschlag auf einer Seite die andere mitreißt. Und er braucht die Disziplin, den Unterschied in einem Satz zu benennen, den jeder lesen kann — nicht in einer Farbe, die nur „besser" oder „schlechter" signalisiert, aber nicht, um wie viel.

Damit endet die erste Runde dieser Serie. Sie folgt derselben Idee von Anfang bis Ende: nicht mehr Intelligenz, sondern mehr Disziplin — sammeln ohne Hürde, archivieren bevor der Store vergisst, zählen statt zusammenfassen, und ehrlich schweigen, wenn die Zahlen es nicht hergeben.

Die zweite Runde wechselt die Perspektive: nicht mehr Algorithmus für Algorithmus, sondern zwei konkrete technische Herausforderungen, an denen wir gearbeitet haben — welche Wege wir erwogen und warum wir uns anders entschieden haben. → Teil 7: Der Fehler, der sich hinter 227 grünen Tests versteckte

← Teil 5: Der Bericht, der auch Nein sagen kann · Zur Übersicht