Firebase Summit 2019 Livestream
Articles,  Blog

Firebase Summit 2019 Livestream


Welcome to Firebase Summit! Welcome to Firebase Summit!
Welcome to Firebase Summit! Welcome to Firebase Summit!
Welcome to Firebase Summit! Welcome to Firebase Summit! Welcome to Firebase Summit! Welcome to Firebase Summit! Welcome to Firebase Summit! Welcome to Firebase Summit!>>Just last month, Firebase
Crashlytics is available for Unity so all you game developers
can get in on the fun of squashing bugs before they
become big enough for your customers to
notice. ML Kit has helpful reply
suggestions. We’ve also added a number of
improvements to Firebase Test Lab, gaming support and more.
All you enterprise businesses will be happy to know that Firebase is
part of the Google Cloud platform. This year, we’ve announced even
more features to put a smile on your
face. Native mobile developers find
out what parts of their app are running slower. Why should they
have all the fun? Firebase Performance Monitoring is now
available for the web. Now you can find out important pageload by incluing a small
script. You can drill into the
distribution by browser, region, device type and more, so you can
see exactly which customers are having a great experience with
your website and which ones aren’t. If you’ve been using
Crashlytics, we’ve added support for creating custom velocity alerts so you can
decide how often you want to be alerted. ML Kit has AutoML Vision Edge,
which will allow you to create custom
machine learning models. Want to create an app that
differentiates birds? Upload to the Firebase console
and we can use AutoML technology to
build a custom machine learning for you run. In Firebase Hosting, we’ve added
Cloud Run, which is the cashing
features with Cloud containers, making it easy for you to add server-Side rendering in
any language you want. We’ve built a brand-New
emulator. So if you want to build a
function that listens, performs and logic and writes changes
back to Cloud Firebase, you can develop and test that
for much faster development. For Cloud Firebase, we’ve added
collection queries. You can search for fields no matter where they are in the database.
It’s easier to organize your data. In the Analytics world, we have
a brand-New audience builder, which will let you create more
sophisticated groups of users so you can
better-Optimize their expeerance. We have
machine learning to create custom reports for Analytics,
which will tell you about unusual trends in your app.
We’re not done. We’ll be hard at work — I said, we’ll be hard
at work. That’s better. Making more improvements you’ve been asking for and probably adding
anuth R surprise or two. Subscribe to our monthly
newsletter to stay on top of all — all —
all — all —
all — all —
all — all —
all — all —
all — all —
all — all —
all — all —
all — all —
all — all —
all — all —
all — all —
all — Welcome to Firebase Summit!>>The first time I came, to get
my first round of chemo, I was so
nervous. -Please, welcome to the stage,
Frank van Puffelen. [Applause]. FRANK VAN PUFFELEN: Wow!
Welcome, everyone, to the Firebase Summit. They told me
that you shouldn’t start the keynote at 10:00 a.m. in Spain
and they were sort of wrong, right? Thank you, all, for
being here. I love having you all, it’s great.
Let’s see. We’ve been doing this for a bit
now. This is the fourth Firebase Summit! We started this in 2016, in Berlin, then Prague. It’s going to be an exciting
day. [Applause and cheers].
I think I see some familiar faces here. Who has been to all four
Firebase Summits? Yes! I love it! I see a few folks and
honestly, that’s impressive, right? Thanks for being with us for
such a long time. We don’t just appreciate the
old-Timers. For who is this their first Firebase Summit?
Oohhh! I love that! Welcome! WelcomeWelcome so much. I look forward to chatting with
as many of you as possible. It won’t be everyone, there’s
just too many of us today. We have people joining on the
livestream. Let’s see if I can find them. They’re right over
there. Hey, everyone, on the livestream. It’s going be
fairly simple. You only have one choice to
make. Tune in or don’t tune in. So, you’re going to be seeing
everything we’ll be doing on the main stage today, so, the
keynote and the main sessions. We’re going to have a special
treat for you. While everyone here is having
lunch, we’ll be hosting #AskFirebase
right here on this stage. Tune in for that and ask your
questions. Back to everyone, here, though.
Honestly, I just want to get started on the keynote, right? We have such cool announcements.
This is just one thing I want to get out of the way. We’re
Firebasers. We welcome each and every one of you and we want you
to have a great experience today. It doesn’t matter what
your background and experience level is. We want you to have a
great time. And to do that, I sort of need
help from everyone, right? Have a look to your left. Look to
your right. Also, when you have a moment, look behind you and in
front of you. There’s bounds to be somebody you haven’t met
before, right? During the breaks, get to know people.
Talk to somebody who you haven’t seen before and introduce
yourselves. One thing I really like is building off of each
other. When somebody says something,
share your experience. You have at least one thing in
common, right? Spanish.
[Laughter]. Okay. We have community
guidelines posted throughout the venue. So, I recommend you read
them, if you haven’t done so already. If you see something that makes
you feel uncomfortable, tell one of our staff members and we’ll
investigate. I like it because I’m pretty much done here.
[Laughter]. With that, we’re ready to
kickoff for the keynote. This is probably the most
exciting thing for me. Let’s give a very, very, warm
welcome to director of products for Google,
Paul Manwell. PAUL MANWELL: Hola! [Speaking Spanish].
[Applause and cheers]. So, as you can see, I’m very
happy to be in Madrid. And so glad that all of you
could come in and us in-Person. I’ve been really enjoying it. I
hope you get to enjoy the food while you’re here, too. I also
wanted to say hello to our livestream viewers. Thank you,
all, for tuning in from all over the world. I’m Paul Manwell. I’m also the director of product
and engineering at Google and I’m so excited to welcome all of you to our
fourth annual Firebase Summit. In 2016, we held the event in
Berlin and were joined by hundreds of developers. Right now, we have more than
1,000 developers from over 70 countries. It’s amazing to see our
community grow stronger, always ready to learn and make Firebase
better. To-Date, the Firebase community
has contributed over 1. 4 million lines of code to
Firebase. Give yourself a round of applause for that. Thank you, everybody.
[Applause]. So, this compares pretty
favorably to the 900,000 lines of code you
also deleted. [Laughter].
Thank you for making Firebase a really healthy codebase and
healthy community. So, we love collaborating with developers like you because you
are the architects of the future. You dare to solve impossible
problems. Then with gusto, write the code
that brings your vision to life. Together, we can move technology
forward by leaps and bounds. So, before we jump into all the
exciting news from Firebase, I wanted to quickly step back and talk about why
Google invested in developers. Google is like you all, we’re
founded by developers, who wanted to organize the world’s information, make it
universally-Accessible and useful so anyone, anywhere, with a dream,
could gain the knowledge to put it to life.
But the world is changing and so we’re evolving the way we
approach our mission. We’re moving from a company that
helps you find answers, to a company that helps you get
things done. We want our products to work
harder for you in the context of your home, your job and your
life. So when you need to find the fastest route to a
restaurant for dinner, Google Maps is there to help you. When you need to buy flowers to celebrate your anniversary,
because you might have forgotten, the Google Assistant
is there. When you need to take a break, YouTube has hours and
hour s of content. And you all play a critical role
in creating these magical experiences. It’s your products
that really help people in moments, big and small. And we believe that a vibrant developer ecosystem that’s open
benefits all of us. And that’s why we invest in the
tools and resources to make development easier and faster. All the way across the spectrum,
from mobile, where just a few weeks
ago, we launched Android 10, adding
support for 5G and many privacy and security features. Also in the Cloud, where we
introduced Anthos that helps you run an app
anywhere. Simply, flexibly and securely. For machine learning, we’re
committed to expanding tensorflow. And of
course, there’s Firebase. The app development platform that brought you all here today.
So, we know that navigating this landscape can be tough, so we’re bringing things together on
Google.dev. You can get up to speed on all the tools and
resources that Google offers. Those of you who are here today
in the audience, and those watching on livestream, can get
early access by going to the link on the screen. It’s Google.dev/topics/Firebase. But today, today is all about
Firebase. Through Firebase, we’re pushing to make app
development seamless. So that mobile and Web
developers can succeed. Which is why the team has been hard at work expanding and enhancing its
capabilities. And for me, it’s really exciting
to see that now over two million apps
actively use Firebase every month. It’s an honor to be trusted by
so many of you and to see the work that you’re doing.
Just to give a few examples. Right here in Spain, Tabify is
using Firebase. In France, Le Figaro is
personalizing content for their users. In the United States, Mighty
Emersion is using Firebase to transform
care for cancer patients. And it really is incredible to
see what you all do. And at Firebase, and across all of
Google’s developer products, the best part of our platform is you
all. Our developer community. We believe that developers are
critical to our success. Which is why we want to have a vibrant
and open developer ecosystem. An ecosystem that we all benefit
from and an ecosystem that helps you bring your ideas to life. We’re here to help you on that
journey. So now, I’d like to share a
story about Mighty Immersion. Roll the video.
-The first time I came to get my first round of chemo, I was so
nervous. -The whole experience of
accepting your child has cancer and being able
to not take it away was probably the
hardest thing. -Often, healthcare visits are
surrounded by pain and fear. I’m Luke Wilson, I’m the founder
and CEO of Mighty Immersion and I work
on virtual reality tools for
children.>>The way VR works is it keeps
the child engaged. They are focused on what’s going on in the virtual world and that
allows them to really be removed from what’s going on, in some cases, around them,
which can be stressful or painful. -I feel like it helps all
around, when you’re watching yourself get a needle put in
your pore, it can be hard to watch.
-The second we started seeing success in the experiences that
we were developing, we realized we needed to
distribute this at a larger scale. We had to grow the headset base
from a couple headsets to 10, 20, even
50. That’s when we needed Firebase
to manage all these devices through a simple web portal
online. Using Firebase made developing and management system
extremely fast. We were able to have this idea and put it into
practice immediately. We didn’t have to focus on the
back-end development, we could rely on Firebase and focus on
the core of what we were building.
So much is taken away from you when you’re a patient in a
hospital. To be able to smile and enjoy your life a little bit
is actually extremely powerful and brings us a lot of
joy, as well. [Applause].
PAUL MANWELL: Hi, everyone. I’m Francis, head of product for
Firebase. What a touching video, right? The first time I
watched it, I got a little teary-Eyed because I know what
it’s like to have close family members battle with cancer. But this is exactly why we do
what we do, to enable companies, like
Mighty Immersion, make the world a better place. And it’s stories like this, and
many others, are what inspire or team to work hard, every day, to
help developers like you succeed. Now together, we’ve
come a long way, yet the best is yet to come.
Now as we look forward to future of Firebase, we’re invested in
three key areas. First, helping you accelerate
your app development by giving you the building blocks to solve
many of the common and core problems in app development. Second, helping you run your app
more efficiently by simplifying your workflows and services
insights when you need it so it helps you improve your app
quality and increase user engagement.
And, third, making Firebase more extensible so that you can
tailor it to your needs, as you scale, by
giving you the control, flexibility and
transparency. Now we’ve got exciting
announcements across all three of these areas today. So, let’s
get started. We’ll dive right into how Firebase helps you
accelerate your app development. Now as developers, we often
spend a lot of time setting up infrastructure or writing code that doesn’t
differentiate our app, authentication, scaling our
servers. And to help you focus more on building amazing user experiences and
running your business, Firebase provides
fully-Managed back-end services to help you solve many of these common
and core problems, from databases, to
Cloud Functions, to ML Kit that helps you apply machine learning
and bring it into your app. Now if you use these services,
you know they take the hard parts of building an app and
make them easy. But we’ve also heard from you
that there’s an area, which is helping you with your
development workflow. Now, today, as you develop and build
an app, this is how it goes. You make some code changes and
you push it to the Cloud. Switch over to your mobile
device and see if it works. And if you need to make a small
change, you got to start this cycle all over again. So we
hear your feedback, that you want a faster and better way to
do this. And that’s why we built the
Firebase emulate suite. Now, the emulator suite lets you
run emulator versions of Firebase, functions, Realtime
Database and Hosting, locally on your
computer, for a faster and safer development experience.
And since the suite runs locally on your machine, it enables rapid
iteration without touching production data
and supports hot reloading when you’re changing funk functions. It enables you to scale across
larger teams. Each developer has a local instance of emulator
on a machine, you can develop them in parallel — say, if you
have a team of five — without creating conflicts.
So, over the past few months, we’ve expanded the functionality
of the emulators. In addition to supporting
Firestore and Functions, we’ve added support for the Realtime
Database. We’ve also expanded the SDK from
Android to iOS and Web and SDKs, like
Java, Node, and Python. Now to show you some of these
new updates, I’m going to pass it to
my teammate, Julio, to show us a
demo. [Applause]. .
JULIO PEREZ-OSUNA MORALES: Hi, everyone. I was born and raised here in
Madrid. It is great to be back here. One of my favorite things
about Firebase is how easy it makes our lives as developers.
And to show you how easy it is to develop using the emulator
suite, let me show you to Friendly Eats app.
Currently, it can save reviews. But it doesn’t update the
restaurant’s rating so we’re going to be adding that
functionality here. Usually, Friendly Eats connects
to the Firestore in the Cloud. So we’ll connect to our local
emulated instances running directly on my machine. Let’s
through how the app will work. When someone leaves a review, we
run it to Firestore, which will trigger the updating function on
my machine and calculate the average rating and write the results back to Firestore,
which you’ll see immediately. And all of this is going to
happen locally on my machine. Okay. Let’s see this workflow
in action. First, we’ll start the emulators. Once we have the Firebase
installed, we’ll run Firebase emulator start, which will start
the emulator we started for our project. You can see the
Firestore and emulator starting. They’re all done, so let’s
switch over to our ID and connect to them. We’re going to need to connects
to the Functions and Firestore emulators. We only need one
statement from each to connect. I’m going to do what all do
developers do and copy and paste this from the docs. So, we already have our instance
of Firestore. And, apply them.
Okay. That’s Firestore done. Let’s do the same for Functions
now. And that’s Functions. So, what
this does is tell the SDK to connect to our local emulators
instead of going to the Cloud. To make sure this is working, as
intended, let’s run our app. We should see an empty list of
restaurants, for now. Since a local Firestore instance
has no data yet. Let’s give this a second start. It’s building. It’s starting.
There we go. Okay. There we go. So, let’s start by adding some
fake restaurants. And there we have it. Let’s see what happens when we
leave a review. So, as you can see, the review
was added. But we haven’t updated the
rating or the number of reviews for the restaurant. To do this, we’re going to need
to add our Function. So, let’s go to the Functions file. Here,
we need this function to run whenever a new review is written
and the first three lines of code will do exactly that.
Then, this function will calculate the updated restaurant information
and store it into Firestore. All that’s left is to export
this function so that it can be executed. So, let’s do that.
Great. So, this should do the trick. And since local
emulators have hot loading, I’ll need to save the changes and
they’re ready immediately. So, let’s try to leave another
review and see if it works this time. And there we have it. You see that, now, we calculate
the updated information and see it
immediately. [Applause]. Hot reloading really is a game-Changegame-Changer. We
make change and see the results instantly. As well as allowing rapid
development, we can set up the emulator to
run programatically.
Back to you, Francis. FRANCIS MA: Thanks, Julio.
[Applause]. So, as you can, our emulator
suite gives you a playground to safely test
features. The most striking advantage is you can develop
your code so much faster. Now, I want to highlight another
building block that you can use to accelerate your efforts to bring
machine learning in to your app, ML Kit.
Last year, we launched ML Kit, bringing together machine-Learning
technologies across Google. Through ML Kit, we give you
access to on-Device and Cloud-Based APIs that you can use out-Of-The-Box. Now
these APIs provide functionality such as face detention, image
labeling, text recognition and we keep adding more. While the base APIs are
extremely easy to get started, we know that you
require more things. We support for custom Tensorflow
models. You can deploy them dynamically
to your app, directly to your end users
devices. We’ve taken support for custom
models even further. Previously, you still had to
create, train, optimize the model all on your own. Recognizing this process
requires some ML expertise. We have AutoML
Vision Edge. Now to create custom models for
image labeling, all you have to do is gather your training images and then
upload them to Firebase. From there, you want to take
care of the training and optimization
process and automatically generate an
ondevice Tensorlight model, no ML expertise is required.
JULIO PEREZ-OSUNA MORALES: To make it easier for our users, we want to automatically tag the pictures
uploaded using ML. I’m going to use AutoML Vision
Edge. Let’s go through how to do this.
We’ll start in the Firebase console, in the ML Kit section,
where we’ll create a new data set called” food and
uploaded images. ” So, let’s do that. Here, we’ll upload those images.
And because uploading can take a little while, let’s jump over to
the data set I created earlier, where the images are already
uploaded. Here, you can see that you have
the images with a label and you can add or remove images, as
well as update their labels. Once we’re happy here, we’ll
move on to the next step, which is training the model.
You can pick between optimizing for higher accuracy or latency
and size. We’ll have to choose how long to train the model for. Larger data sets require larger
train times. I’m going to go with the default
and I’ll jump over to a model that is already trained. Here, you can see the results,
after the model has done training. We can see the
precision and recall and underneath, we can see a
breakdown by label of how often the model was correct. This information allows us to
decise whether we’re ready to use this model.
Once we’re happy, the last step is to integrate the model into
Friendly Eats. We can either bundle it to the
app or publish is to Firebase or
ondevice inferences. We’ve created this model with
just a few clicks and new machine learning experience. So, let’s see if it works. Can we switch to the phone? Please?
[Laughter]. No? Well, let’s do this. I’m going to do the demo and
I’ll show it to all of you who can see it. If you’re
interested, you can come to #AskFirebase and I’ll show you
in-Person. So, here’s the dish.
[Laughter]. And here’s the model identifying
it correctly. [Laughter].
Oh, there we go! See that? [Laughter].
[Applause and cheers]. So, we just walked through how
you can use Firebase to train and deploy
an ML model without needing any ML experience. Back to you,
Francis. FRANCIS MA: Thanks, Julio.
[Applause]. So, since launching Firebase, we
strive to offer fully-Managed back-end
services that speed up your time to market. Now our goal is to help you get
to the fun part of app development without the fuss of
managing servers. Nobody’s got time for that,
right? The emulator suite lets you try
out your code instantly without deploying it.
And AutoML Vision Edge makes it easier and faster to build and
deploy ML into your app. In the coming months, we’re
going to continue to integrate this so you have access to more
Cloud services. I’m going to pass it over to
Derek, our head of engineering.
[Applause]. DEREK PHILLIPS: Thanks,
Francis. Firebase is your partner through
every stage of the app lifecycle. From building an app, to running
it and turning it into a successful business.
As your technology partner, we want our products to fit with
the way you work and help you be more efficient. With products like Crashlytics
and Test Lab and Performance Monitoring, it’s easy to improve
your apps quality and deliver a great experience. When you want to understand your
use Rs, Google Analytics. We offer Remote Config, Cloud
Messagng and in-app. We want to have the tasks you
face every day and insights when you make to make decisions.
This enables you to focus on doing what you love. One of the
things developers love to do, is build features. We can spend
endless hours sitting at our computers, coding up happy
features that all of our users will enjoy. But where there’s code, there
are bugs. We all know that the best time to identify and fix
bugs is before your app is in the hands of users.
Nobody wants to learn about problems in their app from app
reviews because bad reviews and bad ratings can have a lasting,
negative impact on your business.
That’s why it’s so important to get real user feedback and test
your app for stability and usability issues
before releasing it broadly. But user testing can be a clunky
process. You have to recruit testers.
Give them access to your app. Find a way to distribute
pre-Released builds to them. Collect their feedback and then
do it all over again when you have something new to test. So
we asked ourselves, is this really how we want to spend our time?
No. It’s not. And now, we don’t have to. Say hello to Firebase App
Distribution. [Applause].
Firebase App Distribution makes it really easy to distribute
pre-Released versions of your apps to testers. You can manage
all of your pre-Released builds for both iOS and Android. You
can send distributions from the console or you can use the
command line tools that are already part of your workflow. We’re launching App Distribution
for Gradle, the Firebase CLI and
Fast Lane. To walk you through this, I’d
like to welcome Alex. [Applause].
ALEX SINGER: Thank you, Derek. We build App Distribution to
give you a fast, flexible way to get your pre-Released apps to to your
testers devices. There is no SDK to install, forms to fill out or
review process to go through. I’ve been working on a
highly-Requested restaurant feature for the Friendly Eats.
I’ll use App Distribution to send out a build to testers at the company. This is the distributions page,
where I can see any previous
distributions and upload new IPAs and APKs. I’ll upload Friendly Eats. Once
uploaded, there are two steps we need to do to configure a
distribution. The first step is adding
testers. We’ll give this a second to upload and then we’ll start adding testers.
Awesome. Now, I can add individual
testers or groups of testers that I’ve
previously defined. Our iOS QA team will definitely
want access. I’ll also add an internal test
group. And there’s one particular
developer who’s been asking for early access, so I’ll make sure they’re in there,
as well. To give me confidence in knowing who will actually be
invited, I can expand a group to see all of the
individual testers. The second step is to add release notes. Release notes ensure that my
testers know exactly which new features are in this build and
what I’m looking to get input on. I’ll let them know, new
restaurant filter. Check it out. And now we’re ready to send out
this build. After I press” distribute,”
it’ll automatically be sent to these five testers. They’ll
receive an email with instructions on how to get
started with testing on their device. The distribution card
gives me the status of each tester. So I can tell who exactly is
trying out the app. This gives me the confidence to
know if a feature is ready to promote to a production release
or maybe to a larger beta pool of testers.
I’ve also had a few other people, at Friendly Eats, who
have been interested in getting access. I could manually add
their email addresses, but what would be awesome is if they
could add themselves to get access to the test app on their
own. With this, we have Firebase App
Distribution Invite Links. I’ll create a new Invite Link,
which will allow me to generate a unique URL, where testers can
go and sign up for access. So, let’s make a new Invite Link
for Friendly Eats. I’ll configure it so anybody
that signs up will automatically be added to that group and I can add a domain
restriction if I want to make sure people outside of the company won’t be able to
sign up for access. And it’s created. So, now the
link is ready to copy and share with folks at Friendly
Eats, including Derek, who I know has been interested in
testing out an early version. DEREK PHILLIPS: Excellent.
Alex has a new version of the app for me to test out. I’ve
been wanting to check out the new filter feature he’s been
doing. I can click on the link and submit my email address to become a
tester. In my inbox, I get an email
showing me how to get started. I’ll go ahead and sign and
accept the invitation. Oh, it looks like this is the
version that has the new restaurant filter feature, which
is just the one I’ve been wanting to test. I’ll download it and open it up. We’ll give it a second, here; to
download. There it goes.
Finally, I can use that filter feature. So, I’ll go pick it, here, and
then — oh. It crashed. Alex, the filter just crashed on me!
What’s going on? ALEX SINGER: Seriously, I
thought I fixed that before the summit. All right. Let’s hop
back over, in to Firebase, and we’ll go into Crashlytics,
to see that crash appear on our dashboard. So, I’m going to
load this back up. Oh, yeah. There it is. Let’s see what’s
going on here. Yeah. So, digging into this crash, it
looks like you’re running iOS 13. I’ve actually been doing most of
my development on an older device that’s still on iOS 12. So I think I’ve got a fix and a
build that’s ready to be sent out. I want to make sure I can get it
to my testers — and Derek — as quickly as possible.
I could use the Firebase console again. But I want to work on automating
our distribution process. Our team already uses Fast Lane
and I want to expand configuration to
include app distribution. In my Fast file, I’ve added a
new block for Firebase App Distribution, where I can define
the Firebase app ID and groups and release notes. So I want to make sure this goes
out to that internal test group and I’ll let our testers know this is the fix
for iOS 13 crash. Now, to send this out, it’s as
easy as executing that lane. My testers will automatically
get another email, letting them know that there’s a new
distribution to try out and that can install it right away on
their device. Hey, Derek, there should be a crash-Free version
coming your way now. DEREK PHILLIPS: I can’t wait. All I need to do, now, is
download the latest build and I’m sure that this one will finally fix that filter
crash. ALEX SINGER: As you can see,
App Distribution gives me everything I need to manage my
iOS and Android pre-Release testing. Back to you, Derek.
[Applause]. DEREK PHILLIPS: Thanks, Alex.
As app developers, we know first-Hand how crucial it is to
get early feedback. We’re confident that Firebase
App Distribution will make this a breeze and take a pain out of
distributing pre-Release builds. If you’re a Fabric developer,
you may have noticed that App
Distribution looks awfully familiar. And it is. It’s the
next evolution of Crashlytics Beta. You have everything you
need to move to Firebase. As a reminder, we’ll be
sunsetting Fabric on March 21, 2020. If
you’re a Fabric developer, we encourage you to migrate. When
you land in Firebase, you’ll see a summary of the data that was
migrated. And we give you a checklist of tasks that will help you get ramped up
on Firebase. As part of the transition, one of the things we
definitely recommend you do is to configure Analytics. From
the very beginning, Firebase has offered a deep integration with
Google Analytics that gives you free
and unlimited app Analytics, whether
you have a 100 users, it can show
you who your users are, what they’re doing inside your app and even why
they churn. Google Analytics transforms a
mountain of data into insights. We’ve simplified the process so
you can take actions to keep them happy.
We’re continuing to strengthen Google Analytics based on your
feedback. Many of you have been asking to connect your app data across
platforms because your users often
interact with your business through multiple touchpoints.
And many, many, many of you have been asking to get the same rich data
and insights Google Analytics provides for mobile apps for
your web apps, too. And you know what? Now that I think
about it, that’s actually a pretty good idea. So, let’s do
it, then. Starting today, Google Analytics
and Firebase supports web apps.
[Applause and cheers]. Now, Google Analytics gives you
the features you’ve loved for native apps, like the ability to
segment your audiences, build reports to track retention and
understand what actions people are taking. All of these
powerful tools are available for web apps, too. Oh, and while we were at it, we
added cross-Platform support as well so you can get a complete view of your
users journeys. Now with Google Analytics
available withwith Web apps, we thought
we’d add this, too. To show you what all this looks
like, I’m going to hand it over to
Mai. [Applause]. MAI LOWE: Hi, everybody. I’m Mai Lowe and I’m working on
Firebase for Web. So, here we are, back in
Friendly Eats. In the Analytics dashboard. We should be in the Analytics
Dashboard. [Laughter]. Could we switch the screen?
Awesome. Sweet. All right. So, here we are, back in
Friendly Eats, in the Analytics section of the
console. And the the tire Analytics product works
seamlessly for web. But I’m going to focus on three features
to highlight for you today. The first is cross-Platform
Analytics, event reporting and audiences. So, once you see
that dashboard again, I can show you it live.
[Laughter]. All right. Here we are in the dashboard and
by default, you will see your data across your entire
business, that means all of the platforms you build on.
By setting user ID and the SDK, you will now have all the
reports duplicated across devices and platform. But you
can always drill in deeper. Since Web is entirely new to the
mix, let’s look at Web. We’re going to apply the filter. And, just make a black, for,
like, an extra ta-da, you know? Now you see all the web data for
Friendly Eats! [Applause].
All right. Now, I’ve covered cross-Platform
Analytics. Let’s talk about Events. I’m going to look at an
event that I know is near and dear to any wep
developer, Page View. This is one of our new,
automatically-Collected events, specific to web and Firebase.
While this is an awesome and super important metric, I hope
at the end of this demo, you will see that
Google Analytics takes Web Analytics way beyond this. Let’s select an event. Say, Start Review. By default,
you’re going to see event count and the user count who
triggered that event, across your native
and Web aps and you can look at just web if you apply the
filter. All right. Cross-Platform Analytics, event
reporting, let’s talk about audiences, which in my opin pinion is one
of the most exciting features. It can evaluate users on the web
and cross-Platform. If you need a refresher,
audiences are a way for you to group your users along
attributes that are meaningful for your business. Users who made a purchase or
users who passed a certain level in your game. And just like on Native,
Audiences for Web go beyond insight and report
because they’re at the heart, like cloud
Messaging and Config. Let’s set up a quick Audience
and I’m going to use that audience to show you how Cloud Messaging and Remote
Config work for my Friendly Eats app. Power users are considered
users who have submitted more than five reviews in any given
30-Day period. So, I’m going to set up an
audience that captures that particular group. We’re going to create a new
audience and I’m going to select the event to be submit review. I’m going to add a parameter
event count and set that greater to five and check the” in any day period”
box and set that number to 30. I’m going to add another
condition and restrict my browser to Chrome. And you’ll
see why, in just a moment. But I want to point out that
this is a brand-New dimension available in
the Audience Builder, that’s specific to Web.
This audience can now be applied as a filter across the entire
Analytics console so you can drill deeper into this
particular user segment. I actually created this audience
earlier already, so I’m not going to save it. I’m going to
click out of this window. And let’s move on to targeting,
because targeting is Analytics in action and, plus, I think
you’re going to love it. So, I’ve been wanting to send my
power users, at Friendly Eats, a thank
you for being so engaged. I actually sent one earlier
already, but then I found out my app was going through some
issues in Chrome. So now I’m going to send another
one, but just to the Chrome users since they missed the
message the first time around. Now you know why I limited my
audience, earlier, to just Chrome. So, cloud Messaging is how
Firebase sends targeted notifications to users. I’m going to create a new
notification. And, I’m going to title it”
You’re a friendly Eats rock star” and I’m
going to say” thank you for writing
helpful reviews. ” Now we’re going to get to targeting.
And here, you see, I not only have access to my Native apps, there
are also web apps in there. I’m going to choose my Friendly
Eats and the audience I just created. By default, this
message is going to go life immediately. I could also
schedule it to go today, tomorrow, next week. I could even do a recurring one. It’s a pretty handy feature in
Cloud Messaging. So, I’m going to review. Before I publish, I’m going to
switch to two screens where Firefox is
on the left and Chrome is on the right. So, let’s publish. And go to my two windows. And
there it is! Thank you for writing helpful
reviews. [Applause]. All right. Let’s say that’s not
all I want to do for these awesome users and
Friendly Eats. Let’s say I want to give them a
tempary dark mode in the UI because
everybody refers Dark Mode, right? Remote Config allows me to
configure different kinds of experiences
for different kinds of users. I’ve created a condition that
targets the audience we’ve created, power users in Chrome. I’m going to go to the
parameters and set my Dark Parameter Value to
True. I’m going to update, publish my
changes. All right. So, let’s go back. I’m going to refresh Firefox,
first, and nothing should happen. And nothing did. Now
let’s refresh Chrome, and there you go!
Gorgeous. There’s that lovely Dark Mode,
that I know my power users are going to love.
Back to you, Derek. DEREK PHILLIPS: Thanks, Mai.
[Applause]. Data is at the heart of every
good business decision. Google Analytics turns insights, data into insights, so you can
understand what options your users have taken inside of your
app and why. Firebase can also show you what actions your users
are going to take in the future. That’s where Predictions can
help. With Predictions, you can apply
the power of machine learning to
your app Analytics, to segment your users based on their future
behaviors. We’ve been working hard to make Predictions easier
to use and we’ve made some recent improvements to give you
more information and more control. To show you how to harness the
Power of Predictions, I’m going to turn
it back to Mai. MAI LOWE: Thanks, Derek. I use Admob and partner with Restaurants, to sell discounted
coupons to my users. These are valuable to me, but I know that
only a small fraction of my users is actually going to make
that. If I only knew who those users
were, I could optimize the app for them and limit what they see
to keep them in the core flow of the app and
hopefully buy more coupons. Lucky for my, Firebase
Predictions does exactly that. So here we are in the
Predictions console and I’m going to click on the predicted
spend audience. I’m going to expand my graph of active users and you see, they’re
sorted from left to right, in how likely they are to make that
purchase. The probability of them making
the purchase is on my y-Axis. I can
use these blue sliders to select the segment and as I’m moving
the blue sliders, you see the bars and
the data change on the right, to give me more information about the users that
I’m selecting. All right. I’m ready to configure the
in-app experience for this group of users. I’m going to choose
Remote Config. And then, I’m going to select a
parameter called Limited Ads. This is going to reduce the
frequency of the ads that this group of users
sees. To make it extra easy, all the targeting information is
pre-Filled. And here, you see that I’m targeting the top 2% of my predicted
spenders. Let’s continue. Once I publish, I know that my
highest value users are getting the
tailored experience they want. Back to you, Derek.
[Applause]. DEREK PHILLIPS: Thank you.
Okay. So, we just saw demos of our new
improvements in app distribution, Google Analytics
and Predictions. The underlying goal all of these
updates is to help you run your app more effectively, with Analytics
insights and workflows. With Firebase, we want to free you
from the tedious tasks of app development so you can focus on
building amadeing user experiences.
Now, in addition to expanding our own built-In platform, we’re working
to make Firebase more extensible to support your sophisticated needs by giving
you more control, flexibility and transparency.
To talk more about that, I’m going to turn it back to Francis. Francis.
[Applause]. FRANCIS MA: Thank you, Derek.
So, in addition to helping you build and run your app smoothly,
we also recognize that you need to do this at scale. Now as your development team and
userbase grow, so do the complexity of your challenges.
That’s why we’re making Firebase more extensible so that you can
tailor our products to better-Meet your needs. Now one of the ways we do this
is by open sourcing our SDKs so you
can look under the hood. Webelieve in order to create
remarkable software, we need to get a lot of great minds
involved and the power of open source is the power of our
community. And thanks to you, we now have
community supported Mac OS and have
expanded our SDK across server environments, which are huge
wins. Since our last update ad Google
I/O, we have four additional Android libraries, A/B testing
and Remote Config. Remember the Web SDK for
Analytics and Remote Config that Mai just demoed.
We’ve open sourced them already. I want to take the moment to
highlight the work of a React Database for
Firebase with quick start guides and support for every Firebase
service. It’s amazing to see this
community library has more than 5,000
stars on GitHub. And we continue to invest time and
energy into open source because we want to earn your trust by
working with you, to build a transparent and
flexible platform. So, in addition to making our
platform more open, we’ve also taken
strides to meet your sophisticated needs to manage and control access to your
Firebase projects. Last year, we brought identity
and access systems to Firebase and
data. Custom, pre-Defined roles to
limit access to your project. Today, proud to announce that
we’re graduating the system out of beta into general
availability. And as a bonus, we’ve also added
per-Product roles to give you even finer grain control for
each Firebase product. So with this, you can configure
who has access to what so you can prevent mistakes and protect
your data. So, for example, you can enable a team member to just
view your Analytics report, but not mess with your back-end.
Or, you can restrict to permissions to just what’s needed so that
nobody accidentally sends the notification to all your users.
All right. So, we’ve talked about open
sourcing more SDKs and refined access controls to your
projects. All of these are parts of our effort to make
Firebase more extensible. But wait, there is more. We
have one more big announcement and not to be too dramatic, but it
signals the beginning of a new
extensibility frontier for Firebase. Have you ever found yourself
doing repetitive tasks?
Cloud Storage and wanting to make things go faster? Or tired
of being asked to do the same things over and over again, like manually add users to a
Mailchimp email address? There are no good solutions to get
around them. You, yourself, may have recently encountered a
problem that seems common and lacks a quick solution and
wondered, there’s got to be a better way. We want to give you a better way
to tackle every-Day problems and add functionality to your app so
you don’t have to reinvent the wheel. Today, I’m thrilled to introduce Firebase Extensions.
[Applause]. Firebase Extensions are
pre-Packaged bundles of code designed to save you time by automated common tasks
in your project. They’re configurable, open
sourced and work with Firebase. So, whether you want to resize
an image, add people to an email list or
shorten URLs, we’ve built in an array of solutions that’s you
can plug into your project. There’s no need to research,
write or debug code. It’s all done for you. But you
still have the flexibility to configure and customize the
extensions to your specific use cases.
So, to show you extensions and how you can start using them,
I’d like to pass it over to Osa on my team to
demo it to us. [Applause]. OSA OMOKARO: Hi, I’m Osa
Omokaro, the user experience researcher working on Firebase
Extensions. If Firebase were a restaurant,
Extensions would be tapas. Quick and easy bundles of
solutions for common-Use cases in app
development. As an example, I want to expand
my business globally so I need to translate the descriptions of
my app to multiple languages. I’m going to do this using a
Firebase Extension. So, we’ll start off here on the
Extensions Discovery Page. Here, we have a range of
extensions for common-Use cases, but I’m going to select the Translate Text
Extension. This, then, brings me the
extensions page. This extension uses the Cloud Translation API and in vokes it
using a Cloud Function. Normally, I would need to do
this manually and put that all together myself. But now,
Firebase Extensions takes all those separate pieces and ties
them together for me, in one simple step. I don’t have to write a single
line of code. Firebase Extensions are free. I will only be charged for the
underlies functions. Next, I’m going to review the
access granted to this extension. I’ve taken a look at
everything here and it all looks good to me so
I’m going to click” next” to get to the
last step. Extensions are configurable. This is where I
will set up this extension to fit my specific use case. So, I’m going to set my
deployment location and then I’ll review my
target languages. By default, they are set to
English, Spanish, German and French. But I’m going to add Italian,
just because it’s really easy to do that.
Next, I’ll give it to the path to my Firestore Collections where my
strings are stored. And then I’ll add the field that
I want it to translate on. And that’s really all there is
to it. I’m ready to install this
extension. Now, Firebase Extensions take
just a few minutes to install, but so that
I don’t overextend your time, I’m going to show you one that I already installed
previously. Here’s what it looks like. But let’s go straight to the
database so that we can see this in
action. So, here’s my database, my
Collection is Restaurants. I’m going to add a new document. I’ll give it an auto ID, the
field is Descriptions. And the value will be great for
groups. Now, when I hit” save,” this is
going to translate based on the configurations. So, are we ready? Yay!
[Applause]. I’ve been waiting to show you
that for a really, really long time. Extensions are really
cool. And as a researcher, I’ve worked
with a lot of developers, just like
you, to make sure that Firebase got this right.
Extensions are easy to install, they are configurable and they
enable you to accomplish a whole lot more for your app, with just
zero lines of code. Thank you. Back to you, Francis.
[Applause]. FRANCIS MA: Thank you, Osa. So, Osa just showed you some
extension s. And today, we’re launching with
nine Firebase extensions to beta. These ready-To-Go solutions will
help you add new functionalities to
your app, automate repetitive tasks and
use Firebase product more
efficiently. They will help you accelerate your app development,
run your app more effectively and provide more
flexibility. So, we just spent the last hour
talking about the new work we’ve done to make Firebase better. As you just saw, we’ve been
focused on three things. First, giving you the building blocks
to help you accelerate your app development so you can solve
many of the common and core problems in developing an app.
Second, helping you run your app more effectively by simplifying
your workflows and services insights
to increase your app quality. And third, making Firebase more
extensible to support your sophisticated needs by giving you more
control, flexibility and transparency.
With every improvement to Firebase, we aim to make app
development easier so that you can stay focused on building
amazing user experiences. Our mission is to help
developers, like you, succeed, whether success to you is
getting an app off the ground or scaling it into a global
business. You can rely on Firebase.
Now as you go through out the day, I hope you feel energized
and empowered to bring your ideas and passion to life. After all, you are all the
architects of the future. We’ve got lots of technical
talks, cool demos and delicious food ahead and rumor has it, there may even be
chocolate khurros. All right. Folks, thank you for
being here. Enjoy the rest of the day.
[Applause]. FRANK VAN PUFFELEN: Did we
overpromise or did they really deliver? I think we had some good
updates, right? [Applause].
Okay. The slides are still showing,
it’s very interesting. I get that people are ready to
get on a break, right? I skipped some of the housekeeping
things, before, so that we can do them now. And I’m really bad
at remembering things. So what we’re going to have during the
day is that we’ve have Firebase friends coming up on the stage
to sort of tell you what’s going on, to serve as your master of
ceremony. I’m actually really happy to
welcome the first on stage now, she’s my
co-Host, Jessica DiRocco. [Applause]. JESSICA DIROCCO: Thanks. Hey, everyoneeveryone.
FRANK VAN PUFFELEN: Jessica, when people go out for their
break, what they can do? JESSICA DIROCCO: I have a very
important thing I need to start with. Restrooms. In case
you’re not sure where they are, they are to your right, right
near the food and beverage. If that long is too long or you
don’t want to wait, you can go outside the venue and make a
left. FRANK VAN PUFFELEN: I like how
you’re doing the airline theme. What else is there to do?
JESSICA DIROCCO: I saw all of the Code Lab instructors setting up and
we have four new Code Labs, all powered
by Google.dev. If you’re interested in gets
more hands-On with Firebase, grab your laptops.
FRANK VAN PUFFELEN: You’ll be sitting at a table with Firebase and
doing the Code Lab together. I think we have #AskFirebase
outside of here. It’s fairly simple today. If you see somebody wearing a
yellow shirt, you can ask them any
Firebase question. JESSICA DIROCCO: We’re also
going to have Firebasers at all of our demos. We have a ton of demos today and
App Ship. FRANK VAN PUFFELEN: Have we
played, Jess? JESSICA DIROCCO: Not yet.
FRANK VAN PUFFELEN: So, I think we actually have a lot of to do
and of course, we’re going to be reconvening at 11:30. Right?
So we have a short break, now. Grab coffee.
JESSICA DIROCCO: Snacks. FRANK VAN PUFFELEN: I don’t
think I have seen the churros Francis promised.
We’ll see you back here at 11:30. Does that sound good?
JESSICA DIROCCO: Thanks, everyone. FRANK VAN PUFFELEN: Have a
great day. great day.
great day. great day. -It has been mostly one TV per
household. This may be a phone to your next
TV. And that is how this marketing
is skyrocketing. We have seen our MAU grow to
more than 150 million users. You view your content, as
express your opinions. Make it a social experience on the same
platform. It becomes a bidirectional
source. -It is fractional the size, but
we are still keeping up. Before the start of 2018, we
decided to build our app, it is the biggest sporting event in
India. We were expecting a huge surge
of users. We wanted to use this to launch
new features. -Using Firebase Remote Config,
we learned the feature to a small data set of users. -Our engineering team was
monitoring in Firebase Crashlytics and we
noticed crashes. -We used Google Analytics to
segment our users and turned off the feature
for using conditional targeting. Amazingly, we were able to do
all of this without releasing a new one. With Firebase, we can
make decisions by deeply-Understanding and
analyzing our data. -And BigQuery is another source
to achieve this. We export Firebase logs to
compare insights. For example, we log start-Up
time from launch to load. Then we ran each one to understand
where the most time users spent and optimized to reduce lags.
2018 was like a dream year for us. We broke many records and the
best thing 10. 3 million current users at one
goal. With the help of Firebase, we were able to seize
this opportunity, to run experiments, and do control
feature roll-Outs. We increased time by 38%.
Firebase and BigQuery are helping us. So much that our size is
becoming the primary viewing screen for many
Indians. -Hello, everyone. My name is Doug Stevenson, I’m a
Developer Advocate with the Firebase Team.
There are a couple things I’d like you to know about the
summit today. The first thing is lunch. Everyone has to eat,
right? Lunch is going to be served
between 12:30 and 2:30 in the space right here over. So,
don’t miss that. The other thing I’d like to draw
your attention to are the games we have here. There are a
couple of games you can play. One is App Ship and we have a
brand-New game called Golf Golf. These are multi-Player games.
So, go together and play them together. If you’re here by yourself, go
make a new friend and play the games
with your new friend. My favorite new announcement is
Firebase Analytics for the Web. This is something I know you’ve
all been waiting for. It’s not just Analytics, it’s also Remote
Config and Targetsed Notifications. So, I would love to introduce,
to the stage, Mai Lowe and Kevin Lam.
[Applause]. MAI LOWE: Hi, everybody. Hi,
again. [Laughter].
All right. So, we know building successful
apps is hard. And, replicated that success is
even harder. All of you all are building this huge array of different kinds of apps
and you’re all in different parts of those app’s likecycles. So, some of you may be pushing
app to production and you want to
monitor its reliability and performance and some of you may really focused on user
adoption. Some of you may be even focused
on monetizing your app because you want to start earning some
revenue. Firebase is here to help you with all of those
things. We want to be here for you, no matter where you are in
the process. By helping you solve
infrastructure problems, like secure sign-In. Or saving data
to Cloud. To giving you app Analytics, so you know how your
app is performing or if your customers are running into any
troubles. And even to creating
personalized experiences that delight your users and keep them
coming back for more. At least that’s been the case
for Native on Android and iOS. But we know many of you — maybe
all of you here — are building for the web. And we haven’t given the full
Firebase experience to web developers yet. This year, at I/O, we started to
close the gap by launching Performance
Monitoring for Web. Google Analytics. You had no insight into your
userbase and how they were engaging in your content and you
couldn’t take any action in your Firebase. Today, we’re so excited to
announce that Analytics, Cloud Messaging
and Remote Config are available to use on Web and we’re so
excited to talk to you about it. Before we dive in, I’m Mai Lowe,
I work on Firebase for Web. KEVIN LAM: And I’m Kevin Lam
and I’m your Product Manager for Google Analytics. So, here’s
what we’re going to cover today. First, we’re going to give you a
quick walk-Through so you can see everything that’s been extended for your
web app. Then we’ll take a look at how
Analytics powers Cloud Messaging and Remote Config and explore
the different ways you can leverage these powerful tools
for your very own web app. And last but not least, we’re
going to put it all together with a live demo so you that you see these features
in action. Now, let’s dive in. As app
developers, you know that Analytics is key to
understanding your business. And it can often give you a
leg-Up on the competition. But getting Analytics right is a
challenge in and of itself. How do you measure the things that
matter? What do you do with that information? Now what you
need are powerful analysis tools that are both
easy to use and immediately actionable. And that’s where we come in.
Google Analytics, for Firebase, was built from the beginning, to
help you measure what matters most to your business. And it
stems from our belief in data-Driven decision-Making and
our desire to be your partner in crime, as you pour your heart
and soul in to building your apps and growing your business.
And it’s to that end that our product has always offered free and
unlimited event reporting for up to 500
custom events, no matter how large your app grows.
And the best part of all is that it all works out of the box with no
fancy code required. Now without further ado, Mai’s
going to walk you through what that looks like.
MAI LOWE: So, to show you what’s really available for
Analytics and Web, I’m going to give you a quick tour
of the Analytics console, just the major parts that we’re pretty excited about. This is the dashboard and you
get a birds-Eye view, user adoption, engagement trends, metrics,
stability metrics, et cetera. And, as I showed, in the keynote
earlier, here, you can have access — here, you see the
filter for the first time, which allows you to drill into a number of dimensions for any of
the reports that you see. So, things like time, location
and of course, now, platform. And we’re really excited that
Web is now part of this mix. If you want to dive a little
deeper, you go into Event Reporting and
you’ve have automatically collected events, events you
log. Here, you get your basic event
stats, such as how often was triggered
and a demographic breakdown of the users that triggered the
event. If you want to see how well
you’re retaining your users, you can use the Retention Report. This shows you how many users
are coming back to your app. And finally, our stream view.
This gives you realtime feedback into when and where users are
coming into your app and how they are engaging with the content that you created.
KEVIN LAM: Google Analytics has always been about more than just
getting you insights. We strive to take it a step further by
empowering you to take action. And that’s why Google Analytics
is deeply-Integrated with so many Firebase products. We want
to help you with everything from acquiring your users to engaging
with them, to experimenting with different user experiences and
that’s all to say that our goal is to make your life simpler so
that you can focus on what matters most: Building
delightful moments for your users.
The foundation on these in itgrations is a feature called Audiences,
which are user segments you define along attributes that are
meaningful for your business. Audiences are an
incredibly-Powerful and popular feature because they not only
provide rich insights, they also power action. And that’s why
we’re delighted to let you know that Audiences also now work for
your web apps. This means that you now have the
ability to segment your web users the same way you’ve always
been able to on Native apps. You can apply filters on your
reports and dashboards so you can drill deeper into the user journeys of
specific segments. As an example, you can now carve
out your super users. Say, those who have spent more
than $100 in the last month or users who have made more than 20
bookings in the last year. I can even, now, isolate the
users who experienced a crash. Setting up these audiences is
now even easier than ever with the
Audience Builder. While we keep saying that
Audiences power through action, you may be wondering, what kinds
of actions? Well, if you’re an eCommerce
business, how about sending a targeted notification to your
most-Engaged users, thanking them for being loyal customers and offering them a discount on
their next purchase? About offering regional
experiences by highlighting games that are occurring in your
users’ home countries? We’re excited to let you know
you can do any — and all of the above —
with your Firebase web apps, using Cloud
Messaging and Remote Config? MAI LOWE: Let’s start with
Cloud Messaging, or CRM. Is it new? Well, what’s new is that FCM for
Web is now powered by Google Analytics. You can send
targeted notifications based on new signals that are
specific to web, such as browser or OS. You can send messages to
web-Based audiences and user properties. So just like on Native, this
lets you send personalized notifications which are going to
have a much more likelihood of drawing users back into your
app. I can create an audience of
users who haven’t come to my app in the last seven days, inviting
them to come back. Or, I could present a subset of
them with a coupon because I know they have a higher lifetime value and
therefore, a greater tendency to make a purchase.
You can create all of this, easily, in the FCM console. You can also track the success
of your notification using the Cloud
Messaging Funnel Report. This lets you see whether the
notification you’ve sent actually brought you the user
engagement you were hoping for and all this in the
FCM console. Another way to personalize the
experience on Web is with Remote Config. So Remote Config allows
you to have different configurations of your app for
different segments of your users. It can be basic, like browser or
OS or something more complex, like an audience or a user
property. Say, for example, you want to
delight your most engaged users and
reward them? Maybe with a badge? You can do that by
changing your app’s background and have a celebratory note or
maybe a premium offering. It’s so easy, because you can
leverage the power of Google Analytics
Dynamic Audiences. You pick an audience from the
Remote Config interface and that’s it.
You’re done. KEVIN LAM: We just presented a
lot of concepts and features. To make this more concrete,
let’s take a look at a real example that puts everything
into perspective. Meet Friendly Eats, an app we
developed on Android and Web. Friendly Eats is a rating and
reviewing app that allows users to perform three basic tasks.
Users have the ability to filter for certain types of restaurants,
based on category, location or a certain
price point and provide star ratings
and ultimately, write reviews so that other readers can benefit
from a collective knowledge of an entire app’s
userbase. Like similar apps, Friendly Eats
relies on the community of users and naturally, I’m going to want
to grow that community and foster their engagement. So things like confusing or
clunky user experiencing that prevent
my users from writing a review and completing them are really
going to hurt my business over time. In contrast, if I want to
grow my business, I need simple, yet
powerful tools that do a few things. I need to be able to
monitor how my users are growing over time. I also need it to show me
whether or not the techniques I’m applying are working. I need the ability to take real action, based on insights I’m
gleaning. Let’s look at all of this life
so you can get a real feel for what this looks like in the
product. MAI LOWE: All right. Woohoo!
That worked. So, as Kevin said, the core of
Friendly Eats are users writing and submitting reviews. So,
let’s think about what some options are that we can do here.
You can send a notification to all users who started writing a
review, but they didn’t finish. I could send a simple message
saying, come back, finish that review. I need to create a segment that
groups those target users together. I know I have an event called
Start Review. I another event I log when
someone hits the cancel button. So, I’m going to target the
group of users that logs the Start Review
event and then logs the Cancel Review
event. Let’s go to Audience and set
this up. And I’m going to create a new audience. It’s
going to be a custom one. First, I want to make sure the
user even looked at a restaurant. So, we’re going to
say,” open restaurant listing. ” And then I’m going to add a
sequence condition. And the first step in that
sequence is, starting a review. And then, I’m going to add a
step and I want it to directly follow
the” start review event. ” And it’s going to be the
Cancel Review Event. All right. Here, on the right, you see a
rough estimate of how many users will be included in this audience and
it’s just based on your last 30 days of data. If I were to do
something with this audience, how many users would it target?
So, again, I created this audience earlier. So, I’m not
going to save it. I’m going to click out. And now I have my
audience set up. I’m going to go to cloud
Messaging to set up my notification. I’m going to
create a new campaign and title it” come back. ” I’m going to say,” please
finish writing that review. ” So, now we’re going to go to
Targeting. And Native and Web are now available for targeting. So I’m going to click the
Friendly Eats web app first, and the audience
I just created called Canceled Reviewers and because I’m on
Android, I want to target both. I’m going to go,” add another
app. ” Pick my Android app and select
the same audience. Canceled Reviewers.
We get to scheduling. Again, scheduling is live immediately
by default. But you can always schedule to
be on a different date, use the calendar feature, you can have
it be recurring. It’s pretty handy. And you
could even add a conversion event here, so that you can take
advantage of the funnel report that notifications has in the
console. I won’t do that for now. So,
I’m going to review. And I’m going to publish. And I should get a notification
— should get a notification. Well, it would show up right
here, if WiFi was on my side.
[Laughter]. So, let’s say that’s not all I
want to do. So, let’s take it a step further. I want to show a
dialogue box when somebody enters my app and I
want to say to them, welcome back, can you
finish that review? So, I just want to give them another little
notch. So, I’m going to use Remote Config for that. And
here I am, in Remote Config. And, I set up a condition in
advance. It’s a dialogue for unfinished reviewers and it
targets the canceled reviewers that I set up earlier. I’m going to go to parameters
and I’m going to set this parameter
equal to true for this condition. I’m going to update and publish
the changes. And then let’s reload this
instance. And there it is. Welcome back. We would love it if you could
finish the review. All right. I got my notification sent. I
got my dialogue box up. Now, I want to make sure I
continue to monitor how my users are moving through the path, to
the event that’s important to me. So, submitting a review in
Friendly Eats. Lucky for me, Google Analytics
built a bunch of new features that make that really easy. You can access these features by
upgrading to the full Google Analytics experience and some of
you, who with current Firebase developers, may have noticed a little prompt in the
UI that’s telling you to do this upgrade.
Once you upgrade, you have access to a slew of incredibly-Powerful and
new analysis tools that I’m pretty excited to share with
you. They’re all just a click of a
button away in the Google Analytics UI, so you go straight
in here. And while all of these features are really awesome,
there’s one that I’m just so excited about. And I think
you’re going to be, too. So, we’re going to go to
Analysis. Go to Analysis Hub, and, yes!
The feature is Closed Funnels. So, for those who don’t know
Funnels — and are wondering why I’m so excited about it.
They’re a sequence of events or steps that you expect a user to
move through before they do the event for you, which is usually
a conversion event. This report is incredibly helpful to you so
you can monitor how users are moving through the path, where
they’re dropping off and you can adjust your app accordingly. So
you know this is what people are doing before they do this
important conversion and this is what they’re not doing. That’s why they’re not doing it. So, I’m going to start setting
one up so you can get kind of a feel for the product. You basically go into the
editing of steps. And, then you can name your
first step,” open app,” for example,
in Friendly Eats. For us, it’s going to be the
Session Start Event. You can add another step that
says” view restaurant. And, that event is going to be
the Open Restaurant Listing. And, I won’t be repeating this. Basically, you want to do this
for every step that’s logical for your particular app in the
Funnel. So, I created it earlier, as you
saw. And we have Open App, View
Restaurant, Start Review and Submit Review.
So, another feature that’s incredibly powerful is called Segment
Comparison. Let’s take these out so I can show you live. And, basically what Segment
Comparison is you get to compare two
segments side-by-side, you can compare platforms side-by-side.
It’s incredibly easy. You can see, in the UI, the segments
here on the left, you just drag them here into the segment
comparisons. And then they update and there you go. You
have two funnels, side-by-side. So you can monitor how users are
moving through the path and how it’s
different for Web and Android. All right, I’ve shown you a lot
of stuff. I showed you how to navigate
through Analytics for Web. How to set up a notification
campaign in FCM. I showed you how to use Remote Config so you can configure a different
kind of app experience any kind of user
segment you want. And then I showed you to get
some advanced analysis so you can
analyze your strategy. This is going to help get users
back into my Friendly Eats app and
help my business and help the end users
find restaurants that they delight in and have moments
there. Back to the slides, please.
KEVIN LAM: As Mai mentioned, we covered a lot in this session.
But we’ve really only scratched the surface because there’s
still so much more for you to explore in Google Analytics, using our powerful
analysis techniques, including building
segment overlaps and exploring user journeys through path
analysis. Now we won’t go into detail on those, but we’ll let
you explore them on your own or you can come to the
#AskFirebase and learn more. With everything we’ve shown you
DO day, you may be wondering, how do I get started? The great
news is that it’s incredibly easy. Everything we’ve shown you today
is ready and available to you. Now
if you already have a Firebase project, don’t worry. All you have to do, as Mai
mentioned, is upgrade to the full Google Analytics experience, add a Web SDK and
you’re all set. To close, we want to leave you
with a simple takeaway, that Firebase
is here to help you build better apps
and grow your business. Now on the Web. So, we want to thank
all of you, here in the audience, and those who are on
the livestream, for joining us today on this journey. We
sincerely hope that we helped you get closer to delivering your
web app A-Game. Feel free to find us at the
#AskFirebase Sandsbox. Thank you, all, and enjoy the
rest of the summit. [Applause]. -Please welcome on to stage,
Sachin Kotwani and Ibrahim Ulukaya.
[Applause]. -[Speaking Spanish] just
kidding. This topic can be complex
enough, to talk about it in English, I won’t attempt to do
it in Spanish. Hi, everyone. My name is Sachin. I’m a Product Manager on the
Firebase team and I work on ML Kit and here is my colleague,
Ibrahim. And today, we’re going to show
you how you can introduce machine
learning. Before we do that, Ibrahim, why
don’t you tell us what machine learning is?
IBRAHIM ULUKAYA: Como? I thought for a second, Sachin
decided to go in Spanish. We’ll talk about what machine learning
is and how ML Kit makes it easy for you to implement in your
app. And we’ll go through a few
real-Life examples. Should we get started? Let’s roll. So, what is machine learning?
By definition, machine learning is a field of study that gives
computers the ability to learn, without being explicitly
programmed. So, what do we mean by that? Traditionally, software
development is implementing rules. Let’s say we have this app and
we have activities. So, we have this data. We can say if the speed is below
certain threshold, this is working. And, we go one step further,
another statement and we get it running. If we go even faster, maybe we
can estimate it. But, I just realized, there’s
another thing on my app — on my slides. He likes golfing, but how do we
go through detecting golf ing? Just detecting the speed is not
going to be enough anymore. And in this case, we need a
different kind of programming. In traditional programming, we
have all of the rules set. You get the data and we’ll get
the answers. But in machine learning, we don’t have the
exact set of rules yet. So, we’ll need some of the previous answers to get the rules, first.
In machine learning, we will need models and training data, so we need
some of those answers, some labels,
we’ll need to teach our computer what it
looks like or how it looks like. We have labels and a different
set of sensor and say, this is what it
looks like. Then we start training our neural network,
saying, this is running, this is biking and this is how
golfing looks like. So, machine learning has two
faces. The first face, we have the
previous answers we created the model. Now we have the model. We can go through and create
predick dictions with the data we have. So, how does it work? Let’s say we have a recognition. For us, we can detect that this
is eight. But it’s quite an intensive step for eyes and
brain and for computers, maybe we can estimate it’s traditional
programming. We can say for eight, it is two
loops on top of each other. Is that easy? Let’s say we have this example
of 28X28 for pixels. If you use this inputs for zeros
or ones for pixels, then we can
start training our neural network and end up with answers
at the end. Here, there’s one of neural
network in action. We are converging to a model
that we can detect digits. Up until now, software
development has been about statements and using
input data. Here, we cannot explicitly set the rules
anymore. We need to train our neural
network, tell the machine, this is what
this digit looks like. So, how about the steps to
implement machine learning? Historically, this was a big
deal involving ML experts, lots of time and money. And data scientists would
collect training data sets. Usually, ML expert or Ph.D. researchers had to develop the
model. The expert would then train the
model and tune, as needed. Finally, once the model is
ready, we have to deploy the model to our
systems, DevOps will do that. After all these steps, the
developers can start predicting. Can use this model to predict.
This is a quite extensive stage. That’s how we end up with ML
Kit. ML Kit is Google’s machine
learning SDK for mobile. With using ML Kit, we can simply
skip all the stages I mentioned earlier, come up with just inputting the data
to our libraries and come up with the prediction and it can
be all done by the developer. By using the bass API, it’s easy
as selecting the model you need. They were for iOS and Android
devices. We’ll have Cloud APIs. If you’re an advantaged user,
you can use the ML Kit for your models. It’s only a few lines of code to
implement. For now, currently, we have
Vision APIs such as barcode scanning, face detection, image
labeling, text to cognition, object detection, all out of the
box. We have natural language APIs,
such as language identification, smart replies, on device
translation. If you want to bring your own
model, we will serve it as well. If you’re an advanced ML
developer, you don’t need to republish your app every time
you update your model. If your update your model and you want
to implement a new one, you don’t have to go back to store
and wait for approval. You can update your model on the fly.
Today, I want to present a real-Life problem. Let’s say we
have this app. It could be a financial app or a
bank app. Let’s say we want to submit a
form of ID. We realize that often people don’t submit the
right type of document and we’d like to catch that in the
earlier process. Let’s go from the simple
solution, first. Let’s say we want to recognize a
text in the ID so we can come up with
some solution. Say, that it is veryified ID or
not right ID. We have two flavors of the API,
the ondevice API is completely free
while the Cloud API is free after
1,000 API calls, per feature, per month.
Ondevice is perfect for low-Latency, such as realtime
implications. It does not require network. The cloud API has highest
recognition. The ondevice API is good for
text and images and can recognize characters. While the Cloud API works with
text and recognizes broad range of languages and special
characters. I would like to go for a demo. Sachin, I would like to — so, let’s go for identification. Let’s use the realtime
implication. Detection. And we’ll go for one of the IDs we
have here. I’m using the ondevice API. As we can see, I’m detecting the
names, addresses, the other things in the ID. And, if we want to get, like, a
high resolution or we want to use it in dense text, we can also use the Cloud
API. Such as I can detects one of the
things I just found, the scavenger
hunt. Let’s take a photo of it and
we’ll use the Cloud API. Okay. So, here is the detection
results. We have a much better detection,
higher accuracy and we were able to
work in the space. So, this was only text
cognition. What if there’s, like, different pictures on the
ID and also, you want to see how an ID might look like? We also have the image labeling
API, maybe I can give it a try on that one, as well. So, let’s take the picture of
the ID, here. And, we will use image labeling
here, ondevice one. And, I think they’re not going
to get that quite yet. So, having said that, I want to
give it to Sachin — hand over to
Sachin, who will go over the more advanced
solution. SACHIN KOTWANI: Thanks,
Ibrahim. Okay. Can we switch back to
slides? So, like, Ibrahim said, what we
want to do, here — let’s think back of the problem.
We want to identify what type of document we are dealing with,
right, so before a user submits it in an application, we can tell them,
yes, it’s a driver’s license. It is good for identifying
objects. Ondevice, it identifies 400
different types of labels. In the Cloud-Based version, it identifies 10,000 different
objects. Let’s see what the ondevice
would say. For Ibrahim, it says news. For me, it said, paper, poster.
They’re not useful for my use case. So, what do we need? What we need is a custom model
for our application, for our use case, that can identify the
things that we want. Traditionally, you could always
create your model in Tensorflow. We have AutoML Vision Edge. It was launched last year at —
and there was a Cloud-Based version of it. Like Ibrahim
explained earlier, when you’re creating a machine-Learning
model, there are two steps. You train the model and you use the
model. The AutoML Edge product allows
you to train the model in the Cloud, but then the model runs
fully on device. Once the model is actually in
the application, you don’t need an internet connection. You can
start using it. Okay. So, how does it work? Going back to the steps of
building an image classification model, you’d have to prepare
data, train the model, once you’re satisfied with that, that
takes a lot of time, you do a lot of iterations and then you deploy it and then
you use it. With AutoML Vision Edge, you
need to bring the training data because that’s how you’re
training the model. You have different classes. You
bring it with an ML Kit. It will take your images, it will
train the model, tune it, evaluate it and deploy it for
you and leave it ready to be used.
So, for our particular example, we’re going to take images of driver’s licenses and business cards and
random images. We want to catch that, as well.
They go to the AutoML service and what you get is a Tensorflow Lite
model ready to use ondevice. So, let’s see it on the console.
Switch back to the laptop. Okay. Great. So, I’m in the
Firebase console. And I go to the ML Kit section. And then I
click on” AutoML. ” The first thing I’m going to
do is add a data set. So, I’m going to call it” license. ”
Here’s where you choose whether a data set has single labels or
multi-Labels. So a single image can be one
more or more than one thing. In our example, it’s simple. We have three labels, so it’s a
single label classification and once the data set has been
created, the next step is to upload the images. And you do that — you can do in
a Zip Format if you want. The way the zip is constructed is
it’s three different folders. Each folder is labeled by the
thing it has. I have a folder for driver’s
license, business cards and another one
for” other. ” I zip all that together and
upload it. I’m going to show a data set
that I uploaded earlier. And this has images from all
three of those categories. They’re labeled. I can switch
the labels of the images. I can add more images if I want. You
can see there’s a warning here, and that’s because while AutoML
Vision Edge will work with as few as 10 images, we recommend
that you have at least 100. And really, for a good machine learning model, a lot of
training data is key. But if will work. So, we’ll do
it for this example. The next step is to train the model.
Here, I have two choices to make. The first one is the
architecture of the model I want to choose. I can choose one
that’s higher accuracy, but it’s going to be
slightly slower, more latency. It has more layers, more
complex, so the data takes a little bit longer to pass
through. It’s also a little bigger, but that’s the way to do it with high
accuracy. If you want a response really
quick, you would choose the lowest latency and you have a
choice in between, as well. The next thing you would do is
you would choose the number of hours you want to train the
model for. The way I like to explain this is, imagine that you are studying
and you have a page, right? You can probably learn the page
in a minute. If you have 10 pages or a book, it’s going to
take you longer. Similarly, with machine learning
models, depending on how big the data set is, you need more or
less time to train. The good news is that this is an
upper bound. If you select eight hours and the model
optimizes, it will stop training and be ready for you to use.
Okay. So, here, I would click” start
training” and that would take a few hours so I’m just going to
jump to a model that’s already been trained. And, here, we can
see the precision, the recall and the expected
latency of this model. You can also see a confusion matrix
which basically says, in the test part of the data set, every
time we gave it a business card, how did it perform? So, it says that it confused it
with” other” a few times. That gives you an idea of where your
model is getting confused and where you should introduce more
data. You potentially want to add more business cards and
more” other” images. So, these numbers are actually
not very realistic because I have a very small data set, but if gives you an
idea of how it works. Once the model is ready, you can test it
within the console. You can upload an image. That’s
a good way to test it without implementing it in your app. We’ve created a model here and
we haven’t written a single line of code and we don’t need
machine learning experience. So now that we have the model,
what do we do? We have to use the model. Here, we have two
options. The first option is to download
the model and have it with the app. The other option is for me to
publish the model on Google’s
infrastructure. The benefit of publishing is if
you choose not to bundle it, the initial install size is smaller.
Also, when you publish the model, you can — because it’s in the Cloud
and it gets downloaded dynamically, you can swap it
whenever needed. Let’s say if I have a model and I have improved
it with more data, I can switch to a different model and I don’t
have to redeploy my app. So, let’s go back to the slides.
So, let’s say we want to publish a model. By the way, the recommended way
is you do both. You download the model and
publish it so you can swap it. I publish it and give it a name.
I call it” license model. ” So then I’m going to configure
the labeler and load the model and
pass the image to the labeler that I’ve created and have onsuccess listener,
onfailure and onsuccess, I get all the labels and I can start
extracting them and see what the predicted labels are for that
image. Okay, so let’s do a quick demo. Switch to the — okay. All
right. So, I pointed to a driver’s license and you can see, it says”
driver’s license. ” And then, let me point it to a
business card. And it says” business card. ” Okay. Great.
So, back to the slides. There were two APIs. You saw the first thing that
happens was we created a bounding box,
it’s a Base API and took the cropped image, passed it to the AutoML model
and it predict predicted what it was.
It doesn’t mean it’s a toy model, it’s not good. It’s
actually state-of-the-art 1. 8 times faster than the V2
models and those are difficult models to create. There are many possibilities,
designs are challeng challenging. Here, you upload
the images and you get a model. What if I want to add a new type
of document? Let’s say we bring our
application to Spain. We have driver’s license,
business card, but maybe detecting
passports? We add an additional class of
images called” passport. ” We pass that to AutoML Vision
Edge, Tensorflow Lite is ready to use ondevice.
I have two models, what do I do? Switch it on production? That’s
the kind of thing I like to do, but I don’t think it’s
recommended. You can deploy multiple models
with Remote Config. In the code, in the application, we
would hard-Code the model name, say license model, and that would
retrieve that from the Cloud. I publish a second model and
call” license model ES” for Spain. I
create a Remote Config parameter that allows you to do parameters
that you can switch on the fly. I’m creating a parameter called”
my model. ” For users in Spain, they’ll
get” ES” so — and the condition called Spain is going to be
triggered if the user is in the country,” Spain. ” In our application, instead of
hard-Coding license model as the string, I’m going to switch it
to the Remote Config parameter. It gets the right value, license
model ES and license model otherwise.
Okay. So that’s how we implement a
model, an AutoML model in our application.
There’s still a part that’s a little tricky here to do. How do I get the training data?
We actually ran into a similar issue when we were implementing
our application. So we created an open source
Called Custom Image Classifier. What it allows you to do, you
can create a data set. Next, I can start collecting
samples. So, my example would be driver’s
licenses. Here’s an example of collecting
a picture of an apple. I can even take a short video, which allows me to pan around it
really easily. Not only that, but you can
collaborate with others. So, I can invite Ibrahim to my
project and he can add apples that he
has at home. Maybe my apples are red and his are green. We
need a lot of variety in our data. So then once we’re done
collecting the images, we can go back to the console and start
training the model there. Or we can trigger model training from
within the application. Ones the model is ready, we can
take a picture of another apple and see how well it does. So,
you can do everything, from collecting the data, to training
and testing the model, all within a
single app, open source. So, we really encourage you to
play with it, download it, it’s available
for you to download. Okay. So, to recap, ML Kit makes
machine learning really easy for you to use. It offers ready-To-Use,
pre-Trained models, Base APIs, in the Vision section, we have
landmark detection, barcode scanning, face
detection, image labeling and text recognition, object
detection and tracking, which was the bounding box in the
AutoML example. This year, we also launched
natural language, language identifications, smart reply and ondevice
translation and those with custom needs, you can always
bring your own custom model and host it with ML Kit and we’ll
serve it to your end users and if you need help in creating
your custom image classification models, you can do so with
AutoML Vision Edge. That’s all we have for you
today. We can’t wait for you to try
this functionality and give us feedback. We’ll be outside at the
#AskFirebase session. Thanks.
[Applause]. -When a man took a first step on
the moon, he was standing on the shoulders of giants. There were thousands of people
working on the Apollo Mission, the mathematicians, the mechanics,
the engineers made it possible to
safely transport the ostra nots to the
moon and back. They were monitoring the Apollo operation 24/7, ready to step in
and help at any point. How do we know all that? Because of a
very important group of people, the journalists and the
reporters. Did you know that there were
over 3,000 journalists present at the moment of the Apollo 11
launch? That moment alone was televised.
It brought us all together. Still having the goosebumps
looking at a picture like this, today, when I see entire families, friends,
coworkers and complete strangers covered in
front of the few televisions available. I’m also wondering, what if the
moon landing>>Well, it might look a
little different, right? Maybe it lookings like this?
>>Everybody is paying attention to the TV in front of them. Sees
distracted. What’s going on?>>Well, that was my first
impression too, right? They’re not looking at the screen.
They’re playing with their devices. But media is different nowadays,
right? The kid with the phone. He’s maybe reading an article
about the moon landing and the milestones that are being
accomplished in real time. He’s getting push notifications,
he’s sharing that content with his friends on social media.
Same with the laptop, you know? Everyone is consuming the
content in a way that is suited to them and they’re interacting
with it, right? It’s a personalized experience. After all, push notifications
and interactive infographic didn’t exist in 1969.>>My name is Justina and I’m in
San Francisco. In my day to day role I listen to customers such
as yourselves every day and I help you get onboarded on
to the Firebase platform and use it together with Google.>>And I’m James Daniels,
developers relations with Firebase. When I’m not at
conferences like this or meetup groups meeting awesome developers like yourselves, I’m
often spunking around on GitHub and sending pull requests and
reviewing things for our open source SDKs.
>>And today we would like to talk to you about how the media
industry has transformed over the years. It all began swift audience
engagement. And comparing the two pictures,
it’s clear that the way we engage with media and content
today is different than 1969. We have more hardware choices,
tablets, mobile devices. So, we can interact with media in a
different way. We also have different content sources on top of the official
newspapers and televisions. We also have social media, we have
blog posts. So, things have changed. But what remains
constant is the power of the great story such as the moon
landing. It still brings us all together. What has changed is
how we want to engage with that story. And the most successful media
platforms today, they are doing two things to engage their
users. First they allow them to
personalize their content experience. And second, they allow them to
interact with the content. And content personalization is
super-important to Sky UK. At British, the
television and online content streaming platform. They are
working with Firebase on modernizing their technology
infrastructure to be able to deliver fluid and immediate
mobile experiences with their many apps to their
many users. It’s great to be working with
them. The industry pioneer such as
Skyy UK have made the content
interactactive and they have no problem converting users into
subscribers.>>Speaking of media industry
innovators, would like to tell you the story of a 200-year-old
French newspaper that has completely changed how they
interact with their audience and reinvented their business model. LeFigure was one of the first
newspapers in France that successfully navigated the transition from
print to media distribution. They chose Firebase as their
main app development platform, using 11
of our 18 products to deliver personalized content across
their 11 applications. IOS, Android and web. Let’s
start with the content personalization. Sticking with
the moon landing as an example of the narrative that
we’ll be personalizing for our users.
-the moon landing took eight days. It was physically
impossible for the most devoted fans to follow the astronaut’s journey for the
entire time. Push notifications come in super-handy because they
allow the media publishers to send personalize the
notifications to the user base and update them
about the upcoming milestones. Let’s see how we can customize
this for two of our users, James and
Justina and we are about to boost out of the Earth orbit
milestone. As you know, James and I have quite different roles
at Firebase. Our personal interests are also quite
different. Yeah, definitely. You’re business development,
right? You’re used to playing with numbers, focusing in on
that. I imagine that you were really
good with numbers always, right? Probably interested in physics
and math in school. In fact, math and physics were
my favorite in high school. If my teachers are watching this
livestream, kudos to you for everything you taught me. For the Earth orbit boost, I
want to know the speed the astronauts are moving. A whopping 39,000 kilometers per
hour. Those are fine for me. I would add acceleration and a bit
of other details if we had space. But for someone like James, I
don’t know if real numbers resonate with you. How to
personalize that notification for someone like James. He
travels a lot. How many conferences have you spoken at
just this year? Oh, probably something at the
order of 20, 30, something like that.
All right. You spend a lot of time on the planes. What if I
told you that if you could move at the speed at which
Apollo 11 boosted out of the Earth’s
orbit, 39,000 kilometers per hour, it would
only take you 15 minutes to get from Madrid to our office in San
Francisco. That’s crazy. And thank you very
much for putting that big number into context for
me. You’re most welcome. Now, let’s look under the hood
and see what technology infrastructure made it possible for Le Figaro to
deliver that at scale for their users. Everything is user
authentication. And we have many ways of
authenticating your users including unanimous
authentication. I’m not a paying member, I’m
just browsing. And I stumbled to their website
and opened an app. I would like to try the service. But I don’t
want to spend minutes of my precious time putting down my
name, email, phone number. Not sure they want to deal with
them. Not yet. So, the beauty of Firebase authentication is that
the moment I stumble on their website, I will receive a unique
user ID. And thanks to the user ID, I can
immediately start subscribing to the topics of my interest. And those topics will be stored
in Cloud Firestorm, a SQL database
that supports many data structures. One in Firestore is a user
profile. My user is basic. I didn’t submit my address, I have
this user ID. But I can subscribe to three types of
notifications. Of course, breaking-news-world,
relevant for everyone. And aerospace and astronomy. That’s
perfect for me. I don’t think that will be too much for James. So, now once I experience the
content that L Le Figaro delivers and ready to
become a paid subscriber, it’s
seamlessly easy to do it with Firebase. Now you can see my
user profile. I added my profile and my email. But it’s all my topic
subscriptions that are still the same. Now, the first step in
subscribing to personalized notifications is
once my profile is set into cloud
Firestore, that triggers a cloud function
that in turn lets cloud messaging from Firebase know here is a new user and the
three topics she’s interested in. Perfect. Everything is set
and ready to go. Now, when a journalist publishes
a new article, it’s also saved into a
cloud Firestore. Super complex database. It can have data structures such
as articles. And you can see the keywords
that tell you which article it is about. So, the moment that the
journalist push this is article to production, and what’s really
cool, the journalist can actually push an article to
production without involving development teams. And that
event triggers another cloud function that tells cloud
messaging to send a personalized notification
to Justina because this is an article about astronomy. And I’m
super-interested. I’m super-happy with this experience and ready to convert and become
a paying member of Le Figaro notifications. What we walked you through is
what they did to deliver personalized notifications at
scale to their subscribers. You may wonder, when we approach
a big event, hopefully Mars landing in a few years we all
get to experience that, there will be lots of users who want
to receive those personalized notifications. James, can you
tell us more about scalability of cloud messaging?
Yeah, definitely. So, right? We land on Mars. And Le Figaro wants to push a a notification about this Ent
event to their users. Maybe there’s 8 billion people on the
planet. The moon landing had 600 million
people watching it on televisions. And the world’s
population was a lot smaller than they didn’t have phones in
everyone’s pockets. So, you know, it would have a lot of
users. So, the best thing about the architecture that Justina just presented, it’s completely
serverless, right? It can scale from zero to virtually infinity. And it relies on the Google
Firebase Cloud messaging solution to
deliver those push notifications at scale. And can we handle
that? Well, I think we can. So, FCM currently delivers 800
billion messages a day to our users on
behalf of our developers for free.
That’s a big scale. We could actually — thank you.
[ Applause ] We could deliver 100
personalized notifications to every personal on Earth today
and still have some buffer. Yeah, a little wiggle room. So,
we covered personalized content, right? Let’s talk about interactive. So, say I wanted some sort of
info graphic, right? I had the article on the moon
landing and I wanted our users when they came to the page to be
able to tell where the astronauts are along their path. So, what might that look like? So, say we have, you know, their
speed, how much time is remaining, how
many kilometers are left in their path. Maybe milestones that they’ve
already achieved. Milestones yet to hit. And make it real time, right? So, the number of kilometers
keep ticking down. So, how would we build this, right? Again, start with
authentication. The great thing is using Auth,
we can protect our Firestore from
someone pulling down the data. This could be unanimous, they
don’t need to log in with their account. Once they have authenticated,
you reach out to Cloud can have firestore
and get the data and then it real-time
syncs to the user den. Let’s look at the data
structure. Very simple, we have a named info graphic with the
current position, speed, milestones and maybe last
updated. So, say the API from NASA’s a
little slow or you’re updating it manually, that last updated timestamp
could allow you to tween in between the
different milestones. And then when those values change, you
have that real-time nature, rite? So, gone is this pull to refresh
experience. If the user’s on the page, right? They’re gonna get all of those
updates and they’re gonna see those
astronauts ticking along their path. Now, there’s a problem, right? The a the Apollo journey takes a
week. If you’re on the page, and watching it tick along for a
week, not realistic, right? You’re going for a couple
seconds and you’re gonna bounce. How do we reduce this churn?
Maybe we could actually add things like a questionnaire,
survey content, puzzles, games on the page. In this case, let’s do a quick
little trivia question. Right? There are
multiof them. And the user can answer. So, I’m gonna guess Gemini. I
was wrong. The correct answer is Columbia for the command
module of Apollo. And using that real-time nature
as I’m watching this page after I answer this, I can see these
values change over time, right? They’re interactive. It shows me
the live polling data from the users answering questions
alongside of me, making this a very cool experience. And I’ll
likely stick on that page for longer, interact with it longer. So, let’s look at building this. We’ll add in sub collections
survey quos questions, right? Put in the options, correct
answer, and keep track of the number of users that have
answered each question and the total answers. And those
together are gonna give us the statistics that we need to build
those percentages, right? Pretty simple division. And
architecturally, it looks just like the previous one, right? The users authenticate, they go
out to Cloud Firestore, it streams back in real-time.
Now, this has its limits. Namely that Firestore has a 1
QPS sustained document write rate. If you’re writing to the
same document and you have lots and lots of users on the same
page all writing to that document, say they’re
incrementing those numbers clientside, you know, we get a
couple thousand people on that page, we have trouble scale
scaling. What we can actually do is we could instead write their answer to
Cloud Firestore as opposed to incrementing those numbers. And
we can trip a cloud function and we could do a counter, right?
So, we could increment on the function side, maybe we shard
that counter to get over the QPS. And it goes back to
Firestore and then back to the user. So, here, you know, we’ve
managed to scale by writing those answers to the database. And if you run into this problem
a lot, then actually the distributed
counter Firebase extension is for you.
Keep watching this afternoon to learn more about that. Now, the downside here,
for me, is, you know, we’ve hit that scale, but maybe I don’t
care about the user’s answers. We’re writing a lot of things to
the database. Ultimately, let’s look at our
data structure and say, yes, we could — we could fix the scale
by writing those out. But how do we hone in on the problem
itself? It’s really those counters, right? When we have
millions of users on the page, those are gonna be ticking
up and down rather quickly. So, maybe we can restructure our
database so we don’t have to worry about that. So, instead, let’s just keep the
information that we’re interested in the database. The
number of people, the ratio of people that answered each
question, right? Think of Firestore this way,
it’s not only your database, but it’s your API. What information
are you presenting on the page? And organize around that. So,
let’s look at how this is built. Instead of directly writing to
Firestore, I’m going to call a cloud function from the client
side. And maybe I use MemoryStore.
That way I work in memory, I can jot down their answers, put
it in a counter. Not have to worry about, you know, storing
those permanently. Then I have a Cloud function on
cron that trips in there. That writes out to Firestore and then
the user gets their real-time updates.
That sounds really great. But I thought we were focusing on the 100% serverless solutions. And MemoryStore, don’t you have
to set it up, maintain it, apply
security patches? That’s fair. I’ve worked with
MemoryStore a lot, databases like that a lot and
I’m used to scaling them up and provisioning them. Let’s focus
on serverless. There’s great tools in the G CP
toolbox for this. One I reach for is Cloud
Dataflow. It’s going to build this analytics pipeline for us
and it’s functional. So, we can do groups and sorts and counts
and we can do these on windows, right? These windows allow us to
work around these QPS limits. We can do countereds every 20
seconds, add everything up and write it
back to can have firestore every 20 seconds. So, simply we just plug this
into the infrastructure here. And that gets us where we want
to go. And ultimately, this problem of
scalement, right? It depends on your usage, your data structures
and, you know, your access patterns. So, it’s a complex problem. But
we have tools that will help you get there. Now, we might have
gotten a little ahead of ourselves talking about how to take this infographic to, you
know, tens of million, maybe a billion users, right? A little
crazy. But what we’re trying to get across here, right, is these are things
that Le Figaro has dealt with, right? They want these infographics to
scale from zero to huge bursts of users and they don’t want to
have to manage a lot of servers. They want that churn reduce,
they want that interactive content. They want that rich
client experience. Yeah, we may have gotten a
little bit ahead ourselves here. Also keep in mind that Le Figaro
is a newspaper. The majority of their employees are journalists.
In fact, they have 400 journalists working at Le Figaro
today. So, you may wonder, how many
developers support that team of journalists and create those interactive
infographics that James just described? Five? Someone in the
audience just mentioned five. Well, the actual answer is
three. Technical journalist is a hybrid between a journalist and
a developer. And they solely specialize in data
visualizations. But they have 400 journalists
sourcing them data points. But the scaffolding they were able
to create with Firestore and
functions with readily available building blocks was they were
able to do it with the team. And it was servers serverless.
They have it across the apps, they have a team of 50
developers supporting those graphs. But infographics is
supported with just three people. And besides Le Figaro, another media
innovator, Sky UK who we introduced in the talk is moving towards real-time,
event-driven data architecture. They are working with Firebase
on that. Personalizing the experience and tailoring it to
the user’s name is really the future of how the media industry
is engaging their customers. The media industry is obviously
very different today than during the moon landing time in 1969.
50 years ago it took technology and personal courage to pull off
the Moon landing. Today the same is true for every major
milestone, every innovation. Le Figaro and Sky are innovators
in this space. All of you in this room, you’re all
innovators, you’re all playing with new technology, taking risks,
trying to build your application and get to market faster. And
all of the explorers and innovators need a team. The Apollo 11 crew, they were
assisted by thousands and thousands of people. They didn’t sew their own space
suits, they didn’t build their own rockets. They didn’t catch
themselves when they landed in the Pacific. And Le Figaro and
Sky, ultimately, they were assisted by Firebase. They
didn’t have to rack and stack their own servers. They
accelerated their time to market and innovation with ready-to-use
building blocks from Firebase. It is our mission at Firebase to
support all of you innovators in your
quest of building and running great
President Clinton your applications. And
turn your app into a scalable app with millions of users and
looking for components like an application, databases,
functions or maybe machine learning capabilities, Firebase
has your back. Now, if you already have an
application in your store and you have thousands of users and
you have to keep innovating, you have to add a new feature, but
you’re afraid you’re going to disrupt the experience for
existing users, we help you monitor user experience at
scale. And you can roll out the
features gradually, monitoring how they are experienced by your
users. And lastly, the Firebase engage
family of products will help you reach
new user segments. If you would like to run experiments of
different price points or engage users with personalized
notifications, we can also be your mission control center. We
can be your stone. Well, that wraps up our talk. It was a lot
of fun to work on it with James. But we are out of time. Well, it
was a great virtual journey to the Moon and back. And it took us only 25 minutes.
Well, I learned something today. That’s the amount of time it
would take me to travel from San Francisco to Madrid and back,
right? And back. Almost back. And grab some tapas alongside.
That was the last joke for today. Thank you very much for
attending this talk. And huge gratitude to Le Figaro and Sky
who allowed us to share their transformational journeys with
all of you today. Thank you for listening. [ Applause ] thank you
Thank you>>Please welcome on to stage,
Timothy Jordan. Hey, y’all, how are you doing? I
just have a couple announcements for you. You’re getting up, I
can see that. Probably because you’re still hungry. That’s a good thing because
we’re still serving lunch. Head out and get something to eat. Next up in here, we have a
special live edition of ask Firebase for the
livestream. If you want to check that out, please do. And for the
livestream, stick around. In a few minutes we’ll have Ask
Firebase Live. Please stand by for #AskFirebase Please stand by for #AskFirebase . – Hola. And welcome to this very
special episode of #AskFirebase, live. [speaking Spanish]
– I swear that worked when I practiced it.
– That’s hard. – Yes.
– You are right. We are in Madrid and we have a
special guest and format for this live #
#AskFirebase. – It’s a show where we invite
guests, different product experts in Firebase to answer
your questions. Submitted through Twitter, StackOverflow,
YouTube, whatever chances you’re using. If you post it with
#AskFirebase, we ask them on the show.
– Today we will be taking yes questions live right here from the
Firebase Summit in Madrid and answering them
live here. – And to submit your questions,
type them into the chat. If you’re watching this, the chat
window. Type them in. We’ll be looking for your questions and
might get selected. One special note about that is that the
questions we’ll be looking for are specific to the
announcements that happened at the keynote this morning. And
we’ll be having guests on who are experts in the products
shown this morning as well and they’ll be answering questions
related to that. When you’re posting up
questions, to increase the chances of getting selected,
make sure it’s related to that. And there were those who
submitted questions before the show, and responded to the promo
video. We have questions from there as well we’re going
answer. Stay tuned. If you submitted a question, we might
answer it on the show show. – Our first guest is Steve, the
project manager for Google Analytics. He’ll be able to
answer any ofy questions about analytics for
web, remoteon config for web, the
Firebase Cloud messaging. He will answer that. – After that, Kara Yu, PM for
Firebase extensions. Announced this morning. Questions about
that, how to install them, what they can do, you can answer the questions and we will answer
those. – And then we have Fran sis Ma,
our manager for all of Firebase. He can answer questions about
things their Firebase-wide, features
from here, from the Summit and beyond. And answer questions
about app distribution, numeric predictions and anything that
might have been covered in the keynote this morning. Stay tuned
for him. – And finally, our beloved Puff
who helped organize the Firebase Summit in Madrid this year and
will be able to answer any questions about the Firebase
Summit itself. – About to get started. Ready?
– Yeah. Go. – Our first guest, welcome
Steve. – Hey, Steve. Hello, thank you
for being on the show. Good to see you. Welcome on to the show.
– Glad to be here. I’m excited to be here. I love this event.
– Steve, we said you were the product manager for Google
Analytics, what do you do for Firebase? – Google Analytics is
well-integrated with Firebase. It measures the usage and the
data that can be used in targeting the features of the number of Firebase growth
products. – You do that bridge into the
Firebase world. – I’m the bridge between
Analytics and Firebase. – We have a tradition on
#AskFirebase, tell us a fun fact about
yourself? – I have an embarrassing one.
– That’s the best. – An irrational fear of
mushrooms. – A certain color?
– Just mushrooms. – A certain time? You see them
on the lawn, and they’re on your pizza, what gives? I love
mushrooms on mine. – I’ll take them off. Don’t
worry. – Steve, ready for tough
questions? – Bring it on.
– All of you out there, make sure that Steve can answer
questions about Analytics for web, remote config? Web and targeting for Firebase
messaging. Add them to the live feed and we
will be looking for questions. There were a lot of
announcements. Those three, they were big. Can you give a brief
overview of what was exciting? – This was a massive launch and
a massive day for the products. Today we launched the ability to
measure your web apps and engage the end users in ways that
weren’t possible before. Over the last three and autohalf
years we have built out sophisticated and seamless
integrations between Google Analytics and features in
Firebase like remote config and notifications that you can use them together for
compelling use cases to create engaging
experiences and send push notifications in a targeted way.
This has resonated with our developers. But, of course, a
lot of our developers develop web apps too. And the lack of
these abilities on the web really just stood out. So, today
we launched that same free and unlimited Analytics product
for web apps as well. And the ability to target audiences that you create in your remote
config parameters and conditions. And also in your FCM targeting.
And it’s not just this extra ability to measure web apps. But
if you have a web app and say, an iOS app and an Android app,
we also give you the ability to measure cross-platform.
– Across all three. – That’s right. If your users
engage with your product across multiple surfaces. Maybe it’s
cross Device. They’re on their iPhone
in the day and on the iPad at night. Or cross-platform, sometimes on
the desktop using web, and sometimes using phone. We give
you the ability to measure cross-platform in your own
identity space. If you have your own notion of
the identity of a user, you can supply into analytics. And the
whole platform lights up in a cross-platform way. You can de-duplicate your
reports and create audiences. – That’s really powerful.
– Based on users that do some activity on web, some on app, and target
them with the Firebase features. – That’s awesome. Any questions
that people have had that the livestream?
– There was a question submitted from someone on Twitter what
responded to our promo video from SAhan 47 from
Auckland New Zealand. This is his question. Sorry for mispronouncing your
Twitter handle. Thanks for the question. All right. So, they’re
asking — I’m struggling to understand the best solution to
show customer offers for users using
Firebase. Should I be using audiences or
should I be useing audience lookup to
match the attributes? Any help is appreciated.
– Thanks for the question. There is really no real
one-size-fits-all solution for this. I will highlight the advantages
and the aspects of the Analytics-based solution. They
mentioned custom attributes they want to track or associate with
users. There’s a matching concept in
Analytics called user prompts. It may be that you’re setting
user properties for these attributes and you can use these
as filters in your Analytics reports and create audiences off of them and you can use in
other Firebase features. One thing when I look at the
users in tarted or personalized way, it’s Firebase messaging.
They exist for this purpose. To show contextual messages inside
of your app experience to users and you can send those messages
at the right time to the right audience. And audience being the keyword
there, you can define an audience based
on the custom attributes. And in your targeted for in-app
messaging, you can make sure that the users see it at the
right time that you prompt them.
– Awesome. Sad news, Steve, that was fast. But our production
time is telling us we’re out of time for Analytics.
– Time flies. – It does. Thank you for being
on the show. – Thank you. This was so
exciting. – Thank you for having me.
– If you have more questions, Steve got into details, there
was a laundry list. But questions out Analytics for
web or config were web or Firebase
messaging, ask on Twitter or StackOverflow, wherever you ask
messages. And tag it with #AskFirebase and
maybe answer on a future episode. – Next up, if you have questions
Firebase extensions. Our next guest is Kara Yu. Nancy
before for on the show. – Great to be here.
– We know you’re a Firebaser. What do you do in Firebase
extensions in – Absolutely. I’m the product manager for
Firebase extensions that just launched under the keynote a
couple hours ago. – Cool. It’s an #AskFirebase tradition
to ask a fun fact about everyone on the show. What’s your fun
fact? – I got certified for SCUBA
diving ten years ago. I wanted to see a whale shark. I went to Honduras and the
Philippines. No whale sharks. My husband took me to Mexico
where finally I got to swim with whale sharks.
– The huge ones reason right? – The biggest living fish.
They’re 19 meters long potentially. And their like tail is the size
of me. It’s hard to keep up with you
guys. Right after that, he proposed. Whale sharks and I got
engaged. – Is there an expiration on
SCUBA diving licenses? Because if it’s ten years.
– Whatever you feel okay with pressure sensing and clearing
your mask. And doing all the things.
– Cool. Well, Kara, we got some
questions for you from the audience that are coming up
soon. Ready to dig into some of them?
– Yeah, absolutely. – All right. Cool. For the live
audience watching, this is the time to ask any questions you
have about Firebase extensions. Post them into the chat. Rachel
will now be taking a look through the chat to see any
questions you guys have. And we get picked to ask Kara
and get an answer to you. To start off with, for those who
might have missed the keynote this morning, can you tell us about can have
firebase extensions? How? Where can I find them?
– Absolutely. Start with the last question first. Find them on the website,
Firebase Firebase.google.com. There’s a Firebase extensions
there were. Our UX research who are did the keynote would like to — talks about
them as if they’re tapas. If they were a restaurant, they
would be tapas. – Very appropriate for where we
are too. – Exactly. That’s why we decided
on Spain. They’re pre-packaged solutions that allow you to
solve common use cases without having to write a single line of
code. Things like image resizing, translating text.
These are problems that developers have had to solve
over and over again and maybe in different projects. Extensions basically takes all
that have away. They’re easy to install,
configurable and open source. And you can add features without writing a single line of code.
– Nice. They would have been able to do before, but take a
few days or a week to build that. Quick to install solution
that is just work. – Absolutely.
– I actually have a question. Let’s see if I can — there’s
lots of questions in there. But we have a question from dig
ibyte. And this person asks, can
external resources be uses for an
extension? Are there other resources other than just Cloud
functions or a similar language? Like, right now what’s happening
with external resources? – Yeah, absolutely. We have nine
extensions we’re launching today. And several actually
feature third half party APIs. So, we have an extension for
Mailchimp where it automatically adds
users to Mailchimp whenever they show up on your database. And we also have a bitly one
that focuses on the bitly API to so,
it shortens URLs automatically. Extensions basically allow you
to automatically integrate parts of Firebase and other cloud
product with other services. – Third-party and Google Cloud
Platform services? – Good question. We have a bunch
of extensions that do things like help you integrate
with BigQuery BigQuery. – Ooooo…
– That’s my favorite one. I’m not supposed to have favorites,
but I do. – BigQuery, what’s the
connection with BigQuery BigQuery?
– Whenever a change happens, you can specify the extension to
listen for changes. Whenever a change happens, it sends those
updates real-time to BigQuery. You will have a BigQuery that —
a BigQuery view is that show what
is your Firestore collection space
– An easy way to send to BigQuery?
– Yes. – Any other from the livestream?
– Not yet. But one that was submitted. They didn’t know
about the Firebase extensions. They asked one that was relevant
to it. Ask that one. This one is from Jean, sorry for
mispronouncing your name. Thanks for the question. It was
submitted on YouTube. And this is what Jean had to say. My
burning Firebase question is: Are there any thoughts on adding
a feature to Firestore to operate over multiple documents
at the same time with just one line of code? So, operations like remove a
field, rename a field, change value of a field or drop all docs with certain
conditions. I have been doing this with cloud functions, creating a document
on Firestore that specifies the type of operation that I want to
perform to then operate over those documents. But I would
really like a simpler way to do this.
– Absolutely. You’re in luck. A lot of our extensions do that in
different flavors. For example, the translate text extension, when you add a field
that we’re monitoring, it will translate that and write that to
your Firestore collection. Yeah, what you’re talking about is
exactly what extensions are used for. They kind of allow you to
have — you could do that with zero lines of code, not just
one. – Right, just a click, right?
Nice. Typing. – Four clicks and a little bit
of configuration it tell us which collections to monitor.
– It gets configurable for your project or app. So you’re going
to make it your own, right? – Exactly. The powerful part of extensions
is talk actually make it fit your own use case. It’s
configurable and you can tell it which collection to look for,
which field to look for. What the name of, you know, your
translations field should be. So, you can make it match your
Firestore database structure. – Awesome.
– Cool. – So, this is a specific use
case. But are there for extensions coming?
– Yeah, absolutely. So, we are launching with nine today. And
we are always working on more features. So, watch out for new launches
in the next few months. – Cool.
– All right. Let’s see if we have anything on the stream so
far? – Will there — full text search
for Firestore. People are ask for a full text search for
Firestore extension. This is from Andres in Aukland. His name is Andres Uckland. Will there be a full text search
for Firestore? Seven searching all the strings
across the document and look for a text string.
– We have heard that before. And that’s definitely one of the
extensions that we are thinking about. I don’t think we have a
commitment quite yet to that one. But keep the feedback
coming. I think feedback like this
really helps us prioritize what to work on
next. – It sounds like people with
excited. Samuel, he says, are there any
plans for more official Firebase
extensions? People are looking for simple solutions to plug and
play. – Yeah. If you go to our website, click
through to extensions. Firebase. google.com — I should show
this. – Sad news. I’m sorry, the
bearer of bad news. – You have to pay attention
while I repeat a URL. Click through to extensions from
Firebase Firebase.google. com, and look at full list of
extensions, we’ll see not finding the extension, please
give us a feature request. As you have ideas for extensions,
please tell us. We would love to hear from you and make
extensions that help the most number of people.
– That’s awesome. That’s exciting. – All right, Kara, I’m sorry to
say, it’s sometime to wrap up at least for now for Firebase
extensions. Thank you for being on the show. Fantastic to have
you. – Great to be here.
– Thanks so much. – That wraps it up for Firebase
extensions now. But the fun doesn’t stop yet.
Submit the questions on the live chat, we’ll be looking back, or
on StackOverflow, Twitter, YouTube, wherever else. We want
more questions. That’s more feedback for us what you guys
are thinking about Firebase extensions and we will feature
that on a future episode. Until then, we have coming up. – We were able to get Frances
Ma. – Welcome to the show.
– Glad to be here. Always fun. – So, Frances, we scared you
away from all your stuff because what do you do for us at
Firebase? – Well, I have the pleasure of
being the head of product for Firebase.
– That’s a lot of responsibility.
– It’s a lot of fun. – I bet, yes.
– You get so see everything that kind of happens in our world,
right? – I do. It’s incredible to be
able to work with such a great team and see a lot
of the innovations and how to work across the team. And we
share a number of them here today. It’s always fun.
– So, tradition for us, Firebase. Your fun fact,
Frances? – Fun fact. Yeah, there was one time I was
asked to — or I was challenged — to enter into a poetry
contest. On a radio show. And so, one time —
– That sounds like it’s going to be a really interesting story.
– And I won it. – You won it?
– I won it. As a product manager and developer before, I write
lots of code. But never writing poems. So, it was like a hole in
fun. It was like writing a thousand lines of code, you’re
in the flow, and all of a sudden you hit build and
everything compiled flawlessly, it just ran. It just worked. I’m
not a good poetry writer. It was just this hole in one moment.
– This one moment in your life. – Exactly.
– Do you remember that poem? – Too embarrassed to say it now.
– Cool. – Ready for questions?
– Absolutely. – For all of y’all out there,
posting questions. Frances is our group product
manager. Can talk about things going on in Firebase land and
answer questions about app distribution, numeric
predictions or anything covered in the Firebase keynote this
morning that aren’t covered by other guests. I’m going to ask
you a quick question about everyone is asking andmenting to know, what do you see in the
near future for Firebase after Firebase
Summit? – Yeah, a lot of things we’re
working on. As I talked about, we’re always hard at work just
looking in ways to help developers succeed. And, you
know, the main themes for us in terms of investing in towards
helping developers succeed are around three things. First is
helping theming a semirate their app development. The next one is
helping them run their app more effectively. And then the third one is making
Firebase more extensible. And so, you know, not to spoil
too many surprises going into it, but expect us to continue to
be able to expand our products and also improve some of our
workflow, ultimately, with the idea that we want to help
developers focus more on doing the fun stuff so that we can
help them take away a lot of the heavy lifting.
– Yeah. That’s a good idea. Do we have any questions on the
livestream for Frances? – We actually do.
– Ready for this. – Camille F. on the livestream.
Camille is asking, are you going to push support for PWA apps and
are you going to include dart language for Firebase functions?
– That’s a really good question. As you have seen today, we have
really expanded the support for web developers and web apps
across Firebase. So, we’re really excited to see that. And
definitely, you know, a lot of the work that we have done has
been driven from the requests from the web community. You
know, whether it’s PWA developers specifically or just
web app developers more generally. So, definitely,
that’s something that, you know, we’re continuing to invest in.
It’s a really big community and an important one for us. And then in terms of the
supporting for the Dart language, there’s not — nothing
that I can announce at this point about that. But as a
general theme for us, you know, we talked about open
sourceing our SDKs. And we have a lot of SDK contributions that
are from the community. And so, we have been seeing a
lot of these innovations driven bit community. And so, that’s another avenue
where potentially we can continue to
expand more support as well. – Nice. Awesome. In fact, I
think for a lot of the open source libraries, there are
Firebasers involved who are committing to the libraries and
adding some support and some love there.
– Exactly. Very exciting to see. – Fantastic. Frances, I got some
sad news. – Already?
– I heard from the production team that we’re out of time,
actually. And time to bring on the next guest.
– Fun time goes by quick. So, well, looking forward to
have more opportunities to speak at future
Ask Firebase sessions. – Before you go, we might have
time for one more question. One —
– The lucky winner on the stream.
– Let’s see, let’s see, let’s see. Do, do, do do… can — oh.
That’s a database question. I don’t know. Let’s see. There’s an app distribution or a
predictions one. Oh, I actually saw one. Let’s ask about how can —
there’s one it’s about predictions. It’s kind of
general. But how can they use predictions in their app? This
is a product that not a lot of people use right now.
– Well, we have a lot of interest in predictions. That’s
a good common question that we ask — that we get asked about.
How do you use predictions in your app? A common use case we
see is that for people use in promotional use cases. So, you
know, whether you’re building a commerce app or you have in-app
purchases. Common use cases, predicting users that are likely
to spend or users are that are not likely to spend. And
specifically, let’s say if a user that’s not likely to spend,
you can then set a target, let’s say using
remote config tolet say lower the
price, offer a special discount. The spirit of it is being able
to take these predictions and offer more
personalized experiences with remote config. That’s a more personalized use
case and we offer that as well. – I just got word. Thanks so
much for being on the show. Thanks, Frances.
– Thanks so much, Frances. So, Frances only got to answer a
couple questions. We know you have more questions about the
Firebase roadmap or different things down the pipeline. Or
questions about app distribution or numeric predictions. Make
sure you ask them and tag them with #AskFirebase. And on a
future episode we might be able to get those questions answered
for you. – That’s right. And now we have
another guest on the show. We will have on our dearly
beloveed Puff. Hey, Puff. Good to see you.
– Good to see you too. – All right, Puff. – What questions do you have for
me? – You’re at Firebase, but
there’s so many thing use do, you’re an all around Firebaser.
The fun fact about Puff. We know a few.
– Tell me. – A fun fact about Puff? – Most original Firebasers think
I joined before we joined Google. But it’s not true, I
joined afterwards. – I thought that. And you told
me that was the case. And I still thought that.
– Original with Firebase. They believed that I was there when I
joined. Because I say things like, when we joined Google.
– All right. Because it is a team, right?
– Yeah. Exactly. – Well, Puff, we have questions
for you. – Tell me. I haven’t been
answering questions all morning yet. Let’s do this. – And Puff, we can only ask one
question. We’re getting the signal to wrap
up. – What’s the one question that
everyone wants to know?
– I’ll ask one question. We had it in Berlin, a.m. ster Berlin,Amsterdam, Prague
and now Madrid. It’s a rich history and a lot of the stuff
today. There’s the sessions, the code labs, the women tech
makers. What do we have going on, tell
us about that. – I’m asking that you’re not
asking me to pick one favorite. That’s the least — we get them
and then they go to pick up their swag, sorry. It’s not the
nicest word. They get a shirt, get a pin. They’re here. We’re
very happy that they’re here. Then we have a few demos. We actually have twice as many
demos as last year. And we have our famous ask
Firebase. In person outside, you can ask Firebasers. Also wearing
yellow shirts. Trying to keep it confusing. That’s always a big
one. We have a few games that you can play here. But those are old like
lightweight lightweight activities. But the main things
are the sessions on the stage, including this
#AskFirebase. And starting in seven minutes with the next
session here. And we are —
– It’s time to wrap up soon. – We have community talks and
Google Dev, of course, being present. And then we have food
and drinks. Are you Hungary hungry?
– It’s tasty. We’re in Spain. It’s hard to get food that’s not
tasty. It’s tremendous. – It’s been fun. – Well, Puff, we’re getting the
wrapup signal already. To all of our viewers who tuned
in. Thank you. See you future. – Post questions, StackOverflow, YouTube, Twitter, #AskFirebase,
we might answer it. – If it’s on StackOverflow, I
might answer it before then. – Definitely answer before then.
– Stay tuned to the livestream. – See you all later, bye! Welcome to Firebase Summit! Welcome to Firebase Summit! Welcome to Firebase Summit! -Would you be quiet! I’m working on a video for
YouTube. But I want to add pizazz to it.
They have read and write rules to it. I will say — -In my regular life, I’m pretty
certain that I get through three sentences in a row and as soon as I’m on
camera, I’m like… -To release a new version of
your app and the new feature is causing
crashes. -It doesn’t really involve pizza
this time. -I don’t know why kids get all
the fun. -What exactly is the life for a
zombie? -This is something people really
want to know, Michael. Tell me when the release is?
[Laughter]. -Let’s open our pod file. -I’m not a robot, I promise. -My Furbie’s dead. -Do you have a copy of War and
Peace? -I live-Code it.
-Using different apps. We built shared albums in Google
Photos. -Good morning, everyone. Welcome to the Firebase Dev
Summit. -We provide tools that help you
across the lifecycle of your app. -How did you get into the
studio? -I got to go.
-Cheese! Oh, you blinked! [End of video] Up next: Overcome Launch
Anxieties and Ship Apps With Ease By Rebecca He and Rob DiMarco -Please welcome, on to stage,
Todd Kerpelman. [Applause].
TODD KERPELMAN: Hi, everybody! How are you doing? Are you enjoying the conference? How many of you have done the
scavenger hunt? Were you able to find the
pineapple? If you’re still looking for it, I think she’s hanging out near the
photo booth. While I’m up here, raise your
hands — now this is a toughy. Raise your hands if you’ve ever
built something using Firebase? All right. Keep your hands up
if you know how to write a sentence? Whoa! A lot of hands went down. More
than I thought. Do you know we have a Medium
publication? It’s made not just for, you know, people like me
who like to write, but for anybody out there in the
community, who has maybe done something with Firebase and
wants to tell the rest of the world about it. I think we
have, you know, how to submit stories and if that’s not up there yet, you can just, like,
ping me on Twitter. If you want to write a blog
while developing with Firebase, you should go ahead and tell us about it and
we’ll put you on our publication and then you’ll get to be
famous, sort of. We’ve got, I believe, four
talks, four presentations coming up that all kind of follow a theme of after you’ve
launched your app to the world. There’s a lot of work you need
to do to nurture your app and monitor
and it is successful. And, our first presentation, in this
theme, is going to be from Rebecca He and Rob DiMarco, who
are going to be talking to you about how to take
that frightening moment and make it
less frightening. Please welcome Rebecca and Rob
up on to the stage. [Applause]. REBECCA HE: You know what’s a
great feeling? Launching an app. You know what’s really
scary? Launching an app. Today, we’re here to answer the question: What do I need to
know before I launch my Firebase app? My name is Rebecca and I’m an
engineer on Firebase App Distribution.
ROB DiMARCO: And I’m Rob DiMarco, Firebase lead for
products. Let’s start with a story. Together, we’re building
a gaming app. It’s a really cool concept. We’re excited
about it and we want it to be used by people all over the
world. We start by building a
functional prototype. We’re testing it out with our team and
iterating on it and fixing all of the bugs we find as we go
along. We think we’re almost ready, so we set a launch date.
Still, we’re feeling anxious. We fixed all the things we do
know, but what about the things we don’t know? Launch day is
rapidly-Approaching and we go for it. Early signs look
promising. We start seeing downloads. We’re generating some
buzz. REBECCA HE: But then the bug
reports start to come in and on the app Store, we’re seeing
mixed reviews. We see five-Star reviews, but we
also see one-Star reviews and we feel anxious and scared. Some
customers are saying they really don’t like a certain feature of
our app and a handful of others are saying the app crashes for
them. Then, to make matters worse, we
get a security invulnerability report. Users can cheat their way to the
top of a global scoreboard and it becomes a big joke. All eyes are on us.
ROB DiMARCO: At this point, we’re obviously feeling pretty
bummed. We put a lot of work in. We really wanted that
launch to go well. But all of these issues were preventable.
So, what did we miss? That is what we’ll be talking about
today. We’ll give you the tools to gear
up for launch. REBECCA HE: What happened? We
built an app. And then we launched it. But then we started seeing
unexpected bugs and bad customer reviews. It seems like our testing had
missed something critical. So now, we probably wrote some
unit tests and tested on a few
emulator and everything looked find. But deep down, we were
still wonder, what would happen after we launched? So knowing
this, how can we gain confidence in the quality of our
app? The key is understanding that
users have different backgrounds and use different devices. Our
users are diverse. So, our testing needs to be
diverse, too. Given that, what can we do?
ROB DiMARCO: First, we’re going to need real devices. Testing on an emulator simply
isn’t enough. Next, consider, what if our
users use a different language that we do? We need to test
different situations, too. We also can’t forget about
having a very diverse tester base. It would be awesome if we could
our app in the hand of real users before going live.
Now, we know what we need to do, but it’s a lot of work. We’re
really focused on building something that our users love
and we don’t want testing to introduce
any additional stress. Firebase Test Lab makes
automated testing so much easier, instead of having go out
and buy physical Android and iOS devices, Firebase Test
Lab stores those in a Google Data Center. You don’t have to.
Different screen sizes, different languages, different
locales and the many combinations of those factors,
Test Lab will do that for you. How could we have used Firebase
Test Lab to figure out why our app was crashing for different
customers? REBECCA HE: One way is by
running a robo test. It does a search analysis of our app. It
will go to different screens, click on different buttons and
really try to test all the user paths. So, let’s go to the demo and see
how this works. ROB DiMARCO: Ummm. This should be fun. REBECCA HE: Thanks, Rob. All
right. So now we’re in the Firebase
Test Lab. We’ll start by hitting” run a
test” and select” robo test. ” An error is occurring while
loading this page, so we’ll try uploading it here. We’ll upload our APK, it would
validate and then the next page, we would see is a device matrix. So, on this page, we have the
option to select so many different
physical and virtual devices. And, the default selected a few
pixel twos, but I want some variety so
I can pre-Load a template and so I will select the pixel two, a
pixel three and let’s just get an older device, just to shake
it up a little bit. And then at the bottom of the
screen, we also have the option to select a different
orientation and also, different locales if we want to
test different languagesment we would start by hitting” start
three tests. ” This will take a few minutes
to run, so let’s just look at the results from a previous
example. Can we switch back to the
slides, please? All right. So, after a few minutes, we
would have results that look like this. We immediately can see that two
of our test paths didn’t, one failed. Let’s go through the results,
one-By-One. Let’s look at the Nexus 5. So, here on the test result
screen, we see that our test past, our robo
was successful in crawling our app. There are a few different
tabs we can dig into with more information. Here on the first page, we have
the crawler metrics. If we scroll down to the bottom,
we’ll see a crawl graph. This gives us a sense of all the
paths the crawler took. But, a robo test doesn’t just
tell us if a crawl was successful, if it
crashed or not. On the screenshots tab, we also
have the opportunity to really visualize our app and we can even see where
the crawler interacts with user inputs. On the videos tab, we
get a similar, but more detailed view where we can actually walk along the entire
crawler experience. Both the screenshots and the
video give us a really great sense of how our app looks and feels across different
devices. There are two more tabs, log and
performance, they are useful for debugging issues.
All right. So, I’m feeling good about the
Nexus 5. Let’s look at the Pixel 2. So, here we see the Pixel 2
crawl passed, but we see a new tab that says” test issues. ” Aparaantsly, we’re using an API
that will no longer be supported. We’re just safe for now, but
doesn’t this mean it’ll be a problem for
newer devices? We’re feeling concerned. And then if we go
back, and this time we look at the Pixel 3, let’s
figure out why it’s failing. So, our concerns are confirmed. If we dug into the logs a bit
more, there was a” no such method”
exception because that API was no longer supported.
We realized that this is why we were having mixed reviews.
Customers on older API levels were fine, but customers on the
newest API level were running into this crash. In just a few minutes, with
little setup, we found the reason why our app was crashing for our customers.
ROB DiMARCO: Robo tests are really powerful. We can run highly-Customized
tests. Firebase Test Lab lets us to
perform end-To-End tests in one place. Now that we’ve run Firebase Test
Lab, we’re feeling a lot more confident. No matter how many
devices we test on, automated testing doesn’t have context.
The crawler doesn’t understand what your users actually want to
do. We need real users to be able to tell us if the user
experience is confusing or unintuitive. We need some level of manual
testing. That’s where Firebase App Distribution comes in.
Let’s walk through it. Instead of having to manually
send all of your APKs, you can manage
your distributions in one place. In once central location, you
can attach release notes and send to testers. You can get started instantly
with no SDK. It also provides an intuitive UI
for you to manage testers and create
groups. You may want to create one for
iOS and one for Android. When you upload a new distribution,
testers get emailed instantly. App Distribution also provides a
tester UI so your testers get to choose
which version of the app they want to
install. During the keynote, we demoed
how App Distribution can we used. You can distribute iOS and
Android with the Firebase CLI or the
plugin. We understand how important automation is for you
and we want to give you the choice and flexibility to use
Firebase App Distribution. Let’s look at the Gradle plugin
and see how it works. REBECCA HE: Going back to the
example of when we had one-Star reviews, how could we have used Distribution
to get ahead of that feedback? Let’s check out a demo. So, here, I’m on the Firebase
console for my app. I’ve already distributed two
versions of my app. But now I’m ready for version 1. 2 because I’m releasing a new
feature. So, to distribute with the
Gradle plugin, I’m in my build.gradle.
The first thing I need to do is apply the plugin and add the
dependency. Then, in the specific build
variant, you can specify a Firebase block
for the parameters you care about. We’re specifying a service
credentials file, release notes, to let
testers know what’s included in this new version, and groups and
testers, the people who we want to receive a distribution
of our app. So now that we’re ready, we’ll
go to the command line and run a command. We’re going to first
assemble the debuged version of our app and
then run App Distribution. It will upload it to Firebase
App Distribution and make sure my release notes and testers are
also included. I also want to point out that it doesn’t have to be the debug
command. App Distribution is
variant-Specific. We want you to be able to upload
Firebase App Distribution for different build types. It
uploaded successfully, so let’s go to the console and check it
out. So, if we refresh the page, we
should see a new distribution for 1.2.
And we do. We verify that it has the
release notes and the right testers. And then, if I’m a tester and I refresh my inbox, I should get
an email. But in the meantime, let’s look
at a previous release. I would get an email like this and open
it on my mobile phone and start testing the app and here, the
email just came in. Can we go back to the slides?
Awesome. So, we successfully distributed
our Android app. We can distribute iOS apps, too. You can address feedback before
launch and ultimately be more confident that your app will
work in the wild. Also, as you may have seen earlier in the keynote today, App
Distribution is now in public beta, so go to the consoles and
get started. ROB DiMARCO: Now that we’ve
tested our app, let’s move on to validating
its security. Think back to that example at the beginning of
this talk. That’s terrifying, right? If your app goes live, it’s
growing, but that growth and that success also invites
additional scrutiny. We all want to get application security right but this task can
seem daunting. For the next few minutes, we’re
going to give a brief overview of the
application-Level overview and how to use Firebase tools to
validate the security of your app before going live.
For many of these, it might be a refresher. Let’s start with how to think
about security for apps built on
Firebase. Your mobile or web clients connect directly to
services that you control and then those services perform
authorization and authentication checks before they change or
mutate data. But when you build an app with Firebase, we
abstract much of that infrastructure away. So you don’t need it to think in
terms or keep up with OS-Level or
network security. We ask that you think in terms of
application level security. But we still need to ensure that
only authorized services, clients and users are able to
read or write the correct bits of data. So how do we secure
those requests from untrusted client devices? The answer is,
with security rules. Security rules are the tool used
to define whether or not authorization should be granted
for requests to your database. We’re going to walk through the
tools that Firebase offers to help you learn, write and test security rules.
REBECCA HE: First, let’s see an example of how security rules
can be helpful. Let’s say I’m working on my new
game called Gold Mine. Users collect gold as they
through each game play. They also have the ability to
compete against each other and place on a global scoreboard.
Each of these data types, the users, the game play, the
leaderboard, has a different security need. Let’s dig deeper
into the security need of users. So, we want user records to be
publicly readable, but user editable. Only the user, themself, should
be able to edit their profile. So, how can we enforce this
using security rules? Well, writing rules can be
complicated, especially if we’ve never done it before.
This is where the security rule simulator comes in. It is an in-Browser playground
that let’s you safely experiment with security rules. You can
simulate reads and writes without needing to modify your
database or having to set up a development environment. Let’s
go to the console and see a demo of how this works. So, here, we’ve started writing
security rules for our app. The first thing we need to do is
match a specific document. In this case, we’re matching the
user document. And then, inside this block, we
can write rules to match read and
write operations. Let’s think about reads first. We want user profiles to be
publicly-Readable. So, we’re going to write a rule
that’s allow read if true. Pretty straightforward. Now,
let’s move on to writes. So, for writes, remember, we
only want the user, themself, the user who is logged in, to be
able to edit that profile. So, let’s try taking a stab at
it. All right.
Given my limited security rules knowledge, I think this is
right. But how do I validate it? Let’s go do the simulator.
So, here in the simulator, I’m logged in as myself, Rebecca, and I’m
trying to update Rob’s profile. This shouldn’t be allowed, so
I’m going to click” run. ” And the
simulator tells me that the write is denied.
All right. That makes sense. Now, let’s try to edit my own
profile. If I hit” run” again, the write
is allowed. This looks good, so I’m going to publish my rules and save them. Let’s go back to the slides.
ROB DiMARCO: So now, the security rules simulator is useful for learning
and experimenting. But once you start building an app for
production, you want to start developing, testing and
deploying rules, following the same best practices you apply to
the rest of your codebase and for that, we turn to the
Firebase Emulator Suite. It lets you run our production services on your local machine,
include Firebase, Functions and Realtime Database. During the keynote, we saw how
the emulator suite can be used for local development, but even
more importantly, the emulator suite is essential
for thorough testing, running locally is super fast, it’s free
and it doesn’t introduce the risk that you’ll in any way harm a running production
application. Going back to my Gold Mine game,
let’s move on to security the global leaderboard. Using
rules, I’m trying to prevent fraud in this game by making
sure that users can only share scores for
games that they, themselves played,
and it needs to match the result. Let’s use the Firebase Emulator
Suite to validate this behabe ier.
Switch over to demo. Here, in my ID, I’ve started
writing some integration tests for rules to secure that
leaderboard. First, I’ll start the local
Emulator Suite with a single command. I have a local instance of Cloud
Functions, Firestore, the Realtime Database and Firebase
Hosting all running on my local machine. Each time I save my security
rules, the emulator suite is noticing the change, picking
them up, hot reloading those rules and applying them to
my databases. Now let’s take a look at my
tests. Compared to what the simulator’s capable of, this is much more
advanced. This will clear the Firebase
database and I’ll write a test that is going to check to see
whether or not a user can share that result with a
mismatched score. It passes. Great! But remember, when testing
security, always test both code paths. Both the access granted and the
access denied. Think of this just like code coverage. If we test the” if” branch, we
also need to test the” else” branch.
Adding the complimentary tests and re- running, we’ll see that we’ve
got a bug. It looks like I’ve got a typo in
my security rule. I’ll fix this typo. Save my
rules. The emulator suite will hot
reload the change and I’ll rerun my test.
All right. It passes.
That’s what the Firebase Emulator Suite is all about, rigorous,
comprehensive testing for your apps before launch.
Let’s go back to the slides. REBECCA HE: So, at this point,
we’ve corrected all the problems with the initial launch. We’re
feeling confident. But how do we make sure we launch with confidence, every single time?
The answer is, with automation. Automating let’s us maintain
stability and security without sacrificing
velocity. Building great apps is hard. We’ve all got things
to do. Speed matters. ROB DiMARCO: That is why all of
these tools were built from the ground-Up with continuous
integration in mind. We understand how important
automation is for you and how important speed is for you and
we want to help you succeed. Let’s see an example, now, of
how you can integrate Firebase Test Lab, Firebase App Dist rucontribution
and the Emulator Suite. REBECCA HE: We have continuous
integration. Download and install the command
tools for Firebase and Google Cloud.
ROB DiMARCO: We’ll invoke our tests. This lets our security tests run
locally, quickly and in a safe, isolated environment.
Running the tests in this way also ensures that the emulator
suite is spun-Up fully before tests are run and cleanly shut
down after running tests is complete.
REBECCA HE: Then, we can run our Test Lab robo test. In this example, we’re testing
it on two devices. ROB DiMARCO: If all of our
tests pass, we deploy our changes to
Firebase and distribute the latest version of our app to our
trusted testers. We could customize this further,
doing things like distributing
different apps to different channels.
REBECCA HE: So, let’s summarize. We’ve built our app, we’ve
tested it, we secured it, we’ve added automation and now we’re
ready for launch. Remember, these apps stability
and security problems are preventable. Firebase is here
to give you the tools you need so you can launch with
ease and confidence. The first time, and every time.
ROB DiMARCO: Go back to your teams. Try these tools out.
Let us know what feedback you have and how we can help you further.
Thank you. [Applause]. Up next: Roll Out Your New
Features Safely and Confidently By Mayank Jain and Steve Wilber. -Please welcome on to stage,
Mayank Jain and Steve Wilber.
[Applause]. -Hey, I’m Steve Wilber, I’m the
engineer. -And I’m Mayank.
-We’re so excited to be here in Madrid to speak with you today, to
learn how to use Firebase and get your feedback. So, thank
you for taking time out of your busy schedule to be here.
MAYANK JAIN: I would like to talk to you about something that is
important. We have some pics for you that we think may make
this experience of launching new features troublesome and worrisome and with that, let me
share a personal story with you all. So, once upon a time, we had a
small office in New Delhi and it took
45 minutes just to get to the office. We had an amazing team of six developers, marketing folks, and
a designer and working on a
ride-Sharing app and developing a rating and review feature
which had been heavily requested by our customers and we thought
this would be the needed feature. I clearly remember the two-Week
sprint in which we were building — in which we were building the feature to
allow rating the rides in the
ride-Sharing app. This new feature was heavily
requested. We worked hard and a lot of
internal testing. Eventually, we felt we had a
very good test coverage and we were ready
to go live. We crossed our fingers and
uploaded it to the app stores. That — that day, we felt really
confident. The initial metrics looked
really good and we could already see that customers had started
using the feature. We started giving each other
hi-Fives and the mood was jubilant and we thought this would be a dividing factor
in bringing trust in the
ride-Sharing app. That evening, we packed our bags
and went home in a celebratory mode. Well, when we all came back the
next morning, things looked very different. Our app rating was
plummeting with a ton of one-Star ratings and we
had customer complaints in our
support channel. It was down by 15% and it caught
our total team by surprise. I remember reading one of the app store reviews, thanks so much
for the discount, I can’t open any rides on that.
I wish I could give you zero stars. This is not something
you want to read first thing in the morning when you come to the
office, right? So, what happened? Our team quickly went into a
board room situation and realized
there was a fatal app crash happening
repeatedly for most of our customers. We had a fetch
failure condition. It was so bad that our users are
not able to open any rides. Looking at Crashlytics, we found
there were so many conditions for low bandwidth and these conditions
are causes all these fatal crashes. As more users got exposed to
these builds, the problem got even worse and we wouldn’t
control it from spreading. The situation was getting out of
control. We spent the next two days and
nights, trying to work on a possible
fix. It took us more than 48 hours to become fully-Confident
and the only available option was to actually send a hard-Fix upgrade, which took
another one to two days to reach fully to our customers. As a result of this delay, we
not only lost a ton of hard-Earned
customers, but it took a nose dive and we were forced to have some very uncomfortable
conversations. One of the investors said, can’t
you even handle these simple launches? Those couple of weeks were the
harshest experience our team had ever seen. I’m sure everyone here, today,
know that such a situation are death for
your product. And with that, I would like to bring in Steve,
who could show us some really cool ideas that would have
worked for us. STEVE WILBER: Thanks. That sounds like a really tough
launch. Wouldn’t it have been so much
nicer if they rolled out that new feature
in a way that let’s them stay in control of the experience
they’re delivering? What if they could have tested
that feature on broad devices and enabled it for a small portion of their
customers or rolled that feature back if anything went wrong?
What if they could have shipped with the confidence that they
weren’t going to end up with wall of bad
reviews? This is why developers started trying new app release
workflows to solve some of these problems. So, let’s take a step back and
look at some of the methods developers
have been trying. You do as much internal testing
as you could, but it wasn’t uncommon that you would ship a
major bug that impacted many of your customers. You would race
to prepare a fix and then just hope you could get an expedited
review. Like Mayank and his team
experienced. Then came Beta by Crashlytics
and Test Flight. You can deliver builds to your private
beta testers, which would help you get more test coverage
before you sent those builds out to the app stores. You were
still stuck hoping for the best. Next, the app stores introduced
phased releases, giving you the ability to slowly roll-Out a new
version of your binary to your customers and that helps a lot
when it comes to minimizing the risk of shipping a new build.
One challenge is that once a customer gets that app update,
there’s no way to downgrade them back to the previous experience
so you can minimize the number of customers that get
exposed to a bad release. But for those who get it, they’re
stuck with it. Another challenge is your team
is probably trying to develop
multiple features at the same time and it
can get difficult to coordinate those and working around this
can get really complicated and it can lead to
anti-Patterns like working in feature branches. Not only is
it complicated, but it can slow down feature development because
you’re not able to easily get feedback from customers on the
new feature that you’re building.
So, some of you may already be started to think about the
answer to these problems. It’s using a best practice called Feature Flags or Feature
Switches. You can keep all of your code on master, but turned off behind a
Feature Flag. You can remotely turn that feature on for any
customers you wish and you have the ability to turn it off if
customers aren’t getting the experience you want to deliver. There’s no need to wait for an
app to release. As soon as you flip that switch, the feature
goes out or if can roll back immediately.
Having your features behind a flag means that you’ve separated
exposes new features from shipping a particular build of your app and that gives
us some huge wins, both in terms of
developer produck duckativity. It greatly simplifies their
workflow. They can merge their code to master any time they
please, knowing it will be safely tucked away behind a
Feature Flag until the time’s right to expose it to customers
and the flexibility to choose when it’s exposed makes it easy
to get feedback from your customers and to build something
that they’re really going to love. So, you may be familiar with
Feature Flagging. The power we’ve been talking about could have saved Mayank’s team
from the wake of a bad launch that caused them so much
distress. We wanted to make it super
simple for anybody to launch features in their app with
confidence. So, let’s take a look, now, at
how you can use Remote Config to apply some of the concepts we’ve
been talking about. First, we’ll take a look at how
you can get Remote Config integrated into your app. You
can think of Remote Config as a key value store that lives in
the Cloud and dynamically configure how the app will
behave. Here’s how it will grab the configuration from Remote
Config. As you can see, there are just a few lines of code — a few lines of code to get
started. We’ll make a fetch call to pull down the
configuration and then once we’re ready to make use of those
values, we’ll call Activate so they’re ready and available to
the app. This is how we’ll use the flag,
once we’ve got it pulled down. We’ll grab the value for Remote
Config and make it like a standard
boolean value. So once we have our app coded
up, we can use Remote Config to enable that flag. As we
stabilize that feature, we’ll expand our group of testers and
then we’ll start a small percentage
roll-Out and use Firebase to monitor how the release is going and fix any
issues that come up and increase the
percentage until the feature’s completely
rolled out. Let’s check out a demo. We’re
going to walk through releasing a new feature that allows
reviewing a driver. As we walk through, we’ll see
the steps that Mayank, and his team, could have taken to have a relaxed and
confident release. The app lets you see the driver your about to
call, but there’s no way to know what other riders think about
that driver, so let’s add that now. The first thing we’ll want
to do is test the feature, internally, so
let’s set up a Feature Flag that will
allow us to do that. We’ll open up Remote Config and create a
parameter. We’ll call it” driver review
enabled. ” And we’re going to set the
default value to false, that way, we
won’t accidentally expose it before
we’re ready. Now, we’re ready to start making
our feature available to our internal testers. We’re going to use a user
property, from Google Analytics for Firebase. That’s a key
value pair that we can set in the client to give it a
particular state, which Remote Config can then use to target the
behavior to this particular app. We’re going to use it to tag the
username of the user in the app so we can serve up this new
feature to a specific user. In Remote Config, we’ll set up a
new condition to enable our feature. And the condition’s going to
make use of a user property called”
username. ” So let’s call that condition
Member of dev team. ” And we’ll say it applies if
that user property, called username,
contains [email protected] If that is true, we’ll enable
the feature. And once we publish that change,
it’s automatically live and we’ll be able to start doing internal testing of
our feature. It is visible in the app for
testing. Okay. So let’s fast forward in
time a little bit. And the dev team has stabilized.
A great next step is to open up the feature for dogfooding for
anybody at the company to take a look and test it. So, let’s
create a new condition and we’ll call this one” company
employee. ” And well RR have this one
apply if that username contains any
@Firebaseany @Google.com, email address.
We’re feeling pretty good about it. It’s time to release it out
to our customers. Thinking back to Mayank’s story,
this is where things went differently. We’re going to expose it to a
small portion of our customers. Since we’re using Remote Config,
we have the ability to turn it off. We can confidently ship
this build out to the app shores. With our build out,
let’s go back to Remote Config and create a new condition to
start the roll-Out. We’ll call it” driver review
roll-Out. ” And we’re going to say, this
one applies if the user’s in a
random percentile. We’ll start with 1%. That will
be a nice, slow start to rolling out our feature. If anything goes wrong at all,
it will be contained to 1% of userbase.
So, now that our feature’s out in the wild, we definitely want
to start monitoring it more closely. So let’s switch over to
Crashlytics to check on the stability of our new feature.
It looks like there’s a new bug that’s popped up here. So, let’s dig in by clicking on
this issue. If we look at the stack trace, I
think we can see that fetching new images is failing for some
customers and that’s causing the app to crash. So, now that I’ve
identified that this new problem is caused by my feature, I’m
going to roll it back so that I can limit the impact of this
big. I’ll switch back to Remote Config and go to My Feature Flag and set it
to default for all of my production user. I’ll hit”
publish. ” And I’ve gotten all of my users back into a new
state. Mayank, wouldn’t it have been amazing if you could have
done this during your launch? MAYANK JAIN: Absolutely. -Let’s imagine we’ve gotten that
ship fixed. Let’s go back to our Feature
Flag and we’ll, again, set it to true. And then we’ll hit”
publish. ” And with that, we’ve restarted
our 1% roll-Out. From here, we’ll slowly ramp-Up
the exposure of our feature. We’ll continue to monitor the
health of our launch in Firebase and eventually we’ll get to 100%
of our customer base. And with that, our feature will
be shipped and it’s time to
celebrate. Switch back to slides, please. We did a straightforward
percentage roll-Out. But I want to highlight a couple things
Remote Config can help you with. It can be helpful to do a
region-Based roll-Out. Maybe it’s only available in
Spain to start or you might want to target a Firebase audience,
all of the users who have made purchases. Remote Config can
allow you to target these groups and mix it with a
percentage. Okay. So, those were some tips
on how you can use Remote Config on a roll-Out. But we’ve been working on some
pretty exciting new stuff. Mayank, can you show us?
MAYANK JAIN: Absolutely. Wow, Steve, where were you when
we were building a ride-Sharing
app? Feature Flags and Remote Config
have received so much love for developers, that a couple of months ago, we
wanted to make this experience even simpler and even more
powerful. I would like to give you all,
today, a sneak peek on what we’ve been building. We call it Feature Roll-Outs,
it’s products you already use, Google
Analytics, Remote Config and Crashlytics. It makes it a whole lot easier
to roll-Out new features, while
constantly monitoring their stability metrics.
So, let’s go back in time and assume that my team was building
the ride-Sharing app with Feature Roll-Outs in Remote
Config and see how we could have benefited from the best
practices that Steve just described. We could have used
Remote Config and created a new feature with parameters for the
rating and review feature. And notice how cleanly all the parameters are now organized on
the Remote Config UI. And the Feature Roll-Outs, just
a few clicks to set it an internal
testing track and a production track. And since Feature Roll-Outs is
built on top of it, it manages all of
that complexity for you under the hood. The roll-Outs are extremely easy
to manage. Roll forward or roll back, in
just one click. This is probably the best feature I love about Feature Roll-Outs,
you can see your crash, how is it
trending as compared to your users who were just exposed to
this feature. This was very hard to get in Firebase. And is now a huge thing for you
to take the next action, which in this case, looks like a potential
roll-Back. And with the changes for all of
the roll-Out, your team can
collaboratively work together in launching,
anything you’re building. Remote Config is already serving
more than three billion apps and it’s
completely free for you to use. We are trying to remove the
guesswork needed at launching new
features, consistently, reliably and confidently all the time. You no longer need to build
Feature Flagging systems, rather focus
on developing apps. I’m happy to share that we’re
opening up our beta program today. Scan this QR code on your phones
right now and reserve your spot. We can’t wait to see what you’ll
build and launch with Remote Config and Feature Roll-Outs.
STEVE WILBER: We’d love to have you try out the beta of Feature
Roll-Outs, but there will only be limited
spots. Go to the URL. Feel free to reach out to either
of us on Twitter. And if you have any questions, after the session, Mayank and I will
be back in the #AskFirebase area. Thank you.
MAYANK JAIN: Thank you. Up next: How Fast Growing Apps
Move Quickly With Crashlytics. By Shobhit Chugh and Michael
Reed. -Please welcome, on to stage,
Michael Reed and Shobhit Chugh.
[Applause]. -Hi, folks, thanks for coming.
We’re here to talk about Crashlytics and how Crashlytics
can help you move quickly, even as your app is scaling. I’m Michael Reed, I’m a
developer on the Crashlytics product.
SHOBHIT CHUGH: I’m Shobhit Chugh. To compete, you must
move fast. You must release features as fast as your competitorcompetitors. The
stakes are high. If you’re a fast-Growing app, you might
remember the earlier day, you know, when you just started off
and you start with an idea, you ran some
experiment, you started to get some initial traction and then
the idea started to catch. You got more users. More funding.
More revenue. You had a bigger team. But with this growth comes
competition. And you no longer are the only
one in the market. So, to compete, you must keep
moving fast. But, as you grow, you often
become more risk-Averse and we found
four factors related to app stability
that cause things to slow down as they scale. Let’s look into
them. First of all, even smaller
issues can affect a lot of users. Crashes have a real downside.
We have found that when leaving one-Star reviews, Google Play
users often mention stability issues
or bugs. And so you might be tempted to
slow down. How do you make sure you keep an
eye on important issues and keep
moving fast? Second, you face more edge
cases. Once you have more
functionality, more complex codebase, so many users and so many variety of devices, a lot
of edge cases start to emerge. You might have never seen these
edge cases when you were building the app, when you were
testing it. So how do you make sure you
quickly triage, reproduce and fix these edge cases so that you can keep
moving fast? Third, your effort to release
and monitor goes up dramatically. You might spend a lot of time
keeping an eye on your releases, it
could become very onerous. How do you make sure you keep
moving fast? And last, but not least, the
number and variety of issues that you face, that impact your app stability,
increases. Your issue list could look like an endless to-Do
list, which is what my days look like, most of the days. But
let’s talk about Crashlytics instead. So, how do you make sure you
react to crashes one-By-One, but instead,
systematically, start addressing root causes so that you can keep
moving fast? So, here we are, you’ve grown,
you’re a successful app. But have started to move slowly.
Now, you might think of Crashlytics as a place where you come to see how
bad things really are. But, what if — what if you used it as a tool to
ship faster? Using examples from real
customers, we’re going to tell you how to
do just that. Let’s begin the first topic. So, the first problem, your
tolerance for shipping bugs to customers the instability has
decreased because even small issues can affect a lot of
users. But sometimes, in spite of all your code reviews, testing, you might
ship a version to production that might
start crashing. And you don’t want negative app
reviews or customer support tickets to be your first sign
that something’s really broken. Instead, you want to know
immediately if any issue has become a major concern so you
can do something about it. Fix the code. Turn off an
experiment. Roll-Back the release. Do something about it.
But also, since you have so many different issues to deal with,
so many different crashes, you want to be notified just at the
right time. So, for example, for low and medium priority issues, you might just
want to monitor passively, but for
high-Priority issues, you might want to get notified
immediately. Even get paged, if needed.
Crashlytics offers three kinds of filters that maps to this
priority order. There’s new issue alerts, which
occur when a new type of crash occurs
for the first time. This is low-Priority at this time.
We’re just seeing the crash for the first time. Then there’s
regression issues. You fixed a bug, marked it as
closed and then you ship a new release and again, the app starts crashing
in a new version. Low to medium priority. And then there’s velocity
alerts. Which are a true signal that
there’s something significant wrong in your app. Let’s see
how they work. So, what we’re doing is
Crashlytics is monitoring every single issue in your dashboard
to see what percentage of user sessions it is affecting. When a crash starts to affect
more than a certain percentage of
users, we raise up a velocity alert and by default, this
percentage is set to 1%. That’s a significant issue. Earlier
this year, we also launched the ability to fine-Tune this
threshold so that you can change it based on your app size, your workflow, your
particular needs. Now, let’s see how a customer
uses these alerts to keep moving fast. This is one of India’s largest
food delivery services and if the app crashes, the users cannot order
food and they lose money. Speaking of food, I’m starting
to get a little hungry. But the Swiggy team wants to
know about all issues, but they want to focus on the most impactful issues,
first. So in order to do that, they
connected velocity alerts to PagerDuty and
Jira. This way, if something is truly
wrong, the on-Call person will be
notified, will be woken up in the middle of the night, if
necessary, and they will have a Jira issue looking for them to
investigate. In addition, Swiggy also wanted
to make sure that their engineers were kept in the loop
for lower-Priority issues so that is why they connected new
issues, as well as regression alerts, to
rule rooms in Slack and they created separate rooms for the
iOS and Android teams so that they can passively monitor,
triage and pick up any crashes, especially if it’s related to
code they own and they might have changed recently. This allows Swiggy to keep
shipping fast with the confidence they’ll be notified,
in the right manner, for high-Priority crashes, as well
as low-Priority crashes. Now that was keeping an eye on
issues, even as you ship fast. To tell you about edge cases,
here’s my teammate, Mike Reed. MICHAEL REED: Thanks, Shobhit. The velocity alerts become pages
and in new issues go to the slack room?
SHOBHIT CHUGH: You catch on fast, Mike. MICHAEL REED: Handling edge cases. They will discover
bugs you did not discovering in development. Works fine on my machine, but
usually it’s not a joke, right? I bet we’ve all spent countless
hours trying to debug issues without
enough information. I know I found myself wishing I
could meet my end users. I’d ask them questions. What were you
doing? What steps had you taken prior
to the crash? Were there items in your
shopping cart? But I can’t meet every end user and I can’t ask them all of these
questions, so am I going to debug this issue? We want to know what caused the
crash? It shows us which line of code
caused the crash. What’s also important is the state of the
application and the steps taken, leading up to the crash. And Crashlytics can help gather
this data. So, we have three tools that
help developers capture state and sequence usage prior to a
crash. Let’s see how we can use this to find and fix edge cases
quickly. Back to our questions for the
end user. One of them was, did you have items in your shopping
cart? And wouldn’t it be nice if we
could capture this information and enhance our crash reports by adding it to
our crash reports and sending it to our server at crash time?
That’s a leading question, a trick question, because we can
do that. You can do that. It’s a feature Crashlytics
called Custom Keys. Here, we see how easy it is to do. It’s
a function — we call it a function. You name your key and you
programatically set it for that key and it will catch the key
value pairs and send them to our server with your next crash.
So, okay. Cool. We see it’s easy to instrument the code.
Where does the data go? Well, the key value pairs are
visible right next to your stack trace. So now our crash time, no more
regrets that you can’t meet all your end users because we’ve
captured application state of your choosing and it’s
available at crash time. But how about logs? Often, we do our best debugging
with logs. But they’re usually a luxury
available at development time, right at your development
machine. Now that’s not the case when you’re using
Crashlytics because since the beginning of the product, we’ve
supported custom logging. And here’s how it’s done. It’s
a one-Liner. You call a function and provide your log
string and that log is uploaded just like Custom Keys, with the next
crash, to our servers.
They’re next to your stack trace so now you can have your
application state, your custom logs and you get
your stack traces, too. So this is getting a little bit easier.
But suppose you’re experiencing crashes and you haven’t yet
instrumented your code with Custom Keys
orCustom Logs? If you integrate your Google
Analytics SDKs, we can capture pre-Defined Analytics events. We call them Breadcrumbs and
with no code modification, it’s captured. If you’re using
Google Analytics, you probably already defined Custom Events
with finer details. These are also captured and like Custom Keys and Customs Logs,
they’re shipped to our server. Next to your stack trace, you’ll
find your Google Analytics events and you can use these
Breadcrumbs to understand these events. For example, maybe you
have an event which shows the provisioning of a shopping cart
and maybe you have a Custom Key, so now rather than
imagining and reasoning what might have occurred prior to a crash, you can do what some
of our other users do, they go to the locker and grab a device and use the
logs and the Google Analytics Breadcrumbs
to repeat the steps the user took
before the crash. So, I hope you’ll give it a try. Instrument your code, custom
keys, add custom logs and we can help with
these debugging efforts. SHOBHIT CHUGH: So, Breadcrumbs,
I mentioned I was hungry, can you
get me some of those? MICHAEL REED: I’ll bake you a
bread. SHOBHIT CHUGH: You could
automate and we could try to tell you how to
automate it, but why? Why not bring on stage, a customer who
has automated their release processes? So, please join me in welcoming
Madus, Product Manager for the release
team at Spotify. [Applause]. -Hi. All right. Hi. My name’s Madus. I’m the
product owner of the Spotify release team. We release new
versions of the Spotify app for Android and iOS.
And I will share a little bit about how our journey has been and how we
use this. But, I wanted to start by
sharing some numbers. I think the first one may be a bit
surprising to some of you. There are more than 65 teams
that contribute to the main Spotify
app. The platform has more than one
million lines of code. We release knew mobile releases
every week, for both Android and iOS. And of course, when we do it,
that version is rolled out to more
than 200 million monthly active users. So, I would say, our
biggest challenge, in the release team, is to do all this in a way that isn’t
stressful, either for us, as a release
team, or for our developers. So, the release team started
three years ago. And one of the first things we did was we did an inventory of all the
manual steps required to release our app. This is a picture. We
filled an entire whiteboard with all the things we have to do
from signing and uploading nightly
builds, tests, pinging teams with open bugs, status emails,
all those things. And then over time, we started automating
these things, one-By-One. But, one of the really big
manual steps eluded us for a long time
and that was crash monitoring. So, we used Fabric for this and
whoever was the release manager had to log into Fabric, pretty
much every day, to look — see if there were any
new crashes on our alpha/beta builds. This was tedious, but
it was also stressful because this one of the few times where
you could kind of mess up, as the release manager. Maybe you
were fighting other fires, you forgot to look at Fabric for one
day, two days, well, maybe there was a big crash and maybe we
lost two days of debugging and had to cancel a release or
something? That was a big issue and that is
why we were excited when we could go over to Firebase
Crashlytics. It was exactly one feature I was
really, really eager to start using and
that was Crash Data in BigQuery. That had been my dream feature. A quick note here, in order to
protect the users, we disable data
sharing. But anyway, having direct access
to the crash data has been a game-Changegame-Changer for us. We let Crashlytics handle the
grouping. Our automatic tools does
everything. The release manager never has to
log into Firebase. It monitors alpha and beta
builds. We can use a stack trace to assign those tickets to
the right teams. And I want to end with a quick
screenshot of what we’re working on right now. And that is to take the crash
data from Crashlytics and actually integrate it into our
own tools. So, this is a screenshot of our
own tooling, where you can list the crashes for one specific
team and it is shown, in the same tool, where that team would look at back-end requests or
test results. And to me, that is the power of
Crashlytics in Firebase. You have a UI with a lot of really
powerful features, that works for most apps and most use
cases. But as you grow, you can start
writing your own tooling and take full
contoll of the automation. That is what I have. Thanks for
having me. I included my ancient Twitter
handle. I haven’t used it in years. Feel free to reach out if you
want to release a scale. Back to Mike.
[Applause]. MICHAEL REED: I love your app. In fact, I use it all day long.
Identifying broader trends. What do we mean when we talk
about broader trends in the context of
app stability and app quality? The landing page for Crashlytics
shows crashes sorted by impact,
highest to lowest. But is fixing crashes,
one-By-One, top-To-Bottom, necessarily the only way to
pursue your bugs? Maybe not. It’s a good start. But you might be missing signal.
So if not this ordered list, then what? You have all this
data. How can you best-Visualize it? We got pie charts and line
graphs. I’m no data scientist, but I
believe that’s a lamp shade. It’s a lamp shade, right? Okay. This is where BigQuery and Data
Studio can come in. Firebase products allow you to export
your data to BigQuery and BigQuery lets you run custom queries on that
data and it enables integrations into
workflows. Now Data Studio is a dashboard and reports builder,
which is backed by your BigQuery data. So you get a data warehouse and
a UI for you with just a few clicks. This is the BigQuery ID
and as developers are going to feel quite at home there, you write SQL
queries. Most importantly, you’ll have
the opportunity to run ad hoc queries on your data in a custom
manner. And so that’s great. You can write SQL queries, I can
write SQL queries, but how do we present our learnings to our
teammates? That’s where I would use Data Studio. With Data
Studio, you can build visualizations and you build
them graphically, using an IDE. And you’ll enjoy all the
features you’ve come to appreciate from Google
Docs. And Crashlytics has helped you
get started. So, we’ve created this template
and you can clone it and connect to your BigQuery data source.
And once you’ve cloned it, you’re dropped into this IDE.
And you start with a real dashboard, backed back your real
data, and in fact, it looks a lot like the Crashlytics user
interface. But, it’s easy to customize. You can add new
visualizations. You can choose charts from the
pull-Down. Once you’ve chosen your charts, you can populate
them with data by choosing dimensions and metrics,
graphically, from the user interface shown on the right and
there’s a style panel there, so you can round your corners and touch-Up your color schemes.
And, there we have it. So, we’ve added a pie chart and
it shows that, in this case, 21% of our crashes are caused by the
embarrassing null pointer exception.
So, we have some friends who develop an app. They have a nice, large userbase
and they use the default issue list, but they were also interested if
there were broader app quality issues span
is ing across their issues. They found it with Data Studio.
They added a pie chart and it showed their issues, grouped by
exception type. And there was a surprise waiting for them. More
than half of their issues were caused by out of memory
exceptions. Now they knew their app was using memory, of course, but they
didn’t know how much. It all adds up. By using BigQuery and
Data Studio, they could visualize the impact.
So what would you do if you learned that half your crashes were caused by
memory usage? Well, our friends, rather than
fixing issues, one-By-One,
top-To-Bottom, they switched focus and they targeted reducing memory usage and
reducing the memory footprint. With BigQuery and Data Studio,
you can perform custom queries and you
can visualize your data and perhaps
uncover problems that wouldn’t be
apparent. -Thank you, Mike. I really like
the lamp shade and the one in purple, it matches my
shirt perfectly. Can you get me one of those?
MICHAEL REED: I can get you one of those.
-We’re here to tell you there’s no need to sacrifice your
development velocity, how quickly you ship, even as
your app grows. With Crashlytics, you can keep an eye
on important issues so you can ship faster with confidence. You can reproduce and fix edge
cases faster. You can start to automate
release monitoring. And you can identify and act on
broader trends so you can go and fix
your crashes faster. I’m Shobhit. MICHAEL REED: And I’m Mike
Reed. SHOBHIT CHUGH: We will be in
the #AskFirebase area. I hope you enjoy the rest of the summit
and have a great day. Thank you.
MICHAEL REED: Thanks. [Applause]. Up next: Faster Web Apps With
Firebase By Christina Holland, Stella
Gaitani and Ali Kashefian. -Please welcome, on to stage,
Ali Kashefian, Christina Holland and
Stella Gaitani. [Applause].
-Hello, everyone. I want to start with a question:
How many of you have ever heard
complaints that your app is slow? All right.
[Laughter]. And, how many of you immediately
knew what to do about it? All right. So, this is exactly what
we’re here to talk about today. I’m Stella Gaitani. I’m the Product Manager for
Firebase Performance Monitoring. CHRISTINA HOLLAND: I’m
Christina Holland. I work on the Firebase JS Core
Team.>>And I’m Ali Kashefian.
-From our perspective, as web developers, when we think about
an app being slow, we think about many different things. We think about page load times, runtime slowness, however, from
our users’ perspective, this is all the same. The app is slow
and a slow app means that our users are sad because they’re having a frustrating experience
on our site. We start to think about
performance and the first thing that comes to mind is we’re
starting to look for things to cut. And this is a great place
to start, because more often than that, they are things that might not be serving
us or our users and are slowing our site down.
However, we get to having a feature that is helpful, adds value to our
users, but it is impacting our performance. We might, at that point, say it
is what it is. I have to take the performance hit. However, we think there is a
better way. What if, instead of thinking
about performance of a features we want to have and the speed, we think
about performance as a game of tetras where we think about how
to line up our features in the most optimal way to minimize their impact on our sites’
performance? So, how do we do that? The first step is to
understand what our users are experience. This is where
Firebase Performance Monitoring comes in. Firebase Performance
Monitoring will tell you what your users are
actually experiencing when they’re coming on your site. Then, we will think about how to
only download the bare-Minimum of
code and bring the rest later, as we need it. Finally, we will
close the loop and check how the changes we’re making are making
our site’s performance. Are things looking like they’re
getting better? Is it the same? Did we make anything worse? We want to show how to do all of
this in action. We have a demo to show you that. I’m going to turn it over to
Christina, who’s going to walk us through our demo app.
CHRISTINA HOLLAND: Thanks, Stella. Can we get the demo up? Here, we have a simple stock up,
that update every minute. For this demo, I just loaded a bunch
of all stock data into Firestore. So it’s just replaying August
28th over and over again, so don’t use this data to make any
stock-Trading decisions. So, we have a home page that
anyone can see, that has the most
popular stocks and maybe you add a feature where you let people
log in. This home page is open to the public.
We’ve got our app, we put it up and we get lots of hits, which
is great. And like a responsible
developer, we’re going to check in to our channels and ask our
users? STELLA GAITANI: I have to say,
the app feels slow. CHRISTINA HOLLAND: So the
developer’s going to want to ask, slow, how? Page loading and rendering, data
fetching? STELLA GAITANI: I don’t know. It just feels a bit slow, so can
you please fix it? CHRISTINA HOLLAND: So that’s
frustrating feedback because it runs fast enough on my machine
so how can I figure out what the users are seeing? This is where
Firebase Performance Monitoring comes in. Stella? STELLA GAITANI: So, let’s see
what Firebase Performance Monitoring can do for us and let’s go back to the
slides now. Excellent.
Soy, Firebase Performance Monitoring is a real user
monitoring tool. What this means is that it shows you how
your users are actually experiencing your app out in the wild. You
have users coming on your side from different devices, from
different countries, from different connection speed.
Their experience, on your side, might be very different based on those
conditions. So the way that Firebase helps you is by showing
you the full distribution. Instead of providing you with
one data point, let’s say the median or
the 95th percentile, which is really important because we want
to understand how our app is doing at its worst. It shows you the full
distributions of load times so you can see how many users are
on the happy side on the curve. That means they have fast load
times and how many of your users are on the other side. They’re on the long tail of
users who are experiencing long load
times, are frustrated and these are the users you really want to
be thinking about. So far, I talked about page load
time and this is a metric that is
very common. This gives you additional
user-Centered metrics. Page load time, by itself, can
be misleading. You can see how long it takes
for the full page to load. But if your users are seeing useful information in the meantime,
they might not be noticing any details. It gives you some metrics such
as the first contentful page and it shows you the first
input delay, which is the time that it takes for your site to
respond to the first action that your users take on your site. So, these metrics, in addition
to page load time, will give you a more complete picture about
what your users are actually experiencing.
So, now, I want to turn it over to Ali, who’s going to first tell us how
to integrate Firebase Performance Monitoring to our
app and then he will show us what the console can tell us
about the demo app. So, we can understand what is going on
there. ALI KASHEFIAN: Thank you,
Stella. Integrating this Firebase
Performance Monitoring can be easy as dropping a few lines of code in the HTML page
or download and install the MPM
package. Let’s see what the developer
sees. It captures metrics related to
the page load of our application. This is very
helpful to find out if any of the pages are actually running a
little bit slow. Also, as we will see later, we
capture all the network calls made from
the web app, which is helpful in finding out if any of those
calls are taking too long. So, let’s start by going to the
page load and check out the application. This is the URL, it means all
pages under this pattern, currently only at one page. So,
let’s go here. This is the full distribution of all the metrics associated with the
page load. First content pane, the median
is over three seconds and the 95th
percentile is a little bit shy of five. The time it takes the
page to load all the assets, it median is around
three seconds, but there’s a long tail of users who
experience load times, as high as 30-Seconds.
What we’re really interested in is to find out how long it takes
the users to start seeing this stock data and this is very
specific to this app. In other apps, it could be other custom
metrics. So, can we customize Perf to
customize? Yes. We can use custom traces and
custom metrics to capture whatever we’re interested in.
In this case, as I said, we are interested in the duration
between the navigation until we load the initial stock data.
Let’s call it initial data load time. Once the developer of the
stock app applies the necessary modifications, the initial data
load time will start showing up in the table. Let’s take a look.
This is the full view of the data. And, this is the
distribution. As you can see, the median is
around 4.5 seconds, but there is a lot of users who experience
much longer load times, up to 38 seconds, which is a
long time. How can we find more information about these users? One of the features of Firebase
Performance is it allows you to dissect the data such as browser,
country, so on and so forth. This is very helpful if you want
to found out if any segment of the users are experiencing the
app differently. For example, if my app does not render well on a certain browser or if
my page loads very — takes a long time
to load in a certain country or certain region.
Particularly interesting one is effective connection time, to
see if there is any difference with faster connections with the
lower ones. First of all, there are — the possible values are 4G, captures
all the users on faster networks and
they come directly from the navigator API of the browser.
It seems like around 60% of my users are on faster networks,
which basically means that 40% of them are not. And the users, on faster
networks, are only taking a few seconds to start seeing the
data. But, the users on a slower
network are taking much, much longer.
This must be painful. What could be the reason? Usually,
when there’s a significant difference between the
experience of users on faster or slower
networks, the culprit is a network call which is taking too
long. So, let’s see if this is the
case in here. We can do that by going to the
Network Tab and as you can see, we capture all the networks
captured. Let’s filter by the page we’re
interested in. We can change the duration. And I’m going to change the sort
to response time so the longest call appears on the top. The longest one happens to be
bundled with JS. Sounds familiar. It’s actually
the package which includes all the code from
Firebase JS SDK. So, here, the response time, the
median is 1. 75 seconds, but there is a long
tail of users who take up to 30 seconds to load this package. And this makes sense because the
page load size is 200 kilobytes. It must be painful this package
on a slower connection. Let’s confirm that by going to
the full data view of response time, see the breakdown by
effective connection type and, yes, users on slow
connections are taking a very long time to download this. So, we are downloading a large
package and this is effecting the
experience of our users on slower connections. With this
insight, let’s see how we can fix it.
CHRISTINA HOLLAND: So it looks like we need to cut some code. Cutting code doesn’t necessarily
mean sacrificing functionality. The first thing we should check
is if there is some code down to the user that don’t need to be.
How might that happen? If we open up the console, we
might see this warning message that says we should only be
importing the Firebase components we need.
So that’s a good place to start. If we take a look at the code,
the first thing is import Firebase from
Firebase. This is where the problem is. Let’s step through
the app and just see how it works. So, after we import Firebase,
import to Firestore and we’ll render it. What the code looks like is
after importing Firebase, we
initialize the app and this one line gets
performance started. Once the data comes back, we’ll render
the page with it. Just so you know, there’s
nothing magical inside, it’s a simple
subscription to a Firestore collection called Current. Every time a snapshot comes
back, we render it and format it. We will log this custom metric,
that’s how we got it into the dashboard.
So, the first line is the problem because we are importing
all of Firebase, including components
such as Auth and Storage, which we’re not even using in this
app. Let’s just import the components
we need. We’re going to import the
Firebase Core App, which is very small, and then Firestore, of course, and then
Performance. Having made just that one change
from importing Firebase to importing these components,
let’s see how it performs. I’m going to put up a demo of
the two apps, side-by-side. On the left is our original app. This is throttled to 3G. And it looks like we’ve got a
speed improvement, so that’s pretty encouraging. But again, works on my machine
is not good enough. We need to get this out to the users and we
need to check the dashboard again. ALI KASHEFIAN: Let’s take
another look at Firebase.bundle.JS. So, here it
is. Let’s take a closer look. The median is down to around one
second, which is good. But still, we have a long tail
of users KWHOO are experiencing
some delay and the 95th percentile is over
16 seconds. And, here is the page load size.
We have cut to less than half. Great. Let’s see how this is affecting
the initial data loads. We go back to the on-Device tab
and this is initial data load time. This is the time view of our
data. The bottom of the blue area is
the fifth percentile and the top is
the 95th percentile. The dark blue line is the median. Pay attention how we shaved off
the 95th percentile. This is when we made the change. So,
this is great. A lot of improvement.
Let’s focus on the latest version of the app. We can see
that the median is around three seconds, but the long tail
is still here and it’s taking some of our users more than 23
seconds to start seeing the data.
So, we made improvements, but some of our users are still
suffering, which begs the question: Can we do
even better? CHRISTINA HOLLAND: Yes, I think
we can do better for our users. If the first easy win is to cut
out chunks of code you’re not using, the second is to see if
there is code you can bring in later. We brought the bundle size down
by a half, which is great. What if we could cut it down to
zero and get them their whole page before we have downloaded any of the
Firebase libraries. You might be thinking about Lazy
Loading. We’ll render as much of the page
we can and we’ll put placeholders and spinners. But,
no. Because — from the user’s point
of view, a page that has spinners on it is a page that is
not done. Let’s do better for them. Let’s get them a complete
page, with all the stock data, before we have downloaded any of the Firebase
libraries. Is that even possible?
Firestore has a restAPI. We can hit a rest end point with
http Git, so what’s that look like? Here’s a typical URL that will
hit the Firestore restAPI end point. If I was to curl, I get the JSON
data for all our stocks. So, I can use that and render the
page. But, this is a stock app, so
users are going to want their realtime
updates. The Firestore library makes that
a lot more convenient. Is there some way we can get the
best of both worlds? Yeah. So, we’re going to look at our
game plan. We’re going to first fetch the
REST data very fast, render the data immediately so the user has
a complete page and they’re happily looking at their stocks and only then will
we dynamically add it and subscribe to Firestore and they’ll have the
realtime updates before the first-Minute refresh is up.
So what that looks like is — let’s review — we imported all
of Firebase and just the components we need and now we’re
importing nothing from the Firebase library initially. Instead, we’re going to put that
URL in a variable and our very first
step will be to use the Native Browser
Fetch and get JSON data, format it and we’ve got the data, so we can log the
initial log time metric, render the page, so when we have a
happy user, looking at a complete page and only now will we
dynamically import Firebase. Once that’s downloaded, we’ll
initial the app, subscribe to Firebase
and swap in that live data without the
user even knowing. So, there’s nothing magical
about this dynamic Firebase import. It is just three import
statements to import those three libraries, we imported earlier, and then
returns a promise. Imports not supported in older
browsers so if you’re supporting older browsers, know you will need to use a
polyfill. So, we’ve got that plan going.
Let’s see how it plays out. I’m going to demo three apps, now,
on the left is going to be our original. The middle is just
the components we need and on the right is our
REST and dynamic import, which finished loading, before I even
explained what it was. So, that’s pretty fast. So, that’s a pretty good
progression. You can be pretty excited about
that. [Applause].
But again, I just checked this on my local machine, so that’s
not good enough. Right? We got to get it out to the users and we’re going to check the
Firebase Performance Monitoring dashboard to see if they’re seeing this
improvement. ALI KASHEFIAN: Thank you,
Christina. Let’s check out the initial load time again. In the first set of
modifications, we shaved off the 95th percentile
from 30-Something seconds. It is around a few seconds only. Let’s focus on the latest
version. All right. So, the distribution shows us
that the median is around 1. 5 seconds and the 95th
percentile is less than five seconds. Which means that for
the vast majority of our users, the app and the
data loads in a few seconds, which means that the vast majority of our users are
happy ones. CHRISTINA HOLLAND: That’s a
pretty great outcome. Can we have the slides? So, tips to make your web app a
little faster. Can we do even better?
Like, for example, we provide you with the ability to import just the components you need, such as
Auth and Firestore and database and storage. What if we could
provide you with just the methods you need? On a lot of
home pages, you want to know if a user’s logged in or
not so you need get-current-User. Is that
something we can do? That is a great suggestion. We are
definitely looking into how we can get something like that to
you, so keep an eye out.
[Applause]. STELLA GAITANI: Thank you so
much, Ali and Christina, for making our demo of users very
happy. So, our key takeaway is how you
can use Firebase Performance Monitoring to understand what
your user’s experience is like and then start thinking about how you can only download the
bare-Minimum and bring in the rest later, as you need it.
Our mission, here, at Firebase is to help all of you succeed by
providing you with the best tools to help you build amazing
user experiences. We hope today you get some helpful tips on how to speed up your
apps, using Firebase. This is our GitHub repo, if you
want to check out the code we used for this demo. And we will all be hanging out
at the #AskFirebase if you have
questions. -Please welcome on to stage,
Peter Friese. PETER FRIESE: Hello, everyone.
So, congratulations for making it this far. It has been a very
long day and this has been a very long session and we’re not
done yet. So, after the break, there’s
going to be more content and make sure to
be back here at 4:30. I would encourage
you to stay hydrated and also stay energized. There’s more
great food outside. There’s more drink outside. So, enjoy some of the food.
Make sure you’re hydrated. Some also, catch some of the
nice sunlight and don’t forget to be back at 4:30 for more content. Thanks. Video: -The first time I came to get my
first round of chemo. -Being able to not take it away. -Health has been our greatest greatest wealth. I work in developing virtual
reality tools to reduce pain and anxiety.
-It keeps the child engaged. They are focused on what’s going
on, in the virtual world, and that
allows them to really be removed from what’s
going on, in some cases, around them, which can be stressful.
-I feel like it really helps, all around, because when you’re
watching yourself get a needle put in
your pore, it can be hard to watch. -The second we started seeing
success, we realized that we needed to distribute this at a
larger scale. We had to grow the headset to
base in certain hospitals. That’s when we needed Firebase
in order to manage all these devices through a simple web portal
online. Using Firebase made developing
and management system extremely fast. We were able to have this
idea and put it into practice, immediately. We didn’t have to
focus on any of the back-end development. We could rely on
Firebase and really focus on the core of what we
were building. So much is taken away from you
when you’re a patient in the hospital and to be able to smile and enjoy your
life a little bit is actually extremely powerful and brings us a lot of
joy, as well [End of video] -Please welcome on to stage,
Patrick Martin. [Applause].
PATRICK MARTIN: Hi, everybody. How are you enjoying Firebase
Summit so far? Pretty good? All right. All you all awake
for the final stretch? All right. So, I’m a games developer, I
focus on games development, so I think the best way to keep everybody’s mind
engaged is to play the most engaged game of
all, Rock, Paper, Scissors. Rock, paper, scissors, shoot! You paper people, you’re kind of
jerks. Looks like I tied with one-Third
of you. Coming up next is Firebase
Extensions. This is a really cool way you can — as app
developers — reuse existing content without following all
these dedicated steps. It ties a lot of the back-end
stuff together. Then we’re going to go into
offline support. Not everyone may realize that
Firebase still works great without an
internet connection and we’ll just talk about that and see how you can service
your players’ wherever they are. Finally, if you already have an
existing application, we’re going to go into how your might
integrate Firebase without having to tear everything up and
build it all from scratch. So, with all of that said, I
would like to welcome Michael Reed and
Annie to stage to talk about Firebase
Extensions. MICHAEL BLEIGH: All right.
Welcome from the break. It’s exhilaraing to see so many
Firebase developers in a room. This might be the most I’ve seen
in one place, ever. You know, I know it sounds
cheesy, but it’s also true. Firebase is driven by the
developers who use our products every day. In fact, that’s
actually how Firebase came to exist in the first place.
Firebase started with the Realtime Database and you may not know
this, but the Realtime Database started as a hosted service to
allow websites to let their users chat with one another. And the users of this service,
it turned out that they wanted to do more, so they were using
this service, but they weren’t sending texts, they
were sending JSON payloads. Talking to these developers, we
realized that realtime was powerful and difficult to
implement. A new product was born, a
database that lets you store any kind of
data and sync in realtime. In other words, Firebase.
But, we weren’t done listening to developers because once you
can synchronize data in realtime, how can you let users write to it while
still keeping it secure? We built FirebaseAAuthentication
to manage users. But we still weren’t done
listening because once you can build an
entire application using HTML,
JavaScript and CSS, where are you going to put
it? We built Firebase Hosting.
And we kept on listening and we kept on building. We joined forces, first, with
Google, then with Fabric. Today, I can show you how to
build any type of application on almost any platform using nothing but the
suite of tools that Firebase gives you. But we’re still not done
listening to you. We’ve heard you just don’t want
new pieces to fit into the puzzle.
You want help fitting them together in a larger picture. One way to do that is with Cloud
Functions for Firebase. Functions are deeply integrated
into Firebase and give you a trusted,
serverless environment to run your code. Believe me, we’ve seen some
pretty creative use cases. When we talk to you, we hear many of
the same things come up, time and time again.
Now, we can — and kind of do — spend a lot of time answering
questions on Stack Overflow or our mailing
list. At the end of the day, what we really want to do is
solve these common problems for you so you can go back to
working on the things that make your app unique and awesome. So, we’re here, today, to
introduce Firebase Extensions. Extensions are open source, pre-Packaged solutions for
common things. They can tie together existing
products from Firebase and Google Cloud Platform, integrate
with third-Party services or implement patterns we’ve seen
out in the wild. We built Extensions as a platform to
bring new capabilities to Firebase faster than ever
before. They leverage the powerful infrastructure already available
in Firebase, without the need to write a single line of code. You provide a few simple
configuration parameters and we do the rest. We create Cloud Functions and
connect them to Cloud Firebase Database and perform actions, like sending
email or whatever problem you might need to solve in your
application. My name is Michael Bleigh and
I’m an engineering lead on the Firebase products. Rather than
tell you how easy Extensions are to use, what I really want to do is show you what
Extensions to do. I’m going to turn it over to my colleague, Annie. ANNIE RYAN: Michael show you a
bit of the” what” behind Extensions. Now, here’s our app, Friendly
Eats. Now, there’s an extension that can help us with that. So, I’m going to get right to
demoing how just that one extension can get that feature up and running. Hey, Michael, I think I need
your help over here. [Laughter]. MICHAEL BLEIGH: Password s. Typing is hard. [Laughter].
There we go. ANNIE RYAN: Awesome. So, here
we are in the Firebase website and the Firebase Extensions
page. MICHAEL BLEIGH: Can we get that
up on the screen? ANNIE RYAN: So, we’re not there
yet, but we’re almost there. Oh. Oh, we’re switching to the demo
now? There we go.
MICHAEL BLEIGH: Ta-da! [Applause and cheers].
ANNIE RYAN: Ta-da! So, here we are in the Firebase
website, in the Firebase Extensions page.
As I scroll down, you’ll see a list of all the extensions you
can install today. These are solving common
developer problems, such as resizing
images to various thumbnails to deleting
user data from such services, like Cloud Storage and Realtime
Database. But I just spoke about adding a
Share feature to Friendly Eats. I’m going to click and see more
details. Each extension has a robust detail page, such as
this, which tells you a bit more about how this extension will
work in your project. It also provides links to the
Firebase documentation on Extensions and also, a link to
the source code. There’s details on billing and
what billable services this extension is going to use.
You can see more details on exactly what you can configure and also, the
resources it’s going to generate. Now, I’m going to install this
extension through the Firebase console. You can also install
it through the Firebase CLI. I’m going to get right to
installing it. Which this is going to bring me right to the Firebase console and I’m
going to select a project to select the
extension within. Since we’re talking about
Friendly Eats, I’m going to select it and it brings me to the guided step step-By-Step flow. And then I previously talked
about billable services. I’m only going to be charged for
the usage that exceeds three tier. I can read more about that, as
well. I need to give this extension
permission to do things in my project and it’s going to
generate just a service account that has the Cloud Data Store
User role. That’s going to allow this
extension to allow my database instance. But now we’re getting
to the fun part, which is modify this extension
to meet Friendly Eats needs. I’m going to leave the
deployment location as U.S. Central. But here, I need to provide my
SMTP credentials. I also need to specify a collection for the email documents. I think” mail” sounds good, so
I’m going to leave that as the
default. I’m going to use a” no reply. ”
Oops. For my default” from” address.
That looks good. I’m also going to use that as my
default reply” to” address. And users collection, I’m going to
leave that blank for now. I can go back and edit that later. And then I’m going to use the
templates feature, which allows me to use
reusable handle bar templates and I’m going to call that”
templates. ” And that’s it, after a few steps and a few fields, I’m ready to
install this. And so, as this extension is
installing, I’m landing in the Extensions Details page in the
Firebase console, where I can see a list of all my installed
extensions. And that’s it. It’ll be fully-Deployed in just
a few minutes. So now you’ve seen the process
of installing an extension and you may notice this is
different. User research played a huge part
in making this a full end-To-End
platform. Quite simply, we listen to
developers like you. In fact, 700 of them.
And this encompassed 10 different research methodologies
over the course of 10 months.
We listened for hours, literally. We tested three
iterations of the experience along the way. And continually
re-evaluated the array of extensions that you can
install. They have been put through the
test to make sure you’re getting through the compen app
development problems. So, that’s all good to now, right?
But how did this research help? Well, it gave us some guiding
principles keep us on-Track. One principle being
transparency. Simply put: We strive to be respectful to our users and one
way to do that is to provide you a
transparent experience that is mindful of your needs and
expectations. We heard directly through
developers about the way they wanted extensions to be a more
transparent experience. And one of those ways, being the
source code. One developer called out that even just seeing
a link to the source code, one link, upped their trust
10-Fold in the product. They wanted to be able to access
that, more frequently, in the process.
I’m going to take a closer look. Immediately, as you’re browser
through the Details page, you’re
provided with the source code. As Michael has said, all
Firebase Extensions are open source. This is something we
know developers are really keen on because it’s a direct view
into the glue that holds this functionality together and
allows you to trust that it’s going to do what it says it’s
going to do. Also, as you’re going through
that guided installation flow, you can view the source code at any time.
As the extension is deploying, you are still providing with
more opportunities to view the source code.
Another developer, early on in our process, specifically called
out that the permissions needed to be more descriptive. We weren’t displaying enough
information. So, right as you get to step one of that install flow, you know the
exact Cloud function, along with an explanation as to why it’s
even being used at all. We also made sure to provide you
with a complete list of roles so you know the exact access this
will have. You’re provided with a description and a rationale as to why it’s being
used, so there’s really no surprises
here. Top-Of-Mind was understanding
how usage relates to cost. So we really took this into
consideration in later iterations.
So, right within the details page of the extension on the
Firebase website is a section on billing. We know this is really
important when you’re choosing a service to use. So these
details provide you with information on how this
extension will consume usage for those specific services within
your project. Now, our second principle is
control. And that’s about flexibility. So you can get up
and running quickly, no matter what your expertise
level is or what workflows you have established. We kept
hearing about customization during this research.
Developers wanted to know how much flexibility they would have
before they even installed. Like, how well is this going to
work for them and their needs? So, how did we take action on
this? Well, the Extensions details are
super explicit and open to what this
extension will do. For example, with trigger email, you know exactly, nearly
step-by-step, how Firebase is going to render and send those
emails from Cloud Firestore. And again, to let you know if
this extension will work for you, you can view every way in
which the extension can be modified and exactly what it’s
going to generate in your project.
And we first started testing, we were testing CLI only. But many participants said, you
know, I’m not super familiar with the Firebase CLI. And we know not everyone works
in the same way. All you need to do is to choose
the path that you are most comfortable
with. So, we could have thrown all of
these solutions up in a GitHub repo and told you to have at it.
But we wanted to make sure this was an excellent developer
experience and something you could trust to work seamlessly
for you. Now Michael’s going to show you
how trigger email will work within
Friendly Eats. MICHAEL REED: We’re already in
the demo this time. Here I am, in my Friendly Eats app. This is running on a local
Firebase instance. If I click through to my prime
spot restaurant here, I’ve done a bit of the UI work I need to
implement this new email-Sharing feature. So I have this” add a
review button. ” And next to it, I have a”
share” button. It brings up this prompt. [email protected] — there we go. And check out this restaurant,
live on stage. And, I’ll click the” share” button.
Oh, wait. I got an alert. I have to
actually implement the feature. So, let us jump into our editor
and here we have the function that just got envoked so you can see, here’s
my alert that has to-Do and Annie’s told
me about this cool extension, so let’s figure out how we can use
that to send this restaurant recommendation.
So, if I jump over to the console, I can see, in the Extensions
Dashboard, that I have a trigger email extension
and I can see how this extension works. Annie chose sensible names, it
is populated with the values you provide. If she had called the collection
Churros, it would come up like that.
And, we were talking about using the template feature because
we’re going to be sending a lot of these emails so we want to be
able to reuse the same thing without having to paste in an
entire email body from the client every time.
So, let’s see. I’m reading the documentation but I’m just going
to copy from the docs. So, let’s just go back over here.
Paste that in. And okay, we’re not quite done yet. So, we’re
sending to — this is sending to a user, but I want to send to an email address, instead, so
I’ll just send that to the email that’s
passed into this function. We’re going to call the email
Share. We’ll have the note and restaurant information for the
recommendation. All right. So, I’m going to save that. Hit”
refresh. ” And we’ll try sharing this
again. Check out prime spot, it’s live.
So, this time, I hit” share” and there’s no alert, which means my
code has changed, at least. If I pop over to the Firebase
console and go to mail, I can see this document here, where
not only does it have the data that I added, but it also has
this delivery data. And, oh, the state looks like error and if I see error tried to
render non-Existent template share. I asked it to use a
template, but I didn’t actually create a
template. This is called” templates. ” This is called”
share. ” We need a subject line, so
Friendly Eats restaurant recommendation. So, these are just handlebars
templates so I can use the data that I sent along in the message and
then HTML, you know what, I’m not going to
sit here and make you watch my write HTML
live on stage. I’m going to copy this template I’ve written.
It has my note and information about the restaurants. It’s
really straightforward HTML. So, I’ve created my template and
that’s stored in Firestore. Whenever these templates are
updated, any future mail using the
trigger email, will get the latest version of the template.
Going back to my mail collection, I can use another feature, which
allows me to retry mail that failed to deliver for some
reason, if I think it’s going to succeed. So I’m going to change
this error to retry. Save it. You can see, it processes and
this time, great. We have a success. We have the attempt number went
up and hopefully — all right. I’ve got mail! So, I’ve just received this
email — [Applause and cheers].
If I click through, there’s the message that I typed and
information about the rest rant and I’ve implemented my sharing
feature. Can we go back to the slides?
So, I just walked you through how I was able to implement a
social sharing feature much faster than I could have otherwise, by using Firebase
Extensions. Sending email is one of the
extensions we’re introduing today. There are nine of them and we’ve
tailored each one to be used quickly. Of course, this is
really just the starting line, as we said, we’ve been listening
to you. We’re going to keep listening to you.
So, we’re excited for you to try this out and excited to hear
what other extensions you want to see in the future.
Now, if you want to dive in and get started with Extensions, you
can find all of these on Firebase.Google. com, just look for Extensions
and we’re opening up the Extensions
repository today. You can find the source code,
both that we’ve released today and
will over the couple months. I, for one, can’t wait to see
what all of you build with Extensions. If you have any questions, Annie
and I will be heading over to the
#AskFirebase area right now. Thanks, and enjoy the rest of
the summit. [Applause]. Up next: Firebase Offline:
What Works, What Doesn’t, and What You Need to Know By Susan Goldblatt
and Todd Kerpelman -Please welcome on to stage,
Todd Kerpelman and Susan Goldblatt.
[Applause]. TODD KERPELMAN: Hello. Hi,
everybody. Thank you so much for being here. So we have,
like, a boatload of knowledge we’re about to drop on you
today. So I hope you had your coffee
and or siesta because we are going to
talk fast. This is Susan. SUSAN GOLDBLATT: Hi.
TODD KERPELMAN: We’re here to talk to you about Firebase
Offline: What Works, What Doesn’t, and What You Need to
Know. You know, Susan, my phone has,
like, three bars on it right now.
Should I even care about offline?
SUSAN GOLDBLATT: Of course you should care. We’re often on a
good WiFi system but we want our apps to handle situations where
our users go offline, maybe a crowded place or underground so
we want to build out our applications.
TODD KERPELMAN: I guess I will care, thank you.
So, the general philosophy when it comes to offline support is
that Firebase is not an offline-First platform,
but we are offline tolerant. So, what does that mean? You can take an app that is
powered by Firebase and go on a long
flight, like from San Francisco to Madrid or take it on an
elevator and your app will generally continue to work. Yes, there might be a few
degraded experiences, here and there, but it will still
generally be functional. But it not an app where you
could expect to provide an offline-First experience or an experience where your user
stays offline for weeks or months at a time. You will generally see that
philosophy in most of our products. Most of this offline support
works without you having to do a whole lot. Most of our products use caching things and Gmail says
I’m going to connect in two seconds. We’re able to provide you with a fair amount of offline support
without you having to do a lot. There are ways you can effect
these offline behavior in both positive and negative ways. As always, I find the best way
to do the right thing, in the right
circumstances, is understanding how it works behind the scene.
So, let’s create an app with the power of our imagination because
we didn’t have time to actually make one.
SUSAN GOLDBLATT: We love olives. I’ve been eating olives here in
Spain. We thought we would make an app
for those olive farmers so they can
take photos and upload them to
compare different things with. TODD KERPELMAN: That sounds
like it might be useful, if you’re a
olive farmer. Olive Journal was built, using
Firebase. There are a number of Firebase products that are powering our
products behind the scenes. We have Cloud Firebase that stores
a lot of our farmers’ readings,
images, large binary objects are stored and we are a combination of Analytics
and Performance Monitoring and Crashlytics to find out how our users are
interacting with their apps. But this app is primarily used
by growers that are touring on the
countryside. They are not always known for their strong
and robust cell phone coverage. What happens when one of our
farmers attempts to use Olive Journal
and they’re connected to the
internet? Let’s look at the products and
let’s start with Firebase Auth. SUSAN GOLDBLATT: So, Firebase
Auth is Firebase’s identify as a service product. It allows user to log-In to
their application. So, let’s talk a little bit
about how this works. So, you have an app, your user
logs in, it talks to the Firebase Auth server and gives
you a token. You then use that token to talk
to services like Cloud Firebase. You also have access to the user
object, like the email. That token expires after an hour, but we refresh it
underneath the surface. So, let’s talk about what happen s
when you go offline. You only have access to the user object.
So, the email, the user ID and the photo URL. And let’s talk
about what doesn’t work. You can’t log in because you
can’t talk to the server. You have to be able to talk to the server to log in and you can’t
talk to the Firestore or Storage because you’re offline and you
can’t talk to the server. So, let’s talk about the gotchas
here. The main one is not being able to logged in. You won’t be
able to log in. The second kind of related one
is off persistence. You can configure and it tells
you how long you stay logged in. If you have a banking app and
when you close your tab, you want the user to be logged out,
if you’re offline, you won’t be able to log them back in
because you set you off persistence to be
off. TODD KERPELMAN: Let’s move on
to Cloud Firestore because this is the
primary driver of functionality in our
app and one of the best for a smooth
offline experience. We’ll talk about reading data
and using realtime listeners. Why don’t you talk about some
reads. SUSAN GOLDBLATT: When you read
data from Cloud Firestore, two things happen. The first thing
is we get a call-Back from the cache. It comes from the cache
if you have data there. The second thing that happens is
we go to Cloud Firestore to get the data there, to see if there’s any
data there. If the SDK is smart enough, you
only get that first firing.
However, if the data is different, the server sends you
back the new data and you get a second listener that fires and
your cache updates. To the user, it might look like there’s
two reads coming in. But it — to the user, it won’t look like
there’s two reads coming in. So, what happens when we go
offline, we still get that first read from the cache. And so,
that information comes in. But we don’t get the server read. If you’re intermittently off
line, maybe you’re in a spotty area, you’ll get that second
read a little bit later. If will have the slow fill-In
process. But, the thing to notice, here, is you can also
query your cache differently than what you had initially
queried it and also, since you can do that, your cache data
might not be exactly the same as your server data. So, your results may look
different. I think this could be clear in an example. So, let’s say I’ve decided to
look at all of my olive trees in Spain
and I have those in my cache and I ask my app to tell me the
tallest olive trees. If I’m offline, I’ll only get
the tallest olive trees in Spain. I have it in Greece and Italy. So, just beaware that the data
on your server might be a little bit different. TODD KERPELMAN: Let’s talk
about writes. When you write data, a couple of things happen.
Your data is written to the cache right away. Sort of like
with realtime reads, when you write data to the cache,
that will fire off your realtime listener. But now in the background, it is
being sent over to the Cloud Firestore. It will get updated and Cloud
Firestore will send that document back to the client. If these are exactly the same,
by default, cloud Firestore will quietly ignore that second
call-Back. You can change that behavior if
you want. Now the benefit of all this is
that you get some really nice, latency
compensation. From your user’s perspective, it
looks like all the rights happened right away because
you’re not waiting for the round trip to come back from your
server. Oh, yes. So, what happens when you go
offline? Just the first part of that process works. So, for writes, that local write
will trigger your call-Back, your
realtime listener will fire back. In the case of document
modifications, not just new documents, we play back local
writes. That original data doesn’t get confirmed until we hear from the
server. Those writes will be sent down
to Cloud Firestore in the Cloud in the order they were written within
your app. Cloud Firestore will verify it and send back to your
new documents. If this is what we have cached
locally, by default, the local SDK won’t tell you about it, but it will go ahead
and confirm those pending rights. Of course, in some cases, it
might include new data. And that’s fine, too. If this data looks different, it
will, once again, update our cache. So, speaking of cache, I bet you people are wondering how large
it is? SUSAN GOLDBLATT: It’s 100
megabytes and on the web, it’s 40. That’s actually configurable in
your settings. You could set the cache size to
be unlimited, which would remove all the clean-Up and bloat your
app out. It is a setting you can configure.
The other cool thing about the cache is if you have an app and
you’re frustrated, you swipe out of it, your cache stays in
Firestore. You can go back into that app
and access that information. TODD KERPELMAN: Let’s talk
about a couple of gotchas here. The one I’ve seen the most in the real world is
that write completion handlers until your write has been
confirmed by the server. So, right in here, you can see an
example of a write where we’re adding a new journal entry to Cloud
Firestore. We’re saying, okay, dismiss that
new journal entry. If we were running this app
while offline, that call-Back would never fire and it would look like our app
is frozen because we’re waiting to get that response from the
server and it’s bad. You don’t want your app to look like it’s
frozen. That’s something I learned. It’s an antipattern.
Don’t have your app frozen. The right thing to do is dismiss
that dialogue box essentially right away. You don’t have to dismiss it in
your call-Back. Those writes have happened
immediately. They’ve been added to the cache and you are allowed
to work with those right away. So save the call-Back for maybe
changing the appearance of a journal entry to say, yes, this has been
confirmed or written to the Cloud. The second gotcha is that
currently, this on-Device cache is not indexed. We like to say
that Cloud Firestore queries are very fast because we index every
field in every document and every collection. That is true
on the Cloud. On your local device, there is no indexing
right now. When you do a search, we have to unpack and scan every
document in the collection you are searching through. Remember
how we replay all those pending writes, we have do that. If
your local cache is too big, this can run quite slowly.
Now you can fix this by not pre-Loading your cache with too
much data, even if you think your user will be offline.
Like, I know some developers are like, I’m going to download the
entire database and get millions of documents. You know, in anticipation of
maybe having a better experience, but this will not
work. Trust that your user will be
making queries similar to ones they’ve made and let your cache
develop naturally, based on your user’s natural use
pattern. You can also, by the way, adjust
your cache. Go ahead and keep your cache size reasonable if
your notice your user is running on a slower device. If the
detect is old or slow and maybe you think the cache is going to
take awhile to run, make it smaller.
Let’s talk about Cloud Storage the Firebase. This doesn’t have quite a robust
thing. It can do generally the right thing and not break your
app. If you’re not familiar I Cloud
Storage, you can save large, binary objects to the cloud like
images, movies, PDFs and you specify a
reference, which looks like a path. And then asking cloud
Storage to go ahead and upload an object to that path.
Downloading is similar, start with a reference, which once again
looks like a path and say, hey, go ahead and convert that data stream into an image.
If you have an app where you have a pending upload, Cloud Firestore
will retry this until it finally does upload. And this does
generally continue working even if you were to switch to another
app and then come back, when you come back and this app is once
again in the foreground, it will try to redo any pending uploads
it has. However, if your app is killed
or suspended and then starts up again, this behavior’s also
killed. Your app doesn’t remember about these pending
uploads, right? If these image files are
something you’ve only saved as local variables, that data is
also lost. If we assume that keeping these
photos are important to the users of
Olive Journal, what would we do? When our user takes a photo, go
ahead and save that photo to local
file storage and keep a list of files that we want to upload to Cloud Storage. Then, once a photo is
successfully uploaded, the SDK has a message that says, upload
from local file, which makes this pattern easy. Delete the
local version and remove it from our list. So the nice thing
here is when your app is killed and restarts, we
have local files and I have pending uploads and it can try
uploading them again. Let’s talk about downloads.
SUSAN GOLDBLATT: Downloads work exponentially the same. The
thing to note here is that storage doesn’t have a cache,
like Firestore does. So if you want that functionality, you’re
going to have to build your own. It’s fairly easy to do. We have
some simple open source solutions that do this for you. In Android, there’s the Firebase
UI and Glide. Which allows Glide to understand
Firebase Storage references. On iOS, there’s a cache, which
creates an MS CACHE. The other thing is get a
publicly-Accessible URL and use it to use an existing library that
cache images loaded through URLs. It might be Glide or Pin Remote
Image. You have to be online to get them.
So, let’s talk about the gotchas. The first storage gotcha is
about this completion handler. If you’re waiting to close a
dialogue for confirmation that you uploaded your data to Cloud Storage, if you
put it in that completion handler, it’ll
never close the dialogue. Maybe you say, hey, image
uploaded. You won’t get to that point if you’re off line so the solution is just
to take the Firestore write or whatever
you have outside of your completion handler and assume that the data was
correct. In that completion handler, you
can be like,” upload true,” so you have
reference. TODD KERPELMAN: Now, let’s talk
about all the measurement libraries. All of them, or at least three,
Analytics, Performance Monitoring and Crashlytics. They generally follow similar
strategies. In general, it is stored locally
in a cache. For Analytics and Performance Monitoring, we’re
recording this stuff constantly and we wouldn’t want to send
this to Firebase servers. So, instead, we already store
batches of this data locally, and upload
them during intervals or certain moments in your lifecycle. It depends on your device and
your library. On Android, all of this is done
by Google Play Services. That’s why if your app were to crash on
Android, you get that crash data right away because Google Play
Services is able to upload it. On iOS, we have to wait for the
user to start up your app again before
your app can upload that crash data to
our servers. They all follow the same
strategy, which is exponential back-Off or
retry. And in the meantime, we keep
accumulating data from these libraries up to a limit and what
is that limit, you might be wondering? Good question,
because it’s on the next slide. It’s about 10 megabytes and
100,000 Analytics events and nine
crashes, all these subject to change. Don’t get angry when
this changes. One interesting note is on
Android, if we hit this event of 100,000, we
will stop collecting the more recent events and keep the older
events because for a lot of developers, the one thing they
really care about the most is that first open event and the
attribution data that’s associated with it and maybe
some of those initial going through your app’s lifecycle
events like signing in or creating an account or
completing the tutorial and that sort of stuff. If we have to
make a choice, we will keep that data and drop the more
recent events. As for gotchas, most of these
libraries — this is a technical term —
they freak out when they encounter data that’s too old.
Is this data actually old because the user’s been offline for a week
or a month, or do they not trust your system clock? A lot of these libraries do some clever work behind the scenes to
adjust for clocks that might seem off. At some point, they’re not sure
what to do with a date that seems
old. Crashlytics will address this to
change the timestamp. They’re like, it’s fine. You probably
want to see this crash data. Performance Monitoring and
Analytics, they’ll discard data that looks like it’s more than
72 hours old. If you are expecting your users
to be offline for weeks at a time, some of your Analytics
data is going do get lost and your app’s usage might seem
lower because some of that old data
will get discarded. All right. Let’s see if we can
sum up everything we have learned in the last 25 minutes.
SUSAN GOLDBLATT: Cool. So, when you’re offline, things
mostly just work. We have two strategies, caching
things locally or back off and retry. Firebase is designed for occasionally moments, it’s not
offline-First. So, for Auth, can’t log in.
You’re offline. TODD KERPELMAN: Watch out for
the Cloud Firestore, if they will fire if they are offline.
SUSAN GOLDBLATT: Cloud Storage doesn’t have a cache so you’ll
need to write your own or use a third-Party.
TODD KERPELMAN: Our measurement tools, they’re suspicious of
data that seems too old. So, with that, we are out of
time. SUSAN GOLDBLATT: Thank you so
much. We know it’s a lot of information. If you want to
take anything out of this talk, I hope you learned how offline
works and you feel empowered to build with offline in mine and
see how your app works and see if you can close dialogues when
you’re offline. TODD KERPELMAN: The answer
might surprise you. If you have questions, watch
this on YouTube at .5 speed. I know we spoke kind of fast.
Meet us at the #AskFirebase where we can take this
conversation offline. [Laughter].
[Applause]. Up next: How to Integrate
Firebase Into an Existing App By Rafi Khan and
Megha Bangalore. -Please welcome on to stage,
Rafi Khan and Megha Bangalore.
[Applause]. RAFI KHAN: Hey, everybody.
How’s it going? Good? Yeah? [Laughter].
MEGHA BANGALORE: I know it’s late in the day, you guys have
done a really good job. Powered through.
RAFI KHAN: Don’t worry, we have a really good presentation for
you. Worked really hard on it. Really excited to share with you
guys. All right. Let’s get to it. Okay. All right. So,
developers are drawn to Firebase because it lets you create rich
app experiences, gain deep customer insights and grow their
business. However, they think that that
they need to start from scratch. MEGHA BANGALORE: Let’s say you
have a mature enough app to focus on
increasing your user engagement with
in-app. Just by adding the SDKs to an existing app, you can
start iterating your user app experience to improve any of
your key metrics in a thoughtful and
really measured way. RAFI KHAN: At Firebase, we
design our products to be standalone. Today, we’re going to show you
common problems customers. Hi, everyone. I’m Rafi. This
is Megha. We’re engineering managers here at Firebase and
we’re here to talk to you about how to add Firebase to existing
apps. For this talk, we assume that you have a high-Level
understanding of a lot of the different Firebase products and
we’re going to focus on specific architectures and integration
strategies when working with them.
Let’s dig in. Okay. In recent years, more and more apps are popping up with rich,
realtime, collaborative experiences and
they work offline. This is a common problem for
logistic companies or media companies
that have engaging live content and want their customers to be
able to use it in public transit when they’re going in and out of
service. When developers look for ways to
do this, they find Firebase. Often, they’re using other
databases, like SQL or come other database
technology and when they look at Firestore or the Realtime
Database, they think they have to switch. We, at Firebase,
build products knowing you work with other services and we’ve built ours to meet you
where you are. So guess what? You don’t need to abandoned what
you have. You can keep your existing
systems and get all the great features of
realtime synchronization and offline
support that Firestore has. To pull this off, we need to
start with a little bit of planning. And, we start by asking
ourselves for whatever our scenario is, what is the data
that needs to be live? For developer apps, this could be
something like the order, its status or the location of a
driver. For media companies, you could be tracking the
election and you want to show a live vote count. Usually, this data has a
lifecycle to it and you want to know where changes happen from creation to updates
to completion. Next, we think about security.
Now, security is super important. We all know that and
we want to be sure that only the people that should see our data, can see our data
and nobody else. So, we’re fundamentally asking
the question: Who should have access to our data? Now,
there’s lots of ways to do this. But for the examples that I’ve
given, we have two models. In one case, specific users need
access. So, it’s like the customers, in
rusterant, maybe the driver or nobody needs access because the
data’s public, like with election data.
Once you know this, you can answer two really important questions: Do
I need to use Firebase off and what are the security rules that
I need to write? So you now know what your live
data is and you know your security model. Let’s map out
the integration. Okay. So, to talk about integration,
it helps to start from a reference architecture. Now, I
know everybody’s architecture is different, but in most of the
products we work with, there’s a couple of common — there are a
couple of common patterns, okay. Often, a customer has a website
or a mobile app, often both, and users can log into both at the same time
and have multiple sessions that are active. You know, a customer will also
have an Auth service to manage their session tokens and an API
server that can write to their database.
Okay. So, at a high-Level, when you think about the integration,
what you’re doing is using Firestore as a caching layer
that’s directly accessed by your client. Okay. Also, you’re using Firebase Auth
and security rules, alongside your existing architecture in
order to secure it. So now we know where Firestore
plugs in and we know how security will be approached. Let’s talk about code. So, first, we’re going to go to
all of our clients and at log-In or start-Up or really, whenever your app
establishes a service with your Auth service, what you want to
do is go to your Auth service, then you want to talk to
Firebase Auth and get your hands on a custom
token that has the user ID and any custom claims that would be
useful for your rules. Once you have that, you’re going to give
that back to your client and have it hold on to it.
Once the client has it, then it’s going to use that token to connect to
Firestore, with offline support turned on. Now, Todd and Susan just gave an
amazing talk about offline support. This is the gist of where it
comes into play here. All right. So your app is
warmed up. Let’s pipe some realtime data
into it. So, what we’re going to do,
next, is we’re going to go to the
back-end and find where our live data gets
created. For a delivery company, it could be when an
order gets created. For an election, when a
candidate is registered. Wherever it is, you want to go
there and once you’re there, you want to create a document with a
little bit of starter data, just the bits that
need to be live, and you want to put it into Firestore. Once
Firestore has it, it’s going to pass that along to the client. Now, also, as part of this, you
want to tell your client where this live data’s going to be so it can listen for
live updates on it. Now, make sure that your client is also remembering where to listen
because if your app restarts or the
browser gets refreshed, it needs to know
where to rehydrate the connection and start listening
for updates again. Your back-end could be written
in Node, Python, even Java. We meet you
are you are so you can talk to Firestore and put these objects
in. So once that data is written, the client will
automatically start to receive and it’ll start to render it.
And that’s to get it started. Okay. So, the client is
connected. It’s listening for updates, it’s
got its first bit of live data. What’s next? Well, we go back to our server
and ask, what is the lifecycle of the data? For
delivery, when the order is prepared. For election data, it
could be when the polls open or when votes start coming in. Whatever it is, you want to find
all those places in your back-end and you want to update
the same document that you created earlier, with whatever
the new data is. And the moment that that document gets updated,
it’s going to get propagated to all the clients across all their
sessions, across all their devices that are listening for
it. And just like before, you’ll use
whatever admin SDKs match your text stack. If you’re using more than one
text stack, you’ll use more than one
SDK. Okay. All right. So, the data is
live. The client’s getting updated. What else is there to
do? Everybody’s favorite part:
Clean-Up. Here, we’re going to do the
exact same thing, we need to find where our
live data isn’t needed anymore. For delivery, when the order
completes. For the election, it could be when the polls close.
You want to go there just like before, and use the admin SDKs to delete
the data from Firestore, tell the client to stop listening for it and have
it forget about that path because now that the data’s
dead, if the app restarts or the browser refreshes, you don’t
care about it anymore. So this more or less covers the
integration. Now with this setup, what do we
have here? Well, at the highest level,
we’ve tapped into the lifecycle of the data and any time something happens to it,
from creation to update to deletion, we’re just updating
Firestore. Okay. You see, the beauty of this
approach is that your back-end doesn’t need to care about the
client at all. It just keeps sending the data
that needs to get updated, straight to Firestore. All of
your clients, across all of your sessions, across all of
your devices, are always going to get the late S view. If
connectivity is lost with any of them, you don’t need to worry
about it because Firestore’s going to hold that state and
when the app comes back online, it’s going to pull the latest
view and render it. It is covered with Firebase Auth
and security rules, ensuring your data is safe and the wrong
people don’t see it. Now, let’s pull back to our
architecture. See, you didn’t have to leave your existing
database. See how it harmineizes together?
And there you go. How to use Firestore as your
caching layer with offline support.
All right. So, now we’ve got our app. So how do we get users to come
in and stay? This is a really hard part of any app and we all
stumble here. It’s a really tough problem. Forfinately, I have a resident
expert. MEGHA BANGALORE: It’s exciting
how Firebase can meet developers wherever they are. We all know that running a live
app is more than just that. We want to keep users engaged
with content. Sometimes we think of building
an app and growing your app as two
completely different workflows, but with your engineering team
very focused on building and maintaining the app and your
product app focused on growing your business. But, aren’t
things better together? This is my favorite phrase
because it’s really true: Things are better together when
you have a bunch of different teams working together and not
having those barriers. Firebase has the tools to make this is a really collaborative process. We help app developers, PMs and
the whole team work together. Firebase has the tools to help
you bridge that gap between build and grow and you can start
benefiting from them regardless of how mature your product is
and how much has already been built.
So, a lot of people, when they think about growth, they tend to focus
on acquisition, don’t get me wrong, it’s super important. As a side note, if you haven’t
looked into Admob publishing, that would be helpful there. In order to best-Leverage those
newly-Acquired user, you have to ensure they stick. How do you ensure they are
spending time? Let’s take a very specific
focus, increasng using engagement in an
app that is new to Firebase, but is live and doing great. It can
be more important to have 50 super dedicated users than 1,000
casual users. It can turn more of the casual users into super
users. We provide you the tools to
create a truly tailored and personalized experience.
That’s really cool and all, what can Firebase actually add here?
Let’s take a look, with the help of some case studies. The first
one. Cleveni is focused on utilities
and has a global audience and tons
of users. Users were missing out on a lot
of really amazing secondary
functionality and they weren’t hitting the pages. They had tons and tons of
eyeballs, but were missing the extra link to monetize them. So
they wanted to make some changes to their app and they turned to
Firebase for help. So, there were two really big
challenges that they had. First, they had to be able to
change the app’s behavior, dynamically,
without having an app update to be able to play around with
different options. Then, second, they had to split
the app traffic to compare the performance. With Remote
Config, you can do both of these without any difficulties. I’m
going to show a code snippet to allow you to dynamically change
the app. It supports iOS and as you all
heard in the keynote, Web, as well. So, first what you have to do is
go to Remote Config, programatically and get the
parameter you care about. In this case, Native Ad Design.
You’ll actually start getting your logic in your app based on the value
in this parameter. If it equals big size, we want to display a
native Ads where the size and the call to action are bigger
than the normal one. And, in the other case, we want
to display the normal native app. We could have chosen to use a b
oolean. So after releasing the update
and ensuring that enough folks have updated, we can move on to the Firebase
console. Be creating a condition, here,
in Remote Config, we can split the traffic by 50% using a random
percentile. When you do this creation, you
can apply several different
criteria, such as filtering based on language or country.
So here is an example of the design before and after. The
difference is significant. Maybe not on the screen, here.
But especially if you’re on a tiny phone. By testing to
improve this native ad design, we’re ready to go on to
the next step, feature discoverbility. You want users to notice them,
learn how to use them and stay longer in
the app, generating more revenue for you.
To help with the smoother adoption process, they decided to
leverage push notifications and launch The Tip of the Day.
It was designed to be a more subtle form of offering assistance that
could display information available, but not necessarily
hammering or bombarding the user. So, first what they did is they
figured out how were they able to track
users visiting the Help Center? They decided to log a custom
event and this was done programatically in their app.
That’s all they had to do programatically. In the
Firebase console, they were able to create a new audience that
was based on whether this custom
event had been fired. If you have at least one triggering of that event, you’ve been to the
Help Page once. They moved on to the Firebase
Cloud Messaging console, and they
configured the messaging. This shows the composed UI. You can
set the message content, schedule when it’s going to be
delivered and then go into the targeting. One thing to note,
you can provide images here, if you want to show
an image notification. So, going into the targeting
part, which is one of the most powerful
features because you’re able to target users defined in
Analytics. They used three different audiences. I’ll go
over what they are, first, and explain why they’re important. So, in specific, they excluded
members of these audiences, active
users, premium. They think are very important and don’t
necessarily want to interfere with them. Or people who have gone to the
Help Center once. If they’ve gone to the Help
Center, they know where it is. And purchasers. The reason they
want to exclude these people is they are doing the high-Value
actions. They didn’t want to distract the
users doing all the right things with all this extra information. All of this, as you saw, can be
done super easily using the Firebase console. So, if their users weren’t a
purchaser, they would get this push notification. If they click on it, they can
navigate via a Firebase dynamic link and
get to the Help Screen page to learn
about the advantaged features. This is very cool.
It was very easy to do, but what was the actual result? So, it was actually spectacular
and a great success and I’m not eganerating that. They saw no change in in-app
installs. They were able to be really targeted and focus on the
users who could actually benefit from this information. So, this is really cool and all,
but what other types of apps can Firebase help? Games are a
place where Firebase can fit really well into existing apps.
So, let’s talk about a few of them. First, Dan the Man. They were
able to use Firebase to increase revenue, not just increase user
engagement. They constructed a Firebase A/B
test were users were gifted credits.
The control group received no credits. One group received
credits at level three and the third group only received credits if they were in the”
will churn” segments. The user in the” will churn”
test group had a 20% increase. As another example, they were
able to use predictions in a slightly different way, based on the prediction of
spending or not spending. They dynamically changed their
in-Store game for these two groups. They discovered that
players were more likely to make in-app purchases if these cute,
little animated chests were featured at the top of the
store. They gave users who were
unlikely to spend the option of viewing ad
to gain in-Game currency. So, Firebase was able to help
them boost revenue by 25%.
So, we’ve seen that you can use a bunch of different Firebase tools,
kind of combined, like Cloud Messenger,
Remote Config and A/B Testing. We have other tools to help you
re-engage, increase engagement or modify your user’s experience, ensuring
more of your users are able to get a
personalized experience. Improving and iterating based on
the feedback we’re getting from you. -You can add Firestore or
Database. We have services like machine
learning, serverless offerings and other products to help you build
scalable, robust infrastructure that grows with you.
MEGHA BANGALORE: Though we didn’t mention it, there are
also great stability and performance tools that you can
get just by adding the SDK. -We, at Firebase, know you work
with other systems and will meet you
where you are. MEGHA BANGALORE: Firebase can
be uses foundationally when you’re just starting to build
your app or additively as you start exploring new features you
think you need. -Products are stand-Alone and
work getter together. MEGHA BANGALORE: The Analytics
works well with engagement tools, like
in-app messaging or push notifications. The important key
takeaway here is Firebase is there for you at-Scale, whether
you’re starting from zero users or two, just the development
team, to millions of users, we’re able to handle that and
grow with you and continue to support you going forward. So, I want to spend a quick
second — I know everyone wants to get up,
but we have a bunch of cool closing remarks to do. I want to send it back to Puf
and Jessica. -Give yourself a round of
applause. [Applause]. PUF: Thank you.
JESSICA DIROCCO: Thank you, Rafi, thank you, Megha. Thank
you for being here at the Firebase Summit in Madrid.
Round of applause! [Applause].
FRANK VAN PUFFELEN: I need to be careful with Amy. I’m so
happy you’re all still here because it’s been a long, long
day. We have so much content. Can you imagine that we started
only eight hours ago? Quick question, I always love
knowing what happens and most efficient ways to do it with a
show of hands. Raise your hand if you’ve been to every session
in this room? Oh, wow. JESSICA DIROCCO: That is great. For those of you who wereants
able to make it to sessions, they are posted in YouTube in just the next couple
of hours. Who, here, made a new friend
today? Okay, good. [Laughter].
FRANK VAN PUFFELEN: It was one of the highlights for me, of
course, meeting so many of you, including some of
the kids here. I met Chloe, an adorable
2-year-old. Amy joined me here today. She’s
been showing her face. What other questions do we have?
Who took a code lab? Nice. JESSICA DIROCCO: This is great.
And again, for those that couldn’t make the Code Labs, they’re all
available on Google.dev. Hopefully you signed up and
registered for that today. If not, there’s still time left. We had App Ship.
FRANK VAN PUFFELEN: How are be going to solve that? JESSICA DIROCCO: We have a
video for you. FRANK VAN PUFFELEN: Oh, let’s
play the highlight reel. [Playing highlight video] . -Welcome, everyone, to the
Firebase summit. -If Firebase were a restaurant, extensions would be tapas. -This is my second time here.
-Eager to learn. -I want to see what’s new and
ask the devs, first-Hand. [Applause]. [End of video] -Would you be quiet! I’m working on a video for
YouTube. Everyone has read and write
access to videos. Public is dissed.
-In my regular life, I’m pretty certain I get through three sentences in
a row but then as soon as I’m on
camera, I’m like… -Suddenly you hear the new
feature is causes crashing -It doesn’t
really involve pizza this time -I don’t know why kids get all the fun. -Zombie has followers and what
is the life? -This is something people want
to know, Michael. Tell me when the release is.
-I don’t know. [Laughter]. -Let’s our pod file and add. -I’m not a robot, I promise. -My Furby’s dead, I can do what
I want. -Can we do that one again? -Do you have a copy of War and
Peace? -I live-Code it here. -Sharing photos can be hard. So, we built shared albums,
which makes it easy to share photos to
anyone using a link. FRANK VAN PUFFELEN: Welcome to
the Firebase dev summit. -Our mission is to help
developers building better apps by
providing tools that help you across the
lifecycle of your app. -How did you get into the
studio? -I got to go.
-Cheese! Oh, you blinked! [End of video]

3 Comments

Leave a Reply

Your email address will not be published. Required fields are marked *