Gestion des Avis

Que fait Gestion des Avis ?

Utilisez cette compétence pour l'analyse des avis, la gestion de la réputation, les projets de réponses, les projets de plaintes/signalements, l'extraction d'insights produit, l'analyse de CSV d'avis téléchargés et la stratégie d'amélioration des notes.

Workflow MCP

1. Utilisez app-store-connect-mcp.
2. Avis unique : lisez avec get_review_data.
3. Liste d'avis : lisez avec get_reviews_data.
4. Utilisez unansweredOnly, badRatingOnly et maxRating pour affiner les listes d'avis.
5. Utilisez le contexte du projet pour le ton, les liens de support, les problèmes connus et la politique de réponse.
6. Analysez la santé des avis, les thèmes, les opportunités de réponse et l'éligibilité aux plaintes/signalements.
7. Validez avec validate_ai_companion_data cible review ou reviewList.
8. Si on vous demande d'appliquer, remplissez les projets avec fill_review ou fill_reviews.

Champs à remplir

Avis unique :

• responseBody
• complaintReason
• concernType

Liste d'avis :

• reviews : tableau ou map par reviewId, chacun avec responseBody, complaintReason et/ou concernType

Analyse CSV d'avis

Utilisez ce mode lorsque l'utilisateur télécharge ou référence un CSV contenant tous les avis. L'analyse CSV ne nécessite pas MCP sauf si l'utilisateur souhaite remplir les réponses/plaintes dans ASO.dev.

Avant l'analyse :

1. Identifiez les colonnes du CSV. Colonnes courantes : ID avis, note, titre, corps/texte, langue/pays, version de l'app, date, réponse du développeur, date de réponse, appareil/plateforme.
2. Normalisez les dates, notes, langues, versions et valeurs vides.
3. Dédupliquez les lignes répétées par ID avis ou par titre/corps/date exacts.
4. Segmentez par note, langue/pays, version de l'app, période de date, statut répondu/non répondu et longueur de l'avis.
5. Si le CSV est volumineux, échantillonnez des exemples pour les citations mais calculez les comptes/thèmes sur l'ensemble du fichier.

Analysez pour :

• Sentiment par note et texte : positif, neutre, négatif, mitigé.
• Thèmes : bugs/crashes, friction UX, prix/paywall, onboarding, performances, compte/connexion, localisation, support, qualité du contenu.
• Demandes de fonctionnalités : capacités manquantes, motifs répétés "j'aurais aimé que...", comparaisons avec les concurrents.
• Risque produit : régressions par version de l'app/date, bugs graves, intention de remboursement/annulation, préoccupations de confiance/vie privée.
• Langage ASO : phrases que les utilisateurs utilisent pour décrire la valeur, les résultats et les cas d'utilisation.
• Opportunités de support : avis à faible note sans réponse, réponses obsolètes, réponses à fort impact.

La sortie CSV doit inclure des comptes et des exemples représentatifs. Ne collez pas de gros dumps d'avis bruts.

Cadre d'analyse des avis

Classez les thèmes :

Thème	Signification	Action
Bugs/crashes	Échec technique, flux cassé, régression	Escalader la correction, répondre uniquement avec le statut connu
Demandes de fonctionnalités	Les utilisateurs demandent une capacité manquante	Suivre la fréquence et le segment d'utilisateurs
Plaintes UX	Confus, lent, frustrant, difficile à utiliser	Prioriser la révision UX/produit
Prix/paywall	Trop cher, abonnement flou, confusion d'essai	Utiliser monetization-strategy si répété
Éloges	Valeur, plaisir, fonctionnalités préférées	Remercier et apprendre le langage de conversion
Mentions de concurrents	Comparaisons ou raisons de changement	Exploiter les lacunes de positionnement

Signaux de santé des avis :

• Note moyenne et tendance, si disponibles
• Volume récent de faibles notes
• Avis négatifs sans réponse
• Taux de réponse et fraîcheur des réponses
• Thèmes répétés de bugs/UX/prix
• Candidats aux plaintes/signalements

Règles de réponse

• Soyez calme, précis et concis.
• Priorisez les réponses rapides ; visez 24 à 48 heures pour les avis négatifs à fort impact lorsque cela est opérationnellement possible.
• Ne discutez pas avec l'évaluateur.
• Ne divulguez pas de données internes.
• Ne promettez pas de correctifs sauf s'ils sont confirmés.
• Ne demandez pas d'informations personnelles en public.
• Pour les avis en colère, reconnaissez le problème et orientez vers le support.
• Ne demandez pas à l'utilisateur de modifier sa note.
• Ne copiez-collez pas des réponses identiques sur plusieurs avis.

Cadre de réponse

Utilisez HEAR pour les avis négatifs :

1. Hear (Entendre) : reconnaissez le problème spécifique.
2. Empathize (Empathie) : montrez que vous comprenez la frustration.
3. Act (Agir) : expliquez ce qui est connu, corrigé ou en cours d'investigation.
4. Resolve (Résoudre) : invitez au support direct avec le bon chemin de contact.

Les modèles ne sont que des points de départ :

• Bug : reconnaissez, mentionnez la version corrigée connue uniquement si confirmée, invitez à mettre à jour/contacter le support.
• Demande de fonctionnalité : remerciez, dites qu'elle est partagée avec l'équipe, évitez de promettre la feuille de route.
• Négatif vague : excusez-vous brièvement, demandez des détails via le support.
• Positif : remerciez et faites écho au bénéfice qu'ils ont nommé.

Règles de plainte/signalement

• Signalez uniquement lorsque l'avis semble abusif, spam, frauduleux, non pertinent ou autrement en violation de la politique.
• Ne signalez pas un retour négatif valide simplement parce qu'il a une faible note.
• Gardez les raisons de la plainte factuelles et courtes.

Stratégie d'incitation aux notes

Utilisez pour des conseils uniquement ; cette compétence MCP remplit les projets d'avis, pas le code de l'application.

• Déclenchez uniquement après un moment de valeur positive.
• Évitez la première session, l'onboarding, les erreurs, les crashes, les échecs de paiement ou la frustration de support.
• Bons moments : tâche terminée, objectif atteint, série, temps/argent économisé, restauration/export/partage réussi.
• Respectez les limites de la plateforme et n'incitez pas les avis.
• Si les mauvais avis sont causés par des problèmes produit, corrigez le problème avant d'augmenter le volume d'incitation.

Extraction d'insights produit

Utilisez les avis pour extraire :

• Les fonctionnalités les plus appréciées et le langage exact des utilisateurs pour les métadonnées/captures d'écran.
• Les bugs récurrents ou échecs UX les plus courants.
• Les objections de monétisation et la confusion autour des abonnements.
• La fréquence des demandes de fonctionnalités.
• Les concurrents mentionnés et les déclencheurs de changement.

Notation des demandes de fonctionnalités :

Signal	Signification
Fréquence	Combien d'avis mentionnent la demande
Impact sur la note	Si la demande apparaît dans les avis à faible note ou à risque de désabonnement
Segment	Langue, version, type d'utilisateur ou pays où elle apparaît
Adéquation stratégique	Si elle correspond au positionnement et à la feuille de route de l'application
Effort/risque	Si elle nécessite du travail produit, backend, design, prix ou politique

Sortie

# Santé des avis et travail de réponse

Application :
Mode :
Note/tendance :
Filtres :
Source CSV :

## Résumé de santé
- Total des avis chargés :
- Avis à faible note :
- Avis sans réponse :
- Risque principal :

## Sentiment
| Segment | Positif | Neutre | Négatif | Mitigé | Notes |
|---|---:|---:|---:|---:|---|

## Thèmes
| Thème | Compte | Impact sur la note | Preuve | Action |
|---|---:|---|---|---|

## Fonctionnalités/demandes manquantes
| Demande | Compte | Segment utilisateur | Preuve | Recommandation produit |
|---|---:|---|---|---|

## Projets
| ID avis | Note | Thème | Action | Projet |
|---|---:|---|---|---|

## Insights produit
| Insight | Preuve | Propriétaire/action recommandé |
|---|---|---|

## Plan d'amélioration des notes
1.
2.
3.

## Validation
- Colonnes CSV mappées :
- Comptes basés sur les données complètes :
- Ton sûr :
- Pas de données privées :
- Plainte justifiée :
- Validation MCP :
- Prêt à remplir :