Behind the Code: The Google Analytics v3 Mobile SDKs Video Lecture | Google Analytics: For Developers - Data & Analytics

hi everyone welcome to this week's
edition of behind the code this week
we're talking all about the new google
analytics v3 mobile SDKs my name is
Andrew Wales I'm a on the developer
relations team for Google Analytics and
with me in studio is Jim categ no he's a
software engineer who works on our
mobile app SDKs and he's been around
since the beginning more or less I'm not
quite the beginning but pretty close
pretty close to it so he's a veteran we
working on these SDKs for a long time
and he's been behind a lot of the
changes that are in v3 so we're lucky to
have him here and we'll walk through
what's new give you some pointers about
migrating and what to look for as well
so if you go ahead and take a look at
the agenda for the show I'll give you a
quick overview on what's new then we'll
talk a little bit about get set and send
which are really at the core of the v3
SDK these three methods we'll talk a
little bit about session management and
how that works in v3 what's changed and
also what's staying the same and then
we'll take just a quick look at
e-commerce because the models changed a
little bit so we want to give you just a
quick heads up about what's new in v3
then also at the end we'll make time for
QA a lot of you posted some really great
questions to our moderator page so we'll
try to get through as many of those as
we can so let's jump right in so what's
new in v3 so there's really four main
things that are new here the first and
probably the most noticeable thing is
that the api's are now more aligned
across all the different platforms so
you'll notice that Android iOS and also
analytics jsr web our library for
written for javascript is they're all
very much similar and how you use or how
you get set and send data and we'll go
into that a little bit further I think
the second point second big thing that's
new is that there's more flexibility in
setting and sending data and we'll go
through that as well later on in the
show there's now forward compatibility
with new hit types and parameters and
we'll show you some examples of how you
can send any kind of parameter in the
via our SDKs to the
a end point and then the fourth thing is
that there are some new debugging
features notably we've added a dry run
flag so that you can enable the steering
testing so that you don't send test data
into your production reports and then
we've also replaced the debug flag with
this logger class which is actually a
little bit more flexible if you want to
learn more about the debugging features
on this go ahead and check out the
migration guide on the developer site
which is developers.google.com/live
Ock's we're not going to cover them in
today's presentation but there's a lot
of documentation there so go check it
out so let's take a closer look at the
first point API is now aligned across
web and mobile across all these
different platforms Jim can you give us
kind of an overview of sort of what the
I what the impetus was for going back
and refactoring to make things more
aligned across these different platforms
so what we wanted to do with this was to
kind of unify the way you do your
tracking calls across GA whether you use
Android or iOS platforms for mobile apps
or whether you do website so we didn't
want you to have to learn a new way of
doing things with each platform so so
well we kind of followed the Analects
j/s route with basically three methods
for your tracking needs get sentence and
that's what you see here but I think
we'll see a bunch of examples of this
later as we walk through some of some of
the later slides and also really quickly
I wanted to touch on the forward
compatibility with new hit types so how
does the v3 SDK actually enable this
kind of forward compatibility so the way
it enables it is it basically lets you
pass in any parameter name and any
parameter value through the set or San
methods and so previously in the v2 SDK
we had kind of predefined all the
parameters that were enabled for the SDK
to report you know analytics data
through the measurement protocol so we
stripped all that out so that you could
set anything you want anytime you want
and this will enable you to add new
parameters new hit types as they be
available in analytics in general cool
so with this also let you for example
could you now send like web page views
from the App sdq could you have your
flexibility to do that yes absolutely so
that's cool okay great and actually
here's just some here's an iOS code
snippet as well you can just see that
we'll talk a little bit more about the
dictionary builder and the map builder
classes later in the show but just you
can see a quick example of how you might
set or how you might send an arbitrary
parameter in v3 and also how that shows
up in the hit that's generated from it
cool so now that we've gone through an
overview of what's new let's kind of get
more into the meat of v3 and a lot of
that is going to be around using these
get set and send methods and
understanding how those work so let's
start with just a quick overview Jim can
you give us kind of like an
understanding of what the change is from
v2 because I know in v2 we had a lot of
Soviets method right right so v2 we
originally started excuse me with thumb
method calls that start with track
actually not just send so you had a
track view track event track exception
and then we change those to send to be
more you know more in line with what we
were doing but for v3 said before to try
and align with the other platforms the
other client platforms we got rid of all
those special purpose and methods and
replaced them with send so instead of
send view we have sand and then you
would pass in the map of parameters or
dictionary in iOS case that represented
your app you hit and then same with
event transaction exception etc and then
set we had we had very specific set
methods for things like setting campaign
custom dimensions custom metrics and
those are replaced by a general set
method which will take the field name in
the value and
forget this is a little bit new to the
SDKs and that you could actually query
the values of the tracker objects that
you have previously set or or will be
set for us on your behalf so pretty much
any field can be set or retrieved for
the tracker right that's correct yes
okay so let's talk i guess the start
with sin because that's probably the
command that most people are going to be
using most often how does it work
basically so send sounds very
straightforward it takes a map for the
android sdk and iOS sdk would be a
dictionary of parameters parameters have
a name and a value and they're both
treated as string so we no longer deal
with various object types like integers
or floats or Long's everything is is a
strength for the send parameter or send
method sorry and then so when you call
send what happens is the value stored in
the track are emerged with the values
provided in that map the values in the
map will take precedence over what has
previously set in the tracker and then
the hit will be queued for dispatch and
then you don't have to worry about at
that point anymore one of these one of
the cool things in v3 that I definitely
wanted to highlight for people was that
it's actually I'm pretty easy to build
these maps of parameter value pairs
right we have these Matt builder
convenience classes yes a little bit
about then yeah so because we took away
the convenience method calls on the
trackers sent event send exception we
felt the it would be very useful to
provide some way to conveniently build
various hit types so that you didn't
have to remember which parameters needed
to be filled in for each type of hit and
so the map builder class was created for
that purpose so the map builder has
create methods for each of the common
hit types and that create method
basically takes all the parameters that
you would normally set set up for that
hit so for event for example you have
category action label
and value so as an example we have like
a we were sending an event that's
somebody touches a button to play a
video for example yeah might be an
example of that right so here's a
perfect example of an event there's a
couple things to point out in this
example 1 first off the map builder
actually follows the Builder pattern so
those you are familiar with that pattern
will probably recognize this so you
create the map builder class using the
one of the create methods and then you
could optionally set new additional
parameter so here for example we're
going to set custom dimension 22 value
of watch the video and then when you're
finally done with it you can get your
map by calling build and then you're all
set and you just pass that to send and
you're done cool so you can set I mean
it's not just this examples custom
dimensions but you could set anything
else you need to before you're ready to
build let's crunch send it all at one go
that's correct yes it's cool oh and then
here's a so it's the same for iOS right
it'sit's yeah you're building
dictionaries and the classes GA I
dictionary builder yeah so we use the
Builder pattern here with iOS you don't
have maps but you have dictionaries are
very much the same we're very similar so
yes same thing go let's talk about the
set method how does that work so when
you set the set method will make a
permanent adjustment to your tracker
model so the tracker keeps track of all
the parameters and their values that
you've set it's persisted and it all
stay in the tracker until you get rid of
it really so develop so that way if you
have certain fields that you don't want
to set that you want to be set or on
every hit and but you don't want to you
know set it in the map builder every
time you can simply just call set
examples the value is going to be going
to be persistent tracker it'll show up
in every hit unless the map you pass
into your send call overrides the value
right because they don't take precedence
over what set of the jacket and if you
don't want to set that value anymore
what you can do is pass null or nilma I
OS case as the value and that field will
get cleared out effectively ok cool I
think it's an important thing to point
out that when you set something on the
tracker it's going to that value is
going to persist sort of indefinitely
until you destroy that tracker until you
override that value what's right is
right so I think I know we were talking
about before this like there are
definitely some good places where you'd
want to set certain values directly on
the tracker that are going to be applied
to a lot of hits so one of the examples
that I know we talked about was for
example here if you whenever a view or a
screen gets loaded it's convenient to
set the screen name first and then you
can send all your hits after that so in
this example we set the screen name
field to home screen when the view loads
and then we're going to send an appt
view and we're going to send to a Senate
event and both of those hits are going
to contain that screen name I only had
to set it once that's right and this is
very important just like in the web case
if you want your events to be tied to a
particular screen right this is how you
have to do it otherwise your events will
not be attributed to that to your
particular screen rania or I know some
other good examples were setting
settings like anonymize IP or setting a
sample rate because those are tracker
level settings right right so when you
set those you probably want them to stay
set yeah duration of your tracker right
and so that those are good candidates
for set call set call in the tracker
yeah and then there are some bad places
to you this way places um basically when
you when you use this to set fields that
you really are only going to send once I
think that's probably what most people
would run into trouble yeah that's
correct so I know the example we talked
about was an event action so if you have
some kind of handler
and you happen to set an event action or
any of these like event fields those are
really only going to be a platen those
should only be applied to that one event
but if you set them right and then send
other events if you don't provide values
you could well basically going to end up
setting those event fields with every
hit which is probably not what you want
right yeah so this is a bad example of
what you would use the track or set
method for rights and then another
mistake I know I'm made once he pointed
out earlier was and we'll talk about the
session control field a little bit later
but that would be one you have this
ability to start or stop a session by
setting this field and if you set that
field directly on the tracker you're
going to be starting a new session with
every hit yeah what you do not want
disasters right and I made that Masood
not like that please don't make that
mistake cool okay so lastly we talked
about send set and then the last ones
get so the tracker is a model and you
could use it to retain values of the
various parameters that you want to send
to google analytics so a get method lets
you query those those values that you
said previously so I guess the other
thing point to bring up here is that if
you haven't the tracker has this concept
of what we call default values for
certain fields so there's some fields
that you really want to always set in
the application world things like the
application name the application version
the client ID is another good example so
we'll pre fulfill those in for you if
you don't set them using the set method
or pass them through through the map in
the send call and so if you call get on
those particular fields will give you
the value we will provide if if you
haven't set the value so right so for
example if you want to if you're curious
to know what application name we're
going to send with each hit call get on
the application name field got it and
you'll see it so what about a field that
doesn't automatically get set like if
you called get on like campaign source
is it an empty string yeah it'll be I
believe null no ok so I know yes or nil
on the iOS kiss correct and we so we
should definitely get a list of those
default values will make sure to get
that on dev sex I think right now it's
not there yeah but we like to see that
get posted oh the final note here is
client I know several folks using the
SDK best for us to expose the client ID
that we send and we've done that with
the v3 SDK there's one very important
caveat here is all these calls are non
blocking calls except for when you call
get to get the client ID you may block
so especially early in the life cycle
the application so you won't want to
make this call in your initialization
code on the main UI thread exactly block
because it's reading from this guess
because it's reading the client ID is
persisted on the persistence store on
the device and it takes a little time to
read up and then lastly so I think
throughout as you call these different
methods you're going to be providing
fields pretty much with every call so I
thought it deserved maybe just decide to
talk about what these like how you
access these fields and so yeah yeah ok
so we provided some classes that to find
constants for the for all the fields
that you would commonly use in the
application tracking world and they're
in the fields java class there's some
examples there on the slide in iOS is a
ga I fields header file we've also
provided convenience methods for
creating parameter field names for
custom dimensions and metrics as you
know those are repeated fields they work
like index so you have custom dimension
one custom dimension 2 etc etc so we
have some convenience methods that will
build the parameter name for you so you
don't have to figure it out for yourself
and then the last one is sort of what we
talked about earlier where you can use
this like ampersand syntax to get setter
send any parameters right yeah so
the tracker understands the ampersand
syntax and so basically if you look at
your measurement protocol all the all
that the parameters there can be can be
set using the ampersand and this
ampersand t for example would be the
hittite for a head side right so this
would be like an example for a new hit
type that we release in the future but
you could send as you said any
measurement protocol parameter this way
let's talk about what's new in session
management in v3 and also what's the
same because some things I know I've
changed and some things are the same so
Jim when you walk us through everything
we need to know really about session
management and ether I don't know if
it's going to be everything well
hopefully hopefully will clear the air a
little bit about sessions share ok so in
Universal analytics there was a change
this is like outside the realm of the
app SDKs but session management moved
from the clients to the backend so the
backend for universal analytics which
includes the v2 SDK in the v3 SDK the
session management is handled by the
backend and the way it does that is it
looks for a gap in time from one hit to
the next and when that gap is large
enough it will declare the end of
session and start a new session so the
default value was 30 minutes initially
and that default value is now
configurable through the management you
I I'm the Google Analytics website and
if you look at the slide you'll see a
screenshot of what the page looks like
that lets you control the session
timeout session time was count on the
upper right of the picture there yeah
and then campaign time is there as well
yeah campaign timeouts there as well
correct yeah ok so in the v2 SDK in
order to get around that 30-minute
window which was the only window that
the backend would support initially we
decided to add support in the SDKs for
controlling sessions and we did that
through a basically a property or flag
session control behind the scenes with
that flag did was
and a parameter called session control
our ampersand SC is the name and it
would send a start when it felt a new
session should begin and what it did is
it way we did it in v2 is we just
decided that if the app was sitting in
the background for any for certain
length of time I think the default was
30 seconds we would set that parameter
up and say hey we hit we need a new
session we implemented that an easy
track on the Android and in the GA I
tracker class that was returned to you
when you asked for one on iOS the other
the other thing to note here is that
when the trackers were first created in
both iOS and Android we would also set
that session control parameter to start
and send it with the first hit that's
how it worked in v2 this was all to give
you a finer control than that 30-minute
window which is what initially was the
only way you could break sessions in the
back end right right so given now that
you can parameterize you can control
that window to a great degree with the
UI management you I in the application
that analytics application we decided to
kind of step back from it in v3 and
clean things up if you want to flip over
next trick sure so in Android and feith
in v3 for Android the tracker class is
no longer going to set the session
control parameter to start ever for you
you can do it yourself it's just just
another parameter you can again don't
use the set command but you can set it
through the send command in the map
builder easy tracker kind of a side
point for the easy tracker now extends
tracker so you can treat easy tracker
just like your tracker calling good set
and sand and the easy tracker for
Android will continue to manage sessions
as it did in v2 okay so there's still a
parameter to that you can control that
will determine how long the appt sits in
the background before a session control
flag start but go ahead yeah that's
gonna say so for for people who are
using easy
on Android and v2 right now to handle
session management for them there's
probably no noticeable change in v3 so
the one noticeable changes when they
first start I know I guess you're right
so when the easy tracker first starts it
will assume a new session because the
time whatever time period you put in
there will have expired basic I see yes
oh yeah but for those people who are not
using easy tracker in v3 they should
note especially this top point that the
tracker class will no longer set session
control flag to start when the tracker
is created that's correct a very
important point and if you know if
you're not aware that you might be able
to a little bit concerned because your
session numbers won't quite look the
same well look the same as between B 3
and B 2 yeah for iOS again as part of
this alignment we wanted to make all the
SDKs behave the same and so we removed
the session management code which was in
the ga I tracker class from iOS and
again like in Android we no longer set
the session control parameter to start
when the trekkers first created if you
need me if you need to do this manually
which might be a good idea you can look
at hooking up to the notifications UI
application did become active and will
resign active and what you would do
there's did become active you would look
to see if a certain length of time had
passed which you would set up using the
will resign active notification and call
back and then you can decide to set
session the session control parameter to
start or not on the next hit based on on
the values am there for Android users
who are not using easy tracker but they
do want the session control flag to get
set to start when the app launches for
example is the way would one way to do
that beat a subclass application and
Android and do it in them remember
remember you don't want to call set on
the traffic right sorry it's not so set
it on the tracking but you might want to
set it on a screen view map
right right so yeah so your map that you
passed in wouldn't have it set right or
not so let's take a quick look at what's
new with e-commerce in version 3 of the
SDKs it's actually a pretty small change
basically you need to whereas before you
would basically send your transaction
object in one hit you would kind of
create this transaction object and then
add items and then send it all in one
hit in v3 there's actually separate you
need to make separate send calls for
each transaction and item so the syntax
is very much the same as sending a pues
or events in v3 so the easiest way to do
it is to use map builder and then you'd
call create transaction add everything
all the details there build it send it
and then do the same thing for your
items all of them one thing that you
know as always make sure that the
transaction ID in each item matches up
to the transaction ID that you used in
the transaction hit but other than that
all the fields are the same it's just
that you need to make make sure that
you're calling send for the transaction
and then also call send individually for
each item okay cool so let's let's take
some of your questions so the first one
Jim can you please explain the
relationship between sessions session
duration and how active users are
determined it's kind of a big question
is only exists it's it's a universal
analytics question yeah but I guess I'll
take a stab at kind of explaining a
little bit and hopefully maybe we can
get some updates on the web the web site
that really kind of goes in this and
depths them but so a session is
basically a set of interactions a user
has with your application that can be
considered like a single visit to the
application so and those sessions will
be made up of one or more what we call
hits or beacons in analytics the session
duration is measured more or less from
the time that passes between the first
hit as sent or is generated and the last
hit is generated
and then active users are basically the
number of users who send one or more
sessions during the particular reporting
period in question so that's kind of so
accessible answer if session duration is
what would happen in the session with
one so you said that we kind of to get
the duration we look at the first hit in
the last hit to get the duration but
what happens if there's only one hit in
the session well then iteration is going
to be zero it's set to zero okay so if
you have a lot of sessions that are
looking like they're zero seconds or
length that's what that might be what's
going on okay cool the next question
could calls especially event calls be
batched at dispatch time in one single
request we're looking at doing something
like that yes okay so I can't give you
any sort of commitment as to when or how
but yeah let's been on our mind for a
while cool so maybe coming soon next
question is there a way to keep
real-time analytics while using a sample
rate of less than a hundred percent well
so real-time analytics takes the same
data that you send to the website for
the reports and just gives it to a lot
more quick quickly than you would get it
otherwise so your real-time analytics
data should be very much the same as
your report data so you know as long as
you have a large enough sample your
sample rates less than one hundred
percent I think real time can still be
useful right obviously you're going to
have to scale the numbers in your head
or whatever so we report the raw numbers
we don't report the sample numbers so
for example if you see ten in your
sample rate is 10 you could reasonably
infer that you have 100 users / grab at
that time right so basically the sample
rate is going to just limit the number
of hits that gets sent from the client
but the real time reporting it isn't
going to it's not connect I mean it'll
show all the hits that right but if your
sample rate is fifty percent you're only
going to see one hit in real time
instead of two it's the other important
thing to point out here is that the
sample rate actually is based on the
visitor so a particular user or visitor
to your app
will either report all their
interactions or none of them so it's not
like you'll see like half the events
this user's generated you'll see them
all if the user is going to report based
on the sample rate cool so I have
another question here about the new
combined google analytics services SDK
so with v3 we're sort of giving you
analytics but also Google tag manager
together so the question here is will
there will also be an SDK version
without Google tag manager and they're
concerned about the size of that
combined SDK so so Google tag manager
cool google analytics are like one
product or just two different ways of
doing things so we're not going to have
a separate SDK at this point any so
they're always the SDK going forward
will always include both Google tag
manager google analytics I wouldn't
worry too much about the size if you're
doing development in iOS for example the
Xcode will strip out all the code that's
not that you don't use so your actual
final binary will be smaller than you
would expect and if you're using
something I proguard on Android you'll
get the same benefit so even though the
SDKs are larger the code that you your
app code shouldn't get larger as a
result should be based as matter fact
the iOS SDK for example the b3 version
was actually smaller than the b2 version
okay even with the Google tag manager
merge so then then results actually
better for you go all right so uh Jim
any idea on when real-time events will
be added to app properties that's
another one say yes we want to do that
we're working on it I cannot give you
any sort of commitment as to time so
baby is coming soon maybe I think we got
time for maybe one more this is this is
a good one Jim this is a plea to you can
you stop changing function names every
two months we'll try our best yes I do
apologize for for the fast-paced changes
that we're going through in the last
but I'm hopeful cross our fingers here
hopeful this is the last time we changed
names method names like this so and now
at least when you're moving from one
library to another for example if you go
from Android to the web you should see
more consistency yes how to use each and
even even android/ios are more
consistent now than they were before
ghost awesome cool so that brings us to
the end of this edition of behind the
code I wanted to pass on some resources
to everybody watching so we have getting
started guides for the v3 SDKs for both
Android and iOS there's a link there
it's basically
developers.google.com/live Ock's we also
have migration guides and these guides
cover migrating from v2 to v3 or even V
1 to V 3 so go check that out we have a
mobile app analytics forum and there's a
link here there's a lot of good
questions and answers on there I know
Jim's an active participant in that
forum from time to time so it was a lot
of good insight there and there is a
also if you're willing to send
measurement protocol parameters in these
SDKs so we showed you how to do that
using that ampersand syntax we do have a
whole parameter reference that shows you
all the different protocol parameters so
you can go check that out as well and
with that thank you so much for joining
us that brings us to the end of the show
feel free to reach out to us on google+
and we'll catch you next time