---
type: "blog"
id: 24
url: "https://prestadev.pl/it/blog/news/catalogo-meta-prestashop-id-varianti-pixel"
markdown_url: "https://prestadev.pl/it/markdown/blog/24.md"
title: "Il catalogo Meta non riconosce i prodotti di PrestaShop? Controlla ID, varianti e Pixel"
description: "Verifica la corrispondenza dell'ID prodotto in PrestaShop, nel feed Meta e nell'evento Pixel. Prefissi, varianti, content_ids e controllo separato della deduplicazione dell'acquisto."
language: "it"
published: "2026-09-13 20:06:03"
updated: "2026-09-13 20:06:03"
author: "Patryk Marek"
category: "News"
---

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

Il prodotto è nel catalogo, ma l'evento non corrisponde? Confronta il prefisso, il separatore e il numero della combinazione. Guarda l'esempio di ID del feed e del Pixel corrispondenti.

**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.

 ![Lo stesso identificatore prodotto nella scheda del catalogo e nell’evento del Pixel](https://prestadev.pl/modules/ph_simpleblog/featured/24.jpg) 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`.

 | Punto | Combinazione 41 | Combinazione 42 | Cosa confronti |
| --- | --- | --- | --- |
| PrestaShop | Prodotto 812, combinazione 41. | Prodotto 812, combinazione 42. | Identità del prodotto e della variante selezionata. |
| Feed: g:id | ps\_812-41 | ps\_812-42 | Identificatore dell’offerta specifica nel catalogo. |
| Evento: content\_ids | \["ps\_812-41"\] | \["ps\_812-42"\] | Se indica l’offerta corrispondente all’azione dell’utente. |
| Gruppo nel feed di esempio | 812 | 812 | Il gruppo comune delle varianti; non sostituisce automaticamente l’ID dell’offerta. |

 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](https://github.com/facebook/facebook-php-business-sdk/blob/main/src/FacebookAds/Object/ServerSide/CustomData.php). 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](https://github.com/facebook/facebook-php-business-sdk/blob/main/src/FacebookAds/Object/ServerSide/Event.php).

 | Identificatore | Esempio dimostrativo | Cosa deve riconoscere |
| --- | --- | --- |
| content\_ids | \["ps\_812-41"\] | Il prodotto o la variante legati all’azione. |
| eventID / event\_id | purchase\_demo\_1001 | Un singolo evento di acquisto specifico inviato tramite due canali. |

 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](https://prestadev.pl/pl/blog/baza-wiedzy/ga4-prestashop-brak-zakupow-pomiar-sprzedazy).

 ## 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](https://prestadev.pl/pl/facebook-pixel-pro-modul-dla-prestashop.html) e [feed prodotti XML per Meta](https://prestadev.pl/pl/export-produktow-xml-dla-dynamicznych-reklam-facebook-do-prestashop.html). 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.