Recensioni Google in BigQuery

Il profilo Google Business fornisce una valutazione per sede e un elenco di recensioni sotto di essa. Non le dirà mai che trentuno sedi si trovano tra 4,5 e 4,7 mentre una è a 3,4, perché non ha modo di mettere questi numeri a confronto tra loro. Nel data warehouse questo è un GROUP BY e un ORDER BY, e sta su un solo schermo.

Google archivia ogni recensione sotto una sede, e Reviewflowz assegna a ogni sede il proprio profilo, così il nome della sede viene scritto su ogni riga invece di essere dedotto dal testo. Un problema circoscritto a una sede assume così una forma interrogabile.

Quella forma è la diagnosi. Un aumento di prezzo si legge come l'intera rete che si sposta insieme. Un buco nei turni, un lettore di carte che ha smesso di funzionare, un manager andato via a marzo, si legge invece come una singola sede che scende mentre le vicine restano stabili. Sapere quale sede le dice chi chiamare, e basta una query invece di un'intuizione.

Il passo successivo è una clausola WHERE, perché il testo completo della recensione è una colonna ordinaria. Conti le recensioni che menzionano il parcheggio da marzo, suddivise per sede, e avrà individuato il problema di rete prima che qualcuno lo sollevi in una riunione regionale.

Non esiste una destinazione BigQuery gestita da un semplice clic, e questa pagina non farà finta che esista. Ciò che Reviewflowz offre è un Google Sheet nel suo Drive che mantiene aggiornato: una nuova recensione Google diventa una nuova riga entro mezz'ora, una recensione modificata aggiorna la propria riga, e una recensione rimossa da Google perde la propria riga.

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

Se preferisce una tabella nativa partizionata, la Review API è l'altra strada. La interroghi periodicamente o usi il webhook, poi la carichi con lo stesso job che già usa per ogni altra fonte. È un lavoro che un data team scrive una volta sola.

In entrambi i casi lo storico arriva incluso. Su un piano a pagamento, un clic carica tutte le recensioni Google passate di ogni sede, così la linea di tendenza parte già completa invece di riempirsi nel trimestre successivo.

Il volume delle recensioni Google segue il traffico in negozio, non un calendario di uscite. Sale il venerdì, raddoppia il sabato e resta alto la domenica, poi risale per due settimane dopo una campagna locale. Una media mensile sta sopra cinque di quei giorni e ben sotto gli altri due, quindi non descrive nessuno di essi.

Questo è un problema di modellazione, non di reporting, ed è esattamente a cosa serve un data warehouse. Confronti giorno con lo stesso giorno della settimana, applichi una finestra di sette giorni alla tendenza, e un sabato negativo smette di nascondersi dentro un numero mensile.

Sceglie lei cosa far confluire in uscita. Selezioni le sedi, e aggiunga un filtro sul punteggio se lo desidera, così il team di rete riceve ogni sede e il responsabile del supporto riceve una tabella che contiene solo da una a tre stelle.

E la tabella vive nel suo progetto Google Cloud, nella regione che ha scelto, sotto lo stesso IAM che già gestisce e la stessa politica di conservazione che ha già scritto. Concedere l'accesso a un data scientist richiede gli stessi pochi clic di qualsiasi altro dataset lì dentro, e revocarlo di nuovo richiede altrettanti pochi clic.