Tip:
Highlight text to annotate it
X
THOMAS KOTZMANN: Hello, 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
is.com/content/v1.
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, please?
THOMAS KOTZMANN: Yes.
CLAUDIA CIORASCU: Voila, 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 is.com/content/v1, 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 is.com/content/v1 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]