App Store Bewertungen in BigQuery

App Store Connect gibt Ihnen eine Bewertung und eine Liste. Es wird Ihnen nie sagen, dass sieben Stores zwischen 4,4 und 4,7 liegen, während Japan bei 1,6 steht, denn es hat keine Möglichkeit, diese Zahlen nebeneinanderzustellen. In BigQuery ist das ein GROUP BY auf eine Spalte, die Sie schon haben, fünf Zeilen SQL.

Apple ordnet jede App Store Bewertung einem Store zu, und Reviewflowz schreibt diesen Store als Land in jede Zeile. Das Land ist damit echte Daten statt eine Vermutung aus der Sprache, und ein marktförmiges Problem bekommt eine Form, nach der Sie abfragen können.

Diese Form ist die Diagnose. Ein Absturz zeigt sich darin, dass jedes Land gemeinsam einbricht. Ein übersetzter String, der nicht mehr auf seinen Button passt, oder ein Suchfeld, das keine japanische Eingabe mehr annimmt, zeigt sich darin, dass ein Land einbricht, während sich der Rest nicht bewegt. Welches Land sagt Ihnen, welches Team Sie anrufen müssen.

Die Nachfrage ist eine WHERE-Klausel, denn der vollständige Bewertungstext ist eine gewöhnliche Spalte. Zählen Sie die Bewertungen, die seit dem Monatsersten die Suche erwähnen, aufgeteilt nach Land, und Sie haben den Bugreport, bevor ihn jemand einreicht.

Es gibt kein verwaltetes BigQuery-Ziel zum Anklicken, und diese Seite tut nicht so, als gäbe es eins. Was Reviewflowz Ihnen gibt, ist ein Google Sheet in Ihrem eigenen Drive, das es aktuell hält: Eine neue App Store Bewertung ist innerhalb einer halben Stunde eine neue Zeile, eine bearbeitete Bewertung aktualisiert ihre Zeile, und eine Bewertung, die Apple entfernt, verliert ihre Zeile.

BigQuery liest ein Drive-basiertes Google Sheet als externe Tabelle. Ein CREATE EXTERNAL TABLE auf die Sheet-URL, und app_store_reviews existiert in Ihrem Dataset, lässt sich abfragen wie jede andere Tabelle und ist zum Abfragezeitpunkt korrekt, weil es das Sheet liest, keine Kopie. Nichts zu planen, nichts am Leben zu halten.

Wenn Sie stattdessen eine native, partitionierte Tabelle wollen, ist die Review API der andere Weg. Pollen Sie sie oder nehmen Sie den Webhook, und laden Sie dann mit demselben Job, den Sie für jede andere Quelle schon ausführen. Das ist Arbeit, die Ihr Datenteam einmal schreibt, und genau darum geht es: ein Job, keine Checkbox.

So oder so kommt die Historie mit. In einem bezahlten Plan lädt ein Klick jede vergangene App Store Bewertung, sodass die Trendlinie von Anfang an voll ist, statt sich erst über das nächste Quartal zu füllen. Verbinden Sie den Eintrag am Dienstagmorgen, und am Nachmittag können Sie drei Jahre Bewertungen abfragen.

Die Tabelle liegt in Ihrem Google Cloud Projekt, in der Region, die Sie gewählt haben, unter dem IAM, das Sie schon betreiben, und der Aufbewahrungsrichtlinie, die Sie schon geschrieben haben. Einem Data Scientist Zugriff zu geben, sind dieselben paar Klicks wie bei jedem anderen Dataset, und ihn wieder zu entziehen, sind dieselben paar Klicks zurück.

Sie bestimmen, was herausfließt. Wählen Sie die App Store Einträge, und pro Eintrag die Stores. Lassen Sie die Länderliste leer, und jeder Markt, in dem die App verkauft wird, ist dabei, oder nennen Sie Japan und Deutschland, und nur diese Zeilen kommen an. Fügen Sie einen Score-Filter hinzu, und die Tabelle enthält nur ein bis drei Sterne.

So bekommt das Lokalisierungsteam ein Dataset nur seiner Märkte, ohne dass jemand einen Filter pflegen muss, und die Support-Leitung eines nur mit den niedrigen Scores, aus demselben Account und denselben Einträgen. Zwei Geltungsbereiche, die zwei Tabellen speisen, sind ein normales Setup, kein Workaround.

Eine Sache, die Sie wissen sollten, bevor Sie irgendetwas dimensionieren: Das App-Store-Bewertungsvolumen verteilt sich nicht gleichmäßig. Es stapelt sich in den Stunden nach einem Release und den Tagen nach einer Apple-Empfehlung, sodass eine Tabelle, die den ganzen Monat ruhig wirkt, die meisten ihrer Zeilen an zwei Nachmittagen sammelt.