Il catalogo Meta non riconosce i prodotti di PrestaShop? Controlla ID, varianti e Pixel

Se gli eventi di PrestaShop non corrispondono ai prodotti nel catalogo Meta, confronta l’identificatore completo dell’offerta con il valore inviato in content_ids. Contano il prefisso, il separatore e il numero della combinazione. Per l’integrazione, gli identificatori 812, ps_812-41 e ps_812_41 indicano stringhe diverse, anche se una persona può associarli alla stessa scheda prodotto.

Questa guida aiuta a verificare la collaborazione tra il feed prodotti e il Pixel. Gli esempi sono dimostrativi, senza dati dei clienti. Non sono uno screenshot dell’account pubblicitario né una conferma dei risultati della campagna.

Catalogo, Pixel e Conversions API svolgono compiti diversi

Il catalogo contiene le offerte: identificatori, nomi, immagini, prezzi e disponibilità. Il feed è uno dei modi per fornire questi dati. Il Pixel invia eventi dal browser, ad esempio la visualizzazione di un prodotto o l’aggiunta al carrello. Conversions API consente di inviare eventi dal lato server.

Un catalogo importato correttamente non dimostra che gli eventi facciano riferimento alle offerte giuste. La presenza di un evento di acquisto non dimostra invece che ogni prodotto di quell’acquisto abbia una corrispondenza nel catalogo. Per prima cosa, definisci quale parte della connessione stai diagnosticando.

Controlla anche di stare guardando il catalogo giusto e la fonte eventi corretta. Con più negozi, un vecchio Pixel o un feed di test, si possono confrontare dati tecnicamente corretti ma provenienti da configurazioni diverse.

Esempio: un prodotto, due combinazioni

Supponiamo un prodotto con ID 812 e le combinazioni 41 e 42. Il feed esporta le varianti come offerte separate con il prefisso ps_ e un trattino. Per la prima combinazione, l’identificatore è quindi ps_812-41.

Il controllo più semplice consiste nel copiare il valore dell’offerta elaborata e dell’evento in due righe. Confrontali carattere per carattere. Non rimuovere il prefisso “superfluo” prima di aver stabilito a cosa fanno riferimento le altre integrazioni.

Cosa è stato verificato nei moduli PrestaDev?

Nel codice di Facebook Pixel Pro 1.4.5 è disponibile la scelta del metodo di costruzione dell’ID e del prefisso opzionale. Uno dei percorsi crea l’ID prodotto unito all’ID combinazione con un trattino, un altro usa il trattino basso. Esistono anche modalità basate su altri campi. È questa la configurazione da confrontare con l’esportazione effettiva, non da scegliere solo in base al nome.

Il codice verificato del feed Meta 2.9.2, durante l’esportazione delle combinazioni, salva g:id nella forma prefisso + ID prodotto + trattino + ID combinazione. Per questa impostazione, la variante ps_812_41 inviata dal Pixel non sarà identica a ps_812-41 nel feed. In questo percorso, il feed salva il g:item_group_id comune come ID prodotto senza prefisso.

Questa è una conferma del modo in cui i dati vengono costruiti nelle versioni di codice indicate, non una prova di corrispondenza su uno specifico account Meta. Dopo aver modificato le impostazioni, bisogna comunque verificare il file generato, l’importazione del catalogo e l’evento reale.

content_ids e content_type devono essere coerenti

content_ids contiene gli identificatori legati all’evento. content_type definisce il modo di riferirsi ai prodotti o ai loro gruppi. Non bisogna sostituire product con product_group solo per far sparire un messaggio: questo cambia il significato degli identificatori a cui l’evento fa riferimento.

Nell’esempio discusso, scegliamo l’offerta specifica della variante e content_type: "product". Un set di dati semplificato per la visualizzazione della variante appare così:

{
  "content_ids": ["ps_812-41"],
  "content_type": "product",
  "value": 129.00,
  "currency": "PLN"
}

Questo è un frammento di dati di un evento di esempio, non un codice di implementazione completo né una richiesta API. I tipi dei campi content_ids, content_type, value e currency possono essere verificati nell’SDK ufficiale Meta — CustomData. Nella diagnostica di un account specifico, controlla anche i messaggi attuali del Gestore eventi.

Dopo aver cambiato variante, esegui un nuovo test

L’ID corretto alla prima apertura della pagina non basta. Il tema può cambiare variante senza ricaricare il documento. L’integrazione degli eventi dovrebbe usare i dati corrispondenti all’azione attuale, invece di restare sulla combinazione predefinita.

1. Scegli un prodotto con almeno due combinazioni presenti nel feed.
2. Annota i loro identificatori completi dal file e dal catalogo dopo l’importazione.
3. Apri il prodotto in una sessione di test controllata, con le corrette impostazioni di consenso.
4. Controlla i dati dell’evento relativo alla prima variante.
5. Cambia combinazione e aggiungi la variante selezionata al carrello.
6. Confronta ID, quantità, valore e valuta dell’evento con il carrello attuale.
7. Verifica che la stessa azione non venga inviata in aggiunta da una seconda installazione del Pixel, ad esempio tramite un altro modulo o un tag manager.

Non interpretare l’assenza di un evento come un errore del catalogo prima di aver verificato i consensi, il blocco degli script e la configurazione della fonte eventi. Anche l’invio dei dati tramite server richiede una corretta configurazione della privacy; CAPI non dovrebbe essere trattata come un modo per aggirare la decisione dell’utente.

Valore e valuta sono un controllo separato

Un ID identico non conferma l’importo corretto. Per l’evento prodotto, controlla il prezzo della combinazione selezionata e, per l’acquisto, la definizione concordata del valore dell’intero ordine. Non confrontare una singola unità con il totale del carrello né un importo netto con uno lordo senza aver stabilito come funziona l’implementazione.

La valuta deve corrispondere al valore inviato. In un negozio multivaluta, esegui un test separato dopo averla cambiata. Se i dati provengono dall’ordine, confrontali con l’ordine registrato, non con il prezzo di catalogo attuale letto successivamente.

Corrispondenza del prodotto e deduplicazione dell’acquisto

La deduplicazione riconosce due copie dello stesso evento inviate dal browser e dal server. Non serve a unire le varianti di prodotto. Nell’SDK ufficiale Meta è descritto che, per gli eventi corrispondenti, l’eventID del browser deve coincidere con l’event_id del server, e nel processo viene utilizzato anche il nome dell’evento. Fonte: Meta — descrizione di Event e setEventId.

Un event_id fisso uguale all’ID prodotto sarebbe un’idea sbagliata per acquisti diversi dello stesso prodotto. Allo stesso modo, identificatori evento coerenti non correggeranno un content_ids errato. Controlla queste due cose separatamente. Se stai analizzando anche GA4, usa la guida esistente sulla misurazione degli acquisti.

Da dove iniziare per migliorare l’integrazione?

Scegli un prodotto e conserva tre dati: l’ID nel negozio, l’ID importato nel catalogo e l’ID dell’evento. Definisci il formato, modifica l’impostazione corretta, aggiorna la fonte necessaria e ripeti il test. Non cambiare contemporaneamente prefisso, separatore, metodo di esportazione delle varianti e più installazioni del Pixel: questo renderà più difficile stabilire quale correzione ha risolto il problema.

Verifica la coerenza del formato ID in entrambe le integrazioni: Facebook Pixel Pro e feed prodotti XML per Meta. La loro configurazione dovrebbe derivare dallo stesso modello di catalogo. Una corrispondenza corretta è un elemento della qualità dei dati, non una garanzia di redditività delle inserzioni.

Verifica dei contenuti: 13 settembre 2026. Sono stati controllati il codice di Facebook Pixel Pro 1.4.5, del feed Meta 2.9.2 e le definizioni pubbliche nell’SDK ufficiale Meta. Non sono stati eseguiti pubblicazione né acquisto di prova sull’account pubblicitario del cliente.