 Good afternoon, everyone. Welcome to our session on Stand Out on Google Search with Structure Data and Search Analytics. My name is Andrei Valente. I'm a technical program manager in search. And this is Duncan Orsman, a product manager in search. Thanks for joining us today. So the first thing I want to do is to give a little bit of perspective as to how we arrived where we are by going a little bit back to the evolution of search. As you know, Google's mission is to organize the world's information and make it accessible and useful. But how we're doing this is changing over time. Users are not satisfied anymore with us providing a link to a possible answer. They want us to provide the answers whenever possible or help them navigate through the space of possible answers or possible alternatives. And in fact, you can see that many of our products, including, of course, the assistants, are now having this theme of Google providing assistance to our users. So before, and in fact, until now in many cases, what you have, if you put a search like dessert recipes, is a set of links that you can explore, you can try out. And you have some snippets that try to give you an idea of what is behind those links. But users that land on your page once they click don't have enough context, and it's not clear during tent. So we tried to make this better. And last year, we launched this idea of rich cards. The idea of rich cards is that there are visual modules that organize the information on what used to be a blue link in such a way that it's simpler to read, more visually appealing, and easier to navigate. These cards were sometimes organized into carousels, like you see here. So you would be able to scroll right and left and see some possible visual answers to your query. And now, particularly in the last year or so, we have evolved even further into this notion of immersives. These are sort of mini applications you have where you can explore the range of answers. So not only you have the visual components of these rich cards that we had before, but you'll also have things like these step targets. So for instance, you can refine your query and say, well, not only I want a strawberry tart recipe, I want one that's gluten-free. And this way, what happens is that somebody who clicks on this has a very clear intent of what they want to get. Now, what happens, however, is that, in addition to all the information that Google has in its knowledge engine, what happens is that we use a lot of third-party structured data to power this. And what that means is that there's an opportunity for you. If you have a site where you have relevant information, you can try to organize that site and optimize its performance in such a way that you can participate in these features. What we have found is that the sites that implement structured data typically see increased click-through rates and increased engagement. In other words, the users that come to you are better users. So for example, here is one use case that we found. Rotten Tomatoes implemented structured data in more than 100,000 of their pages that attracted billions of impressions. But the more interesting part is that these pages resulted in 25% higher click-through rate, which is really very hard to achieve within any other means, compared with the pages they have that didn't have structured data. In other words, you can do these, and there's sort of good results for you. Later on, we're going to have more case studies that will explain the details. Now, in the remainder of this talk, we're going to teach you how you can use structured data to optimize your site's performance. We're going to tell you how you can use this to stand out, pick up the right markup that you're going to put on your site, and how to measure the impact once you implement this. Now, next, Duncan's going to talk to you about how structured data appears on Google Search and give you more details. Thanks, Andre. Hi there. I'm Duncan Osborn. I'm a product manager on Search. So Andre is going to get into how you implement and measure structured data in just a second. But I thought first we'd go through some of the features that we've built that utilize structured data so that you can see how it then appears to users, and then we'll go through the implementation later. So we have quite a broad set of verticals that support features that have structured data in them. I'll go through just a couple examples. But I guess the key here is they're a fairly large number of verticals supported now, and we have a good set of partners in each one. So there's a good base to learn from. And we're constantly thinking of new verticals to roll out structured data features into. So I chose just a couple queries to show off structured data. These are just random from my search history. Let's get started from recipes. So this is a great example of a vertical where we've invested in structured data features at several levels, namely the page level, the domain level, and finally the result level. And so I'll walk through one of each of those. And it's dangerous to show cookies at snack time. But here we go. This is at page level. So in this case, what we've done is we've taken all of the recipe leaf results, as we call them, which just means a single recipe result. And we assemble them into a single carousel at the top of the page, which makes it easy for users to access all of the recipe results in one single place and make their decision and finally land on the one that they've chosen. You can see here that we're featuring several different kinds of structured data. First, we have the rating. We have the calorie count. And we have the cook time. All of those are sourced directly from the markup on the third-party site. It's also important to note that one click away from this experience is another interface that we've even more heavily optimized for browsing large numbers of recipes in this case. And here, again, we're using the same types of markup. But we've just restructured them so that they fit better in the UX that we've chosen in this case. One other thing that's important is we see several visual ramifications of structured data here in terms of rating and calorie count. But what's behind this experience is actually the markup at the page level, which tells us that it's a leaf result, a recipe page. And so that allows us to make decisions about how we then present them to users. So both kinds are important, the signal, and finally, how we decorate that result for users. So that's a page level. Now we move to domain level. At this point, we're assembling all the results. But the results that are in a single listing page are recipes, which by definition comes from a single domain. So instead of concatenating many different domains in one place, we now give the site owner a single property for their content. So once again, we've reflowed all of the content you see here in terms of ratings, cook time, calories, just in a smaller card format. So a good example of how we're fairly flexible and how we display this data. But the other interesting point here is that this list of content is customizable, both in content and in order. And that gives you a fairly visible level of control over how your results appear in search, which is pretty cool. OK. That's domain. And finally, at the result level, if we have a result that ranks that's just a single leaf page, we won't just leave it as a blue link. We'll use any data that we have to decorate that result that it looks really good, and also allows users to make decisions directly on the search results page. And the next one I wanted to show you, so moving on from cookies to something to make you even hungrier, is restaurants in SF, which is what cool people call San Francisco. So in this case, we again have the domain level results. So we've taken all of the restaurants that are in a listing page and assembled them into a carousel. But what's interesting here is, in this case, the side owner has only just provided the title. And we just shrink the card to adapt to that kind of data. But in this case, the side owner could also add things like the cuisine type or the location for the restaurant. So it's generally a good idea just to take a look at our developer guidelines and see what's possible for a given data type. And then you can decide, in that case, how you want us to render the cards. For example, they could have also added ratings, and those would appear right between the location and the title. And then one other point here, when you're doing domain level markup, you're only affecting your results. So we don't actually switch to results as a result. OK, so to burn off the calories, we're now moving to running choose. And we're also switching to a different product. In this case, image search. So here, instead of going to web search, I went to the Image Search tab. And I searched for Nike Free Earn, which is a shoe. So in this case, this is a good example of a query where you have users that want a fairly visual exploration to start with. That's because they're exploring options and comparing how they visually look. But at a certain point, they want to move to the point where they make a purchase. There you need additional information as a buyer. And that is where structured data comes in handy. So here in this case, we've included the price and the rating directly in that result once I tapped on the shoe that I wanted to buy. And then, of course, there's the link at the bottom of the page that allows me to visit and eventually purchase. Great, let's wrap up these examples with a brand new feature that we launched just about a week ago. This is for events. So in this case, I searched for concerts in NYC, where I live. And here, right at the top of the page, we have a single box that assembles all of the events for my query. And so, again, we've assembled things, but we rely on structured data to make this look good. So much of the data that we see here, the date, the time, the location, and even the image, are provided to us by the site owner. So this is, once again, one of these great features that we can provide to users based on the data that we're able to share with publishers. OK, Andre is here to walk you through how to then implement all of this markup. Thank you, Duncan. So what I'm going to do is I'm going to walk you through the journey of implementing this on your site, on your property. Before I do that, I just want to highlight and piggyback on a couple of elements that Duncan talked about, about what is structured there. What does it look like? Most of you are developers, but just in case. So you see here on the left side a specific card with the recipe. And on the right side, I'm going to highlight a few elements so that you can see how they match. So you see, this is a script tag in JSON-LD. And it specifies that this is a recipe according to the schema in schema.org. That's a public specification. And then each of the properties is going to match components that can go into the card. So in this case, for instance, the name, your basic Kassadeli recipe becomes the title. You see here, as we continue, more tags. The image gives you a URL for the image that we're going to display on the image on the left. And the description can give you some elements that we could use, for instance, in the snippet. On more structured components, for instance, this is how you would specify an aggregate rating. And then we then translate this information into the stars and the number of reviews that you see on the left. And then finally, you have here the total time, the cooking time, the 10 minutes, as well as the number of calories. And this is how they're specified. So the lesson learned here is each specific markup, each type you have, in this case, a recipe, is going to have its own specification. And you can see how they translate into the elements of the card. Now, this is sort of the overall journey of the implementation process. And I'm going to walk you through each element of it. So the first one is you want to identify the best markup match. So you're watching this talk, and you're thinking, right, this is something I could try to do. Now, throughout this journey, I will talk about different tools. And here is a summary. There's the Search Gallery, the Search for Data Testing Tool, and the Search Console. These links, of course, are available to you. Hope you can take a moment and try those out after we talk. The first starting point is the Search Gallery. The Search Gallery basically allows you to figure out what are the places where you can add structure data and the kinds of things that you can do. The first part I want to highlight on the left top on this list, by the way, this is a brand new version of the Search Gallery that's being published this week. You see these enhancements, and these are things that you can do more or less independent on the kind of information you have. So you know, recipes mark up. You're going to do if you have recipes on your site. But these are things that can enhance your results in Google Search independently on what you do. So for instance, you could have improved how the breadcrumbs are structured, corporate contacts, logos. You'd be surprised how many people don't give us a good specification of what their logo is, so we could show it if necessary. Once you sort of look at these opportunities, they're all sort of low hanging fruits. Probably everyone can do that. And then you see the second part, which are the vertical content types that Duncan was describing to you. So you have data sets, events, fact tracks, music, podcasts, and stuff. So this, for instance, is the specification, the documentation for recipes. And you see that there's actually several kinds of mark up I can have. On the left side, it's like a single recipe or a single query. And then on the top, on the extreme right, you see a list. So Duncan was talking about how you can sort of make a list page. This is how it would look like. Now look carefully at the specification here. This is all on Google Dev site. And towards the bottom of the content page, we always show you the property. So earlier on, I was talking about the schema. Well, here we kind of give a summary of the things that we expect. And stick special care to look at which things are required. Because not all the pages, if you don't have all the required elements, they want to actually be published. And of course, it's a good idea for you to put the recommended fields as well, because that will increase the quality of the result, the quality of the car that we could show, and will make you look better. So for instance, like number of calories in the recipe, it's not obligatory. But if you put it, the information would be added as Duncan was described. OK, once you identify the kinds of markup that you want to have, now the next step is to actually draft some of it and sort of play with it. Well, back to the guide to the page where the documentation is, you see there's these links with a C markup. And for each of those, we actually will then give you a sample of what the markup is for that kind of structured data. And that will bring you to the second tool in our 3-2 part called the Structure Data Testing Tool, which we're going to get to later as well. The Structure Data Testing Tool opens with a sample of that specific kind of page so that you could use it as a starting point. The idea is that you can kind of play with it, see what it looks like. Generally, we try to make it really complete so it has all the components. And you could use this as sort of a starting point. Now, we recommend to you that you create a version of a sample page. Now, take a page of your site, for instance, that has a recipe or something, and then add the markup to that and test it out. So you can actually give the address of the page and StTT will, Structure Data Testing Tool, StTT, will go pick up that page, analyze it, and tell you what happened with it, and give you whatever errors and warnings there might exist. Now, if your sample page, for instance, may be in a pre-deployment environment, you are not ready to publish yet, you can still mark, you can still cut and paste the markup here so you can still test it. It's just a little bit more cumbersome. Now, once your page verifies for some structured data element, the next step is for you to see how it looks like. And you have this Preview function here. Once you click Preview, you see a sample card. As Duncan said, it depends a little on the context, how much information we display, but you could see what your elements would look like in a realistic card that would be shown in search. And that helps you also tweak your content. So maybe you try different pictures or different images to see what's the best way to showcase your structured data. OK, so at this point, we understand what we want to do. We tested one to see what it looks like. And now the next step is to deploy this for some pages, or sort of a subset of your site. We generally recommend that you don't do this for everything at once. Get a subset of your site, and actually, can you go one page back? That you use a subset of your site and use that to try out. So add this to just perhaps even manually to a few HTML pages just to get a notion of what it would look like. Now, I'll get a more technical. So there's actually two ways in which you could add the structured data. So one is the same kind of script that I showed you earlier in JSON-LD. You put in a script tag, and it would show like this. And it's actually the most common way in which people do it. And another one, you could actually use microdata inside a div tag like this. So there's additional documentation on our dev site if you want. Now, of course, you could implement these things manually, but that's not a great idea. What you really would like to do is to use your CMS. I imagine most of you who have large or even sizable, or even that's not large, where properties have a content management system to manage your content, what you really want to do in the most common way we have found that people do it is that they pick up a suitable structured data CMS plug-in. There's many CMSs that have plug-ins that you could get. You could try a few different ones. We don't have any specific recommendations. But the idea is that you publish your content, your standard HTML content, but it then publishes the structured data with it. So you don't have to manage things one by one. All right, so once you put this in a specific subset of your site, it's time for you to review the stats and what this would look like. And for that, we get to our third tool, which is the Search Console. Now, Search Console is similar to Google Analytics in a way, but it focuses on Google Search. So it tells you how Search looks at your site and what elements of that appear in search results and how many times it appears itself. Now, different from the structured data testing tool in the Search Gallery, which were fundamentally just open, the Search Console requires a little bit of setup, because you have to sign up and verify properties. Now, I'm curious, how many of you have actually verified or used Search Console? Just so I get an idea. Not as many, maybe a third, a fourth. All right, so we'll give you a little bit of detail. There's more to it than that. But the first step for you is to get associated with an account. So you have anybody can get an account of Search Console. That's straightforward. But then what you have is a verification process that proves that you have rights to the site that you want to verify to test or use on Search Console. Again, much like Google Analytics is the same process. Commonly, you do this by uploading some special file to your site or perhaps to a domain, one of the components of your domain and your domain name provider. Now, if you have a larger organization, you might want to check. It's frequently the case that somebody else might have used and set it up. And in this case, they can authorize you and make life a little simpler. So once you register your site or you register the ability to manage your site through Search Console, the first thing you want to do is to add sitemaps. And sitemaps are a way for us to look and see what information you have. Now, of course, we already look at sitemaps if they're available. But this helps because it helps us understand which is the sitemap that you prefer to use. So for instance, imagine you deploy some new stuff and you have a sitemap and you give us that sitemap and we sort of use that to figure out what the components are of your site. So for instance, you could do this for a section of your site while you figure things out. This is what Search Console looks like, much like Google Analytics also. There's a lot of stuff here, so a lot of different reports. It's not always very easy to find. But let me walk you through some ways in which you can dig into the data for your implementation. First, you could use this rich cards report that's sort of marked on the left. And that monitors which structured data elements were correctly found on your pages after crawl. And the first thing you want to do, of course, is to look at whatever issues were found. So like the structured data testing to allow you to test one specific markup, this basically looks at what elements are all on your site and what do they look like. Keep in mind, by the way, that it takes a while to crawl your site. So once you implement everything, you might want to give a couple of days until we catch up to this. What you want to do, of course, is to look at all the critical issues. Remember those sort of obligatory or necessary properties. So for instance, you may want to look at those because those things may actually prevent us from showing our structured data into a card. You could also look at non-critical issues, as I said before, because they could improve the quality. Now let's look, for instance, at the issues that were affecting the recipe card type. So you see below this specific site implemented both recipes and local. So if we click on recipe, then we get sort of a subset of the report only about recipes. And you could see here there's 218 invalid cards. And at the bottom, you see the problems that were found. So that gives you a very good idea of what is it that you need to fix. As you see in this case, there's a bunch of opportunities that you might have missed in terms of adding nutrition. But the most important one is that there's 218 pages. In fact, all of the ones that are invalid and are invalid because they seem to be missing a field, in this case, image. If you click on that same line, you can dig even deeper and find examples. So Search Console can actually sort of guide you to the specific pages on your site where that problem was found. And in addition, if you click on one of those further, you can actually get a dialogue that will eventually lead you to the structured data testing to with that page and with that markup where you can figure out exactly what went wrong. So we try to help you debug this at a relatively fine grain level. So for instance, in this case, you see on the left side, the image that you're missing is marked as no image here. On the right side, you see marked in blue. And in the list of the scheme or the properties that that property was not filled, and it's obligatory. So we basically try to sort of connect sort of the lowest level of the specific page to the overall implementation of your site. All right, so now we review out of this, we want to fix and launch. Recrawl, reindex, again, keep in mind, this could take a couple of days until we actually get to all of it. And now you're ready. So you publish the stuff. And the question for you, of course, the most important one is, how do I know my return on investment? How do I know that this was useful? And how do I know what the results are in terms of the effort that I put on doing this? So these are some of the key stats. These are standard kinds of things for web pages, clicks, impressions, the number of times that the information was shown, the card was shown, click-through rate, the average position in which this was shown when it came in the search results page. And you could get all of this through the Search Analytics report. And the Search Analytics report gives you a lot of different ways of sort of parsing and filtering information to find out how each part of your site did. And in fact, it also can help you do this both with and without the markup, which is a great way for you to compare. And one of the ways, of course, are partners used to figure out what happened. So you can view impressions, click CTR and position as we discussed before. And you can filter based on, for instance, the search feature type. So notice, by the way, that some pages can appear both as a rich and no rich result, given a certain query depending on the context. And what you want is you want to try to analyze what are the pages that have the high CTR. So basically, you could use this to detect what's working well. What are the places where your implementation had the best results? Let me show you a few ways in which you could filter this. The Search Appearance filter tells you how pages with markup perform. So in this case, you can select rich results, which are the results that have structured data. You can also filter based on a pattern of URLs. So perhaps remember earlier, I said you want to implement this on a section of your site? It's under a specific folder or a specific URL pattern. You could specify this here and then sort of compare how this looks compared to the rest of the site. You could also look at date ranges, which can be useful, for instance, if you implemented this like one week and then the following week, you can compare like before and after. So this is sort of an overview of the process for implementing structured data among these verticals. And now Duncan's going to tell a little bit more about how the sites that have implemented structured data, what kind of ROI did they get? Thanks. OK, final stretch. I want to walk you through again some of these partners that we've seen across a few different verticals, but also across several different geos to show the diversity of success that we've seen so far. So let's start with the one that you just saw, Rotten Tomatoes. Again, a good adoption of structured data, which led to a 25% higher click-through rate for those results. But they weren't alone. Here, we saw Food.com, which is one of the primary providers of recipes online. They also had good coverage of structured data, with 80% of their results as rendered in Google Search, as rich results. And they saw a 35% increase in CTR, which is super encouraging. Next, going over to Europe, but also going over to a different vertical, so in this case, local restaurant listings. Lavochette put a markup on 90% of their results, and they saw, again, a fairly high increase in CTR. Moving back to recipes, but over to Japan. So here, this is an interesting case, because not only did they see an increase in interaction on those results, but the resulting session, as users landed on those pages, was of higher quality. So if you're in one of those verticals, it depends on the quality of a user landing on those pages. This is a great sign. And finally, moving to South America, we saw Nestle Brazil with 82% higher CTRs. This is, again, super encouraging. And hopefully, we will see some of you on this list next talk. So we covered three things in this talk. The first is the opportunity, which is literally to stand out on Search. One of the rare opportunities you have to customize your results visually for Google users. And we have quite a few verticals for now, and we're constantly thinking of new verticals for rollout. So if you're not on the list that I showed before, you can just go to the search page. And then you can see that the results are already tuned. Second, we show you the tools that you can use to implement all of that structured data and to measure the impact. And of course, the results, as we've seen, can be very promising. So just to wrap up, this is a quick reminder of the links that can hopefully help you get started, if you haven't already. First, the search gallery to see what the options are. It's good to click through the types of content that correspond to the content that you have on your site. The interesting tool is there to diagnose and to indicate any errors that you have in your markup, and also just guide you through the correct practices to make sure it's working properly. And finally, in Search Console, once you manage to ship all of your structured data, you can enjoy the results with the analytics that are contained therein. And that's about it. There are search office hours for any questions that you may have. Please take advantage of that. And otherwise, please enjoy the rest of I.O. Thank you very much.