Recensioni App Store su BigQuery

App Store Connect le dà una valutazione e un elenco. Non le dirà mai che sette storefront si collocano tra 4,4 e 4,7 mentre il Giappone è a 1,6, perché non ha modo di mettere quei numeri a confronto. In BigQuery è una GROUP BY su una colonna che ha già, cinque righe di SQL.

Apple archivia ogni recensione App Store sotto uno storefront, e Reviewflowz scrive quello storefront su ogni riga come paese. Il paese è quindi un dato reale e non una supposizione dedotta dalla lingua, e un problema legato a un mercato ha una forma che può interrogare.

Quella forma è la diagnosi. Un crash si legge come tutti i paesi che scendono insieme. Una stringa tradotta che non entra più nel pulsante, o un campo di ricerca che ha smesso di accettare l'input in giapponese, si legge come un solo paese che scende mentre gli altri restano fermi. Il paese le dice quale team chiamare.

Il passo successivo è una clausola WHERE, perché il testo completo della recensione è una colonna come le altre. Conti le recensioni che citano la ricerca dal primo del mese, suddivise per paese, e ha il bug report prima ancora che qualcuno lo apra.

Non esiste una destinazione BigQuery gestita da un semplice clic, e questa pagina non farà finta che esista. Quello che Reviewflowz le offre è un Google Sheet nel suo Drive, tenuto sempre aggiornato: una nuova recensione App Store diventa una nuova riga entro mezz'ora, una recensione modificata aggiorna la sua riga, e una recensione che Apple rimuove perde la sua riga.

BigQuery legge un Google Sheet basato su Drive come tabella esterna. Una singola CREATE EXTERNAL TABLE sull'URL del foglio e app_store_reviews esiste nel suo dataset, si interroga come qualsiasi altra tabella, ed è corretta al momento della query perché legge il foglio stesso, non una copia. Niente da pianificare, niente da tenere attivo.

Se preferisce invece una tabella nativa partizionata, la Review API è l'altra strada. La interroghi a intervalli oppure usi il webhook, poi la carichi con il job che usa già per ogni altra fonte. È un lavoro che il suo team dati scrive una sola volta, e chiamarlo job invece che una casella da spuntare è proprio il punto.

In entrambi i casi lo storico arriva insieme al resto. Su un piano a pagamento, un clic carica tutte le recensioni App Store passate, così la linea di tendenza parte già completa invece di riempirsi nel trimestre successivo. Colleghi la scheda martedì mattina e quello stesso pomeriggio può interrogare tre anni di recensioni.

La tabella vive nel suo progetto Google Cloud, nella regione che ha scelto, sotto l'IAM che usa già e la policy di conservazione che ha già scritto. Concedere l'accesso a un data scientist è la stessa manciata di clic di ogni altro dataset, e revocarlo di nuovo è altrettanto rapido.

Sceglie lei cosa esce. Selezioni le schede App Store, e per ogni scheda gli storefront. Lasci vuoto l'elenco dei paesi e sono inclusi tutti i mercati in cui l'app è in vendita, oppure indichi Giappone e Germania e arriveranno solo quelle righe. Aggiunga un filtro sul punteggio e la tabella conterrà solo le recensioni da una a tre stelle.

Così il team di localizzazione ottiene un dataset dei soli mercati che le interessano senza che nessuno debba mantenere un filtro, e il responsabile dell'assistenza ne ottiene uno con solo i punteggi bassi, dallo stesso account e dalle stesse schede. Due ambiti che alimentano due tabelle è una configurazione normale, non un espediente.

Una cosa da sapere prima di dimensionare qualsiasi cosa: il volume di recensioni App Store non è distribuito in modo uniforme. Si accumula nelle ore dopo un rilascio e nei giorni dopo una segnalazione in evidenza, quindi una tabella che sembra silenziosa per tutto il mese raccoglie la maggior parte delle sue righe in due pomeriggi.