Engage and Keep Your Users in Your App with Firebase (Google I/O’19)
Articles Blog

Engage and Keep Your Users in Your App with Firebase (Google I/O’19)


[MUSIC PLAYING] MEGHA BANGALORE: Something
that a lot of app developers are continuously focused on is
how their users are actually engaging with their app. Are they delighted by it? Are they enjoying it? What are they disliking
about the app? SUMIT CHANDEL: Are there users
sticking around in their app or are there users even
coming into their app? MEGHA BANGALORE: So we’re going
to share the story of our two good friends, Jesse and Quinn. SUMIT CHANDEL: Who may or
may not be real people. MEGHA BANGALORE: May
or may not be real, but who are two app developers
who sought to build and launch their own app and how
they address these issues. SUMIT CHANDEL: So
this is their story. All right. Jesse and Quinn work
out a payment startup and they had an idea of making
a really useful app for a user to user payments that make it
easy to pay back your friends and also maybe do
in-store payments. And they’re both
pretty good engineers. And they care a lot
about the user experience like I’m sure many of you do. And so they felt quite
confident that they could build this app
out, follow all the best principles and design
principles along the way, release it, launch. And then get a good user
engagement experience out of that. And that’s exactly
what they did. They built the app, they
launched, and they released. MEGHA BANGALORE: Great success. There was lots of
celebration and much revelry. Everyone was super excited
that the app was live. And you know what? The app was out for many
days and there wasn’t a single negative review. SUMIT CHANDEL: So
as a matter of fact, there are actually
no reviews at all. So despite all their best
efforts in building this app and releasing it out,
users weren’t engaging it in any kind of meaningful way. But why? They followed all the
great design principles and all the best practices. They got buy-in from their
executive team with a prototype before they built it, they
went through design mocks with their designers and
built some really good flows throughout. They worked with
their testing team and got a lot of great
internal feedback within their own team
and the extended company. And they got really
excited about the feedback that they saw. MEGHA BANGALORE: They also
worked with their release team. They managed to figure
out how to get their app live into production. They managed to work with
marketing and branding and got a marketing
budget and they launched. SUMIT CHANDEL: So why weren’t
they getting the engagement that they thought they would
receive once they released this out into the wild? Well, let’s take
a look at the week by week breakdown of what they
went through to understand this and uncover it. So let’s enter week
number one, which is understanding your
user experience with data and improving on it. Now, when it comes to
understanding your user journeys in your app,
metrics are everything. And like all good engineers will
do, good developers will do, Jesse and Quinn added a lot of
event logging into their app so that they can
dig into the metrics later to figure out what
it was that was going on. And that they can uncover these
core issues of what’s going on with their user experience. So they logged a lot
of custom events. Some of these are more
important than others. Those more important events
are called conversion events. Those are things that
are more important than just for example,
the user opened up the app or they looked at
a summary page. It’d be more things like,
did they create an account? Did they send or receive
a payment to a friend? Did they invite a
friend to the app? That kind of thing. MEGHA BANGALORE:
So like your KPIs, your key business metrics,
not necessarily something that’s for operational
use or tracking workflows but something that’s really
important for your business. SUMIT CHANDEL: And
to log those events and to mark those
conversions they used Google Analytics
for Firebase. If you haven’t used
this before, pretty much just by adding the Firebase
Analytics SDK to your project, you get a lot of really
useful out of the box reports and graphs
for standard things like in app purchase revenue,
user retention, daily user engagement and so forth. But you can also do a
lot of custom events that you can create. And conversion events
that you can also mark. And that’s exactly what Jesse
and Quinn did for their app. So the most important, the
mega important conversion in their case was
creating an account. Because it’s from that
point that everything else in their app was possible. So they mark that
as a conversion by toggling that switch right
down there that you can see. So OK, this is now
their conversion event. Now, it’s really
useful to get numbers behind these custom events
and these conversion events that you can look at here. But I think what’s
more important than that is visualizations
around the data that can give you a better idea of
what’s going on with your user journey. Which is what they
needed to figure out here for their create
account use case for users coming into their app. MEGHA BANGALORE: I mean,
these visualizations are useful for getting an at
a glance look at something. Especially when you’re
logging this much data it can be a bit
overwhelming and we’re not machines we’re not good at
processing that in real time. SUMIT CHANDEL: And one really
good visualization tool for that data is
something called a funnel. Now, some of you may be
familiar with this already and if you are what you’re
probably thinking about is a closed funnel,
which is let’s say funnel A represents users
who took action or triggered event A representative
that funnel. Those users then go on to
complete action B in funnel B, and so forth. And that’s the closed
funnel that you kind of see on the right hand side. MEGHA BANGALORE: So kind of
like an actual physical funnel, right? You can’t lead from the bottom. It all just came
in from the top. SUMIT CHANDEL: Right. So that’s why what most
folks are familiar with. Now, there’s also the
concept of open funnels and open funnels are a
little bit different. They still represent
the actions that a user took in a given funnel. So funnel A for action A.
But the difference there is that the other funnels
next to that, the users who took that action might
not have previously taken any of these other actions
and the other funnels. So the user took
action B in funnel B might not have done
action A in funnel A. And why am I bothering
to mention all of that? The reason is because
when you first go to the Google
Analytics console and look at funnels that’s
what you’re going to see, open funnels. And if you don’t know that’s
what you’re looking at you might be super
confused because you’ll see that users who
committed action A had a 300% conversion rate to
getting into action B. Which wouldn’t make sense unless
you knew that, oh, I’m looking at open funnels. These events might not
be connected together. But you can actually look at
the funnel data in that way, if you’d like just by
applying some filters. And we’ll show how to do that. So what you’re looking at does
represent closed funnel data. MEGHA BANGALORE: So
funnels are really useful. But what did Spot
Your Friend use? So they decided
that the conversion event that they really cared
about was Create Account. So they checked
the workflow that led into creating that account. There were two. The first is when the
users went directly to the app or Play Store and
downloaded and saw the app. And the second
was when they were coming in via an invite
link from their friends and going through
a similar workflow. SUMIT CHANDEL: All right. So we’ll look at the first case. So this is users who
directly what does the app and downloaded it. And this is the
funnel visualization you’ll see in the Google
Analytics console. Now, this is also
counting the users who might have been
invited to the app. But this is just to give
a general idea for Jesse and Quinn as they’re digging
into the issue for what might be going on. So looking at the
data here we see that there’s about 1.4
million first open events. That’s pretty good. MEGHA BANGALORE: Which
actually seems pretty good. Right? This is a new app,
first fresh launch. 1.4 million actually
installing it is not bad. SUMIT CHANDEL: So yeah,
it’s a really great number. And that means that
their marketing team and the marketing
efforts there are working because they’re getting
a lot of initial users coming to the app. Their conversion rate, however,
into the Create Account event is not so great. It’s 329,000 about and that’s
a 23.2% conversion rate, which isn’t that great If you
consider the fact that these are users who downloaded
and installed the app. And if they went
through all that trouble they’re pretty
intent on using it. So if they’re not converting
there must be something wrong. So let’s look at the second
flow of the invite flow for users coming into the app. And this is what the
funnel looks like here. MEGHA BANGALORE:
Oh, it’s even worse. SUMIT CHANDEL: So here it’s
a really bad conversion rate. And there’s a few
additional insights that you can glean actually
by looking at this graph. So the first thing
is that we see the invite link clicked events
has about 1.1 million users who took that action. That means that the
majority of their users are actually coming in from
this invite flow, which is important to know
because that means they have to make sure they get
that thing like really right. The next thing is
their conversion rates. So 26,000 and 2.3%,
which is terrible again considering all
the trouble people went through to get to
this point of the app. And so there’s
something wrong here, something fishy they need to
identify with what’s going on with their onboarding flow. And one last note before we go
on to what they did with this is the filter that
we’re applying up top. So remember that note I
mentioned about open filters? In the first graphs
that we looked at we didn’t have that
applied but that was fine because there is an
implicit connection between those events. Here there might not be. So we need to apply a filter to
make sure that we’re not just counting anyone who created
an account, but really those users who are invited to
the app and took both actions. And so that’s why
applying that filter can give you the insight
you’re looking to glean. And so they did that. And they said, OK. Something wrong with
our invite flow. Let’s take a look at
what that looks like. MEGHA BANGALORE:
So actually let’s take a look at what that
flow looks like in person. SUMIT CHANDEL: And heads up
it’s going to be pretty bad. MEGHA BANGALORE: So
first what happens when you’re sharing
it with a friend, you create this invite
link which you can then send via SMS or email. That seems pretty
straightforward, pretty normal. But when you click
that invite link what users are dropped into
is this mobile web page which has links for the
Play Store or App Store. The user then has to actually
go to and pick and download the right version of the
app for their phone, which is not ideal. SUMIT CHANDEL:
Yeah, I’m not a fan. MEGHA BANGALORE:
Yeah, it’s not great. Because every step you have
here you’re dropping off users. Once you actually
install the app you’re presented with this
giant form with tons of fields that you have to
fill out and there’s no context as to why
you’re even doing this. SUMIT CHANDEL: So if you
are anything like me, when I download an app to
fill some kind of use case if the first thing I see is
a bunch of different flows of going to the right store,
downloading the right version, filling out a lot details
I’m probably not going to go through all that. And maybe even worse I’ll
just uninstall the app, which is definitely what you want. So wouldn’t a flow that looks
something more like this be a whole lot better? So in this case, on
the left hand side it’s still the
same initial screen of a friend inviting their
other friend to pay them back. And sending them
a link to the app. But what if after
they clicked on that the first
thing they saw was not which store that they have
to go to download the app, but they’re automatically
taken to the correct store based on their device? And then presented when they
first open app, download, and install it the
first thing they see is the context for which
they were sent here. Which in this case,
is Megha wants me to pay her back the
pizza because Megha doesn’t like to do favors. MEGHA BANGALORE: And Sumit
never has cash on him so it’s a whole big thing. It’s a whole big thing. But moving on to
the onboarding– [INTERPOSING VOICES] SUMIT CHANDEL: I
don’t know about that. But let’s continue
on with this example. So let’s say the first thing
that is exactly why you came to this app in the first place. And then you go
through that flow, you fill out a streamlined
account creation process. And then you can pay
your friend back. So this is a way
better onboarding experience for someone who
was invited into this app. And so Jesse and
Quinn said, that’s what we need to improve
because that’s a flow where we’re see that we’re hurting. And that’s exactly what
they did using something called Firebase Dynamic Links. So if you haven’t used Firebase
Dynamic Links before it kind of works as just we saw. There is a single
link that you create and after a user
clicks on that link, they’ll be taken to the
right store for their device automatically, whichever
is appropriate. If they’re clicking on it
from none of those devices we’ll just go to a web page. And after that point, once
they download and install that app there is deep link
context that you’ll receive in your application code that
you can then extract to say, OK why did they come to this app? What context were they in? And then present
them with that screen the first time they
open up the app. So let’s see how
they set that up. MEGHA BANGALORE: So
this is the Android code but it works very
similar in iOS as well. So here is where they
generate that link that has all the contacts that
they’re going to need. In this case, it’s the
user ID, the amount, and the actual event. So Megha, $12.50, for pizza. SUMIT CHANDEL: Yes. So this won’t be the
link that they’ll see, it’s the link that you’ll be
able to get in your application code. Now let’s look at generating
that Firebase Dynamic Link that the user will see. And this is what
builds that part. So we get an instance of the
Firebase Dynamic Link object. We set link, which is
the link that we just created in the previous step. And then we set
a DomainUriPrefix for our Firebase Dynamic Links. You’ll notice in this case,
it’s spotyourfriend.page.link. That special .page.link
subdomain is something that Firebase can create for you. So if you don’t have
your own domain, or if you don’t want to set
up your own custom domain to host these Dynamic Links– although, you can do
that if you like– you can just automatically
set this one up fairly easily through the console. And it’s going to
create a mini website with all the configuration
files and asset files you need to host
your Dynamic Links for you. So it’s pretty quick there. And then the next call is
building a short dynamic link. That’s just because
you don’t want to present the user with
this massive link with all that metadata of the
link data you need and whatever other
parameters you’re adding on. You can make this call to
build a short version that you could send, that’s
an asynchronous call. And so that’s why there’s an
addOnCompleteListener call there just to make
sure that task worked and you get that
shorten link back. And then you add on some
Android parameters and some iOS parameters that
encode into the link where to go for your Android
app or for your App Store app or iOS app for these users. And so that’s what they did they
implemented Firebase Dynamic Links, extracted that link
data to make a warm experience the first time it opens,
and implemented this flow. And, you know, it
actually worked. MEGHA BANGALORE: It did. It did. It was definitely
making an improvement, but it still wasn’t
doing enough. So let’s enter a week 2. A/B testing the invite flows
to find the very best one for your users. So the onboarding flow change
they made was doing a good job, it was helping and the
numbers were showing that. So let’s take a look
at the updated numbers. So we have about 238,000 users
clicking that invite link. And we have 11,000 users
creating an account. So this is a 4.8%
conversion rate. SUMIT CHANDEL: Yeah,
it’s an improvement. It’s better than the 2.3%
we saw earlier but still not a massive improvement
that they were hoping for. MEGHA BANGALORE: Yeah. It’s still a very
low conversion rate. So what was going on? Jesse went out to dinner
with his friend Nick and invited him to
you Spot Your Friend to split the cost of a bill. Nick promptly installed the
app and then forgot about it for a few days. Now, Nick is a bit absent minded
and he doesn’t necessarily remember what he had
to eat the last day, let alone who he had it with. But when he opened the
app again a few days later he did remember having
pizza with Jesse. But he said, I know
10 different Jesses. If I open this up
even a few days later, I wouldn’t really know
what this was about. So that context
would be useless. SUMIT CHANDEL: And so Nick
shared that feedback with Jesse and a Eureka moment and struck. So actually our warm
onboarding flow is good, it’s an improvement but the
reason why it’s not working is because people
don’t always know who it was that was requesting
this money because it’s just that name. What if we put the
photo in there instead? So it’s the photo of
the friend that way they know exactly who it is. That’s a way better
onboarding experience. That’s what we should implement. And then Jesse was like,
let’s go ahead and do this. MEGHA BANGALORE: Well,
not so fast, Quinn said. So Quinn shared the
app with her mom and what she remembers her mom
saying was the fact that Spot Your Friend only had
text was actually what she liked about it. There weren’t a lot of
confusing visuals or images that distracted from the
main purpose of the app. So she wouldn’t have
liked a photo only. SUMIT CHANDEL: So
clearly there’s different approaches
that might work best based on anecdotal evidence. So what’s needed here is
something more scientific to figure out which version
is actually preferred. MEGHA BANGALORE:
And so that’s where something like A/B
testing can come in handy. So you might be familiar
with A/B testing. But in case not
you’re not let me go with a classic
example of button color. Sorry. So let’s say you’re
not sure if having a blue button or an orange
button on your purchase screen will lead to larger
revenue in the long run. The best way to find
out is to actually run this test on real users. So you split your users
into a little subset, show the different experiences
to each one of them. And then just track the
results and see which actually results in more conversions. Then with that
winning variant you can roll it out to everybody. In the case of Spot Your Friend,
we had three different variants that we were testing about
how we display the inviter. First, we have what’s
already launched, variant A, which is text only. We have variant B, which
is Nick’s favorite, which is photo only. And just because we’re
running an experiment anyway, they also try
variant C, which is including both text and photo. Maybe this will actually satisfy
both Nick and Quinn’s mom? So what they did was
they ran this experiment using Firebase A/B testing. SUMIT CHANDEL: But
there’s a problem, Megha. MEGHA BANGALORE: Oh, no. What’s that? SUMIT CHANDEL: So of
course, we have a problem. MEGHA BANGALORE: Of
course there’s a problem. SUMIT CHANDEL: Did
you realize that– so while it’s great that
they could do A/B testing and test all these
different variance and get some results figure
out which one works best, they need a way to actually
inject these into the app or flag them into the app,
which they don’t have right now. So right now there’s no photos,
there’s no photo and text. There’s just that
text only option. So they need a way to do that. MEGHA BANGALORE: I think I
know where this is headed. Is there something
Firebase can do to help? SUMIT CHANDEL: There is. Yes, there is. It’s something called
Firebase Remote Config. So for those who aren’t
familiar Firebase Remote Config, you can kind of think
of it as a key value store that lives in the
cloud that you can push out to your end users’
client devices based on different conditions. So maybe historic app usage,
maybe the device locale that they’ve set up,
maybe the local time on that user’s device. So whatever conditions you like. You can kind of
gate that for when you want those values to be
pushed out to your clients. It also doesn’t require
redownloading a new version of your app, which
is nice anytime you want to push new changes
or new parameter values out. The other neat thing about it is
that it ties into A/B testing. So to set up those
different variants you would use Remote
Config parameters, set up the values you want
to set there, and then have your A/B test
use those and change the values for the different
variants you want to run. So let’s see how
they set that up for the photo case and
the text only case. Right here in the console. So this is the console over here
and there’s the Remote Config section. And we’ve already previously
created the Remote Config parameters that they
would use, which are this profile picture
on install and profile text on install. And these are just
Boolean values they can set on
and off depending on if they want that to be
present in the invite flow. Now, the other thing to
note about these parameters is that there’s a
condition applied here. This thing called
Invited via FDL. This is a condition
that we created for only those users who came in
via the Firebase Dynamic Link. So via that invite flow. We’ll look later how we
can actually set up such an audience in another example. But here that’s what
they set and applied to these Remote Config
parameters that’s only pushed out there. And let’s say we want
to add a new one. Just to give an idea of what
it looks like to create one, this is how we do it. So let’s say we wanted
to show Spot on install. That’s our– MEGHA BANGALORE:
Spot’s a little dog. The favorite mascot
for Spot Your Friend. SUMIT CHANDEL: Yep. It’s pretty adorable so it
be a shame not to use him. So let’s do Spot on install,
by default is false. But if we wanted to add
that into the invite flow at some point, we could
by setting that up here and then applying
a condition to it. But in their case that’s
not what they did. So they just had these
two values defined. I’ll publish these changes. And so that’s what they’ve
got in their console setup as values ready to use and
download into the devices. So we can go back to the slides. So now they’ve got that set
up in the console let’s look at how they set it up in code. And again, this
is using Android, but it’d be very
similar for iOS. So the first thing to do
is to actually configure your Remote Config instance. So that’s the first step here. So you obtain an instance of it. And then you configure it, one
of the most important elements of which is setting
the minimum fetch interval for how often your
app is going to actually check for new values in the cloud
from a Remote Config that apply to this instance of the app. And for now, that’s
3,600 seconds. So roughly once an hour. MEGHA BANGALORE: And
you might be tempted to have this be more frequent. And definitely when you’re
in developer mode that’s a great idea, you’ll actually
get those changes more quickly. But when you actually
launch you don’t want to have something that’s
checking this frequently because if you think about
it, on your end user’s device it’s making these
unnecessary fetches, that’s not really great
for your battery life. SUMIT CHANDEL: Yeah. And on top of that, you might
get rate limited as well. Because consider the fact that
in the case of Spot Your Friend they have about
1.4 million users. So that means 1.4 million
instances of this running and if that’s happening
every second that’s 1.4 million calls. So that’s definitely
going to get rate limited. So you definitely want
to make this something like more like once
an hour in production but more often when
you’re debugging. All right. So they did that. And then the last call
at the bottom there and you see is the
fetch and activate call. So that just fetches
any values that applied to this device
and activates Remote Config the very first time
that this might be opened up for this user. So that’s what that
call is doing there. Then here’s how you’d actually
get those Remote Config values. So you, on that instance
of Remote Config object, just call get Boolean or
get string or whatever value as you have defined. And you just pass
in the key, which is the name of the parameters
that you created earlier in the console. So the
PROFILE_TEXT-INSTALL_KEY and the PROFILE_PHOTO_INSTALL_KEY. MEGHA BANGALORE:
Now, in the case of Spot Your Friend,
the experiment they were running
was right on install. So what they did was they added
a few seconds quick splash screen on the very first install
in the very first open to allow time for that server call to
complete so a user can actually enter into the experiment. So they added the splash screen
with our dear friend Spot. And then they directly led
it into the warm onboarding that we saw before. So with this change to the
app shipped and in production they’re ready to really
run those A/B tests. So let’s go to the console
and see how they set that up. So here we have
their experiment. There’s some basics here. This is just for a
human readable text so it’s just so we
can find it later on. But this is the
interesting part. So here we’re targeting everyone
who has come in via the FDL. So we say includes
install via FDL. At the moment, we’re
targeting 5% of our users. That’s enough for
Spot Your Friend to get a good
sample size, but you might want to change
this depending on how many users you have
in your app in that audience. There’s no activation
event because we want to start exactly on install. The primary metric here, the
goal, is Create Accounts. And so that’s why we
emphasize it front and center as a primary metric. There are, however, additional
metrics that are generally a good idea to track. And they’re automatically
set but you can delete them if you don’t need them. For example, crash free users. It’s really great to be
super focused on one goal. But if one of the
variants is actually causing a lot of
your users to crash you want to make sure
that you can take that into consideration. SUMIT CHANDEL: Yeah. Another good example
is user retention. So let’s say if you’re
a game developer, and you’re making a game easier
for a beginner audience who just comes into it, and you’re
changing some parameters to make it easier
for them, well it might make the game more boring
for other users who come in and negatively affect
your retention. So you might want to keep
that as a secondary goal to make sure you’re not
affecting those negatively. MEGHA BANGALORE: Awesome. And now we get to
the actual variants. These are the variants
that I showed you before. The first one is the control
group, which has already launched, which is
where a text is true and profile picture is false. And these are the
same parameter names that we had defined
in a Remote Config. The second variant is
the all in a bucket. It’s text and photo, where
text is true and photo is true. The final one is photo
only, where text is false and photo is true. So see we can actually
review that one. And all we need to do
is publish it, start it, and now that experiment is
running and ready to start gathering data. And now back to the slides. SUMIT CHANDEL: Right. Now, I think I’m sure
at this point, it takes a while for these
results to come back, which means that I might
have time for coffee. And it’s quite late so I
could definitely use some. MEGHA BANGALORE: Well, actually
Jesse and Quinn did already run this experiment so we could
just get the results right now. SUMIT CHANDEL: All right. Fair enough. So normally, you
might have to wait a little while for the results
come back or more importantly, just for enough data to
come in to actually make a reasonable prediction for
what variant works best. But in this case, we
already have the results. MEGHA BANGALORE: Let’s take
a look at what happened. SUMIT CHANDEL: So in
this case, the winner is photo only,
which is interesting because I would have figured
that text and photo would be the preferred option. MEGHA BANGALORE: I’m
with Quinn’s mom. I think I would’ve preferred
text only because there are enough apps showing me
selfies or cute chinchillas. I don’t really need more
distractions especially, not in a payment app. SUMIT CHANDEL: So it kind
of goes so you can’t always go with your gut and it’s
always useful to have a more scientific approach. And by running
this A/B test they saw that photo only
is the one to go with and they rolled it out
to all their users. And looks like it worked. Right? The conversion rate here
is a huge improvement. MEGHA BANGALORE: Awesome. SUMIT CHANDEL: So 62.3%. That’s great. And more in line with
what they expected. MEGHA BANGALORE: Well, great. Now Jesse and Quinn
lived happily ever after and their app was amazing. Right? SUMIT CHANDEL: Can
I get a coffee? MEGHA BANGALORE: Yes. SUMIT CHANDEL: No. MEGHA BANGALORE: Darn. SUMIT CHANDEL: Because there’s
another problem that they ran into, one that’s very common. And that’s the problem
of user retention. So now at this point
they’re getting a lot of users coming in,
marketing is doing a great job. The conversion rate for
creating accounts looking good. Their A/B test worked for that. But now they’re seeing that
they’re not getting users to stay in the app after those
initial conversion events. Looking at their user retention
graph in the Firebase Console– MEGHA BANGALORE: Very dramatic. It’s very dramatic. SUMIT CHANDEL: It’s a
pretty dramatic graph. So you can see that almost
within the first day after users have
created their accounts and started using
the app, they’re almost dropping off to 0%
usage, which is pretty terrible. But why? What’s going on? MEGHA BANGALORE: Well, so
Quinn had a sneaky suspicion that there were a bunch of users
who are actually using the app, sharing a bunch of
money, and then leaving. So she dug into the
data little bit more and discovered that
it was the case that some of these users
who were churning still had money in their account. So they were leaving free
money in the app for no reason. SUMIT CHANDEL: So
that’s actually like a huge call to action. Because no one likes
to leave money behind. Right? So maybe some of these you
just created their accounts they received money or they
sent money but they still have money left over and they
just kind of forgot about it and stopped coming to the app
not realizing they actually have some money left in there. So that’s a great
call to action. If there was only a way
to message these folks, email them, or somehow
notify them to let them know, hey, you got money
come back to the app. Use it. Do some stuff. Stay in our app. But I don’t think there’s
anything I can do. MEGHA BANGALORE: There is. Firebase Cloud Messaging. SUMIT CHANDEL: Damn. I’m not surprised. MEGHA BANGALORE: And
of course there is. So Firebase Cloud
Messaging, or FCM for short, uses the exact same
audiences that we saw before with A/B testing
and a Remote Config. And so we just need to create
a new audience now and target those users. SUMIT CHANDEL: So the
first step in order to notify the right people for
it to re-engage them in the app is to define an audience
that represents them. So let’s look at how we
do that in the console. OK. So here we’ve already
defined that audience called have money, are churning. We’re very creative
with our names. And so I’ll edit this to take
a look at what it looks like. OK. So Jesse and Quinn
had the foresight to define a user property here
called money remaining, which you can see right over here. Now user properties,
you can’t think of them as representing
user states and you can record those with
your analytics events. So whatever makes
sense for your app, you can use these
to configure those. The limit I believe is 24,
25 such user properties. In the case for
Jesse and Quinn, they made one for money remaining. And so they can filter
on this and create an audience based on that
user property to say, OK. We only want to target the users
who have at least $5, maybe even $1 would be better
here, but at least $5 money remaining because they still
have some money left over. Now that’s the inclusive
group for this audience. There’s also an exclusive
group and that is we want to target users
who aren’t still active. Because if they’re still active
we don’t want to bother them. Let them continue using the app. So here the way
that one is defined is just by setting an
exclude group over the screen view, which is basically a
generic they did anything with the app, which means
that they’re still using it in some way. So if screen view event is
registered for this audience and the event count is greater
than zero in any 45-day period, these are still active users. So we don’t want to bother them. So let’s exclude that. And after they’ve
done that they’ve defined the audience that we
now want to target and notify that they have money remaining. So we’ll save that. And we’re ready
for the next step. MEGHA BANGALORE:
And then they’re ready to go to the FCM console. So from the FCM console you
can send those campaigns, those notifications. So if we look here, we
have the notification check your pockets, Spot
comes in for the save letting you know there’s still money. So we have the similar
targeting that we saw before. But in this case, we’re
targeting the audience have money, are churning. We could target another
app if we wanted to here but for now we’ll just
stick with this one. We want this campaign
to be running from now until the end of time. We don’t want to have
to come back every day and send this message for
new people in the audience. We do want to make sure
though that we’re only sending this message once. We don’t want to be spamming our
users and kind of annoying them with a lot of notifications
that aren’t relevant to them. SUMIT CHANDEL: Otherwise,
they might uninstall your app. MEGHA BANGALORE: Exactly. They’ll definitely
uninstall that app. There’s no conversion event
that we care about here so we can move on there. And there are no other
parameters we want to provide. So we can review this,
publish it, and now it’s live. So if we go back to the slides. Whenever users have
money remaining and are churning out
of the app, they’ll get a gentle reminder
saying, hey, come back. Remember about
Spot Your Friends. Keep using it, and get the
money that you have remaining. So if you wanted to have more
customization in that message itself, like maybe the user
name or the actual dollar amount remaining in their account, you
could use the FCM Admin SDK. And that allows your servers
to send a direct message to your user using
their FCM token. SUMIT CHANDEL: But in the
case for Spot Your Friend, Jesse and Quinn just used this
generic version and it worked. Their user retention went up
and they were doing just fine. MEGHA BANGALORE: But let me
guess something else went wrong before Jesse and Quinn could
live happily ever after? SUMIT CHANDEL: So far
that’s been the pattern. But no, up until
this point, they’re conversions we’re looking good,
account creations were looking good, the retention improved. So everything is good. MEGHA BANGALORE: Sweet. Actually legit celebration then? SUMIT CHANDEL:
Legit celebration. Yeah. MEGHA BANGALORE: Great. SUMIT CHANDEL: That’s
what you want, right? But this story
kind of gets boring when there’s not
more ups and downs. MEGHA BANGALORE: That’s true. It’s more exciting
when there are new challenges
that you’re facing or new problems
that you’re solving. That’s real life. SUMIT CHANDEL: Yes. And we promised
an action packed, no holds barred
presentation here. So something did go wrong and
let’s enter week number four to look at that, which
is engaging your users and helping them discover. So let’s say at this point Jesse
and Quinn we’re doing really good a lot of different fronts. Their user base has grown a lot. They’re getting a great initial
engagement and great user retention. So they got so good,
in fact, that others started to take notice. And some partners wanted
to be affiliated with them. Some really big partners. In fact, some credit
card companies. MEGHA BANGALORE: Nice. SUMIT CHANDEL: So someone
from a credit card company or representative
approached Jesse and Quinn and said, you guys
have a lot of users that are active in
the major cities where we have a lot of partners
and brick and mortar stores who have great deals
available to them. And because Spot Your
Friend is a payment app it makes sense to surface
these deals in the app so that they can redeem them. And if they do some
percentage of that can go to you guys for
helping surface them. MEGHA BANGALORE:
Which is awesome. So now Jesse and Quinn created
a section in Spot Your Friend to highlight and showcase
all of these deals. And they’re like, OK. This is awesome. We’re good to go. Everything is great. SUMIT CHANDEL: And
there is the problem. On the next slide right
here is that no one is redeeming anything. So the issue now
is discoverability. So it’s great that the credit
card companies approach them, they’re surfacing their deals in
the app in some section of it, but users who have
been using the app aren’t really
navigating to that. They’ve not been using
it for that before. They’re not used to going there
to use it for that purpose and no one is
redeeming anything. So what can they
do to improve this? Well, they do know that users
are making in-store purchases. So if only there was
a way to notify them at that moment at the right
place and the right time when that happens that, hey,
you just bought a pair of skis, there’s a deal for ski boots. There’s a deal for ski goggles. You can take action on if
it’s available to them. But I don’t think there’s
anything I can do with that. MEGHA BANGALORE: There is. Firebase In-app Messaging. SUMIT CHANDEL: Oh, snap. All right. Let’s see it. How does it work? MEGHA BANGALORE: So
Firebase In-app Messaging, or FiaM for short, allows you
to configure in-app messages from the console and
actually have them sent to your users’ devices. You don’t need to
worry about shipping a new version of your app, you
can create campaigns on the fly and that day it will come over. So let’s actually take a look
at the campaign they created. Let’s go to the console. So now we have my
favorite deal SKUAS12, I don’t know about you. It’s my favorite
product in the world. SUMIT CHANDEL: Oh, yeah. MEGHA BANGALORE:
But so the way FiaM am works is that
you drop in the SDK and it handles all
of the UI for you. So you’re given some
template options and that’s what we’re
going to configure here. In the case of this particular
alert with the deals, we want to use a modal,
which is the most kind of– I’m not going to say
aggressive, but it’s the most very visually
compelling side where it takes up
the whole screen and it takes your attention. So we have this
Spot alert saying that there’s this new discount
on Bluetooth headphones. So the image that
we provide here is hosted on Firebase Storage. It doesn’t have to be, but the
integration works really well if you want to use it that way. There’s a button here, which
has the call to action. This is how the
user will actually understand more about the
deals, they can then redeem it. We’re using our good friend
Firebase Dynamic Links again here to give a deep link into
that section of the app, which actually has the deal. Now we’re using the same
targeting that we know and love from the other Firebase products
so I can skip past here. And we have the
same day scheduling. It’s from now until
the end of time. The interesting thing
here is, as Sumit said, we want this to be a
very contextual message. So in this case,
when a user actually completes the in-store
purchase that’s when the message
is going to pop up. And again, we want to
be mindful of our users. We’re only going to show
this message once per device. We do care about
a conversion event here, which is
redeeming the deal. So I’ll say that here. We publish this, we take a
quick check to review it. And now we’re good to
go and this is live. So if we go back to the slides. When the purchase
is complete and we send that analytics
event, users will now see this message telling
them about a new deal that we’ve just
added to the app. SUMIT CHANDEL: And so
that’s what Jesse and Quinn implemented to make
these users discover these deals at the right
place and at the right time and start redeeming it. And that worked, of course. And they started actually
making some money and becoming profitable,
which is awesome because that means
that everything has been going right. They’re ready to live
happily ever after and we can get some coffee. Right? MEGHA BANGALORE: Yes. And so they had this
really happy pattern that they continued of
going to the metrics, understanding their users, and
iterating and improving the app experience to create this loyal
group of very delighted users who kept using the app. So there are more
deals that were coming in from other companies
because of that engagement. And they were able to make
all that great revenue, making Spot Your Friend
the giant, enormous app success that we all know
and love because everyone has this app, obviously. SUMIT CHANDEL: Of course, yes. I’m the number one user and
I’m sure you all downloaded it and installed it. So yes. All right. This is the story
of Jesse and Quinn and the trials and
tribulations they went through as they released
their app and tried to get more user
engagement and get the profitability in the end. Hopefully, through
that process of how they resolved some of these
issues, some of these things made sense for your
apps as well and are good takeaways for how you which
you can use for your own apps. Whether that’s with
Firebase or whatever else. And if you have follow ups– MEGHA BANGALORE: Yeah. We’ll be in the sandbox. It’s over that a way, the
Firebase sandbox afterwards. And so feel free to
ask us any questions or just dropped by to say, hi. Yeah. Thank you very much
and congratulations surviving through
the last session of I/O and happy developing. SUMIT CHANDEL: Thank
you all for coming. [MUSIC PLAYING]

2 thoughts on “Engage and Keep Your Users in Your App with Firebase (Google I/O’19)

Leave a Reply

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

Back To Top