Sessions is temporarily moving to YouTube, check out all our new videos here.

Firebase 2017 Update and the Habits of Highly Successful Developers

Laurence Moroney speaking at SWmobile in June, 2017
JustUploaded
 
Great talks, fired to your inbox 👌
No junk, no spam, just great talks. Unsubscribe any time.

About this talk

What's new in Firebase for 2017.


Transcript


So 51%, this is the number of developers of mobile apps that we found through research that we've done ourselves as well as through partners that are below what we call the poverty line, and the poverty line is making $500 or less on your app per month. And so this number came from research that was done towards the end of 2016. We did some at the beginning of 2016 that said it was about 48%, and the trends we're seeing show that it's continuing to grow. We don't have any research yet in 2017, but shows that the number of people who are below this poverty line are continuing to grow. You probably all have seen that. I remember in 2007 when Apple first released the iPhone. You know, I released a, I put a really silly little app into the App Store, and it used the Microsoft Translator API. I mean if you were to do that today, you wouldn't make anything because the quality bar has gone up. The amount of time and effort we have to put into building apps has gone up, and the competition of course has increased. So the second number, 29%, this isn't Brexit. Can anyone guess what this one is? Okay, good. So this is in contrary to the previous number, this is the number of developers that we've found are what we call above the successful line. Then we break that number, and as well as the 51% that you saw earlier the vast majority of those are below $100. My little French translator app is definitely in that column, in the below $100. I think I earned $15 on it last year, but the idea is like vast majority of developers are in that space. So what we've been doing at Google is we're saying we really wanna empower mobile development, and we want to empower mobile development not just on Android, but also on iOS and the web because one of the main reasons for that is that when we look at the highly successful developers, those folks that are in the $25K box, we started looking at some of their habits. And one of habits that we saw from them was that 88% of them are actually targeting all three platforms. We had some data that suggested that we love Android developers, but if you only build on Android, it's hard to be successful. We love iOS developers, but if you only build on iOS, it's hard to be successful. And we love web developers of course, and mobile web developers, but if you only build on that it's hard to be successful. As as we were looking through when we were building Firebase we realised, look at these folks in the top bucket, and 88% of them are actually targeting all three platforms. These aren't the iOS fans. These aren't the Android fans. These aren't the web fans. these are professional developers who are actually successful at making a lot of money by targeting all three platforms. So at the time we were building out something to service folks, to allow folks to move towards the right-hand side of this diagram, at the time we imaginatively called it the Google Cloud Platform. Sorry, the Google Mobile Platform because we already had a Google Cloud Platform. And then we bought this start up called Firebase, which you may have heard of. And the idea was that we decided to release Firebase as a new product last year at Google IO, but the idea was that Firebase, the start up, anybody had used it before the Google acquisition, out of interest? A few, okay, so there was some great stuff in there. There was realtime database, there was authentication and there was stuff like that. But we decided to purchase that because we were building out a platform for all of these services that we realised that developers need to be able to reach the right-hand side of the diagram that I showed earlier on. And so we had been building like a realtime data store. We had been building authentication, and we also had like all these grow technologies like dynamic links and invites and ad mob and all that kind of stuff. But when Firebase was available to purchase we decided that it was the ideal thing for developers. We knew developers loved it. We loved it too, so to actually buy that and to merge that into our efforts. And it was also around the time that, was it ... What was the name of the API that Facebook bought and then killed? Parse, thank you. I keep saying Slack, but it's not Slack. You know, it was also around the time that Firebase bought Parse, and then Parse died. And so we were like, you know, we don't want Fairbase to die, but we also really don't want Firebase to continue just being a database and just being authentication. We realise that for developers to be highly successful there were a number of services that they need. There were services that we were working on, and let's merge that into that, and let's release that. So at IO last year we released Firebase, and then there is a whole bunch more services that we're working on and we're continuing to add to this. But today I just wanna talk through some of these and why we built them so that developers like you can be towards the right-hand side of the diagram that I'm showing. So one of the things about Firebase that we realised, and when we look at the habits of highly successful developers, that they're very much driven off of analytics. Now I used to spend a lot of time as a development manager, and usually as a development manager the last thing that you build into your app are analytics. And we've probably all sat around in those meetings where it's like the business people want one set of analytics, the marketing people want another set, the perf people want another set, the developers want another set. And it's like you take a look at once you realise all of these analytics that you need to build into your application, you're gonna have to push your ship time back by six months, nine months, 12 months, something like that, so you compromise and you don't build any. So part of our decision making process in Google was that we had this product called Google Analytics, and we really wanted to build a mobile first version of that. And that's where it was originally called Firebase Analytics. At IO this year we rebranded it to Google Analytics for Firebase because our marketing people are really boring. And the idea behind this though, it still stays the same, and that was that we wanted developers to be able to get a core set of analytics for free in two ways. Number one, you don't pay a dime, and number two, you don't write any code. And most of us think in terms of code. Our managers think in terms of dollars and cents, sorry, pounds and pence, so we wanted to be able to like meet both of those and take both of those boxes when it comes to free. And that's what Google Analytics for Firebase was born. If you're an Android developer, there's a single line of configuration you add to build If you're an iOS developer, there's a single pod that you add, and you get a full set of analytics, and you're done. And then if you can imagine, that's common analytics that you'd expect like app open, app close, open this view, open that view, those kind of things. But then of course if you want custom analytics, then the idea was there was an API, and unfortunately there's some code that you have to write for custom analytics for things that you do uniquely. And then you'd like write code for that and put it in, but still from a dollars and cents or pounds and pence point of view, that's actually free. And one thing I'd like to show is that one of the things that we released just this year at IO, just a couple of months ago was the idea of what was we called the stream view for analytics. Like if you were a Google Firebase user in 2016, you would have realised that when you start like logging analytics you can't really see them for about 24 hours. We realised that was a bit of a mistake, but we didn't want to hold that up from releasing it. So we've been working on optimising analytics, and now analytics are usually available within 30 minutes or less. So the idea here behind stream view is like there's an app at Google Maps called Bingo Blast, which is a casual game, and this is a real time view of people playing Bingo Blast, or at least within the last 30 minutes. So we can actually see a heat map here of people playing Bingo Blast. So like you know if I go into the Google Maps, where's my cursor? If I go into Google Maps, then I can zoom in. We got a lot of Bingo Blast players in the U.K. Maybe, no, nobody in Bristol playing it right now, sorry. And one of my personal favourite parts of this, and I was sharing this with the guys in the bar earlier on, is that there's something very voyeuristic about this. It's that you can take a user snapshot, so you can see a random user, and what that random user is actually doing and playing your game right now. So right now I'm looking with somebody with a Samsung in an unknown area who isn't really doing that much. Let me find another one. And so if I, let's see, if I go back to location. So the idea is like have you had one of, have you ever built an app, and then sometimes you wanna hand the app to a random user and look over their shoulder, and have no interference with what they're doing in any way and see how they're using their app? That's the idea behind this user snapshot, so let me try it again. Let me pick another random user so we can see what they're doing. And here's another boring random user who isn't doing much, but when I usually do this demo it's much better. You know, the iOS users tend to be far more engaged, so let's look at the iOS version of the application. So we released it on both Android and iOS. So these are the iOS users. Drumroll. Okay, they're all over the place. Let's pick a random iOS user so we can look at a snapshot of what they're doing. And see, told you the iOS users are usually more interesting. So we can start looking at. So we built some custom analytics into the app. So I can actually, it's really, it's kind of creepy, but it's also kind of cool. But whoever this person is in France, that I can actually see everything that they were doing. So like you know, Bingo Blast is kind of like it's a Bingo game, but you also spin some slots to earn some virtual coins, and then you start doing things in it. So I can start seeing some of the analytics that they have here is like, you know, this is obviously somebody who shares a phone with somebody else. And then there are multiple Facebook users. It might be like, I don't know, a husband and wife sharing a phone, or parent and child sharing the phone. So here you can see the Facebook user change analytic event, so somebody signed out of their Facebook account and then signed in with a new Facebook account. So the new user is logged in. We got the signed in equals true. We can see they're on iOS, and those powers they have in the game, it's like your level. We can see they start spinning, they started a new session. These folks have a lot of coins. They have 40,000 coins. So you can start actually ascertaining how your users are using your application. Obviously there's no personal identifiable information here because then that would be really creepy, but it's a great way so that you can start taking a look at how users are using your application. This is a single user, of course, but there are many, many aggregate views you can get here for like what parts of your screen they're hitting, who's playing relative to the number of coins, what countries are you popular in, all those kind of things, and all those analytics like I say come along for free. So when these analytics come along for free, you can then use them to determine how people are using your application. So next up as part of analytics, that was one thing that we just launched this year at IO, and that's the stream view that I just showed. And then there's also a debug view. So for example if you release your application as a beta, and you wanna release it as a closed beta, it's something the idea is to help you manage that beta by automating it. So you can put a number of beta analytics in there so you can see how users are using your app. Are they engaged with it? What are they doing, what are they not doing? Where are they crashing? All that kind of stuff, so again just a really neat way for you to actually look at how your application is being used in debug. So if you wanna spread your application around the world and have a large scale beta to see how it's being used, then that's available to you, so that's all a part of Firebase Analytics. And then finally after releasing your application if you're lucky enough to have millions of users, and you wanna be able to analyse how they're doing, the idea is one of the things that we've been adding and continually improving is the ability to export from Firebase Analytics to BigQuery. BigQuery is part of the Google Cloud platform. So you can then start slicing and dicing the user data the way that you want instead of according to the console that we've given to you. And then one more, this one part, this is always my favourite slide to show because before I joined Google I worked for Microsoft, and at Microsoft I was a Windows phone developer and an iOS developer, and there was always the urban legend that iOS developers, there may be less of them than there are Android. Sorry, iOS users, there may be less of them than there are Android users, but iOS users spend more money. If we take a look at this slide, this was a screenshot that I took from Bingo Blast, and in this case we had 22,700 active users of Bingo Blast who spent $2,000. But we only had 5,000 users on Bingo Blast on iOS, and they spent $3,000. All right, so it's again thinking of the highly successful developers targeting multiple platforms, this to me was just one little signal again supporting that because where like the Android users were spending maybe 10 cents per user per month, whereas the iOS users were spending, was it 60 cents per user per month, that kind of thing. So it was very, very effective for us when were building Bingo Blast to target both platforms. So earlier on when I mentioned the idea when at Google we wanted to build this Google mobile platform which we ended up calling Firebase to have two sets of services, one to help developers build an app quickly, and common things that developers need to do to be able to bring an app to market with high quality, to actually provide a lot of those services for you. And the second one was the number of services for growth hackers, to be able to grow you app. I primarily work on the growth side of Firebase. If you were at IO, I did a number of growth talks there, and like I manage the growth track and that kind of stuff. So I tend to talk more about that. But in the Firebase space, so when it comes to developers there were these services. Real time database and authentication came originally as part of the purchase of Firebase, and then we've added hosting, cloud functions and cloud storage to that. So first of all, how many people have used the Firebase Realtime database? Oh wow, quite a few of you, all right. So I'll go over it quickly for those who haven't. The idea behind it was that we wanted to have a cloud-hosted NoSQL database. NoSQL so that you don't have to start thinking in terms of writing and maintaining code that runs on a server or in the cloud. All of the code that you build runs within your app or within your site. And as a result you have less places to manage and maintain code. There's less places where bugs can happen. There's less places to deploy code to, and we made this very conscious decision to build a realtime database in this space. And when the folks at Firebase had already built one, it was a natural fit for us to build that and enhance that with our cloud platform. So the idea was really you are a mobile developer. You are not a database developer. And if you think about it in terms of like for people building database driven apps, you used to have an end tier architecture where you'd have a SQL database, and then you'd have code that sits close to the data like stored procedures, SQL queries. Then you'd have code that wraps that to make it accessible to the outside world. Then you'd probably have a mobile interface on that. And then on your mobile app you'd have a proxy layer that talks to the interface, and then finally your mobile logic. And there were all these tiers of code that you'd have to build and maintain. So we really wanted a responsive, fast realtime database so that you write code in your mobile app, you get rid of all of these tiers, and you can focus on building your business logic, and that's what the realtime database was all about. And then the idea again behind the realtime database, we live in a multi-device world. So many of us have a laptop and we have a tablet and we have a phone and maybe we have a smartwatch, something along those lines. And if we build an app that we use but it runs on all of these platforms, we need to be able to synchronise the data across all of those in realtime. So for example, if I'm consuming some kind of an app, and I add data in my phone, I want to be able to see the data instantly or close to instantly on my watch. And then it's the idea behind the realtime database was something that was on the cloud that was able to fan out at scale to multiple devices so that these can all be in sync with each other, and that's the idea behind the NoSQL based realtime database. So then the second of these, and probably in many ways I would argue the most valuable is authentication. So we've done a lot of research about how people leave your app and why, and the more steps that you have in somebody signing up to use your app, it's effectively, I mean a rule of thumb is that every step that you add reduces the population by 50%. So if you, for example, have a million people who come to your app because of an advertising campaign, and you have one sign up step, they're gonna go down to half a million. If you have another sign up step, they're down to a quarter of a million. If you have another sign up step, they're down to 125,000. So the idea is with all of the research that we've done and all of the work that we've done in building things like Google Plus and Gmail and other sites like that, we wanted to optimise that UX flow for users so that it makes it as easy as possible for them to sign up. And then secondly for users to sign into your app, again research that we've done found that many successful application developers did not build their own user store because the amount of time and effort that you have to spend to build a user store is really high, but to maintain it in this world of hackers is even higher. So we made a conscious decision to make it as easy as possible for you to have a single API so that you can sign in with Google, sign in with Facebook, sign in with Twitter, sign in with GitHub. We're adding more all the time, and I'd live to hear feedback if there's any other service providers that you'd love to have added. I know we're working on the popular Chinese service providers at the moment and stuff like that. And the number one request that we had was phone number auth, so instead of using like a username and password, and as part of our Digits acquisition we've been integrating phone number auth from Digits into Firebase auth, and we announced that at IO this year. So again the idea was that like if you think about it, if you only ever use one part of Firebase, and by the way it's not like you'd pick one, you pick everything. You can chop and change any of these technology. You're gonna use the one that you want. If you only ever use one, I'd suggest that you look at this one because it can save you a lot of maintenance costs in the long run, and it's completely free to use, except for phone number auth, that we have to charge a little bit for that because generally when you sign up for something with a phone number there's an SMS message is sent to verify that phone number, so we just pass on the cost of using that infrastructure to you. But I think, I don't remember the exact cost. I'm not a salesperson, but I think you'll get up to 10,000 a month for free or something like that. So it's only if you're building a huge application that you have to worry about those costs. Functions is the new hotness. We released functions this year at the Cloud Next, which was back in March, and the idea behind functions was all of the stuff that I've been saying about Firebase and writing code that runs in your app is all very good, and it's a conscious decision that we made to reduce your complexity, but there's always code that you need to write to runs on the server. There may be some custom code that you want that you don't wanna ship in the app. There may be some stuff that only makes sense to run if it's on the server. And we've been working on functions. We launched it just a couple of months ago. It's still quite limited. There's a whole bunch of extra stuff that we're adding to it, but the idea behind this is that it's no.js based stuff, and any kind of events that happen in Firebase, like a database change, an analytics event, an auth event or something like that, is that you can write no.js code to respond to that. And the neat thing behind this is that you don't have to think of a specific server that you're deploying that code to. You just write that code in the Firebase console, and you don't think about servers or anything like that. We handle all of that behind the scenes in Firebase. And so that's what function's all about, and it's very useful if you wanna build some applications that have some backend logic. For example, I used to work in financial services for a British company called Reuters, and we had a number of financial analytics that were our crown jewels that were ways that we could measure the value of a company, and there's no way you would put those analytics into a mobile application where they could be reverse engineered, and that code would have to run on a server somewhere. And that's the idea behind functions, so that kind of code isn't being deployed in your iOS or your web or your Android application. Next one, and it's kind of a funny one, and it's amazingly useful and very few people use it, and it's Firebase Hosting. So if you build a mobile app, and you wanna deploy it to the App Store, you wanna deploy it to the Playstore, you almost always need a website. And then as a result developers have to go off and find web space and rent that web space and get the domain name and map it to it. Maybe it's PHP or maybe it's something else, and deploy a website to that, and that's just this extra workflow that you have to go to for the point of view of deploying a website that you need to deploy so that you can be, the App Store will let your app in or the Playstore will let your app in. So we said in order to reduce all of that friction we built hosting into Firebase. So it's free, and you can map a domain name to it for free, but the other neat thing about it is that it's built on our cloud platform, so it's globally edge cached, and it's really fast, and it's very simple to use. So I always like to give a demo of this one at this point just to show how fast it is. So we're on a shared wi-fi network here, and as a hobby when I'm not a Googler I actually am also, I write comic books, and I do a lot of renderings and previsualizations of characters for these comic books. And so I render the biggest image that I could render, and it was a 100 million pixel image. And I put it into Firebase hosting, and I'm gonna download it now, and how long do you think it would take to download like a 24-bit per pixel, 100 million pixel image on the shared wi-fi here at Just Eat? The Just Eat guys are getting panicky now, right? How long do you think it would take? - [Attendee] Five minutes. - Forty minutes? - [Attendee] Five. - Five minutes, okay. Should we time it? Boom! Okay, it was that fast, and I didn't cache it. I cheated a little bit, though. So the idea with Firebase hosting is you can store static files in Firebase hosting. So it's not a PHP type of site or anything that on site. HTML, JavaScript, CSS, that kind of thing. So this is my 100 million pixel image. I cheated a little bit because there's a really JavaScript library called Open Seadragon, and Open Seadragon uses a similar technology to Google maps where the ideas in Google maps is you know when you zoom in and you zoom out of a map you get different tiles. So while this is 100 million pixel image, the way I'm zoomed out now it's probably about an 800 by 800 image, so it downloaded really quickly. And if you look closely you probably saw all the tile forming. But I loaded it, and as I've been talking it's been downloading the higher resolution tiles in the background. So just to show that it's a 100 megapixel image, if I zoom in on her eye, we can see it gradually getting clearer, and we can see the reflection in her eye of what was behind the virtual camera when I rendered this. And the other part that I really like to show is that 3D models like this, the idea is that you build the 3D model with like this grey character, but then there are photographers who photograph skin from real people so that you can map the skin onto it to make it look realistic. And whoever the model is who provided the skin for this, on the day she was photographed had dirt under her fingernails. Just to show it's a 100 megapixel image. And if you look at the monitors in the background here, you probably can't see the writing on them, but as I zoom in some of them have writing, and you can start seeing it, like Claude is written there, and stuff like that. And this is all hosted in Firebase hosting. As you can see, it's fhscreencast at firebaseapp.com. You can go on there and take a look at yourself and zoom and play with the image. So these are the kind of things that you could do with Firebase hosting, and it's why it's one of my favourite technologies that's in there. And again, it's a free hosting provider. Right now you can see I'm using the fhhosting.firebaseapp.com, but I could map a domain name to that if i wanted, and you get everything globally edge cached, etc., etc. It's why I'm here in Bristol and it's working just as well as it worked for me back home. So next up is storage. So thinking again of cloud scale and cloud speed storage. If you're building an app that requires you to store file on your user's behalf, particularly large files, you have a programming nightmare when it comes to handling uploading and downloading of those files, particularly on a mobile when it comes to, even in a advanced civilised country like the United Kingdom or the United States or Ireland or other places, people move around. They might be driving, or they might be on a train when they're uploading or downloading a file, and networks are changing. And as a result, you generally have to write a lot of code to handle handshaking if you're downloading a large file and you lose your network connectivity, you don't wanna restart downloading the file again. So part of the reason of what we've been building behind this is that so not just you're getting the storage, but the APIs give you the ability to have the reconnection and resyncing when you're uploading and downloading. So that's the growth stuff, very quickly. We also have some quality stuff in there. So when you're building an app, not just are you able to build a better app, but we also want to think about the things that you need to do to build a quality app. So the first of these is crash reporting. The number one reason why people uninstall or drop an app or give poor reviews is crashes. So with crash reporting the idea was that if you think about at stack trace, but crash reporting is a remote stack trace. So if somebody in Korea is using your app, this happened to me personally. Someone in Korea was using my app, and they had a crash. Instead of me getting on a plane and flying to Korea to figure out, or buy a Korean phone and try and figure it out, I was actually able to see a stack trace of what had actually happened to them, see the impact of that \ and fix it. So again, it's integrated with analytics. I spoke about analytics at the beginning. So with analytics you can start to defining audiences, and like if you have millions of crashes, you can start filtering them by audience. And then once you start getting that kind of intelligence, that this audience had this crash, then you can fix that and deploy a new version remotely. There was one great talk at IO. I don't know if you guys are gonna cover it later, where it was we built an application for Santa tracking. Every year the Google maps team like to track Santa Claus, and they built an app for Santa Claus, and they built it modularly so the idea was that if this app crashes on Christmas Eve, we're screwed, right? Because there's no way we'll be able to build and ship a new version of it before the big man finishes his rounds. So the idea was that this was built modularly with like many games and all that within the app, and using crash reporting, if it crashed in a particular area, and it actually had happened where there was one country where one of the mini games crashed in, then using another technology which I'll talk about in a moment called remote config, using crash reporting we were able to determine this location it crashed in. Using a remote config we were able to turn off that module in that country, and then everybody continued to have their experience without us needing to ship a new version of the application. So crash reporting's really call. Perf monitoring, similar kind of things. The idea is that as well as crashes you wanna see how your application is behaving in different places and with different analytics audiences. Perf monitoring actually gives that to you. So you can see network connectivity. For example, in this case you can see in Sweden for some reason they had a pretty poor network issues, or relatively poor network issues where in the rest of the world they hadn't. And that then helps us, helps you to be able to figure out why in Sweden, for example in this case, your app's doing badly so you don't get bad reviews in Sweden. Test Lab for Android, okay, one quick question? Who here has a Pixel XL? You. Do you mind if borrow it for about six months? - [Attendee] Yeah, sure. - They usually tell me to get lost. Okay, that's better. I need to debug my app though, and I'm gonna release in six months, so can I now borrow your phone? No. - [Attendee] - Now I really wanna borrow it. So the idea behind Test Lab for Android is that you know not everybody has every phone. I don't even had pixel XL. I wish I did. So but the idea with Test Lab for Android is whenever we've worked with developers, and particularly Android because there's such diversity. It's a lot easier for iOS developers because there's relatively little diversity, but with Android, particularly globally there's such diversity of platform that it's really difficult for developers to be able to test on every platform that they want to test for. And even we at Google, like it's hard for me when I'm building an app to test it on a Pixel XL because I don't have a Pixel XL. So part of that problem we wanted to solve with Test Lab for Android for all developers was a case of we built a data centre with every type of Android phone we could find, either in a physical version or in a virtual version. And then the idea is that you build your application, you upload you APK, and on Test Lab for Android we'd run a whole bunch of tests on that for you. So it's robo tests of standard things like open and close app, that kind of thing, as well as custom tests that you can define, and then we sent back screenshots and stack traces and all those kind of things. We find this particularly useful like in some countries where some devices aren't available. Like for example I think the Pixel XL was available here much later than it was in the U.S., but if you wanted to develop and target for the Pixel XL, instead of flying to the U.S. and buying one and coming back and testing it, you could actually be able to do that with Test Lab for Android. So again, thinking of the habits of highly successful developers, we really wanted to build this to help folks to be successful. And I have only a few seconds left, so I'm gonna very quickly go through some of the grow stuff, and you can ask me about it in the pub later. Cloud Messaging is one of the most popular parts of Firebase. The idea behind Cloud Messaging is to deliver realtime messages to users. Earlier I mentioned the number one reason why you get bad reviews in the App Store and the Playstore, and that was crashes. The number two reason why you get bad reviews is spam messages, spam notifications. When we take a look at spam notifications being received against uninstall rates, it's scarily bad. So the idea is we built Cloud Messaging so that you can drive it off of analytics. So instead of you sending a message to all of your users when it's only relevant to maybe 10% of them, you can define analytics audiences and send messages to those, that type of thing. Or there's a thing called topics where people can subscribe to a topic and can only receive messages from that. In November of last year we announced that we send through this infrastructure one trillion messages per week, and 98% of those messages are received on connected devices in less than 500 milliseconds. We haven't announced the new figure yet, but we're close to double that, so we're continuing to expand this. It's continuing to grow hugely, and we find for highly successful developers, if you can send the right notification at the right time to the right user, you can grow your app. But if you send the wrong notification at the wrong time to the wrong user, you can lose your audience. So we've really tried to integrate this as much as possible with analytics tools so you can be really smart about how you use them. And also when messages are received, that it goes into the notifications funnel in analytics so you can tell which messages are effective and which aren't. So the last one I'll go into, because then I'm running short on time, one of my personal favourites is how many people here use the Google search engine? Nobody? so Google search engine has become part of everybody's everyday workflow. And maybe some of you use Bing, maybe some of you don't, I don't know, but it's become part of almost everybody's everyday workflow. And so we've built this technology called App Indexing based on the logic of if you have content on the web, and you have the same content in your app, doesn't it make sense that the users who have taken the time and effort to instal your app, that if they're searching for that content, it should be surfaced in your app instead of them being taken to a bunch of random websites, and that's the idea behind App Indexing. So for example, if I build, I love baseball, so if I build a website for my favourite baseball team, and if I build an app for my favourite baseball team, if a user somewhere in the world has installed my app and they're searching for the roster of my favourite baseball team, the idea is to direct the user to the app instead of to a website for that baseball team. The reason for this is the average user can have up to, I can't remember, I think it's 58 apps on their device, and 90% or more of those apps are only ever used once. How many of us have gone to the App Store or the Playstore, we've downloaded an app, we've installed it, we play with it once, we forget about it, and we never use it again until we're running out of space on our phone, so we uninstall it or we buy a new phone, and that's not the app that makes the transition. So the idea behind App Indexing is to really help reengage with your users in that way. It works on both iOS and Android. So if your users are searching for content on Google, and that content is in your app, we wanna be able to help you direct your users to your app so that you can continue to, in this case it's not directly a growth technology, but it's preventing shrinkaged. And in order to do that, it's pretty simple. On iOS there's a thing called universal links. So in a universal link you define the link between your site and your app, and you specify the package name of your app. On Android it's called Asset Links. It's just a json file that you put on your website, so when the Google spider crawls your website it sees the asset links. It see this application as associated with this website. The Google search app on your phone knows that that app is installed. They'll go hey, this person's looking for the baseball roster of a particular team. We're gonna surface it in the app where they can have a rich native experience, and that type of thing. So it's a really, really, has anybody used App Indexing? One, nice. Oh, very few use it. To me it is, oh two, okay, criminally underused technology because it's so simple to implement, and the amount of growth that we've seen or the amount of like lack of shrinkage that we've seen come out of that is amazing. And then the last one that I just wanna show before we run out of time is Remote Config, and I know should be from Cookbook is here, because I know we showed Cookbook at IO because they were a great usage of Remote Config. So the idea behind Remote Config is that Remote Config provides a server side variable that's driven off of analytics. The example that I like to give is like say take for example you're building an e-commerce app, and you wanna provide a standard discount to your customers in this e-commerce app. And you maybe provide a standard discount for all customers is zero percent, but you wanna have more customers in France. So in France you say we're gonna give a 20% discount to users in France. And in Ireland we're gonna give a 10% discount to users in Ireland. So how would you do that in your app? You'd have all this if-then logic, right? If user in Ireland, set discount equal to 10. If user in France, set discount equals 20. But then you get great growth in France and you realise you're losing a lot of money by giving all the French a 20% discount, so you wanna increase their prices by 10%. How would you do that? You'd recode it, and you'd ship a new version of the app. So the idea behind Remote Config is you'd have a standard discount variable, and then off of analytics you'd set the value of that variable. So for example in this case you'd say discount is the variable type, and then for the analytics audience in France you'd set it to 20, for the analytics audience in Ireland you'd set it for 10. For the rest of the world you'd set it for zero. And then you can change that in the back end, and then front end you don't write any code, you don't change any code, and it will update automagically. So that's the idea behind Remote Config. And the folks at Cookbook did a really cool thing. Maybe you can share it with us. So what they did was that people who cook are interested in different types of cuisine. So for example, if you like Indian food, they gave you an onboarding experience where the splash screen was a picture of the Taj Mahal, and your onboarding experience was taking you through what you need to learn to cook Indian food. If you did Italian food, the same kind of thing. And instead of writing all of this code and shipping all of these graphics, on the front end within the application they could just set up Remote Config variables. You know, let's say this is your splash screen graphic. These are the URIs that you go to to download particular pages for this onboarding experience, and then based on the analytics audience that liked Indian food for example, they had an Indian food onboarding experience. I can't remember the exact growth figure, but between using that and using Firebase Auth that I showed earlier on for a sign up experience, if I remember right, I need to go back to my IO slides, but I think they grew something like 20% in the space of a year since they started implementing that stuff. Maybe you can share with us what the actual figure is. I don't recall, but I'll dig it out of my slides later if anybody has any questions. So those are the kind of things, and I know I've run out of time, so these are some of the habits of highly successful developers. Being able to have programmatic growth. Being able to use services instead of building stuff for yourself, particularly for authentication, having realtime responsive database, using analytics to drive growth, using users daily workflow, like using a Google search engine and like leveraging that to help grow your app. And then using things for example such as Test Lab so that you can test across, you know one of the hard parts of building for Android is the diversity. Some people all it fragmentation. I like to call it diversity. As you know, there's the diversity fragmentation so that you can test on all of these devices without needing to own all of these devices. So that's a quick summary of where we're at with Firebase, some of the new things we've done. I'm happy to answer any questions later in the pub, so thank you very much.