[MUSIC PLAYING]
ANDREW BROGDON: Hey, everybody.
I'm Andrew Brogdon, and welcome back to the Mobile Ads Garage.
Today, with the help of my partner, Gary the graphics guy,
I'm going to talk about AdMob and Google Analytics
for Firebase.
Publishers have been able to use Analytics and AdMob together
for a while now, but Engineering just
rolled out some new features that
make them smarter and more powerful in combination.
Plus, everything I'm about to show you
requires no code changes beyond a Gradle or a Podfile update.
And the Analytics are free and unlimited.
[MUSIC, CHEERING, AND FIREWORKS]
I know, right?
That's the most fun sentence I've
gotten to say in this entire video series.
All right, now.
OK.
Let's take a look at how AdMob and Google
Analytics for Firebase are working together.
If you're already a Firebase developer,
or you saw our earlier episode introducing
AdMob with Firebase, you're probably familiar with these.
They're the Gradle dependencies and CocoaPods
for AdMob and Firebase core.
That core includes Analytics.
So when you build your app with these,
you get the SDKs for both of those services included.
Now, they each have a backend service in the cloud
that they send data to.
That's how you get all that juicy AdMob reporting
data and all the stats that show up in Analytics.
The new piece that the engineering team just
finished building is this--
a link between the two systems, which
means AdMob reporting data, real dollars and cents,
now appears in Google Analytics for Firebase,
and Analytics data shows up in AdMob reporting.
So again, all you have to do is make
sure you've linked your AdMob app to a Firebase project
in the AdMob app settings.
And make sure you're building it with these dependencies
on Android and these CocoaPods in iOS,
and this connection will start working for you.
Now, let's take a look at how that data is made available
once it's up there on the server.
We'll start with the AdMob reporting interface
and see what Analytics data we can play with.
All right, so here's the AdMob UI.
And some of you might be thinking, hey,
that looks different than it did when I logged in this morning.
At I/O '17, AdMob announced a new version of the web UI,
and it's being rolled out right now.
You get the same AdMob functionality,
plus some new stuff like mediation groups
right in there--
and look for a blog post about that
in the video description-- plus a new material design look.
Because the UI has been updated, I'm
just going to go over, real quick, how to link an AdMob
app with Firebase.
So here, you just go to app settings.
And you can see the option to link is right there.
So I just click the Link to Firebase button,
and I'm asked to confirm the package name of the app.
I like to use the package names for my app names
when registering apps in AdMob, so I can just
type the same thing again.
Firebase space is a lot of stuff on bundle IDs and package
names, so it's important to get these right.
Now, AdMob's checked my Firebase account
and given me the option to connect with an existing
project or start a new one.
And I'm going to start a new one.
So I type in a name for my new Firebase project, click
Continue, and I'm linked up.
So again, all that's really required here
is to use the Gradle and CocoaPod dependencies you just
saw, and link your app.
Do make sure that when you do the link,
you don't forget to grab the configuration file right there
and drop it into your project as well.
Check our Firebase Quickstart-- and there's
a link for that in the description-- for more
details on what's in that file.
So let's say it's a week after I release my new version
with Analytics compiled in.
And I come back to the AdMob UI, what new things can I see?
So there's two big ones, and they're right here
on this screen--
the revenue card and user metrics.
I like revenue, so let's check that one out first and zoom in.
Cool.
So first, you get a straight bar chart
that shows you the revenue generated by your app, which
doesn't seem like much, but notice these categories down
here.
That's not just ad revenue.
By hooking into Firebase, AdMob is
able to give you the big picture, including
all the ways you're earning.
So if you've got a game out there with in-app purchases
and ads, you don't have to go bouncing
around different consoles to get all the numbers.
It's right there.
On the user metrics card, it's a dashboard
presenting some important numbers for app publishers.
Some of these are pretty self-explanatory,
like sessions per day and active users.
There are a couple I want to point out, though.
First is ad exposure.
This is a measure of how much of a user's session
was spent being exposed to ads.
Ideally, you want to make the revenue you need
while keeping that number low.
So it's good to keep an eye on it.
The other stats I want to point out
are the average revenue numbers.
These tell you the average revenue per user
and the average revenue per paying user.
ARPU, as it's called, is all your revenue
divided by all your users.
And it's a key stat.
ARPPU, which I can't pronounce with a straight face,
calculates IAP and commerce revenue
for users making a purchase, which
lets you know how you're doing with users engaged
enough to open their wallets.
So that's AdMob reporting, which gives you
the same kind of information you're used to getting,
but with new intelligence from Google Analytics for Firebase.
Now let's take a look at the Analytics console
and see how AdMob data makes an impact there.
So here we are in the Firebase console
in the Analytics section.
And I'm going to scroll right down
and zoom into the first thing I want to show you,
which is LTV, or Lifetime Value.
There we go.
Previously, this value did not include AdMob ad revenue.
But after the link-up between systems, it does.
So this number can now tell you how much
total revenue from ads and purchases
you're averaging per user.
If you're running a universal app campaign in AdWords
to grow your user base, you need to know how much revenue you
can expect from each user so you can figure out how much you
can spend to acquire them.
And with AdMob data included, you've
now got a complete value.
I'm going to zoom back out and head over to the Events tab
now to show you two new events that have
made their way into Analytics.
And they're right here at the top--
ad click and ad impression.
These are automatically generated for you.
And you can use them just like any other event-- session
start, change of screen, you name it.
So let me dig into one.
Let's do ad impression.
And I'm going to take a spin down the page
once it gets loaded up.
There we go.
So these are broken down by ad unit right now.
And I've got stats for clicks, impressions, and revenue.
Plus, that new ad exposure metric is available.
Let me show you a cool trick you can do here.
I'm going to change the grouping from ad unit
to grouping by screen class.
This field is generated for you using the class
names for activities and view controllers,
or you can customize it with calls into the Analytics
library on the mobile side.
Check out game board and main menu here.
You can see the ad exposure is almost entirely on game board.
It's 94%, compared to only 1.3% for the main menu.
That's more than 70 to 1.
But when I look at revenue, it's about 15 to 1.
That means my users are more receptive on the main menu
than they are while playing the game, which
is a piece of intel I can use in shaping my monetization
strategy.
Maybe I want to try removing ads on the game board
and using something like an interstitial that
appears between actions.
Or maybe I want to try a richer format,
like native, in the main menu, see if I can push engagement
even higher there.
The idea here is that Analytics gives you
actionable intelligence on your users
that you can really put to work.
I'm going to pop back out to the list of events now.
And I just want to mention that once you've
got Analytics in your app, you can start extending it
for a custom solution.
For example, these ad events are automatic.
But if you want your app to log an event called "reward
received" every time a user watches a rewarded video ad
to completion, you can do that.
I'll put a link in the description
below to the Firecast series, which
can show you how to log your own events in Analytics.
In addition, I also have all the other Firebase services
that I can choose to integrate, like Remote Config.
For example, I can make a custom audience based on my events
and send different configurations down
to the device based on that.
I could create a reward received event,
like we just talked about, make an audience
of those users who've experienced it,
and then use Remote Config to turn off all the other ad
formats in the app and focus on rewarded video.
You'd have to spend a day or two in mobile code
to make that happen, but it's there if you want it.
Similarly, if I have a subset of my users
that spend a lot on in-app purchases,
maybe I'd prefer to show them a house ad
campaign for my other apps instead of normal AdMob ads.
I could use Remote Config to send down different ad
units based on audience, and then use
them to make my ad requests.
There's just a ton you can play with here now
that all this information is in one place.
So that's it for today.
Before you go, though, I've got some resources for you.
If you look down in the description,
you'll see links to the AdMob with Firebase Quickstart guides
for Android and iOS, plus a help center article that
covers how to link an AdMob app with a Firebase project
in case you haven't done that step.
You'll also find a link to our SDK forum,
where you're welcome to bring any technical questions you
have.
And if you've got a question about this series or an idea
for something you'd like us to cover, leave a comment below.
And Gary and I will see you next time.
[MUSIC PLAYING]