Un codice QR può portare alla pagina prodotto corretta e mostrare comunque l’immagine del prodotto sbagliata. Il motivo più frequente non è la scansione, ma una filiera di distribuzione degli asset poco solida: un nome file viene confuso con un’identità di prodotto, una grafica promozionale sovrascrive il packshot neutro oppure una vecchia variante della confezione resta raggiungibile tramite lo stesso URL.
A luglio 2026 GS1 ha ratificato il Product Image Standard 5.0. La nuova versione principale integra nello standard la linea guida separata per la condivisione e la distribuzione. In questo modo acquisizione, archiviazione, denominazione, metadati, diritti di utilizzo e distribuzione tecnica non sono più descritti in documenti distinti. Per produttori, distributori e gestori di destinazioni QR è una buona occasione per trattare le immagini dei prodotti come dati anagrafici versionati, invece che come semplici file decorativi.
Cosa cambia davvero nella versione 5.0
Lo standard non introduce un nuovo diritto sul prodotto né impone l’utilizzo di un determinato sistema di gestione delle immagini. È un insieme di regole GS1 per immagini digitali associate a prodotti e condivise tra organizzazioni. Secondo il registro delle modifiche, nella release 5.0 i contenuti esclusivi della “GS1 Product Image Sharing/Delivery Guideline” sono stati integrati nello standard esteso per le immagini. Inoltre, denominazione, struttura e formulazioni sono state uniformate. Il catalogo di riferimento GS1 indica la versione 5.0 con data di modifica 17 luglio 2026.
Il cambiamento decisivo risiede quindi meno in un nuovo formato di file che nel modello complessivo. Un’immagine non viene creata solo per un singolo negozio online. Viene fornita da un provider di immagini, elaborata da più destinatari e potenzialmente distribuita tramite distributori, pool di dati, pagine prodotto, app o accessi QR. Lo standard collega la qualità dell’asset alla questione di come i destinatari possano raggiungere in modo affidabile il file corretto.
Separare il master asset dal derivato web
GS1 raccomanda di archiviare le immagini dei prodotti come file master di alta qualità e ricchi di informazioni. Da questi master si possono derivare i formati e le dimensioni per i diversi canali. Si evita così che ogni destinatario ridimensioni o elabori nuovamente un file web già compresso.
Nella pratica questo significa lavorare su due livelli. Nel repository interno degli asset si trova un master asset approvato, ad esempio un TIFF di alta qualità o un altro formato sorgente adatto. Il livello di distribuzione genera da questo derivati JPEG o PNG per il web, le applicazioni mobili e i feed di dati prodotto. Un derivato può essere rigenerato; la sua associazione funzionale, validità e origine non devono però cambiare.
Il modello riduce anche le varianti contraddittorie. Quando una confezione viene aggiornata, la nuova immagine riceve un proprio stato di approvazione. I vecchi lotti o mercati possono continuare a fare riferimento alla versione precedente, finché questa rimane valida in quel contesto. Sovrascrivere automaticamente il file mantenendo invariato l’URL sarebbe tecnicamente comodo, ma comprometterebbe la tracciabilità.
Nome file, prodotto e asset sono tre identità
Lo standard GS1 utilizza nomi file strutturati, che possono contenere, tra l’altro, la GTIN del prodotto rappresentato, nonché il tipo e lo scopo dell’immagine. Chiarisce inoltre che questo nome file non è un identificatore GS1 del file immagine stesso. La GTIN identifica il prodotto commerciale, non l’asset digitale. Se si deve identificare univocamente come documento digitale un file immagine non commercializzato, lo standard indica a questo scopo il Global Document Type Identifier, in breve GDTI.
Questa separazione è importante per i modelli di dati. Un prodotto può avere molte immagini: vista frontale, vista laterale, confezione, dettaglio, applicazione, rappresentazione della sostenibilità o immagine del codice 2D stampato. Al contrario, un’immagine promozionale può mostrare più prodotti. Una relazione “Il prodotto ha un URL immagine” non è quindi sufficiente nel lungo periodo.
Un oggetto asset solido richiede almeno un ID interno proprio, la GTIN o l’ID prodotto associato, il tipo di immagine, lo stato di approvazione e una versione. Se necessario, si aggiungono GDTI, lingua, Consumer Product Variant, angolazione e stato della confezione. Il nome file resta utile per lo scambio e la ricerca degli errori, ma non è l’unica fonte attendibile.
Un file immagine ha bisogno di un URL diretto e stabile
Nella logica del Global Data Synchronisation Network, le immagini dei prodotti non vengono distribuite come file binari nel record. Vengono invece trasmessi link alle immagini raggiungibili. La versione 5.0 descrive a questo scopo la distribuzione tramite un URL condiviso. Ogni file dovrebbe essere raggiungibile direttamente; tra gli errori noti rientrano link non funzionanti, formati danneggiati o inadeguati, protezione con password e pagine nelle quali l’utente deve navigare manualmente fino all’immagine corretta.
Questa immediatezza è altrettanto importante per le destinazioni QR e le API dei dati prodotto. Un URL dovrebbe fornire esattamente un asset in un formato definito, non una galleria o una richiesta di autenticazione. Il server dovrebbe restituire un tipo di contenuto corretto, mantenere sotto controllo i reindirizzamenti e distribuire in modo affidabile la stessa risorsa a ogni richiesta ripetuta.
Ciò non significa che ogni URL prodotto possa offrire una sola immagine. Un GS1-Digital-Link-Resolver può rendere individuabili più risorse tipizzate associate a un’identità di prodotto. Le risorse immagine devono comunque avere destinazioni univoche. Il resolver gestisce selezione e collegamento; il sistema degli asset resta responsabile del file, della versione e delle autorizzazioni.
I metadati determinano quale immagine è corretta oggi
La versione 5.0 introduce un ampio elenco di metadati. Comprende, tra gli altri, GTIN, nome del prodotto e del marchio, tipo di immagine, nome file, data di creazione, inizio validità, data di scadenza, numero di versione, titolare giuridico, diritti di utilizzo, lingua e data della verifica della qualità. Anche il testo alternativo è previsto come metadato facoltativo.
Non tutte le aziende devono compilare subito ogni campo. Tuttavia, cinque decisioni non dovrebbero mai essere contenute solo nel nome file: quale prodotto è rappresentato? Quale ruolo ha l’immagine? In quali mercati e lingue può comparire? Da quando a quando è valida? Chi può modificarla o inoltrarla?
In particolare, le date di inizio e fine impediscono di mostrare packshot errati durante una transizione. Un’immagine futura può essere già distribuita senza diventare visibile prima della data di approvazione. Dopo la scadenza può essere rimossa automaticamente dalle visualizzazioni dei clienti senza eliminare il record storico. È più preciso che sostituirla manualmente nel giorno stabilito.
I diritti di utilizzo fanno parte del processo di distribuzione
Un’immagine tecnicamente raggiungibile non è automaticamente libera da utilizzare. Lo standard descrive limiti tipici: spesso i destinatari possono ridimensionare proporzionalmente le immagini o convertirle in un altro formato. La modifica di testo e lingua, l’utilizzo in un territorio errato o la visualizzazione prima o dopo il periodo concordato possono invece essere inammissibili.
Per questo l’API delle immagini non dovrebbe limitarsi a fornire un file. Dovrebbe almeno rimandare a un record con titolare, profilo dei diritti, validità e contesto consentito. Prima della pubblicazione, un distributore può così verificare se l’asset è approvato per paese, lingua, canale e periodo. Se mancano indicazioni sui diritti, l’organizzazione ha bisogno di una regola predefinita consapevolmente definita, non di un’ipotesi implicita.
La multilingua non è un suffisso aggiunto al file in un secondo momento
Lo standard prevede indicazioni linguistiche nel nome file quando un set di immagini dipende dalla lingua. È particolarmente importante per packshot, immagini illustrative e claim che contengono testo visibile. Una nuova versione linguistica è funzionalmente un asset distinto; non dovrebbe essere creata tramite elaborazione automatica dell’immagine in un’altra lingua se ciò modifica le informazioni sulla confezione o le approvazioni.
Anche i testi alternativi richiedono contesto. Lo standard GS1 li presenta come metadati, mentre il W3C-Decision Tree per i testi alternativi distingue se un’immagine sia informativa, funzionale, ridondante o puramente decorativa. Un packshot neutro su una pagina di dettaglio prodotto richiede quindi una descrizione diversa dalla stessa immagine inserita in un link o accanto a informazioni testuali completamente identiche.
Per una pagina QR multilingue, il testo alternativo dovrebbe derivare dal contesto dei contenuti nella lingua specifica. Un testo descrittivo archiviato centralmente può fungere da punto di partenza, ma non dovrebbe essere copiato senza criterio in tutti i canali.
Anche l’immagine di un codice 2D richiede una gestione delle versioni
Lo standard definisce un tipo di immagine tecnico specifico per i codici a barre 2D, tra cui i codici QR con GS1-Digital-Link-URI e GS1 DataMatrix. Per queste immagini indica una dimensione minima di 600 per 600 pixel e uno schema di denominazione strutturato. Allo stesso tempo, GS1 avverte che le immagini dei codici 2D possono essere scansionate in qualsiasi momento da partner o consumatori e devono essere mantenute aggiornate quando cambia il contenuto collegato.
Questo aspetto va distinto dal controllo della qualità di stampa di un codice. Un’immagine ad alta risoluzione non garantisce che il codice effettivamente stampato su una confezione curva, lucida o danneggiata sia scansionabile. Nel processo degli asset deve quindi essere chiaro se un file sia un originale di produzione, una foto documentale o una rappresentazione illustrativa del codice.
Un test pratico di accettazione per gli URL delle immagini
Prima dell’approvazione, l’organizzazione non dovrebbe controllare solo l’aspetto visivo. Un test automatizzato può verificare che l’URL sia raggiungibile senza autenticazione, fornisca il tipo di contenuto immagine previsto, rispetti le dimensioni minime e non reindirizzi a una galleria HTML. Un hash o un ID di versione mostra se il file distribuito sia cambiato senza una nuova approvazione.
Il test funzionale completa quello tecnico: GTIN e la variante di prodotto devono corrispondere, tipo di immagine e lingua devono essere corretti, il periodo di validità deve coprire il momento della distribuzione e i diritti devono autorizzare il canale di destinazione. Per le immagini informative si verifica inoltre la presenza di un testo alternativo adeguato. Per un codice 2D è necessaria anche una scansione reale del campione di produzione.
Si crea così una filiera piccola ma completa: master asset approvato, derivato riproducibile, associazione univoca all’asset, URL diretto, metadati leggibili dalle macchine e validità monitorata.
La conseguenza per i progetti QR e di dati prodotto
Il GS1 Product Image Standard 5.0 chiarisce che le immagini dei prodotti non sono allegati aggiunti alla fine di un progetto dati. Hanno una propria identità, un ciclo di vita, diritti e caratteristiche qualitative. Chi archivia solo un percorso file accanto alla GTIN perde queste relazioni al più tardi alla prima modifica della confezione, della lingua o della campagna.
Per destinazioni QR, feed di dati prodotto e futuri passaporti digitali di prodotto è quindi utile un registro degli asset che pubblichi le immagini con lo stesso livello di controllo riservato alle altre informazioni prodotto. Il codice QR resta il punto di ingresso. Che dietro di esso appaia l’immagine corretta, valida e utilizzabile dipende da una filiera degli asset gestita in modo ordinato.
Fonti
GS1 Product Image Standard, Release 5.0, luglio 2026
