Tip:
Highlight text to annotate it
X
So I'm Brendan Guenther, I'm the Director of Virtual University Design and Technology.
I'm going to talk a little bit about
some of the policy and legal implications of
turning on
and using Google Analytics to collect
site statistics
and
web usage stats.
We've been using it for years actually without realizing that we were in violation of
a bazzillion MSU policies
in my unit.
I think that's how I got stuck with this presentation.
We discussed it
in the L,C,and T Senior Staff Meeting; the Directors Meeting
back in February.
And we deemed it to be kind of a low risk, I think, from a legal standpoint and that there are
a lot of nasty things in the Google Analytics terms of service
that our General Counsel's Office would object to
in principle
for any contract. These are the things we fight over when we're actually negotiating contracts on
behalf of the university.
Things like, you know, blanket and affigation clauses.
Or we promise--we being MSU--promise to pay all of Google's legal bills should either of us
get sued relative to use of
Google Analytics.
And some of those issues,
although I think we're probably right that it is probably a low risk that use of
Google Analytics would result in the university being sued,
we're gonna run it past counsel
one last time before we say "yeah let's go ahead and just turn on Google Analytics on every site in the university
that wants to use it".
That being said,
we think that
we can probably come to terms. We've successfully managed to get approval for Apps for Education Contracts
signed with Google recently.
So we have some hope that council will give us some guidance on
which sites maybe we shouldn't use it for and what
areas are a concern.
There's always a
remote possibility that we can roll some of the terms of service into the kind of contract
that we agreed
to for the Apps for Education.
So it seems like there's enough of a chance that this will go forward that it's worth talking about.
There's a lot of implications for
people to maintain sides
if you are to use this. So I'm going to assume that you kind of know a lot about site statistics already, that
you'll probably gathering site statistics from your site in some way and you understand the
value of
analytics.
In a nutshell,
Google Analytics is comparable to a lot of the open source stuff that I assume people are already using
or the other commercial products that have been on the market for years.
Google bought Urchin, which is a website,
a web analysis company that we've used on
www.msu.edu and some of the other centrally maintained sites for
quite a while.
So their technology and their legal agreements read a lot
like that.
This is a cloud-based service, though.
And like all these things, it uses a tracking cookie
that's set in the browser,
and it's a fairly persistent cookie
to track
over time a user's use of the web.
I think one of the key differences between Google Analytics and anything that you run locally,
this tracking cookie is used in common across all sites on the web.
Most local products either analyze log files or use a local session
cookie to track,
and so you don't get this kind of comprehensive everything that I've done on the web view
in a database.
Mind you, when I use Google Analytics on our sites, I can only see your activity on my site,
but in the Google data store
they can piece that together across all your activity on the web.
This creeps out
privacy advocates,
obvious reasons I think.
So in a nutshell you know it's how people found your site, how they explored it, what their
quick path was.
You can use this information for a variety of ways. We use it to enhance our website, we use it to understand
who's using our website, who the audience is, which pages are popular, which sections are working
and which are not.
Generally that helps you increase conversions, and in the capital world that tends to be sales.
But even on sites like MSU maintains that could be
listservs, subscribers, it could be
active participants in a forum that you run
on your site.
It could be incoming freshman that are interested in your major,
it could be a variety of things. And conversions don't always happen on the web, sometimes you'd be
tracking that metric someplace else and hoping that
increased website traffic has some correlation with some other number or metric that
you have.
But if you track these statistics over time, we put together some pretty successful funding
arguments over time--
both internally and with
on behalf of some of the contracts that we have for the foundations that support them,
in the case of small non-profits.
Sorry, one little thing about AdWords
there, and I'm gonna bring this up later probably too,
but you can tie this together with AdWords.
And AdWords is a way that you get free Google Analytic service forever,
otherwise there's a page view limit;
five million page views after that. You're not allowed to use it for free,
you have to set up and AdWords account.
And AdWords brings into play a lot of stuff that is kind of beyond the scope of what I want to get into
today.
When I talked to David Gift about it recently he reminded me that MSU has a policy about--in the
traditional built physical
environment about advertising--
and advertising has to be board approved.
That's why we go through University Relations in a lot of cases to help us prepare advertising
because they're familiar with what
will get approved and what won't.
This policy doesn't speak specifically to the web,
but it probably applies in the web.
So
I know of some
environments that are doing AdWords campaigns for a variety of reasons and I'm not entirely sure if they're
on the reservation or off the reservation.
I just would encourage you if someone asks you to start an AdWords campaign for your site
to make sure that there's some thought about whether or not what you're doing
complies with MSU's expectations on advertising.
So there's a number of steps you have to get into and these are almost all likely
to have legal or policy implications in the MSU environment.
You have to agree to the Google terms of service. I'm going to assume everyone in this room has probably agreed
to the Google terms of service at some point already
for a variety; if you've used anything Google you've agreed to the Google terms of service.
If you have a Gmail account,
if you've used MSU Google Apps for Education, to a certain extent we agreed to the Google terms of service on your behalf.
When you sign in with your net id
you're riding on our
agreement to the terms of service, and those are slightly modified.
And that's really the only difference, by the way, between our Google Apps--
the MSU Google Apps--
and Google Apps out in the world. There are few legalistic differences.
It's hosted in the same place, it's the same code, it's running all the same place,
we just tweaked a couple of
sentences in the Terms of Service.
That's not really the sensitive one, I don't think,
since probably most people are agreeing as an individual
to set up a Gmail
username and password.
Probably if you are going to use Google Analytics you should consider creating the Analytics Profile
not with your personal Google account, but set up a new Google account on behalf of your department.
Have that username or password
assigned by your IT people, or whoever it is who holds the keys to the electronic kingdom so to speak,
in the department
and generally does access control
across all systems.
The reason being
we made the mistake of having staff set it up and when they leave
by their grace they continue to do access control for us and share out that access,
but the original owner of the profile is an individual
and this is probably better done on an institutional basis.
You have to agree to the Google Analytics terms of service and that's the messy one
that has,
I would say, several
red flags in it
that we're going to work with counsel on.
What I'm going to stick to today are the things in the terms of service that are particularly pertinent to you
as someone who might implement Google Analytics.
Immediately after agreeing to the Google Analytics terms of service you will have an opportunity to set
preferences
on the privacy of your data
related to, that the tracker collects.
I'll get into that in
a little bit here.
The next step would be--now you have a profile you probably can figure a site for it, you've got privacy
settings for it--
would be to actually distribute access to the reports that are generated
from the data. This is
mind you, prior to data collection but so they have access to the profile
you'd give that access to other people who have to set up their own Google
accounts and agree to the terms service in order to do that.
That's how we do it, I think there's probably seven, eight people in our office that have access to every single
site
profile, depending on who needs that information.
So prior to actually deploying the tracking code,
because as soon as you do that you're going to start collecting data,
you should audit your site.
There's a number of things to look for that
derive from the terms of service, and I'll get into that.
And you should establish a privacy policy.
These are actually legally mandated by the agreement with Google.
So these are kind of the key things, and I took out a lot of the
things that the lawyers will object to.
But it does have a five million page view limit.
You and third parties that
you contracted to your site or that are involved in hosting your site, that kind of thing,
must not collect personally identifiable information
and associate it with the tracking cookie.
So for instance if we were putting this on www.msu.edu
probably the fact that my home page includes my MSU net id and therefore can fairly
easily be traced back to my identity
probably doesn't count as this.
But if for instance every time I logged into the,
to the site,
for instance it actually had a login that was required every time, so
if it was ANGEL for instance.
It was obvious who I was in the course of logging in and it was displayed in the URL
such that it would be captured by the tracking cookie,
that would be a no no.
And so probably looking; the easiest way to do this as a web developer is probably to look
through your
access log
and use some kind of search tool to search for things that look like they might be personally
identifiable whether it's an e-mail address, names.
I'm not
gonna be so ridiculous as to suggest that anyone ever put a social security number in a URL, but
who knows maybe somewhere, certainly not at MSU.
But search through your site and audit essentially to see whether or not you think you might
be exposing people to personally identifiable information.
I think this is especially true for web applications, so if you were to install off the shelf
software
Like Drupal or
Word Press or something like that, just evaluate probably its profiles, things like that.
Areas in the site where the user name, like we would be embedded in the URL.
Since we're talking about MSU, if you run an actual application of some sort like AIS would,
probably you want to make sure that
your search parameters and things like that--
that actually make use of
data, that is in a database behind the site--
doesn't expose,
not necessarily
the person browsing the web's user data, but other data we would consider
private or confidential.