App-Store-Review-Arbitrage
Wandle die App-Store- oder Google-Play-URL eines Mitbewerbers in ein Go-to-Market-Briefing für eine einzige Session um: priorisierte Beschwerdecluster, eine Broken-Promise-Karte, Landing-Page-Überschriften und Werbetext-Richtungen – alles basierend auf wörtlichen Rezensionen.
Kritische Regeln (vor Schritt 1 lesen)
Diese Regeln gelten während aller Schritte. Ein Verstoß gegen eine von ihnen führt zum Fehlschlagen der Selbst-QA (Schritt 6).
- Jedes Zitat muss wörtlich sein. Keine Paraphrase, keine Grammatikkorrektur, keine Bereinigung. Nur die exakten Worte des Rezensenten.
- Keine erfundenen Statistiken. Schreibe nicht „40 % schneller“ oder „2× zuverlässiger“, es sei denn, ein Rezensent hat eine ähnliche Formulierung explizit verwendet. Der Selbst-QA-Schritt prüft auf nicht belegte Prozentangaben.
- Clusternamen müssen die Sprache der Rezensenten verwenden. Studiere die Anti-Pattern-Tabelle in Schritt 3.
- Jede Überschrift und jede Werbetext-Richtung muss ihr Quellcluster zitieren. Format:
[cluster: "cluster-name"]. - Abschnitt 2 ist immer in der Ausgabe enthalten – auch im degradierten Zustand. Niemals überspringen oder weglassen.
- Keine verbotenen Wörter in generierten Texten: powerful, robust, seamless, innovative, game-changing, streamline, leverage, revolutionize, transform.
Schritt 1 – Eingabe parsen und Plattform erkennen
Akzeptiere eine natürlichsprachliche Aufforderung, die eine App-URL enthält. Extrahiere die URL.
Plattformerkennung:
apps.apple.com→ App Storeplay.google.com/store/apps/details?id=→ Google Play- Jede andere URL → stoppe und antworte: „Bitte gib eine direkte App-Store- oder Google-Play-URL an. Ich kann keine Rezensionsdaten von anderen Quellen analysieren.“
ID-Extraktion (vor dem Aufruf des Skripts durchführen):
| Plattform | Was extrahieren | Wie |
|---|---|---|
| App Store | Numerische app_id | Ziffern nach /id in der URL |
| App Store | country | 2-Buchstaben-Code nach apps.apple.com/ (z. B. us, gb) |
| Google Play | package_name | Wert des id=-Query-Parameters |
Speichere die extrahierten Werte – du wirst sie für den Ausgabedateinamen in Schritt 7 benötigen.
Wenn product_context in der Aufforderung des Benutzers angegeben wurde (was das eigene Produkt tut), speichere es – es wird verwendet, um die Texte in Schritt 5 zu personalisieren.
Schritt 2 – Rezensionen & Metadaten sammeln
Führe das vollständige Abrufskript aus:
python3 scripts/fetch_reviews.py "{app_url}" --output {tmpdir}/asr-raw.json
(Hinweis: Ersetze {tmpdir} durch das temporäre Verzeichnis deines Betriebssystems, z. B. /tmp unter macOS/Linux oder C:\Temp unter Windows).
Dies ruft sowohl die Store-Beschreibungs-Metadaten als auch die Rezensionen ab.
- App Store: iTunes-API – kostenlos, keine Authentifizierung. App-Store-Rezensionen werden über Apples öffentlichen iTunes-RSS-Feed abgerufen. Einige Apps geben aufgrund von Apples API-Beschränkungen 0 Rezensionen zurück – in diesem Fall fährt das Skill mit den verfügbaren Daten fort und protokolliert eine Warnung. Google Play ist der primär unterstützte Pfad.
- Google Play:
google-play-scraper-Paket – kostenlos, keine Authentifizierung
Wenn das Skript fehlschlägt, lies den Fehler aus stderr. Häufige Ursachen:
- Paket nicht installiert: führe
pip install google-play-scraperaus - App nicht gefunden: überprüfe, ob die URL ein aktuelles, aktives Listing ist
- Google-Play-API-Fehler: führe
pip install --upgrade google-play-scraperaus und wiederhole den Vorgang
Das Skript gibt den Sammelfortschritt auf stderr aus. Warte, bis es abgeschlossen ist. Nach Abschluss lies {tmpdir}/asr-raw.json und zeige die Sammelzusammenfassung dem Benutzer an:
✓ [N] Rezensionen gesammelt ([N] niedrig bewertete 1–3★) von [Plattform]
Datumsbereich: [älteste] bis [neueste]
Paket: [iTunes-API | google-play-scraper]
Überprüfe den Exit-Code:
- Exit 0 → Sammlung erfolgreich, überprüfe
metadata.store_description. Wenn null: notiere dies – Abschnitt 2 verwendet den degradierten Zustand. Fahre mit Schritt 3 fort. - Exit 1 → Fehler (lies stderr-Nachricht, zeige sie dem Benutzer an, stoppe)
- Exit 2 → Gate 1 ausgelöst (< 10 niedrig bewertete Rezensionen gefunden)
Gate 1 – Schwaches Signal Stopp: Wenn das Skript mit Code 2 beendet wird, lies die gate_message aus {tmpdir}/asr-raw.json und zeige sie dem Benutzer wörtlich an. Fahre nicht mit Schritt 3 fort. Erstelle kein unvollständiges Briefing.
Schritt 3 – Beschwerde-Clustering
Lade low_star_reviews aus {tmpdir}/asr-raw.json.
Clustere alle niedrig bewerteten Rezensionen in 4–6 benannte Beschwerdethemen. Wende diese Formel an, um jede Rezension zu bewerten:
complaint_weight = (4 - Bewertung) × recency_factor
recency_factor:
Alter der Rezension ≤ 90 Tage → 1,0
Alter der Rezension 91–365 Tage → 0,7
Alter der Rezension > 365 Tage → 0,4
Alter der Rezension = (heutiges Datum) − (Rezensions date-Feld) in Tagen.
cluster_score = Summe von complaint_weight für alle Rezensionen im Cluster.
Clusternamen – kritische Regel:
Du wirst abstrakte Namen schreiben wollen. Widerstehe. Verwende das exakte Verb und Substantiv aus den Rezensionen.
| ❌ Abstrahiert (falsch) | ✅ Sprache der Rezensenten (richtig) |
|---|---|
| „Stabilitätsprobleme“ | „Abstürze beim Exportieren als PDF“ |
| „Sync-Probleme“ | „Daten nach Sync zwischen Telefon und Desktop verloren“ |
| „Monetarisierungs-Hürden“ | „Bezahlschranke erscheint nach 3 Tagen, nicht nach 14 wie versprochen“ |
| „Leistungsabfall“ | „App friert jedes Mal ein, wenn ich suche“ |
| „Onboarding-Probleme“ | „Kann nicht herausfinden, wie ich einen Teammitglied einlade“ |
Regeln:
- Jede Rezension gehört zu genau einem Cluster (weise sie ihrem dominanten Thema zu)
- Verwerfe jedes Cluster mit weniger als 3 Rezensionen – protokolliere es als Rauschen
- Wähle 3–4 wörtliche Zitate pro Cluster: zuerst die niedrigste Sternebewertung, dann die aktuellsten
Gate 2 – Minimale Clustergröße: Nachdem Cluster mit weniger als 3 Rezensionen verworfen wurden, überprüfe, wie viele Cluster übrig bleiben.
Gate 3 – Flag für geringe Konfidenz: Wenn weniger als 3 Cluster übrig bleiben:
- Stoppe NICHT. Fahre mit der Ausgabe fort.
- Füge dies unmittelbar nach den App-Metadaten in die Briefing-Kopfzeile ein:
⚠ GERINGE KONFIDENZ: Nur [N] Beschwerdecluster(s) haben die minimale Evidenzschwelle erreicht (≥ 3 unterstützende Rezensionen). Die Ausgabe spiegelt begrenzte Daten wider. Ziehe einen Mitbewerber mit mehr Rezensionen in Betracht oder erweitere den Bewertungsfilter.
- Nimm Cluster der mittleren Stufe in die Ausgabe auf (Score ≥ 5)
Klassifizierung der Stufen (für die Ranglistentabelle in Abschnitt 1):
- Kritisch: Score ≥ 60
- Hoch: Score 15–59
- Mittel: Score 5–14 (nur enthalten, wenn Gate 3 zutrifft)
- Rauschen: Score < 5 (verwerfen, nicht aufnehmen)
Schreibe Cluster in {tmpdir}/asr-clusters.json:
{
"clusters": [
{
"name": "Clustername in der Sprache der Rezensenten",
"score": 34.5,
"tier": "Hoch",
"review_count": 14,
"verbatim_quotes": [
{"rating": 1, "text": "exakte Worte des Rezensenten", "date": "YYYY-MM-DD"},
...
]
}
],
"discarded_noise": 2,
"gate_3_triggered": false
}
Schritt 4 – Broken-Promise-Erkennung
Dies ist der Schritt, der dieses Skill von allen vorhandenen Tools unterscheidet. Er muss als eigener benannter Schritt ausgeführt werden.
Lade:
metadata.store_descriptionaus{tmpdir}/asr-raw.json- Alle Cluster aus
{tmpdir}/asr-clusters.json
Wenn store_description null ist: Setze store_description_available: false. Schreibe {tmpdir}/asr-promises.json mit einem leeren broken_promises-Array und detection_note wie unten angegeben. Fahre mit Schritt 5 fort.
Wenn die Store-Beschreibung verfügbar ist:
-
Behauptungen extrahieren. Eine Behauptung ist jede spezifische, überprüfbare Aussage über das App-Verhalten. Siehe
references/broken-promise.mdfür die vollständige Definition und Beispiele. Schließe vage Superlative, Teambeschreibungen und Pressezitate aus. -
Querverweise. Überprüfe für jede Behauptung alle Clusternamen und wörtlichen Zitate. Ein Widerspruch liegt vor, wenn das Cluster das Versagen des versprochenen Verhaltens direkt dokumentiert (mindestens 3 Rezensionen).
-
Broken-Promise-Datensätze erstellen – einen pro bestätigtem Widerspruch:
{ "claim_text": "wörtlicher Auszug aus der Store-Beschreibung", "complaint_cluster": "exakter Clustername", "gap_label": "Behauptet X; Benutzer berichten Y", "evidence_count": 18 }
Schreibe nach {tmpdir}/asr-promises.json:
{
"store_description_available": true,
"broken_promises": [...],
"no_contradictions_found": false,
"detection_note": null
}
Degradierte Zustände:
- Keine Beschreibung:
store_description_available: false,detection_note: "Store-Beschreibung nicht verfügbar (abgerufen am YYYY-MM-DD, leer zurückgegeben). Broken-Promise-Vergleich kann nicht durchgeführt werden." - Keine Widersprüche:
no_contradictions_found: true,detection_note: "Keine gebrochenen Versprechen erkannt. Die Store-Beschreibung scheint im Vergleich zu den Beschwerdeclustern keine übertriebenen Behauptungen aufzustellen."
Siehe references/broken-promise.md für Anti-Patterns (was NICHT markiert werden soll).
Schritt 5 – Texte generieren
Verwende die Cluster aus Schritt 3 und die gebrochenen Versprechen aus Schritt 4, um die Abschnitte 3–5 des Briefings zu generieren.
Textregeln (gelten für alle drei Abschnitte):
- Jede Überschrift und jede Richtung muss ihr Quellcluster zitieren:
[cluster: "cluster-name"] - Keine verbotenen Wörter: powerful, robust, seamless, innovative, game-changing, streamline, leverage, revolutionize, transform
- Keine erfundenen Statistiken – keine Prozentangaben oder Zahlen, es sei denn, ein Rezensent hat sie verwendet
- Wenn
product_contextangegeben wurde: mache die „Sag dies“-Richtungen spezifisch für die Funktionen dieses Produkts. Wenn nicht: schreibe sie als Positionierungsvorlagen, die der Benutzer ausfüllt. - Verwende die Sprache der Rezensenten in Überschriften – leite sie ab von oder zitiere den tatsächlichen Rezensionstext
Abschnitt 3 – Landing-Page-H1-Bank (3–5 Überschriften):
- Jede:
"[Überschriftstext]" [cluster: "cluster-name"] - ≤ 8 Wörter, wo möglich
- Spreche den frustrierten Benutzer direkt an
Abschnitt 4 – Werbetext-Richtungen (genau 3 Paare):
Cluster: [Clustername]
Nicht das: "[was der Mitbewerber behauptet oder eine generische schwache Alternative]"
Sag dies: "[Gegenbehauptung, die auf Beschwerdebeweisen basiert]"
Beweise: [N] Rezensenten berichteten [wörtliche Beschwerdenzusammenfassung]
Abschnitt 5 – Anti-Claim-Warnungen:
- Eine Warnung pro gebrochenem Versprechen aus Schritt 4
- Wenn Abschnitt 2 degradiert ist: ein einzelner Hinweis (siehe
references/brief-format.mdfür den genauen Wortlaut)
Schritt 6 – Selbst-QA
Überprüfe vor dem Speichern das generierte Briefing auf diese Prüfungen. Wenn eine Prüfung fehlschlägt, korrigiere das spezifische Element und prüfe erneut – speichere kein fehlschlagendes Briefing.
| Prüfung | Regel |
|---|---|
| Wörtliche Zitate vorhanden | Jedes Cluster hat ≥ 2 wörtliche Zitate |
| Keine verbotenen Wörter | Keines der 9 verbotenen Wörter erscheint in den Abschnitten 3–5 |
| Keine nicht belegten Prozentangaben | Jedes % in der Ausgabe muss auf die tatsächlichen Worte eines Rezensenten zurückzuführen sein |
| Alle Texte zitiert | Jede Überschrift und jedes „Sag dies“ hat eine [cluster: "name"]-Zitierung |
| Clusteranzahl ≥ 1 | Mindestens ein Cluster hat die Gates 2/3 überstanden |
| Abschnitt 2 vorhanden | Abschnitt 2 erscheint in der Ausgabe (in jedem Zustand) |
| Zitierte Bewertungen ≤ 3 | Alle wörtlichen Zitate stammen aus 1–3★-Rezensionen |
Hinweis zur Clusteranzahl: Das Minimum für ein bestandenes Briefing ist 1 Cluster (nicht 3). Das Gate-3-Flag für geringe Konfidenz behandelt Fälle, in denen < 3 Cluster überleben – das ist eine Warnung, kein Fehlschlag. Die Selbst-QA schlägt nur fehl, wenn 0 Cluster vorhanden sind.
Schritt 7 – Ausgabe speichern
Setze das vollständige Briefing gemäß dem Format in references/brief-format.md zusammen.
Speichere nach:
docs/review-briefs/[app-id]-[YYYY-MM-DD].md
Erstelle das Verzeichnis docs/review-briefs/, falls es nicht existiert.
Gib das vollständige Briefing auf dem Bildschirm aus.
Bereinige temporäre Dateien: {tmpdir}/asr-raw.json, {tmpdir}/asr-clusters.json, {tmpdir}/asr-promises.json.