Avis App Store vers BigQuery

App Store Connect vous donne une note et une liste. Il ne vous dira jamais que sept vitrines se situent entre 4,4 et 4,7 pendant que le Japon est à 1,6, parce qu'il n'a aucun moyen de mettre ces chiffres côte à côte. Dans BigQuery, c'est un GROUP BY sur une colonne que vous avez déjà, et ça tient en cinq lignes de SQL.

Apple classe chaque avis App Store sous une vitrine, et Reviewflowz écrit cette vitrine sur chaque ligne comme le pays. Le pays est donc une vraie donnée plutôt qu'une supposition à partir de la langue, et un problème propre à un marché a une forme que vous pouvez interroger.

Cette forme est le diagnostic. Un crash se lit comme tous les pays qui chutent ensemble. Une chaîne traduite qui ne tient plus dans son bouton, ou un champ de recherche qui a cessé d'accepter la saisie japonaise, se lit comme un seul pays qui chute pendant que les autres ne bougent pas. Le pays vous dit quelle équipe appeler.

La suite est une clause WHERE, parce que le texte complet de l'avis est une colonne ordinaire. Comptez les avis mentionnant la recherche depuis le premier du mois, répartis par pays, et vous avez le rapport de bug avant que quiconque n'en dépose un.

Il n'y a pas de destination BigQuery gérée sur laquelle cliquer, et cette page ne prétendra pas le contraire. Ce que Reviewflowz vous donne, c'est une feuille Google Sheets dans votre propre Drive qu'il tient à jour : un nouvel avis App Store devient une nouvelle ligne dans la demi-heure, un avis modifié met à jour sa ligne, et un avis qu'Apple retire perd sa ligne.

BigQuery lit une feuille Google Sheets stockée sur Drive comme une table externe. Un seul CREATE EXTERNAL TABLE pointant vers l'URL de la feuille, et app_store_reviews existe dans votre ensemble de données, s'interroge comme n'importe quelle autre table, et est à jour au moment de la requête parce qu'il lit la feuille, pas une copie. Rien à planifier, rien à maintenir en vie.

Si vous préférez une table native partitionnée, l'API Review est l'autre voie. Interrogez-la ou récupérez le webhook, puis chargez-la avec le job que vous exécutez déjà pour chaque autre source. C'est un travail que votre équipe data écrit une fois, et l'appeler un job plutôt qu'une case à cocher, c'est tout l'intérêt.

Dans les deux cas, l'historique vient avec. Sur un forfait payant, un clic charge chaque avis App Store passé, pour que la courbe de tendance démarre pleine plutôt que de se remplir sur le trimestre suivant. Connectez la fiche un mardi matin, et vous pouvez interroger trois ans d'avis dès l'après-midi.

La table vit dans votre projet Google Cloud, dans la région que vous avez choisie, sous l'IAM que vous gérez déjà et la politique de rétention que vous avez déjà écrite. Accorder l'accès à un data scientist prend les mêmes quelques clics que pour tout autre ensemble de données, et le retirer de nouveau prend les mêmes quelques clics en sens inverse.

Vous choisissez ce qui en sort. Choisissez les fiches App Store, et par fiche choisissez les vitrines. Laissez la liste de pays vide et chaque marché où l'appli se vend est inclus, ou nommez le Japon et l'Allemagne et seules ces lignes arrivent. Ajoutez un filtre de note, et la table ne contient plus qu'un à trois étoiles et rien d'autre.

L'équipe de localisation obtient ainsi un ensemble de données de ses seuls marchés sans que personne n'ait à maintenir un filtre, et le responsable support obtient celui des seules notes basses, à partir du même compte et des mêmes fiches. Deux périmètres alimentant deux tables est une configuration normale, pas un contournement.

Une chose à savoir avant de dimensionner quoi que ce soit : le volume d'avis App Store n'est pas réparti régulièrement. Il s'accumule dans les heures qui suivent une sortie et les jours qui suivent une mise en avant, donc une table qui paraît calme tout le mois collecte l'essentiel de ses lignes en deux après-midis.