Pillar4 min di lettura·820 parole

Pixel vs Conversion API · perché oggi servono entrambi

Differenze, complementarietà e implementazione di Pixel browser-side e Conversion API server-side. Perché nel 2026 nessuna campagna seria può fare a meno di uno o l’altro, idealmente di tutti e due in parallelo.

Pixel e Conversion API (CAPI) sono i due canali tecnici con cui Meta riceve dagli inserzionisti i segnali di conversione: cosa fa l’utente sul sito o sull’app dopo aver cliccato (o visto) un’inserzione. Storicamente, Pixel era sufficiente; dal 2021 in poi, con ATT di Apple e GDPR rinforzato, Pixel da solo lascia troppo segnale sul tavolo, e CAPI è diventata complemento necessario.

Nel 2026 non è più una scelta binaria "Pixel o CAPI", è un setup combinato "Pixel e CAPI" con deduplicazione lato Meta. Capire chi fa cosa è essenziale per leggere correttamente i report.

Pixel · il canale browser

Il Pixel è uno snippet JavaScript installato sul sito web dell’inserzionista. Quando un utente carica una pagina taggata, il browser dell’utente fa una chiamata a Meta con i parametri dell’evento (PageView, ViewContent, AddToCart, InitiateCheckout, Purchase, Lead).

Caratteristiche tecniche:

Canale: browser → Meta direttamente.
Identificatore utente: cookie Facebook (_fbp, _fbc) e click ID (fbclid in URL).
Visibilità: l’utente può vedere la chiamata negli strumenti developer del browser; ad blocker e privacy extension possono bloccarla.
Vulnerabilità: rifiuto consenso GDPR cookie, ATT su iOS (per app), ad blocker, modalità incognito.

Punto di forza: implementazione velocissima (codice JavaScript da incollare nell’<head> del sito), funziona out-of-the-box, segnali ricchi per gli utenti che non hanno bloccato il tracking.

Punto di debolezza: il 30-50% dei segnali viene perso in Italia a causa di consenso GDPR rifiutato, ATT iOS, ad blocker. Il dato vero è significativamente più alto del tracciato.

Conversion API · il canale server

La Conversion API è una chiamata HTTP firmata dal backend dell’inserzionista a Meta. Quando un utente completa un acquisto sul sito, il server stesso del sito invia a Meta l’evento con i dati identificativi hashati.

Caratteristiche tecniche:

Canale: server inserzionista → server Meta.
Identificatore utente: dati PII (email, telefono, IP, user agent) hashati lato server con SHA-256 prima dell’invio.
Visibilità: zero lato utente. Non passa per il browser.
Vulnerabilità: resistente a GDPR cookie rifiuto (perché non c’è cookie), a ATT (perché non è tracking cross-app), ad ad blocker (server-side).

Punto di forza: recupera 20-40% del segnale perso da Pixel. È particolarmente importante per attribution di Conversion bottom-funnel (ROAS, CPA).

Punto di debolezza: implementazione richiede sviluppo backend non banale. Va integrato con il sistema di consenso GDPR (anche server-side non si possono inviare dati senza base legale documentata). Hashing PII secondo schema Meta è obbligatorio.

Deduplicazione · il punto chiave

Pixel e CAPI inviano spesso gli stessi eventi. Esempio: utente completa acquisto, il browser manda Purchase via Pixel e il server backend manda Purchase via CAPI. Senza deduplicazione, Meta conterebbe 2 acquisti invece di 1, gonfiando il ROAS.

La deduplicazione si fa tramite un event ID univoco condiviso fra le due chiamate. Lo stesso evento viene inviato sia dal Pixel che da CAPI con uno stesso event_id (es. uno UUID generato lato server e passato anche al browser). Meta riceve i due eventi, vede l’event_id comune e li deduplica.

Se la deduplicazione non è configurata, i report Meta sono sistematicamente gonfiati e il ROAS apparente non è credibile. Verifica obbligatoria.

Setup combinato ottimale

La best practice 2026:

Installare Pixel su tutte le pagine del sito, configurando gli eventi standard (PageView, ViewContent, AddToCart, InitiateCheckout, Purchase, Lead).
Configurare CAPI lato backend per gli stessi eventi, con event_id condiviso con Pixel.
Validare deduplicazione in Events Manager di Meta: i diagnostici mostrano se ci sono eventi non deduplicati.
Configurare consenso GDPR per entrambi i canali: nessun evento viene inviato senza consenso documentato.
Monitorare event match quality (EMQ): Meta espone un punteggio 0-10 sulla completezza dei dati identificativi inviati. Sotto 7 indica che CAPI manda pochi parametri (es. solo email, niente telefono) e perde matching opportunità.

Cosa cambia nei report

Con setup combinato corretto, il ROAS Meta sale sensibilmente (20-40% in media rispetto al solo Pixel) perché l’attribution recupera utenti iOS senza ATT consent e utenti che hanno rifiutato cookie GDPR. Questo non è un "trucco" per gonfiare i numeri: è un avvicinamento alla performance reale, che il solo Pixel sottostimava.

Nelle conversazioni con il cliente, va spiegato: "Il ROAS sale non perché abbiamo cambiato campagna, ma perché abbiamo recuperato il segnale che prima ci sfuggiva". La differenza fra ROAS "Pixel only" e ROAS "Pixel + CAPI" è la misura della "blind spot" dell’attribution browser-only.

Quando si può evitare CAPI

Per business molto piccoli (singolo professionista, micro e-commerce <€500/mese di budget Meta) con budget di sviluppo limitato e categorie non sensibili a ATT (target prevalente Android, browser permissivi), il solo Pixel può bastare nel breve termine.

In ogni altro caso, CAPI è investimento obbligatorio. Il costo di implementazione (2-15 giorni dev a seconda della piattaforma) si ripaga in 1-3 mesi di campagne attive con migliore attribution.

Vedi anche: Pixel, Conversion API, ATT, Attribution Window, Privacy ATT.