Track
Pixel e integrazioni con le piattaformeTutorialIntermedio

Meta Conversions API nella pratica: event_id, dati di abbinamento con hash e codici evento di prova

Come far funzionare in parallelo il Pixel di Meta e la Conversions API senza conteggi doppi — con i campi esatti, le regole di hashing e il flusso degli eventi di prova dalla documentazione di Meta.

Di
Redazione Track
Pubblicato
Ultima revisione
Tempo di lettura
4 min di lettura

Punti chiave

  • Meta unisce un evento del pixel e un evento del server solo quando entrambi condividono event_id ed event_name entro la finestra di deduplicazione: genera l'ID una sola volta e passalo a entrambi i percorsi.
  • Gli identificatori in user_data vengono normalizzati e poi sottoposti a hash SHA-256; fbc, fbp, IP e user agent restano in chiaro, e fbc/fbp vengono acquisiti solo dopo il consenso al marketing.
  • La modalità ibrida dà a Meta l'unione delle chiavi di abbinamento: e-mail e telefono con hash dal sistema degli ordini più fbp/fbc dal browser.
  • Un test_event_code tiene gli acquisti di prova nella scheda Eventi di prova e fuori dai report; ogni tentativo e ogni codice di errore è visibile nell'Event Debugger.

L'endpoint in una riga

POST https://graph.facebook.com/{version}/{pixel_id}/events con un token di accesso di un utente di sistema e un body JSON che contiene un array data di eventi. Track fissa centralmente la versione della Graph API (v25.0 al momento della stesura) e registra quando l'endpoint è stato verificato l'ultima volta rispetto alla documentazione di Meta.

I campi che contano

Ogni oggetto evento contiene:

  • event_namePurchase, Lead, AddToCart, InitiateCheckout, CompleteRegistration, Subscribe, StartTrial, Contact, Schedule, Search, ViewContent, PageView oppure un nome personalizzato
  • event_time — secondi Unix, al massimo di sette giorni prima
  • event_id — la tua chiave di deduplicazione
  • event_source_url — l'URL della pagina
  • action_sourcewebsite per gli eventi web
  • user_data — dati di abbinamento (vedi sotto)
  • custom_datavalue, currency, content_ids, contents, order_id, num_items

Opzionale ma prezioso in fase di test: test_event_code al livello superiore del body. Gli eventi inviati con un codice di prova compaiono in Gestione eventi → Eventi di prova e non vengono conteggiati nei report.

Deduplicazione: stesso event_id, stesso event_name

Meta unisce un evento del pixel e un evento del server quando entrambi condividono event_id ed event_name e arrivano entro una finestra dello stesso ordine di grandezza dell'evento stesso (Meta documenta 48 ore). Due conseguenze:

  1. Genera l'ID una sola volta, nel momento in cui avviene l'azione, e passalo sia alla chiamata del pixel (fbq('track', 'Purchase', {...}, { eventID: id })) sia al payload del server.
  2. Mantieni identici i nomi degli eventi su entrambi i percorsi. Un Purchase dal browser e un purchase dal server sono due eventi.

Track lo fa per costruzione: l'SDK genera un ID dell'evento sorgente, replica la chiamata del pixel con quell'ID e il worker invia lo stesso ID in event_id.

user_data: cosa sottoporre a hash e come

Meta richiede l'hashing SHA-256 degli identificatori personali dopo la normalizzazione:

CampoNormalizzazione prima dell'hashing
emsenza spazi ai margini, tutto minuscolo
phsolo cifre, prefisso internazionale incluso, senza zeri iniziali né segno più
fn, lnminuscolo, senza spazi ai margini, solo lettere
ctminuscolo, senza spazi né punteggiatura
zpminuscolo, le prime cinque cifre per gli Stati Uniti
countrycodice ISO a due lettere, minuscolo
external_idqualsiasi ID stabile, con hash

Non sottoposti a hash: client_ip_address, client_user_agent, fbc, fbp. Il valore fbc si costruisce dal parametro URL fbclid come fb.1.{timestamp}.{fbclid}; fbp è il cookie _fbp impostato dal pixel. L'SDK di Track li acquisisce entrambi solo dopo il consenso al marketing e li inoltra esclusivamente a Meta.

Cosa premia la «qualità dell'abbinamento degli eventi»

Meta valuta ogni evento in base a quante chiavi di abbinamento ha ricevuto. Quelle con l'effetto maggiore sono e-mail con hash, telefono con hash, fbp/fbc ed external_id. Gli eventi server provenienti da un sistema degli ordini portano di solito e-mail e telefono; gli eventi browser portano fbp e fbc. Inviare entrambi i percorsi con lo stesso event_id dà quindi a Meta l'unione delle chiavi — il motivo pratico per cui la modalità ibrida rende più di ciascun percorso preso da solo.

Il flusso di test

  1. In Gestione eventi apri il set di dati → Eventi di prova e copia il codice (per esempio TEST12345).
  2. Salvalo nelle impostazioni della destinazione; Track lo allega solo finché la destinazione è in modalità di test.
  3. Invia un acquisto di prova dalla procedura guidata. Il worker lo consegna e mostra la risposta di Meta (events_received: 1 e un fbtrace_id).
  4. Conferma l'evento nella scheda Eventi di prova con i parametri e le chiavi di abbinamento attesi.
  5. Disattiva la modalità di test; da questo momento gli eventi vengono conteggiati.

Le classi di errore che incontrerai

  • 190 / OAuthException — token non valido o scaduto: ruota il token dell'utente di sistema
  • 100 con sottocodice 2804 — parametro non valido: di solito un hash malformato o un action_source mancante
  • 4 / 17 / 32 / 613 — rate limit: Track attende con jitter e riprova
  • 5xx — temporaneo: viene ritentato; il circuit breaker mette in pausa la destinazione se l'errore persiste

Ogni tentativo, inclusa l'anteprima oscurata del payload, è visibile nell'Event Debugger — ed è da lì che parti quando manca un acquisto.

Fonti primarie

Documentazione e standard su cui si basa questo articolo.

  1. Meta — Conversions API: Using the APIdevelopers.facebook.com
  2. Meta — Customer information parameters (hashing)developers.facebook.com

Questo articolo ti è stato utile?

Redazione responsabile

Redazione Track

Prodotto e engineering

Le persone che costruiscono Track: engineer e analyst che lavorano ogni giorno su server-side tracking, strumenti per il consenso e integrazioni con i connettori.