LaunchLint Academy
Die kurze Antwort
- App-Name, Apple-Untertitel und Google-Play-Kurzbeschreibung erfüllen unterschiedliche Aufgaben. Sie sollen eine echte Suchintention treffen, den Nutzen verständlich machen und innerhalb der aktuellen Feldgrenzen wahr bleiben.
- Beginne nicht mit Keyword-Wiederholung. Definiere Zielgruppe und Problem, ordne Begriffe nach Relevanz, verteile sie ohne unnötige Dopplung über die verfügbaren Felder und miss Impressionen, Produktseitenaufrufe, Conversion und Qualität gemeinsam.
- Diese Checkliste ist kein einmaliger Content-Check. Führe sie vor dem ersten Store-Upload, nach relevanten Änderungen an Abhängigkeiten oder Konfigurationen und unmittelbar vor der Freigabe erneut aus. Entwicklung, Produkt und die Person mit Zugriff auf die Store-Konsole müssen denselben Build beurteilen. Statische Signale im Projekt sind besonders wertvoll, weil sie reproduzierbar sind, beweisen aber weder das Laufzeitverhalten noch die Antwort eines Backends. Ergänze sie deshalb mit Tests des signierten Artefakts, offiziellen Store-Angaben und einem klaren Freigabeprotokoll.
1. Positionierung in einem Satz
Formuliere Zielgruppe, konkretes Problem, wichtigste Alternative und belegbares Ergebnis, bevor du Keywords auswählst.
Behandle positionierung in einem satz als überprüfbaren Teil des konkreten Release-Kandidaten. Verknüpfe die Entscheidung mit der zuständigen Datei, dem Store-Feld oder einem reproduzierbaren Gerätetest. Notiere erwartetes und beobachtetes Verhalten getrennt, benenne einen Owner und stoppe die Veröffentlichung, wenn ein sicherheits- oder review-relevanter Widerspruch offen bleibt.
Prüfnachweis für den Release
- Produktionsstand für positionierung in einem satz eindeutig benannt
- Betroffene Projektdatei oder Store-Einstellung verlinkt
- Prüfung auf einem sauberen Gerät wiederholt
- iOS- und Android-Abweichungen dokumentiert
- Offene Frage mit Owner und Termin versehen
- Ergebnis ohne Secrets oder persönliche Testdaten gespeichert
2. Suchintentionen clustern
Trenne Problem-, Funktions-, Ergebnis-, Marken- und Vergleichssuchen und priorisiere die Absicht, die der aktuelle Build wirklich erfüllt.
Behandle suchintentionen clustern als überprüfbaren Teil des konkreten Release-Kandidaten. Verknüpfe die Entscheidung mit der zuständigen Datei, dem Store-Feld oder einem reproduzierbaren Gerätetest. Notiere erwartetes und beobachtetes Verhalten getrennt, benenne einen Owner und stoppe die Veröffentlichung, wenn ein sicherheits- oder review-relevanter Widerspruch offen bleibt.
Prüfnachweis für den Release
- Produktionsstand für suchintentionen clustern eindeutig benannt
- Betroffene Projektdatei oder Store-Einstellung verlinkt
- Prüfung auf einem sauberen Gerät wiederholt
- iOS- und Android-Abweichungen dokumentiert
- Offene Frage mit Owner und Termin versehen
- Ergebnis ohne Secrets oder persönliche Testdaten gespeichert
3. App-Namen fokussieren
Der Name muss unterscheidbar, lesbar und merkfähig bleiben. Ergänze nur einen relevanten Kategoriebegriff, wenn er die Positionierung klarer macht.
Behandle app-namen fokussieren als überprüfbaren Teil des konkreten Release-Kandidaten. Verknüpfe die Entscheidung mit der zuständigen Datei, dem Store-Feld oder einem reproduzierbaren Gerätetest. Notiere erwartetes und beobachtetes Verhalten getrennt, benenne einen Owner und stoppe die Veröffentlichung, wenn ein sicherheits- oder review-relevanter Widerspruch offen bleibt.
Prüfnachweis für den Release
- Produktionsstand für app-namen fokussieren eindeutig benannt
- Betroffene Projektdatei oder Store-Einstellung verlinkt
- Prüfung auf einem sauberen Gerät wiederholt
- iOS- und Android-Abweichungen dokumentiert
- Offene Frage mit Owner und Termin versehen
- Ergebnis ohne Secrets oder persönliche Testdaten gespeichert
4. Apple-Untertitel ergänzend nutzen
Der Untertitel erklärt Nutzen oder Zielgruppe, statt den Namen und das separate Keyword-Feld mechanisch zu wiederholen.
Behandle apple-untertitel ergänzend nutzen als überprüfbaren Teil des konkreten Release-Kandidaten. Verknüpfe die Entscheidung mit der zuständigen Datei, dem Store-Feld oder einem reproduzierbaren Gerätetest. Notiere erwartetes und beobachtetes Verhalten getrennt, benenne einen Owner und stoppe die Veröffentlichung, wenn ein sicherheits- oder review-relevanter Widerspruch offen bleibt.
Prüfnachweis für den Release
- Produktionsstand für apple-untertitel ergänzend nutzen eindeutig benannt
- Betroffene Projektdatei oder Store-Einstellung verlinkt
- Prüfung auf einem sauberen Gerät wiederholt
- iOS- und Android-Abweichungen dokumentiert
- Offene Frage mit Owner und Termin versehen
- Ergebnis ohne Secrets oder persönliche Testdaten gespeichert
5. Google-Kurzbeschreibung auf Conversion
Nutze den zusätzlichen Platz für konkreten Wert und Differenzierung, ohne Keyword-Stuffing, Rankings, Preise oder zeitabhängige Promotion.
Behandle google-kurzbeschreibung auf conversion als überprüfbaren Teil des konkreten Release-Kandidaten. Verknüpfe die Entscheidung mit der zuständigen Datei, dem Store-Feld oder einem reproduzierbaren Gerätetest. Notiere erwartetes und beobachtetes Verhalten getrennt, benenne einen Owner und stoppe die Veröffentlichung, wenn ein sicherheits- oder review-relevanter Widerspruch offen bleibt.
Prüfnachweis für den Release
- Produktionsstand für google-kurzbeschreibung auf conversion eindeutig benannt
- Betroffene Projektdatei oder Store-Einstellung verlinkt
- Prüfung auf einem sauberen Gerät wiederholt
- iOS- und Android-Abweichungen dokumentiert
- Offene Frage mit Owner und Termin versehen
- Ergebnis ohne Secrets oder persönliche Testdaten gespeichert
6. Feldgrenzen und Richtlinien prüfen
Apple begrenzt Name und Untertitel, Google Name und Kurzbeschreibung. Prüfe die aktuellen Werte vor Veröffentlichung und vermeide fremde Marken sowie irreführende Claims.
Behandle feldgrenzen und richtlinien prüfen als überprüfbaren Teil des konkreten Release-Kandidaten. Verknüpfe die Entscheidung mit der zuständigen Datei, dem Store-Feld oder einem reproduzierbaren Gerätetest. Notiere erwartetes und beobachtetes Verhalten getrennt, benenne einen Owner und stoppe die Veröffentlichung, wenn ein sicherheits- oder review-relevanter Widerspruch offen bleibt.
Prüfnachweis für den Release
- Produktionsstand für feldgrenzen und richtlinien prüfen eindeutig benannt
- Betroffene Projektdatei oder Store-Einstellung verlinkt
- Prüfung auf einem sauberen Gerät wiederholt
- iOS- und Android-Abweichungen dokumentiert
- Offene Frage mit Owner und Termin versehen
- Ergebnis ohne Secrets oder persönliche Testdaten gespeichert
7. Pro Markt lokalisieren
Recherchiere regionale Suchsprache, kulturelle Verständlichkeit und Wettbewerbsbegriffe; eine wörtliche Übersetzung ist keine ASO-Strategie.
Behandle pro markt lokalisieren als überprüfbaren Teil des konkreten Release-Kandidaten. Verknüpfe die Entscheidung mit der zuständigen Datei, dem Store-Feld oder einem reproduzierbaren Gerätetest. Notiere erwartetes und beobachtetes Verhalten getrennt, benenne einen Owner und stoppe die Veröffentlichung, wenn ein sicherheits- oder review-relevanter Widerspruch offen bleibt.
Prüfnachweis für den Release
- Produktionsstand für pro markt lokalisieren eindeutig benannt
- Betroffene Projektdatei oder Store-Einstellung verlinkt
- Prüfung auf einem sauberen Gerät wiederholt
- iOS- und Android-Abweichungen dokumentiert
- Offene Frage mit Owner und Termin versehen
- Ergebnis ohne Secrets oder persönliche Testdaten gespeichert
8. Messplan und Iteration
Ändere möglichst eine klare Hypothese pro Experiment und bewerte Auffindbarkeit, Conversion, Aktivierung, Retention und Bewertungen statt nur Ranking.
Behandle messplan und iteration als überprüfbaren Teil des konkreten Release-Kandidaten. Verknüpfe die Entscheidung mit der zuständigen Datei, dem Store-Feld oder einem reproduzierbaren Gerätetest. Notiere erwartetes und beobachtetes Verhalten getrennt, benenne einen Owner und stoppe die Veröffentlichung, wenn ein sicherheits- oder review-relevanter Widerspruch offen bleibt.
Prüfnachweis für den Release
- Produktionsstand für messplan und iteration eindeutig benannt
- Betroffene Projektdatei oder Store-Einstellung verlinkt
- Prüfung auf einem sauberen Gerät wiederholt
- iOS- und Android-Abweichungen dokumentiert
- Offene Frage mit Owner und Termin versehen
- Ergebnis ohne Secrets oder persönliche Testdaten gespeichert
Häufige Fragen
Sollte das wichtigste Keyword im App-Namen stehen?
Nur wenn es die App natürlich beschreibt und den Namen nicht austauschbar oder irreführend macht.
Wie lang dürfen Name und Untertitel sein?
Apple nennt aktuell 30 Zeichen für Name und Untertitel; Google nennt 30 Zeichen für den App-Namen und 80 für die Kurzbeschreibung. Prüfe die verlinkten Quellen vor jeder Veröffentlichung.
Darf ich Keywords wiederholen?
Vermeide mechanische Wiederholung. Nutze die Felder entsprechend ihrer Funktion und priorisiere verständliche Relevanz.
Wie schnell sollte ich Metadaten ändern?
Erst wenn eine Hypothese, ausreichend Daten und eine stabile Vergleichsbasis vorliegen. Zu häufige Änderungen zerstören Lernfähigkeit.