Server Side Tracking: come ottimizzare Google Ads e Meta Ads con le Conversions API, senza provider esterni

Se fai campagne su Google Ads o Meta Ads, c’è una buona probabilità che una parte delle tue conversioni non arrivi mai alle piattaforme. Adblock, Safari che cancella i cookie dopo pochi giorni, browser in-app di Facebook e Instagram, utenti che chiudono la pagina un attimo prima che il pixel parta: ogni conversione persa è un segnale in meno per gli algoritmi di offerta, che quindi imparano peggio e spendono il tuo budget con meno precisione.

Il server side tracking nasce per risolvere proprio questo problema. In questo articolo ti spiego cos’è, perché oggi è diventato quasi indispensabile e soprattutto come l’ho implementato su un portale di comparazione offerte che gestisco: senza provider esterni, senza container intermedi e senza plugin, con il backend in Java che parla direttamente con le API di Google, Meta e TikTok.

Non è una guida teorica: dentro trovi l’architettura, gli snippet di codice, come verificare che tutto funzioni e anche gli errori che ho fatto io lungo la strada, che probabilmente sono la parte più utile di tutto l’articolo.

Cos’è il server side tracking

Nel tracciamento tradizionale, detto client side, è il browser dell’utente a inviare i dati: quando qualcuno compila un form o completa un acquisto, uno script (il pixel di Meta, il tag di Google Ads, quello di TikTok) parte dalla pagina e comunica l’evento alla piattaforma pubblicitaria.

Nel tracciamento server side è invece il tuo server a comunicare la conversione, con una chiamata diretta alle API della piattaforma. Il browser non è più l’unico anello della catena: l’evento parte da un sistema che controlli tu, nel momento in cui sai con certezza che la conversione è avvenuta.

Le piattaforme principali mettono a disposizione API dedicate:

• Meta: la Conversions API (spesso abbreviata in CAPI), esposta tramite la Graph API
• Google Ads: la Data Manager API, il nuovo punto di ingresso unificato per inviare eventi e conversioni
• TikTok: la Events API

Nel linguaggio comune si usa “CAPI” un po’ per tutte, ed è con questa nomenclatura che lo userò anche io in questo articolo.

Perché il pixel da solo non basta più

Il tracciamento lato browser ha funzionato bene per anni, ma oggi deve fare i conti con una serie di ostacoli che non dipendono da te:

• Adblock e protezioni anti tracking: bloccano gli script dei pixel prima ancora che vengano caricati.
• Safari e ITP: limitano la durata dei cookie impostati via JavaScript, quindi una conversione che arriva dopo qualche giorno rischia di non essere più collegata al click.
• Browser in-app: buona parte del traffico da Facebook e Instagram si apre nel browser interno dell’app, dove cookie come _fbp spesso non vengono nemmeno creati.
• Redirect e chiusure rapide: se l’utente lascia la pagina subito dopo il click, il pixel potrebbe non fare in tempo a partire.
• Conversioni che avvengono altrove: in un modello di affiliazione, una vendita avviene sul sito del merchant e ti viene notificata giorni dopo con un postback. Nessun pixel sulle tue pagine potrà mai vederla.

Per darti un’idea concreta: sul portale che gestisco, in una giornata campione il pixel di Meta ha registrato 14 click in uscita, mentre via server ne sono arrivati 18. Quasi un evento su quattro, lato browser, si perdeva. E ogni evento perso è un’informazione in meno con cui Meta decide a chi mostrare i tuoi annunci.

Le strade possibili: provider, GTM server side o integrazione diretta

Quando si decide di passare al server side ci sono, in pratica, tre diverse strade.

1. Provider esterni e container gestiti

Servizi come Stape ospitano per te un container di Google Tag Manager lato server. Il browser invia i dati al container, che li inoltra alle piattaforme. È la via più rapida per partire, ma ha due limiti: paghi in base al numero di richieste e aggiungi un intermediario tra il tuo sito e le piattaforme.

Io sono partito proprio da questa architettura, poi, con la crescita del traffico, il container ha superato il limite mensile del piano (oltre 500.000 richieste) e mi sono trovato davanti a una scelta: fare l’upgrade o spegnere tutto.

Alla fine ho deciso di spegnerlo, perché nel frattempo la mia integrazione diretta faceva già lo stesso lavoro anzi lo faceva meglio.

2. GTM server side in self hosting

Una seconda opzione prevede che sia tu ad ospitare il container server di Google Tag Manager su un tuo cloud, elimini il provider, ma resti con un’infrastruttura in più da mantenere e con una logica di tracciamento che vive dentro GTM, lontana dai dati veri del tuo business.

Ma soprattutto richiede la gestione e manutenzione di un VPS (Server Virtuale Privato)

3. Integrazione diretta dal backend

Questa è la strada che ho scelto: è l’applicazione stessa a inviare le conversioni alle API delle piattaforme. I vantaggi, per come la vedo io:

• Nessun costo per richiesta e nessuna dipendenza da terzi.
• Dati affidabili: la conversione parte dal sistema che sa davvero che è avvenuta (il database, il gestionale, il postback del partner).
• Conversioni ritardate e offline: puoi inviare una conversione anche giorni dopo il click, cosa impossibile per un pixel.
• Controllo totale su quali dati escono, quando e verso chi. Un punto che conta molto anche per il GDPR.

Il rovescio della medaglia è che serve sviluppo software: devi saper mettere le mani sul backend. Se il tuo sito è un CMS standard senza una parte applicativa, questa strada richiede un intervento più strutturato.

Ne parlo anche nell’articolo su cosa fa un Solution Architect: scelte come questa vanno pensate a livello di architettura, non aggiunte a pezzi.

Come funziona l’architettura

Il principio è semplice e si riassume in tre momenti.

1. All’ingresso: quando un utente arriva da un annuncio, l’URL contiene un identificativo del click (gclid per Google, fbclid per Meta, ttclid per TikTok). Il backend lo legge e lo salva in sessione, insieme a IP, user agent e cookie _fbp quando presente.
2. Durante la navigazione: ogni azione rilevante (un click verso un’offerta, un form inviato) viene registrata in un log applicativo che si porta dietro quegli identificativi.
3. Alla conversione: quando la conversione si verifica, anche giorni dopo tramite un postback del partner, il backend ritrova il log del click originale e invia l’evento alla piattaforma giusta.

Un dettaglio importante: registro anche da quale piattaforma arriva il traffico (Google, Meta, TikTok) e invio ogni conversione solo alla piattaforma che l’ha generata. Mandare tutto a tutti significa sporcare i dati di ottimizzazione.

Come implementarlo: gli snippet in Java

Gli esempi che seguono sono in Java con Spring Boot, lo stack su cui lavoro, ma la logica è identica in qualunque linguaggio. Sono volutamente semplificati: in produzione aggiungerai gestione degli errori, configurazione esterna dei token e log.

Catturare gli identificativi del click

Il primo passo è leggere i parametri all’arrivo dell’utente e conservarli. Per Meta conviene costruire subito il valore fbc, che ha un formato preciso.

String gclid  = request.getParameter("gclid");
String fbclid = request.getParameter("fbclid");
String ttclid = request.getParameter("ttclid");

if (fbclid != null && !fbclid.isBlank()) {
    // formato fbc: fb.1.<timestamp in millisecondi>.<fbclid integro>
    tracking.setFbc("fb.1." + System.currentTimeMillis() + "." + fbclid);
    tracking.setPlatform("facebook_ads");
} else if (gclid != null && !gclid.isBlank()) {
    tracking.setGclid(gclid);
    tracking.setPlatform("google_ads");
} else if (ttclid != null && !ttclid.isBlank()) {
    tracking.setTtclid(ttclid);
    tracking.setPlatform("tiktok_ads");
}

tracking.setFbp(readCookie(request, "_fbp"));   // può essere null nei browser in-app
tracking.setClientIp(resolveClientIp(request)); // attenzione a proxy e CDN
tracking.setUserAgent(request.getHeader("User-Agent"));

Nota su resolveClientIp: se il tuo sito è dietro un bilanciatore o una CDN, request.getRemoteAddr() restituisce l’IP del proxy, non quello dell’utente. Devi leggere l’header corretto (per esempio X-Forwarded-For o quello specifico della tua CDN), altrimenti invii a Meta lo stesso IP per tutti.

Meta Conversions API

Per Meta ti servono l’ID del pixel e un token di accesso, che generi da Events Manager nelle impostazioni del pixel.

La chiamata è una POST verso la Graph API.

// POST https://graph.facebook.com/{versione-api}/{pixel-id}/events?access_token={token}
Map<String, Object> userData = new HashMap<>();
userData.put("client_ip_address", click.getClientIp());
userData.put("client_user_agent", click.getUserAgent());
userData.put("fbc", click.getFbc());                      // non va hashato
if (click.getFbp() != null) userData.put("fbp", click.getFbp());
userData.put("external_id", List.of(sha256(click.getSessionId())));

Map<String, Object> event = new HashMap<>();
event.put("event_name", "Purchase");
event.put("event_time", click.getConversionEpochSeconds());
event.put("event_id", conversion.getTransactionId());     // chiave di deduplicazione
event.put("action_source", "website");
event.put("event_source_url", click.getLandingUrl());
event.put("user_data", userData);
event.put("custom_data", Map.of("currency", "EUR", "value", conversion.getValue()));

Map<String, Object> body = Map.of("data", List.of(event));

Potrai vedere gli eventi server direttamente nella sezione Events Manager di Facebook ADS

Tre regole da non dimenticare:

• Deduplicazione: se invii lo stesso evento sia dal pixel sia dal server, Meta lo conta una volta sola solo se event_name e event_id coincidono. L’ID deve essere generato una volta e condiviso tra browser e server, non creato due volte in modo casuale.
• Dati personali hashati: email, telefono, nome e simili vanno normalizzati (minuscolo, senza spazi) e passati in SHA-256. fbc, fbp, IP e user agent invece vanno in chiaro.
• Versione della Graph API: usa una versione supportata e tienila aggiornata, Meta depreca periodicamente quelle vecchie.

Google Ads con la Data Manager API

Per Google ho scelto la Data Manager API, il nuovo punto di ingresso di Google per inviare conversioni ed eventi. L’autenticazione avviene con OAuth2: crei un client OAuth in Google Cloud Console, ottieni un refresh token e lo usi per generare i token di accesso.

// POST https://datamanager.googleapis.com/v1/events:ingest
{
  "destinations": [{
    "operatingAccount": { "accountType": "GOOGLE_ADS", "accountId": "ID_ACCOUNT" },
    "loginAccount":     { "accountType": "GOOGLE_ADS", "accountId": "ID_MCC" },
    "productDestinationId": "ID_AZIONE_DI_CONVERSIONE"
  }],
  "consent": { "adUserData": "CONSENT_GRANTED", "adPersonalization": "CONSENT_GRANTED" },
  "events": [{
    "adIdentifiers": { "gclid": "GCLID_SALVATO_AL_CLICK" },
    "transactionId": "ID_UNIVOCO_CONVERSIONE",
    "eventTimestamp": "2026-10-13T10:15:00+02:00",
    "eventSource": "WEB",
    "conversionValue": 25.00,
    "currency": "EUR"
  }]
}

Lato Java, la parte di autenticazione si risolve con la libreria ufficiale di Google:

UserCredentials credentials = UserCredentials.newBuilder()
        .setClientId(clientId)
        .setClientSecret(clientSecret)
        .setRefreshToken(refreshToken)
        .build();
credentials.refreshIfExpired();
String accessToken = credentials.getAccessToken().getTokenValue();
// header: Authorization: Bearer {accessToken}

Un consiglio: durante lo sviluppo aggiungi "validateOnly": true al corpo della richiesta. Google valida il payload senza registrare la conversione, così puoi fare tutte le prove che vuoi senza sporcare i dati.

[SCREENSHOT 3: Google Ads, azione di conversione alimentata via API]
Alt: “Azione di conversione Google Ads alimentata tramite Data Manager API”

TikTok Events API, in breve

Se fai campagne anche su TikTok, la logica è la stessa. La chiamata va verso https://business-api.tiktok.com/open_api/v1.3/event/track/, con il token di accesso nell’header Access-Token. Nel payload indichi l’ID del pixel, il nome dell’evento, un event_id per la deduplicazione e, nei dati utente, il ttclid salvato al click insieme a IP e user agent. Avendo già costruito la struttura per Google e Meta, aggiungere TikTok è questione di poche ore.

Monitoraggio e retry: la parte che nessuno ti racconta

Inviare un evento è facile. Sapere che è arrivato davvero, ogni giorno, è un’altra storia. Le API possono rispondere con un errore, un token può scadere, un deploy può rompere qualcosa. Se non te ne accorgi, perdi conversioni in silenzio.

Per questo ogni invio viene salvato su database con il suo stato:

@Scheduled(cron = "0 */15 * * * *")
public void retryFailedConversions() {
    List<CapiEvent> failed = capiEventRepository
            .findByStatusAndAttemptsLessThan(Status.ERROR, MAX_ATTEMPTS);
    for (CapiEvent e : failed) {
        boolean ok = dispatcher.send(e);   // Meta, Google o TikTok in base a e.getPlatform()
        e.setAttempts(e.getAttempts() + 1);
        e.setStatus(ok ? Status.SENT : Status.ERROR);
        capiEventRepository.save(e);
    }
}

Sopra a questo ho costruito una piccola dashboard interna che mi mostra, giorno per giorno, quanti click reali ci sono stati, quanti eventi sono partiti, quanti sono stati accettati e quali sono falliti, con un pulsante per rinviare manualmente quelli persi.

Questa dashboard mi ha salvato più di una volta. In un caso un aggiornamento dei template ha rotto il tracciamento lato browser: la differenza tra tag client side e server side è passata in un giorno dal 12% abituale all’85%. Il server side ha continuato a contare correttamente, e proprio quel salto mi ha fatto scattare l’allarme. Il server side non è solo più preciso: diventa anche il tuo sistema di controllo.

Come verificare che il tracciamento funzioni

Una volta in produzione, ecco i controlli che faccio sempre.

Meta: Test eventi

In Events Manager, nella scheda Test eventi, ottieni un codice di test da aggiungere temporaneamente al payload (test_event_code). Gli eventi inviati dal server compaiono in tempo reale, con l’indicazione “Server” e, se invii anche dal pixel, lo stato di deduplicazione.

Meta: qualità della corrispondenza degli eventi

Per ogni evento Meta assegna un punteggio da 0 a 10 che indica quanto bene riesce ad associarlo a un utente. Nel portale che gestisco, dopo l’arrivo dei primi acquisti via server, il punteggio dell’evento di acquisto è passato da 4,4 a 6,1 su 10, con IP, user agent, ID esterno e fbc coperti al 100%. Il punteggio non arriva più in alto perché il portale non raccoglie email o telefono: è un limite strutturale, non tecnico.

Google Ads: diagnostica e confronto con i click reali

In Google Ads, nella pagina dell’azione di conversione, trovi lo stato e la diagnostica degli invii. Ma il controllo che conta davvero è confrontare tre numeri: click reali registrati dal tuo sistema, eventi inviati, eventi riconosciuti da Google. In una giornata campione: 379 click reali, 375 eventi inviati via CAPI e circa 380 riconosciuti lato GADS, 371 quelli riconosciuti con l’invio lato client (GA4).

Come vedi i dati sono perfettamente sovrapponibili e le conversioni lato server inviate sono esattamente quelle riconosciute.

Usa le conversioni server side per il bidding

Ultimo passaggio, spesso dimenticato: se hai sia il tag client side sia l’invio server side, assicurati che le campagne ottimizzino sulle conversioni giuste. Io uso un obiettivo di conversione personalizzato che contiene solo le azioni alimentate via API, così lo Smart Bidding impara dai dati più affidabili e non conta due volte lo stesso evento.

Gli errori che ho fatto io (così non li fai tu)

Questa è la sezione che avrei voluto leggere prima di iniziare.

L’app OAuth di Google lasciata in modalità “Test”

Per settimane tutto ha funzionato, poi improvvisamente gli invii a Google hanno iniziato a fallire. Il motivo: il client OAuth in Google Cloud Console era rimasto nello stato di pubblicazione “Test”, e in quella modalità i refresh token scadono dopo 7 giorni. Soluzione: portare l’app “In produzione”. Una riga di configurazione, giorni di conversioni da recuperare.

Il fbclid troncato

Un vecchio limite su un campo del database tagliava il fbclid a pochi caratteri. Risultato: il fbc inviato dal server non coincideva con quello del browser, e Meta non riusciva né ad associare né a deduplicare gli eventi. L’identificativo del click va conservato integro, sempre.

I browser in-app di Facebook

Quasi tutto il traffico da Meta Ads arriva dal browser interno dell’app, dove il cookie _fbp spesso non esiste e alcuni fbclid non sono validi. Ho aggiunto un controllo di validità sull’identificativo e smesso di contare sul _fbp: in questi casi IP, user agent, fbc e un ID esterno fanno la differenza.

Conversioni inviate anche per i bot

Crawler e bot pubblicitari visitano le pagine con parametri di campagna nell’URL. Se non li filtri, finisci per mandare alle piattaforme eventi che non sono mai stati di un essere umano. Un controllo sul bot prima di ogni invio è obbligatorio.

Ottimizzare per l’evento sbagliato

In una prima campagna su Meta la destinazione era direttamente il link di uscita verso il partner, così l’algoritmo ottimizzava per i click e non per le vendite. Il server side ti permette di inviare l’evento di acquisto vero: usalo come obiettivo, non fermarti a quello intermedio.

Privacy, consenso e GDPR

Chiariamo subito un equivoco: il server side tracking non serve ad aggirare il consenso. Le regole su cookie e trattamento dei dati valgono anche quando i dati partono dal server.

Nella pratica questo significa:

• inviare gli eventi solo per gli utenti che hanno dato il consenso al marketing, o comunque nel rispetto della base giuridica che hai individuato;
• comunicare a Google lo stato del consenso nei campi dedicati della richiesta;
• inviare il minimo indispensabile e hashare sempre i dati personali;
• conservare un registro dei consensi lato server, per poter dimostrare cosa ha accettato l’utente e quando;
• aggiornare informativa privacy e cookie policy citando l’invio dei dati alle piattaforme.

I benefici concreti per le tue campagne

Ricapitolando, cosa ottieni con un tracciamento server side fatto bene:

• Più conversioni attribuite: recuperi gli eventi che adblock, browser e cookie ti stavano facendo perdere.
• Algoritmi che imparano meglio: Smart Bidding e l’ottimizzazione di Meta lavorano su dati più completi, con un impatto diretto sul costo per acquisizione.
• Conversioni ritardate e offline: vendite che avvengono giorni dopo, o su sistemi esterni, tornano finalmente collegate all’annuncio.
• Nessun costo ricorrente per provider e container, e una dipendenza in meno.
• Un sistema di controllo: il confronto tra client e server side ti avvisa subito quando qualcosa si rompe.
• Controllo sui dati: decidi tu cosa esce, verso chi, e con quale consenso.

Domande frequenti

Queste alcuune domande e risposte sul server side tracking per ottimizzare le campagne

Non sai da dove partire? Ti aiuto io

Implementare il server side tracking in modo diretto richiede di lavorare su più fronti insieme: backend, API delle piattaforme, configurazione di Google Ads e Meta, monitoraggio e privacy. È esattamente il tipo di progetto in cui lavoro da anni, mettendo in comunicazione sistemi diversi.

Se fai campagne su Google Ads, Meta Ads o TikTok Ads e hai il sospetto che i numeri non tornino, posso aiutarti a:

• fare un audit del tracciamento attuale e capire quante conversioni stai perdendo;
• progettare e implementare l’invio diretto delle conversioni dal tuo backend, senza provider intermedi;
• impostare monitoraggio, retry e obiettivi di conversione per il bidding;
• migrare da una soluzione basata su provider esterni a una gestita interamente da te.

Scrivimi raccontandomi come è fatto oggi il tuo sito e su quali piattaforme investi: partiamo da lì.

Conclusioni

Il pixel nel browser non è morto, ma da solo non è più sufficiente. Il server side tracking ti restituisce i dati che stai perdendo e li consegna agli algoritmi che decidono come spendere il tuo budget pubblicitario. Si può fare con un provider, con un container GTM server side oppure, come ho fatto io, con un’integrazione diretta dal backend: più impegnativa da costruire, ma senza costi ricorrenti, senza intermediari e con il pieno controllo dei dati.

Qualunque strada tu scelga, ricorda le tre cose che fanno la differenza: identificativi del click conservati integri, deduplicazione corretta e un monitoraggio che ti dica ogni giorno se gli eventi stanno arrivando davvero.