ASO: Leitfaden für kreative Tests

Ein nützlicher ASO-Gestaltungstest beantwortet eine konkrete Frage: Hilft diese Version der Store-Seite der gewünschten Zielgruppe beim nächsten Schritt? Legen Sie diesen Schritt, die Zielgruppe und die Entscheidungsregel fest, bevor Sie ein neues Icon oder neue Screenshots erstellen.

Beginnen Sie mit einer nachvollziehbaren Änderung, vergleichen Sie sie im selben Zeitraum mit der aktuellen Seite und dokumentieren Sie auch Tests ohne eindeutiges Ergebnis. Vierteljährliches Testen garantiert keine höhere Conversion-Rate. Das gilt ebenso für das Kopieren des ersten Screenshots eines erfolgreichen Wettbewerbers.

Wählen Sie zuerst das Problem

Prüfen Sie die Seite auf den Geräten, in den Sprachen und auf den Store-Flächen, die Ihre Zielgruppe tatsächlich nutzt. Icons, Screenshots und Vorschauvideos können auch außerhalb der vollständigen Produktseite erscheinen. Es gibt keine allgemeingültige Regel, wonach die ersten zwei Bilder die meisten Installationen verursachen. Prüfen Sie, ob das Versprechen lesbar, für Besucher relevant und durch die App gedeckt ist.

Leiten Sie daraus eine Hypothese ab:

Das sind Ausgangspunkte für die Diagnose. Auch Preis, Bewertungen, Produktqualität oder ein veränderter Besuchermix können eine Conversion-Lücke erklären. Ein Durchschnitt über verschiedene Stores isoliert den Einfluss der Screenshot-Anordnung nicht.

Wenn Sie nur ein Element verändern, lässt sich ein Unterschied leichter erklären. Auch ein vollständiger Konzepttest kann sinnvoll sein: Vergleichen Sie eine funktionsorientierte Bildfolge mit einer anwendungsorientierten. Das Ergebnis gilt dann für das gesamte Paket. Der Test zeigt nicht, welche einzelne Überschrift, Farbe oder Abbildung ausschlaggebend war.

Das passende Store-Experiment einrichten

Apple Product Page Optimization

Apples Testkonfiguration unterstützt bis zu drei Testversionen neben dem Original, ausgewählte Lokalisierungen und eine festgelegte Traffic-Zuteilung. Geeignet sind auch Apps mit einer veröffentlichten Vorbestellungsseite. Apples Konfigurationsanleitung nennt bis zu 90 Tage, sofern der Test nicht früher beendet wird. Prüfen Sie vor der Planung das verfügbare Enddatum in App Store Connect: Die Analytics-FAQ erwähnt auch mögliche Verlängerungen. Die veröffentlichte 90-Tage-Grenze der Konfigurationsanleitung ist weder eine Mindestdauer noch eine Zusage für ein eindeutiges Ergebnis.

Apples Übersicht zur Produktseitenoptimierung beschreibt Tests von Icons, Screenshots und Vorschauvideos. Neue Inhalte müssen geprüft werden; alternative Icons müssen im App-Binary enthalten sein. Erhalten zwei Testversionen jeweils 20% des Traffics, bleiben 60% beim Original. Eine gleichmäßige Verteilung auf die Testversionen bedeutet also nicht, dass die Kontrollgruppe genauso groß ist.

Apples Abbildung mit zwei Icon-Versionen in voller Größe ansehen.

Abbildung von Apple: Auf den beiden Produktseiten ist das veränderte Icon zu sehen. Dies ist ein Plattformbeispiel, kein Testergebnis von Strataigize.

Die Ergebnisdokumentation erläutert bayesianische Schätzungen und Kennzeichnungen für bessere oder schlechtere Leistung ab 90% Konfidenz. Betrachten Sie geschätzte Verbesserung, Intervall, gewählte Vergleichsbasis und Teststatus gemeinsam. Ein positiver Punktschätzer allein reicht nicht aus. Ein nicht eindeutiges Ergebnis belegt außerdem keine Gleichwertigkeit der Versionen.

Google Play: Store-Listing-Experimente

Googles aktuelle Anleitung erlaubt bis zu zwei Testvarianten gegenüber dem aktuellen Eintrag. Möglich sind ein Experiment mit Standardgrafiken oder bis zu fünf lokalisierte Experimente gleichzeitig. Der gewählte Anteil der Testzielgruppe verteilt sich gleichmäßig auf die Varianten; die übrigen Besucher sehen den aktuellen Eintrag.

Dokumentieren Sie die Zielkennzahl genau so, wie sie in Ihrer Konsole erscheint. Die aktuelle Anleitung nennt Klicks einzelner Nutzer auf Installation, Öffnen oder Vorregistrierung; einige Definitionen auf derselben Seite beschreiben noch abgeschlossene Aktionen. Prüfen Sie Oberfläche und Berichtsdefinition, bevor Sie einen Klick als Installation bezeichnen. Legen Sie die kleinste nachweisbare Effektgröße und das Konfidenzniveau vor dem Start fest. Verwenden Sie die Laufzeitschätzung der Konsole für genau diese Konfiguration.

Google zeigt das Ergebnis mit Intervall und Handlungsempfehlung. Nach sechs Monaten endet die Datenerfassung eines noch laufenden Experiments, und der Traffic geht zurück an den aktuellen Eintrag. Eine erfolgreiche Variante wird dabei nicht automatisch übernommen. Bei beiden Stores müssen Sie entscheiden, ob ein Ergebnis eine Umsetzung rechtfertigt.

Einen nachvollziehbaren Testplan schreiben

Für eine hypothetische Sprachlern-App könnte der Plan so aussehen:

• Frage: Vermittelt ein erster Screenshot mit der tatsächlichen Gesprächsübung den Nutzen klarer als die bisherige Funktionsliste?
• Umfang: Ein Store und eine unterstützte Sprache, mit gleichzeitig laufender Kontroll- und Testversion. Halten Sie fest, welche Länder- und Gerätefilter die Plattform tatsächlich unterstützt und welchen gemischten Besucherkreis Sie nicht trennen können.
• Änderung: Nur den ersten Screenshot ersetzen. Icon, übrige Bilder, Angebot und Produkterlebnis möglichst konstant halten.
• Messung: Primäre Plattformkennzahl, Zähler, Nenner, Zuteilung und Ausgangszeitraum dokumentieren. Eine wirtschaftlich relevante Mindestverbesserung vorab festlegen.
• Zeitplan: Start, geplantes Ende, Berichtszeitzone, Mindestbeobachtungszeit und Plattformschätzung speichern. Releases, Aktionen, Ausfälle und Traffic-Veränderungen protokollieren.
• Entscheidung: Festlegen, wer die Umsetzung freigibt, welche Belege erforderlich sind und wann ein Test ohne eindeutiges Ergebnis endet.

Dieser Plan ist ein Beispiel, kein durchgeführtes Experiment. Bei bezahltem Traffic gehören auch Platzierung, Region, Suchanfragen- oder Zielgruppenmix und Attributionsfenster ins Protokoll. Ein veränderter Kampagnenmix kann einen Vorher-nachher-Vergleich unbrauchbar machen. Unser Ansatz zum Testen neuer Kanäle beginnt ebenfalls mit einer klaren Frage und klaren Grenzen.

Reicht der Traffic für die Frage?

Eine Planungskalkulation kann zeigen, dass ein Experiment länger dauern würde als das veröffentlichte Testfenster. Das folgende Rechenbeispiel gilt für ein binäres Ergebnis bei unabhängigen, teilnahmeberechtigten Personen, mit einer Kontroll- und einer gleich großen Testgruppe. Annahmen: zweiseitiges Signifikanzniveau von 5%, Teststärke von 80% und feste Stichprobe. Verwendet wird eine Normalapproximation mit gepoolter Varianz unter der Nullhypothese und getrennten Varianzen unter der Alternativhypothese. Die Zahlen sind aufgerundet. Die Stichprobendokumentation von statsmodels erläutert dieses Verfahren.

Jede Zelle nennt den Bedarf pro Gruppe, keine Installationsprognose. Eine relative Verbesserung von 10% gegenüber 30% ergibt 33%, also 3 Prozentpunkte mehr. Dafür werden insgesamt 7.526 Teilnehmende benötigt. Bei 500 teilnahmeberechtigten Personen pro Tag im Experiment ergibt das rechnerisch etwa 15,1 Tage. Planen Sie also mindestens 16 volle Tage für diese Menge ein. Nimmt nur die Hälfte des relevanten Traffics teil, verdoppelt sich die benötigte Kalenderzeit ungefähr.

Bei einer Ausgangsrate von 20% bedeutet eine relative Verbesserung von 5%, zwischen 20% und 21% zu unterscheiden. Dafür braucht das Beispiel insgesamt 51.166 Teilnehmende, bei 500 pro Tag etwa 103 Tage. Das überschreitet die veröffentlichte Planungsgrenze von 90 Tagen in Apples Konfigurationsanleitung. Weniger Testversionen, mehr geeigneter Traffic oder eine deutlichere Veränderung können den Test ermöglichen. Ihn unbegrenzt laufen zu lassen, bis er positiv aussieht, löst das Problem nicht.

Diese Zahlen prüfen die Machbarkeit und ersetzen kein statistisches Store-Modell. Wiederholte Seitenaufrufe sind nicht unbedingt unabhängige Personen; Gruppen können unterschiedlich groß sein; native Kennzahlen und bayesianische Schätzungen weichen von dieser Berechnung ab. Mehrfachvergleiche und die wiederholte Suche nach einem frühen Gewinner bei einem Test mit fester Stichprobe erfordern eine passende statistische Behandlung. Auch die berechnete Stichprobe garantiert kein Ergebnis: Teststärke bezeichnet die Wahrscheinlichkeit, den angenommenen Effekt unter dem angegebenen Modell zu erkennen.

Berücksichtigen Sie den für Ihre App relevanten Wochenverlauf, selbst wenn sich schnell viele Beobachtungen sammeln. Nutzen Sie eine vorab festgelegte Endbedingung und das Verfahren der Plattform. Bleibt das Ergebnis unsicher, dokumentieren Sie das. Ein Vorsprung, der nach drei Wochen verschwindet, kann durch Zufall, Besuchermix oder eine tatsächliche zeitliche Veränderung entstehen. Sein Verlauf allein belegt keinen Neuheitseffekt.

Individuelle Produktseiten und randomisierte Tests trennen

Individuelle Produktseiten können zu einem Anwendungsfall, einem verweisenden Link oder einem geeigneten Suchkontext passen. Wenn Sie eine besonders interessierte Zielgruppe dorthin schicken und sie mit sämtlichen Besuchern der Standardseite vergleichen, isolieren Sie den Einfluss der Seite nicht.

Apple berichtet bei Verweisen auf individuelle Seiten von durchschnittlich 2,5 Prozentpunkten Verbesserung gegenüber durchschnittlich 1,6% auf Standardseiten. Addiert ergibt das 4,1%; 2,5 geteilt durch 1,6 entspricht rund 156% relativer Verbesserung. Zur Schlagzeile nennt die Seite weder Stichprobengröße noch Beobachtungszeitraum oder randomisierten Vergleich. Behandeln Sie sie als veröffentlichten Gesamtwert von Apple, nicht als erwartbare Steigerung Ihrer App. Gestaltung, Lokalisierung und Messung erfordern weiterhin Arbeit.

Halten Sie bei einem Seitenvergleich Zielgruppe, Quelle, Zeitraum und Messdefinitionen vergleichbar. Verteilen Sie Besucher nach Möglichkeit zufällig. Andernfalls kennzeichnen Sie die Analyse als beobachtend und dokumentieren Sie mögliche Störfaktoren. Prüfen Sie die Qualität nach der Installation nur, wenn Ihre Messung die Seite oder Testversion tatsächlich mit späteren Ergebnissen verbinden kann. Die aggregierte Nutzerbindung belegt nicht, dass ein bestimmter Screenshot bessere Kunden gewonnen hat.

Inhalte gestalten, die das Produkt belegen kann

Verwenden Sie die echte Oberfläche und zeigen Sie eine Aufgabe, die die App tatsächlich erfüllt. Apples Metadatenregeln verlangen eine zutreffende Darstellung des Erlebnisses und klare Hinweise, wenn gezeigte Inhalte einen zusätzlichen Kauf benötigen. Auch Googles Metadatenrichtlinie untersagt irreführende Screenshots und Aussagen.

KI kann beim Entwerfen von Komposition, Hintergründen und Text helfen. Unsere Leitfäden zu Gemini-Bildprompts und ChatGPT-Prompts für visuelle Inhalte liefern dafür Ansätze. Bewahren Sie die echte Oberfläche, die tatsächliche Verfügbarkeit von Funktionen und belegbare Aussagen. Prüfen Sie Übersetzungen, Lesbarkeit auf kleinen Displays, Beschnitt und Barrierefreiheit vor der Einreichung. Ein überzeugendes Bild einer nicht verfügbaren Funktion bleibt ungeeignet, unabhängig von seiner Klickrate.

Entscheidung und offene Fragen dokumentieren

Speichern Sie einen kurzen Ergebnisbericht mit den genauen Dateien, Zeitangaben, Gruppenzuteilungen, Kennzahlendefinitionen, Stichproben, Effektschätzungen und Unsicherheiten. Dokumentieren Sie das Umsetzungsdatum getrennt vom Testende.

Beobachten Sie nach der Umsetzung vergleichbare Nutzergruppen. Fehlt eine Zuordnung späterer Ergebnisse zur Testversion, sagen Sie das ausdrücklich. Eine bessere Store-Conversion allein belegt weder zusätzlichen Umsatz noch Gewinn.

Strataigize bietet App Store Optimization an und hat deshalb ein wirtschaftliches Interesse an diesem Thema. Unsere historische Kleo-Fallstudie berichtet von einer um 127% gestiegenen Downloadrate und einer um 110% gestiegenen Conversion-Rate innerhalb von 30 Tagen, in denen Texte und Bilder geändert wurden. Sie enthält keine randomisierte Kontrollgruppe und isoliert nicht den Beitrag eines einzelnen Gestaltungstests. Lesen Sie sie als Fallbericht, nicht als Ergebniszusage.

Der Vergleich von ASO-Tools trennt native Experimente von Recherche- und externen Testwerkzeugen. Wenn Sie Unterstützung bei der ersten Hypothese und ihrer Messung brauchen, buchen Sie eine kostenlose Wachstumsberatung.

Häufige Fragen

Wie oft sollten wir die Gestaltung aktualisieren?

Prüfen Sie sie, wenn sich Produkt, Zielgruppe oder unterstützte Märkte ändern, und sammeln Sie konkrete Testhypothesen. Eine vierteljährliche Prüfung kann bei der Planung helfen. Sie verlangt kein Redesign und verspricht keine Conversion-Steigerung von 20–30%.

Was tun, wenn der Traffic für einen A/B-Test zu gering ist?

Beheben Sie klare Genauigkeits- oder Lesbarkeitsprobleme, ohne experimentelle Belege zu behaupten. Qualitatives Feedback kann die nächste Hypothese verbessern. Berechnen Sie, ob eine größere Konzeptänderung messbar wäre. Ein datierter Vorher-nachher-Vergleich kann Hinweise liefern, schließt gleichzeitige Änderungen von Zielgruppe, Saison oder Produkt aber nicht aus.

Sollten wir jede statistisch bessere Version übernehmen?

Prüfen Sie die Effektgröße, die vertretene Zielgruppe und das Versprechen der Gestaltung. Ein kleiner Vorteil rechtfertigt möglicherweise nicht die Pflege mehrerer Sprachversionen. Auch deutlich mehr Store-Klicks können Nutzer anziehen, deren Bedürfnisse die App nicht erfüllt.