Tip:
Highlight text to annotate it
X
>>Neil Rhodes: Thanks for coming to this session. Before I begin, a couple questions.
First off, how many of you currently use Google Analytics?
So it looks like 50, 75%, somewhere in there. And of those of you, how many of you use Google
Analytics for mobile apps? Almost the same percentage, maybe 30%, something like that.
So for those of you who don't use Google Analytics at all, it's a way of providing anonymized,
aggregated data about the usage of your software, and we're going to see that in much more detail.
For those of you who use Analytics but don't use it for mobile yet, I hope this really
shows you how mobile can be quite useful with analytics.
And for those of you who are already using Google Analytics with mobile, I think you're
going to be really excited about what we have to show you with the new features, new announcements.
So my name is Neil Rhodes. I'm tech lead for the mobile analytics SDK. I'm really happy
to show you what we've been working on for the last nine months.
About two years ago, we released an SDK for mobile analytics. But it wasn't really a great
solution. So Google Analytics has been really designed best for Web sites. And, really,
what we said to you when we provided this SDK was, you can go ahead and use analytics
for mobile applications. However, you have to pretend you're a Web site. Right?
You pretend you're a Web site. We will pretend you're a Web site. And we're not going to
really give you anything application-specific. So how does that pretense work or how did
it work? Well, for one thing, when you signed up an
account, you had to provide the URL of your Web site, until recently.
Now, I don't know about you, but I don't have a URL for my mobile application. So you had
to fake one. Another example. All the terminology was Web-centric.
We use terminology like "visit" and "visitors." I don't have visitors to my application; I
have users. And I don't have visits; we have maybe sessions. I don't have page views; I
have screens. And also, I have information that's specific to applications, things like
versions, application name, things like, well, crashes; right? That happens. And it's information
you want to find out about. So what we're announcing today, what we have
announced today, really, is mobile applications as first-class citizens at Google Analytics.
Announcing Google Mobile App Analytics. [ Applause ]
>>Neil Rhodes: Thank you. So this is available in beta. We're taking
people in via white list. And we're going to be allowing those people to enter the beta
in waves. And we expect to have everyone who's using Analytics available to use mobile apps
by the end of summer. I'll talk a little bit later about how you
sign up for this white list. So mobile applications. When you're developing
a mobile application -- we saw a number of sessions this week about development.
Actually, let me add one more thing. When I say "mobile applications," I did say Android
applications? >>> No.
>>Neil Rhodes: I said the word "mobile," because this includes both Android and iOS.
So when you're developing applications, you go ahead and develop them. And then you market
those applications through a variety of ways. So you might have paid advertising, email
marketing campaigns, Google Search, and so on, SEO type things. And then, my favorite
part next to the analysis is monetizing. Right? How do you make money on this application.
We had sessions on this as well this week. What we're focusing on is the third part,
the measuring and the iterating, that is, measuring how well your development has worked,
how well your marketing and monetizing are working, and then improving those and iterating
on them. For development, some of what you can measure
are -- the sad thing I mentioned earlier -- crashes. Also measure how people are using your application,
whether there are particular screens that are not used very much or options that are
not used very much or screens that are confusing to users and they leave your application.
So by measuring that, you can then go and iterate and make a better product.
You can measure your marketing. What happens when users come into your application via
different channels? How do they act within the application? How well do they monetize,
and so on? We'll look at some of this in more detail.
We break apart, really, three different areas of measurement. So one is acquisitions. Where
are your users coming from? Are they coming because an email marketing campaign drove
them to Google Play, for example? Are they coming because they're doing a search on Google
for various key words? Are they coming because of various advertising campaigns?
And it's important to get that information. You want to spend your money wisely if you're
doing advertising campaigns. A second is engagement. Once the users actually
get there and are using your application, how are they using it? What screens are they
using in your application? For how long? How do users move within your application from
screen to screen? That nasty word, app crashes, again. So we
may want to know information about app crashes, like, what is the crash, of course. But also
where is it occurring within your application. What kinds of devices is it occurring on?
What operating system versions? What versions of your application is it happening in?
Events. Think of screens as sort of the where in your application. And events is the what
that's happening. So you can add code to your application to
track specific events that are occurring, things like, for instance, the user choosing
a particular preference item. Let me pick a specific example.
Let's say you have a menu item to carry out some task. What percentage of your users use
that menu item? Do you have any idea? Is it 1%? Is it 50%? How many users don't even know
there are menus? Probably a fair number. Right? And so by causing an event to be tracked when
a menu is chosen, you can have some idea of how often that's used. Maybe it would be simpler
to not have that event at all. Or maybe it happens so often you want to actually make
that happen on screen. So that's acquisition. Where do users come
from. Engagement, what do they do when they get
there? And then outcome.
So we have several outcomes. One outcome is certainly monetization. What sales do you
have of your application? What ad revenue do you have? What in-app purchases do you
have? And I want to look at that information and
slice it and dice it in various different ways, like per country, for example, or in
a number of different ways that we're going to see.
We also have the idea of goal conversions. So you can set up a goal within your application
of, like, reaching a particular screen or having some particular event happen and see
how users get to that conversion, how many of those happen and so on.
So now let's look at a demo. So here I am, and I'm going to create a new
account. So I've got an application I want to do tracking for. And what do I want to
track? Well, what we see is a first-class object or application. So we have a Web site,
yes. And if we had a Web site, we would need to know its URL, of course. But we're not
a Web site. We're an application we're going to be tracking. So no need for a URL.
Our application actually has a name. This is Neil's App, let's say. And my account.
And then I can go ahead and get a tracking ID.
First I've got to agree to the terms of service. My Evelyn woods speed reading class comes
in handy. And, yes, this all looks reasonable. And now I get a tracking ID.
So this is the ID -- UA number number number dash number -- that I'm going to use within
my application to specify that it's for this account that I am tracking information.
From here, I can easily download the SDK. So the Android SDK or the iOS SDK, in a single
link. I have references to the documentation from
here. A lot of folks monetize their application
using AdMob. And so if you use AdMob, we have a single download that actually combines both
the AdMob and Analytics SKDs. One fewer thing to download.
So I've created this account, but I'm not going to actually use it right now, because
since I just created it, there's no data there. Instead, I'm going to look at a different
account. So this is for an application I call Acme Travel. It's an application that's used
for searching and booking hotel and flights. And in the overview, we provide what we hope
are the most useful graphs and dashboards that you'd want for looking at this. And we've
organized it in these three ways, again: Acquisitions. So here we see how many new users and active
users per day, where they're coming from, what device model.
Engagement. How long are they using your application? How many screens per usage or per session?
What screens are the most common? And then outcomes. Goal completions. And as
I mentioned, my favorite, in-app revenue. So I can see revenues were going up slightly,
and then I had a sudden drop, but that was made up for by a nice peak.
So graphs and numbers are nice. But that is not the reason for analytics. Instead, the
reason is to have -- find information so that you can take action.
Look at an example. So Google Play sources. I can see, again,
the acquisition. How did my users get to my application?
So this source and medium tells me -- Google and CPC tells me, basically, this is an AdWords
campaign. I also have an email campaign. Mobile Display is an AdMob campaign. So this was
not me monetizing my app, but instead, me as an advertiser trying to drive users to
my application. Organic search. Google doing a search that led to going to Google Play.
And other advertising campaigns as well. And from each of those, I can find out how
many users, how many new users, I got, how many sessions those users had, the duration
of those sessions, and the in-app revenue. This is the information that we provide you
directly. You can certainly make customer reports and slice and dice information how
you want. What do I get from this actionable?
Well, I see, for example, that my AdWords campaign had ten new users with an average
session duration of 35 seconds, and they spent a total of $2,493. This is probably an exceptionally
good AdWords campaign, actually, with an average of $250 per user.
My email campaign did fairly well. I had six new users. So, actually, if I just looked
at users, ten new users in my AdWords campaign, six new users in my email campaign. Well,
that says that the AdWords campaign is about 50% better than the other one; right? But
the cohort of people coming in are actually different. That is, their behavior is different,
depending on how they got there. Why might that be? Maybe the people who came
in via my AdWords campaign, I had a particularly compelling ad that only people who are quite
qualified would click on. And maybe on my email campaign it was somewhat less directed
and I had more sort of random people coming in.
But in any case, I can see how well my ad worked with respect to the money I got. And
here, clearly, the AdWords campaign went well. We'll take questions at the end. But do save
that question. Look at another question I have.
So this application is in English. I have enough money, I have enough budget, to translate
it into a single language, to localize it. And, unfortunately, one.
As I look at this chart, I see that English is certainly my predominant use. So this is
people whose devices are set to use English. But I also have people who are using it in
German, in Spanish, and French. Now, again, the application is in English, but they're
on a device that's set up for German, Spanish, or French.
And as I look at the numbers here, my natural inclination would be to say, German is obviously
the language to which I should translate next, because that's the most number of users.
But if I look more carefully, dive into the numbers a little deeper, I see that the behavior
of the users using German is quite different from the ones using Spanish. In particular,
the screens per session is 2 for German, which is very close to the English of 2.09, whereas
in Spanish, it's only 1.38. If I look at the session duration, it's actually
longer in German than it is for English users. But in Spanish, it's five seconds.
Here's what that tells me. Here's the story that I get from that. I could be wrong, but
this is my interpretation. German users, at least of this application,
are willing to use it in English. They're willing to use it for just as long as English
users. Spanish users are not. Okay? They open the application and they leave pretty quickly.
So this says to me that although I might affect more users if I translate it to German, I'm
actually going to improve the life more if I translate to Spanish, because the German
users are okay with it and the Spanish users are not.
Does that make sense? Okay.
Let's look at an overview of devices and networks, again, to try and get some actionable information.
Top network operators, not that useful to me, although it does tell me, since we're
using Sprint as the top network operator, that people are mostly using this via cell
connection and not via Wi-Fi. So that's useful information.
Key information here for me is the OS versions. So I see that Android 4.0 is the largest set
of people using my app. Android 2.1 behind that, iOS just behind that, iOS 5. And then
some other versions of Android and iOS. So what this says to me is that the majority
of people using iOS are using iOS 5. And, in fact, I wouldn't lose too much of my iOS
users if I required iOS 5 as a minimum version. Doing that might allow me to take advantage
of iOS 5 features. Okay? And make my life a little easier because I didn't have to support
iOS 4. On the other hand, it wouldn't make sense,
according to these numbers, for my particular users for Android. If I required Android 4
as a minimum, I would lose a lot of my existing users.
So that says to me if I want to support Android 4 features, I need to make sure to do so in
way such that my application will still run on earlier devices.
I can see the device models, and that's useful. Screen resolution is another thing that can
be important; right? If I know what percentage of people are using what screen sizes. This
tells me a fair number of people are using large-resolution devices, high-resolution
devices, and so therefore it might make sense for me to invest in higher-resolution artwork,
because my artwork right now is fairly low res.
Let's move now from acquisition to engagement. I can see information like what screens people
are using, what events are occurring. One thing that's really interesting is engagement
flow. So this tells me how people move within my application from screen to screen. This
particular application doesn't have very many screens. It's a fairly simplistic application.
But what I see is -- so this is telling me on the left that people coming in using the
Android version of the app, and the people coming in using the iOS version of the app,
and I get to see how many of them go -- start at the search screen. So the vast majority
of them start at the search screen. And in the red here on the right is the dropoff,
how many of them leave the application by going to the search screen and then leaving.
So we have some number, about 8%, drop off. The rest of them are moving over to the results
page. Say I want to narrow down just what are the
Android users doing. In this case, I see most of them go on to the search page, but a small
portion of them just go into the login page and then, kind of weird, go directly into
the results page. I'm not quite sure what's going on there and that might make me want
to look into my application a little bit. So this tells me the where of how people move
within my application. What we've also got is ability to look at not only the where but
also what's occurring as well. So I can look at a combination of screens and events. Let
me start at the results page. So I can see that the results page, from there I go to
the preferences or the book page somewhat, but then I also go to these blue events. So
I can see the interaction that's occurring in my application by users between screens
and between also screens and actions. Crashes. So we differentiate between crashes and exceptions,
or rather exceptions are a superset of crashes because we also have exceptions that occur
that are not fatal. So crashes are fatal exceptions. And unfortunately in this application we had
some crashes. Our 1.1 version had four cashes, our 1.2 version had 13. So that might say
to us that's not good, it's not good to have crashes, right, I'd like to have the number
zero there. Might say just our 1.2 version got worse than our 1.2 version or maybe it
says we have a lot more usage of our 1.2 application. We can investigate that a little further.
We have versions of our application for both iOS and Android in 1.1 and we introduced 1.2.
It's interesting, if I add some information to this and look at the operating system,
and what I see is it's actually segregated. The 1.1 version of the application only has
crashes on Android. And there are none in the 1.2 version of Android. So that says I
had a problem there and I fixed it. Unfortunately, what happened on iOS? Apparently, I was doing
great there and I added a bug. It wasn't me, it was my partner. I don't have bugs. I'm
going to fix the 1.2 version of Android, in fact. Some of the other reports we can see
and how this is useful. So this is loyalty. How many times does a particular user use
your application? So there are some users that use it once. And this is during the time
period of interest that we're looking at. Some people use it between 50-100 times. It's
useful to know how many people use it, but it's also useful to know how that affects
other parts, how does that affect your monetization. In this case how does it affect your goal
conversion. If we look at the goal conversion here, I see that about session 6, I get a
big bump in my goal conversion from 77% to 92%. So this may be because users become more
comfortable with my application and then are willing to go ahead and go to this conversion,
which in my case involves buying something. So maybe it's important to try and help drive
people who use it more so they become comfortable so then they can monetize your app.
All right. And actually the final one I want to show you is the e-commerce. And this I
don't have anything actionable right this instant but I love to see how much money I
make, and I can see how much money I make for each of my products, in this case I'm
selling round-trip air tickets and so I can see that I'm selling a lot, for some reason,
between Ontario and Boston. I might look into that and see how I can sell even more.
So what have we seen? What we've seen is the introduction in the GA of mobile apps as a
first-class citizen. So we've seen the sign-up flow, the new reporting. Next what I'd like
to look at is how you actually add this to your application. To begin with, let's look
at the architecture and let's look at the architecture of a Web site. You've got a Web
site to which you are adding analytics. What happens is you have a Web page that includes
GA, Google analytics.js, JavaScript. This JavaScript has an API on it and you can then
track various things, including events, and pages views and so on and those get sent down
to the cloud there which is the Google analytics back end. And it's very straightforward and
simple. It's a little more complicated in the mobile case. First off, you're not downloading
JavaScript dynamically, right? Instead, you have an SDK that's linked with your application.
That SDK will then accept tracking calls from your application, and unfortunately, it can't
send them directly to our back end. For a couple reasons. Give me one reason.
>>Neil Rhodes: What's that? >>> Power.
>>Neil Rhodes: Power's a good reason. So we wouldn't want, every time you switch screens,
to be powering up the radio and sending out hits across the Internet. The second reason
is if we -- even if we did power up the radio, maybe there's nothing there, right? You're
on an airplane or in a tunnel or something else. So we don't necessarily have Internet
connectivity. And even if we did, it's not clear we want to be using it immediately.
So instead we queue those hits in a local database and then those get dispatched on
a periodic basis. As well, you can request a dispatch manually. So if you're already
making some connection to the network, that's a good time to request a manual dispatch because
we can then piggyback on top of your connection which is good for battery life.
So let's look at the steps you need to take in order to add analytics. And there are really
four basic ones to get started. We'll talk of -- in a moment of additional things you
can do. So these four steps are to add the jar file to your project. In this case I'm
going to be talking mostly about the Android, although some asides about iOS specific. For
iOS don't add a jar file, okay, for iOS add dot.hn.a file. So we first add the jar file,
and actually I'm going to talk about this somewhat briefly because I'm going to go through
a live demo. The second thing is add a configuration file. On iOS you're going to actually be doing
this in code, and the reason for that is in iOS, it's very -- you have a single place
when your application gets started. You can go ahead and do initialization. For Android
your application starts because some activity starts and so we don't want to have to duplicate
that code with every activity. So instead, we provide an XML file with configuration
information that we read from. So the most important configuration piece is that tracking
ID you got when you created the account. UA-number, number, dash, number.
The second thing I always like to turn on for development is GAD bug. So turning that
on will provide additional debugging information to the console so that you actually know analytics
are working, things are happening. The third thing is auto activity tracking.
And this is specific to Android. If your application is designed as a set of activities, each of
which roughly corresponds to a screen, as the travel application was, then you would
want to turn this on. And so as a user switches from activity to activity, we will automatically
track those as different screens. I'll talk a little bit later on in cases where that
wouldn't make sense. And the final thing we're turning on here
is reporting uncaught exceptions. This will install an uncaught exception handler, what
I think of as an exception handler of last resort which will take an exception that is
about to abort your application and go ahead and track that and send that to Google analytics.
There are a couple of configurations you can do as well and they're documented. So that's
number two. Number three, update your manifest. The most
important two things are a set of permissions, right? You need to be able to connect to the
Internet so you need to set that permission. And we need to know what the network state
is so you need to set that as well. I've mentioned the fact that analytics provides
information about where you're coming from the application, okay? Sorry, how your application
gets installed, how users go into Google Play and Google Play has to provide information
to analytics and that's done with an install receiver. So there is a notification that's
made when Google Play installs your app, we handle that notification, grab this campaign
information, and then we'll send it the first time the user uses your application.
The final thing you need to do is actually add some code. You need to tell analytics
that you're starting, so in every one of your activities you need to overwrite on start
and on stop and call analytics SDK. We do provide a tracked activity class that just
does exactly this, so if you just want to subclass from that that's fine as well. so
what I'd like to do is a quick demo of actually doing this just to show you kind of how simple
it is. So I'm going to create a new Android project from one of the samples that ships
with the SDK. I'm going to use the notepad example. All right. And step one was to go
ahead and add the jar file. So I'm going to go ahead and create a libs directory. Which
already exists. Which is quite odd. Since I just created this from scratch. So here's
what I'm going to do. I'm going to create a new Android project and I'm going to name
it notepad 2 and I'm sure that will solve all the problems. Because I'm quite suspicious
when code suddenly appears there automatically. And there's no libs directory there, so that's
looking better. So I have a libs directory. And I'm going to go ahead and drag over my
jar file. And that's step I need to do. Step two I need to do is I need to tell Eclipse
to go ahead and use that jar file as part of the class path. So I'm going to configure
the build path, add the jar file, okay. That's step one done. Step two, I said, was we need
to create an XML file for configuration. So I'm going to create a folder for that. Create
an XML file and call it whatever you want. I'm going to call it analytics.XML and it's
going to have values. And then go ahead and add the values I want. So I'm going add a
string which is the tracking ID. So GA_trackingID. And now I need to remember my UA. So thank
goodness I have it hidden away in a text file. Great. The other things I need to add, unfortunately
the visual editor doesn't work for, so I need to add a Boolean which is GAD_bug. We'll set
that to true. I had another Boolean which was, let's see, we want to -- auto activity
tracking. I could do the uncaught exceptions but I happen to know that notepad doesn't
have exceptions. The last thing I need to do is I want, for debugging purposes only,
to adjust the dispatch period. And I just want to make it 15 seconds so I can actually
quickly see these hits go out. We would not ever want to ship with this because that would
basically just keep the radio active most of the time. So that was step two. Step three
is the manifest. And in the manifest I need to add my two permissions. So the first permission
I'm going to add is accessing the network state. And the second permission I want to
add is being able to access the Internet. And what's the final thing I said we needed
to do? And I'm not going to put in the install receiver now because I'm not actually planning
on installing this via Google Play. The last thing is code. So I'm going to go into the
notes list, and I need to override on start and on stop. Feel free to tell me if I make
any typos. Okay. So that's my onstart. My onstop looks very similar except we stay stop
instead of start. There are three activities in this application. For the other two, the
subclass activity, I'm going to go ahead and subclass tracked activity. As I mentioned,
that's exactly the same thing, it just overrides it on start and on stop. And the title editor
is the final one. Import it. And I think we're good to go. So let's go
ahead and run this application. Okay. So we can see it's uploading it on to the emulator.
You know, that reminds me of something. All this is running. I'm going to go back to the
analytics report because there was run report I intended to show you that I forgot. And
that is a report that started coming out last year, I believe, which is real time. And I
want you to know that real time works for applications as well. So switching away a
second, I want to have an application that uses real time. This notepad is going to have
one user. My Acme application doesn't have really any right now but there's one that
you all have which is the I/O app. So if you all pull out your phones and pull out the
Google I/O app. So the Google I/O app right now has 210 users. Okay? We see -- and as
you use it, and go ahead and sync so what happens with the Google I/O app is it doesn't
actually send the hits back to analytics until it's actually synching so it can piggyback
and do that so you're going to see more and more users coming on here as you start using
the application. So 215 applica- -- 216 users. Most of them are using the agenda, which is
not surprising. But there are other people in various other screens, most of them Friday
screens, which is not surprising, again, not using Thursday, not using Wednesday. So this
allows you to see how many users are using your mobile application, in this case, in
the last 30 minutes, and in this case, in the last minute. If we go back to the notepad,
I can see in the log that we actually have hits being sent, so I can see this get and
I get to see actually what the particulars of the hit that's being sent. So that's my
indication that this is working correctly. I'd really like to be able to see this, so
for some reason I can't unlock this. But I know the notepad actually opened. You can
actually also -- this is a useful use of real time. So in this case this is the notepad,
real time. And I get to see, I have one user of about four minutes ago, which is when I
first launched the application. That's a good way you can quickly verify that your application
is getting information back to Analytics. Okay. So we've seen today what we have. We've
seen the reports, we've seen how you add analytics to your application.
There's other code you might want to add to your application. Tracking views manually.
This would be the case if you have a game application where you have a single activity
and users are moving from level to level in your game. So you would want to call trackview
as they enter a new level. Or if you've got your application organized as fragments as
users display one fragment or another fragment, you would want to trackview. Events I talked
about, the what is happening in your application. We have a three-level hierarchy of strings
as well as a value associated with each event. E-commerce, so you have any sort of e-commerce
in your application, as we did in the travel app, you can record it here. It's basically
transaction consists of one or more items, each of which can have their own quantity
and price. Exceptions, so you can use the uncut exception handler or catch your own
exceptions. In this case, the false means it's not fatal. You can provide the raw exception
in which case we will summarize it for you. Or you can provide a textual description on
your own. And timing; timing can be really useful to optimize your application and user's
experience of that application. You might want to keep timing, for instance, of how
long it takes to sync your application to your backend, or how long it takes to load
a new level in your game. And then get that information in your reports and find out there
may be out layers you want to go fix. So I've seen what we have today. Let me look
at an upcoming feature that I'm really excited about. And that is, integration with Google
Play. When you are creating an account, you have the option of linking that to a Google
Play account. We will show you then all of the applications you have in that Google Play
account. You probably don't have Gmail and YouTube. We at Google do. You will see your
icons for your applications and you can then link an application to your account. How is
that useful? Well, we have a report that shows you how
users are getting -- you've already seen how users get to your application, right? We now
have some extra information that we can show about how many users may get to your page
in Google Play and of those how many actually download the application. Right? Because there's
definitely a difference there, right? You've got people who go to Google Play, see your
page and see side, nah, this isn't for me. You can see how people differentially download
based on how they are coming in. Are they coming in via Google search, AdWords, so on.
This can allow you to optimize your campaigns as well as optimize your Google Play page.
What might you do? You might adjust your screen shots. You might adjust your copy. And you
might find you want to get better reviews by whatever means you can do that.
One more thing. I'd like to go ahead and bring Nick up on board, to show you something else
exciting in the space of Analytics and mobile applications.
[ Applause ] >>Nick Mihailovksi: Thanks Neil. My name is
Nick Mihailovski. Where's the clicker. Thank you. All right. I'm going to get you guys
awake because I know it's late in the day and Analytics is probably -- for me it's one
of my favorite subjects. So my name is Nick Mihailovski. I'm a developer programs engineer
on Analytics. I'm really excited here to talk about one more thing that we have. Now, typically
most people who use Google Analytics log into the web interface and view their data. But
what happens if you're away from your desk? Like if you're traveling and you want to view
your data on the go. In the past, it's been difficult. The experience hasn't been that
great. You either have to go and boot up your computer or you are going to have to go and
go to your mobile device and look at the browser and the experience wasn't optimized until
today. Today we're launching -- [ Applause ]
>>Nick Mihailovksi: Wooh! All right. Today we are launching a new Google Analytics mobile
application that allows you to view your data directly from your Android device. Now, if
all things work well, it's -- if all things work well, I'm going to try to show you a
demo from my device. Let's see if the Wi-Fi cooperates here. All right. Hopefully nobody
calls me either. All right. So here I have Analytics app on the phone. I'm going to turn
it on. First thing what we do is we show you a list of all the profiles that you have access
to. So the demo I'm going to give you today is Google I/O app, the same one Neil showed
you. I'm going to go ahead and click on that. The first thing we show you is the dashboard.
This is a quick way for you to view your key performance metrics. What's nice about this
dashboard, it's completely customizable. So right here, the default view will show you
the total number of active users for the I/O app. Notice how the number of active users
has increased because everybody is using the app at I/O. Now what I could do is click this
plus button, I have a full list of different metrics I can use to add to this dashboard.
I'm really interested in crashes. Crashes should not happen on an app especially when
everybody is using it. Let's go ahead and click on the crashes metric. I can configure
this to change and apply advanced segments. I could change the date range, bunch of stuff.
For you guys, we will use the default view. Go back. Boom. There you have daily crashes
in the palm of your hands. Pretty cool. So here's a little story on the next feature
that I think was really cool and is really applicable. So for the keynote, I was standing
there in line with my buddy Antonio Rosso. We are standing in this line. Thousands of
people around us. Everybody is trying to get into the keynote for I/O. We started to chat
about how this year at I/O the audience is bigger, things are better. The new mobile
I/O app is so much better, it's easier to use. We look around, he asks me, I wonder
how many people are using the mobile app. I look at him and smile. I showed him this
view. Which is realtime reporting in Analytics. Now, I probably don't have a connection here,
so you can't see the data because it's realtime and since there's no connection, you're not
going to see information here. But what we are doing is we are bringing realtime, up-to-the-second
reporting directly in the palm of your hands. So at the time when we were looking at the
data, we saw about 5,000 different people using the app right there. And I swear this
works because I was sitting right here and I was looking at it the whole time changing
networks and, of course, when I have to do the demo, there's no connection. It's setup
to work on Google I/O. So what we will do here is we will show you a metric of the total
number of users whether it's in your web site or your application. So if you're at the movie
theater looking at your metrics, if you're in a board room meeting and kind of sneaking
a view, you have up-to-the-minute reports of what's going on in your site. Now, in Google
Analytics there's over 200 metrics you can analyze. That can be difficult to analyze
all that data on such a small device. A couple of years ago we launched what we call Google
Analytics Intelligence. Now, Google Analytics Intelligence mines all your data and finds
statistically significant changes and shows those in a report. It's pretty much a what's
change report. To make analysis easy on the device, we incorporated Google Analytics Intelligence
directly in a view. What this shows you is a list of the top things that have changed
on your site, ordered by day and by statistical significance. And so when you click on the
first link, what we see is that in San Francisco the number of sessions has increased by 500%
and that's an anomaly in our data set. You can see by the data-over-time graph that there's
a huge increase of data right there. Now, when you're looking at this data, you might
be, again, waiting to get on a plane or eating dinner, and you want to share this with your
team at home. We made this easy to share by clicking this button. You can send this report
to your team back at home. So that's a high level review of the Google Analytics mobile
application. The app is free. It will be available through Google Play within a couple hours.
With that, I want to bring Neil back on stage. [ Applause ]
>>Neil Rhodes: Thanks very much, Nick. So let's summarize. We've shown you Google mobile
app Analytics which brings mobile applications as a first-class citizen into Google Analytics.
If you go to this link goo.gl/E8ULI, you can go ahead and sign up for the whitelist. Whitelist
will be available in waves starting Monday, and the good news that I have for recall of
you at I/O is that you all at I/O have preference over anyone else.
[ Applause ] >>Nick Mihailovksi: Let's be clear, if you
want to use this application tracking, this brand new stuff, sign up right now because
a lot of other people will sign up and you guys will have preference.
>>Neil Rhodes: When he says right now, wait until the session is over. All right. Second
thing we showed is -- so what will happen, you will get an email. User will be enabled
to go create app profiles. You can go download the SDK, look at the docs, create applications
that use it, start sending the data, seeing the reports and so on. So it's all there.
The second thing we have launched today is a Google Analytics Android app, which Nick
just showed you and which we are really excited about.
Here's the link for it. As Nick said, it should be available in the next couple of hours.
There's a QR code not too useful for those of you here. If you happen to be streaming
this, it might be useful. With that, we thank you very much.
[ Applause ] >>Neil Rhodes: So let's now open it up for
questions. Just to let you know, by the way, Nick and I will be available after this session.
We will go out in the hallway and then we will make our way down to lunch. You're free
to join us. Any questions? Let's go ahead with questions?
>>> Hi. So if I were already using Google Analytics for my app and there's already data,
like a lot of Analytics information on there, what's the migration path? How do I migrate
to -- >>Neil Rhodes: So you are already using Google
Analytics for mobile app? >>> Yes.
>>Neil Rhodes: So unfortunately, you really need to just switch over to use the new and
you're not going to be able to see your new and old data.
>>> Okay. Is there a plan, though, for the migration?
>>Neil Rhodes: So, no, unfortunately. This was really -- just the old mobile SDK was
a labs feature, we don't have a migration. >>> Thanks.
>>> Basic question, when you were on the dashboard for Google Play showing the traffic sources,
do you have to input those choices manually or does it auto recognize where you're traffic
is coming from. >>Neil Rhodes: The traffic sources are auto
recognized for everything except the email campaign there. So in general, we have manual
campaign tracking and auto tracking that happens. >>> Can I go back to those traffic sources
and look at future retention and actions from those traffic sources, or is it only showing
me app open on the initial launch? >>Neil Rhodes: What happens is that when you
have a traffic source, that information is maintained across the lifetime of that user,
and so we can still see information, for instance, of what happens on those users in the future.
>>Nick Mihailovski: So if you have in-app transactions, you can then attribute that
back to the original ad that sent them to download your app.
>>> Beautiful, that helps me with lifetime value and retention. Thank you.
>>Neil Rhodes: Question. >>> Two questions. The first one is maybe
a bit broad. Can you give an overview of how yourselves compares to your competitors like
Flurry? >>Neil Rhodes: So, we provide somewhat -- well,
we both are analytics and we provide additional features that --
>>> Google Play, that one. >>Neil Rhodes: Let me back up a second. Having
multiple choices is good for users and we are going to let users decide which they prefer.
>>> Okay. Well then the other question was more specifically about one of the features
that they have is about, you can tie parameters to events. Like when you have an event for
the levels, player has beaten a level, you can add statistics about how they did in that
level. When I last looked at Google Analytics, you could only say just an event. Is there
anything to allow to tie the extra parameters to it.
>>Nick Mihailovksi: That's a great question. We released a feature called custom variables
in the previous SDK. That's something we are looking to bring to the new SDK. If you look
at our documentation and read about custom variables, you will see they give you the
ability to add meta data around the type of stuff you want to bring, your business data
into our product. >>> That's useful.
>>> My question is about pausing the application. So when the application -- when user pauses
the app duty, say by pressing the home key, is that considered a user leaving the screen?
>>Neil Rhodes: So when the user leaves the application, for instance by going to the
home screen, that is considered leaving that screen, yes.
>>> That's considered a drop of the user? >>Neil Rhodes: So the question as to whether
that causes a new session or not is up -- we actually have a timing mechanism so that you
can specify sort of how long the user is away from the app before we consider that a new
session. >>> Is that part of the SDK?
>>Neil Rhodes: Yes. >>> Thanks.
>>> I actually have two questions. So number one is, is there a limit of number he of events
the client library will track per day? >>Nick Mihailovksi: A limit of 500 requests
per session. >>> And number two, is there a export API?
For example, if you came up with new query that, for example, Google doesn't support
right now, but you wanted to run against that data, do you have an export API to grab that
data, or not. >>Nick Mihailovksi: We do. We call it our
core reporting API. If you go to developer.android.com/Analytics, there's a lot of resources around how to use
that. >>Neil Rhodes: Just to make clear, we do not
export the raw data. We export reports. >>> Okay.
>>Neil Rhodes: So aggregated data. >>> Thank you.
>>> Question about the refer attribute or the receiver from Google Play. We had some
issues about this previously when you have various people managing campaigns, the operating
system sends one receiver value and not all the receivers. So you're in a unique place
to kind of push back on that and say it needs to be a broadcast so that more than one receiver
can get that information. >>Neil Rhodes: It's true, it is kind of clumsy
if you have multiple receivers associated with your application. I think I'm addressing
your issue. You need to write a meta receiver that then dispatches it to the others. It
is kind of clumsy. We'll take that information back to the Android team.
>>> Thanks for the presentation. The question is about the Android developer console. Right
now there are some stats there. What's the crossover between Analytics and the console
that you can see for your applications? >>Neil Rhodes: We are trying to integrate
that more. We're working on it. >>> Will it be a subset or --
>>Nick Mihailovksi: One of the stuff that Neil was talking about was deeper play integration.
Some of the metrics they are giving your there are about how people engage on the site. Analytics
gives you more in-app usage and they give you more within your listing on the actual
play product. The integration that we are looking to do is give you holistic end-to-end
measurement so you have full visibility in how to gain more people to come to your site,
how you can optimize the copy in-play and get more people to download and transact.
Neil talked about some stuff coming out looking forward a little bit. You can consider those
integrations getting deeper and deeper. >>> Great. Thank you.
>>> How easy is it to cohort analysis looking at the user engagement over time with WebKit
and things like that? >>Nick Mihailovksi: So for cohort analysis,
we do show you the total number of users and active users on the site. It's something that
we are looking at to give you the right -- to be able to segment them properly. There are
deeper things to do. Something we are still looking at.
>>> How realtime is the data? >>Nick Mihailovksi: Realtime is within a couple
seconds when you have an Internet connection. [ Laughter ]
>>Neil Rhodes: For the realtime. What we say sometimes is, at least for the web site, we
know before the user knows. So before the user sees the page, we can already know that
they have been there, which I think is interesting. >>> Is there any plan to add support for other
mobile platforms? Like Windows phone or Blackberry? >>Neil Rhodes: We are looking into other platforms,
yes. >>Nick Mihailovksi: There's a trade-off on
market share, too, so we want to go where developers are.
>>Neil Rhodes: And we are also investigating ways this which third parties could provide
that. >>> Can you explain how you define the concept
of session and time spent and how it's different from the web?
>>Neil Rhodes: So it's -- a session length consists of, when you enter the first activity
until you leave -- until you -- let's make it clear. So it's a little complicated by
the fact, of course, that on Android your application is still running even in the background,
right? So it's when you leave an activity and don't start a new activity and then stay
out for some certain period of time. I think the default is 30 seconds maybe. Although
I don't remember and that is configurable. In addition, if you've got a period of inactivity
for at least 30 minutes that, will also be considered stopping a session.
>>> So like if you're playing a long-form video, is that considered activity? Like say
if you are watching an hour-long movie. >>Neil Rhodes: As long as you are making tracking
calls at least every 30 minutes, then that will be considered the same session. But that's
a good example where you would want to explicitly make calls to -- for instance, track the event
that they are 15 minutes in, 30 minutes in, 45 minutes in, so on, so you can get some
idea. >>> Thank you.
>>> Can I label my users as a custom cohort? Does the old segmentation feature of Google
Analytics work? >>Neil Rhodes: Segmentation feature certainly
works. If you want to be labeling them in the form of custom variables, then, no, that
is not there now. >>> Another question, I think the play integration
is a killer feature, by the way, and sets you apart from Flurry. Two-part question,
one, I would love to see more data coming in Google Play, like this cohort gives me
a 30% lower rating than this other cohort. The question is, is this exposed in a way
that other SDKs could theoretically grab that data through the receiver or some other way?
>>Neil Rhodes: So the -- first off, that's very useful information about the suggestion
for the Google Play. Things like how well they rate and so on. The aggregated -- there's
a couple answers. So the aggregated information is certainly available through the export
API. The receiver information is available to any application. So you can know the campaign
that caused them to get to Google Play. The actual information from Google Play as terms
of number of views and things like that, there's no API that I know of, at least at this point,
and I don't know of any plans for one. >>> Thanks.
>>> I have two questions. One is are you planning to release the source code of the Analytics
app for Android. >>Nick Mihailovksi: Application to see your
data, probably not. We have API, and there's people who built their own frontends. But
for this one, we will probably own it ourselves. >>> Is there a way to track uninstalls with
the new feature of Google Analytics? >>Neil Rhodes: There is currently no way to
track uninstalls. That is not to say we won't have that as part of Google Play integration.
>>> Is there any support for app widgets as part of the launch?
>>Nick Mihailovksi: So we're providing the framework to do the tracking and so that's
some of the more documentation on how to use the framework to do that. We would probably
look to go do it within the next couple quarters. There will be more better support for that
type of stuff in the future. >>Neil Rhodes: But it can be used today. There's
nothing that requires you to have activities in order to do tracking. There's sort of a
lower level of just initialize the tracker and start making tracking calls. You can certainly
do that from a widget. >>Nick Mihailovksi: Just there's a guy right
here, Andrew, he is on our team, and somebody maybe you want to talk to to figure out some
of the use cases. >>> What is the minimum Android API required?
>>Neil Rhodes: That is a great question that I should know the answer to off the top of
my head. I believe it's 2.1. It's certainly no later than that. Does that work for you?
No? Okay. >>> In the XML document, you have a debug
mode and you have to differentiate something like the dispatch time. Is there a good way
to set that so, like, I have a debug application, is there a good way to differentiate? Not
just keep switching the string for the ID, string for the debug.
>>Neil Rhodes: Yeah, I can understand where that XML -- you want to be able to do programmatically,
perhaps. You can certainly do it programmatically as well. You can leave it out of your XML
file and just make a programmatic call to either turn the debugger on or off depending
on your debugger setting. >>> In app starter?
>>Neil Rhodes: Yes. All that stuff is also available programmatically. We'll take the
last question. >>> Earlier you mentioned there was a 500
limit per session. What happens after you hit that? Does it just dump off the frontend?
Does it stop recording? >>Neil Rhodes: So that limitation is actually
on the backend rather than in the SDK. And so what actually happens when you exceed 500
is undefined in practice. So but it could change, you know, in an hour. It drops everything
past the 500. >>> Thank you.
>>Neil Rhodes: I'm not lying about that, am I? Okay. Thanks very much. We certainly appreciate
it. We will be out in the hallway if you have other questions.