 My name is Tal Oppenheimer. I'm a product manager on the Chrome team. And I'm here with Maria and Robert to talk about some of the things we've learned from building products that can work for billions of people. So just before we jump in as a quick overview, there's three main things that we're going to be covering here. The first is just talking about where we've found that our users actually are and where we expect them to be in the coming years. Second, we'll be talking about some of the things we've learned from trying to make sure that all of our products work for everyone. And third, we'll be sharing some specific tips that we have for how you can build products that work for everyone as well. So to jump right in, when we're talking about billions of people, we really need to think about where people are accessing the internet. And the reality is that internet growth is happening everywhere. So we really need to take a global look when we're thinking about this. So this is a chart from 2014 of the overall number of internet users per country, where darker means more internet users. And what you'll see that is that in 2014, China has a tremendous number of internet users with about 675 million. And then you'll see that the United States also has quite a large number of internet users at slightly under half that number. But if we fast forward a little bit, we start to see a different story here. So by 2015, you see a few other areas light up, most notably India here, with about 354 million internet users. And by 2016, we still see a similar picture, but we're seeing a few other areas light up as well, with areas like Brazil having 139 million internet users and Nigeria at about 87 million internet users. But what's really interesting isn't just looking at the absolute number of internet users, but looking at the growth that we've been seeing year over year in each of these countries. So looking at the same data a little bit differently, this is a chart of the number of new internet users that came online every year. And in 2014, you already see a bit of a different picture here. You'll see that while we saw a lot of total internet users in the United States, the new internet users was quite minimal and because the United States is honestly pretty saturated, the number of internet users. In comparison, both China had a lot of new internet users and India. But if we fast forward a little bit more, we see this start to shift as well. In 2015, there's clearly a dominant India here with new internet users. And this gets even more pronounced in 2016, last year. And if we dig into this and looking at India specifically, last year, we saw over 100 million new internet users come online in India alone. But what's really remarkable here is that this is the second year in a row that we've seen over 100 million internet users coming online just in India. And this isn't just the case over the past couple years. We still see that 65% of India's population is not yet online. So projecting forward, various estimates suggest that by 2020, there will be about 1 billion unique mobile subscribers in India alone. And this is just India. Remember, we saw other areas on this map also having quite a few new internet users. And we've seen this shift in a lot of our Google products as well. To give one example on Chrome on Android, we've seen that we now have hundreds of millions of internet users from all of these next billion user countries. And this is already the case. And it's not just limited to the browser. We're also seeing this with how they engage with certain products. For example, with Google Search, we see that Brazil, India, and Indonesia are all in our top 10 based on search query volume for Google searches. So the reality is that it's not just about where our users are going to be, but it's where our users are today. As a result, we've been working really hard to improve our own products and to share some of the things we've learned. I'm going to invite Maria on stage. I'm going to invite 2020, right? It just blows my mind. All of these people are coming online. Rahul yesterday, day before, and his mobile keynote mentioned that seven people are coming online every minute in Brazil. So these people are going to be your future users. And a lot of them are already our users. And we've been doing a bunch of research and also iterating on products to make sure that we best suit their needs. And I want to share with you a little of the stuff that we've learned so that you can apply it when you are building new stuff on the web or elsewhere for your own products. Now, Brazil, India, and Indonesia might seem like they are very different. Different continents, different types of population, languages, culture, GDP. But actually, what we found is that they share a few very common things. And I want to share three of those things with you first to put you in the right frame of mind when you're thinking about building a product on the web, what kind of things you should be considering. The first thing that is shared across all of these countries is that there is a really wide range of devices. Now, all of us have a phone in our pocket. And probably you bought your phone, what, maybe a year ago, two years ago. But in India and Indonesia and Brazil, people use a lot of secondhand phones. There is a super wide range of screens, storage, and memory. So what might work on your phone if you're building and testing it on this kind of device might not work for these users. In fact, what we know is that about 33% of users in India run out of storage on their phone every day. Can you imagine this? You look at your phone in the evening, you're like, oh, I can't take any more pictures. I have to delete something now. And that's what they do. Actually, 83% of people delete stuff every week to make space for new pictures or videos or other things. So what does this mean for you? If you're building an app or you're building something else and it's large, for a small phone with limited storage, you're going to have a hard time competing with everything else. And you're always going to be in a precarious position if someone is wondering, OK, I want to have some more space for videos, what should I delete? Should it be this 2-megabyte app or should it be this 45-megabyte app? The other thing that we found, which is shared, is the very poor quality of connection. So a lot of us here on Wi-Fi, we probably don't even notice. We're completely online all the time. 4G networks, really fast connection. But half of the users in India currently are still on 2G connections. And 2 thirds of the users in Nigeria are on 2G connections. So a lot of them actually are not even connected most of the time. And if you're building a product which relies on the updates over the air or you're relying that people have to be connected in order for your product to function, that is not going to work out for you. So we learned this the hard way. So you need to make sure that your products are either fully functioning offline. So offline is a state of its own. It's not an exception. Or you need to make sure that at least they degrade gracefully so people can still use them in some kind of decent way. Finally, data is really, really expensive. So a lot of people in those countries actually use prepaid data. So they will buy it in small packets of 10 megabytes or 100 megabytes. And they're extremely conscious with how they're using this data. So they keep track which app is using up how much. And they will turn different things on and off. And sometimes even go into airplane mode in order to preserve the data. So for us, what we perceive as a free app and it's only 40 megabytes to download is actually a big decision for them because they have to spend a bunch of their very, very precious data in order to download it. So if you're requiring people to install stuff and it's large in size, think again. So we took these three trends and then with research, we've actually extracted five principles that have made our products successful. And I want to share with you an example of what we've made in terms of changes for each of those five principles. And I'm hoping that this will help you when you're building your products on the web. So the first really big principle that we learned is that before people even start interacting with your product, you need to remove the barriers for them to do so. So remember the things that I mentioned before in terms of high cost of data, poor connectivity, and low quality, low range devices. Those are things that stand between you and these users even before they start using your product. So you need to think about, OK, can I make a solution that will not require an install? Can I have something which is very small, which works offline? And here's an example of how Twitter did this. I don't know how many of you went to the session that they did on Monday. But they very recently released a progressive web app, which is a light app. And it solves for all of these challenges to remove these barriers. So it doesn't require any installs. It's less than 1 megabyte in size. And it allows to read stuff offline, even if the user is disconnected if that stuff has already been preloaded. And it also comes with a data saver feature so that people can pick exactly which images and videos they need to download. So they don't need to see all of their stream. They can just download the things that they like. And they've just launched it for a few months now. But it's really enjoying a lot of success. So here's just some of the metrics that they shared with us. It gets over 1 million launches per day. And since they've launched it, they're seeing 20% decrease in bounce rate. So by removing these barriers, they have delighted their users. And they're doing pretty great. And they actually built it specifically for these emerging market users where the connectivity is flaky and the data cost is high and the devices are kind of poor. The second thing that we've learned is that in order to succeed in these markets, you need to optimize for speed. Your load performance needs to be amazing. And a lot of people are like, well, I don't need to do all this special work. And believe me, you're not special casing for a specific market when you're making your stuff fast. I have yet to hear anybody anywhere on the planet that is complaining that something is loading too fast. So if you make your stuff work for users in Indonesia on a 2G connection, your users in the US will be also super delighted. Now, we've been working to optimize our car products as well for speed. And one thing that we noticed is that for users in India on 2G connections, it actually could take sometimes up to eight and a half seconds for the search results page to load for them. So imagine that. You're searching and you're counting 1, 2, 3, 4, 5, and still no results. So we did some work to optimize our page. And we also didn't stop there. We actually looked at, what can we do after the click? Because we noticed that in some cases, again, on 2G connections, it could take up to 25 seconds for a page to load in India. So what we launched is something called transcoding pages. And it leads to great results. So this is an example of one of the biggest newspapers in Indonesia, Kompas. And as a result of this transcoding and page optimization, we are now consuming 90% less data. And these pages load five times faster. And what do you think users react? How do you think users reacted when they saw this? Well, actually, there's been 50% increase in traffic to these transcoded pages. Because users just perceive that everything is loading much, much faster. And then they just browse more. So it's a win-win for both sides. The next big thing that we learned is that offline is a state in itself. We need to make sure that our stuff functions, even when people are going in and out of connectivity. So not everybody has Wi-Fi. In fact, a lot of people especially go to stores or train stations in order to get access to Wi-Fi. They download a lot of stuff there, and then they spend most of their time offline the rest of the day. So one thing that we are experimenting with in order to make sure that people have a little bit smoother experiences when they're going online and offline throughout the day is in Chrome, if you're searching. So this is the example on your left. If you're searching and you're trying to fetch a page in Chrome and we notice that you're offline, first we'll show you a adorable dinosaur. And second, we show you this download button. So when we detect that you're, if you click on this button, we detect that you're going back online later, we'll download this page for you then, and then you can see it. So we are aiming to experiment in order to smooth the experience for people. Similarly in search, if someone does a query and we notice that they're offline, we'll offer them to do the search later and then send them a notification that they got their results. The next trend and a really important one is that in a lot of these countries, people use more than one language to accomplish their daily tasks. They might do their homework in English, they might talk to their Grandma in one dialect and they might use a completely different language in school. And so depending on that and what product you're building, you need to be ready to handle these challenges. For example, in search, what we've noticed is that sometimes people will search in English but the words that they're typing are in Hindi. So we launched something where if you're searching in Hindi and in English, we'll show you the results side by side and you can actually click on the top and then just switch. And people really like this. We saw that there is a 50% increase in Hindi searches on mobile after we launched this. Now the last trend and a very important one is that a lot of these users are coming online in a completely different context. And so you shouldn't expect that the product that you have right now with the UI and the flow and the graphics will fit their needs even though it has a very specific function. So a lot of them are coming online for the first time on a phone. They don't have any experience with desktop. A lot of them have never used email and they have different cultural expectations or color preferences. So we did a lot of research for our products in order to make sure that what we're launching for them is actually suitable for their needs. And you need to keep this in mind as well. So here is an example. This is the Chrome default page. And if you look at the one on the left, it's the standard one, right? Google is pretty much known for its super minimal interface. We have the search box and that's it. But what we found when we did research with users in India is that this empty page reminded them of like a big vast empty lobby where you have to walk all the way and then ask a receptionist something. So it felt very cold and not welcoming. And what they wanted to see were they wanted to be surrounded by their favorite things. And so on the right side, you will see a version of the Chrome homepage that we're experimenting with where the user can see their favorite sites that they're visiting the most often. And then also they can see articles that are related to the searches that they've been doing. So this feels a lot more welcoming. And we continue to experiment with that. So to sum up, five important things that you need to remember if you're building stuff for these markets, which we learned the hard way and you today, by waking up early and coming to the session, have managed to learn the easy way. First, before you even start thinking about how people are interacting with your product, make sure to remove the barriers for them to adopt this product. Second, make sure to optimize performance as much as possible because these connections are super slow and data is very scarce. Third, Third, yes. Make sure that your product works offline almost as well as it works when it's online. Fourth, don't assume people speak only one language all the time and make sure that whatever user flows you have in your product are addressing their multilingual needs. And finally, but not last, make sure to guide the users and that your experience in your product matches what they're expecting in terms of culture and habits. So you've seen the examples of how we've done this in our own products on the web and hopefully by now you're inspired and you wanna know how you can do this. Well, you're very lucky because we have Robert here who's gonna give you specific examples for each of these five things on how to build to succeed in next billion user markets. Thank you, Maria. So first and foremost, thank you for showing up. Like, morning of day three, I love you. I'm so happy you're here. So, I'm Robert and I'm looking at how the world is evolving and looking at what we learn. I'm gonna be here and talk about our best advice for caving to these challenges. Like, our best practices and how you also carry all of this into the things you're building. So, the first and really most important thing, though, and Maria was talking about this as well, this is not only about advice for a certain market or a certain country or a certain person. Like, all the advice we'll be giving you here will be applicable everywhere. It's gonna help all your users wherever they are in the world. So, let's start with removing barriers. For instance, as Tal was saying, in 2020, we expect about one billion unique mobile subscribers in India alone. That's a lot of people. So, how do we cater to that and how do we make sure to remove barriers for them? As you saw with Twitter Lite, when you're building something, you really make sure that you have no friction or as low friction as possible. So, no install being necessary, saving as much data as possible and working offline. These are all crucial features. But you also need to have the best possible reach with what you're building and also that the content is actually being kept up to date for your users as well. And meeting these seeds of no install or using as little data as possible are really big and hard challenges for native apps. So, what's the solution? As I'll be showing you from our experience, progressive web apps really respond to all of these challenges and also these opportunities. And I'm gonna walk you through this with a few examples and also a number of different use cases as well. Historically, with native apps, once they've actually been installed, they had really great UX experiences. Homescreen icons, offline support, push notifications, background syncing, access to sensors and much more. And the idea with progressive web apps is bringing the best of native together with the best of web. Like, what are our learnings and how can we get it all in one good package? And I'm sure you already heard a lot about progressive web apps so far before Google I.O. and also here at Google I.O. as well. So I'm not gonna delve too much into the technical details here. I just wanna quickly mention a few of the core basic features, like app to home screen, push notifications, offline support. And all of these features, it's not just something that's completely new, right? This is being built on top of what the web already has, the existing reach that the web has and then already staying up-to-date capabilities that the web has as well. One quick thing to mention though, if you haven't already implemented that, is the web app manifest. So you can add this to your HTML code and this is really foundation for the features like add to home screen and push notifications. And the way to do it is really, really simple. Just reference the manifest file from in the HTML code and then within the manifest file it describes the app name, the icons, the start URL and much more. And an important thing to note here if you look at the start URL is also to make sure to have a parameter in there is you know if your users are coming from the home screen icon or if they're coming from visiting your progressive web app through a browser tab. You can also control other things like having a splash screen, theming and background color, display type, orientation and much, much more. And we've had a number of talks here at IO about progressive web apps. So I really recommend looking at those videos but also in our developer website as well we have very detailed information how you go about implementing all of these things. But also when we talk about progressive web apps we can talk about a lot of technology, right? But at the end of the day it's about user experiences and this is really the key thing. Like user experience need to be reliable, fast and engaging. For whatever you build this is the key thing and then for us these are the key words for progressive web apps. Whatever you do this should really be your new mantra. Look over your building, does it actually match this? And we also see this kind of mental approach as the key to removing barriers for your users. And when we talk about being reliable it means that it will always load instantly for users. You will never show the users that are actually offline and you use service workers to cater to that and their clients have proxy to put you as a developer in control of things like cash and networking requests. But it's also about being fast. You need to load fast but you also need to stay fast as well. You don't want to have any janky scrolling or slow experience. Like it always needs to be very, very smooth for the user. And also needs to be engaging. And we see features like add to home screen, immersive full screen experiences, push notifications and much more that's really, really good things to get there. But another part of removing barriers that is sometimes overlooked is actually storage constraints. Like app size matters more today than ever before. And we see a lot of users never installing any new apps or never installing any apps at all or they remove the apps they're using up the most of the space on their devices. And as Maria mentioned, 33% of smartphone users in India run out of memory space every day. That's a lot of people. And for instance, if you only have one gigabyte of app storage, you can only install between five and 10 native apps. So with this in mind, we were really excited with seeing Twitter's progressive web app with the relocator to this specific issue. So Twitter Lite is under one megabyte. And compared to the native apps that only makes up one to 3% of their sizes as well. And this is great light. It's a really small file size. But they launched very recently and already so far, they see a 50% increase in page views and 60% increase in pages per session. And in India, a company called OlaCabs, they had fairly big native apps, 60 megabytes on Android, 100 megabytes on iOS. And these aren't like super big sizes for native apps. These are like, but fairly big, right? So they decided to build a progressive web app to address this. And the result was really stunning. So their progressive web app now is only half a megabyte. So you compare that to the size of their native apps and you can still give the users the same exact experience. And they also work with Polymer to achieve this, both to get the small file size and the good experience, but also working with Polymer to make sure that they would have support for the UC browser, which is one of the very popular browsers in their main market. And Polymer is natively supported in Safari, Chrome, and Opera. And with Polyfills, it works on Firefox, Edge, UC browser now, and IE 11 as well. And whichever framework you use, I mean, you should use what works best for you. This is just one example, but make sure it also has a small file size. Like in the case of Polymer 2 that was just released, it's only 10 kilomites on Chrome, 30 kilomites on Safari, and slightly larger on Firefox and Edge and a couple of the other ones. And in Brazil, we saw a company called Terra. And they recently built a progressive web app as well. And for them, it's already a success. They're seeing users visiting twice as many pages as before, but also spending twice the amount of time in their progressive web as well, compared to their previous mobile experience. And the second challenge, but also opportunity here, is really optimizing speed. You want to make sure to reach your users, but also make sure that they don't go elsewhere as well. So coming back to OlaCabs, their progressive web app has an enviable first load of only 50 kilobytes. And repeat load sizes can be as small as 10 kilobytes. And that actually means 500 times lighter than the iOS app and 300 times lighter than the Android app. So, I mean, it's completely different walls here, right? But also this load data consumption makes sure that the first load is about three seconds and then repeat load times could be down to about 1.8 seconds, which is good on its own. Like it's a fairly good loading time. But in this case, these loading times are in 2G or ultra-low 3G networks, which of course is the defining factor to actually reaching your users. And for them, cating to many, many millions of people in India, this is the key thing to actually being able to reach them to begin with. Another really interesting number that we see is that 53% of the users abandon sites that take longer than three seconds to load. And 53% of users, that's over half in three seconds. That's not a long time. So you can work a lot with progressive web apps and achieve a lot of really good performance. But generally with progressive web apps, we've seen that for the second and subsequent loads using progressive web apps and service workers, it's a really good experience. But what about the first load? What about if no matter how hard you work on it, what if it's not fast enough for your users? One option we've been looking at here is called AMP. And accelerated mobile pages. And one thing that I want to stress here is that it's an open source initiative, really trying to make the web better through fast and high-performing pages across different devices and distribution platforms. And the idea with AMP is that you're guided to only do things that are fast. It's almost impossible to make slow AMP pages. So I'm going to talk briefly here about what AMP is, but also how it ties into progressive web apps. And AMP consists of a few different things. The first thing is AMP HTML. And it's basically regular HTML with some restrictions for reliable performance. I like these cute little balls. It's like a morning shot or something. But basically it's HTML, but it's extended with some custom properties that you will need. And some HTML tags are being replaced by AMP-specific tags or so-called AMP HTML components. The second part is the AMP JavaScript library. And the idea is really to ensure the fast rendering of the AMP HTML pages to manage resource loading and also give you support for a few other different custom tags I mentioned. But it also makes everything that comes from external resources load asynchronous. So nothing on the page can block anything else from rendering. And finally, you have the Google AMP cache. And the idea with that AMP cache is that you can serve cached AMP pages. So it's a proxy-based content delivery network for delivering all valid AMP documents. And it caches them, improves them, and improves the page performance automatically. So these three together make up the foundation for AMP. And if you want to get started and create your first AMP page, it's really quite easy. It looks like any basic HTML page you've ever seen before, just a few regular tags. But as you can see at the top, you have the lightning icon indicating that this is an AMP page. You have some boilerplate CSS needed to make sure you have the consistent rendering and look across browsers and platforms. And then finally, you include the AMP JavaScript library. And then you're good to go. That's your first AMP page. It works. And then if you want to do things like including an image, you have the AMP image component. And if you look at it, it kind of looks like the image element in HTML that you're used to. It has the source attribute, the alternate text, dimensions, and all of that. But the interesting part here is that the AMP runtime can choose to delay or prioritize resource loading based on different things like view for position, system resources, connection bandwidth, and other factors. So basically the runtime will take care of it for you to manage the image resources, make sure that it loads the best and most suitable things at that specific time. And one company called Somatos started working with AMP pages and they had a four second page load before and they're down to one second now. And again, on really slow networks as well. And I mentioned I was gonna talk about AMP and progressive web apps and how they're connected to each other. And we see two different approaches here. One is using AMP as an, come on. One is using AMP as an entry point into your progressive web app. And the other one is using AMP as a data source for your progressive web app. So taking a look at the first one and using AMP as an entry point, AMP selling point is really almost instant delivery of pages, whereas for the web apps enable much more interactivity and engagement enabling features. So a good approach here could be have an instant first load with AMP and then upgrade the user to a progressive web app. Basically start fast, stay fast. And the way to do it within an AMP page is to use a component called AMP install service worker. It basically allows you in the AMP page to warm up a progressive web app in the background. So then for the next click from the user you can instantly load a fully featured progressive web app. And looking at this component you have the source attribute here which is specifying the URL of the service worker you wanna register and they have an optional attribute called data iframe source which could be the URL of an HTML document to register a service worker. And then finally you need the layout attribute which must have the value and no display. And looking at this combination between progressive web apps and AMP we go started working with that and for the AMP pages they had a previous page slow time of about 12 seconds and it's down to 2.75 seconds now. And for the progressive web app shell they had a loading time that was almost nine seconds before and they're down to 1.63 seconds now. And again these tests are being done on a Nexus 5 on a slow 3G connection. So just looking at the improvement and again coming back to the user experience it makes such a massive difference for them. But it's not only fast, right? This directly leads to actual results. So with the new implementation these now see 74% of all visits actually turning into conversions. And all in all the conversions have gone up now on the site 95%. And looking at the other option of having AMP as a data source for your progressive web app maybe you started with building something with AMP for instance where you haven't built a PWA yet. And the idea here is that you can still reuse your AMP content within the progressive web app. And a common scenario could be that you're building a progressive web app as a single page application that connects to a JSON API through AJAX. And I know it kind of looks like I'm trying to set a world record in acronyms here. I'm sorry about that. It's a lot of fancy words. But the thing here is like with the JSON API here then it will return a number of data sets to drive the navigation and then the actual content of your site. So the way you can do it is that you start by including shadow AMP in your progressive web app. You load the AMP library in the top level page but it won't actually control the top level content. It will only amplify the portions of the page that you need it to. And then secondly as you would normally do you handle navigation in your progressive web app but then the final twist here that you then use the shadow AMP API to render AMP pages in line. So it could look something like this. You have a progressive web app shell around everything but then when you start tapping you get the AMP content and the AMP pages instantly within the progressive web app. So it's been a really good combination in that way. Another thing I wanna mention is the network information API. And we had this for a while but people have been really asking for detailed information about bandwidth to convey the HCP client's network connection speed. And network speed here is provided as an estimate of the current transport RTT and the network bandwidth. And it also takes constant variation and user variation into account. As you might know, 4G doesn't actually always mean the 4G speed you would expect. But still though, if you're building things you're doing a really good job but it's not really fast enough for users at the end of the day. How do you know when to deliver even lighter experiences? And one really good option here is to check for the save data request header. And this is available in Chrome and Opera and in Yandex browsers. And the idea here is to deliver fast and light applications to users who have opted in to the data savings mode in their browser. And for instance, in Chrome, if you turn the data saver on it will send this header with on as the value. So it basically looks like something like this. It's easy to check the header and then know what the users want and need here. But also if you're building something or using something like a service worker you can inspect the request headers and you can apply the relevant logic to optimized experience. So you can, for instance, return an alternate response like different markup, smaller image files, more video size and much, much more. And within the Chrome DevTools if you start inspecting headers there you will just find save data really quickly and you can adapt the code. The third part here is about addressing intermittent connectivity. And Maria showed us before in the what we learn section that around 50% of the users in India are on 2G. So slow or intermittent network conditions are really big challenges for reaching users but also giving them a good experience. And here we really see service worker as a key technology to address that. So what are they and how do they work? Basically it's a programmable proxy sitting between a network and the browser but it's more than that. So when a page registers a service worker it adds a set of advent handlers to respond to things like network requests, push messages, updates to the service worker and much more. And because it's being event based it doesn't need to be a resident in memory unless it's handling one of those specific events. And also a kind of a side note here there are two interesting options for poor network conditions but also devices with slow disk access. And the first one is using timeout for slow networks. So for instance if you have a slow or intermittent network condition you can create a timer in the service worker where you give the network a chance to deliver a resource within say one second but if it doesn't then you can fall back to the local resource. A small note here like don't set a timer that's too long though because the service worker might get killed or replaced by a new service worker. The other really fun thing is race conditions because with some devices it might actually be faster to go to the network and get the content than going to disk which is not what you would expect but this is a really good interesting way of testing that. And of course both with the timer and with going to disk or not it's always important that you get data from the network to have it locally just in case. And Marie also mentioned Nigeria and seeing two thirds of the users being on 2G here. And one company there called Conga added service worker to streamline the site to help consumers really reach the parts of the sites they wanted to browse. So you go through categories to can review previous searches and can actually even check out by them calling into order all by being offline. And as you can see the results was much, much faster than native like 92% less data for the first load and 82% less data to reach the first transaction. But it wasn't just faster than native it was much faster than the previous mobile website as well. So 60% less data for the first load and 84% less data to reach the first transaction. And the fourth part and Maria was talking about over 20% of users in countries where we see the next billion users are coming online are searching in two or more languages. So we have something called the search console which is tools from Google to show how your site is doing in Google search. But you also have something in there called search analytics which looks like this which shows you queries, positions and results, clicks, click through rate and much more. And you can filter information in many ways in here like applying the country and the device filter for instance to see from which countries we're getting the most mobile users. And also in this example, the majority of the users of the site are coming from China, Indonesia and Malaysia. So it's really worth investigating whether the contents available language they understand and also if they can complete the key user journeys. You can also track performance, specific pages, specific queries and much more. And finally about guiding your users. It's really about making sure to help users when they come to your website the first time. And we've seen really good numbers from add to home screen here. In this case with OLX, like the users browsing around, they're looking to see what it's like. And then you get to a certain point where you get to add the home screen prompt pop up. And they then choose to add it to the home screen and then to get the icon of the home screen it's really easy for them to get back as well. And one really, really interesting number to share with you here now that I actually don't think has been anywhere else here at IO so far is that we see users five to six times more likely to use add to home screen than installing the equivalent native app. That's a pretty big difference. And in India, we saw Flipkart with 63% of the users on 2G. And again, being fast was essential, right? And user service worker and all that to achieve this. But one really interesting part here is that they really worked on when to show that to home screen prompt. And now they see really great results. So 60% of the users are now coming from the home screen icon, which is fantastic. But it's not only a lot of visitors, it's also high quality visitors. So people coming from the home screen icon, they convert 70% higher than the other ones. So summing it all up, as you see, in applying the five principles that we learned about, removing barriers through using progressive web apps and the web. Optimize speed by using AMP and progressive web apps together, but also the network information API and the save data header. And for addressing intimate connectivity, service workers is really your best friend here. And make sure to have multilingual support and understand your users and which languages they're actually using. And then adding features like add the home screen, which has been really successful to make sure that you actually guide the users throughout the journey. And with all of this, we hope this is good advice and good numbers and good learnings for you to go out and build for your next billion users. And if this sounds great, which it does, right? You will go to this website and you will get a lot of advice and guiding to actually how to get started. And also, Tal, Maria and I is just gonna be out around in the corner and the big ground fluffy thing in the mobile web sandbox. So please come over, ask us questions and tell us what you're building. On behalf of all of us, thank you and go out and build great things.