Un responsabile e-commerce apre la prima fattura Google Cloud dopo il passaggio al server-side e trova un importo che non somiglia a nessuna delle cifre lette in giro. Aveva confrontato tre articoli, tutti parlavano di poco più di cento euro al mese, e lui ne sta pagando una frazione. Un collega di un’altra azienda, stesso setup sulla carta, ne paga il triplo.
Nessuno dei due sta sbagliando qualcosa. Semplicemente, il costo di un container server-side non è un prezzo di listino: è il risultato di una formula con quattro o cinque variabili, e chi pubblica un intervallo secco sta descrivendo la propria configurazione, non la tua. Qui trovi il metodo per calcolarlo prima di firmare qualsiasi cosa.
Perché le cifre che trovi online non valgono per il tuo sito
Prima cosa da chiarire: il container server di Google Tag Manager è gratuito. Lo crei dentro l’interfaccia GTM come un qualsiasi contenitore web, senza pagare una licenza. Quello che paghi è la macchina che lo esegue: un’immagine Docker che gira su un server, raggiungibile da un endpoint pubblico, attiva ventiquattro ore al giorno.
La cifra che circola più spesso nei forum nasce dalla configurazione storica suggerita per App Engine: tre istanze di produzione sempre accese più una di preview. È un dimensionamento pensato per l’alta disponibilità e per volumi importanti. Per un sito italiano da qualche decina di migliaia di sessioni al mese è sovradimensionato, e il risultato è che la persona si convince che il server-side costi come un abbonamento software aziendale. Per un e-commerce che concentra metà del fatturato in tre settimane di novembre, invece, quello stesso numero è sottostimato: nel picco servono molte più istanze, e per il resto dell’anno molte meno.
Seconda distinzione che i preventivi mescolano volentieri: l’infrastruttura, il setup iniziale e la manutenzione sono tre voci separate. L’infrastruttura è ricorrente e proporzionale al traffico. Il setup è una tantum e dipende da quanti tag migri e da quanto è in ordine il tuo Data Layer. La manutenzione è il tempo che qualcuno dedica, durante l’anno, a tenere in piedi la configurazione quando un template o un’API cambia. Confrontare un preventivo che include tutte e tre con uno che include solo la prima è l’errore più frequente di chi chiede tre offerte.
La formula: dagli eventi mensili alla bolletta
Il costo infrastrutturale si calcola in quattro passaggi. Nessuno richiede competenze da sistemista.
Passo 1, stima le richieste in entrata. Moltiplica le sessioni mensili per il numero medio di eventi che invii per sessione. Un sito vetrina con page_view, scroll e un paio di click sta su numeri bassi; un e-commerce con view_item, add_to_cart, begin_checkout, purchase e gli eventi di consenso arriva facilmente a dieci o più eventi per sessione. Aggiungi le richieste di caricamento dello script se servi il file di GTM dal tuo dominio personalizzato, perché anche quelle passano dal server.
Passo 2, conta le richieste in uscita. Qui molti si fermano troppo presto. Un singolo purchase che alimenta GA4, Meta Conversions API e Google Ads genera tre chiamate in uscita, non una. Se aggiungi un arricchimento verso un’API esterna o una verifica su Firestore, salgono a quattro o cinque. Il carico di lavoro del container cresce con le destinazioni, non con gli eventi.
Passo 3, traduci le richieste in istanze. Un’istanza di taglia piccola regge senza problemi decine di richieste al secondo quando i tag sono leggeri, molto meno quando ogni evento attende risposta da più API. Il numero che conta è il picco, non la media: se mandi una newsletter alle 10 del mattino o parte una campagna TV, in cinque minuti concentri il traffico di mezza giornata.
Passo 4, moltiplica per il prezzo orario della regione. Le regioni europee costano un po’ più di quelle statunitensi. Chi ha vincoli di residenza del dato in UE sceglie comunque l’Europa, ed è una scelta che consiglio anche a chi non ha obblighi formali: la differenza di prezzo è modesta, la latenza verso gli utenti italiani migliora.
Come ordine di grandezza, e sempre come fascia indicativa: sotto il centinaio di migliaia di eventi mensili con una o due destinazioni si resta in poche decine di euro al mese su una piattaforma che scala a zero. Tra alcune centinaia di migliaia e il milione di eventi si entra nelle decine alte o nelle basse centinaia. Sopra, il conto dipende quasi interamente da quante chiamate in uscita genera ogni evento.
L’errore ricorrente è dimensionare sulla media mensile. Chi lo fa non risparmia: perde eventi proprio nel giorno in cui valgono di più, e li perde in silenzio, perché un container saturo restituisce errori che nessuno guarda.
Le voci che non compaiono quasi mai nei preventivi
Cloud Logging. Con il logging verboso attivo, ogni richiesta scrive una riga. Su volumi seri la voce di log può avvicinarsi o superare il costo delle istanze. Serve in debug, non in produzione continuativa: conserva gli errori, scarta il resto, imposta una retention corta.
Traffico in uscita. Ogni chiamata verso i vendor è dati che escono. Preso singolarmente è poca cosa; su milioni di eventi al mese diventa una riga visibile, soprattutto se il container parla con servizi in regioni diverse dalla sua.
Dominio personalizzato, certificato e load balancer. Il dominio di primo livello è quasi sempre necessario per far durare i cookie di prima parte. Il certificato in genere è incluso. Il bilanciatore, quando la piattaforma lo richiede, ha una quota fissa mensile che su volumi bassi può pesare più delle istanze stesse. È la voce che fa saltare i conti ai siti piccoli.
Server di preview. Utile mentre configuri, inutile dopo. Resta acceso per mesi nella metà dei progetti che ho visto, e paga come una macchina di produzione.
Servizi di contorno. Export su BigQuery, Firestore per la deduplica o il caching, qualche Cloud Function di supporto: singolarmente centesimi, insieme una voce da tenere d’occhio.
Le ore di presidio. Non compaiono in nessuna fattura cloud e sono la voce più cara. Un template che cambia, un’API che aggiorna la versione, un consenso che non passa più come prima: qualcuno deve accorgersene e rimettere a posto.
Quattro modi di ospitarlo, quattro profili di spesa
Cloud Run. Scala a zero, paghi a consumo. È l’opzione più economica per traffico irregolare e per chi parte da volumi bassi, a patto di accettare qualche cold start e di configurare bene i limiti. Ho messo a confronto questa strada con l’alternativa gestita nell’analisi su Cloud Run e hosting gestito a confronto.
App Engine. La configurazione storicamente documentata. Costo più prevedibile, ma con una base fissa che paghi anche a traffico nullo. Ha senso quando il traffico è alto e costante.
Hosting gestito di terze parti. Canone a fascia di eventi, nessuna console cloud da presidiare, aggiornamenti dell’immagine inclusi. Il costo per evento tende a crescere ai volumi molto alti, ma per chi non ha un sistemista interno il conto va fatto includendo le ore risparmiate. Le logiche di questo modello le spiego nella pagina sull’hosting del container server-side.
VPS o Kubernetes autogestiti. Listino più basso di tutti, competenze richieste molto più alte. Aggiornamento dell’immagine, monitoraggio, certificati, backup: se nessuno in azienda sa fare queste cose, il prezzo basso è apparente.
I criteri di scelta onesti sono quattro: volume di eventi, tolleranza al downtime, chi ti risponde alle 23 del Black Friday quando gli acquisti non arrivano più in Ads, e vincoli di residenza del dato.
Quattro scenari con i conti in chiaro
Blog o sito vetrina, circa 20.000 visite al mese. Infrastruttura nell’ordine di poche decine di euro al mese, setup contenuto, manutenzione quasi nulla. La mia opinione netta: qui il server-side raramente si ripaga. Senza spesa pubblicitaria da ottimizzare, il beneficio è quasi solo di qualità del dato. Meglio investire quelle ore nel tracciamento lato client fatto bene, come argomento nell’articolo su quando conviene davvero passare al server-side.
E-commerce piccolo, 50.000 sessioni al mese, tre destinazioni attive. Il moltiplicatore delle destinazioni triplica le richieste in uscita. Infrastruttura nell’ordine di qualche decina di euro mensili su una soluzione che scala a zero, più dominio e logging contenuto. È la fascia in cui il server-side inizia ad avere senso economico, perché c’è un budget pubblicitario da proteggere.
E-commerce medio-grande con stagionalità. Qui si dimensiona due volte: un minimo di istanze per i mesi tranquilli e una soglia di scalata per il mese di campagna. Il mese di picco può costare un multiplo del mese normale, ed è denaro ben speso. Il punto di attenzione è ricordarsi di abbassare il minimo dopo le feste.
Agenzia o consulente con più clienti. Container condiviso o container separati è la vera domanda. Condividere abbatte il costo per cliente ma complica l’isolamento dei dati, l’attribuzione dei consumi e la gestione del consenso. Separare costa di più in assoluto, ma rende ogni cliente fatturabile e sostituibile senza toccare gli altri. Per chi gestisce portafogli di clienti ho raccolto le considerazioni operative nella pagina dedicata alle web agency e ai consulenti.
Come leggere un preventivo e calcolare il punto di pareggio
Un preventivo di implementazione serio contiene sempre: piano di misurazione degli eventi, migrazione tag con elenco nominativo, gestione del consenso, test di parità dati fra client-side e server-side, documentazione consegnata. Se mancano il test di parità e la documentazione, stai comprando una configurazione che nessun altro potrà mantenere. Se il preventivo è altissimo ma non include il piano di misurazione, stai pagando ore, non risultati.
Quanto puoi fare da solo: un analyst che padroneggia GTM arriva tranquillamente a creare il container, collegare i tag GA4 e verificarne gli eventi. Dove serve un tecnico: configurazione DNS e dominio di primo livello, policy sul consenso, debugging degli endpoint che restituiscono errori silenziosi. Chi vuole la via di mezzo può partire da un percorso di affiancamento sul Tag Manager server-side invece di delegare tutto.
Il punto di pareggio si calcola così: prendi il budget pubblicitario mensile, stima la quota di conversioni che oggi non viene attribuita, applica quella quota al budget e confronta il valore recuperato con il costo totale dell’infrastruttura più la quota mensile del setup. La misura va fatta sul tuo prima/dopo, su una finestra omogenea, non su percentuali lette in rete. Sotto un budget pubblicitario modesto il ritorno resta dubbio e conviene prima sistemare il lato client; sopra, il recupero di anche una piccola parte delle conversioni perse copre l’infrastruttura con ampio margine, come mostro nell’analisi su come il server-side incide sul costo delle campagne.
Restano fuori dal foglio di calcolo tre benefici reali: il controllo su cosa esce verso i vendor, lo script più leggero nel browser, la durata dei cookie di prima parte. Dopo l’avvio, imposta un budget alert sul progetto cloud, guarda il costo per evento una volta al mese e rivedi il dimensionamento ogni trimestre. Chi preferisce un canone a fascia senza sorprese può confrontare la propria stima con le fasce di prezzo del servizio gestito e decidere con i numeri in mano.
Domande frequenti
Il container server-side di Google Tag Manager si paga a parte?
No. Creare un container server dentro Google Tag Manager è gratuito, esattamente come un container web. Quello che si paga è l’infrastruttura che esegue l’immagine del container: un servizio cloud, un hosting gestito o un server proprio. A questo si aggiungono dominio personalizzato ed eventuali servizi di contorno come logging ed export dei dati.
Qual è il costo minimo realistico al mese per partire?
Su una piattaforma che scala a zero e con volumi bassi, l’infrastruttura può restare nell’ordine di poche decine di euro al mese. Attenzione però alle voci fisse: se la configurazione richiede un bilanciatore sempre attivo, quella quota pesa più delle istanze stesse quando il traffico è ridotto. Il minimo va sempre calcolato sul picco orario, non sulla media.
Posso usare un solo container server per più siti o più clienti?
Tecnicamente sì, e il costo per cliente scende. Però condividere complica l’isolamento dei dati, l’attribuzione dei consumi in fattura e la gestione separata del consenso. Per un’agenzia che fattura il tracciamento come servizio, container separati per cliente restano la scelta più pulita: ogni ambiente è indipendente e può essere ceduto o chiuso senza toccare gli altri.
Perché la fattura cloud è più alta della stima iniziale?
Nella quasi totalità dei casi le cause sono tre: il logging verboso lasciato attivo dopo il debug, il server di preview dimenticato acceso per mesi e il numero di destinazioni sottostimato, perché ogni evento che alimenta tre piattaforme genera tre chiamate in uscita. Vale la pena controllare queste tre voci prima di pensare a un ridimensionamento.