Il ROAS gonfiato dal doppio conteggio

Ho trovato il gap. I ricavi che Meta riportava erano 2.3 volte quelli reali del periodo.

Il primo sospettato ovvio è il doppio conteggio. L’account ha sia il Pixel che le Conversions API attivi. In teoria è il setup corretto — è quello che Meta stessa raccomanda per recuperare i segnali persi da iOS e dagli ad blocker. Ma c’è un dettaglio che quasi nessuno verifica: la deduplicazione.

Il concetto: event_id e deduplicazione

Quando un acquisto avviene sul sito, succedono due cose in parallelo.

Il Pixel (client-side) registra l’evento e lo manda a Meta dal browser dell’utente. Le Conversions API (server-side) registrano lo stesso evento e lo mandano a Meta dal server. Se i due invii non portano lo stesso event_id, Meta non sa che si tratta dello stesso acquisto. Li conta entrambi. L’evento viene registrato due volte. Il valore dell’acquisto viene sommato due volte. Il ROAS si gonfia.

Questo non è un bug di Meta. È una funzionalità progettata per essere usata correttamente. Meta ha bisogno di ricevere i segnali da entrambe le sorgenti — quella ridondanza è utile, è lo scopo delle CAPI. Ma il parametro event_id serve esattamente a dirle: “questi due eventi sono lo stesso, contali una volta sola”. Senza event_id, il sistema non può deduplicare. Conta tutto.

Un account con Pixel e CAPI senza deduplicazione può avere un ROAS sovrastimato del 30-60% solo per questo motivo. Se ogni acquisto viene registrato due volte, il valore conversioni nel Business Manager raddoppia. Il ROAS raddoppia. Le campagne sembrano performare il doppio di quello che performano davvero.

Cosa succede se lo ignori

Le decisioni di scaling si basano su un numero che non esiste.

Si aumenta il budget perché “sta funzionando” — ma quello che sta funzionando è il conteggio doppio, non la campagna. Si tagliano campagne che sembrano meno efficienti, senza sapere che la loro efficienza è semplicemente tracciata meglio (o peggio) rispetto alle altre. Si ottimizza l’allocazione del budget su metriche che non riflettono la realtà.

Il paradosso è che un account con Pixel e CAPI attivi — che in apparenza è ben configurato, è “avanzato” — può avere un problema di tracciamento più grande di un account che usa solo il Pixel. Il setup più sofisticato, senza deduplicazione, produce distorsioni maggiori.

Come si verifica

La verifica si fa in Events Manager.

Apri l’account Meta, vai su Events Manager, seleziona il Pixel. Nella sezione “Attività”, puoi vedere per ogni tipo di evento quante occorrenze arrivano dal browser e quante dal server. Meta mostra anche il tasso di corrispondenza tra i due flussi. Se il tasso di deduplicazione è basso o la colonna non mostra corrispondenze, il problema è confermato.

Se la verifica rivela che la deduplicazione non è attiva, la correzione richiede di configurare l’event_id in modo che sia lo stesso nel Pixel e nelle Conversions API per ogni evento. Il come tecnico, come generare l’ID univoco, come passarlo attraverso GTM, come collegarlo alla richiesta CAPI, l’ho spiegato in dettaglio nell’episodio 3 della prima serie di Rivoluzione Andromeda, dedicato esattamente a questo strato del sistema. Se non l’hai ancora letto, trovi il link nel mio profilo.

Qui il punto è il perché: senza event_id condiviso, il sistema non può deduplicare, anche se Pixel e CAPI sono entrambi attivi e sembrano funzionare. La ridondanza è utile ed è proprio parte dello scopo delle CAPI. Il parametro event_id è quello che trasforma la ridondanza da problema a risorsa.

Il conteggio è sistemato. Il gap no

Sistemata la deduplicazione, i ricavi nel Business Manager si avvicinano a quelli reali. Il gap si riduce in modo significativo.

Ma non si chiude.

Resta una discrepanza che il doppio conteggio non spiega: i ricavi Meta sono ancora più alti di quelli reali, in misura minore ma comunque significativa. Questa volta non è un errore tecnico da correggere, è un meccanismo di attribuzione che funziona esattamente come è progettato per funzionare, e che continua a produrre un numero che non corrisponde alla realtà del business.

Ne parlo nel prossimo episodio.