Community Dialogue on Policies


Uploaded by webdevcafe on 24.01.2012

Transcript:
Hi, good afternoon.
I apologize for not making it over here sooner I think it's been nearly,
it was summer I believe when I
hashed all this out with general counsel and we've been meaning to get me here.
This was begun a long time ago
at a time when I had a lot more free time to tackle projects like this.
And I think it's a really important tool, Google Analytics is,
for web developers.
I have to confess that I think I was in front of this group
more than a year ago talking about this and at the time confessed that we'd
been using it for quite some time
before we realized that we were potentially violating some kind of
institutional policy in doing so.
And compared to what I present today we had a
pretty immature version of how
to; the doctrine of to how to use this in an efficient manner
as an asset of the institution as opposed to something that as an
individual web developer
you know we were using for our site.
So the current state of Google Analytics is that
it has been decided
by Libraries, Computing and Technology--so David Gift helped invent this
as well as the general counsel's office-- that it is acceptable use Google Analytics.
I kind of eluded to that a year or more ago, whenever it was that I last saw this group.
But we actually go to the point where we worked out all the details and
reviewing every line of the terms of service, the multiple terms of service
involved. And we settled on
essentially an acceptable use doctrine that says,
as a web developer--as someone who's maintaining sites on behalf of the
institution to the extent that this is somewhat sensitive information or at least has
business value, the reports that come out of this--
here's the steps you should go through in setting up a Google Analytics account and deploying it on your
site so you are in line with MSU's institutional stance
on sensitive information, you're
in line with our acceptable use policy, you're
in line with Google's terms of service policy because they're pretty strict about what
you do and do not do
in the use of the tracking cookie and in the use of this reporting data.
So that you have a step-by-step guide as to how to go about doing this and you can
feel relatively safe in terms of
the Cloud computing memo and other things that have come out of LC&T
advising. The use of Cloud
services, particularly free Cloud services should be taken
fairly cautiously by MSU staff.
We also drafted a privacy statement so this is what most
web developers would call a privacy policy.
The reason it's called a privacy statement is the use of the
"p-word", policy at MSU
is reserved for the authority of the board
being the legal body under which the institution
has its legal authority vested.
That's the entity, the legal entity
and the board has to decide
on official policy, the board didn't decide on this.
The board is certainly not going to decide on any of your individual websites',
privacy policies.
So when MSU parlance for your users we thought the term privacy
statement was equivalent.
If you were to put a link at the bottom of your website that says "privacy statement"
we think most users of your website will understand what that means.
And that's where the functional equivalent of a privacy policy as most
global web developers would call it. So that's what we're going to call it: privacy statement.
So we developed one of those, that was a necessary step
in response to Google's terms of service.
It's also important because it's just good etiquette, right to be
fairly transparent with your users about what information you collect from them
particularly when it happens behind the scenes and it's not
immediately apparent to them. Unlike filling out a web form, right, when we're doing this kind
of tracking cookie stuff
it just happens routinely, there's nothing evident in the user's behavior
that we're tracking information about them the entire time.
So you want to expose what are we talking about you,
why are we tracking it, what do we intend
to use it for, who are we sharing it with?
That's explicitly required in Google's terms of service if you're going to use
Analytics. And I will once again confess that when we first acquired Google Analytics
we failed to note that in their terms of service.
Another good reason to have a standard set of practices at the institution.
So before this meeting
we actually managed to get published a tech based article on help.msu.edu
about how to use Google Analytics. If any of you have a
computer with you,
you can pull this up by going to help.msu.edu and searching for analytics
is the easiest way to get to it, should be the first link that appears.
So if I searched MSU's tech base;
I'll make this bigger, is that fairly readable?
If you just search for analytics
it's this first link here.
This is going to be the lasting documentation.
This isn't something that is particularly well supportable by the
help desk, right, because the people you expect to help you are fairly
transactional technical problems. This delves into policy stuff and in terms of
interpreting the legal language here.
If you're going to implement this
and you go to read through
this and you don't understand something you should do
at this point you're probably going to be stuck e-mailing me and I will get back to you in a couple weeks.
Unfortunately at some point
there will probably be a set of you that will have gone through this
and we'll have a better understanding. I know that some of the people
in this room have already done this because they
talked to me or we were going through it earlier.
I know that Debbie's in the back from the MSU web team, which sites right now
have we already
deployed this or have you already gone through the process of doing this?
So if you were to go there you should see a privacy statement link down in the footer.
So that'll be a good example of looking through; so on this page you're going to see the
generic process and a link to the generic privacy template.
They've actually gone through a thought process is to this whole thing
in deciding how to implement it on that site and you will see the conclusion
of those decisions essentially manifest in the privacy statement they linked there.
So that'll be something you can do
if you're going through this process to see what other people have done.
Probably this community will gain
greater competence in this and you'll be able to compare notes with each other on the
list serve. When it's like, "What about this certain line in the terms of service, how is this possibly okay?".
Some of those maybe you can answer amongst each other, some of those maybe you
bounce to me and say, "We don't get it Brendan, how could this possibly be okay?"
and I will try to explain it.
And it could be that that goes above my level of expertise, I'm not a lawyer so I
may turn back to general counsel and say, "So remind me when we discussed this,
did we think of it this way and how does that relate to
our interpretation of the law?".
So just simply walking through this
one of the things that we wanted to do is make sure that the
access to the reports and what-not that come out of Analytics;
and let me just stop here and say I am going to assume you already know what Google Analytics is, what it does,
this is not a demonstration of Google Analytics
I leave that as an exercise for the reader. If you're totally unfamiliar with it,
there's a ton of information out there on the website
posted by your colleagues out in the world
as to why you might want to use Google Analytics, what it does, how to use it really
well for certain things.
I'm going to leave that as an exercise for the reader, this is strictly how to go about
doing it at MSU so you're in bounds.
So one of the first things to be sure of is that it's not my own personal
identity, my own personal Google account which has nothing to do with my
employment at MSU that I'm creating all this stuff under.
The account that gets access to Google Analytics kind of owns the key to
give access to other people who access to the reports.
We want that to be
a piece of institutional property so you can leave your job and transition to someone else
and you don't have to get in this awkward "Oh geez, how do I,
I don't want to give them my personal Google account,
how do I leave them with the ability to provision access to this?".
So the first step is
assigning or requesting an organizational net ID.
At Virtual University we have a net ID that we paid for for years called vu@msu.edu.
I can use that to create a Google account.
So in other words the
non-Google email address associated with that
Gmail account is vu@msu.edu.
I'm not going to use it for anything else, I'm not going to use Gmail,
I'm only going to use it for Analytics and other things like this
strictly to provision access to people, either administrators, web developers, or
my unit that need access to Google Analytics reports.
So that's also the second step, right? Using vu@msu.edu to create an account may be called
vu@gmail.com. You are going to have to agree to terms of service
to do this, right? In setting up a Google account you're agreeing to generic Google
terms of service. On our review of the various terms of service
essentially the consensus between LC&T and general council is that it is acceptable for
MSU employees to click through this specific terms of service agreement for this
specific purpose. Alright, so this is one of those stop points were normally
as an employee you don't have authority to bind the institution to a
legal contract and a click through agreement is essentially that.
We for years have been installing Microsoft Office on our own computers and things like
that and agreeing to these end user license agreements.
Some of these things are seen as fairly benign,
some of them like this not as much. We've at least read this one and said, "This is okay to do".
We're not saying it's okay to click through every agreement on the internet, just this one.
Once you've signed up for an Analytics account
you can now provision access to that. So at that point I might go to the web developments
in my unit or administrators in my unit that want to see these reports directly
and I would ask them to set up their own personal Google account.
If they already have one I'm okay with using that.
We're basically going to control access to the reports
available in Google Analytics to each of those accounts so that when those people
leave their job
I can sign in with my departmental Google account
then I can take their access away.
And if someone I hire in I can go in and add that person.
And at that point we're not really worried about that person clicking through
the terms of service because they are kind of doing it on a personal level
and we're okay with provisioning access to non-MSU net IDs in that way.
One of the common questions I get about this is, "Can I use
the Google Apps suite that MSU has
to do any of this stuff?"
and the answer to that right now is no.
You know we have to turn on access beyond the docs and calendar
applications, one application at a time
and we haven't decided to turn on Analytics
because we think it's actually probably good for people have to go through these
additional steps and acknowledge this policy
in going and doing it. And it seems like turning it on for the Google Apps suite
makes it look like free-for-all, go ahead and just use Analytics.
There's a need to transmit this information and so having to go to this
policy and understand how to set it up the correct way;
we think it would be harder for people to understand that this is kind of
a special thing and the process is important.
If it's just on that Googleapps@msu.edu page it looks like you can just go use it without any thinking about it.
So at the point where you've got the departmental account,
you've signed up for Google Analytics you may be giving some people access to it,
in there you can add websites that you want to track. So a specific host name for instance
like vu.msu.edu.
Google is going to give you a piece of code that you can then deploy on the site
that has a tracking code that is specific to that website
and that's how it's going to generate your reports.
At that point, you know if you had
somebody who is like a security officer or generic IT person might be the
one that sets up this departmental account and provisions the access.
I would recommend that in your department it might not be the web
developer, it might be someone else who is
more routinely dealing with access control to information systems.
If it is not the web developer who does that initial setup
they can then get that tracking code, give it to the web developer,
they can decide where to put it on the site.
Since you're all web developers
I assume you understand the difference between
someone who edits content on the web and the technical skills that you can do.
This Google tracking code stuff and deciding where to put it, this is clearly in
your realm and clearly not in the average person's realm.
You may have other people who have access to published content on your site,
you definitely don't want them to be the one doing this
because it matters where you deploy this. It should really be rendered on every page load
on your site, but only once per page load.
And if you put this code in the wrong spot it may only be tracking use
of a couple pages on your site, and not your entire site or it could be hammering the
heck out of the Google servers and doing it three times per page load and
generating bad statistics
and overloading the Google servers in a way that possibly violates
their terms of service.
So this is clearly something that that
someone who that familiar with the site structure and established the site
template should do. And then at that point
you're kind of up and using it. So there's a lot more detail written here about
what to take into account with that.
Before you deploy the cookie there's a couple of things that really you
should do. A web developer who's expert in this realm
you need to incorporate the privacy statement into your site.
That involves customization of this privacy template, this model privacy statement
which is hyperlinked off of that article.
This is what we worked out with general counsel based on;
basically what we tried to do is come up with a generic privacy statement
that could be customized on a site by site basis that probably would encompass most
of what you need.
And met the key requirements in the Google terms of services as to what you're supposed
to be disclosing to users.
We looked at numerous other universities
in terms of how they either established templates or what they just
posted on their privacy statement.
That said this might not be perfect for everyone.
If you're looking at your site and you have a really rich web application
it could be that you plan to collect other information about users and
use it fairly actively in a way that possibly impinges on privacy,
you may decide to go to general council with your own draft that gets more explicit
about how you plan to use user collected information. An example of that might be
you know like the University Developments website where they actually collect
money from people and its e-commerce system.
It involves sensitive information as to who gave how much money to what,
how we plan to use that contact information in the future
to possibly reach out and ask you for more money in the future.
This might go beyond what this statement is really talking about doing.
This is probably typical of your
fairly normal departmental web site, mostly informational
to the extent that it collects things about users. It's probably maybe like
subscribing to a list serv or
participating in a discussion forum, something fairly benign like that.
So this isn't a one size fits all, it's one size fits eighty percent, maybe.
So there are instructions at the top here.
Anything inside brackets is something you probably need to be
customizing like your unit name.
Some of this stuff is pretty obvious. In a nutshell it basically says,
"This privacy statement informs you of how we're going to use the information we collect on the site".
It starts to get specific about the kind of information collected,
so there's a section that basically says "Information you voluntarily provide",
this would be like web forum kind of stuff
because it's very obvious I'm typing in stuff into a web forum.
When we get down into
editing personal information, like if you collect a user profile on your site,
you should probably provide explicit instructions, this would be a customization point
where you say, "Here's how you find your user profile,
here's how you change and update information on it". These are really standard things
that are on web privacy statements.
The sensitive part that we had to include about Google Analytics and about any
server logs you might have is this information we collect automatically. So in other words, it's
not going to be obvious to you that we're collecting information from you, we're
going to do it all the time whenever you are active on the site it's going to appear to be passive
information collection to you.
And so there's some kind of inlay person explanation of what a cookie is,
usually the technical mechanism of how this stuff happens and then
this third party tracking technology is the part where it gets specific to Google.
And we tried to write this in a way where we're not totally specific to Google so if Google is
out of business tomorrow and stops offering this service
you might switch to using free Yahoo Web Tracking if such a thing
comes into existence.
And theoretically a lot of this privacy statement can stay intact and we can
insert a new block
that's specific to Yahoo's terms of service instead of Google's.
And there's some stuff in here reminding you that
whatever you do choose to put in here, it has to comply with the
requirements of your third party tracking provider.
So we expect that Google is going to change their terms of service over time
and may add additional requirements for you,
very important that you not assume that we've imbedded everything about this and that it never changes.
When you're going to deploy this read the Google terms of service,
there are very clear and explicit instructions there about what you need to
include in your privacy statement, what you need to do technically to comply with
their terms of service.
You need to reach your own conclusion
and I'm sure the web team did when they were deploying it, that indeed
we've done everything we need to do both in being transparent with our users
and in technically providing the service.
So there is a block in here that we provided that is relevant to
Google Analytics at the time this was drafted which was about July of last year.
And some links, we want to link to the terms of service Google provides,
we want to link
to any information they provide that's
directed towards consumers about what's really going on.
A particularly important thing to link to would be how to opt out.
There's almost always a way in your browser to configure your browser
to not accept these kinds of tracking cookies, to notify you before accepting them.
There are for instance plug-ins that I can install on Firefox that block all tracking cookies from
Google, Microsoft, you name it.
It's good to inform uses that they have that option.
This is one of the things we think is important if we're going to
impose this on users.
There was a day when we insisted on buying our own tracking technology. We
used a License Urchin
which Google bought in order to implement Analytics
and it was a stand-alone server product.
Basically you had a server appliance that sat and all it did was punch server logs.
The license for the software measured in the tens of thousands of dollars.
I don't know what all we searched on that but I don't think it
was much farther than www.msu.edu
which is to say there's thousands of other websites on campus that we didn't bother
to cover with that license, couldn't afford to.
It took a lot of labor to do to maintain that server platform.
We've traded that cost for free service,
the down side is the users now
in their use of our websites, they use this tracking cookie,
they don't have as much privacy as they used to have.
There was a point back in the '90s when Paul Hunt was the Vice Provost and the
acceptable use policy said users' privacy was the most important thing in the universe,
even to the detriment of us running the network.
That would be my own personal interpretation of Paul's stance on this issue.
If Paul knew we were using Google Analytics he would probably come and ring my neck.
I hope he doesn't watch this recording.
Because this is a trade-off between convenience to us and access to this
information which helps us improve our websites
which makes our websites a better public asset
with the users kind of global right to privacy on the internet. And that's probably
something to think about before you deploy this.
If I was running the library catalog I would not be putting Google Analytics on it
because it's probably hard to avoid
making it apparent what people are looking for in that catalog
from this tracking information. Theoretically it's anonymous,
and that gets us into the next thing you need to worry about as a web developer.
In addition to customizing this privacy statement
you need to audit your site to make sure it complies with the technical terms of service
and there's two main things to avoid there.
First and foremost a really general avoidance, and this is explicitly against
Google's terms of service,
you are not to attempt to correlate the tracking cookies. So in other words
the unique identifier--which is a big ugly serial number of letters and numbers--
in that user's cookie. So on their user-agent
they have a cookie that uniquely identifies them cross all websites on the internet.
It's not just your sites, it's all sites that use the Google tracking cookie.
This is how, by adding the tracking cookie,
you're contributing to that giant collection of information that Google has
about that user.
Your reports give you access only to your wedge
but their database has everything the user does on the internet
on any site that uses Google's tracking cookie
and this is how it is a privacy concern.
You're not to try to uniquely identify that user's tracking code
to something you know about them as personally identifiable.
But a lot of our web applications, when I use it you know that I'm Brendan Guenther.
You're not to try to figure out a
correlation between Brendan Guenther and that tracking code.
They explicitly forbid you from doing this.
On the Google
web forums frequently there are web developers that are actively asking on the forums,
"How do I go about doing that?"
and all the other web developers say,
"Boo on you, that's evil and it's against the rules you shouldn't even be asking
that question you fool".
We want to make sure that our use of this is above board, we don't want to see
anybody doing that here.
There's no reason to do that, I think that's against
our institutional norms in terms of internet privacy.
And certainly we don't want you violating Google's terms of service, in
accepting the free service you've accepted the you're not going to try to
personally identify that person.
Even if you have twelve websites in your college and you really would love to know
how Brendan Guenther is using all twelve
of those websites across there you're just not going to be able to figure it out
without violating this rule.
I would say there's no business interest of the university that trumps
this concern. Even if Google didn't impose this rule we would probably be
asking that you not do this.
The second thing you need to do is make sure that, particularly in the case of a web
application, your web application is not encoding variables
which contain personally identifiable information in the URL.
So query string variables, GET requests
that include my identity as the consumer of the information. So like if I go to--
I'm assuming everyone is following what I'm talking about, this is where I get a little bit technical--
if you go to, I'm going to guess here and I am going to guess that if I go to
msu.edu and do the people search that is probably a GET request. Is it?
We shall see. It is not.
Okay so one of the things I could've been doing here if that wasn't a post, is it could
have been putting in the URL here a variable name
and what I typed in this form field.
That's probably fine because that's just anybody searching for Brendan and that doesn't really
matter much. But if I had logged into this,
if this was ANGEL and in the process of logging in it encoded that I'm brendan@msu.edu
up in the URL string
that URL string gets recorded with the tracking information. This
is in your server logs now.
The difference is now you are sharing it with Google and you're sharing it in a way
that at least within Google's database they now know
that brendan@msu.edu is this certain serial number.
You accidentally just violated Google's terms of service and did the exact thing
I was just telling you, you should avoid.
So there needs to be an auditing, probably, of your server logs to just
verify that the encoded variables that happened in the URL
aren't recording personally identifiable information of the person using the site.
This is a relatively trivial thing to do if you have access to your server logs now.
Search for that sign, email addresses, try to figure out if those are benign collection email addresses or
potentially malicious collection of email addresses.
Search for user names;
and I think there's a grey area here. Like is a uniquely
identifiable user ID,
is that dangerous? I don't know I mean we haven't been asked too many specific
questions about this. If you're not sure
that would be something maybe to bounce to me, I will
probably get some collection of the people on the web team together,
maybe even someone from general counsel and try to decide, is that okay or not?
We haven't been faced with too many specific questions about this yet but this is what we want you
to watch out for when you audit your site.
I think, those are kind of the three main points: how to go about
setting up the account,
how to customize the privacy template and how to deploy the privacy
statement on your site, and
things to audit your site for before you go ahead and deploy the tracking cookie.
Those are the three main legs in which we're hoping you stand.
Anybody have questions while I'm here?
Given that this policy was kind of created for Google Analytics
but we still have websites which have server logs, would it be appropriate to post this on every site
that's collecting information? Yea you can wipe out; yea so
just to repeat the question just in case people in the back couldn't hear that,
the question was, if we have,
if we're just using server logs and we're not using Google Analytics or some other
third-party tracking,
would it be a good idea to customize this privacy template to our site and use it anyway?
And I would say yes.
Go ahead and just wipe out the third-party tracking component. I think this kind of
disclosure statement about what you're using your server logs for and what information you're
collecting in them about
your web users is a good idea. And if you don't already have a privacy statement
it's just good etiquette to have a privacy statement.
There's no reason you couldn't just disclose that just for
use of our own server logs.
You know if you were using Urchin for instance
and not using Google Analytics, I would still disclose; and in the privacy template
there is I believe room in there in the next section which I never bothered to scroll down to gets
into server logs. And it says specifically, "This is what we collect in our server logs".
If you were collecting something else--'cause you can customize these on your server configuration--
you should probably change the section so that it accurately reflects what you're doing.
Any other questions?
What will happen if we're using Google Analytics and you fail to implement a privacy statement?
If you're Google Analytics and you fail to implement a privacy statement,
you would be violating Google's terms of service to the extent that you clicked
through that agreement and agreed to bind the institution to that agreement,
you've now created a liability for Michigan State University.
As an employee I think that's something I would try to avoid.
I can say with certainty I do try to avoid and I think probably
that's just pour professional practice. I would hope that although
web developers I think as a community haven't yet,
don't have a really strong professional organization that isn't part of
the ethical code of conduct that everyone in this room would try to avoid doing that.
And certainly I am in the process of trying to make sure all the sites that we
a long time ago deployed these tracking cookies on
that we're in the process of going back and forming
policies on to get ourselves out of this exact ethical lapse that we accidentally got
ourselves into. That's a good question. So the privacy statement applies only to
websites or web applications in MSU? It does not apply to third party applications like Survey Monkey?
Yes, so this whole privacy template and doctrine that we came up with really is for MSU websites,
it doesn't necessarily apply to other applications.
One of one of things that we've been looking at amongst the communicators group, which is
pretty closely aligned to this group,
is use of like social network tracking tools, email
marketing campaign tools. This gets into a really similar realm, similar kinds
of reports for a similar business purpose but
often not driven through the website and I'd say this
is an approach specific to MSU owned websites, not necessarily hosted out
like Facebook pages, for instance.
As a web based;
there are lessons you could probably translate but I'd say I wouldn't attempt
to use this directly to make that translation. I was wondering if on your
your website and you've got the tools like the "like" buttons on Facebook and you've got
the ability to "like" or "dislike" and if
in the third party vender area if you display the information that you're doing, if that corrects
that situation? I think
if you're using a Facebook "like" button and you're embedding that on your website that's
a good example of the use of another tool which we know has privacy implications.
Including that in your privacy statement here is definitely a good thing.
The thing that I think this whole doctrine doesn't necessarily cover is
that whole doctrine as to who set up the Facebook account, who owns the Facebook page?
Are there other things that are happening in the pressing of that "like" button
in terms of data collection that happens on Facebook
that involves agreement to a terms of service, a Facebook terms of service that maybe
we should go to general counsel and say, "Is it okay that MSU employees bind the institution
to this Facebook agreement?".
I would say that those are things that
you could interpret a lot from this doctrine and probably establish a similar doctrine.
If this community has a strong desire to use the Facebook "like" button, it would probably
be a good idea to be specific about some of those discussions
rather than every single one of us handling that on an adhoc basis.
And it would be a good idea
to take things are going to be commonly used and go to general counsel
and ask for explicit clarification as to what exactly should we put in this
privacy statement, how exactly should we establish a use doctrine and
can they give us a legal opinion as to the acceptability of that terms of service?
Because what they do is they can take a look at that cloud computing memo
and as lawyers, as legal experts, they can interpret some of the
business concerns that we have embedded in that memo
in a way that those of us as general practitioners don't look at in the same way.
I can say that I've definitely found value in talking, I worked with Lee Bollinger in the general counsel's
office and Lee was tremendously helpful in arriving at a well worded, well considered
use of Google Analytics.
And I think Christine Zeko actually signed off on, "Yeah this is an
acceptable package of information". And if we're gonna use
Facebook or an email marketing tool I say we should probably;
you know if there's some consensus that forms among this group, that in that certain
service sector, this is the tool to use.
We should go ahead and take that discussion there,
it'll be easier now with having gone through this.
So in theory a user could be bounced around from
site to site within the msu.edu domain
and so they would be going from
one private policy to another policy to another policy.
Is there any concern that it's not necessarily transparent that that policy is changing to the user?
That's a really good question. I would put that in the philosophical realm
where it's like I'm not even going to try to provide a solid answer to that.
I think in the beginning of the privacy statement we tried to make it clear what the
scope of the privacy statement was
so when you're reading that www.msu privacy statement
it's pretty clear that this applies to
the primary university homepage but the further you travel down the link path
the less likely that policy is to apply.
I'd say the same thing applies in use of this privacy template anywhere.
Whether users understand that,
I don't know. I'm not sure they understand anything in these privacy statements.
I'm not sure how many people read them.
I suppose if we invented the tracking code on this we'll eventually be able to answer that question.
I'm not sure how many people clicked on it ever, whether they understood it, I don't know.
This gets really into the realm of;
and I think that's why it's useful to have that local debate or even for
yourself in deciding for my site
is this fair game? You know you don't have to link to the privacy
statement in the footer,
you can make it more prominent.
I'd say the more sensitive the nature of your site is,
the more rigorously you should review this and the more thought you should put into
how you're informing your users.
You have tools at your own disposal and
where you choose to place the link, you know whether you;
like on ANGEL for instance
there's an explicit paragraph that talks about privacy and the surveillance
that happens in running the management system.
You know, we've debated where to put that on the home page, where to put that in the log-in process,
whether to include it in the footer of every single page.
And that's evolved over time, but
that's an example of where just a link down at the bottom we thought was insufficient,
we've given it more prominent placement. You could argue that we could give it even
more prominent placement than we have.
That's a good question to consider, I think, every time you go to implement this. Am I totally out of time yet?
No we're not, but if I could ask a question of the folks here,
by a show of hands, how many of you are using Google Analytics right now for your sites?
How many of you are using Facebook "like" buttons at this point?
That may very well be--I'm glad you mentioned that-- because that may very well may be
the kind of thing that we want to do as the next step on this.
Yeah. Is have a conversation with counsel about that sort of piece.
So I'm just going to guess because
I'm guessing the camera sweep probably didn't capture the hands quite fast enough, was that about
fifty percent for use of Google Analytics? Give or take?
And maybe 1/5 to a 1/4 for use of a "like" button? Yes, just about.
Well there's just a couple people with the "like" button but it seemed like
3/4 of people raised their hands about Google Analytics.
What are people finding value in, in Google Analytics so far?
Like what are you using the reports for? Well it's fast
and it helps me to track specific nominal values easier.
And actually it makes it easier for me to distinguish access from staff network and actual users. Google allows me to do that easily.
So you're not mistaking actual patrons from people who that just testing the site or
internal people that are using it as a replacement for the phone directory or something
like that? It helps with like analyzing browser usage trends, device usage trends.
Still I use it because it is faster than other tools I'm using.
Does anyone use like the bounce page analysis or the search term analysis
to actually change the content of the site, or the sight of the site?
Can you talk about that a little bit?
Have you actually made design changes?
We changed some of the metatags on some of the
pages based on search terms. Because our site is really split between internal and external users.
And the external users search for things completely differently
than the internal users do.
So we have to make sure our keywords take both of those things into consideration
or we're not serving both parts of our audience.
For MSU libraries, I totally disregard bounce because
we expect to have higher bounce.
Yeah, you find what you're looking for
that's okay, it depends on the nature of the site.
Yeah, that's kind of the difficult thing about using Google Analytics, I find, is that there
are some assumptions built into the tools, that people got to your site through an
advertising campaign
and an initial bounce is a bad thing. With some sites that's not necessarily a fair assumption.
But I think it has helped us decide, how do we segment our audience?
And how does the usage differ across those audience segments.
So certainly we've learned a lot about what are the popular
pieces of content on our site.
You know a lot of the sites I run are content rich
and we have in our expert mind an idea of what's relevant to the world
but they obviously have a slightly different weighting of those values.
And that has helped inform us as to
which pages are totally relevant and we're just putting up for our own
sense of compliance and which one are people consuming and where should we
invest our time and improvement?
Yeah? I'm not using Google
Analytics, but we use Analytics on our departmental website and found that
mostly our users are undergraduates and use the search terms and the pages they use to help guide our FAQ design
because that's one of our big goals is to
tell the undergraduates what they need to know
and so the Analytics has been crucial to figure out
what it is they're looking for.
Somebody in the back row?
Oh that was a minute ago, but I would say for CAS for the mobile site
we use Google Analytics to see what people
needed right away because we wanted people to get the information as quickly as possible
and so that's what we use.
So if I have time to squeeze a little announcement in here, this is vaguely related in that it's a recent
service/policy development.
MSU is a member of the Incommon Federation,
so if you've used Educause lately
and you didn't bother to setup an Educause account you might have noticed that
on their log-in page they've got a little link under there that says, "If you're an Incommon
member you can sign in through that".
And what that allows you to do is use your MSU net id.
So I don't even need an account on the Educause site anymore, this is just a working example.
If you click on that it takes you to the "where are you from?" service which basically
asks, "Which institution are you from?"
and if you're doing it from on campus it tends to identify that you must be coming from
merit so you must either be a U of M person or a MSU person.
It gives you a little shortcut in the giant list of institutions that are Incommon members.
And you click on MSU and then you get the MSU net id log-in box
and I can just do brendan@msu.edu and login with my net id password without creating an account.
And I think there are going to be more and more services like because it's one of the most direct benefits
of being an Incommon member. They also
are giving us essentially access to
SSL certificates at a really reduced price.
We had to pay
a fair amount out-of-pocket at the institutional level in order to get access to
this but Libraries, Computing and Technology decided to do this so we have the ability to
generate these certificates that are at a reduced cost.
On tech.msu.edu and I'm not entirely sure what to search for here,
I don't know if this is linked or not yet.
Ha, it is! So if you type in SSL into the search box the
first thing here that comes up in keywords, so I bet if you type in SSL
into the MSU webpage it'll do the same thing. Is that true, or is it different?
I don't know, anyway on tech.msu.edu if you type in SSL it'll work.
There's this SSL page and this describes kind of the pricing framework. These
are certificates provided by Kimono, so that's a major SSL provider, it's going
to work in every browser is what that means.
If you buy a three year certificate, it's ten dollars per year.
This is a very competitive price to what you can get out there on the internet, so this probably becomes,
we hope, the path to least resistance to generate certificates.
If any of you are using wild-card certificates,
which is to say any sub-domain.something.msu.edu that works with the SSL certificate, those aren't
as secure. It leaves your users open to man-in-the-middle attacks and other things like that.
There was a business reason why you might have chosen to buy a wild-card certificate because
it was cheaper than buying bunches and bunches of other certificates.
This should eliminate that motivation.
If you have a wild-card certificate we recommend that you go ahead and just buy
these instead. There's two ways to do this. You can just use this request form.
Let me just log in. At least it knows who I am now.
Fill this in and choose what you want and someone will generate it for you.
If you think you are going to be generating just a ton of these certificates
then you can get, I think your department can actually request someone in your
department who has the ability to generate these themselves. That would probably be
an I.T. person.
And I think we are asking for like a three year commitment and it's a fair amount of
out-of-pocket money
I believe the College of Natural Science might have already taken us up on this.
So obviously for some of us that have lots and lots of these certificates, it makes sense.
It certainly gives you more direct access to just do it yourself
and it might actually at the end of the day be cheaper for you.
If you want to do that and you want to talk to somebody about it, Scott Thomas in ATS
who I am presenting this on behalf of because he couldn't make it today,
he said you could go ahead and contact him directly.
If you want to talk about the getting department wide access and you have questions
about it, I believe that's in this article too.
Maybe. Unlimited subdomains SSL request form. So this is the
if I want one certificate at a time,
this one down here is if I want to have
someone in my department be able to crank these things out at will.
This is available now so feel free to take advantage of it, I think it's a good deal.