Tracking server-side per Facebook Ads

Il tracking server-side per Facebook Ads è una configurazione in cui il tuo server, non uno script nel browser, invia gli eventi di conversione a Meta tramite la Conversions API. Recupera gli eventi che ad blocker e limiti dei browser tolgono al Meta Pixel. Non cambia le regole sul consenso, le impostazioni di attribuzione né le conversioni che Meta modella.

Il termine copre due cose distinte, e molte configurazioni ne fanno una sola. La prima è da dove parte l’evento: dal tuo server invece che dal browser. La seconda è dove vivono gli identificatori: un cookie di click impostato dal tuo server, sul tuo dominio, invece che scritto da JavaScript. Le opzioni di configurazione di Meta gestiscono la prima. La seconda la decidono le regole di Safari. Entrambe fanno parte del tracking lato server nel senso che conta per l’attribuzione.

Cosa significa tracking server-side su Meta

Con il solo Pixel, il browser fa tutto: lo script si carica, legge i cookie di Meta e riporta il Lead quando il form viene inviato. Se lo script non si carica, non viene riportato niente.

Con la Conversions API è il tuo server a inviare l’evento: il nome, l’orario, un event_id e le informazioni sul cliente che Meta usa per abbinarlo a una persona (email e telefono in hash, l’identificatore del click, indirizzo IP, user agent). Meta dice che gli eventi web inviati così sono collegati al tuo Pixel e si comportano come quelli del Pixel: servono agli stessi tipi di ottimizzazione e compaiono in Ads Manager ed Events Manager (Informazioni sulla Conversions API). Il payload è descritto nella voce Meta CAPI.

Le opzioni di tracking server-side per Facebook Ads a confronto

Il confronto delle opzioni di configurazione di Meta elenca un’opzione Meta-enabled da un click, le integrazioni dei partner (tra cui Google Tag Manager) e l’integrazione diretta. Il Conversions API Gateway è documentato a parte su Meta for Developers. In pratica:

Per la lead gen, il metodo conta meno del punto da cui parte l’evento. L’opzione Meta-enabled e il Gateway partono entrambi dal Pixel: inoltrano quello che il Pixel ha raccolto nel browser. Se un ad blocker ha fermato lo script del Pixel, di solito non c’è niente da inoltrare. La configurazione più solida invia il Lead dal server che ha ricevuto il form, con gli identificatori che ha salvato quando è arrivato il click. Cioè un’integrazione diretta, o uno strumento che la gestisce per te.

Cosa risolve il tracking server-side e cosa no

ITP di Safari: il cookie deve arrivare dal tuo server

Le regole di tracking prevention di WebKit trattano i cookie in modo diverso a seconda di chi li scrive:

• I cookie creati da JavaScript vengono cancellati dopo 7 giorni senza interazione dell’utente con il sito.
• Quando ITP rileva un click ID nell’URL (link decoration), i cookie che JavaScript crea su quella landing page hanno una scadenza massima di 24 ore. fbclid è un click ID.
• I cookie impostati in una risposta HTTP sfuggono a questi limiti, a meno che la richiesta vada a un sottodominio che risolve tramite CNAME verso una terza parte, o a un indirizzo IP di terze parti. In quel caso anche loro sono limitati a 7 giorni.

Il Pixel è JavaScript, quindi i cookie che scrive ricadono nelle prime due regole. Un server container su sst.tuodominio.it che punta a un provider di hosting può ricadere nella terza. Nessuno di questi limiti si applica a un cookie impostato nella risposta HTTP della landing page stessa, dall’host che la serve.

È il principio del tracking first-party di DropCPL: la landing page è servita dal dominio di tracking, e il cookie del click (first-party, HttpOnly) viene impostato nella stessa risposta che la renderizza, senza redirect in mezzo. La storia di cosa si è rotto e quando è in tracciare dopo iOS, e ITP ha la definizione breve.

Consenso e opt-out

Spostare la chiamata sul tuo server cambia il modo in cui viaggiano i dati. Non cambia se hai il diritto di inviarli. Il centro assistenza di Meta dice che la Conversions API, come il Pixel, non è pensata per aggirare l’App Tracking Transparency di Apple o le norme europee sulla privacy come la direttiva ePrivacy, e che gli eventi server seguono gli stessi controlli sull’attività fuori da Facebook e sui dati dei partner che valgono per il Pixel (Informazioni sulla Conversions API). Se il tuo banner di consenso blocca il Pixel finché la persona non accetta, l’evento server per quel visitatore ha bisogno dello stesso blocco. Come costruirlo è una domanda per il tuo consulente privacy.

Attribuzione e conversioni modellate

Gli eventi server finiscono nella stessa macchina di attribuzione degli eventi del Pixel. L’impostazione predefinita di Meta è 7 giorni dal click, 1 giorno dalla visualizzazione e 1 giorno dall’interazione, e dove i risultati non si possono misurare direttamente per dati parziali o mancanti, Meta può usare la modellazione statistica per una parte di essi (Risultati). Il tracking server-side rende il numero di Meta più informato. Non trasforma Ads Manager nel conteggio dei lead che hai ricevuto: quel lavoro lo fa il tuo conteggio first-party, come spiega CPL reale vs CPL della piattaforma.

Il tracking server-side funziona meglio quando il server che registra il click è lo stesso che renderizza la landing page. DropCPL fa entrambe le cose sul tuo dominio di tracking, poi invia il Lead a Meta tramite la Conversions API con un event_id e i valori fbc e fbp. Inizia gratis →

Deduplica: l’event_id condiviso tra Pixel e server

Meta consiglia la configurazione ridondante, con Pixel e Conversions API che inviano gli stessi eventi (Gestire gli eventi duplicati). A Meta arrivano quindi due copie dello stesso Lead, e ne tiene una sola quando:

• il nome dell’evento del Pixel coincide con l’event_name del server (Lead e Lead),
• l’eventID del Pixel coincide con l’event_id del server,
• entrambi arrivano entro 48 ore dal primo evento con quell’ID.

Browser: fbq('track', 'Lead', {}, { eventID: 'lead_7f3a91' })
Server:  { "event_name": "Lead", "event_id": "lead_7f3a91", "action_source": "website", "user_data": { ... } }

Il modo più semplice per avere ID uguali: lascia che il server crei prima il lead, usa l’ID del lead come event_id nella chiamata all’API e passa lo stesso ID al browser per il Pixel. Meta supporta anche la deduplica su fbp o external_id, ma quel metodo in genere funziona solo quando l’evento del browser arriva per primo, e un server che invia il Lead appena riceve il form spesso arriva prima del browser.

Senza un ID condiviso, Meta può contare due volte lo stesso lead, e il CPL in Ads Manager sembra migliore di quello che è. Deduplica tra Meta Pixel e CAPI spiega come verificarla in Events Manager.

Match quality: cosa deve contenere l’evento server

Un evento server che Meta non riesce ad abbinare a un account non viene attribuito a nessuno. Meta chiama quelli riusciti eventi abbinati (matched events), e dice che con la Conversions API puoi includere parametri di informazioni sul cliente che aumentano sia gli eventi abbinati sia la tua Event Match Quality (Informazioni sulla Conversions API).

Per un Lead da un form su landing page, invia quello che hai raccolto legittimamente, formattato come richiedono i parametri delle informazioni sul cliente di Meta:

• email e telefono, normalizzati e in hash SHA-256;
• il click ID (fbc) e il browser ID (fbp), senza hash;
• indirizzo IP e user agent del visitatore, senza hash, raccolti al momento dell’invio del form (lo user agent è obbligatorio per gli eventi web);
• un external_id, per esempio l’ID del lead, per cui Meta consiglia l’hash.

L’identificatore del click è quello che lega l’evento a un click specifico su un annuncio, ed è quello che manca più spesso. Se il fbclid non è stato salvato quando è arrivato il click, nessun codice lato server lo recupera dopo: un motivo in più per catturarlo sul server che renderizza la landing page. I cookie fbc e fbp spiegati copre il formato, e Event Match Quality di Meta copre punteggi e correzioni.

La configurazione che sceglieremmo per la lead gen su Meta

1. Servi la landing page dal tuo dominio, e registra il click (con fbclid e ID dell’annuncio) sul server che la renderizza.
2. Imposta il cookie del click in quella stessa risposta: first-party, HttpOnly, nessun passaggio di redirect.
3. Fai inviare il form allo stesso server e crea lì il lead, con un ID.
4. Invia il Lead alla Conversions API da quel server, con l’ID del lead come event_id, più email e telefono in hash, fbc, fbp, indirizzo IP e user agent.
5. Se si attiva anche il Pixel, dagli lo stesso eventID.
6. Decidi i budget sui lead che hai contato, e tieni il dato di Ads Manager come diagnostica.