Tip:
Highlight text to annotate it
X
DANNY HERMES: OK.
Hallo iedereen.
Welkom bij dit webinar over het up-to-date houden
van uw productgegevens.
Ik heet Danny Hermes.
Ik werk bij ontwikkelaarsrelaties en ben lid van het commerciële
team hier bij Google.
We geven informatie over bepaalde API's,
bieden hulp en feedback, en organiseren webinars
zoals nu.
Vandaag word ik bijgestaan door Ali Afshar, Amanda Surya en Jasmine
[? Kahn ?]. U kunt met ze chatten voor hulp bij de vragen
die u heeft. Maak er gebruik van!
Er is een optie voor het opsteken van uw hand, maar
gebruik deze liever beter niet. Stel gewoon uw vraag en ze zullen
deze zo goed mogelijk beantwoorden.
Laten we nu dus maar snel beginnen.
Vandaag hopen we een paar belangrijke vragen te
beantwoorden over Content API.
In de eerste plaats: wat is het?
En ten tweede: wat houdt ons beleid voor het up-to-date houden van gegevens in
en hoe wordt dit toegepast op uw API?
Waarom is de API geschikt voor u?
We gaan een vergelijking maken tussen
de API en gegevensfeeds.
En we gaan het hebben over de implementatie.
Hoe kunt u uw API gebruiken?
Als u vragen heeft over een van de dia's,
kunt u ze in de chat plaatsen en dan krijgt u hopelijk
een snel antwoord.
Om te beginnen: wat is de Content API for Shopping?
Als we deze vraag willen beantwoorden, moeten we het eerst hebben
over Google Shopping.
Artikelen die zijn geüpload in het Google Merchant Center,
komen uiteindelijk terecht in Google Shopping.
Uw productgegevens worden opgeslagen in het Google Merchant
Center en gaan van daaruit naar Google Shopping
op het bureaublad.
Behalve in Google Shopper op Google Mobile komen de gegevens ook terecht in
nog een paar andere kanalen zoals Google Affiliate Network en
Google Commerce Search.
Stel dat u drie digitale camera's heeft
die u wilt verkopen
en u uploadt ze naar het Google Merchant Center, en
vervolgens gaat iemand naar Google en
zoekt naar digitale camera's.
Dan ziet u hier, in het blauw, de drie camera's die u heeft
geüpload.
Dus, zoals ik al zei, een artikel in Google Shopping
moet dus eerst worden geüpload naar het Google
Merchant Center.
Er zijn twee makkelijke manieren om dat te doen.
Via Google Product Feeds en waar we het hier over gaan hebben:
de Content API for Shopping.
Wat is dat dan, de Content API for Shopping?
Dat is de vraag die ik nu ga beantwoorden.
Dit is een API, gebaseerd op HTTP, REST en GData.
En wat is dat dan?
U heeft een verzoek met al uw productgegevens en u
kunt daarvoor get, post, put en delete gebruiken.
Dit zijn de vier werkwoorden die worden gebruikt voor REST API.
U verzendt dit naar onze resource op
googleapis.com.
En wij geven een antwoord in de vorm van een x bedrag.
Nu wat meer over een API.
Een API is een manier waarop programma's communiceren
met dingen als Google-servers of in dit geval met
Google Shopping.
Kortom, het is een manier waarop twee programma's
met elkaar praten.
Feeds, of gegevensfeeds, zijn daarentegen bestanden
die de informatie over uw producten bevatten.
Deze lijken op het verzoek dat met de
Content API wordt verzonden, behalve dat het hier slechts gaat om een
plat tekstbestand of XML-bestand.
Deze bestanden bevatten kenmerken en entiteiten met
specifieke informatie over uw productgegevens.
Deze tekstbestanden of XML-bestanden worden
rechtstreeks geüpload naar het Merchant Center.
Met de Content API for Shopping kunnen ontwikkelaars
die gegevens dus via een programma uploaden naar alle
Google Shopping-sites.
Hiermee kunt u subaccounts beheren
als u een marketplace heeft en meerdere verkopers of
meerdere subwinkels beheert.
En u kunt hiermee ook al uw gegevensfeeds instellen.
Als u dus naast de Content API ook gegevensfeeds wilt gebruiken,
dan kunt u deze feeds beheren
via de API.
Nadat uw gegevens zijn geüpload, kunt u het dashboard
van het Google Merchant Center gebruiken voor prestatiemetingen en
kunt u ook andere dingen configureren.
Op dit dashboard ziet u gegevens over de feeds
die u momenteel gebruikt, de producten die u heeft geüpload, de
kwaliteit van de gegevens en andere prestatiestatistieken.
Met de API kunt u ook klikken bijhouden.
Als u bijvoorbeeld een verzoek heeft naar de link hier in de dia
-- en ik leg u hier nu niet alles uit maar alleen
het belangrijkste -- dan kunt u een begin- en einddatum
en een specifiek artikel opgeven, en daarmee kunt u dan de
klikken bijhouden voor dat datumbereik.
Dat is een extra handig foefje dat we hebben opgenomen in de API.
Dan gaan we nu verder met het beleid voor up-to-date houden.
Wanneer iemand Google Zoeken gebruikt om een bepaald
product te zoeken, en de prijs van het product is $ 102, zoals u
hier ziet, dan verwacht de gebruiker dus dat hij het artikel
inderdaad voor $ 102 kan kopen.
Als uw basisprijs verschilt van de totaalprijs,
dan verwacht de gebruiker dat dit verschil duidelijk wordt aangegeven.
De gebruiker wil tenslotte weten wat hij uiteindelijk gaat
betalen, toch?
Bij Google Shopping willen we het drie groepen
mensen naar de zin maken.
Ten eerste, de gebruikers.
We willen dat ze de best mogelijke ervaring hebben.
We willen dat ze kunnen vinden wat ze zoeken.
Een we willen dat ze nauwkeurige informatie krijgen
over deze producten.
Ten tweede denken we aan de verkopers en dealers.
We houden rekening met de mensen die goederen verkopen,
omdat we willen dat ook zij een goede ervaring hebben bij
de transacties met hun goederen in Google Shopping.
En ten slotte, onszelf.
We willen gewoon dat alle partijen tevreden zijn.
Kortom, het beleid voor up-to-date houden van Google
stelt dat wanneer een gebruiker komt, blah, blah, blah --
Ik ga hier nu niet alles voorlezen.
U kunt het beleid lezen via de verkorte link
onder aan deze dia: goo.gl/C5P8X.
Hierin vindt u alles over ons beleid voor het up-to-date houden van gegevens.
Bedenk wel dat we in de eerste plaats aan de gebruiker denken,
dan aan u, en ten slotte aan onszelf.
Wat heeft dit nu te maken met de Content API?
Als u bijvoorbeeld prijzen en hoeveelheden heeft die
vaak wisselen, dan is het handig als u uw artikelen in
Google Shopping kunt updaten met de laatste wijzigingen.
Met feeds kunt u maar een paar keer
per dag updaten.
En hierdoor kunt u ook uw prijzen en hoeveelheden
maar beperkt updaten.
Als u de Content API for Shopping gebruikt,
kunt u prijswijzigingen
meteen doorvoeren.
En als u een enorme hoeveelheid artikelen heeft,
kan het bijhouden en uploaden elke dag
nogal een moeizaam karwei zijn.
Met de API kunt u uw voorraad in een keer
uploaden en hoeft u vervolgens alleen kleine updates uit te voeren.
Dus waarom is de Content API geschikt voor u?
Dat heeft u vast al begrepen op de laatste dia.
Hier ziet u een globaal overzicht van het verschil.
Zoals gezegd, feeds voor productgegevens zijn handig voor
kleine productvoorraden
met weinig transacties.
En omdat we het hebben over platte tekstbestanden of door komma's
gescheiden tekstbestanden, kost het niet veel moeite om te implementeren.
De Content API for Shopping is daarentegen geschikt voor grote
voorraden met veel transacties.
Hierbij komt echter wel wat ontwikkeling kijken.
Een van de mooiste dingen van de Content API
is real time.
Nieuwe producten worden razendsnel ingevoegd.
Wanneer u een nieuw product plaatst,
duurt het maar een paar seconden.
En u krijgt onmiddellijk een antwoord van Google
of het product is opgenomen of niet.
Als u de prijzen en hoeveelheden van artikelen
bijwerkt, zijn er ook geen extra bewerkingen vereist.
Nadat een artikel is geüpload in het Merchant Center, zijn
er wel wat extra bewerkingen nodig om de kwaliteit te waarborgen
die we onze gebruikers willen bieden.
Als u een artikel al heeft geüpload en alleen
een prijs of hoeveelheid wilt updaten, gebeurt dit meteen.
Dit is wat we de 'snelle pijplijn' noemen.
En de snelle pijplijn voor wijzigingen van prijzen en hoeveelheden
is een van die sterke punten van de de Content API.
De Content API is ook geautomatiseerd.
Dus de feedback van de API heeft dezelfde indeling
als het verzoek dat u heeft verzonden.
Alles gebeurt per artikel, dat wil zeggen dat u voor elk afzonderlijk
artikel dat u invoegt of bijwerkt of verwijdert,
een antwoord krijgt.
En, zoals gezegd, u krijgt onmiddellijk antwoord.
Op het moment dat u een verzoek doet, krijgt u
al antwoord van Google zodat u weet of het bijwerken
is gelukt of niet.
Bij feeds krijgt u feedback via een e-mail en
vaak is dit slechts een overzicht in plaats van een antwoord per artikel
dat ook nog eens dezelfde indeling heeft.
Laten we nu de implementatie eens vergelijken.
Zoals gezegd, bij productfeeds gaat het om eenvoudige door komma's
gescheiden bestanden of platte tekstbestanden, of zelfs XML-bestanden
als u dat wilt.
Hierbij heeft u geen ontwikkelaar nodig, vooral
niet bij kleinschalige toepassingen.
Bij de Content API heeft u ten minste
minimale praktische kennis nodig van XML.
En u moet ook wel wat ervaring
hebben als ontwikkelaar.
En als we de specificaties bijwerken
en iets aan de API veranderen om u een betere ervaring te bieden
of de gegevens te verbeteren die we aan de gebruikers van
Google Shopping aanbieden, dan is er natuurlijk soms wel
wat onderhoud vereist aan de dingen die u verzendt
De Content API heeft daarom een paar handige extra functies
die feeds juist niet hebben.
De eerste is, zoals al genoemd,
dat u subaccounts kunt beheren als u onderliggende verkopers heeft
of hele winkels moet beheren.
U kunt gegevensfeeds ook beheren als u uw hele voorraad
wilt uploaden met één gegevensfeed en vervolgens
de Content API wilt gebruiken om kleine veranderingen aan te brengen.
Een dergelijke gegevensfeed
kunt u beheren via de Content API.
Een andere handige functie is dat u verzoeken om nieuwe artikelen
te plaatsen, bestaande artikelen bij te werken en bepaalde artikelen te verwijderen
allemaal kunt verwerken in één groot batchverzoek. Maar daarover
heb ik het later nog bij de implementatie.
Hoe kunt u dit alles nu gebruiken?
Hoe werkt de implementatie feitelijk?
Hier komt wat XML bij kijken.
Het is een verzoek met informatie over het artikel
die naar Google wordt verzonden.
We hebben dus een titel en nog wat andere informatie
die nodig is voor
de juiste verwerking.
Er is content over het artikel, de prijs, de voorwaarden.
Allemaal kenmerken die belangrijk zijn wanneer een gebruiker
naar het artikel zoekt.
Laten we nog wat nader ingaan op de XML.
XML is een opmaaktaal
en lijkt op HTML.
Het is gestructureerde taal,
met gegevens die door een computer kunnen worden begrepen.
De vorige dia was misschien wat minder
duidelijk om naar te kijken.
En dat komt omdat deze was bedoeld voor een computer,
en in deze vorm
niet was bedoeld voor een mens.
Hier is een voorbeeld van XML
met een definitie van een notitie.
We zeggen dat deze voor mij is en afkomstig is van Ali.
Ali geeft het onderwerp op als XML en de hoofdtekst --
wel, dat is XML.
Het gaat dus echt alleen om gestructureerde gegevens
die een computer kan begrijpen.
Nu we deze gestructureerde gegevens hebben voor een
bepaald artikel, kunnen we dit posten.
Posten is een van die vier werkwoorden die worden gebruikt voor de API.
En hier post u naar een bepaalde link.
En u post met verificatie, dus u heeft een verificatietoken
nodig. Dit wordt in de documentatie beschreven.
En nadat dit naar Google is verzonden,
krijgt u antwoord zodra het aankomt.
Nog een paar dingen --
Bovenaan is een HTTP- code, hier 201, wat betekent
dat de verzending is gelukt.
Onderaan ziet u een plaats voor het
artikel dat u heeft ingevoegd.
Dat is belangrijk.
Let hier even goed op.
Dit is de plaats voor een unieke URL van het product
dat u heeft ingevoegd.
De basis van deze URL is content.googleap
is.com/content/v1.
Dat is uw id.
Er is een pad en een projectie en nog wat
elementen voor de API.
Aan het einde ziet u iets belangrijks:
de product-id.
Deze product-id is uniek voor dit specifieke product
dat u zojuist heeft ingevoegd.
Later, nadat u dit product in uw voorraad heeft ingevoegd,
kunt u die link gebruiken om terug te gaan en het
product te updaten of verwijderen.
Wanneer u het antwoord 201 ziet, en een locatie opgeeft, krijgt u
dus weer een antwoord.
Zoals gezegd, de antwoorden van Google hebben precies
dezelfde indeling als het verzoek.
Hier ziet u een voorbeeld.
U herkent weer dezelfde elementen: titel, content en een id.
Maar het bevat ook dingen als 'gepubliceerd op' en 'bewerkt op'.
Dit zijn dingen van Google over wanneer u het artikel heeft geüpload
en voor het laatst heeft bewerkt en wanneer u het naar ons heeft verzonden
en wanneer het verloopt.
Standaard is dit 30 dagen.
Voordat u zich nader verdiept in de details van
de implementatie, kunt u een interactieve online demo
bekijken die we hebben gemaakt.
Gebruik Google Zoeken en zoek naar Content API for Shopping en u
zult het vinden.
Met de demo kunt u in feite alle bewerkingen doen.
U kunt hiermee nieuwe artikelen invoegen, bestaande
artikelen updaten of verwijderen, subaccounts beheren en verder alles
wat u met de API kunt doen in een gebruiksvriendelijke
online interface.
Wanneer u verzoeken maakt, krijgt u de antwoorden die u anders
ook zou hebben gekregen, zowel het antwoord met de HTTP-status
als de content van dat antwoord.
Het is precies dezelfde content als die van de API.
Als u dit alles heeft uitgeprobeerd en besluit
over te gaan tot de implementatie, dan kunt u gebruikmaken van vier
open source-clientbibilotheken in .net, Java, python en php.
Dankzij deze bibliotheken kunt u een aantal moeilijkheden vermijden,
zoals de id-link met onderdelen die niet zo makkelijk zijn te onthouden
en die ook niet per se nodig zijn
voor de implementatie.
Dit is opgelost met de clientbibliotheken en ze zijn
dan ook een prima hulpmiddel om uzelf te verifiëren en alle andere
dingen te doen die u ook met de API zou doen
in een van de talen die uw ontwikkelaars al kennen.
Onder aan de dia ziet u een link die u kunt gebruiken
als u meer wilt weten over deze clientbibliotheken.
Ikzelf en een aantal andere ontwikkelaars, zoals Ali die
hier ook meedoet, hebben veel bijgedragen aan deze bibliotheken
en dat doen we nog steeds.
Ze worden grotendeels ondersteund door veel technici van Google.
Maar ze zijn open source, dus u kunt altijd de broncode
bekijken.
U kunt ook updates zien
of zelf een update voorstellen.
Als ik de gastenlijst hier bekijk, zie ik dat
sommige mensen al voorstellen hebben ingediend om bepaalde fouten
op te lossen in deze bibliotheken
Dus als iemand een idee heeft...
Een van de handige extra functies van de
Content API is, zoals gezegd, dat u batchverzoeken kunt verzenden.
Let op de afbeelding hier aan de zijkant.
U bundelt producten en bewerkingen in één
verzoek om te posten. Dat is hier zo goed aan.
U kunt meerdere producten en meerdere bewerkingen in één
verzoek plaatsen. Dus u kunt tegelijkertijd artikelen verwijderen
en andere bijwerken.
Of een nieuw artikel invoegen en de prijs van een ander artikel
veranderen met een
batchbewerking.
Batchbewerkingen zijn wel beperkt.
Elk verzoek kan ten hoogste één megabyte groot zijn.
Maar u kunt gzip of zip of dergelijke gebruiken om
de grootte te verminderen.
U krijgt dan weer antwoord net als wanneer u normaal een artikel invoegt
of bijwerkt.
En deze antwoorden hebben natuurlijk weer dezelfde indeling
en geven per product aan of
ze zijn verwerkt of niet.
Het voordeel hiervan is dus dat u niet 100 verzoeken
hoeft te sturen voor 100 artikelen, maar kunt volstaan met één verzoek.
En u kunt dit opslaan in uw volume voor verzoeken.
De volgende nuttige implementatiefunctie van
de Content API die ik wil bespreken, behoeft een toelichting
voordat ik verder ga.
Toen we dit hebben toegevoegd, waren we in afwachting van een
gewijzigde specificatie voor feeds.
Velen van u weten dit waarschijnlijk al.
Op 22 september hebben we de specificatie voor feeds
gewijzigd om een betere ervaring voor gebruikers
te bieden met Google Shopping.
Dus bepaalde dingen die via de Content API
worden verzonden, waren geldig vóór 22 september,
maar zouden daarna ongeldig worden.
Daarom zochten we naar een manier u van te voren te waarschuwen.
De waarschuwingsmarkering is een eenvoudige markering die u
kunt toevoegen aan het einde van een URL wanneer u een verzoek verzendt voor invoegen
of een update of elke andere bewerking waardoor de status verandert
of uw voorraad verandert.
En wanneer u deze markering
-- hier vet weergegeven aan het einde van deze link --
toevoegt aan het einde van een verzoek,
dan geeft het antwoord niet alleen aan of de bewerking is gelukt of niet,
maar krijgt u ook waarschuwingen over bepaalde zaken die mogelijk
leiden tot fouten.
Of bijvoorbeeld in het geval waar we aanraden een kenmerk
te gebruiken hoewel dit niet is verplicht, ziet u een waarschuwing met deze
aanbeveling.
We hebben nog een soortgelijke markering, de
zogenaamde testmarkering.
Deze markering is een sandbox.
En het is letterlijk een testmarkering.
U kunt hiermee een verzoek verzenden alsof
u uw gegevens updatet of wijzigt,
zonder dat u feitelijk gegevens invoegt.
Dus zonder dat u feitelijk ook maar iets verandert.
U krijgt dan precies hetzelfde antwoord als u zou krijgen
wanneer u een echt verzoek verzendt, behalve dat in feite
niets wordt veranderd.
Dit is dus net zoiets als de
interactieve online demo.
Het is een manier om een implementatie te testen voordat
dit gevolgen heeft voor uw productgegevens in het
Merchant Center.
Er is nog een praktische functie, die eigenlijk inherent is aan een API,
maar die hier met name handig is voor verkopers en dealers.
Als uw bedrijf een ERP-systeem (enterprise resource planning) gebruikt,
dan kunt u in uw ERP, via een programma, reageren telkens wanneer een product
wordt ingevoegd of gewijzigd, en
u kunt de Content API for Shopping
aanroepen om een soortgelijke
voorraadwijziging door te voeren in het Google Merchant Center.
Op die manier kunt u uw eigen voorraadsysteem up-to-date
houden met ons voorraadsysteem.
Ik hoop dat wat u vandaag heeft gehoord u is bevallen.
Als u aan de slag wilt gaan, kunt u
deelnemen aan onze online community.
Het is een Google Discussiegroep.
Zoek naar Content API for Shopping in Google Discussiegroepen
en u zult het vinden.
Hier ziet u een link.
Ikzelf lees het forum en veel van onze technici
volgen het forum ook.
De antwoorden zijn doorzoekbaar, dus als
iemand eerder al dezelfde vraag heeft gesteld, kunt u de vraag
zoeken en het antwoord bekijken zodat u uw eigen
implementatie desgewenst kunt aanpassen.
Als u meer specifieke ondersteuning wilt, neemt u
contact op met uw accountbeheerder.
We hebben ook nog wat andere opties.
Verder heb ikzelf wat documentatie die ik bijhoud
en altijd up-to-date houd en die ik graag zoveel mogelijk
met iedereen wil delen. Deze documentatie is te vinden op
code.google.com/ api/shopping/content.
U hoeft deze URL niet te onthouden.
Ga naar Google en zoek naar Content API for Shopping,
dat is de eerste link.
En het is het eerste resultaat.
Als u feedback wilt die niet is te vinden in Q & A,
kunt u me over een week gedurende één uur onder kantoortijd
vinden in een hangout op 3 november.
Ik kan u dan wat meer
informatie geven.
Als u direct feedback wilt geven over dit webinar,
kan dat via de volgende verkorte link:
goo.gl/7PjFA.
Daar kunt u feedback geven
over het webinar van vandaag.
Heeft u nog vragen? Ga uw gang!