everybody. Thanks for coming. Welcome to our talk. My name is Thomas Kotzmann. I’m the tech lead
for the Google Content API for shopping. CLAUDIA CIORASCU: And I am
Claudia Ciorascu from Google Merchant Center. We are both from Zurich,
Switzerland. I just remembered how
someone described Switzerland to me earlier– very little country with
narrow streets. Yes, very little country. But you know we have very tasty
cakes, chocolates, and wonderful desserts. THOMAS KOTZMANN: And today,
we two are talking about empowering local shopping
through Google Shopping. Just out of curiosity, how many
of you have attended the previous talk about
the Content API? Please raise your hands. Good, excellent. So we presume some
basic familiarity with the Content API. But even if you’re just
generally interested in local shopping, you will surely find
our presentation interesting and enjoy our live demos. This is a technical
presentation. So we go into details– how to configure your accounts,
how to use the Content API to upload products
and to update your inventory, and how to verify your
data freshness. Before I dive into the details,
though, let me give you some motivation for
local shopping. I also want to point out why
it is important both to merchants and to Google. Google’s mission is to
organize the world’s information. And that does not just include
web pages, images, and videos, but also information
about products. An important question in this
context is, which stores in my neighborhood sell a
certain product? Do they have it in stock? And what does it cost there? In 2011, Forrester Research
did a study. And they concluded that about
46.5% of all retail sales in the US, up to some extent,
were web-influenced. That means that from 100 people,
about 46 to 47 either order a product online and get
it delivered to their home or they do some online research on
the web but then go to some local, physical store and
get the product there. So I would like to let
you take a guess. From these 47, or 46 to 47
people, what do you think? How many still go to a local,
physical store? Just shout out some numbers. Ideas? AUDIENCE: 30. THOMAS KOTZMANN: OK, 30. Other ideas? AUDIENCE: 100%. THOMAS KOTZMANN: Huh? 100%? What else? So it’s about 40 people of the
46 still buy in local stores. That relates to about $1.2
trillion of retail sales. That’s about six times as much
as people ordering online and get it delivered
to their home. So $1.2 trillion still by
selling in local stores. Why is that so? Well, people want to try out
things before they buy it, touch them. Maybe they want still some
personal advice. Or they want to take it home
right away and not wait for the delivery. Now, how can merchants benefit
from this user behavior? The answer is simple. Instead of just providing the
user with information about the product itself, they also
tell the user where he can find it, where he can buy it,
and whether the product is in stock there and what it costs. And this is what local
shopping is about. As you can imagine, it takes
different types of information to answer that question. First of all, you need local
product data, information about the product itself– a title, a description, brand,
the condition that the product is in, and so on. From this information, Google
Shopping renders a product page that reflects exactly
this information. So far, there’s no big
difference to online shopping experience. When it comes to local shopping,
merchants also need to provide Google with their
store locations and price and inventory data, which associates
the stores with the product and adds store-specific
product properties like price, quantity,
and availability. In the Merchant Center, the
merchants get, then, information about the
quality and the freshness of that data. The user can then enter location
into the web browser and will see stores in the
neighborhood that sell the product that he or she is
currently browsing. The user can also see additional
information about the stores, like an address
or a phone number. And it’s possible to see what
the product costs in that store and whether it’s currently
available in stock or out of stock. So for the user, it’s
nicely laid out. At the top of the page, he sees
the product information. And at the bottom, you can see
the nearby stores and whether it’s in stock there– the local availability,
whether it’s in stock or out of stock. So let us sum up that
for a second. Local shopping answers
two questions– where can I buy something, and
what do I want to buy? The first part is driven by
store locations, also known as business listings. It’s just another term. They want part by products
listings– either online product listings
for the online products that you can get delivered to your
home, or local product listings for those products
that you can buy in some physical store. Let us distinguish a few
use cases that the merchant could be in. A merchant could have online
stores with pickup possibility. So you can order online, but
you can then go to some physical store and pick
up the product there. This merchant would obviously
upload business listings for the location, where can I pick
up the product, and online product listings. No local product listings
because everything needs to be ordered online. Another use case are
local stores only. So a merchant would then upload
business listings and local products, but no online
products because he requires the consumer to go to
some local store. Finally, the ideal case is that
the merchant has both an online store and local stores. And this merchant would upload
all three types of information. As you can already see from
the color coding on that slide, business listings are
managed with a different application than products
listings. The reason is that business
listings are also used somewhere else on Google,
like on Maps and so on. So business listings are managed
with Google Places and products listings with the
Google Merchant Center. And Claudia will now talk you
through the steps that it takes to participate
in local shopping. CLAUDIA CIORASCU: Thank
you, Thomas. So to make full use of Local
Shopping, the merchants have to do some preparation steps
at the beginning. This includes to sign up in the
local shopping program, to provide the necessary
information about the stores that they own, and to do the
necessary configuration in Google Merchant Center
account. After that, they can regularly
update information about their product via Google Content API,
as we’ll see later for example, to keep up to date
information about the local products that they have, about
their price and inventory. And of course, they can all
the time monitor the performance and quality
of those products. Local Shopping program
is in beta and is open on request only. That means the merchant can
contact and send a request to Google sales representatives
and apply for the program. They will give you the
application and do the necessary configurations to
include the merchant in the Local Shopping program. As my colleague explained
earlier, Local Shopping depends on two sources
of information– one which handles data about
the stores owned by the merchant via Google Places, and
the other one which keeps track of the product listings
that are sold in those stores. And those are managed in
Google Merchant Center. For the next steps, we prepared
a demo account, a demo user, and we’ll show
you exactly how this has to be done. Please let me introduce you
our imaginary lady, Geneva Matterhorn. By the way, her name matches
with the two most touristic places in Switzerland, the town
of Geneva and the highest peak, Matterhorn,
from Swiss Alps. She prepares very delicious
cakes, and she has a small business where she sells
those cakes. By chance, she has some shops
around San Francisco. But please don’t run to
those shops because they are just imaginary. She keeps the information
about her shops in Google Places. Google Places is
an application. It’s quite a young
product which already proved its potential. It handles the necessary
information about business listings. Business listings can be seen
as a presentation, or as a business card, about a physical
entity that can be identified by its location
in the real world. In the case of the merchants,
usually the business listing represents the stores
that they own. Each business listing will
finally appear either on Google Search, Google Maps,
or recently on Google+. A business listing contains
the information about the location of the store, like
the country, like the state or address. It also provides information
about how the potential customers can contact the
representatives of the store. It has a description which
promotes the store on the Search Results page. And usually, it is classified
in at least one pre-defined category to better describe
the store depending on the services and the store type. Besides the basic information
about the location, the merchant can annotate the
business listing with additional data like opening
hours, with pictures and videos to better promote the
store on the results page, or with information about the
facilities inside or outside the store to give a complete
image of the store and to help the customer to decide. Each store has to
be confirmed– validated and confirmed– in order to give the correct
information about the stores that they own. We didn’t validate our stores
because we don’t really want to make them appear
on Google Search. For the stores that appear on
the Search Results page, the merchants can actually monitor
the visibility and the impact of the business listing, looking
at the metrics under Impressions and Actions
columns. Impressions gives how many times
the stores have been listed on the results page while
the Action represents how many times the business
listing has been clicked by the potential customers. Each store is identified
by a store code. While this is internal
information and it’s not displayed to the final customer,
it is actually very important for the merchants
because they can refer to the business listing from
an external source, as we’ll see later. So this is how the dashboard
looks in Google Places for our lady, Geneva Matterhorn,
and shows all the shops that she owns. Complementary, Google Merchant
Center handles information about the product listings. Product listings are a rich
description of the products that can be purchased from those
stores or that can be purchased by the customer either
online or locally. Google Merchant Center provides
different mechanisms to upload data about the product
listings either via a [? flat ?] file in the data
fields page, either via Content API, as we’ll
see later. To assure the quality of the
data and to check if the content of the data conforms
to the policy from Google Merchant Center, the merchants
can check the data quality page which shows the details
about the potential errors related to the upload process
or to the content of the product listings with details
on a case by case basis. At any time, the merchant can
monitor the state and the performance of the product
listings, looking at the Performance page or on
the Dashboard page. Once the merchant is included in
the Local Shopping program, he has access to the Local
Shopping Settings page. He has to finish the process
by confirming the participation in the program by
enabling the Local Shopping on this page. In this way, he will be able
actually to upload information about the local products and,
in addition, also he can upload information about the
business listings from Google Places but via Google
Merchant Center. As I said, Local Shopping on
both data from Google Places and Google Merchant Center. To make the link between the two
accounts, the merchant has to provide information about the
Google Places account that contains information
about his stores. If he doesn’t have a Google
Places account yet, then he can defer this at a later stage
and in this moment just use the first option. But usually, the merchants have
a Google Places account which is owned by the
same user as the Google Merchant account. In this case, lady Geneva has
the same Google Places account, which means she’s using
the second option to make the link between
the two accounts. If the Google Places account
is owned by another person, then the merchant can specify
the email address of the owner of the Google Places account. Then, the system will send a
confirmation email to the owner of the Google
Places account. And the person has to accept
and to agree to share the information about his stores
with this Google Merchant Center account. When everything is ready,
the merchant can upload information about his products
online and locally. As you can see, in this moment,
we have no products for our lady Geneva. Thomas, can you help her
to upload some data? THOMAS KOTZMANN: Yes,
I will be happy to. We have seen the sign up process
for Local Shopping and how to manage business
listings and link the two accounts. And now, let’s upload some
products for Geneva. Local Product Listings is
information about products across stores without any
store-specific properties because the store-specific
properties will be provided later via the price and
inventory updates. I will get back to that. Local products are sent as XML
to our Content API for Shopping server, either via
PUT or POST depending on whether you insert or
update the products. Local products are
uploaded the same way as online products. So if you’re familiar with the
Content API or have been to the previous session, then
there’s no surprise in there. Local products are linked with
online products via reference so that they show up, that
they can be associated correctly and show up
on the same page. So assuming that you already
know about online products, let me now focus here on
the differences with local product data. First, there’s the
channel element. This is an optional element. If you omit it, it defaults
to online. So if you want to upload local
products, you have to explicitly set it to Local. Then, as mentioned before, if
the merchant has both online and local stores, he’s advised
to link the local products with the corresponding
online ones via the web item ID element. The link to some landing page
of the merchant’s own web presence is optional
for local products. The price is optional as well. But if given, it defines a
default national price. So it’s actually a good thing
because if you do not specify a price during price inventory
updates, then the price for this particular store defaults
back to the price that was given when you uploaded
the product. Finally, there’s no quantity or
availability on the product level because this is
store-specific information. It will differ from
store to store. In San Francisco, you may
have five pieces left. In New York, maybe 100. So now that you know the
differences between online and local products, there’s really
not much behind it. Let’s upload some products via
the [? email ?] page that you also have seen in the previous
session, some simple tools that we provide to allow to
play around with the API. It’s probably not for your
production uses, but it’s a very nice way to issue real
Content API requests and see the result immediately. So we do a batch request. We upload items, local
products or items. And we do a batch request. You should do the same for
better performance. And we upload to the URL
content.googleap Then, the Merchant Center
account IP of our cake stores, followed by
/items/products/schema, which just means we upload items, and
then /batch because we do a batch request. We upload four entries in this
batch request, two online products and two corresponding
local products. The first entry corresponds
to an online product. It has a title. So Geneva sells very good
strawberry cakes, actually the best ones in the world, as the
description indicates. There’s a link to the web
presence of this store. We set the channel to online
here because we uploaded an online product. We could have just as well
omitted this element because this is the default. But this is just to show you
explicitly the difference. Then, we have some ID. The merchant can pick any ID. So our online product
has the ID 01. And then, the standard
attributes, the content language, the country, some
product category which is in this case, bakery cakes. The condition, new– well, I
would hope so for cakes. The price– so if you ordered
online, it costs $14. And it’s in stock, so you
can order it online. And then, for online products,
we also specified tax and shipping information. So that should look
familiar to you. It becomes more interesting with
the second entry, which corresponds to the
local product. We have, again, a title,
strawberry cake. Again, the same description. But now, the channel is local. So we tell the Content API we
uploaded a local product. Then again, content language
and country and a different ID. Now, our ID is 11
instead of 01. But we use, as a twist, the web
item ID to link this local product to the corresponding
online product. Then, we have a default
national price. So if we later on, for a
particular store, do not specify any price, then for
this store, the price will default to $15.50. So it seems to be a bit more
expensive than if you were to order it online. Then, we have, again,
the product category and the condition. And that’s pretty much
all it takes to submit a local product. We have the same below again
for pineapple cakes just to make the experiment a bit
more interesting. But these entries have all
the same structure. So I will not go into
details there. So let us execute
this request. Claudia, please press
the button. And we’ll see how it works. So this is the request that we
send to the Content API. And we got the response back. We see from the status code
200 it was successful. And the response just echoes the
request and tells us that all four entries have been
uploaded successfully. CLAUDIA CIORASCU: Let’s see
how this looks like in Merchant Center. If we look at the
products page– Thomas, can you refresh,
Content API exists. We have the four products that
Thomas just uploaded via the Content API. As you can see, there
are four products. We can see the titles, the price
for those products, the availability for the online
products, the condition– which is new for all of them. And what’s important is the
channel, which actually makes the distinction between which
products are online and which products are local. For all the products, the
merchant can also see the visibility and impact of those
products on the Search Results page and in the Impression
and Clicks columns. If we look in more details at
one of the local products, we can see the Status of the
product which, in this case, it’s not yet searchable because
we just uploaded it. But also, we can verify the
information that has been provided when doing the
API [? call ?]. We can see the ID, which
in this case is 11. We can see all the other
attributes like description, condition, price, et cetera,
but also the web item ID, which actually makes
the match with the corresponding online product. On the local data quality page,
the merchant can now have an overview of his
products, online and local, in a side-by-side comparison
format. In the first table, they can see
how many online products they have and how many local
products they have. This gives them an idea about
the products and which channel they are covering and how
much they are covering. In our case, we have
two online products and two local products. This is detailed day by day
for the first week. This can be detailed later with
day by day for the entire month, but there is also a trend
graph which quickly can show you the status
of the products. The last two columns highlight
the matching between the online and local products. The number of online products
matching to local products show many online actually
have a correspondent in the local channel. And the last column shows how
many local products have a correspondent in the
online channel. Usually for the merchants that
sell both online and local and that are selling all items
online and local, they will have similar numbers in the
two columns, and they will have around 100% matching. But these numbers actually
depend on the business model that the merchant has. For example, we can imagine that
our lady Geneva, since she’s selling cakes and some
cakes cannot be sold online, she probably has more local
products than online products which means the number of local
products would be higher than the number of online. But it also means that the
number of local products matching with the online would
be actually smaller because there are smaller
online products. And thus, the matching will
not really be 100%. This is OK as long as this
pattern is constant over time. If it is a change in this
pattern, actually it indicates there could be an error
with the data that has been provided. Either the products don’t match
any longer, either the IDs of the products have
changed, et cetera. Until now, Thomas helped lady
Geneva to upload data about the local and online products. But we have no information
about where the local products, where the cakes can
be bought, from which store and with which price? So, Thomas, you can– THOMAS KOTZMANN: And we add this
information right now via Price-Inventory Updates. Price-Inventory Updates
differ significantly from product requests. So they are submitted via
separate Price-Inventory API feed, which just means
it’s a different URL, different XML structure. You can think of price-inventory
data as a mapping of store product peers
to store-specific product properties like price, quantity,
and availability. As mentioned before, some
products may have a different price in San Francisco than in
New York, so you want to specify it on a store
by store basis. Each entry must specify
at least a quantity. This is a required field. The price is mandatory only if
you have submitted the local product without the
default price. If you did submit the local
product with a price, you can override it with a
price-inventory update. But if you do not specify one,
then it will default to this national price. Something that’s also different
to product uploads is that the only supported
operation is update. You cannot insert inventory. And you cannot really
delete inventory. If a product is no longer sold
in a certain store, you will just set the quantity
to 0 and the availability to out of stock. That’s it. Another difference that is
notable is that updates are incremental. Remember, if you upload the
product, the latest version replaces any previous one. So if you omit an element there,
it also will not be there in the final result. This is not true for
inventory updates. They’re incremental. So if you omit an element
here, the value remains unchanged. And if you want to delete a
certain value, you would specify an empty XML element. Something that is again similar
to product uploads, is that they can be grouped
in batch requests. And they should be grouped in
batch requests for better performance. Here, I can give you a hint. Rather group by product
than by store. So rather update a few products
across many of your stores than many products
across few stores. It will simply be
more efficient. Let us look now how to really
technically do a Price-Inventory Update. As I said, the URL
is different. Only the beginning
is the same. content.googleap, and the account ID. But then, followed by /inventory
because we want to do an inventory request,
followed by the store code. Remember, that’s the one that
Claudia pointed out when we went through the Google
Places demo. Followed by the literal /items
and the ID of the local product whose inventory
you want to update. And this ID consists
of four components. It will also sound familiar to
those of you that already use the Content API. The first one is the channel. Obviously, it’s local here. Then, the language, English,
the country, US, and the merchant specific ID of
the local product. Here, 11, which relates to
our strawberry cake. We update just the inventory of
this single item, so we do a PUT request because
we do an update. PUT corresponds to update. And then, we send
some XML entry. And how that looks
like, I will show you on the next slide. In contrast, for batch requests,
you would replace everything after “inventory”
by /batch. And then, instead of sending a
single entry, you would send a feed of multiple entries. Each entry needs to specify the
operation because we can no longer infer that from the
HTTP method because you can– so for products, you can merge,
delete, and update and insertions into one
batch request. So you’ll need to specify
the operation here. For Price-Inventory Updates,
remember the only operation is Update. But for consistency across the
API feeds, we require it to be specified here as well. And since the URL that we send
this request to does no longer encode the ID of the item whose
inventory we want to update, you’ll need to include
this information in the entry via the ID element. Good thing, though, is that this
ID has exactly the same structure as the URL that you
would use if you would update the inventory only of this
one, single item. So it’s as easy as that. Now, how does the
entry look like? There are actually not so
many attributes in a price-inventory update. You have the price,
what does it cost? If you do not have a default
national price, you need to specify that here. The quantity, the mandatory
field to say how many pieces are still left in this store to
avoid that then consumers go somewhere and do not find
the product anymore. The availability in stock, and
here please make sure to make it consistent with quantity. So if the quantity’s nonzero,
the availability should be in stock. And if it’s zero, it should
be out of stock. And then, you can even
specify sale prices. So for example, you
sell the product– in our case, the strawberry
cake– for a special discount at $12.90
during that conference. So you can even specify the
interval during which the sale is effective via the sale
price effective date. This element consists of
two date-time specs. You can set either of them to
null for an open-ended sale price that either started way in
the past or ends somewhere in the future. So here, I made our sale start
at the beginning of the conference. And it’s open-ended. So at some point, I will have to
do an inventory update with an empty sale price element to
stop the sale, to delete the value because if I do in between
some Price-Inventory Updates and do not mention the
sale price at all, it will keep unchanged because remember,
Price-Inventory Updates are incremental. Each date-time spec in the sale
price effective date can, but does not have to have,
a time portion. It can also be just a date. When it has a time portion,
you can also specify a time zone. But you do not have to. And if you don’t specify a
time zone, the time is interpreted in the local time
of each and every store. So in this case, our sale starts
at 9 o’clock in New York and also at 9 o’clock
in San Francisco. Although, strictly speaking,
these are two different points in time. So let us now see how that
looks like in practice. Let us do an inventory update. We again use the demo
page that also supports inventory updates. We just pick the
tab, Inventory. We again do a Batch Request. So the URL is content.googleap and the familiar account ID of our lady
Geneva /inventory/batch. And we send two entries. So we do two Price-Inventory
Updates. But if you look closely, we
update only one item, namely our strawberry cake, with the
ID 11, across two stores, namely store1 and store2. So we followed our own advice to
rather update few products, only one product, across
many stores than the other way around. The first entry corresponds to
the store1 and specifies the price, $15.50. There are eight pieces
of this delicious strawberry cake left. It costs $12.90 in this
particular store. And we define a sale price. So this is exactly what
you saw on the slides. The second entry
is for store2. There, the cake is
a bit cheaper, so $14 instead of $15.50. But, maybe because it’s
cheaper, they ran out of the cakes. So they have zero pieces left,
and it’s now out of stock. So let us now– Claudia, please press
the button– execute this inventory update. We again see it was
successful. The status code is 200. And similar to product uploads,
the response echoes the input just to tell you that
both entries have been updated successfully. If you do not want to assemble
the XML yourself, you can also use client libraries. I have just as an example
picked Python here. You would create an inventory
entry and set all the attributes that you
want to change. If you do not want to change
one attribute, just don’t set it. If you want to delete it, set
it to an empty value. Then, we retrieve the content
for Shopping client, and we call the update inventory entry
method where we pass in the inventory entry and the ID
of the item whose inventory we want to change. It’s similar for
batch requests. There, you would just set the
ID on the entry itself. And you would call a method that
does not take a single entry, but a list of entries. Otherwise, it’s the same. So let us now look at
the data freshness. CLAUDIA CIORASCU: Now that we
have information about the products per store, we can see
in the Local Data Quality page more information about
the local products. For example, the first column
will show the number of stores that have local products
available. Because merchants usually don’t
close– hopefully– or don’t open stores every day,
here, normally it’s a constant number over time. In this case, for example, two
stores because we uploaded data for two stores. But any drop in the graph at
the beginning or any number which is lower than the expected
number of stores is actually an indication that
something went wrong with uploading the data. Maybe the match with the store
ID was wrong, or maybe the information was not the
expected amount. Besides that, the user
can also check the freshness of the data. It is recommended that the price
and inventory data be uploaded at least
once per day. Compare with the information
about the online products that can be uploaded once per week,
or the ones related to the stores, which can be provided
at least once per month. So because we are expecting
that the data is uploaded every day, usually the merchants
will see that all the stores have refreshed data
in the last 12 hours. It can be in the
last 12 hours. It can be in the
last 24 hours. But if it gets too old, then the
merchants should actually re-upload information
about the local products and the stores. There’s also information
of similar metrics, but per stores. Which stores actually
have fresh data? And again, we are expecting– the merchants are expecting– to see that all the stores have
fresh data in the last 12 hours to be sure that the local
products will appear with up to date price
and inventory. If there is at least one store
or there are some stores which are classified in one of the
48 hours, for example, or seven days, it means that the
data is stale, and it’s old. And it should be re-uploaded
by the merchant. Because in most of the cases,
the matching between the online and the local product
listing is important, we also show the number of stores that
have matching between the local and product items. In our case, we have only two
local products and two online stores that we are matching. So both stores actually appear
with 100% matching. But this actually depends,
again, on the business model that the merchant has. So if it is more like an online
merchant with pick-up, then it means has more
online products. The matching will be less
because it doesn’t really have local products. Or, for example, if we can
imagine for our lady Geneva that she sells more of her local
products than online, again, the matching is less
because actually it has less online products. So this depends on the model
of the business. But it’s important to be
constant over time. Any change in this pattern
could actually be an indication that it is a
problem with the data. And in this case, the merchant
should actually look more into the data and fix the
potential errors. In a real situation, lady Geneva
will actually be happy to help the potential customers,
to give them that delicious cake. But since now it’s imaginary,
we’ll just demonstrate how [? we see this ?] now. THOMAS KOTZMANN: So that brings
us to the end of our presentation. You have seen that you have to
sign up for Local Shopping, how to upload and manage store
locations, also known as business listings, how to link
the Google Places account to your Merchant Center Account,
how to upload product data, local product data, and what
the difference to online product data is, how to do price
and inventory updates, and how to verify the freshness
of your data in Merchant Center. Local Shopping on Google
Shopping helps consumers to find stores in their
neighborhood where they can pick up the product. So it’s really a good experience
for the user. It also enables local stores to
compete with online stores and therefore has a significant benefit for the merchant. The program is currently in beta
and has been launched in US, UK, Germany, France,
and Japan. If you are in the US, then
just follow this short link to sign up. This will lead you to the
Merchant Center Help Center pages, so you can also
find it there. Fill in the form to apply to
participate in Local Shopping. If you are in one of the other
countries, then please contact your Google sales
representative. You’ll find more information,
in particular how to use the Content API both for the upload
of local products and for price-inventory updates on
this URL on the developer’s page, the documentation
for the Content API. And that is the end
of our session. I have, again, included
the links here. I think we will also
publish the slides. So thank you very much
for your attention. And now, we have some time
left for questions. [APPLAUSE] THOMAS KOTZMANN:
Any questions? Yeah, please use the mic. AUDIENCE: Is there any
particular method for representing deals, promotional
deals, like buy one get one, at least showing
some kind of flag of that information? THOMAS KOTZMANN:
Currently not. What you can do is to
define a sale price. That will be highlighted. It’s on sale now. We will show the
special price. So this is your opportunity to
promote a particular store via the sale price and the sale
price effective date. AUDIENCE: I have one more
question, unrelated. THOMAS KOTZMANN: Absolutely,
go for it. AUDIENCE: It relates
to frequency. So would it be realistic to
think that a large retailer could maintain a perpetual
inventory, in other words somewhat frequent inventory
updates? THOMAS KOTZMANN: Yes,
yes, absolutely. So what we set, this update– that’s an excellent question– this update frequency that we
set were some recommendations. At least once a month, update
the store locations. Probably once a week
or once a day, update the local products. And then, the inventory,
at least once a day. But if it changes, update it
immediately because that’s good for the user, right? We need fresh data because
otherwise, the user thinks it’s in stock because you have
not updated it, goes to the store, and is very disappointed
because it ran out of stock. So absolutely, we always
recommend update this inventory data as soon
as it changes. With how many requests
you can do, that’s also a good question. And that’s one of the reasons
why this program is in beta. We actually want to work with
merchants to get that right. And as I said, the different
costs associated with a request, therefore in
a batch request– I told you, rather group by
products than by stores. And different quotas apply. And we just need to get
the numbers right. But if you apply and we contact
you, then we will work with you and make sure that
it fits your use case. AUDIENCE: Thank you. THOMAS KOTZMANN: Sure. Any other questions? Take your time. AUDIENCE: Thank you guys
for the information. Can you speak to how this
content fed up into your system might be tied into
product listing ads? THOMAS KOTZMANN: Yeah, for the
time being, Local Shopping is not affected by listing ads. So it will continue to show up
on the products pages, will stay free for the time being. So it’s not really affected
by product listing ads. Any other questions? OK, then, thanks again
for coming. Enjoy the rest of
the conference. See you around. Thank you. [APPLAUSE]