NITIN MANGTANI: Welcome. I hope you’re having fun
at Google, are you? The tablets simply looked
awesome, so I’m sure you’re having double the fun now
with those tablets. Quick intros. My name is Nitin Mangtani. I’m a group product
manager at Google. I work in the commerce focus
area and I’m here today to talk about shopping APIs. And with me, also, a colleague
of mine, Ali, he’s going to join us later. So let me talk a little bit
about what we’re going to focus on today, and as you
walk out of the session, exactly will you learn? So I just wanted to set the
stage and talk about, what are the different innovations
Google is doing around shopping and shopping search? And then I’m going to switch
gears a little bit and we’re going to talk about, how does
it relate to the development community broadly? How can you collaborate with
Google and be part of the broader ecosystem? As we’re doing a lot of
innovations on the Google site and this is where shopping APIs
are, in some ways, the heart and soul of
our ecosystems and developer outreach. So we’re going to focus a
lot on shopping APIs. The shopping APIs have multiple
components, so we’ll talk both about them and how
they interact with the Google properties. We’ll try to show you a couple
of live demos and also go into details on the actual API and
the semantics of them. But before I do that, I just
wanted to step back and give you guys a little update on
what’s happening in the broader retail or the
shopping arena. So if you look at the retail
industry, the first online transaction happened maybe
a decade or 15 years ago. Someone took the credit card
and bought online. Now it’s been a long time since
we went from a purely shopping at the store to online
shopping, but if you look at some of the interesting
data points, what’s happening is that, even
after 15 years, a good portion, in fact a majority of
the shopping, still happens at a physical store. In fact, the data shows 90%
of the shopping happens on somebody’s store where a user
walks into the store and makes a purchase. What’s more interesting is that,
even though 90% of the shopping happens in a physical
store, close to half, 43% of those decisions, the purchase
decisions are made in the online world, which is even
before a user or a consumer walks into that store, he or
she has researched that product or that brand or
that retailer online and made that decision. So that’s why it’s so important
for the broader community to have that presence
in the online world so that, whether you are a
retailer, a brand owner, or you’re a developer, if you’re
thinking about shopping, it’s very important that you think
about what’s the online presence of your shopping
initiative. And last, but not the least,
there are a lot of data points made last year which are
predicting that the smartphones will outsell the
desktop computer sometime in 2012 or 2013. Guess what? It happened last quarter
of 2010. It didn’t even take until 2012
or 2013, which is a pretty interesting phenomena if you
look at the evolution of computing and some of the other
computing paradigms and their adoption. Mobile is one of the fastest
growing technologies, and what’s happening is, it’s
blending these worlds of what we used to call online shopping versus in-store shopping. These two worlds are getting
blended, which, from a consumer point of view,
doesn’t matter. You can start the search online
but actually purchase the transaction going
into the store. [? And ?] that mobile device is
bridging that gap. Because on the mobile device,
you can do the research and you can even find the stores
near you which carry that item, and then they will show
you the directions. So you can just drive to that
store and pick that item. So it’s a very interesting
dynamic which is changing how shoppers look at broader retail
industry, and how they are interacting with retailers
in general. So let’s look at some other
interesting things that are happening on the Google site. So I think most of you might be
aware of Google Shopping or Google Product Search. If you type in any product-related query on Google– and you can try this, for
example, digital camera– we would show you the
different cameras. We will also show you the
information about them: ratings, reviews, the price,
and the retailers that they can buy from. This application has been live
for a while, and I’m sure many of you might be already
playing with this. The interesting thing, which I’m
going to connect the dots pretty soon is, I’ll show you
how what you see here on the consumer side is related
to the shopping APIs. And how shopping APIs play an
important role in feeding this data to Google. So one of the APIs, which we’re
going to go in a lot more detail, it’s called
Content API, which is basically the heart and soul
of our infrastructure. And that’s how these items get
listed on Google Shopping. The next innovation we did is,
back in the days when you typed in a query, digital
camera, we would show you the same camera and the same image
multiple times, basically showing you all the retailers
that sell those products. And obviously, from a consumer
point of view, that wasn’t the best experience. So we improved the experience a
lot by creating something we call the product page, which
is, this particular camera, Canon Power Shot, is sold
by multiple retailers. In fact, 158 retailers, but
it’s is the same product. There’s no point showing that
image 158 times, or the description, or the ratings
and reviews. Because no matter whom you buy
this product from, the product remains the same. So we created this canonical
catalog pages for the products so that, as a consumer, as you
are typing in a query, we show you this product page. You can look at all the
information about the product and then, at the bottom grid,
you see all the retailers. We still show you the retailers
ratings, because that’s equally important. Once you know that this is the
right product to buy, you also want to know which is the right
retailer to purchase this product. So that’s where we show you that
information and then we show you the price and
other attributes. So that’s where the next evolution in Google’s shopping. The third thing, which I
mentioned to you, mobile is a pretty interesting paradigm. In fact, if I look at my own
personal behavior, and some of the shopping queries that we
see on Google, this is increasing at a much faster pace
than any other revenue. Because users are using shopping
and mobile as the primary conduit to
do the shopping. And at Google, we launched this
application called Google Shopper, which essentially
allows you to scan a barcode or an image and it will find the
product which matches the description or that UPC code. It will tell you all the
information about it. How many people have downloaded
Google Shopper? [UNINTELLIGIBLE] So for the rest of you,
please try it. So, it’s a free application and
it’s available on both on Android and iPhone. It’s pretty cool. It’s shows you the power
of what you can do with a mobile device. This is something which is my
personal favorite, which is mobile meets local. We went from desktop-based
shopping, to a canonical product, to mobile, and then
this is the ultimate nirvana where now, I can not only search
that product, but it tells me precisely that this
item is available on these stores near me. And in fact, we get– and this
is why the API is important– we get this real time inventory
feed from all these retailers so we can precisely
tell you whether this item is on the shelves at that
store or not. Because the opposite of it is,
you find a product, you like it, you drive to a store,
and guess what? That item is not available. And I call that phenomenon
anticipointment. I kind of felt this anticipation
like, I got the product, I want to buy it. You walk into the store. It’s not there and you
get disappointed. We wanted to make sure we
avoid that phenomenon of anticipointment, and wow the
users by giving them this perfect information and giving
them this assurance that this item is actually on the shelf
right now in a store near you. And then last, but not the
least, you can obviously click on Get Directions and it will
guide you to that store. What can be better than that? And this is really changing how people think about shopping. Because back in the days,
there was this clear distinction between what was
online shopping and what was shopping at the store. The reality is that there
is no such distinction. These worlds are merging. A lot of times users will walk
into the store, but complete the transaction in
the online world. Or vice versa, which is a more
common scenario, they will start their research online but
finish their transaction at a physical store. And there are various reasons
why they do so. And as a retailer, as an
e-commerce website owner, you want to make sure that you give
the best choice to the consumer, and let them
pick what’s most convenient for them. And this kind of local shopping
and mobile blends these two worlds perfectly. So what are Google’s shopping
APIs and how does it relate to all the innovations that I
showed you on google.com? So the shopping APIs
are essentially divided into two segments. So this is kind of my style
of drawing a simple architectural diagram. So bear with me as I try to
walk you through very bare bones components here. But if you look at the heart
of it, we have something called Google Merchant Center,
which is our webmaster kind of tools for uploading
data to Google. How many people are aware of
Google Merchant Center? OK, so this is pretty good. It looks like at least
half of the audience. But for those of you who are
not developers, Google Merchant Center is our simple
dashboard where you, as a developer, or if you’re working
for a retailer, can interact with it to upload the
items that you but sell on your website or in a physical
store near you. And what you see at the bottom
of this slide is two different avenues. So you can either upload
this data, what we call Product Data Feed. These are simple XML or Excel
files, and you can simply go to the Merchant Center and
click File Upload, and upload that file. Or you can use this new
API, which is the Content API for shopping. This API has much more tighter
libraries, that’s much more easier for a developer to
program against them and integrate back into
your system. Also the Content API
allows you to do more incremental updates. So one of the most common
requirements we see is to update price and inventory,
right? During the day, a retailer
changes its price multiple times. If you change your price from
$60 to $49, you want to make sure that that price is updated
within minutes. So the Content API allows you to
do that, as well as, if you run out of the stock with some
item, you can do so without uploading your entire
inventory. We can make those fine grained
incremental updates. So we’re going to talk a lot
about Content API today. But at this point, I just wanted
to give you a high level overview. And then, on the client site,
obviously, I showed you a lot of innovations on google.com,
which is the box Google Shopping represents. But what’s more interesting,
you can take those same innovations and power search on
your own e-commerce site. So we have an API called Search
API for Shopping, which allows you to take a lot of
innovations that are happening on Google to power
the e-commerce experience on your website. And also, that API allows you to
monetize the data inventory feed here at Google. So you can be a publisher,
what we call, at Google, Affiliate Networks. So you can be an affiliate on
the Google Affiliate Network and publish some of
these items. And this applies to anybody. You don’t need to
be a retailer. If you’re a website owner,
blogger, or publisher, you can leverage that API to monetize
your website better. So we’re going to talk about
both of these APIs in a lot more detail, and these
other two components. But at this point, let me
introduce to you, a colleague of mine, Ali. And he’s going to take
you through the details of Content API. Ali? Thank you. ALI AFSHAR: Thank you, Nitin. Hello everyone. Thanks for coming. As Nitin he said, I’m an
engineer working in Zurich on the shopping APIs. I work for Developer Relations,
and really, my goal is to help people use the APIs
and make sure that they’re successful with them. So let’s start. Well, hopefully, Nitin’s
explained this, but I just want to recap who should
be using the Content API for Shopping. Well anyone who sells anything
online, firstly, and that’s so that people can find your
product when they search on google.com and Google
Product Search. That’s the first thing. And secondly, as he’s told you,
and the research shows, that people do research their
purchases online even if they going to purchase offline. So for that reason, if you
sell things offline, you should have your products in
Google Shopping, using our Content API. So that equates to retailers. If you are a retailer, anyone? If you work for a retailer, if
you write software that a retailer uses, ERP systems,
online shopping systems, this is an API you should, in my
opinion, be interested in. Right. Let’s start from the
very beginning. I’m sorry if this is all very
basic information, but I just want to make sure everyone’s
on the same page. So they’re HTTP-based APIs, in
the same way that your web browser is. And we have a resource and
that resource has a URI associated with it. We make a request that’s
identical to a web request. That can be any one of the verbs
that we have, get, post, put, delete. There are others, but those are
the important ones we’ll be looking at today. And we get a response back, and
that response can contain the data in any of the data
formats, such as JSON and XML, which are the ones were going
to be using today. So if you’re familiar with
RESTful APIs, if you’ve heard of the concept REST, this is
all going to be a bit more obvious for you. But essentially, we have
resources, we make requests, and we get responses back. What is the data format like? Well, I said it was either
XML or JSON. And you do have a choice
with this API whether you use XML or JSON. The default format is XML, for
this API and that really suits the more enterprisey feel. Enterprises like using XML. It’s built on GData and the Atom
Syndication Format, so that we have a feed, corresponds
to a list of products, and an Atom
entry corresponds to an individual product. And inside there, we have the
various products attributes. You can see there the title,
the Atom title. And this is for an army knife,
a Swiss Army knife. I live in Zurich so we
know our knives. And you can repeat some elements
in that, so that’s a very high overview of that. And we’ll look at the individual
data model. So each product we have, each
product you give us, you send to us, is uniquely identified
by those four components you see there: the channel by
which you’re selling it, which is online. EN there, which is the language,
the country, U.S. and your SKU, your individual
code for that. So those four components are
stuck together to make the unique ID for the product. That’s worth knowing. Why? Because if you upload the same
product for a different country, or the same product
with a different language, that’s regarded by our system
as a different product. So inside that product, we
have various attributes. I’ve only got the title
one up there. And each product can belong
to a number of product categories. And we provide a taxonomy
for that that is fairly comprehensive, so it should
cover all your product needs. As you’ll see, we recommend
you use all of these. The schema itself. We have created a new namespace,
a couple of namespaces to add on to the Atom
namespace to extend what you can see. The title is the
product title. The content is the product
description. The link is the link to
the product page. That’s really important. We don’t host your product
information. We require a link from you– a URL– to a place where people can see information about that product. Now typically, you know what
I’m talking about. There’s an image there, there’s
the price there, you can click, Add to Cart, and
some product information. But we really require that. And then there are
some individual elements for our API. So the target country, that
comprises part of the ID that I said. The content language,
that’s the language of the content element. The condition, we do require you
to tell us the condition of the product, new, used,
or refurbished. Information about the price,
including currency, and some images, or one or more images. We do ask for one high quality
image, at least. So those are the important required
elements. There are many more, 30 or 40,
and they’re well documented. You can see the links
afterward. Right. Before I show the actual request
and response, I want to give you some tips for
getting your products higher in the ranking, OK? This is really important and
they’re all really, really common sense. So you’re saying, oh, but
that’s common sense. But actually, if you do all of
them, it will significantly improve your rankings. So firstly, fill out as many
fields as you can. Our user of this product, Google
Shopping, google.com, is the person trying
to find something. So it’s me trying to buy a
digital camera, or it’s you trying to buy something that
you want, a bicycle. Those are the users and we’re
really keen, at Google, to give users exactly what
they’re looking for, the best data. And we can give them that data
if you give it to us. So firstly, fill out as many
fields as you can. Secondly, use good
quality images. People love looking at stuff. We all love looking at stuff,
and if you can see something, you’re going to buy it. That’s a really, really strong
motivator to actually buy it. We do check that the images you
give us do exist. We do check that the product pages do
exist. We do check that the prices on the product page is
accurate to the information that you sent us. And if there are discrepancies
with those, that can adversely affect your rankings. Product identifiers. I very briefly mention
this here. Books have ISBN numbers,
products have UPC codes, and more recently there is
a g10 Code that is used by both of them. It’s a generalization
of both of them. Now if you give us these
identifiers, then we can accurately place your products
on one of those catalog pages. So we know that the digital
camera is the exact same digital camera, and that will
put you in that catalog page. And also, it’s very good for
your rankings as well. Product categories. People do like to search
by category. They do like to browse
products by category. And if you use our taxonomy,
then we can provide the results when people are
looking for them. Again, it’s all about the users,
all about the person who’s looking. So if you give us the
information, then we can index it accurately. Good titles and good
descriptions. This is my favorite one. Don’t write your titles
in all capitals. Use good punctuation. Ensure they’re well spelled. We do check all of these things,
and again, we want to give the user a good
experience. So we don’t want to show them
all capitals, so we won’t. And the last one is
more general. Include information about
tax and shipping. I’ve had the same experience. If I don’t know how much tax I’m
going to pay on a product, I just won’t even consider
buying from that site. If I don’t know how much it’s
going to cost to get it sent to me, I won’t even consider. And it’s so important. If you noticed, on Nitin’s
demonstration, with all the merchants, alongside reviews,
it had tax and shipping information. It’s that important that we
want to show that to users immediately, because it
can affect where they decide to buy from. So those are my tips. If you want to discuss
any of them in detail with me, please do. I’m around all day today
and tomorrow. So let’s get on to
the actual API. You saw there was a resource
in that that had a URI. There two types of resource
we use, mainly for our Content API. The first one is the
product endpoint. Now that is used for any
operation which is general for all the products
of a merchant. For example, if you want to
insert a product that’s not specific to a single product,
and so we would use this endpoint, or to retrieve a list
of all your products. Now that’s made up of a few
bits, the root URI. That’s the URI of the API. Then the merchant ID is only
one, two, three, four, five, and all merchants who have
signed up for the Merchant Center have an ID. The path and then
the projection. I won’t be talking about
the projection. It’s an advanced option
on how we return some extended parts of XML. You can read about that, and
again, that’s something I can talk to you about individually
if you’re interested. So that’s the product
endpoint. That’s where we send any request
which is general for the merchant. The second endpoint is a
specific endpoint for every single product. It’s identical up until the
point where we add on the end, the four part product ID that
I spoke about earlier. So you can see, it’s joined
by [? curl lines ?] and it’s made up of those four
segments that I spoke about. And when will we use
this endpoint? Well, if we have a specific
product operation, if you want to update the information,
if you want to delete the information, this is the
endpoint we’d use. So what we have online, is
it’s an [? arguable ?] code site, is an interactive
demo of this API. Now I find that the best way for
someone to get their feet wet, to warm themselves
up with the API. What it allows you to do is,
enter your values, either in a form, or as raw XML. You make the request and, I
don’t know if you can see with the resolution, but as I say,
I strongly recommend all of you to go and try this. It shows you the request you
make and then the response. All I’ve done is– because you
can’t see this too well– taken some segments out of
here so we can talk about them, specifically. You’ll see the link
for that later. Please use it. It’s really useful. So the first thing we want to
do is create a new product, upload a product to
Google Shopping. And this is probably the
most common use case. How do we do that? Well, we make a POST request, so
inserting products, always a POST request. And we make it
to the product URI, the feed URI for that merchant. You can also see that we pass
a couple of extra headers. The first one is the
authorization header. Now, all requests for this
need to be authorized. We’re using AuthSub here, but
it supports all of our authorization methods. And they’re talking about OAuth
and OAuth 2 here at the conference. So if you’re interested in that
part of it, please go and have a look at that. But all requests need to be
authorized because we can’t let anyone just manage
your information. And the last one is the
Content-Type, and we’re using application/atom+xml. And this is what the body of
the request looks like. So first thing you notice,
well, it’s XML and we’ve encoded it as UTF-8. Please feel free to encode it
as whatever you like as long as it’s UTF-8. No, no, as whatever you like. And then you see the entry
element that we have. We’ve got a few namespaces. I’ve left some out for brevity
and I’ve actually left out some required fields here. So what you would have is
slightly bigger than this. But you can see the title, the
Content-Type text, the SCID element, which is the SKU, the
condition element, the price, which has the units
of currency. The unit is required, and then
some tax information. Now tax is specifically
localizable. You can say, I want the tax in
California to be such and such, or I want the tax in the
zip code to be such and such, or in this city to be
however you like. So you can specify arbitrarily
complex tax rules there. And what do we get back? Well, we’ve just sent
the product. We’ve created a new product. Brilliant. And so we get back a
201 response, which means you’ve created. This is interesting. From a REST point of view, not
only have we created a new product, we’ve created a new
REST resource, a new place where you can do stuff. And so we get back
in the headers– a location header which shows
us our new resource with our new URI. So you can store that and use
that if you want to update the information later. And with that, we get a response
back that is an echo of our original request. So it
tells us that the fields we’ve added have been successful. And with a few others added,
such as, the published, which tells us that it’s been
published and the date and time, the APP edited,
that’s the Atom Publishing Protocol namespace. I’ve added here a couple of
elements that weren’t in the original POST request, which we
would have needed to have. And there you see, really
important, the link REL equals alternate element that is the
landing page for this product. This is the page that
people would go to. So that’s inserting products,
I think the most common use case. As you’ll see, you
can use this for updating products as well. But I’m just going to show you
how to update a product. Now this time, instead of doing
a POST request, we do a PUT request to the specific
product URI, which is there, and the same as the product URI
we just got back when we created it. Again, it needs to be authorized
and we need to provide the Content-Type
header. We send exactly the same body,
but it’s not exactly the same because you might be keen, and
notice that I’ve gone on sale and I’ve reduced my
price slightly. So if I want to update a
product, I send exactly the same as I would to insert
a new product with the additional information, but
this time I send it to the specific product URI with
a PUT request. And we get back a 200. We haven’t created
anything new. We’ve just updated. It’s just a simple 200 with,
again, the information that we echoed and we got back. The third important use case
is deleting products. Well, that’s really easy. We don’t send anything,
you really you get anything back, as a body. You just send a delete request
to the specific product endpoint, and you just get
the response back. And that’s how you
delete a product. One of our most important
features for this API is that we support batch processing. Now a batch is a set of
operations, each one with a project associated with it. So by operation, I mean you can
insert product A, you can update product B, you can
delete product C. So each product in a feed
comes with an operation. And the advantage of that is you
can put, firstly, hundreds in a single request. And so you
just saved the amount of requests you have to make. And that can go up to a megabyte
in size which is gzipped, so we’ll see a little
example of that. But if you’re like most
merchants– and most merchants don’t have 10 or 15 products,
they have hundreds and hundreds of thousands
of products. Some merchants here
have hundreds of millions of products. So if you batch them, that’s
really advantageous for you because you make
fewer requests. Also say we get individual
responses for each batch operation, so you will know
which ones succeed and you will know which ones fail, and
you will get the error information that you need. Let’s have a look at one. All batch requests are a POST to
the batch URI, which is the product feed with the
word batch attached on the end of it. So they’re all POSTs, it doesn’t
matter what kind of operation, because you will
specify the type of operation in the entries themselves. And here’s a batch body with
just one operation in there, so imagine there could
be hundreds in there. Again, it’s a feed at the top
level and its a simple entry exactly like our other entry. And my laser light is gone. You can see then there’s
the batch element. And that batch element has
an operation type and that type is insert. So this will insert this
product, if we send the batch. And when we send the batch,
we’re always going to get a 200 back, even if we send a
hundred operations that were all complete garbage and none
of them succeeded, we will still get a 200 back because the
batch itself did succeed. And this is what the response
looks like. Well, it’s identical to our
other responses, but it does have the addition, firstly, of
the batch operations that we had parsed and then,
importantly, the response code for that batch, which, in this
case, is the 201 created, identical to the response we
got back when we made the insert request. So
that’s batching. I recommend you all use it if
you’re uploading products. We also have real
time updates. Now, normally, when you upload
a product to Google Product Search, it takes a few hours. You’re thinking why, why does
that take a few hours? Well, we have to validate it. We have to make sure that the
page exists, the product is accurate, the information is
accurate, because we can’t risk people putting false
information, or we don’t want to risk that bad experience
for the user. So it takes a while to check. But the really important
information, and that is the price and the quantity, as in
your inventory of the stock. If you change that, we have
a special fast track. So that means, within– I’ve said five minutes but
it’s actually shorter– so almost immediately, that
result will be reflected in Product Search. That’s really great because as
Nitin said, people like to know when the product’s
in stock. In fact, they need to know. So it gives them the most
accurate information as quickly as possible, and people
are more likely to buy stuff off you. We also have other features. I’m just going to race
through this. Firstly, inserts for existing
items are updates. So if you try and insert the
same item twice, and by the same item, using that four part
ID, the second time won’t create a new item, it will
merely update the old item. OK, so that’s the quickest
way to update an item. The difference with a normal
update is that, in a normal update, if the product doesn’t
exist, you’ll get an error. You can’t update a product that
doesn’t exist. Whereas here, it would just go on and
create the product, so this is the quickest way of updating
your product information. We also have data feed API, not
to mention that you can upload your products
using data feeds. It’s a bit slower, it takes a
bit longer, but you can manage these feeds programmatically. You can say these are my feeds,
or these are the third party feeds who I manage. Here they are and this is
how you upload them. Also, we provide aggregator
accounts. You may have multiple accounts
underneath you. You may manage multiple
accounts. And to do that, we have a
specific API that manages products for those
subaccounts. And you can use them for a third
party if that’s the kind of business, if you’re in an
aggregator-type business. Think of the marketplaces. Just a little example of when,
just to put it into context. Now this is the simplest flow
you can have. So you have an ERP system. If you’re a normal retailer,
you have an ERP system, but when something changes, you send
a notification to your module that will handle this,
and that will make a single call to the Content
API for Shopping. You write it once and you just
leave it forever, and for the rest of time, your products
will be accurate in Google Product Search, all the
time, up to date. People can find them
and people will be able to buy them. So the Content API for Shopping,
an HTTP-based API based on Atom and GData
by default. Use it to manage your product
data for Google Product Search and Google Shopping, easy to
manage data feeds for yourself or third parties, and you
can manage subaccounts. So that’s that. I’ll get Nitin back up here to
talk about our other APIs. NITIN MANGTANI: Great. Thanks, Ali. Switching gears here a bit. So, so far you saw a lot of
innovations that were happening on Google Shopping and
Ali went into the details of how can you use Content API
to upload your items to Google so that it shows up on various
properties on Google, be it Shopper, Google Shopping,
and things like that. I want to switch gears here and
talk about the other side of our APIs, which is, once we
uploaded data to Google– and there’s so much innovations
happening on Google– how can you benefit from those
innovations and power your own e-commerce site with the search APIs that Google provides? The search API that we provide
for that is called Search API for Shopping. And the number one use case for
Search API for Shopping is something we call a Google
Commerce Search. This one is actually
a paid product. Google Commerce Search, which
allows you to power e-commerce experience on your
own website. Let me show you a live demo to
illustrate what exactly this product does, and how shopping
APIs are used. If I go to one of our customer’s
website, this is Baby Edge which is a pure-play
online e-commerce website, and the search here is powered by
the API, the search API, which is based on the items they
uploaded to Google. For example, if I’m searching
for a stroller, as you could see here, we leverage
all the features that you see on Google. So the first thing you see is
search auto-completion. So we are showing you these
suggestions: strollers for babies, strollers
with car seats. But then, what’s more
interesting, you also see instant, which is, you’re seeing
the actual results even before you finish your query. So literally, with three or four
keystrokes, we are able to predict what the user is
looking for and in subseconds, show him or her all the
products, with the images, the title, as well as the price. Now you can go ahead and finish
this query or you can pick one of these suggestions. And you can see that, as I’m
altering these suggestions, the actual search results
are changing. So this is all real time, kind
of Google Instant, but for your own retail website. At this point, if I hit enter,
I see a much more comprehensive search result, so
you see a lot more details now, whether this item
is in stock or not. But what’s more interesting
are the things on the left-hand side. So [? guests ?] of e-commerce, people not only
like to do a search, but they like to do more refined
searches. So it’s like I’m looking for a
stroller, but I want the brand to be Britax. So just by clicking on that
brand Britax, you can see now all the strollers are only
from the brand Britax. And similarly, you can further
refine and say I’m looking for a price between $300 to $500,
and now you can see only those products where brand is Britax
and the price is between $300 to $500. What’s cool about this is this
number, 200 milliseconds. Because when you’re building an
e-commerce site, the last thing you want is it
slows you down. The technology slows you down. You want to make sure that your
e-commerce site is not only fast, it’s interactive. Think about the experience when
you walk into the store. What you like about it. The things you like about when
you walk into a store is, somebody is speaking
back to you. And you want to make sure that
your website is fast enough and is interactive. And that’s why we have built
these features like Search as you Type and Instant, because
it looks like as if the website is talking
back to you. This is not like a static
website where you’re typing in your entire query, hitting
enter, and waiting five seconds before you see the
first search results. This is much more interactive,
more real time and this is all based on the Search
API for Shopping. The beauty about this model
here is that, because this retailer, Baby Edge, has already
uploaded their data items to Google so that it shows
up on Google Shopping, they can use that exact same
feed to power search on their own website. And there’s a product around
it– it’s called Google Commerce Search– which provides a lot
more features. And the actual product itself
is a paid product, but we do offer a [? double upper ?] API. It gives you around 2,500
requests per day, so if you want to build a quick
application or a prototype, you can do it, there’s
no charge for it. But once you use it
for production use, it’s a paid product. Let me show you a quick demo to
explain a little bit more, because I don’t have many slides
on Google Commerce Search, but just to
set the stage. This is one of the demos
we built for you. [VIDEO PLAYBACK] NARRATOR: Since the dawn
of time, people have engaged in commerce. In the Stone Age, cavemen
traded in rocks. At the height of the Roman
Empire, people bartered for chickens. Then came [UNINTELLIGIBLE] And finally, online shopping. This evolution in commerce got
us thinking about the future of retail, and that’s why we
built the all-new Google Commerce Search. It’s an e-commerce search
solution that makes buying easy, and selling,
very profitable. Here’s how it works. Let’s say you run
cavewheelhouse.com, a website that sells stone
caveman wheels. Buyers visit cavewheelhouse.com
to search for and purchase wheels. And with Google’s new Search as
you Type feature, they find relevant wheels in just
a few keystrokes. As the wheel merchant, you have
absolute control over the search elements the customer
sees on your web page. You can easily introduce
promotions for discounted tricycle wheels, high
performance racing wheels, and more. And have these automatically
displayed when your visitor enters a related search query. You can also designate
banner zones. You can even collaborate with
your colleague, the wheel marketer, and any other
caveman you desire. The results, wheel enthusiasts
find the exact wheel they’re searching for, and maybe
even something unexpected along the way. And if you have a cave wheel
house brick and mortar store with those items in stock,
Google Commerce Search even lets your shopper know
that their items are available nearby. By connecting visitors to
relevant products faster than ever before, your business can
sell many more wheels. Start the next era of your
e-commerce store with Google Commerce Search. [END VIDEO PLAYBACK] NITIN MANGTANI: Well I just
wanted to spend a few minutes explaining, it’s essentially an
e-commerce search platform and at the heart of it, it uses
the search API to power the complete e-commerce
experience on your website. So whether you are a retailer
with a brick and mortar store or you’re a pure-play online, or
you just have an e-commerce website, and you want to get the
full experience that you see on Google, you can do so
using this product and the actual API. Let me show you one last thing
before I move back to the slides and go into the
details of API. So let’s take one example. I want to show you what does it
take to build a new search engine if you have an
e-commerce website? So in this case, Forever 21,
which is one of our customers, they already upload
data to Google. So this is Google
Product Search. They’re already giving data
feed, and they’re actually using the new Content API ,
which Ali went on the details, to upload items to Google. So these are all items that
Forever 21 has already uploaded to Google. And let’s say if they wanted to
build a new search engine for their own website, all they
would do is, they would go to this wizard, Commerce
Search Creator, they put in their name, which is
Forever 21, select the language, country. This is the ID which we give it
to them, so every merchant has a unique merchant ID which
we give it to them. And this is a developer
key which they enter. At this point, you can go out
and create the search engine and I can finish it. And basically, once you have
created the search engine, you can try any of the
queries here. So if I’m trying, for example,
trousers, this is in real time, searching for data that
Forever 21 has already uploaded to Google. So without writing a single line
of code, we can generate a basic bare bones e-commerce
search engine for any of the retailers that have uploaded
data to Google. Now you can take the same
template and, obviously, put your own styling guidelines,
because you want to make sure that it’s unique to your taste
and audience and plug it into your website. And what’s more interesting is
that, on the left-hand side, we can actually go
and generate some code for you guys. So there’s some auto-generation
of code going here, which we can
also do that. Now, at the end result, what
you would see– and this is actually a true example– is if I go to forever21.com, and
they actually use Google Commerce Search, you can search
for any of these items. And you can see the UI and the
layout looks different than what was on that quick demo,
is because they could take that code, apply their styling,
and then power the experience on their
own website. And then, obviously, you can
further refine these search results, whether you’re looking
for knit tops and things like that. And this is, again,
powered by Google. So that’s the overview of
Google Commerce Search. I want to talk about one more
use case before I hand it back to Ali, to go into the details
of the Search API. The other use case, which is
pretty useful, is Google Affiliate Network. So let’s say you are
a publisher. You have a website or you have
a blog, and you want to monetize your website. One way to do that is that you
can use the data feed from Google to put the items that
are available from various retailers and you can,
basically, make money through the referral fee. So if there is a user who
clicks on that item and actually makes the purchase back
on the retailer’s site, we share the commission
with you. And what do you need to
do is two things. You need to sign up to become
a Google Affiliate publisher and then you need to request a
key, so that you can place these items on your website. Those are the two
main use cases. You’re either a developer
working with a retailer, or you are just a publisher and
you want to monetize your website better, you
can do so with the Google Affiliate Network. And as I mentioned to
you, it’s relatively straightforward. If you do a Google on Google
Affiliate Network, it will take you to the details
on how do you sign up. So with that, why don’t I ask
Ali to come back to the stage and walk you through the
Search API details. Ali? ALI AFSHAR: Thank you
again, Nitin. Right. The Search API for Shopping. As Nitin said, you use it to
get product search like results in a programmatic way. It’s much, much simpler than the
Content API for Shopping. Firstly, it’s only read only. We can’t send any information,
we’re only getting information. So all operations are Get
requests, and all operations go to a single URI resource. And that URI resource contains,
as part of it, again, the merchant ID, so
you’re getting products from the specific merchant. So all Get requests, all
to the same URI. The data format this time,
by default, is JSON. Again, you have a choice, but
the default format is JSON. Now why is this the case? Well, we feel that the
applications that would use this API would benefit from a
lighter data format, one that would run natively in a
browser, run on mobile platforms, and that’s the kind
of application that we think would use this API. Again, you can use XML
if you want to. The JSON is equivalent to the
XML, so we have attributes in the JSON that correspond to
elements in the XML itself. These are the main attributes,
and you can see there’s a big similarity with the ones we sent
for the Content API: the title of the product, the
content, the descriptions, the link, the home page
for the product. The country, that corresponds to
the target country, and the language, again, the
content language. We give all the other
information that you’ve provided, or the merchant has
provided, we give that back, too, in the condition element,
the price element, any numbers of images. So it’s the JSON format, and
this is just an example of what it looks like. So I’ve done a search there
for strollers and I got 513,000 results and this is just
the first one, and I’ve even cut off the description
because it would have gone on for ages. So this is the kind of result
that we get back. It’s just an example. Now to go through what
Nitin actually did. We provide options to the API
by providing URI parameters. Now Nitin’s search for a
stroller, I don’t know if you noticed, s, he typed,
then, s-t. Now each time he typed a
character, a web request was being made and they
looked like that. So the first one was just q
equals s, s-t, s-t-r, s-t-r-o, and each time he was getting
a response back. And that was being rendered in
the page and that’s what gives the instant results. So that’s how you do
that free text search using the q parameter. We also have structured
search results. You noticed he did a narrowing
his results down by the brand Britax, and we have the restrict
by parameter that you can pass most of the attributes
that you can have in there, and you can restrict
the operation. So if you want just the Britax
brand, you parse restrict by equals brand Britax. If you just want brand new baby
equipment, it’s probably likely, then you just
parse condition new. Also we have a method by which
we will rank the results that we’ll give back to you. So you don’t need to order
them yourself and that’s useful if there are
500,000 results. But you can rank by price, by
relevance of your results, and by the date published, in both
directions, so ascending and descending. One really cool feature of this
API is that we provide results diversification. When you’re doing a search, if
you search for a digital camera, you may notice that the
first 50 are all from a certain brand, or all from
a certain publisher. This allows us to say, I only
want one result from each brand, or I only want one result
from each retailer. And in this case, we pass the
parameter that we want, and then the number of results fit
that parameter, so I want one result for each brand. There are actually some other
ways that we can do structured search, and that’s all
in our documentation. This is just a quick overview. And there are other features,
as I say, and these features relate to cool Google
stuff that is good. Firstly, spelling. So if someone misspells the
product, we pick that up, and in our results, if you ask for
them, we give back a did you mean style thing for the product
they were actually looking for, and we give those
recommendations for how it should be spelled. Thumbnails. Remember I kept saying about
high quality images, why do we need high quality images? Because we create thumbnails
for you. We create any number of
thumbnails of any size up to 226 pixels. We will give them back to you. So, in your request, you parse
thumbnails equals– well I want four thumbnails– 6,428. Name them like that and the API
will create them and give you links back. Even cooler than that, if you’re
doing instant search, the thumbnail data will be
inlined in the response. So all you need to do,
then, is just render them straight back. You don’t need to make
additional requests to get the thumbnails. And that’s how you get that
instant result with the thumbnail images next to them. We also provide histograms
so you can get a spread of the data. You give us a number of slots,
I want price slots, and it will split it up into that
number, let’s say 10, and it will give you how many products
for each price slot. That’s useful if you want to
compact your prices with the whole ecosystem of prices. We provide field filtering,
which means we don’t always give back all the fields
in every response. You can specify which ones you
want and that’s useful for quick responses where you don’t
want the whole 40 line description, you just want the
title, you just want the pricing, you just want
the thumbnail. So you can specify that. And like all APIs, if we’re
returning hundreds of results, we’ll give you a way that you
can page the results. You can get the next hundred and
the next hundred and then the next hundred, if that’s
what you want to do. There are other features as well
and, again, they’re all documented, but it’s all about
trying to get the results back fast that you can display
them to your users. So that’s the Search
API for Shopping. A quicker run-through because
it’s a simpler API with just the one endpoint. It’s, again, HTTP-based. This time the default data
format is JSON, but you can use JSON or XML. And it loosely, it searches
products programmatically in the same way that you would do
if you were on Google Shopping or Google Product Search. You can use it for the Google
Affiliate Network, and you can use it for Google
Commerce Search. That’s the Search API
for Shopping. Right. That’s mostly all done. Thanks for bearing with me. To put my commerce hat on for
a second, I just want to discuss the two important
things in business. You guys are into business and
commerce because that’s why you’re here and no
somewhere else. So what’s the most important
thing in business, anyone? Well, obviously, making money. So, hopefully, we’ve shown you
how to make money by driving traffic to your site by
uploading products with the Content API for Shopping. The traffic is driven not just
through Google Shopping, it’s driven through google.com. People would type something in
google.com, and within a click, they will be on your site
if you use the Content API for Shopping. I’m just going to pause
there that because that’s really important. OK? That’s the first thing. Second most important thing
in business, anyone? Making more money. Thank you very much. I knew someone would know. So you can make even
more money. You can improve your conversion
rate by using Google Commerce Search. People will find what they’re
looking for immediately. And they will buy it because
you’ve got a good experience and that shows that when
people can find stuff, they buy it. You could make a little
bit, even more money if you’re a publisher. If you’ve got any content, you
can include results, products results, on your blog, on your
website, in your application that has product-related
stuff. And you will receive money when
people click on those, and [? converse ?] on those. So my most important
things in business. Thank you very much
for listening. We’ll take questions, and good
luck with all your ventures. If you do have questions, by
the way, come up to the microphone. It’s really important. NITIN MANGTANI: So we have 10
minutes or so, for questions, so if you guys can
please line up. Go ahead, [? sir. ?] SPEAKER 1: Does Google plan
to monetize the shopping themselves with ad words? NITIN MANGTANI: So the question
is, does Google plan to monetize shopping? It’s actually already
monetized. So if you go to Google Shopping,
there is ad words, just like Google, which
are paid placements. And then there are organic
results, which are free. So we don’t charge for Content
API, if you want to upload data to Google, but then you
can place ad words on that result set. SPEAKER 2: In terms of inventory
information, in stock, out of stock information,
and I think that, at this point, it’s not
a required field. Do you see that becoming
required in the near future? NITIN MANGTANI: So those two
things around inventory, one is your online availability. So we do want to know whether
this item is out of stock or is it available? And the second part is, your
in-store availability. So if you have both online
presence as well as in-store presence, the in-store
availability is not a required field. In fact, currently it is a
separate API in a feed, because it requires a lot more
complexity to give us feed for all your stores. You might have hundreds of
stores just in North America. And that’s completely
optional. We are slowly rolling
that program out. And basically we can associate
both these feeds together so we know that this is you as a
retailer who’s giving us both those feeds. SPEAKER 2: But more important
for the online? NITIN MANGTANI: Well
it depends. I think if you have both online
presence them as well as a physical store presence,
I think it’s in your best interest to give us your
physical store inventory, too. Because as I showed you in the
slides, earlier, 90% of the revenue is still happening in
the physical stores, and you want to get that foot traffic
as well, right? SPEAKER 3: OK, I have two
questions, actually. Sorry. One, the taxonomy for
categories, we have feeds in several languages, but I haven’t
figured out how to do the taxonomy for any language
but English. Are you doing that translation
behind the scenes or are you going to release the other
languages eventually? [INAUDIBLE] ALI AFSHAR: Use the taxonomy in
English, and then it will be automatic. SPEAKER 3: OK, that’s good. ALI AFSHAR: That’s the safest
way to do it because certain products don’t translate that
well, certain words that describe products don’t just
translate that well, so use the English taxonomy. SPEAKER 3: OK. I apologize to the other
people behind me. The second question is, for the individual product updating. I know, for the batch product
uploading, there’s a cap to the number of products you can
send, both per feed and overall for your account. How does that cap translate to
the individual products? Do some disappear when
you upload more? Or is there no cap, or what? ALI AFSHAR: The short answer is
that almost every operation you can possibly do
does have a cap. We can have caps on, and I can’t
go into details, but number of products you have
uploaded, number of operations, it’s all capped
because we don’t want to get spammed, and we don’t
want to get denial of service attacked. But the caps are all
very, very high. And if you do reach one of the
caps, you can just ask for an increase and there’s
no problem. SPEAKER 3: So, you would get
an error response if you reached a cap of some kind? ALI AFSHAR: You get a specific
response, too many operations, that’s the error message,
so you’ll know. It’s unlikely that the small
to medium people will encounter this, but we’re
keen for the data. So we’re that keen for the
data that we will keep increasing your cap if
that’s what you need. We do investigate the use case,
but yeah, you shouldn’t have any problem. NITIN MANGTANI: Yeah, and the
point here of what Ali is saying is that we want to
relevate your account and understand that indeed, you need
a higher cap, and if you feel like you should file a
support ticket with our operations team, and we’ll
look at your application. Hopefully you’re not hitting
that limit right now. SPEAKER 3: We’re hitting
the limit, yes. Good. NITIN MANGTANI: OK,
well, thank you. Why don’t we take a couple
of questions on that? Go ahead. SPEAKER 4: Just a question
about the categories on the left. Are they customizable, like size
and color and all that? NITIN MANGTANI: On your
own websites? SPEAKER 4: On your
own website. NITIN MANGTANI: Yes,
absolutely. So we call them facets
or parametric search. Let’s just go back here. What I was showing here, in one
of the demos, the things that you see on the left-hand
side, for example, things like price, brand, these things are
called facets, and they are fully customizable. For example, if you’re selling
appliances, you can have a field on the left-hand side
which is BTU, or convection oven, or regular oven,
and things like that. So you can decide what do you
want on the left navigation, fully customizable. SPEAKER 5: You mentioned that
you had to validate the pricing information. Do you guys do it often where
you would come by a couple of times a day or something like
that, so if we don’t give you the information fast enough, you
may say our information is invalid and we will decrease our
search rankings, or do you have a little buffer
with that? ALI AFSHAR: The situation you’ve
describe could happen, but the good thing is,
we check again. So it may not be valid for the
period of time that we couldn’t access the home page. Or, for example, the
price is incorrect. So we do recheck, but yeah,
that’s a good tip. Make sure your data
is accurate when you upload to us. NITIN MANGTANI: It’s also
good for you, right? If you’re running a business,
you have a pure-play online, or you have a physical store,
as your prices are changing, you want the consumers to know
about the change, right? Most likely the prices, you’re
doing some discounting, or they’re going down. And in that case, actually it’s
in your best interest that the consumer knows that
the price went from– for this camera, which was
like $199 to $149, right? And having that discrepancy
leaves a bad taste, both in the consumer’s thing and
it also disserves you. Now there are some instances
which we have seen– I’m sure it’s not you guys– but where people are
purposefully giving us wrong data, which know I think
there’s a term in the industry, they call it bait
and switch, right? And we definitely want to make
sure that we catch those issues and we basically disable
those feeds because that doesn’t help the
entire ecosystem. We want people to be genuine. But if it is a technical issue,
a few hours later, we are monitoring this, and
we’ll notify to you. And the reason we created this
new Content API is exactly with that use case in mind. If you’re selling a million
items, and let’s say you change the price only for 10
items, you don’t need to upload your entire data
feed for those million items again to Google. You can just write a small
program which updates price for those 10 items, and within
5 or 10 minutes, we would go and update the price. So I highly encourage you, if
you’re in a situation where your prices are changing within
a day, multiple times, please leverage Content
API for Shopping. If your prices don’t change,
then feeds are fine. You can upload once in a day
and we’ll take care of it. SPEAKER 5: Thank you. SPEAKER 6: Mine is an
interface question. When you look at the sites
like shopping.com and pricegrabber, they’re
all laid out in a much more usable format. But when you go to Google
Shopping, things are in different places and they’re
a little bit wonky. I’m wondering if the plan is to
work on the interface for the consumer. NITIN MANGTANI: Well,
the Google shopping is a consumer interface. If you go to Google, you can
type in a query, for example, digital camera, or any of the
other queries, and we show the search results right on
the first page, right? So we are driving a lot
of value to both the consumer, right? So when a consumer comes to
Google, he or she can have multiple intentions. Maybe he just wants to do
research on what a digital camera is and what’s
a zoom lens and some things like that. Or maybe he wants to buy it. So we want to show
this information right here to the consumer. Now, at this point, we are
driving a lot of traffic back to the retailer, but obviously,
we want to give them the full information
here. So this is absolutely tailored
towards both consumer and retailer. As far as usability is
concerned, we do a lot of experimentation so, without
commenting on some of the other players that you
mentioned, we have our own usability team. And we do a lot of research on
what consumers like, and it’s a hard science. There’s no perfect answer, and
that’s why we do a lot of [UNINTELLIGIBLE] testing, much like you guys
do on your own website to determine what things appeal
most to the consumers and tried to tailor our
website around it. ALI AFSHAR: But having said
that, if you’ve got any specific suggestions or
feedback, come and see me because we’ve only got
50 seconds left. But come and see me. I’ll write them down and
I’ll take them to the shopping team. Thanks. We appreciate all
your feedback. NITIN MANGTANI: Well, I think
we are out of time here. I want to thank everyone here. We are in a very exciting time
here on the commerce and shopping in general. And we want to work with the
broader ecosystem, so whether you’re a developer, a publisher,
or a retailer, we absolutely want to
work with you. And this is why shopping
APIs are so critical. As Ali mentioned, we both will
be here as well as we have the office hours, so happy to get
more feedback from you, inputs, and as well
as insights. So thank you once again. Enjoy your day. ALI AFSHAR: Thank
you everyone.