Tutto ciò che costruiamo davvero quando un'azienda dice di voler usare Google in modo corretto: l'architettura dati GCP completa, raccolta GA4 pulita, pipeline BigQuery, Looker e Looker Studio per il reporting, amministrazione Workspace, automazioni Apps Script, topologia Pub/Sub, identità e sicurezza, e come tutto si connette al resto dello stack. Nessuna approssimazione, nessun pitch commerciale. Solo la meccanica e l'ordine con cui la affrontiamo.
Questa guida è lunga perché l'argomento è ampio. Google Cloud da solo comprende decine di servizi, e Google Workspace è un'intera piattaforma di produttività e identità. La maggior parte dei team usa una frazione di ciò a cui ha accesso, spesso in modo impreciso. Quello che segue è un resoconto preciso di come pensiamo allo stack, a quali parti rivolgersi per prime e come ogni livello si connette al successivo. Leggila dall'inizio alla fine e capirai come affrontiamo un intervento prima ancora che ci parliamo.
Google Cloud Platform non è un singolo prodotto. Conta circa duecento servizi, la maggior parte dei quali non ti serviranno mai. I quattro che contano di più per un'azienda in crescita sono BigQuery (il tuo data warehouse), Cloud Run (workload containerizzati senza gestione server), Cloud Functions (codice piccolo attivato da eventi) e Pub/Sub (il livello di messaggistica che tiene insieme tutto). Tutto il resto o si basa su questi oppure è un'esigenza specialistica che saprai di avere quando ci arrivi.
Google Workspace sta a parte ma si connette. È la tua email, il calendario, i documenti e il provider di identità, e per molti team è il luogo in cui le decisioni vengono davvero prese, anche quando quelle decisioni sono tecnicamente guidate da dati che si trovano in altri sistemi. L'opportunità di integrazione non è solo connettere Workspace a Cloud; è rendere intelligenti gli strumenti che le persone usano già.
Il problema più comune che vediamo al momento dell'audit non è che sono stati scelti gli strumenti sbagliati. È che gli strumenti giusti sono stati adottati uno alla volta, senza un modello dati che li connetta, così l'azienda ha GA4, BigQuery, un CRM, una piattaforma pubblicitaria e un database prodotto che non hanno mai parlato tra loro. L'audit esiste per trovare questi gap prima che inizi il build.
Il modello mentale corretto per uno stack dati GCP è un imbuto: i dati grezzi da molte sorgenti atterrano in un unico warehouse, le trasformazioni girano dentro il warehouse e gli strumenti di reporting leggono da esso. BigQuery è il warehouse. Gestisce petabyte, esegue SQL in secondi e ha connettori nativi con ogni altro servizio GCP. Sceglierlo come livello centrale è la decisione che permette a tutto il resto di comporsi in modo pulito.
La decisione più importante nell'architettura dati è lo schema. BigQuery è economico da archiviare e veloce da interrogare, ma se lo schema è un dump diretto delle tabelle applicative diventa impossibile da interrogare per chi non lo ha costruito. Progettiamo gli schemi attorno alle domande che il business fa davvero: fatturato per canale per giorno, conversione del funnel per coorte, churn per tier prodotto. Le tabelle sono volutamente ampie e le trasformazioni sono scritte in SQL standard che il tuo team può leggere e verificare.
ELT sta per extract, load, transform. I dati arrivano grezzi in BigQuery prima, poi le trasformazioni girano dentro il warehouse usando SQL o uno strumento come dbt. È il contrario del vecchio pattern ETL in cui si trasformava prima di caricare, ed è migliore per due motivi: i dati grezzi sono sempre disponibili se hai bisogno di rielaborarli, e BigQuery è più veloce ed economico nell'eseguire trasformazioni di qualsiasi servizio esterno.
Il lavoro pratico di costruire una pipeline ELT ha quattro fasi. Prima, censire le sorgenti: quali dati esistono, dove si trovano, come si accede a essi (API, webhook, export file, replica database) e con quale latenza li servi. Seconda, progettare lo schema grezzo in modo da preservare fedelmente la struttura sorgente, compresi i campi che attualmente non usi. Terza, costruire il livello di estrazione gestendo correttamente autenticazione, paginazione e rate limiting. Quarta, scrivere le trasformazioni che producono le tabelle orientate al business.
Le pipeline che costruiamo più frequentemente collegano Salesforce o HubSpot (via API REST con carichi incrementali), Google Ads e Meta Ads (via le rispettive API), Stripe (via webhook in Pub/Sub) e il database prodotto (via replica in lettura o stream CDC). Ognuna gira in modo indipendente, quindi un guasto in una sorgente non rompe le altre, e ciascuna è monitorata con alerting sul timestamp dell'ultimo aggiornamento della tabella grezza.
GA4 è la piattaforma di analytics giusta per la maggior parte delle aziende in crescita, ma la configurazione client-side predefinita ha un problema strutturale: il codice di misurazione gira nel browser dell'utente, il che significa che ad blocker, Intelligent Tracking Prevention di iOS e i banner di consenso ai cookie erodono i tuoi dati prima che raggiungano Google. Gli studi su proprietà tipiche e-commerce e SaaS mostrano costantemente che il 20-40 percento delle sessioni non viene tracciato con una configurazione solo lato client.
Il tagging server-side risolve questo problema spostando l'endpoint di raccolta su un container che controlli tu, in esecuzione su Cloud Run. Il browser invia gli eventi al tuo dominio, non direttamente a Google. Il tuo container server-side li inoltra poi a GA4 e a qualsiasi altra destinazione (Google Ads, Meta, webhook CRM). I vantaggi sono concreti: migliore completezza dei dati, cookie first-party che sopravvivono a ITP e nessun dato personale che lascia la tua infrastruttura prima che tu abbia potuto anonimizzarlo o rimuoverlo.
La configurazione ha tre parti: un web container Google Tag Manager che spara al tuo endpoint sGTM invece che direttamente a GA4, un container GTM server-side ospitato su Cloud Run con auto-scaling configurato e i tag GA4 e pubblicitari ricostruiti lato server con la corretta mappatura delle variabili. La configurazione Cloud Run richiede un sottodominio personalizzato che punti a essa affinché i cookie impostati siano first-party; senza quello, il beneficio ITP scompare.
Colleghiamo anche l'export BigQuery di GA4. Ogni evento che GA4 registra viene trasmesso quotidianamente (o in tempo reale nel tier 360) in un dataset BigQuery. Quella tabella di eventi grezzi è la base del lavoro di analytics: puoi interrogarla con SQL, unirla al tuo database prodotto e costruire funnel personalizzati che l'interfaccia GA4 non supporta. È una delle poche integrazioni gratuite nello stack Google che ripaga immediatamente.
Looker Studio (ex Data Studio) è lo strumento giusto per la maggior parte delle esigenze di reporting. Si connette direttamente a BigQuery, si aggiorna su schedule e produce dashboard che i team non tecnici possono leggere e condividere senza toccare SQL. La chiave per una configurazione Looker Studio che venga davvero usata è collegarla a tabelle BigQuery pulite e ben denominate piuttosto che ai dati sorgente grezzi, così le metriche sono coerenti in tutti i report.
Looker (il prodotto enterprise completo, ora parte di Google Cloud) aggiunge un livello semantico: un insieme di definizioni di metriche che si pone tra i dati e gli strumenti di reporting, garantendo che “fatturato” significhi la stessa cosa che tu lo interroghi in Looker, da un notebook Python o via API REST. Per i team in cui le definizioni di metriche coerenti su più strumenti sono un problema reale, il livello semantico vale l'investimento. Per i team in una fase precedente, Looker Studio direttamente su BigQuery è più veloce da mettere in produzione e meno costoso da gestire.
Le dashboard che costruiamo seguono un pattern costante: un'unica panoramica esecutiva che copre i quattro o cinque numeri che guidano davvero le decisioni (fatturato, pipeline, attivazione, churn, efficienza della spesa) e una dashboard operativa per team (funnel marketing per canale, attivazione prodotto per coorte, salute cliente per tier). Ogni grafico ha una query SQL che puoi leggere e ogni metrica ha una definizione scritta che appare al passaggio del mouse. L'obiettivo è che chiunque guardi la dashboard possa capire cosa sta vedendo senza chiedere all'analista che l'ha costruita.
Pub/Sub è il backbone di messaggistica che rende GCP componibile. Invece di servizi che si chiamano direttamente l'un l'altro, un produttore pubblica un evento su un topic e qualsiasi numero di subscriber agisce su di esso in modo indipendente. Un nuovo cliente si registra nel tuo prodotto: un subscriber carica l'evento in BigQuery, un altro attiva una sequenza di benvenuto nel CRM, un terzo aggiorna un contatore in una dashboard Sheets. Nessuno di loro sa degli altri, e se uno fallisce, riprova senza influenzare gli altri.
Usiamo Pub/Sub per tre categorie di eventi. La prima sono i trigger per le pipeline dati: un webhook da Stripe o un evento prodotto genera un messaggio Pub/Sub che attiva la Cloud Function che lo carica in BigQuery. La seconda sono le sincronizzazioni cross-system: un deal chiuso nel CRM pubblica un evento che attiva un task di Customer Success, un aggiornamento di Looker Studio e una bozza di fattura, tutto insieme, nessuno bloccante per gli altri. La terza sono il monitoraggio e gli alert: una query pianificata BigQuery pubblica su un topic quando una metrica chiave supera una soglia e un subscriber instrada l'alert verso Slack o email.
Workspace è spesso l'ultima cosa a cui un'azienda in crescita pensa finché non diventa un problema: un account utente non disabilitato dopo che qualcuno è andato via, un Drive condiviso senza proprietario con tremila file che nessuno riesce a trovare, un alert di sicurezza scattato mesi fa che nessuno ha visto. Una buona amministrazione di Workspace non è affascinante, ma è la fondamenta su cui si poggia tutto il resto dello stack Google, perché Workspace è il provider di identità.
Il lavoro di amministrazione che svolgiamo copre cinque aree. Gestione del ciclo di vita degli utenti: provisioning di nuovi account con i gruppi e le autorizzazioni corrette dal primo giorno, e deprovisioning completo di chi lascia comprensivo di revoca dei token OAuth di terze parti. Governance dei Drive condivisi: audit di chi possiede cosa, applicazione di policy di retention e cancellazione e spostamento dei contenuti orfani in posizioni gestite. Baseline di sicurezza: applicazione dell'autenticazione a due fattori in tutta l'organizzazione, revisione dell'inventario degli account admin e configurazione del Security Investigation Tool per evidenziare attività anomale. Gestione delle licenze: allineamento dei tier di licenza all'utilizzo reale in modo da non pagare per funzionalità che nessuno usa. Configurazione di compliance: impostazione delle data region, configurazione di Vault per legal hold se necessario e revisione delle autorizzazioni delle app di terze parti.
L'audit porta alla luce tutto questo. La maggior parte delle organizzazioni con cui lavoriamo ha almeno due o tre account che avrebbero dovuto essere disabilitati ma non lo sono, almeno un account admin non iscritto all'autenticazione a due fattori e almeno una dozzina di autorizzazioni di app di terze parti che nessuno ricorda di aver approvato.
Apps Script è il livello di automazione integrato di Google per Workspace. Esegue JavaScript nell'infrastruttura di Google, ha accesso diretto a Sheets, Docs, Drive, Gmail, Calendar e Forms senza overhead di autenticazione e può chiamare API esterne. Non è un ambiente di programmazione general-purpose, ma per la categoria specifica di automatizzare i flussi Workspace è più veloce ed economico da costruire rispetto a qualsiasi strumento esterno.
Le automazioni che costruiamo più spesso con Apps Script rientrano in quattro gruppi. Elaborazione form: un Google Form raccoglie dati, lo script li valida, scrive una riga su uno Sheet, invia email di conferma, crea inviti Calendar e opzionalmente pubblica su Slack o un CRM. Generazione documenti: uno script legge dati da uno Sheet o da BigQuery, compila un template Docs e salva l'output in una cartella Drive nominata, sostituendo un processo che prima richiedeva un pomeriggio a qualcuno. Workflow di approvazione: uno script instrada una riga di Sheet attraverso una catena di approvazione via email, aggiornando lo stato a ogni azione dell'approvatore. Sincronizzazioni dati: script pianificati leggeri che inviano dati da Sheets a un'API esterna o li ricevono indietro, per sistemi in cui una pipeline completa sarebbe eccessiva.
L'identità è l'unica area in cui un errore è difficile da recuperare. Un ruolo IAM mal configurato che concede a un service account l'accesso da project-owner, un account admin Workspace senza autenticazione a due fattori o un token OAuth lasciato sull'account di un dipendente che ha lasciato l'azienda sono tutte superfici di attacco che peggiorano nel tempo. Trattiamo identità e IAM come un deliverable di prima classe, non come un afterthought.
Sul lato GCP, il principio del minimo privilegio è la regola. Ogni service account ottiene esattamente le autorizzazioni di cui ha bisogno per le risorse specifiche che tocca, scritte come ruolo IAM personalizzato, non un ruolo predefinito a livello di progetto. Le chiavi dei service account non vengono usate dove Workload Identity Federation o il metadata service possono fornire credenziali invece; le chiavi che non possono essere evitate vengono ruotate su schedule. L'accesso ai dataset BigQuery è controllato a livello di dataset e tabella, non a livello di progetto, così un developer può interrogare le tabelle pulite senza toccare i dati grezzi o i dataset di altri team.
Sul lato Workspace, le raccomandazioni di sicurezza della console di amministrazione sono un pavimento, non un soffitto. Oltre all'applicazione dell'autenticazione a due fattori e alla revisione degli account admin, configuriamo policy di accesso context-aware per qualsiasi app Workspace che gestisce dati sensibili, revisioniamo e riduciamo le autorizzazioni OAuth di app di terze parti che si accumulano silenziosamente nel corso degli anni e configuriamo il Security Investigation Tool per avvisare su attività di accesso sospette, download massivi da Drive e condivisione esterna di documenti sensibili.
Google Cloud si connette ai sistemi esterni attraverso due pattern. Il primo è il pull: una Cloud Function o una query pianificata chiama un'API esterna su schedule, recupera dati e li carica in BigQuery. Questo copre la maggior parte dei casi d'uso di reporting: il tuo CRM, le tue piattaforme pubblicitarie, il tuo sistema di fatturazione. Il secondo è il push: un sistema esterno chiama un endpoint Cloud (di solito una Cloud Function dietro una configurazione Cloud Endpoints o API Gateway, oppure una push subscription Pub/Sub) quando qualcosa cambia. Questo copre i trigger in tempo reale: un pagamento completato, un utente che si attiva, un deal chiuso.
Le integrazioni che costruiamo più frequentemente sono la sync CRM (Salesforce e HubSpot hanno entrambi API REST ben documentate con supporto ai carichi incrementali), le piattaforme pubblicitarie (Google Ads, Meta, LinkedIn hanno tutte API che restituiscono dati di campagna e conversione con un ritardo di due giorni), i processori di pagamento (il sistema webhook di Stripe è affidabile e il suo modello di eventi si mappa in modo pulito su Pub/Sub) e i database prodotto (tipicamente via replica in lettura o un connettore Fivetran o Airbyte se è già in uso). Documentiamo ogni integrazione in un formato standard: l'endpoint API, il metodo di autenticazione, i campi estratti, lo schedule e il comportamento in caso di errore.
Ogni intervento apre con l'audit gratuito, che produce una lista prioritizzata di cosa costruire e in quale ordine. Il build stesso è un progetto a perimetro fisso, strutturato in due o tre fasi a seconda della complessità dello stack.
La fase uno è sempre la fondamenta: tagging server-side GA4, BigQuery collegato all'export GA4, baseline IAM su GCP, hardening della sicurezza Workspace. Questo è il lavoro che rende tutto il resto affidabile. La fase due è il livello dati: pipeline ELT per i due o tre sistemi sorgente che contano di più, lo schema BigQuery che li unisce e le prime dashboard Looker Studio. La fase tre, dove necessario, copre l'automazione: topologia Pub/Sub per le integrazioni event-driven, automazioni Apps Script per i flussi manuali di maggior valore e amministrazione Workspace per i team con esigenze significative di gestione del ciclo di vita.
Tutto ciò che costruiamo è documentato a uno standard che permette al tuo team di possederlo dopo la consegna. Ogni pipeline ha un runbook che descrive cosa fa, come è monitorata e come riavviarla in caso di errore. Ogni dashboard ha un dizionario dati che definisce ogni metrica. Ogni automazione Apps Script ha commenti inline e uno Sheet di test che ti permette di attivarla manualmente. L'obiettivo è che sei mesi dopo la consegna il tuo team possa mantenere ed estendere il lavoro senza tornare da noi.
Un unico punto di contatto. Avrai una persona che possiede l'intervento, il piano di consegna e qualsiasi escalation. Le specifiche arrivano in un formato standard con criteri di accettazione che il tuo team può verificare. I dataset e i report iniziali sono tuoi da tenere e il codice viene distribuito nel tuo progetto GCP, non nel nostro.
Questa è l'architettura completa. Quando vuoi che venga applicata al tuo stack, il passo successivo è un audit gratuito: una vera analisi del tuo ambiente GCP e Workspace, i risultati entro una settimana, senza obblighi.
Un audit gratuito del tuo stack Google reale, i risultati quantificati e un perimetro fisso per costruire ciò che manca. Risultati entro una settimana.
Richiedi un audit Google gratuito