Donnez-lui un identifiant d'app ou un lien Play Store et récupérez les avis sous forme de tableau - le texte, la note en étoiles, la date, les votes utiles, la version de l'app utilisée par l'auteur, et la réponse du développeur lorsqu'elle existe. Dix colonnes, une ligne par avis.
La plupart des exports d'avis sont un instantané unique. Ce qui rend celui-ci utile, c'est ce qui se passe quand vous le relancez le mois suivant.
Chaque ligne porte un review_id. Sur nos 842 lignes il y en avait 559 distincts - et pas une seule exécution ne contenait de doublon d'elle-même. Les répétitions étaient toutes entre exécutions, exactement ce à quoi on s'attend en extrayant deux fois la même app. Cela vous donne une clé propre : réunissez les exports, écartez les lignes dont vous détenez déjà le review_id, et ce qui reste est réellement nouveau.
La référence documente aussi un paramètre cutoff qui prend un horodatage le plus ancien, de sorte que vous pouvez ne demander rien de plus ancien que votre dernière extraction plutôt que tout récupérer pour en jeter la majeure partie. Entre cela et l'identifiant, une extraction mensuelle reste peu coûteuse quelle que soit la taille de l'historique d'avis - et il devient grand : notre échantillon remonte à août 2016.
Une différence structurelle avec les autres extracteurs de ce site mérite d'être signalée. Il n'y a pas de colonne query ici. L'app soumise est renvoyée sous app_id à la place, donc si vous regroupez plusieurs apps dans une exécution, c'est la colonne sur laquelle vous regroupez.
Quatre réglages, et deux d'entre eux sont ce qui garde une extraction récurrente petite.
Filtrer sur une seule note en étoiles ne fonctionne que lorsque le tri est réglé sur la note.
Voici l'en-tête de l'export dans l'ordre de la feuille, identique sur les 11 exécutions. Les taux de remplissage sont comptés sur les 842 lignes que ces exécutions ont renvoyées, couvrant 559 avis distincts pour trois apps.
com.facebook.katana. Présent sur les 842. C'est ce qui identifie l'entrée - il n'y a pas de colonne query sur ce service.https:// et toujours sur l'hôte de contenu utilisateur de Google.2025-03-08. Présent sur les 842 et conforme à YYYY-MM-DD dans chacune. Les nôtres couvraient presque dix ans.8.116.0.213. Présent sur 702 des 842 - mais voir la note ci-dessous, car la couverture varie beaucoup selon l'app.Huit des dix colonnes étaient présentes sur absolument chaque ligne. Seules app_version et reply varient, et toutes deux d'une façon qu'il vaut mieux comprendre avant de construire - la note ci-dessous les couvre. À propos de l'ordre également : le tableur place review_id en dernier, tandis que l'export JSON le place en deuxième. Les mêmes dix colonnes dans les deux cas, lisez donc par nom plutôt que par position.
Les quatre viennent de la lecture des 842 lignes et non de la référence, et chacune change la façon dont vous écririez le job.
Nos 842 lignes contenaient 559 valeurs distinctes de review_id, et aucune exécution prise isolément ne contenait de doublon d'elle-même - chaque répétition venait d'une autre exécution, en extrayant la même app plus d'une fois. L'identifiant est donc stable entre extractions et unique au sein d'une seule. Réunissez vos exports dessus et vous obtenez un historique d'avis qui grandit plutôt qu'un tas de fichiers quasi identiques.
reply était renseignée sur 15 lignes sur 842 - moins de deux pour cent. Chacune de ces quinze portait sur un avis une étoile, et les quinze appartenaient à une seule app ; les deux autres apps de notre échantillon n'en avaient aucune. C'est un échantillon bien trop petit pour en faire une règle sur le comportement des développeurs, mais largement suffisant pour dire qu'une fonctionnalité fondée sur les réponses regardera une colonne presque vide la plupart du temps.
Globalement elle était présente sur 702 lignes sur 842, ce qui semble confortable jusqu'à ce qu'on ventile par app : 90 % sur l'une, 84 % sur une autre et 14 % sur la troisième. Une analyse qualité version par version est donc réaliste pour certaines apps et pas pour d'autres, et le chiffre agrégé ne vous dira pas dans quel cas vous êtes. Vérifiez la couverture sur votre propre app avant d'y adosser un graphique.
Sur nos lignes la répartition était de 35 % une étoile, 11 % deux, 12 % trois, 7 % quatre et 35 % cinq - une courbe en U, avec le moins d'avis au milieu. Quelle que soit la moyenne que vous en tirez, elle ne décrit presque personne. Les lectures utiles sont la forme elle-même et le texte derrière chacun de ses deux bouts, ce qui est précisément la raison d'extraire les avis plutôt que la note affichée par la boutique.
Là où un historique complet d'avis vaut mieux que le résumé de la fiche.
Comme app_version voyage avec l'avis, vous pouvez découper le ressenti par version plutôt que par mois. Une baisse de note cesse d'être un mystère et devient une release précise - et si les avis de la version suivante remontent, vous avez votre réponse sans avoir rien instrumenté.
Les avis des concurrents sont publics et étonnamment francs. Extrayez le texte des avis une étoile d'une app rivale et vous obtenez une liste non filtrée de ce que les gens ne supportent pas chez elle - à la fois une feuille de route et un réservoir de formulations pour votre propre positionnement.
Fixez la liste d'apps, relancez selon une cadence et dédupliquez sur review_id. Ce qui arrive à chaque fois n'est que le nouveau, si bien qu'un pic d'avis une étoile se voit au moment où il se produit, et non en fin de trimestre quand quelqu'un consulte enfin la boutique.
Pas d'abonnement, pas de minimum, pas de licence par siège. Vos 500 premières lignes sont pour nous - ensuite, paiement à l'usage.
Pour chaque nouveau compte, une seule fois. Sans carte bancaire. Tous les extracteurs débloqués. 500 lignes représentent plusieurs apps avec une limite par app raisonnable, assez pour voir la forme des notes et vérifier la couverture de version de votre propre app.
Environ 2 $ pour 1 000 avis. Les extractions récurrentes sont là où cela devient économique : dédupliquer sur l'identifiant d'avis et utiliser le cutoff fait qu'un rafraîchissement mensuel coûte une fraction de la première exécution, quelle que soit la longueur de l'historique.
Tarifs au volume, SLA, workers dédiés et onboarding sur mesure pour les équipes qui surveillent un portefeuille d'apps à cadence fixe. Donnez-nous vos chiffres et nous établirons un devis.
LIVESCRAPER10 au paiement.La plupart des produits sortent sur les deux plateformes, et les plaintes coïncident rarement. Ces deux-là couvrent l'autre côté.
Le même travail du côté d'Apple. Exécuter les deux pour un produit est la seule façon honnête de distinguer un bug propre à une plateforme d'un vrai bug.
Avant de pouvoir lire les avis d'une app, il vous faut sa fiche. Cherchez un jeu de mots-clés et obtenez les apps qui se positionnent dessus, une ligne chacune.
Réponse courte : oui, avec une chose à garder en tête - un avis porte un nom affiché, traitez-le donc avec un peu plus de soin qu'une grille tarifaire.
Les avis du Play Store sont publics. N'importe qui peut les lire sans compte, et collecter des informations publiquement visibles à des fins de recherche est une pratique établie de longue date. Tant que les données sont publiquement disponibles et que le processus ne perturbe pas le site, aucune loi fédérale ne l'interdit.
Le point à traiter délibérément est que author et author_image décrivent une personne, même seulement par un nom affiché qu'elle a choisi de publier. Au sens du RGPD ce sont des données personnelles, les obligations habituelles s'appliquent donc : avoir une raison de les conserver, ne pas les garder plus longtemps que nécessaire, et ne pas chercher à les enrichir jusqu'à une identité réelle. Si votre analyse porte sur l'app et non sur les auteurs - ce qui est presque toujours le cas - écarter ces deux colonnes à l'import ne vous coûte rien.
Les conditions de Google restreignent l'accès automatisé, cela reste donc une question de conditions. Nous ne touchons à rien derrière une connexion, n'exécutons aucun traceur tiers sur la couche de données, et vos exports s'auto-suppriment au bout de 30 jours.
Les questions que nous entendons le plus. Autre chose ? Parlons-en - ce sont des humains, pas des bots, qui écrivent les réponses.
app_id, author, author_image, rating, date, review, likes, app_version, reply et review_id. C'est l'en-tête de l'export, identique sur 11 exécutions. Huit étaient présentes sur chacune de nos 842 lignes ; seules app_version et reply variaient. Le tableur place review_id en dernier et le JSON le place en deuxième, lisez donc par nom plutôt que par position.com.facebook.katana ou un lien Play Store complet vers la même app se résolvent tous deux, et vous pouvez les mélanger dans une exécution allant jusqu'à 1 000. L'app est renvoyée sous app_id sur chaque ligne, ce qui est le champ sur lequel regrouper quand vous en soumettez plusieurs.review_id, et sur nos 842 lignes aucune exécution n'en a jamais répété un en interne - les doublons venaient tous d'autres exécutions. Dédupliquez dessus et vous ne gardez que le nouveau. Il existe aussi un réglage cutoff qui prend un horodatage le plus ancien, pour éviter de récupérer l'ancien historique.2016-08-16 à 2026-07-10 - près d'une décennie d'historique pour les apps que nous avons extraites. La profondeur d'une exécution donnée dépend de la limite par app et du tri que vous choisissez.reply était renseignée sur 15 de nos 842 lignes - moins de deux pour cent - et les quinze portaient toutes sur des avis une étoile d'une seule app. Prévoyez que la colonne soit vide la plupart du temps.Soumettez vos identifiants d'apps et récupérez les avis sous forme de lignes - texte, note, date, votes utiles, version et réponse. Vos 500 premières lignes sont gratuites.
Le Play Store vous montre une moyenne d'étoiles et les avis qu'il juge les plus pertinents. Ni l'un ni l'autre n'est très utile pour travailler : la moyenne aplatit une distribution qui est généralement tout sauf plate, et les avis qu'on vous montre sont une poignée tournante choisie par quelqu'un d'autre. L'Extracteur d'Avis Google Play renvoie à la place les avis sous-jacents sous forme de tableau - une ligne par avis, portant le texte tel qu'il a été écrit, la note en étoiles, la date, le nombre de votes utiles, la version de l'app utilisée par l'auteur, la réponse du développeur lorsqu'elle existe, et un identifiant stable de l'avis lui-même. Soumettez des identifiants d'apps ou des liens Play Store, jusqu'à 1 000 par exécution, choisissez combien d'avis par app et comment les trier, et exportez en CSV, JSON ou Excel.
Les dix colonnes de cette page sont mesurées plutôt que supposées. Ce sont l'en-tête de l'export, identique sur 11 exécutions, et chaque chiffre cité provient des 842 lignes que ces exécutions ont renvoyées - 559 avis distincts pour trois apps. Huit des dix étaient présentes sur chaque ligne. Deux ne l'étaient pas, et il vaut la peine de connaître les deux avant de construire : app_version apparaissait sur 702 des 842 au total, mais sa couverture allait de 90 % sur une app à 14 % sur une autre, et reply n'apparaissait que sur 15 lignes en tout. Une limite de la preuve doit être dite clairement : ces exécutions couvraient trois apps, ce qui suffit à établir la forme de la sortie et le comportement des colonnes, et ne suffit pas à prédire ce que telle app à vous renverra. L'offre gratuite est là pour ça.
Ce qui rend ce service digne d'être branché sur quelque chose de permanent, c'est l'identifiant d'avis. Sur les 842 lignes il y avait 559 identifiants distincts, et aucune exécution ne contenait de doublon d'elle-même - chaque répétition venait d'une autre exécution, exactement comme on s'y attend en extrayant deux fois la même app. Cela fait de l'identifiant une clé de déduplication fiable : réunissez vos exports, écartez les identifiants que vous détenez déjà, et vous obtenez un historique d'avis qui grandit au lieu d'un dossier d'instantanés qui se recouvrent. La référence documente aussi un paramètre cutoff prenant un horodatage le plus ancien, de sorte qu'une extraction récurrente n'a pas à récupérer l'archive à chaque fois. Cela compte plus qu'il n'y paraît, car l'archive est profonde - notre échantillon remontait à août 2016.
Deux autres choses façonnent la lecture de ces données. La première est la polarisation : les notes de notre échantillon se répartissaient à environ 35 % sur une étoile et 35 % sur cinq, avec seulement 7 % sur quatre, si bien que le milieu de l'échelle est quasi vide et que toute moyenne calculée dessus ne décrit presque personne. Le contenu intéressant se trouve aux deux extrémités, ce qui est l'argument pour lire le texte plutôt que la note. La seconde est que c'est le seul extracteur ici sans colonne query - l'app soumise revient sous app_id, c'est donc le champ sur lequel regrouper quand vous en soumettez plusieurs. Notez aussi que les noms de colonnes de l'export lui sont propres ; la référence de l'API décrit les mêmes données avec d'autres noms pour sa réponse brute, construisez donc contre l'en-tête que vous recevez réellement. Commencez gratuitement : vos 500 premières lignes ne coûtent rien et ne nécessitent pas de carte bancaire.