Meta Conversions API: cos'è, come funziona e quando serve davvero

Poi arriva il preventivo, e la domanda diventa un'altra: mi serve davvero, e a cosa serve esattamente?

La risposta breve è che la Conversions API è un secondo canale per far arrivare a Meta le informazioni sulle conversioni. Il primo è il Pixel, che parte dal browser di chi visita il sito. Il secondo parte dal tuo server, o dalla piattaforma su cui è costruito il negozio. Non si sostituiscono: nella maggior parte dei siti oggi lavorano insieme, e proprio per questo la parte più delicata non è attivarla — è fare in modo che Meta capisca che i due canali stanno raccontando lo stesso acquisto, e non due.

Qui vediamo cosa fa davvero, cosa non fa, perché una configurazione approssimativa può peggiorare i dati invece di migliorarli, e in quali situazioni è una priorità vera. Senza codice, e senza raccontarti che risolverà problemi che non risolve.

Cos'è la Meta Conversions API

La Conversions API — spesso abbreviata in CAPI — è il canale con cui la tua azienda può inviare a Meta gli eventi che avvengono sul sito, in app o nei propri sistemi, partendo dai propri server invece che dal browser di chi naviga.

Detta così sembra un dettaglio idraulico. In pratica cambia una cosa sostanziale: chi spedisce l'informazione. Con il Pixel, a spedirla è il browser della persona; con la Conversions API, a spedirla è un sistema controllato da te — il tuo server, la piattaforma e-commerce, il partner che gestisce l'integrazione.

Sul piano di cosa Meta ci fa poi, la differenza è meno grande di quanto sembri. Nella documentazione, gli eventi server sono collegati a un dataset e vengono elaborati in modo analogo a quelli che arrivano dal Pixel: possono essere usati per misurazione, reportistica e ottimizzazione allo stesso modo degli altri canali di collegamento.

Una nota sui nomi, perché genera confusione: quello che per anni si è chiamato «Pixel» oggi nelle interfacce Meta è spesso indicato come dataset, e le due parole vengono usate in modo intercambiabile. È lo stesso identificativo. Se in Gestione eventi non trovi più la voce «Pixel» dove te la ricordavi, non è sparito niente.

Questo articolo si concentra sul caso più comune e più cercato: gli eventi di un sito web, e-commerce o generazione di contatti. La Conversions API può fare anche altro — collegare eventi che arrivano da un CRM, da sistemi offline, da un'app — ma il grosso delle implementazioni riguarda quello, e il resto lo accenniamo solo dove serve.

Pixel e Conversions API: qual è la differenza?

La tentazione, guardando la tabella, è concludere che il secondo sia meglio del primo. Non è così, ed è il punto in cui quasi tutti gli articoli sbagliano.

Il Pixel non è morto e la Conversions API non lo sostituisce. Sono due strade verso la stessa destinazione, che si comportano bene in situazioni diverse. Il browser sa cose che il server non sa — cosa ha guardato la persona, come è arrivata, che percorso ha fatto. Il server sa cose che il browser non sa — se l'ordine è stato davvero confermato, quanto vale, se il pagamento è andato a buon fine.

Per questo, per gli eventi web, la configurazione documentata da Meta come scenario di riferimento è quella combinata: entrambi attivi. Se ti stai chiedendo se togliere il Pixel dopo aver messo la CAPI, la risposta è no. Se non hai chiaro cosa faccia il Pixel, conviene partire da lì: ne abbiamo parlato in Meta Pixel: cos'è e come funziona.

Come funzionano insieme Pixel e CAPI

Prendiamo un caso concreto, senza codice.

Una persona vede un annuncio su Instagram, tocca, arriva sul tuo negozio. Guarda un prodotto, lo mette nel carrello, va al checkout e compra. Fine.

Cosa succede lato Pixel: il browser segnala gli eventi man mano che accadono — la visita alla pagina prodotto, l'aggiunta al carrello, l'avvio del checkout, l'acquisto.

Cosa succede lato Conversions API: quando il tuo sistema registra l'ordine come completato, invia a Meta l'evento di acquisto partendo dal server, con le informazioni che ha a disposizione.

Risultato: Meta riceve due segnalazioni dello stesso acquisto. Una dal browser, una dal server.

Ed è qui che sta tutto il mestiere.

Il ruolo dell'event_id

Perché Meta capisca che quelle due segnalazioni sono lo stesso fatto e non due acquisti, entrambe devono portare con sé lo stesso identificatore dell'evento — quello che nella documentazione si chiama event_id.

Il principio, senza tecnicismi:

• l'acquisto numero X genera un identificatore, mettiamo ABC123;
• il browser invia «Acquisto, id ABC123»;
• il server invia «Acquisto, id ABC123»;
• Meta vede lo stesso nome evento e lo stesso identificatore, e capisce che si tratta di un solo acquisto.

Non serve che tu sappia come viene generato quell'identificatore — è lavoro di chi implementa. Serve che tu sappia che deve esserci, e che deve essere identico sui due canali.

Come funziona la deduplicazione

Il meccanismo con cui Meta scarta il doppione si chiama deduplicazione, e nella documentazione poggia sulla combinazione di nome dell'evento e identificatore dell'evento: se i due canali inviano lo stesso evento con lo stesso identificatore, ne resta uno.

Sembra un dettaglio da sviluppatori. È invece la differenza fra migliorare e rovinare la misurazione, e vale la pena dirlo con chiarezza: una Conversions API configurata male può essere peggio di nessuna Conversions API.

Se la deduplicazione non funziona, i tuoi acquisti risultano gonfiati. Non solo nei report — cosa già spiacevole — ma anche nei dati su cui il sistema di Meta impara. Meta stessa avverte, nella propria documentazione, che identificatori di evento imprecisi possono portare a deduplicazioni sbagliate, con conseguenze sulla reportistica delle conversioni e sul rendimento delle campagne.

Tradotto: se ottimizzi le campagne su un numero di acquisti che non esiste, stai insegnando al sistema la cosa sbagliata.

L'obiettivo non è «avere la CAPI attiva». È far arrivare eventi corretti.

Quali eventi ha senso inviare

Meta ha un insieme di eventi standard — visualizzazione di contenuto, aggiunta al carrello, avvio del checkout, acquisto, contatto, registrazione, e altri. Tecnicamente puoi inviarne molti.

Il criterio non è tecnico, è di buon senso: un evento serve se rappresenta qualcosa che ti interessa misurare o su cui ti interessa ottimizzare. Non tutto quello che si può inviare merita di essere inviato: riempire il dataset di micro-interazioni non rende il sistema più intelligente, lo rende più rumoroso.

In pratica, i due casi che contano davvero:

• e-commerce → l'acquisto, con il suo valore e la sua valuta. È l'evento su cui si gioca tutto;
• generazione di contatti → il contatto acquisito, e possibilmente qualcosa che dica se quel contatto valeva qualcosa.

Su questo secondo punto torniamo fra poco, perché è la parte più interessante e la meno sfruttata.

Quali dati accompagnano un evento

Un evento non è solo il suo nome. Porta con sé due gruppi di informazioni.

Sull'evento in sé: quando è avvenuto, su quale pagina, che valore ha, in che valuta, quali prodotti riguarda, e l'identificatore di cui abbiamo parlato.

Sulla persona, per il collegamento: sono i parametri che permettono a Meta di capire a quale account associare quell'evento. A seconda di cosa hai a disposizione e di cosa puoi legittimamente inviare: email, telefono, un identificativo interno del cliente, indirizzo IP, informazioni sul browser, gli identificatori che Meta stessa usa.

Due precisazioni importanti, e non sono intercambiabili.

Prima: i dati di contatto vanno hashati, gli altri no. Meta specifica che i propri sistemi sono progettati per non accettare informazioni di contatto non hashate — nome, email, numero di telefono. Ma non vale per tutto: parametri tecnici come l'indirizzo IP, le informazioni sul browser e gli identificatori generati da Meta non vanno hashati. «Hasha tutto» è un consiglio sbagliato, e produce eventi che non si agganciano a niente.

Seconda: l'hashing non trasforma un dato personale in un dato qualsiasi. È una misura tecnica di protezione, non un lasciapassare che ti autorizza a inviare qualunque informazione. Ne parliamo nella sezione sul consenso.

C'è poi una regola pratica che vale la pena conoscere: Meta chiede che ogni evento contenga almeno uno dei parametri di collegamento, formattato correttamente. Un evento senza nulla a cui agganciarsi arriva, ma serve a poco.

Due identificatori che vale la pena conoscere

Nelle discussioni tecniche sentirai nominare due sigle.

Il browser ID è un identificatore che l'ecosistema Meta associa al browser. Il click ID è collegato al clic proveniente da un annuncio Meta, quando quel clic c'è stato.

Due cose da non fare, entrambe frequenti:

• non darli per scontati. Non sono sempre presenti: se una persona arriva sul sito digitando l'indirizzo, non c'è nessun clic da un annuncio, e quindi non c'è nessun click ID;
• non inventarli. Un click ID deve nascere da un clic reale. Fabbricarlo per «migliorare i numeri» significa inviare a Meta un'informazione falsa.

Cos'è l'Event Match Quality

In Gestione eventi, accanto ai tuoi eventi server, trovi un punteggio chiamato Event Match Quality — spesso abbreviato in EMQ, espresso su una scala da 0 a 10.

Cosa misura: quanto le informazioni sul cliente che invii insieme agli eventi aiutano Meta ad abbinarli a un account. È una metrica sul collegamento, e su niente altro.

Cosa non misura, ed è la lista che serve davvero:

• non misura se le tue campagne funzionano;
• non misura la qualità della creatività;
• non misura se l'acquisto che hai inviato è corretto;
• non misura se la deduplicazione funziona (quella si controlla altrove);
• non è un indice di «salute generale» dell'account.

Puoi avere un Event Match Quality alto e campagne che vanno male. Puoi avere un punteggio basso e vendite ottime.

Come si alza: inviando più parametri di collegamento, quando li hai e quando puoi inviarli. Meta indica una scala di priorità fra questi parametri — l'email hashata è quella con il peso maggiore, seguita da informazioni come indirizzo IP, dati del browser e telefono hashato, mentre altri identificatori pesano meno.

Su quale numero puntare: circolano soglie di riferimento — 6 come minimo accettabile, 8 come obiettivo sull'acquisto — ma sono indicazioni che vengono da operatori del settore, non una soglia universale fissata da Meta. Trattale come punti di riferimento, non come voti.

E soprattutto: un punteggio più alto non garantisce risultati migliori. Un collegamento migliore può contribuire a un'attribuzione più completa e a segnali più puliti per l'ottimizzazione. Non compensa un'offerta debole, una creatività che non funziona, un pubblico sbagliato o un checkout che perde gente per strada. La Conversions API non aggiusta le campagne: aggiusta il modo in cui i risultati arrivano a Meta.

Perché il server-side rende la trasmissione più robusta

Il motivo per cui la Conversions API è diventata un tema non è una notizia sola, ma una somma di cose.

Gli eventi che partono dal browser dipendono da molte condizioni che non controlli: impostazioni del browser, estensioni installate, script che non si caricano, connessioni che cadono, restrizioni che negli anni sono aumentate. Nessuna di queste, presa singolarmente, «rompe» il tracciamento; insieme, rendono la trasmissione dal browser meno prevedibile di quanto fosse.

Il server, invece, è tuo. Se il tuo sistema registra un ordine, quell'ordine esiste — e l'invio a Meta non dipende da cosa succede sul dispositivo di chi ha comprato.

Detto questo, servono tre paletti, perché è il punto dove si dicono più sciocchezze.

Server-side non vuol dire aggirare le regole delle piattaforme o del browser. Vuol dire spostare da dove parte la trasmissione di alcune informazioni. È una differenza di percorso, non un modo per fare cose che altrimenti non potresti fare.

Server-side non vuol dire dato perfetto. Se il tuo sistema non registra un'informazione, la Conversions API non può inviarla. Non inventa nulla.

Server-side non vuol dire senza consenso. È il punto successivo, e merita una sezione sua.

Privacy e consenso: il server non cambia le regole

Qui bisogna essere netti, perché è l'equivoco più pericoloso di tutto l'argomento.

Si sente dire: siccome i dati non passano più dal browser, il consenso non serve. È sbagliato.

Inviare dati a Meta dal tuo server resta a tutti gli effetti una condivisione di dati verso un soggetto terzo. Il fatto che il percorso tecnico sia diverso non cambia la natura dell'operazione, e non fa sparire gli obblighi verso la persona a cui quei dati si riferiscono.

Il principio, formulato in modo utile e senza entrare in materia legale: l'implementazione deve rispettare la normativa applicabile e le scelte di consenso dell'utente. Spostare la trasmissione sul server non elimina questi obblighi.

Due conseguenze pratiche:

• il sistema di gestione del consenso deve poter agire anche sul lato server. Non basta che il banner blocchi il Pixel se poi il server invia comunque;
• l'hashing non è un'autorizzazione. Serve a proteggere il dato in transito e Meta lo richiede per le informazioni di contatto, ma non trasforma un'informazione personale in una che puoi inviare senza pensarci.

Una precisazione che evita confusione, perché la domanda arriva sempre: il Consent Mode è un meccanismo dell'ecosistema Google. Non è il sistema con cui si gestisce il consenso per la Conversions API di Meta. Sono due mondi diversi, e vanno configurati separatamente.

Per il resto — quali basi giuridiche, quali informative, come configurare la piattaforma di consenso — serve chi se ne occupa di mestiere. Questo articolo dice cosa non dare per scontato, non cosa scrivere nella privacy policy.

Cosa la Conversions API non fa

Vale la pena raggruppare le promesse che sentirai e che non stanno in piedi.

Non recupera «tutti i dati persi». Rende il flusso più robusto; non ricostruisce eventi che la tua azienda non ha mai osservato e non crea informazioni che non possiedi.

Non porta il tracciamento al 100%. Nessuna configurazione lo fa, e chi te lo promette ti sta vendendo qualcosa.

Non allinea Meta con Google Analytics o con il tuo gestionale. Ci torniamo fra due righe.

Non garantisce un costo per acquisizione più basso o un ritorno più alto. Può migliorare la qualità dei segnali. Cosa succede poi dipende da offerta, creatività, pubblico e sito.

Perché Meta, Analytics e il gestionale non coincidono

Dopo aver implementato la Conversions API, molti si aspettano che i numeri si allineino. Non succede, e non è un difetto.

I tre sistemi contano cose diverse: usano modelli di attribuzione diversi, finestre temporali diverse, definizioni diverse di cosa sia una conversione, fusi orari e configurazioni diverse, e ognuno gestisce l'identità a modo suo. Uno scarto fra Gestione eventi, il tuo strumento di analytics e il gestionale è normale.

La Conversions API migliora il flusso di segnali verso Meta. Non rende Meta uguale al tuo gestionale, e non è quello il suo scopo. Il gestionale resta la fonte di verità su quanto hai venduto; Meta ti dice cosa è successo dal suo punto di vista, che è un altro.

Come si implementa

Le strade principali sono tre, e la differenza fra loro è quanto lavoro tecnico richiedono e quanto controllo ti lasciano.

Integrazione con la piattaforma o con un partner

La strada più semplice: la piattaforma su cui è costruito il negozio, o un partner supportato, offre un'integrazione già pronta con Meta. Configuri, colleghi il dataset, e la maggior parte del lavoro tecnico — deduplicazione compresa — è gestita dall'integrazione.

È la scelta giusta per la grande maggioranza delle aziende, ed è anche quella che rende inutile pagare uno sviluppatore.

Gateway

Meta mette a disposizione una soluzione intermedia — nota come Conversions API Gateway — che riceve gli eventi e li inoltra alla Conversions API senza che l'azienda debba costruire l'integrazione da zero. Riduce il lavoro tecnico rispetto a un'implementazione diretta, con un costo di gestione.

Le denominazioni e le modalità di accesso in quest'area si sono mosse parecchio: se la valuti, verifica cosa è disponibile oggi per il tuo caso invece di affidarti a una guida di due anni fa.

Implementazione diretta

Il tuo sistema parla direttamente con l'API di Meta. Massimo controllo, massima flessibilità — e serve qualcuno che la costruisca e soprattutto che la mantenga.

Ha senso quando hai esigenze che le altre due strade non coprono: eventi che nascono in sistemi tuoi, logiche di business particolari, dati che arrivano dal CRM.

Nessuna delle tre è «la migliore» in assoluto. La scelta dipende dalla piattaforma che usi, dalle competenze che hai in casa, da quanto controllo ti serve, da quanto sei disposto a spendere in manutenzione e dai volumi in gioco.

Il caso Shopify

Su piattaforme come Shopify esiste un'integrazione ufficiale con Meta che gestisce il collegamento e riduce moltissimo il lavoro tecnico. Per un negozio Shopify standard, è quasi sempre la strada giusta.

Due avvertenze. La prima: le configurazioni disponibili e i nomi delle impostazioni sono cambiati più volte, quindi vale la pena guardare cosa offre l'integrazione oggi invece di seguire un tutorial datato. La seconda, più importante: attivare l'integrazione non è la fine del lavoro. Va poi verificato in Gestione eventi che gli eventi arrivino, che siano quelli giusti e che la deduplicazione funzioni.

Come verificare che funzioni davvero

Questa è la parte che quasi nessuno fa, ed è quella che distingue un'implementazione buona da una che sembra buona.

In Gestione eventi, per gli eventi server, Meta mette a disposizione una serie di controlli — la panoramica degli eventi, l'Event Match Quality, la freschezza dei dati e la deduplicazione degli eventi.

Cosa guardare, in ordine di importanza:

1. Gli eventi arrivano? Verifica che gli eventi che ti aspetti compaiano davvero.
2. Da dove arrivano? Distingui quelli ricevuti dal browser da quelli ricevuti dal server. Se l'acquisto arriva solo da uno dei due, sai già dove guardare.
3. La deduplicazione funziona? È il controllo più importante quando i due canali sono entrambi attivi. Attenzione a come si legge: se per un acquisto arriva solo il browser oppure solo il server, non c'è nessuna coppia da deduplicare, e l'assenza di attività non dimostra niente. Il segnale da approfondire è un altro: se ti aspetti che lo stesso acquisto arrivi da entrambi i canali ma non risulta deduplicato, verifica che i due eventi arrivino davvero e che condividano nome dell'evento e identificatore.
4. La diagnostica segnala qualcosa? Gli avvisi di Meta su parametri mancanti o formattati male vanno letti, non ignorati.
5. I parametri arrivano tutti? Confronta quello che pensavi di inviare con quello che risulta ricevuto.
6. I volumi hanno senso? Un numero di acquisti improvvisamente doppio rispetto al gestionale è il sintomo classico.
7. Il valore e la valuta sono corretti? Non esiste una definizione «giusta» in assoluto del valore di un ordine — dipende da cosa la tua azienda considera tale, e su alcune piattaforme gli eventi usano il totale dell'ordine con imposte e sconti inclusi. Quello che conta è che sia la stessa ovunque: backend, integrazione e report devono raccontare lo stesso importo. Una valuta errata, invece, falsa tutto quello che ci costruisci sopra.

Un'avvertenza sull'interfaccia: nomi delle voci e schermate cambiano con una certa frequenza. Se quello che leggi non corrisponde a quello che vedi, è probabile che sia cambiato il nome, non la funzione.

Quando serve davvero

La domanda del titolo. Ecco le condizioni in cui la Conversions API è una priorità vera:

• Meta è un canale importante per la tua acquisizione, non un esperimento da duecento euro al mese.
• Hai conversioni con un valore reale e in numero sufficiente perché la misurazione conti.
• Vendi online e l'acquisto è l'evento su cui ottimizzi.
• Oppure generi contatti e sai distinguere un contatto buono da uno inutile.
• Hai un backend o una piattaforma affidabile da cui partire.
• Alcuni eventi che ti interessano non nascono nel browser — un ordine confermato dopo una verifica, un contratto chiuso, un contatto qualificato dal commerciale.
• Qualcuno guarda l'account con regolarità e può accorgersi se qualcosa smette di funzionare.

Il caso più interessante: la generazione di contatti

Se raccogli contatti, c'è una possibilità che quasi nessuno sfrutta.

Il modulo compilato è solo il primo passo. Nel tuo CRM, dopo, succedono altre cose: il contatto viene qualificato, fissa un appuntamento, diventa cliente. Sono quelle le informazioni che dicono davvero se una campagna sta funzionando.

Il concetto vale la pena di essere capito: Meta può ottimizzare meglio quando riceve segnali più vicini al risultato commerciale vero, non solo all'invio del modulo. Se il sistema sa quali contatti sono diventati clienti, può cercare persone che assomigliano a quelli — invece di persone che assomigliano a chiunque compili un form.

Non è automatico e non è banale da costruire: servono un CRM che tenga traccia delle cose, un'integrazione che funzioni, e la verifica di cosa è consentito inviare. Ma è la ragione più solida per cui un'azienda di servizi dovrebbe interessarsi alla Conversions API — più solida del generico «recuperi i dati persi».

Quando invece non è la priorità

Sezione corta e utile, perché è quella che ti fa risparmiare soldi.

Se ti trovi in una di queste situazioni, la Conversions API non è il tuo problema principale:

• spendi cifre molto piccole e le conversioni si contano sulle dita;
• non hai conversioni da misurare;
• il Pixel non è nemmeno configurato bene — capita più spesso di quanto si creda;
• le campagne mandano traffico a una pagina che non converte;
• non sai dire con certezza quanti ordini hai fatto questo mese dal gestionale;
• le campagne hanno problemi di struttura, pubblico od offerta che nessun miglioramento di tracciamento può compensare.

Il principio, secco: prima assicurati che l'evento che stai inviando rappresenti davvero una conversione. Poi migliora il modo in cui lo invii.

Investire in un'implementazione sofisticata quando il problema è che gli annunci non funzionano è come comprare un contachilometri di precisione per un'auto che non parte.

Errori comuni

Quelli che si vedono di più:

1. Acquisti duplicati perché la deduplicazione non è configurata o non funziona.
2. Valore non corrispondente all'ordine — l'importo inviato non è quello che l'azienda considera valore di quell'ordine.
3. Imposte e spedizione gestite in modo incoerente fra backend, integrazione e reportistica: il problema non è includerle o escluderle, è farlo in modo diverso da un sistema all'altro.
4. Valuta errata, tipicamente su negozi multi-mercato.
5. Mapping diverso fra mercati o sistemi, che fa divergere gli stessi ordini a seconda di dove li guardi.
6. Eventi server senza corrispondenza con quelli del browser.
7. Identificatori incoerenti fra i due canali.
8. Eventi inviati nel momento sbagliato — un acquisto segnalato all'apertura della pagina di ringraziamento anche quando il pagamento non è andato a buon fine.
9. Eventi che non rappresentano conversioni reali — un contatto contato all'apertura del modulo invece che all'invio.
10. Il consenso non rispettato lato server.
11. Codici di test lasciati attivi in produzione.
12. Nessuno che controlli, per mesi, se sta ancora funzionando.

Checklist finale

In conclusione

La Conversions API non è una scorciatoia e non è una moda. È un secondo canale per far arrivare a Meta informazioni che oggi, passando solo dal browser, arrivano in modo meno prevedibile.

Fatta bene, rende la misurazione più solida — il che significa report più affidabili e, indirettamente, un sistema che impara su dati meno sporchi. Fatta male, gonfia i numeri e insegna la cosa sbagliata a un algoritmo che poi spende i tuoi soldi.

Ma la domanda giusta, prima di implementarla, è un'altra: stai già misurando la cosa giusta? Perché se l'evento che invii non rappresenta una conversione reale, inviarlo meglio non serve a niente. E se le campagne non funzionano per ragioni che non c'entrano con il tracciamento — quelle di cui parliamo in perché le campagne Meta non danno risultati — nessuna infrastruttura di misurazione le sistemerà.

Prima l'evento giusto. Poi il modo migliore per inviarlo.

Continua la lettura

Meta Ads

Meta Pixel: cos'è, come funziona e perché è fondamentale per le campagne

Meta Ads

Come funzionano le Meta Ads: la guida semplice per trovare nuovi clienti su Facebook e Instagram

Meta Ads

Remarketing su Facebook e Instagram: cos'è e perché funziona così bene