Server-Side Tagging su Cloud Run: Analisi Costi 2026

·3 min lettura
Server-Side Tagging su Cloud Run: Analisi Costi 2026
In questo articolo

L'adozione del Google Tag Manager Server-Side (sGTM) è stata frenata per anni dalla paura dei costi. Molti CFO vedono "Google Cloud Platform" e pensano a fatture a tre zeri. La realtà del 2026 è diversa: con le giuste configurazioni e il free tier mensile generoso, un container sGTM per un sito medio-grande (500k sessioni/mese) può costare meno di un abbonamento a un tool SaaS entry-level.

Il segreto sta nell'usare Cloud Run (ambiente serverless) in modo intelligente, evitando le configurazioni di default "sprecone". Ecco la guida operativa all'ottimizzazione dei costi al 2026.

Capire la Fattura: Cosa paghi davvero?

Cloud Run ha un modello di pricing granulare al millisecondo. Le tre voci che pesano davvero:

  1. CPU & Memory allocation: paghi le risorse mentre l'istanza è attiva (circa $0.000024 per vCPU-secondo e $0.0000025 per GiB-secondo nel listino US 2026).
  2. Request count: paghi per milione di richieste (costo trascurabile).
  3. Networking egress: paghi per i dati che escono da Google Cloud verso Internet (la voce più insidiosa per ecommerce ad alto traffico).

Il Free Tier che molti dimenticano

Google offre ogni mese (per progetto):

  • 180.000 vCPU-secondi gratuiti
  • 360.000 GiB-secondi di memoria gratuiti
  • 2 milioni di richieste gratuite

Per un sito sotto le 100k sessioni/mese, il container sGTM resta facilmente dentro il free tier e la fattura è di pochi euro (solo egress). Su volumi maggiori il free tier non basta, ma resta un sussidio mensile non trascurabile.

Le 4 Regole d'Oro del Cost Saving

1. Scaling a Zero (con Attenzione)

Per anni si è consigliato di tenere sempre almeno 1 istanza attiva (min_instances=1) per evitare "cold starts" da 2-5 secondi al primo caricamento. La funzionalità CPU Boost di Cloud Run riduce questo problema: alloca CPU aggiuntiva durante lo startup dell'istanza più per i 10 secondi successivi, accorciando l'avvio da secondi a centinaia di millisecondi nei casi tipici.

Per siti con traffico notturno nullo (es. B2B italiani), impostare min_instances=0 con CPU Boost abilitato significa non pagare nulla dalle 22:00 alle 07:00, mantenendo cold start tollerabili.

Per ecommerce con traffico H24, ha più senso min_instances=1 per garantire latenza costante anche al primo hit del mattino.

2. Tuning della Concorrenza (Concurrency)

Questa è la leva più potente.

  • Default: Cloud Run gestisce 80 richieste contemporanee per istanza.
  • Ottimizzato per sGTM: sGTM è un'applicazione I/O bound (aspetta risposte di rete, usa poca CPU). Puoi alzare la concorrenza a 200 o 300.
  • Risultato: invece di accendere 5 istanze per gestire un picco di traffico, ne bastano 2.

3. Region pricing

Le regioni europe-west8 (Milano) e europe-west1 (Belgio) sono le più sensate per traffico italiano dal punto di vista latenza. europe-west1 costa marginalmente meno per vCPU-secondo. La differenza è nell'ordine del 5-8%, non così rilevante salvo volumi enterprise.

4. Log Management: Il "Vampiro" Nascosto

Spesso il 30-40% della fattura sGTM non è il server, ma Cloud Logging. Ogni richiesta HTTP loggata (header, body, response) consuma GB di spazio log.

Best practice:

  • In produzione, imposta la variabile d'ambiente LOGGING_LEVEL su ERROR o WARNING.
  • Usa log INFO o DEBUG solo nell'ambiente di staging o durante un debug attivo, e non oltre le 24 ore.
  • Configura una "Exclusion Rule" su Cloud Logging per scartare i log di successo (HTTP 200) se non strettamente necessari per audit.

Su un container di un cliente reale, queste tre regole hanno fatto scendere la fattura mensile da €120 a €35, a parità di traffico.

Stima dei Costi Reali (Scenari Italia 2026)

Tre scenari concreti, con configurazione 1 vCPU, 512MB RAM, regione europe-west1, CPU Boost attivo, concurrency 200:

Scenario A: Sito B2B (50k sessioni/mese)

  • Hit totali: ~1.5M (pageview + eventi)
  • Calcolo (vCPU/RAM): coperto dal free tier
  • Egress: ~€3
  • Logging: ~€2
  • Totale stimato: €5-10/mese

Scenario B: Ecommerce medio (500k sessioni/mese)

  • Hit totali: ~15M
  • Calcolo (vCPU/RAM): ~€30
  • Egress: ~€12
  • Logging: ~€5
  • Totale stimato: €45-55/mese

Scenario C: Ecommerce grande (2M sessioni/mese)

  • Hit totali: ~60M
  • Calcolo (vCPU/RAM): ~€85
  • Egress: ~€40
  • Logging: ~€10
  • Totale stimato: €130-150/mese

In tutti e tre i casi, il ROI è positivo nei primi 60 giorni: il recupero conversioni perse via ad-blocker (vedi Enhanced Conversions) e la riduzione di rischio compliance pagano la fattura più volte.

Limiti

Cloud Run non è la scelta giusta per tutti. Se hai traffico costante 24/7 sopra le 10M sessioni/mese, dovresti valutare Cloud Run Always-On CPU o passare direttamente a istanze Compute Engine dedicate, dove il pricing diventa più prevedibile e l'egress può essere ridotto via Cloud CDN.

E il pricing di Cloud Run cambia. Le stime di questa pagina sono allineate al listino di metà 2026: verifica sempre col calculator ufficiale di Google Cloud prima di committarti su un budget annuale.

Prossimi passi

Se stai valutando server-side tagging per il tuo stack, il punto di partenza è capire dove ti stanno andando le conversioni adesso. Un audit tracking GA4 misura quante conversioni perdi, prima di stimare quanto recuperi col server-side. Da lì, il piano di adozione viene tarato sul ROI atteso.

Per chi è già sul setup, le due aree dove server-side fa la differenza vera sono le Enhanced Conversions (recupero conversioni via dati first-party hashati) e il Tracking Ecommerce (revenue allineata al gestionale, attribuzione corretta). Sul lato GTM, la guida operativa al servizio è in GTM Server-Side.

Correlati