Google I/O 2013 – Optimize Web and Mobile Apps, Across Devices, Using Google Analytics

By | November 15, 2019


NICK MIHAILOVSKI: All right. How’s it going everybody? My name is Nick Mihailovski. I’m here with Andrew Wales
and Pete Frisella. We’re on the Google Analytics
developer relations team. Today we’re really excited to
talk to you about cross-device optimization using
Google Analytics. We changed the title last
minute, so don’t worry, you guys are in the right
presentation. We have an awesome presentation
for you today. Today we’re going to talk
about three big things. We’re going to talk about how
you can measure beyond the web and app with Google Analytics. We have an amazing presentation
about how you can optimize experiences
across devices. And finally, we’re going to tie
this all together with how you can measure online and
offline experiences together, all using Google Analytics. So let’s begin. Today we’re in the middle of a once-in-a-lifetime technology explosion. Wow. Take a look at Saint
Peter’s Square. Take a look at the
scene in 2005. There’s one person
on a cellphone. I think it’s a flip phone. Like, who uses a flip
phone today? Now fast forward to 2013. There’s a million devices, many
different devices that people are using. What’s amazing is that these
devices are different. We see tablets, we
see smartphones. In fact, at the end of the day,
people are using more devices than ever before. And our data shows that, within
the United States, 90% of users have three
or more devices. So I want to take a
quick poll here. Raise your hand if you
have, personally, three or more devices. That’s a huge amount
of people. Now keep your hand up. I want to see who has the
highest number of devices. Keep your hand up if
you have 4 devices. 5 devices. 6. 7. 8. Wow. 9? 10? 11? 12? PETE FRISELLA: Go by fives. NICK MIHAILOVSKI: Maybe 15? 20 devices. Seeing two people,
a couple people. 25 devices? Wow. You guys definitely
are all winners. Come by our booth after this. We’ll give you a cool little
Google Analytics Android box. The fact of the matter is, as
you saw, everybody’s using many devices. So something else magical
happened in 2005. Can anybody guess what it is? That was the year we launched
Google Analytics. And so when we launched Google
Analytics, we built a piece of tracking code for the
web that included a lot of client logic. And that data got sent to
Google Analytics using something we call the utm.gif. A couple years later,
we launched V1 of our application tracking. What we had to do, is we had to
port all that client logic and the complexity into Java
and into Objective-C to support our Android
and iOS SDKs. As we look to the future, what
we really want to do is support measuring users
across any devices. And so, because it was so
complex to port our code, we completely rewrote our
infrastructure for collection. And we released something
what we call the measurement protocol. And we released this maybe
a couple months ago. And the measurement protocol is
an easy to use way to send data to Google Analytics
from any devices. So all of a sudden, you now
have a way to measure interactions with game consoles,
set-top TV box, even point of sale system, pretty
much any sort of places where you have user interactions. So let me quickly explain to
you how the measurement protocol works. But before we get into that, we
really need to understand the Google Analytics
data model and what we’re trying to represent. At its core, Google Analytics
represents how users interact with content. For example, this lovely
lady here is buying flowers for her boyfriend. In this scenario, the
user is the lady. And viewing the product page for
flowers is the interaction that we’d want to track. So to measure this interaction
with Google Analytics, there’s three pieces of information
we need. One is we need to identify the
tracking ID which defines the Google Analytics account
you have. Two, you would need to identify
what we call the Client ID, and this represents
an anonymous user. We represent it with
the cid value. And finally, we need to
represent the interaction. We represent it with what
we call the Hit Type. Within Google Analytics
there’s many different Hit Types. There’s page views, events,
transactions, items, so forth. So these three values map
into a request to the measurement protocol. The protocol is actually
an HTTP request. To this end point,
google-analytics.com/collect. You send a Get Request. You specify version. And then you have the
three values. You have the tid, which
is your UA number. You have the cid, which is
the anonymous User ID. You have the Hit Type, in
this case is a pageview. And finally is flowers. It’s that easy. And to send this data, if I go
back into this screen here, in the back here I have Google
Analytics real time report. So all I need to do is grab
this URL, open a browser window, hit Enter– hopefully, if everything
works, boom. We see the data directly
in real time reports. That’s how easy it is to send
data to Google Analytics. Now, the user interaction
model is super flexible. And the measurement protocol
is really easy to use. So you can take this model and
apply it to many different scenarios that might not even
have to do with websites. For example, here’s my Google
employee badge. Inside of it is an RFID chip,
and on the chip has my employee ID. That represents the user. Now, here I have
an RFID reader. And the reader’s hooked up to
Google Analytics, through this little app here. So when I scan my badge
over the reader– with any luck– Boom. I see the data directly
in real time reports. Now, what’s even more amazing
about sending data from any device, what’s really
cool about this– let me just go back to my
presentation here– what’s really exciting is that
demo only took five lines of shell script. That’s how easy it
was to send. So now anybody can send
data to Google Analytics from any device. All right. Enough fun and games. Let’s look at a real
world application. In fact, let’s take a look at
how the Chrome Dev Rel team at Google uses the measurement
protocol to measure their app, Yeoman. So what is Yeoman? Yeoman was inspired
by Ruby on Rails. And the Rails framework makes it
really easy, with a command line script, to add a couple
commands and get an entire Ruby web application. So the Chrome Dev Rel team,
because of the plethora in growth of all these different
JavaScript frameworks, wanted to provide a simple command line
tool so developers can write a couple commands and
they could build all this structure of framework of their
modern web applications. So here’s the screen
shot of the tool. And what the developer relations
team wanted to understand was how many people
are actually using this tool. So when they started looking
at the problem, the first question that came to mind– you
know, the first thought– they were like, yeah, we’ll
use App Engine. App Engine’s powerful. It’s easy. It gives us all the power. But when they started looking
at the problem of what they had to solve, they had to write collection to collect logs. They had to write some
asynchronous tasks to process those logs into reports. They had to build a front end
to display all the reports, and potentially even get into
some visualizations to make it all look pretty. Now, that’s a lot of work. And when we showed them the
measurement protocol, it was very easy to see why using
Google Analytics in the protocol would save
them so much time and be so much easier. So they implemented the
measurement protocol in this application. And when users actually use the
app for the first time, they’re prompted with a simple
little opt-in to collect anonymous data to Google. When the user approves that,
we create a random ID that gets stored on disk. And that’s what we use
for the Client ID. Now, every command that the user
uses is actually sent as an event to Google Analytics. So all of a sudden, they can
log into the report and see exactly how many people
are using their app. And this is huge. This is huge because they’re not
tracking installs, they’re tracking active users using the
unique visitors metric. In fact, this is one of the most
popular things they use during performance review time
because they can actually quantify the impact their team
has on growing the adoption of this product. What’s nice about this is Google
has a lot of features out of the box, Google
Analytics does. And so one of the business
questions that they have is, what is the actual impact of
their outreach efforts? And so the team actually goes
around the globe, speaks at many events like I/O. One of the
events is called G-Kenya, and it’s actually part of our
Africa outreach event. And at one of those events
they talked the Yeoman product, and so they
were curious. Like, what was the last amount
of people who actually used the product? And here, directly in analytics,
they can now tell whether that event
was effective. Effectively, they’re using
Google Analytics to tell people that they should travel
around the world. It’s pretty amazing. And finally, they’re using
analytics to show what are the actual applications people
are using and frameworks. And this is great, because when
they started looking at their development cycle and
saying, where should I focus my time and effort, they could
see what were the top languages people used and then
incorporate these as the default setting, so people
don’t actually have to download them independently. So the measurement protocol with
Google Analytics gives the developers of any
application the ability to measure how users use
their application. With that, I want to turn it
to Andrew to talk about cross-device optimization. ANDREW WALES: Awesome. Thanks, Nick. So Nick just showed you how you
can send data to Google Analytics from pretty much any
connected environment really easily, using the measurement
protocol. And that’s really awesome. In this next section, I want to
show you some things we’re working on to make it easier
for you to actually analyze that data and to build better
cross-device experiences for your users. So I want to start
with User ID. Now, you saw in Nick’s demo,
when he was sending those hits with the measurement protocol,
he was using a field called the Client ID, or cid. And this has been around in
Google Analytics for a while. Basically, it’s an anonymous
ID that represents a single user on a single
client device. So if I’m using your web app on
my smartphone, I have one Client ID that represents
me using that phone in GA, Google Analytics. Now, if I access your site on
a desktop, I’m going to get another Client ID, a unique
one, that GA’s going to use as well. And this is going
to keep going. So if I use your web app on five
different devices, I have as many as five different
unique Client IDs in GA. Now, this can be fine if you
want to do analysis of my experience with your
app on one device. So if you want to say,
OK, how’s Andrew using my app on a desktop? That’s fine. No problem. You can definitely do that. Where it gets tricky, and where
we run up against a little bit of a barrier, is
when you start asking questions about, how is Andrew
using my product across all these different devices? For example, how many devices
in total do I use to access your app? How much revenue do I generate
across all of my devices for you? This is where Client ID starts
to feel a little bit like some walls that we run up against
in analytics today. So we’re introducing a brand
new ID called User ID. And the difference here is
that User ID is going to represent a single user across
all of their devices. And with that User ID, we can
start to break down those walls and start to answer some
of these really cool cross-device questions. Let me show you a really simple
example of how this is going to improve GA reporting. So let’s say Pete’s using my
web app on his smartphone. And you can see here, GA
has generated for him a unique Client ID. And in my reports, he’s
considered one unique visitor. Now this is fine. All’s well and good, until Pete
decides he wants to go get himself a tablet. Good for Pete. But bad for me. Because now, when he uses
my app, he’s got a new Client ID, right? It’s unique. And GA is saying, great, now
I’ve got two unique users. Well, I know there’s actually
only one Pete. He’s irreplaceable. But he’s using two devices. And as this continues on, he
gets more and more devices, he shows up as more and more unique
visitors on my reports. This gets to be a problem,
because I actually only have one user, but here it’s
saying I have three. So let’s do this again
using User ID. So now Pete’s using my app
on his smartphone. And when he signs in– because
this is actually a signed-in experience. When he signs in, I’m going to
take his User ID from my auth system and I’m going
to send it to GA in this new uid field. And I’m going to do the very
same thing when he does this on his tablet, and when he
does it on his laptop. And you can see, as he keeps
accessing my app, the number of unique visitors
stays the same. Because GA now understands this
is one user with three different devices. So User ID. It’s going to enable
cross-device reporting. It’s really best for signed-in
experiences. So where you have an auth system
that has an ID that’s stable that represents a
particular user across all these different devices. And that ID has to be
non-personally-identifiable. And this is really important. Because you can’t send
personally-identifiable data to Google Analytics. So please, for example, don’t
use my Social Security number and send it into GA. That is not a good idea. Don’t do it. It’s really easy to
actually do this. So this is an example of using
our analytics.js library, which is our new JavaScript
library that’s built on top of the measurement protocol. And mostly we’ve kind of
abstracted out the complexities of auth. But most of the work in GA is
being done with just this one line, this set API where you
can just say, if you have a User ID, if somebody’s signed
in, you can get it and set it to this uid parameter. And now when you send this page
view, it’s going to send that uid along with it. It’s pretty straightforward. So you see now it’s really easy
now to send data from any connected environment using
the measurement protocol. And I just showed you how you
can use User ID to have this idea, this notion,
representation of a user across all their different
devices. Now I want to show you some new
reports we’re working on to help you actually analyze all
this data and to do some pretty cool optimizations. I want to show you
three reports. The first is the Device
Overlap report. Second is the Device
Paths report. And the third is the Acquisition
Source report. So I’m going to start with the
Device Overlap report. And this is brand
new, by the way. It’s a sneak peak. We’ve never shown it before, so
I’m very excited to show it to you today. So the Device Overlap report is
all about allowing you to segment users and outcomes like
conversions, revenue, by different device combinations. So let me show you
what I mean. So suppose Nick is using my
app on his tablet, then he moves to the desktop and he uses
my app there as well, and he actually does an in-app
purchase for $3.99 This is great. Great for me. If you did this without using
User ID and you looked in GA before these new cross-device
reports, you might see something like this where you
see Nick represented as two unique visitors. And if somebody asks you, well,
what’s the value of tablet here in this
interaction? You look at this report and it’s
really hard to figure out what the value was. You would be totally reasonable
in saying, eh, tablet really doesn’t have
much value here. We should get more desktop
users, right? Because that guy spent $3.99. It’s actually the same person,
but we can’t tell that. So you’re missing a little
bit of the picture there. Now let’s do this again with
User ID and cross-device measurement. It’s actually Pete. So Pete’s actually signed
in now, and I’m sending Pete’s User ID. Now with the new Device Overlap
report, look at the difference. We’re able to say, you actually
had just one user. They used a combination of
desktop and tablet, which is actually what happened. And that combination of desktop
and tablet led to $3.99 in revenue. So if somebody asks you, what’s
the value of tablet, you can say, well,
this is great. Actually, in combination
with desktop, it produced $3.99 in revenue. So that’s the Device
Overlap report. Allows you to segment users
and outcomes by device combinations. Next, I’m going to show you
the Device Paths report. This report’s all about
segmenting users and outcomes by device paths. So not overlap this
time, but paths. So let me show you
what that means. So I just showed you how you
can now use combinations of devices as segments, right? So we were able to see
that Pete used both desktop and tablet. That’s pretty cool. Wouldn’t it also be cool if you
could segment by paths? So not just the fact that Pete
used both together, but that he moved from one to another
in a specific order. And what could you
learn from that? So that’s the Device
Paths report. This is brand new. We’ve really never had
anything quite like this in GA before. And what you’ll see here on
the left, this is the sequencer view. You’ll see all the top paths
users are taking across different device types. And then on the right side,
you’ll see all their engagement metrics, including
outcomes like revenue, transactions, et cetera. Now, one of my favorite
features– oops. Let me back up. One of my favorite features
about this report– so I’m really interested
in revenue, right? As probably most people
are who have apps that are out there. I’m really interested in the
paths that actually lead up to transactions because I want to
try to maximize the number of people I can drive through those
most profitable paths. So using the sequencer options,
I can say, just show me all the paths that led
up to a transaction. I’m just interested in those. And actually, here I’m only
going to see the last two. So when we do that, this
is what we get. And look at that third
row there. This is actually pretty cool. Because we can see that this
specific path, when people move from desktop to tablet,
this is ridiculously profitable for me. Look at that revenue, the
number of transactions. This is really awesome. One of the things I might do
after looking at this is to create a promo on the desktop
that says, hey, if you have a tablet, come check us
out on the tablet. Because I know when people move
from desktop to tablet, they’re more likely
to purchase. And when they do purchase,
they purchase a lot more. Just one example of the insights
you can pull out of the Device Paths report. And again, this is all about
segmenting users and outcomes by device paths, not
combinations. One last report I want
to show you is the Acquisition Source report. This report’s about
getting true acquisition value by device. And once again, this has really
never been possible in GA before today. So let me run through
another scenario. So Nick’s using my app. I only have two users,
Nick and Pete. Hopefully some of you,
maybe later. So this app’s being
used by Nick. He makes a $0.99 purchase. Then he uses my app on a tablet
and he makes a $2.99 in-app purchase. It’s fantastic. And he loves this so much that
he actually makes a $14.99 in-app purchase on
the desktop. This is great. Now, if we looked at this in GA
today, without using User ID, without using any of the new
cross-device reports, we might get a report that looks
like this, right? We have three unique visitors. They’re split across desktop,
tablet, and mobile. And if somebody were to ask
you, well, what’s the acquisition value of tablet? Or, sorry– of mobile. You’d look at this report and
you’d say, well, we acquired one user for mobile and they
made a $0.99 purchase, right? So it’s not nothing,
but it’s not a lot. And you might actually
say, well, desktop generated $14.99. So maybe that’s the better
acquisition channel, right? Maybe we should try to get
people coming through on desktop instead of mobile. Let’s do this again using
User ID and the new cross-device reports. So here’s the same
interaction. Now Nick is signing in, so I’m
sending his User ID to GA. And here’s what we
get with the new Acquisition Source report. We’re able to see that there
was just one user, that we acquired them through mobile. And here’s the really cool part,
we can see that on the originating touch point, which
was that original mobile phone, we generated
$0.99 in revenue. But the really awesome thing is,
now we can see, because we have User ID that’s tying all
this together, we can see on all these other touch points,
all these other devices, Nick actually spent $17.98
more, incremental. So now when somebody asks you,
well, what’s the acquisition value of mobile, you can say,
well, it’s $0.99, but then they went off and spent $18. This is actually a really great
acquisition channel. You’d have the exact opposite
conclusion. This actually does work. It’s just that you couldn’t
really see it before. But now with User ID,
and the Acquisition Source report, you can. So Acquisition Source. Get true acquisition
value by device. So just to summarize what
I’ve covered so far. User ID, it enables cross-device
measurement in Google Analytics. It should be
non-personally-identifiable. And I’ll say that again. Non-personally-identifiable. And right now it’s in a limited
pilot, and we’ll have more details about when
it’s coming to you guys pretty soon. I also showed you three new
cross-device reports. And these are going to enable
cross-device analysis, and they’re all built on top
of using User ID. And these reports are coming
soon, and we’re going to have some more information for
you soon about when you can expect those. Cool. So now I want to pass
it off to Pete. He’s going to talk a
little bit about measuring online to offline. PETE FRISELLA: Great. Thanks, Andrew. All right. So Nick gave us some really
cool demos with the measurement protocol. And you can do some really
awesome things with the measurement protocol. It’s pretty exciting. Andrew introduced User ID,
which allows us to do the cross-device measurement. So I’m going to take a look now,
let’s put these things together and see how we can use
that to actually combine online with offline
measurement. So why is online and offline
measurement important? Like, why do we care? Well, if you think about the
way people interact and the way users interact with your
business or your services these days, a lot of times
they’ll start the online interaction, and then actually
conclude in the offline world. So maybe they will do some
research online, look at a product they really enjoy, and
then visit the store and make the purchase there. So when we think about a lot
of these situations like in retail where this happens, how
to get those two to connect and how do we find that path
from the online campaign all the way through to that
final purchase? All right. So this is important. And it’s not just for retail. There’s things like, maybe
someone purchases a ticket online and then they visit the
event, the venue, and they use the ticket there. Or perhaps they purchase
something and then return it and come back again. So these offline and online
interactions are taking place all the time, right? So from a customer perspective,
you want to know that particular path. So when we think about the
measurement problem and why this is important, and how it
looks today, this is a very basic and simple report. But it tells a story. If you were to ask somebody,
based on what you see here, what’s the outcome or what do
you think happened for this particular set of campaigns, I
think the likely conclusion would be, well, they all seem
to perform reasonably well, but they’re all kind
of the same. They’re all generated around
$25,000 or so in revenue. So if you were to follow up and
ask, OK, well, is there any particular campaign we
should probably pay more attention to? Maybe one that we want
to optimize or spend more money on? It would really be difficult
to find this, to determine this. But we just talked about how a
lot of times you have online interactions that end up
concluding offline. So we know that data’s out
there and it exists. So we probably want to make
decisions for that complete story, and not just
this online story. So in that sense, what you
really want is probably something that looks like this,
where you have your offline and your online revenue
together in one place. And now you have a completely
different story, right? If you ask those same questions
again, what do you think happened here, what
campaigns perform really well, now you see there’s something
that happened here that wasn’t apparent before. It’s that one of your campaigns
generated a large amount of offline revenue. And now you can say, well,
what should we spend more time on? And the answer is a lot
more clear now. We should probably look at
the newsletter in May. I don’t know what we did there,
but something generated a lot of offline
revenue, right? So this makes a lot
of sense, right? We want to know these two
combined to give us some good optimization possibilities and
what the actual paths that people are taking from
online to offline. Everybody kind of gets this
and understands this. But we really want to be able
to have this data in GA. So let’s look at
how we do this. How do we actually implement
something like this using what we know about measurement
protocol and the Client and User ID? So the first thing we want to
do is step back and think about the User ID and this
Client ID concept. So which one should you use to
implement online to offline? There’s two things
to think about. The first thing is, do you
have a consistent way to identify the user? And this goes back to what
Andrew was talking about the User ID, right? So if you do have a consistent
way to identify users, maybe through a sign on or an
auth system, then you want to use User ID. So when that’s available, use
User ID, and that’s going to be a stable ID that you
have and provide. So it could be an auth system,
it could be like a loyalty card or something. It’s just a way to identify
that user. If you don’t have that, then
you can still do this. You just want to use
the Client ID. And we have a mechanism that
allows you to extract that Client ID that we’ve set for you
through Google Analytics. OK. So now we understand maybe
which ones we should use. Let’s look at how we’d actually
implement this on a real-life scenario
using User ID. So the scenario is, we have a
retail store, Daily Deals. And there’s an online
component in this offline purchase. So typically, you’d see
something like, a user visits a site, they would sign on and
when they do that we would know what user this is. Like, who does this belong
to, this account? We’d have that information. So we have a User ID. Maybe browse the site a little
bit, look around to see what they enjoy. Maybe there’s a new deal that
they really want to take advantage of, so they’ll
print off a coupon. And this is your online
component now. They’ve completed that, and now
they’re going to the store with the coupon. So from the in-store purchase it
looks something like this. Visitor visits the store
with their coupon. And now that they have the
coupon, we actually know that it belongs to Andrew because he
printed it off and we know which coupon this was printed
off for which user. And he uses that coupon
to make a purchase. And finally the transaction
concludes and we have the complete cycle from online
to offline interactions. This is what we all know
what happens today. But how do we apply GA to this
scenario to get that report where we see those two,
online and offline revenue, come together? Well, the first thing you want
to do is enable online management with the User ID. This is the important part. When you send in hits to Google
Analytics, you want to make sure that you set the User
ID, this stable ID that you have, because you have an
auth system and you have signed in, right? The second thing you want to do
is, in the in-store side of things, from the point of sale,
because we have the measurement protocol, now you
can send hits from pretty much anywhere, including point
of sale systems. So at that point, what you
want to do is send the transaction to Google Analytics,
you want to make sure you set the user ID
in that situation. And the thing that’s maybe not
100% obvious, but is important here, is what the coupon
actually accomplishes. The coupon is what
actually ties these two things together. It allows us to encode the User
ID into the coupon, for example, which we then
can extract in the in-store purchase. So this actually makes
the connection. So let’s look at number one, the
step where we want to do online measurement
with the ID. You’ve seen this before,
it’s the same as what Andrew showed you. Because you have an auth system,
you want to get the User ID, and you want to set
it when you send hits to Google Analytics. The second step is the
in-store purchase. So again, we have the
measurement protocol. At that time, we want to make
sure we set the User ID to the same ID that we had from the
online coupon when they printed that, and we want to
send the transaction value when it actually takes place. So this will actually tie the
offline purchase back to that online interaction,
and going back all the way to the campaign. So that was retail, but it’s
just not retail, right? You can use this for a lot
of different things. If you have a loyalty card, that
gives you a nice, stable ID that you can use for these
different channels. Memberships, tickets, all these
things you can encode these User IDs into, and then
at the time of redemption or the offline interaction, you can
get that User ID back out and pass it along to
GA with the hit. So that was User ID. Let’s look at Client ID. So maybe you don’t have an auth
system or you don’t have a way to get a stable ID across
different channels. We do have the Client ID. That’s the ID that’s generated
by Google Analytics. So if we look at this scenario,
it’s kind of a test drive scenario where you’re
interested in a car and you want to book a test drive, or
you want some more information about the car. So the same scenario. You have an anonymous ID user
that comes to the site. They might do a little bit of
research about the car and what they’re looking for. It might not be there. And they’ll fill out a form,
and that form will get submitted to a CRM system, so
a Customer Relationship Management system, and within
there it’ll generate a lead. So that’s the online component
of this scenario. Then you have the
car salesman. And this guy, looks very
familiar to Nick, comes along and he grabs that lead out
of the CRM system. And he calls up the customer. And he talks to him. And he’s really good at what he
does, so he convinces the guy to book a test drive. That’s all he does. All he does is just book
test drives, Nick. And once he’s done that, he
indicates in the CRM system, OK, we move this prospect or
customer from a new lead to a booked event. So this customer’s gone through
this conversion. So how do we apply analytics to
this to make sure that we connect this offline test drive
booked component back to that online behavior that
initially got him to the site, and what research that they
may have done before that? So in this case, to implement
Google Analytics, you want to make sure that you have
analytics implemented on the site in general. So across all the
site you should have analytics installed. The second thing we want to
do is send the Client ID with the form POST. So we need a way to get that
Client ID out of the tracker, so the Google Analytics
ID that’s provided. And then we need to send that
to the CRM system so that it can be saved within the lead. And then from the CRM’s
perspective, when the test drive’s actually booked, we need
to get that ID and then send the hit back to Google
Analytics using that same Client ID. So let’s see how that looks. Let’s see how the first
step looks. So for the form itself, we want
to submit the Client ID with the form. So we need to add a new
field to the form. In this case, the ID is Client
ID, but it could be any ID, whatever, of your choosing. The important thing
is that the form, the element, is hidden. And we’re going to use this to
set the value for the Client ID when the form gets posted. So we have this new element. And then we add a listener
to the form for when it gets submitted. Because we want to know, once
that form gets submitted, we want to grab the Client ID from
the tracker and we want to send it to the CRM system
with the actual lead gen. So the way we do that is,
we have a method, inner mechanism, to allow you
to pull the Client ID out of the tracker. So that first line there, the
blue line, is how we get that. So once you have the value, then
you want to set the value of the input element for the
form to that Client ID. That way, when the form gets
submitted, that value will be sent along. And then finally, we just want
to send an event to Google Analytics to indicate that
there was a new lead gen. And that’s going to use the
Client ID that’s part of the tracker already. So it’s going to be associated
with that particular user’s interactions. The second part is, we want to
send another event to Google Analytics from the CRM system to
indicate that this user has booked with us for
a test drive. And now it’s measurement
protocol, which is very simple. At this time, we just want to
make sure we pull up the Client ID that we saved in the
CRM system, that same ID. And we send it along with the
hit to indicate that there was an event where the test drive
was actually booked. And that will tie back all of
that interaction across, from the online to the offline CRM
system, back into Google Analytics, and you’ll have that
view of that full path. All right. Just to wrap up things here, the
important thing here is, we want to make that
connection, right? So if you’re doing online
to offline, you use that connection, use the User ID or
a Client ID to make that connection. And that’s important. Once you have that connection,
then you’re able to attribute offline interactions to online
campaigns and online interactions. And once you have that, then
you’re able to optimize for the complete story. So now I’ll pass it
along to Nick. He’s going to finish up. NICK MIHAILOVSKI:
Thanks, Pete. And Andrew. That was really exciting. I don’t know about you guys,
but this is pretty amazing. We’ve covered three
big things today. We talked about how Google
Analytics is enabling every developer here who’s building
applications to now use Google Analytics to really
measure usage. We talked about beautiful
reports of how we can now optimize across devices, and
how this will enable you to make better decisions of how
you’re building your apps. And finally, we talked about
getting the true value of your marketing campaigns by tying
the offline and online experiences together, all
using Google Analytics. So there’s a couple key
things here of when this stuff’s available. The measurement protocol
is available now. What that means is, everybody
here, after this session, should go look at our developer
docs and implement Google Analytics in
your applications. The second thing is User ID. That’s coming soon. Subscribe to our
+GoogleAnalytics channel and we’ll announce when it’s
available for trusted testers. Finally, all our developer
documentation’s on developers.googl
e.com/analytics. If you haven’t been there,
shame on you. Go there after this session. Finally, come see us in the
after hours, where we’ll be answering questions. Thanks a lot for your
time, guys. [APPLAUSE]

Leave a Reply

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