Mehr App-Bewertungen bekommen, ohne Nutzer zu nerven

Gute Apps haben nicht automatisch viele Bewertungen

Im Produkt kann alles ordentlich aussehen: Buchungen werden abgeschlossen, Kurse werden genutzt, Lieferungen kommen an. Auf der Store-Seite stehen trotzdem nur wenige Bewertungen. Ganz oben bleibt eine alte Rezension sichtbar, die einen Fehler aus einer längst ersetzten Version beschreibt.

Dann liegt es nahe, möglichst vielen Menschen möglichst oft ein Fenster mit der Bitte um fünf Sterne zu zeigen. Das erhöht zwar die Zahl der Unterbrechungen, schafft aber noch keine gute Bewertungsstrategie. Wer direkt nach dem Start gefragt wird, hat kaum eine Grundlage für ein Urteil. Wer gerade eine Zahlung bestätigt oder einen Fehler gesehen hat, möchte seine Aufgabe beenden. Und wer für eine gute Note belohnt wird, gibt keine unabhängige Bewertung mehr ab.

Sinnvoller ist ein Ablauf, der im Produkt beginnt. Die App erkennt einen tatsächlich erreichten Nutzen, prüft, ob die Nutzung stabil verlief, wartet auf einen ruhigen Augenblick und bittet dann das Betriebssystem um den nativen Dialog. Ob er erscheint und wie der Mensch reagiert, bleibt außerhalb der Kontrolle der App.

Bewertungen sind dabei nur ein Teil der ASO-Arbeit rund um den Start. Sie sollten dieselbe glaubwürdige Geschichte unterstützen wie Store-Beschreibung und Screenshots.

Sterne, Rezensionen und Support erfüllen verschiedene Aufgaben

Eine Bewertung ist die Auswahl von einem bis fünf Sternen. Eine Rezension ergänzt öffentlichen Text. Der Support ist ein privater Kanal, in dem konkrete Konten, Bestellungen oder technische Details geklärt werden. Feedback aus einem Betatest gehört wiederum in die Phase vor dem öffentlichen Release.

Diese Wege dürfen sich ergänzen, sollten aber nicht heimlich voneinander abhängen. Ein selbst gebauter Sterneregler in der App ist keine Store-Bewertung. Noch problematischer ist eine Vorfrage wie „Gefällt dir unsere App?“, die zufriedene Personen in den Store und unzufriedene Personen ausschließlich zum Support führt. Dieses Aussortieren wird als Review Gating bezeichnet. Es verzerrt das öffentliche Bild und widerspricht der Idee unabhängiger Rezensionen.

Ein ehrliches Produkt bietet deshalb zwei getrennte Möglichkeiten. Die neutrale Bewertungsanfrage kann nach klaren Nutzungskriterien erscheinen. Hilfe und Feedback bleiben jederzeit für alle erreichbar. Eine Beschwerde muss nicht erst abgegeben werden, damit die Person weiterarbeiten kann, und ein Lob wird nicht gegen eine Funktion eingetauscht.

Der richtige Moment folgt auf ein Ergebnis

Apple empfiehlt eine Anfrage nach einer abgeschlossenen Aktion, Aufgabe oder Spielstufe, ohne die laufende Nutzung zu unterbrechen. Google verlangt, dass Nutzerinnen und Nutzer genug Erfahrung gesammelt haben, um eine sinnvolle Einschätzung abzugeben. Der erste App-Start erfüllt keine der beiden Bedingungen.

Was als Ergebnis gilt, hängt vom Produkt ab. In einer Termin-App reicht die Reservierung allein oft nicht; der Termin sollte stattgefunden haben. Bei einer Lern-App ist eine kurze Lektion ein schwaches Signal, ein abgeschlossenes Modul nach mehreren Sitzungen ein deutlich besseres. Eine Liefer-App sollte nicht fragen, solange der Kurier noch unterwegs ist. Bis zur Übergabe kann sich die Erfahrung vollständig ändern.

Wiederholter Erfolg ist meist aussagekräftiger als eine einzelne Aktion. Die notwendige Häufigkeit richtet sich nach dem Nutzungsrhythmus. Vier Trainingseinheiten können eine Woche abbilden, vier Steuererklärungen dagegen mehrere Jahre. Starre Rezepte aus fremden Produkten helfen hier wenig.

Genau deshalb hängt die Anfrage mit Onboarding und erstem Nutzwert zusammen: Das Onboarding zeigt den Einstieg. Eine Bewertung sollte erst folgen, wenn das Produkt sein Versprechen eingelöst hat.

Erst die Auslöselogik, dann der Code

Vor der Implementierung sollten Produkt, Design, Entwicklung und Support gemeinsam festlegen, welches Ereignis eine Anfrage möglich macht, welche Nutzungserfahrung nötig ist und welche Umstände sie verhindern. Es geht nicht darum, eine Fünf-Sterne-Person vorherzusagen, sondern um einen fairen Zeitpunkt.

Zusätzlich braucht es technische Sperren: die zuletzt verwendete App-Version, das Datum des letzten Versuchs, Fehler in der aktuellen Sitzung und offene Probleme. Die Plattformquote ersetzt diese Logik nicht. Auch wenn Apple oder Google den Dialog unterdrücken, wäre ein API-Aufruf nach jedem Auftrag unnötig.

Nach dem Erfolg sollte ein kurzer Abstand folgen. Die Bestätigungsansicht gehört oft noch zur Aufgabe. Erst wenn das Ergebnis verstanden ist und die nächste Handlung nicht wartet, entsteht der ruhige Moment für eine freiwillige Bitte.

*Eine gute Auslöselogik verbindet echten Nutzen, genügend Erfahrung, Ausschlüsse und eine Pause. Sie versucht nicht, die spätere Sternezahl zu erraten.*

Bei Apple ist der API-Aufruf nur eine Bitte

Mit RequestReviewAction beziehungsweise der StoreKit-Schnittstelle übergibt die App den Bewertungsdialog an das System. Apple entscheidet, ob er tatsächlich erscheint. Pro Person kann der Dialog höchstens dreimal innerhalb von 365 Tagen angezeigt werden; außerdem lässt er sich in den Systemeinstellungen vollständig abschalten.

Ein dauerhaft sichtbarer Button mit der Zusage „Jetzt bewerten“ sollte deshalb nicht einfach diese Schnittstelle aufrufen. Wenn die Person bewusst eine Rezension schreiben möchte, kann die App stattdessen den von Apple dokumentierten Link zur Bewertungsseite im Store öffnen. Der native Dialog gehört in einen nicht blockierenden Moment, in dem auch dann alles normal weitergeht, wenn nichts erscheint.

Apple rät vom ersten Start, vom Onboarding und von einer unmittelbaren Reaktion auf einen Fingertipp ab. Die Beispieldokumentation merkt sich die zuletzt angefragte Version, wartet auf wiederholte Erfolge und fügt eine kurze Verzögerung ein. Das sind gute Bausteine, aber keine allgemeingültigen Zahlen.

Die App-Review-Richtlinien von Apple verlangen den vorgesehenen Dialog. Bezahlte, belohnte, gefilterte oder gefälschte Bewertungen können zu Maßnahmen gegen das Entwicklerkonto führen.

Google Play veröffentlicht die Quote absichtlich nicht

Auch Google Play stellt einen nativen In-App-Dialog bereit. Die Schnittstelle unterliegt einer zeitabhängigen Quote, deren genaue Höhe Google nicht nennt und jederzeit ändern kann. Ein technisch erfolgreicher Aufruf kann daher ohne sichtbares Fenster enden.

Google nennt zudem eine wichtige Grenze: Vor oder während der Karte darf die App keine Meinungsfrage wie „Gefällt dir die App?“ oder „Gibst du uns fünf Sterne?“ stellen. Die Karte darf weder verändert noch überlagert werden. Ein dauerhaft angebotener Link „Rezension schreiben“ sollte direkt zur Play-Store-Seite führen und nicht von der begrenzten In-App-Schnittstelle abhängen.

Das macht den beliebten Umweg über eine vorgeschaltete Zufriedenheitsfrage nicht nur unsympathisch, sondern auch fachlich falsch. Support bleibt ein eigener, leicht auffindbarer Weg. Die Store-Anfrage wird anhand der Nutzung ausgelöst, nicht anhand einer vermuteten positiven Meinung.

Eine kleine Zustandslogik reicht für den Anfang

Die Umsetzung muss kein riesiges Regelwerk werden. Ein nachvollziehbarer Ablauf ist wichtiger als viele Sonderfälle:

1. Ein Wertmoment wird abgeschlossen.
2. Die App prüft wiederholte Nutzung und Mindestabstand.
3. Fehler, Zahlungen, Streitfälle, Support und frühere Anfragen werden geprüft.
4. Bei einem Ausschluss endet der Ablauf still.
5. Ansonsten folgt eine kurze Pause und der native Aufruf.
6. Der Versuch wird gespeichert, unabhängig davon, ob das System etwas zeigt.

Diese Informationen sollten über Sitzungen hinweg erhalten bleiben. Ein fernsteuerbarer Schalter ist ebenfalls hilfreich: Wenn ein Release abstürzt oder der Zahlungsdienst ausfällt, kann die Anfrage pausieren, ohne dass eine neue Version nötig ist.

In der Beta-Testphase prüft das Team nicht nur den sichtbaren Dialog, sondern vor allem die eigenen Ein- und Ausschlüsse. Testumgebungen behandeln die Plattformquote teilweise anders als die Produktion. Die Produktlogik muss trotzdem stimmen.

Analysiere nur Signale, die wirklich vorhanden sind

Die App kennt den geeigneten Moment und den Versuch, den Dialog anzufordern. Sie erfährt nicht zuverlässig, ob Apple oder Google ihn gezeigt hat, welche Sterne gewählt wurden oder ob ein Text veröffentlicht wurde. Eine unmittelbare „Bewertungs-Conversion“ lässt sich daher nicht seriös aus dem App-Ereignis berechnen.

Für den Start reichen etwa review_moment_eligible und review_request_attempted. Sinnvolle Eigenschaften sind Wertmoment, Version, Sprache und Ausschlussgrund. Persönlicher Rezensionstext gehört nicht in ein allgemeines Analyseereignis.

Store-Konsolen zeigen später aggregierte Entwicklungen nach Version, Land, Sprache oder Gerät. Diese Daten sollten neben Releases, Störungen und Änderungen der Auslöselogik betrachtet werden. Wenn gleichzeitig ein großes Update und eine Kampagne starten, lässt sich eine bessere Bewertung nicht automatisch dem Dialog zuschreiben. Die Einrichtung der App-Analyse sollte solche Grenzen dokumentieren.

Eine gute Antwort zeigt, dass das Problem verstanden wurde

Öffentliche Antworten sind kein Platz für Werbetexte. Eine hilfreiche Antwort benennt den konkreten Punkt, erklärt den nächsten Schritt oder nennt die Version, in der er korrigiert wurde. Sie enthält keine Bestellnummern, E-Mail-Adressen oder Kontodaten und drängt die Person nicht zu einer höheren Bewertung.

Ein wöchentlicher Ablauf schafft mehr als spontane Einzelreaktionen. Das Team sortiert Rezensionen nach Version, Sprache, Gerät und Thema, reproduziert wiederkehrende Fehler, ordnet sie einem Verantwortlichen zu und verknüpft die Behebung mit den Release Notes. Nach dem Release kann die Antwort aktualisiert werden.

Apple und Google benachrichtigen Rezensierende über Antworten; sie können ihre Bewertung anschließend ändern. Darauf besteht kein Anspruch. Der wichtigere Effekt ist öffentlich sichtbar: Auch zukünftige Interessierte erkennen, ob ein Team zuhört und nachvollziehbar handelt. Für Produkte mit Community, Buchungen oder vielen Anbietern hilft ein klarer Moderations- und Supportprozess.

Schlechte Bewertungen werden durch bessere Releases repariert

Im App Store lässt sich die zusammengefasste Bewertung bei einer neuen Version zurücksetzen. Sie wird außerdem je Store-Gebiet separat berechnet. Schriftliche Rezensionen bleiben jedoch erhalten, und Apple warnt davor, den Neustart leichtfertig zu nutzen: Eine Seite mit sehr wenigen Stimmen kann ebenso wenig Vertrauen auslösen wie eine schwache Note.

Bei Google Play fließen neuere Bewertungen stärker in die öffentlich sichtbare Note ein. Das begünstigt Produkte, die tatsächlich stabiler werden. In beiden Stores bleibt die nachhaltige Antwort dieselbe: Fehler beheben, verständlich kommunizieren, Support erreichbar machen und erst nach echter Nutzung fragen.

Vor einem Reset sollte die neue Version über einen angemessenen Zeitraum stabil sein. Häufig ist es überzeugender, auf ältere Kritik mit einer konkreten Fehlerbehebung zu antworten, statt die Vergangenheit optisch verschwinden zu lassen.

So kann ein erster Monatsplan aussehen

In Woche eins werden vorhandene Rezensionen und Supportfälle thematisch ausgewertet. Woche zwei gehört den Wertmomenten, Sperrregeln, Analyseereignissen und Texten. In Woche drei entstehen die iOS- und Android-Anbindung, Verzögerung, Versionsspeicher und Fernschalter. Woche vier startet mit einem begrenzten Anteil der Nutzerschaft, damit technische und inhaltliche Fehler auffallen, bevor alle betroffen sind.

Als Ziel eignet sich nicht „sofort 4,8 Sterne“. Es lädt zu Abkürzungen ein. Besser sind überprüfbare Qualitätsziele: keine Anfrage nach einem Fehler, weniger wiederkehrende Beschwerden, schnellere Antworten auf reproduzierbare Probleme und ein wachsender Anteil geeigneter Momente, in denen die Bitte respektvoll gestellt wird.

Für ein neues Produkt lassen sich Funktionen, Support, Analyse und Store-Veröffentlichung im interaktiven Projektbrief gemeinsam ordnen.

Häufige Fragen