Come filtrare bot e spam nel container server

da | Nov 5, 2026 | Configurazioni pratiche e troubleshooting

Come filtrare bot e spam nel container server

Come filtrare bot e spam nel container server significa intercettare le richieste automatizzate prima che diventino eventi fatturati e hit inviate a GA4, Google Ads o Meta, agendo su quattro livelli: edge, client del container, tag, destinazione.

Nel resto dell’articolo trovi come misurare quanto traffico non umano arriva davvero al tuo endpoint prima di toccare qualsiasi configurazione, le regole concrete livello per livello, il compromesso tra risparmio e falsi positivi, e cosa puoi raccogliere per riconoscere i bot senza finire fuori dal GDPR.

Perché i bot nel container server costano più che nel GTM web

Nel GTM lato browser un bot che non esegue JavaScript semplicemente non traccia nulla: nessun tag scatta, nessun costo. Nel Google Tag Manager server-side (sGTM) il meccanismo si ribalta. Ogni richiesta HTTP che raggiunge l’endpoint del container viene ricevuta, valutata dai client e consuma risorse, anche quando nessun tag arriva a scattare.

Il danno è doppio. Il primo è infrastrutturale: su Cloud Run le richieste tengono sveglie le istanze e spostano la fattura verso l’alto, sui servizi di hosting gestito gli eventi erodono la quota del piano. Se vuoi capire come si compone questa spesa, l’ho scomposta in quanto costa davvero un container server side.

Il secondo è sulla qualità del dato. Sessioni fantasma, conversioni duplicate, segnali sbagliati inviati a Google Ads tramite le conversioni avanzate (Enhanced Conversions) e a Meta tramite la Conversions API (CAPI). Le piattaforme pubblicitarie ottimizzano su quello che gli mandi: se nel flusso entrano eventi generati da script automatici, il matching peggiora e l’algoritmo impara su pubblico inesistente.

GA4 ha già un’esclusione automatica dei bot noti basata sulla lista IAB/MRC, non disattivabile. Ottima cosa, ma agisce a valle: quando quel filtro interviene, il tuo container ha già ricevuto, processato e fatturato la richiesta.

Come capisco quanto traffico bot sta entrando nel mio container server?

Prima regola: non si filtra niente prima di aver misurato. Servono 7-14 giorni di baseline, altrimenti non potrai dimostrare a te stesso (o al cliente) che il filtro ha funzionato.

Leggi i log del container. Su Cloud Run apri Logs Explorer e filtra per il path dell’endpoint di raccolta, raggruppando per User-Agent e IP:

resource.type="cloud_run_revision"
resource.labels.service_name="gtm-server"
httpRequest.requestUrl=~"/g/collect"

Sui servizi di hosting gestito la stessa informazione sta nella sezione log o monitoring del pannello. Se non c’è, è una domanda da fare prima di firmare.

Confronta i volumi. Numero di richieste all’endpoint contro eventi registrati in GA4 nello stesso intervallo. Uno scarto ampio e stabile nel tempo è il primo indicatore di traffico non umano o di spam diretto.

Scendi nel dettaglio con BigQuery. Se hai già l’export attivo (altrimenti parti da come inviare eventi GTM server side a BigQuery), cerca gli utenti con molte visualizzazioni e zero interazioni:

SELECT
  user_pseudo_id,
  COUNT(*) AS eventi,
  COUNTIF(event_name = 'page_view') AS page_view,
  COUNTIF(event_name IN ('scroll','click','add_to_cart','purchase')) AS interazioni
FROM `progetto.analytics_XXXXXXXXX.events_*`
WHERE _TABLE_SUFFIX BETWEEN '20250101' AND '20250114'
GROUP BY user_pseudo_id
HAVING page_view > 100 AND interazioni = 0
ORDER BY eventi DESC

I segnali tipici da cercare nei log: User-Agent assente o con stringhe headless, Accept-Language mancante, nessun header sec-ch-ua, referrer impossibili, intervalli tra eventi perfettamente regolari, geografie incompatibili con il mercato del sito.

Caso a parte è lo spam Measurement Protocol: qualcuno legge il tuo Measurement ID nel sorgente della pagina e invia richieste direttamente all’endpoint pubblico. Lo riconosci perché manca il cookie first-party (FPID o client_id coerente), mancano gli header del browser e spesso il page_location è un dominio che non ti appartiene.

I 4 livelli dove puoi filtrare: quale scegliere e cosa costa

La regola operativa è semplice: più in alto filtri, meno paghi e meno sporchi i report, ma più alto è il rischio di tagliare utenti veri.

Livello Cosa blocca Impatto sul costo Rischio falsi positivi Reversibilità
1. Edge / WAF La richiesta prima del container Massimo risparmio Alto Immediata
2. Client del container La rivendicazione della richiesta Parziale Medio Alta
3. Trigger di eccezione sui tag L’invio a GA4/Ads/Meta Nullo Basso Alta
4. Destinazione (GA4, BigQuery) Solo la reportistica Nullo Molto basso Totale

Il livello 1 è l’unico che riduce davvero la bolletta, perché la richiesta non arriva mai a Cloud Run o al container gestito. Il livello 2 interviene quando il client GA4 decide se rivendicare la richiesta: il costo è già stato sostenuto, ma hai pieno accesso a header e parametri. Il livello 3 lascia esistere l’evento nel container e gli impedisce di uscire verso le destinazioni: protegge i dati e gli algoritmi pubblicitari, non il portafoglio. Il livello 4 (filtri sul traffico interno, esclusioni in BigQuery o Looker Studio) pulisce i report ma non tocca nulla di quello che hai già inviato a Google Ads o a Meta.

Opinione netta: chi parte dal livello 1 il primo giorno fa un errore. L’edge non conosce il contesto di tracciamento, vede solo IP e header, e un blocco sbagliato ti fa perdere conversioni vere senza che tu te ne accorga per settimane. Si parte dal livello 3, si misura, e solo i pattern confermati salgono al livello 1.

Configurazione pratica: filtrare i bot dentro il container server

Nel container server crea una variabile di tipo Request Header per leggere user-agent. Poi una variabile personalizzata che restituisce vero o falso:

const getRequestHeader = require('getRequestHeader');

const ua = getRequestHeader('user-agent');
if (!ua) return true; // nessun User-Agent: quasi mai un umano

const lower = ua.toLowerCase();
const patterns = ['bot','crawler','spider','headlesschrome',
  'python-requests','curl/','wget','go-http-client','scrapy','axios'];

for (let i = 0; i < patterns.length; i++) {
  if (lower.indexOf(patterns[i]) !== -1) return true;
}
return false;

Crea un trigger di eccezione chiamato "Bot rilevato" che si attiva quando quella variabile è true, e applicalo ai tag GA4, Google Ads Conversion Tracking e Meta Conversions API. Un solo punto di controllo per tutte le destinazioni: quando aggiorni la lista di pattern, la aggiorni ovunque.

Prima di bloccare, però, misura. Usa una trasformazione del container per aggiungere a tutti gli eventi un parametro diagnostico, per esempio traffic_type = bot_suspect, e lascia passare tutto per una settimana. In GA4 o in BigQuery vedrai esattamente quanto volume stai per tagliare e, soprattutto, se dentro quel volume ci sono acquisti.

Contro lo spam Measurement Protocol servono controlli applicativi:

  • verifica la presenza del cookie first-party (FPID) e scarta le richieste che ne sono prive quando l’evento dichiara una page_view precedente;
  • fai inviare dal sito un parametro condiviso, non documentato nel sorgente visibile, e validalo nel client o in una variabile;
  • controlla che page_location appartenga ai tuoi domini;
  • usa un path di raccolta personalizzato al posto di quello predefinito.

Un chiarimento onesto: un dominio di tracciamento personalizzato riduce il blocco da parte degli ad-blocker, ma non rende il container invisibile agli script automatici. Nessuna configurazione elimina il 100% del traffico non umano.

Filtrare a monte: WAF, rate limiting e provider gestiti

Quando hai pattern certi, portali all’edge. Con un WAF davanti al dominio di tracciamento puoi bloccare per User-Agent, per ASN e applicare rate limiting sull’endpoint di raccolta. Con Google Cloud Armor davanti a Cloud Run ottieni lo stesso risultato, con il vantaggio di vedere subito l’effetto sul numero di istanze attive e quindi sulla fattura.

Il rate limiting va calcolato, non copiato. Parti dal comportamento reale di un utente del tuo sito: quanti eventi genera in media una sessione d’acquisto sul tuo e-commerce, picchi inclusi. Una soglia generica tipo "10 richieste al minuto per IP" taglia gli utenti su rete aziendale e le navigazioni rapide da mobile.

Se usi un servizio di hosting gestito per il container, fai due domande precise prima di sottoscrivere: esistono funzioni di filtro anti-spam incluse, e gli eventi filtrati rientrano comunque nella quota del piano? La seconda risposta cambia completamente il calcolo di convenienza rispetto a un’installazione su Cloud Run gestita in autonomia.

Attenzione a cosa non devi bloccare: Googlebot e i crawler di verifica, i servizi di uptime monitoring, Lighthouse e PageSpeed, la modalità anteprima di GTM, i tuoi test automatizzati. Mettili in una allowlist esplicita prima di attivare qualunque regola.

Falsi positivi: come evitare di buttare via conversioni vere

Il dato che non raccogli non si recupera. Una regola troppo aggressiva colpisce utenti su IP condivisi, browser poco diffusi, proxy aziendali, e lo scopri solo quando le conversioni calano.

Procedura in tre fasi, sempre nello stesso ordine: osserva con il parametro diagnostico, confronta gli eventi marcati come sospetti con gli ordini reali nel backend (WooCommerce, Shopify, PrestaShop), solo dopo blocca. Se tra gli "eventi bot" trovi anche un solo ordine reale, la regola va riscritta.

Tieni una riconciliazione periodica: ordini a backend contro purchase in GA4 contro conversioni in Google Ads, prima e dopo l’attivazione dei filtri. Se dopo il filtro i numeri divergono in modo nuovo, il problema è il filtro. Il tema delle discrepanze lo approfondisco in perché le conversioni di Google Ads non corrispondono a GA4.

Ultimo controllo, spesso dimenticato: se usi la deduplicazione tra pixel browser e Conversions API, verifica che il filtro lato server non stia scartando la metà server di una coppia event_id. Il risultato sarebbe un sotto-conteggio sistematico proprio sugli eventi che ti interessano di più.

Bot, spam e GDPR: cosa puoi raccogliere per filtrare

Il tracciamento lato server non aggira il consenso, e il filtro anti-bot non è un’eccezione. Riconoscere il traffico automatizzato è un’operazione tecnica di sicurezza e integrità del servizio, ma l’indirizzo IP resta un dato personale: limita la conservazione nei log al minimo necessario e documenta la logica di filtro nel registro dei trattamenti.

Evita il fingerprinting avanzato come scorciatoia anti-bot. Raccogliere decine di segnali di device per distinguere un umano da uno script ti espone su un terreno molto più delicato di quello che stai cercando di difendere.

Tieni separate le due logiche nel container: un evento senza consenso non deve diventare un evento "pulito" perché ha superato il controllo anti-bot. Sono decisioni diverse, con basi giuridiche diverse. Su come impostarle correttamente trovi i dettagli nella guida a Consent Mode v2 lato server.

In autonomia puoi gestire variabili su User-Agent, trigger di eccezione, parametri diagnostici e filtri in GA4. Per Cloud Armor, client personalizzati e validazione con token condivisi conviene farsi affiancare: lì un errore si paga in conversioni perse, non in tempo. Se preferisci un confronto diretto su come impostarli, scrivici.

Checklist operativa in 8 punti

  1. Misura la baseline di richieste all’endpoint e di eventi per 7-14 giorni.
  2. Identifica i pattern ricorrenti nei log: User-Agent, IP, path, frequenza.
  3. Attiva un parametro diagnostico nel container invece di bloccare subito.
  4. Sposta all’edge solo i blocchi confermati, per abbattere il costo.
  5. Applica un unico trigger di eccezione ai tag GA4, Google Ads e Meta CAPI.
  6. Proteggi l’endpoint dallo spam Measurement Protocol con validazioni applicative.
  7. Riconcilia le conversioni con il backend dell’e-commerce dopo ogni modifica.
  8. Rivedi le regole ogni trimestre: i pattern dei bot cambiano, le tue liste no.

Domande frequenti

Il filtro bot integrato di GA4 è sufficiente o serve filtrare anche nel container server?

Non è sufficiente se usi il server-side. L’esclusione automatica di GA4 si basa sulla lista IAB/MRC dei bot noti e agisce a valle: la richiesta è già arrivata al container, è già stata processata e, su Cloud Run o su un piano a consumo, è già stata conteggiata. Inoltre quel filtro protegge solo i report GA4, non gli eventi che il container inoltra a Google Ads o alla Conversions API di Meta. Per quelli serve un trigger di eccezione nel container.

Bloccare i bot nel container server fa risparmiare davvero sui costi?

Dipende da dove blocchi. Solo i filtri a livello edge (WAF o Cloud Armor davanti al container) impediscono alla richiesta di raggiungere l’infrastruttura, riducendo istanze attive e richieste conteggiate. I trigger di eccezione sui tag e i filtri in GA4 non tolgono un centesimo dal costo del container: migliorano la qualità del dato. Per quantificare il risparmio, confronta il numero di richieste all’endpoint prima e dopo, non il numero di eventi in GA4.

Come riconosco lo spam inviato direttamente all'endpoint con il Measurement Protocol?

Cerca richieste prive di cookie first-party coerente, senza header tipici del browser come Accept-Language o sec-ch-ua, con page_location su domini che non ti appartengono, spesso concentrate su pochi IP e con intervalli regolari. Nei log del container appaiono come chiamate dirette al path di raccolta senza alcuna richiesta precedente allo script. Le contromisure sono applicative: validazione del cookie, parametro condiviso inviato dal sito, controllo del dominio e path di raccolta personalizzato.

Filtrare il traffico bot tramite indirizzo IP è compatibile con il GDPR?

Sì, se trattato come misura tecnica di sicurezza e integrità del servizio, con alcune cautele. L’IP resta un dato personale: vanno limitati i tempi di conservazione nei log al minimo necessario, documentata la logica di filtro nel registro dei trattamenti e indicato il trattamento in informativa. Da evitare invece il fingerprinting avanzato usato come scorciatoia anti-bot, che apre questioni ben più delicate del problema che risolve.