Tip:
Highlight text to annotate it
X
DANNY HERMES: Bene.
Salve a tutti.
Benvenuti a questo webinar su come mantenere
sempre aggiornati i dati dei prodotti.
Mi chiamo Danny Hermes.
Lavoro alle relazioni con gli sviluppatori nel team di
Commerce di Google.
Ci occupiamo di far conoscere alcune delle nostre API,
di fornire assistenza e feedback e di altre cose,
come questo webinar.
Oggi sono con me Ali Afshar, Amanda Surya e Jasmine
[? Kahn ?], che saranno in chat per assistervi
se avete domande. Usate pure la chat per qualsiasi domanda.
Ci sarebbe anche l'opzione di alzare la mano, ma
il mio consiglio è di porre semplicemente la domanda e loro
faranno del loro meglio per rispondere a tutti.
Bene, ci siamo. Cominciamo.
Oggi speriamo di rispondere ad alcune importanti
domande sull'API dei contenuti.
Innanzitutto, di che cosa si tratta?
Secondo, qual è la nostra politica di aggiornamento dei dati e come
si applica all'API?
Perché l'API è la soluzione che fa per voi?
Metteremo a confronto e analizzeremo le differenze tra
l'API e i feed di dati.
Poi passeremo all'implementazione.
Come si usa l'API?
Nel frattempo, se avete domande su qualcuna delle
diapositive, inseritele nella chat e cercheremo di dare
una risposta esauriente.
Per cominciare, cos'è Content API for Shopping?
Per spiegarlo è necessario prima parlare di
Shopping.
Gli articoli finiscono in Google Shopping dopo essere
stati caricati su Google Merchant Center.
I dati dei prodotti vengono archiviati in Merchant
Center e da lì passano a Google Shopping
sul desktop.
Arrivano a Google Shopper su Google Mobile e a diversi altri
canali come Google Affiliate Network e Google
Commerce Search.
Supponete, ad esempio, di avere tre fotocamere digitali
da mettere in vendita.
Le caricate su Google Merchant Center. Poi
qualcuno va su Google
e cerca fotocamere digitali.
Ecco qui, evidenziate in blu, le tre fotocamere,
caricate in precedenza.
Quindi, come dicevo, per esporre un prodotto in Google
Shopping, è necessario prima caricarlo su Google
Merchant Center.
Esistono essenzialmente due modi per farlo.
I feed di prodotto di Google e quello di cui parleremo
oggi: Google Content API for Shopping.
Che cos'è Google Content API for Shopping?
La domanda a cui avevo promesso di rispondere.
È un'API basata su HTTP, REST e GData.
Che cosa significa?
Immaginate di avere una richiesta che contiene tutti i dati di prodotto
e potete usare i metodi di richiesta GET, POST, PUT o DELETE.
Questi sono i quattro metodi di richiesta di REST API.
La inviate alla nostra risorsa che si trova su
googleapis.com.
E noi forniamo una risposta che è un valore x.
Qualche cenno sul concetto di API.
Un'API è un modo per interagire a livello di programma
con elementi come i server di Google, o Google Merchant
Center, in questo caso.
In pratica si tratta di un modo che permette a due programmi
di parlare l'uno con l'altro.
Si differenzia quindi dai feed: un feed di dati è semplicemente un file
che contiene tutte le informazioni sui vostri prodotti.
È molto simile alla richiesta che viene inviata
con l'API dei contenuti, tranne che è un semplice
file TXT o XML.
In questi file gli attributi e le entità delineano
quali sono i dati specifici del prodotto.
Questi file, TXT o XML, vengono
caricati direttamente in Merchant Center.
Di conseguenza con Content API for Shopping gli sviluppatori
possono caricare a livello di programma quei dati su tutti
i siti di Google Shopping.
Vi permette di gestire gli account secondari nel caso in cui
abbiate un marketplace e gestiate più
venditori o più negozi affiliati.
Vi consente inoltre di impostare feed di dati.
Se volete creare combinazioni con l'API dei contenuti
e utilizzando i feed di dati, potete gestire tali
feed attraverso l'API.
Dopo che i vostri dati sono stati caricati, potete migliorare
il rendimento e configurare altri elementi tramite
la dashboard di Google Merchant Center.
Nella dashboard sono compresi i dati dei feed che
state utilizzando attualmente, i prodotti che avete caricato,
la qualità dei dati e altre statistiche di rendimento.
Con l'API potete inoltre tenere traccia dei clic.
Basta inviare una richiesta al link indicato in diapositiva,
non starò a leggervi tutto, ma
in sostanza dovete specificare una data d'inizio, una data
di fine e un particolare articolo, e otterrete
la tracciatura dei clic in quel particolare intervallo di date.
Questa è un'ulteriore funzionalità che abbiamo introdotto nell'API.
Vediamo adesso la politica di aggiornamento.
Quando qualcuno esegue una ricerca Google per trovare
un prodotto, se il prodotto è quotato a $ 102 come
si vede qui, l'utente si aspetta di poter comprare
l'articolo a $ 102.
Se il vostro prezzo base è diverso da quello del totale,
l'utente si aspetta che venga riportata la differenza.
E vorrà sapere quanto dovrà
pagare alla fine, giusto?
Nel caso di Google Shopping noi prendiamo in considerazione
tre persone.
Numero uno: l'utente.
Vogliamo che abbia la miglior esperienza possibile.
Vogliamo che riesca a trovare quello che cerca.
E vogliamo che trovi informazioni
precise su quel prodotto.
Numero due: i rivenditori, i commercianti.
Ci preoccupiamo di chi vende i prodotti perché anch'essi
abbiano un'esperienza positiva quando mettono a disposizione
i propri articoli attraverso Google Shopping.
E infine il numero tre: noi.
Vogliamo essere in grado di soddisfare tutte le parti in gioco.
Di conseguenza, la politica di aggiornamento dati di Google
afferma che quando un utente, eccetera eccetera...
Non sto a leggervi tutto il testo.
Se vi interessa leggere il testo intero potete usare il link
in fondo a questa diapositiva, goo.gl/C5P8X.
Riassume quello che pensiamo riguardo l'aggiornamento dei dati.
Per ora, vi basti ricordare che ci occupiamo prima dell'utente,
poi di voi, e infine di noi.
In che modo tutto questo si applica all'API dei contenuti?
Un esempio è il caso di quando vi sono frequenti variazioni
di prezzi e quantità e vorreste poter aggiornare
gli articoli in modo che Google Shopping rifletta queste variazioni.
Se utilizzate i feed di dati, potete aggiornare i dati un certo numero
di volte in un giorno.
E questo in qualche modo limita la frequenza di aggiornamento
dei prezzi e delle quantità.
Con la Content API for Shopping, potete farlo
nel momento esatto in cui i prezzi cambiano
e le variazioni sono subito evidenti.
Se poi avete un inventario di articoli molto, molto vasto
la manutenzione quotidiana e il caricamento dello stesso
pesante feed ogni giorno possono diventare ingombranti.
Invece, la strada da seguire può essere di caricare una sola volta
tutto l'inventario e usare poi l'API per i piccoli aggiornamenti.
Perché la API dei contenuti è la soluzione giusta per voi?
L'ultima diapositiva era molto chiara a questo riguardo.
Ecco una veduta aerea della differenza.
Come dicevo, i feed di dati di prodotto vanno bene per inventari
di piccole dimensioni e statici.
Piccoli e che vengono modificati di rado.
Naturalmente, trattandosi di file TXT o valori separati da virgole (CSV)
non è complicatissimo implementarli.
La Content API for Shopping, al contrario, è indicata per gli
inventari grandi, che cambiano rapidamente.
Per utilizzarla però, serve un po' di lavoro di sviluppo.
Uno dei maggiori vantaggi della API dei contenuti
è l'essere in tempo reale.
È velocissima per l'inserimento di nuovi prodotti.
Siamo nell'ordine di pochi secondi quando si tratta
di inserire un nuovo prodotto.
E si ottiene immediatamente una risposta da Google
che informa se il prodotto è stato inserito.
Analogamente, quando si aggiornano prezzo e quantità
degli articoli, non è necessaria ulteriore elaborazione.
Dopo che l'articolo viene caricato in Merchant Center, occorre
un minimo di elaborazione per assicurare la qualità
prima di poter offrire il servizio agli utenti, giusto?
Se avete già caricato un articolo e volete soltanto
aggiornare il prezzo o la quantità, l'aggiornamento è immediato.
Va a finire in quella che chiamiamo "express pipeline", la linea diretta.
È una parte rilevante dell'API dei contenuti, questa linea diretta
per le variazioni di prezzo e quantità.
L'API dei contenuti, inoltre, è automatica.
Pertanto il feedback restituito dall'API è nello stesso formato
della richiesta inviata.
È a livello di singolo articolo, quindi per ogni articolo che
provate a inserire, aggiornare o eliminare
ricevete una risposta.
E, come dicevo, le risposte sono immediate.
Nel momento in cui inviate la richiesta, ricevete
la risposta da Google, che vi informa se l'aggiornamento
ha avuto successo o meno.
Diversamente dai feed, in cui il riscontro arriva via email
ed è un riepilogo invece che una risposta
dettagliata articolo per articolo.
Ora confrontiamo e analizziamo le differenze di implementazione.
Come dicevo, con i feed di prodotto si gestiscono semplici file
separati da virgole, file TXT o anche XML,
se volete.
Non occorre essere uno sviluppatore per questo,
specialmente se si lavora su scala ridotta.
L'API dei contenuti, invece, richiede almeno
una minima conoscenza pratica del linguaggio XML.
E richiede anche qualche
competenza di sviluppo.
E, ovviamente, poiché aggiorniamo le specifiche e cambiamo
alcune cose dell'API per migliorare la vostra esperienza
e i dati che riusciamo a far visualizzare
agli utenti di Shopping, occorre un minimo di manutenzione
a ciò che inviate.
Detto questo, ci sono altre eccellenti caratteristiche
proprie dell'API dei contenuti che i feed non hanno.
La prima, come ho già accennato, è la possibilità di gestire
account secondari nel caso in cui gestiate venditori o
interi negozi.
Potete inoltre gestire i feed di dati nel caso in cui
vogliate caricare l'intero inventario con un solo feed di dati e poi
usare l'API dei contenuti per apportare piccole modifiche.
Potete gestire quello specifico feed di dati
mediante l'API dei contenuti.
Un'altra cosa importante: potete gestire richieste di inserimento
di nuovi articoli, di aggiornamento di quelli esistenti e di eliminazione
di altri, tutto in una sola richiesta in batch. Approfondiremo questo
aspetto nella sezione sull'implementazione.
Vediamo allora come si può usare.
Come funziona l'implementazione?
Ecco un contenuto XML.
Si tratta di una richiesta che contiene le informazioni per il
vostro articolo e che verrà inviata a Google.
Vediamo un titolo, altro testo strano sopra il titolo,
che non è altro che codice che
serve per inviarlo.
Ci sono i contenuti sull'articolo, il prezzo e le condizioni.
Tutti questi sono attributi importanti quando un utente
cerca un articolo.
Soffermiamoci un attimo sull'XML.
L'XML è un linguaggio di markup.
È molto simile all'HTML.
È un linguaggio strutturato.
Serve a trasportare dati che siano comprensibili per un computer.
Per questo motivo l'ultima diapositiva appariva complicata,
difficile da leggere.
Questo perché il linguaggio è progettato per essere compreso
da una macchina, e non per essere letto
così com'è da un umano.
Ecco un esempio di testo XML.
Qui definiamo una nota.
Diciamo che è per me da parte di Ali.
Ali inserisce l'oggetto "XML" e il corpo del testo...
"XML is the cat's meow!" (L'XML è favoloso!)
Si tratta in pratica di dati strutturati che un computer
è in grado di capire.
Una volta creati i dati così strutturati per un
determinato articolo, lo pubblichiamo con POST.
POST era uno di quattro metodi dell'API.
E lo pubblicate su un link preciso.
Inoltre lo pubblicate con autenticazione, perciò dovete
avere un token di autorizzazione, descritto nella documentazione.
E quando è stato inviato a Google, vi informiamo
sull'esito.
Ancora un paio di cose:
in alto abbiamo un codice HTTP, il 201, che
significa "successo".
E notate anche che in fondo c'è la riga "Location", posizione, relativa
all'articolo specifico che avete inserito.
Questo è importante.
Per adesso limitatevi a prenderne nota.
Quella posizione è un URL univoco per il prodotto che
avete inserito.
Questo URL contiene la radice, content.googleap
is.com/content/v1.
Questo è il vostro ID.
Ci sono poi un percorso e una proiezione che sono
anch'essi codice per l'API.
E poi c'è qualcosa di molto importante alla fine,
un ID di prodotto.
Questo ID di prodotto è unico per quel particolare prodotto che
avete appena inserito.
In seguito, dopo aver inserito il prodotto
nell'inventario, potrete usare questo link per tornare
indietro e aggiornare o eliminare il prodotto con quel link.
Per quanto riguarda la risposta 201, anche quando
date la posizione ricevete una risposta sull'esito.
Come dicevo, le risposte inviate da Google sono nello
stesso identico formato della richiesta.
Ecco un esempio di risposta:
Contiene praticamente gli stessi elementi: titolo, contenuto, ID.
Ma contiene anche elementi come "published" e "edited".
Provengono da Google e indicano il momento di caricamento,
l'ultima modifica dell'articolo, quando ci è stato inviato
e quando scade.
Per impostazione predefinita, dopo 30 giorni.
Prima che iniziate l'implementazione vera e propria
abbiamo preparato per voi
una demo interattiva online.
Per visualizzarla, cercate Content API for Shopping
con la ricerca di Google.
Nella demo è possibile eseguire tutte le operazioni.
Potete inserire nuovi articoli, aggiornare quelli esistenti
eliminarne, gestire account secondari, fare tutto
quello che potete fare con l'API in un'interfaccia
online facile da usare.
Quando inviate le richieste, la demo restituisce
le risposte che ricevereste, complete di stato HTTP
e di contenuti relativi alla risposta.
Esattamente gli stessi contenuti che ricevereste tramite l'API.
Al termine della demo, se decidete di eseguire
l'implementazione, abbiamo quattro librerie client open source
scritte in .net, Java, python e php.
Le librerie consentono di estrapolare alcune difficoltà, quali
il link dell'ID, in cui vi sono alcune parti che non sono
proprio facili da ricordare e di certo non sono del tutto
indispensabili per l'implementazione.
Sono state estrapolate, e le librerie client costituiscono
un metodo funzionale per fare richieste, autenticarsi e
fare tutto ciò che si può fare tramite l'API usando
linguaggi che i vostri sviluppatori conoscono già.
C'è un link in fondo a questa diapositiva se desiderate
ulteriori informazioni sulle librerie client.
Io stesso e alcuni degli altri sviluppatori, come Ali, che è in
chat, abbiamo collaborato intensamente a queste librerie
e continuiamo a farlo.
Sono supportate in gran parte da molti ingegneri di Google.
Sono comunque open source, perciò potete sempre
vedere il codice sorgente.
Potete vedere sempre gli aggiornamenti.
E, se lo desiderate, potete anche inviarne qualcuno.
Ho dato un'occhiata all'elenco degli ospiti e vedo
che ci sono persone che hanno inviato soluzioni per i bug
di alcune di queste librerie.
Se a qualcuno viene qualche idea...
Come dicevo, una delle grandi ulteriori caratteristiche
dell'API dei contenuti è che si possono inviare richieste in batch.
Osservate l'immagine a lato.
Qui mettete insieme prodotti e operazioni in una sola richiesta
POST. È fantastico.
Potete inserire più richieste e più operazioni in
una sola richiesta. As esempio, se volete eliminare
alcuni articoli e allo stesso tempo aggiornarne altri, è possibile farlo.
Se ad esempio volete inserire un nuovo articolo e allo stesso tempo
cambiare il prezzo di un altro, è possibile farlo
con un'operazione in batch.
Al momento le operazioni in batch hanno dei limiti.
Ogni richiesta può essere al massimo di un megabyte.
Potete però comprimerla con gzip o come preferite
per ridurne le dimensioni.
Riceverete una risposta, proprio come per un normale inserimento
o aggiornamento.
Anche questa sarà nello stesso formato in cui l'avete inviata
e con l'indicazione individuale di errore o successo per
ogni prodotto.
Uno dei vantaggi è che, invece di inviare 100
richieste per 100 articoli, potete inviare una sola richiesta.
E potete risparmiare sul volume della vostra richiesta.
Per la prossima grande caratteristica di implementazione
dell'API dei contenuti devo fare una
premessa.
Quando l'abbiamo aggiunta, avevamo in sospeso una modifica
per la specifica del feed.
Molti di voi forse sanno a che cosa mi riferisco.
Il 22 settembre abbiamo cambiato la specifica del feed
per consentire una migliore esperienza agli utenti
tramite Shopping.
Alcune cose che venivano inviate tramite
l'API dei contenuti erano valide prima del 22 settembre, ma
non lo sarebbero più state dopo quella data.
Volevamo offrirvi un modo per essere avvisati per tempo.
Il flag di avviso è un semplice flag che potete aggiungere
alla fine di un URL a cui inviate una richiesta
di inserimento, aggiornamento o qualsiasi operazione di modifica
dello stato che cambi l'inventario.
Quando aggiungete il flag,
qui lo vedete in grassetto alla fine del link,
dicevo, quando includete il flag alla fine di una richiesta,
la risposta non solo indicherà l'esito positivo o negativo,
ma anche gli avvisi su particolari elementi che potrebbero
portare a un esito negativo.
Oppure, nel caso in cui consigliamo un attributo che
però non è indispensabile, fornirà un avviso che mostra la
raccomandazione.
Sulla scia dei flag di avviso abbiamo anche un
flag "dry-run", il test di prova.
Il test di prova è come una sandbox.
Si tratta di una prova generale.
Consente di inviare una richiesta come se si volesse
aggiornare i dati o modificarli senza di fatto
dover inserire i dati,
senza dover di fatto modificare nulla.
Si ottiene la stessa identica risposta che si avrebbe
se fosse stata inviata una richiesta reale, solo che
niente viene di fatto modificato.
Si tratta di un passo avanti rispetto alla demo interattiva online, ma
è nello stesso stile.
Vi offre un modo per provare l'implementazione prima
di avere un effetto reale sui dati dei prodotti in
Merchant Center.
Un'altra interessante funzionalità: un uso importante dell'API in generale
ma che lo è in particolare per i commercianti e i rivenditori.
Se avete un sistema aziendale di pianificazione delle risorse,
un sistema ERP, ogni volta che aggiungete, inserite o modificate
un prodotto, potete di fatto avere un riscontro
a livello di programma per tali azioni sul sistema ERP e inviare
una chiamata a Content API for Shopping perché esegua una
modifica analoga nell'inventario di Google Merchant Center.
In questo modo potere mantenere il vostro sistema di inventario
aggiornato con il nostro sistema di inventario.
Spero che via sia piaciuto quello avete sentito oggi.
Se vi interessa andare avanti
abbiamo una community attiva online.
È un gruppo di Google.
Potete trovarla cercando Content API for Shopping in Google
Gruppi.
Oppure, seguite questo link.
Io stesso leggo il forum e molti dei nostri ingegneri
lo consultano per tenersi informati.
È sempre possibile cercare nelle risposte, perciò se
qualcuno ha già posto la stessa domanda, potete
eseguire una ricerca e consultare la risposta e magari
aggiornare la vostra implementazione di conseguenza.
Se vi interessa un supporto più personalizzato,
vi invito a contattare il vostro gestore account.
Sono disponibili anche altre opzioni.
E infine la documentazione, che seguo io stesso. Sono molto
scrupoloso nel tenerla aggiornata così come lo sono nel tenere voi
il più possibile informati. Potete consultarla all'indirizzo
code.google.com/ api/shopping/content.
Non dovete memorizzare questo indirizzo.
Basta che cerchiate Content API for Shopping
su Google. È il primo link.
Il primo risultato della ricerca.
Infine, se desiderate altro feedback oltre alle Domande e risposte,
potete raggiungermi tra una settimana per l'ora di ricevimento
in un videoritrovo di Google + il 3 novembre.
Posso fornirvi altre informazioni a posteriori anche per quanto
riguarda le persone.
Se inoltre desiderate inviare feedback direttamente su questo
webinar, abbiamo un link apposito.
Potete seguire il link breve, goo.gl/7PjFA
da cui potrete inviare i vostri commenti sul
webinar di oggi.
Se ci sono altre domande, chiedete pure.