Yuma 4×4

Media and Communications

AdMob + Analytics – Mobile Ads Garage #12

AdMob + Analytics – Mobile Ads Garage #12

[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]

11 thoughts on “AdMob + Analytics – Mobile Ads Garage #12

Leave comment

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