Bug 6610 - Integration of Google Analytics in Koha.
Summary: Integration of Google Analytics in Koha.
Status: CLOSED WONTFIX
Alias: None
Product: Koha
Classification: Unclassified
Component: OPAC (show other bugs)
Version: 3.6
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Juan Romay Sieira
QA Contact: Bugs List
URL:
Keywords:
: 7918 (view as bug list)
Depends on:
Blocks:
 
Reported: 2011-07-20 11:10 UTC by Juan Romay Sieira
Modified: 2014-12-07 20:02 UTC (History)
8 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Juan Romay Sieira 2011-07-20 11:10:35 UTC
New system preference for the introduction of Google Analytics in the Koha ILS.
Comment 1 Paul Poulain 2011-07-20 13:26:25 UTC
I'm not sure this is needed : you can add the gganalytic html into one of the existing syspref (like opacheader, or opacuserjs)
Comment 2 Owen Leonard 2011-07-20 13:30:13 UTC
I think it would be easier for librarians if all they had to do was plug in their Google Analytics UID.
Comment 3 Katrin Fischer 2011-07-20 14:28:34 UTC
Please make sure that OFF means really off and no communication with Google. 
I think some would think of this as unfeature for privacy reasons.
Comment 4 Paul Poulain 2011-07-20 14:47:11 UTC
well, thinking of it i'm really against this syspref : there are many tools to achieve what gg analytics do (http://piwik.org/ to name one) We won't add a syspref and some code for each of them. The syspref for local html/javascript achieve the goal, that's enough !
If we want something "easy", it should be in the documentation, with a tutorial or something like that.
Comment 5 Juan Romay Sieira 2011-07-20 15:19:36 UTC
(In reply to comment #4)
> well, thinking of it i'm really against this syspref : there are many tools to
> achieve what gg analytics do (http://piwik.org/ to name one) We won't add a
> syspref and some code for each of them. The syspref for local html/javascript
> achieve the goal, that's enough !
> If we want something "easy", it should be in the documentation, with a tutorial
> or something like that.

yes, there are a lot of utilities to achieve it, but different as google analytics. Piwik as I read, needs to be installed into the server, as awstats. There are some clients who can't install software into servers (servers in public administration, third parts...) because server managers dont want it, or maybe lost lot of time until its installed , and this solutions is the best for them. Finally I got to add a new syspref, because the script of ga needs to be just before the </body> tag to run as expected.
Comment 6 Paul Poulain 2011-07-20 15:43:11 UTC
not at all. piwik is exactly an OpenSource gg analytics: in Koha, you just have to add a link into Koha.
This link will point to piwik server, it's true, but/and it's also exactly like gganalytics. Well not exactly, because you've the choice : either you set up your own piwik server or you find one from someone else.
We (BibLibre) are investigating the idea to provide this service to our libraries (a piwik server)
I think it's very important for our freedom to have an OpenSource solution, it's a privacy question (katrin is right)
Comment 7 Juan Romay Sieira 2011-07-20 15:56:18 UTC
Ok, so, I'll get some time to investigate piwik. You're right to find and OpenSource solution.
Comment 8 Magnus Enger 2011-11-09 10:09:27 UTC
Some users might find either Google Analytics or Piwik or anything silimar disturbing. All they will see is JavaScript requests going off to somewhere unknown while they are searching, placing holds, browsing their reading history etc. This might be construed as (an unknown) Big Brother looking over their shoulder while they are using the library. 

One solution might be to only include the JS code on pages that are viewed by non-logged in users. 

Another solution could be to not track the pages that require a logged in user (like placing holds or viewing reading history), but track everyone while they are e.g. searching. 

This could be governed by a syspref, so libraries could choose what they want to track (accompanied by a small note pointing out the privacy issues). 

BTW: Piwik looks really cool! It seems they even have an API that might make it possible to display the stats collected by it *inside* Koha.
Comment 9 Magnus Enger 2011-11-09 10:16:27 UTC
Agh, I forgot half my point...

In order to get the kind of integration I'm talking about above, we need closer integration than what we can get from just chucking some JavaScript into OpacHeader or some other existing syspref.
Comment 10 Paul Poulain 2011-11-09 15:20:18 UTC
Some users might find either Google Analytics or Piwik or anything silimar
disturbing.

> Magnus, for gganalytics, you're right.
But for piwik :
 * it can be piwik.yourlibrary.org => won't be a trouble for users, it's from the library, not "big brother ggl is watching you"
 * in piwik, you've an option to not be tracked, so you can always add a link on the main page to the piwik page explaining the feature & letting the user choose to be "not tracked"

(was my 2cts)
Comment 11 Ian Walls 2012-04-06 10:08:36 UTC
*** Bug 7918 has been marked as a duplicate of this bug. ***
Comment 12 Ian Walls 2012-04-06 10:17:47 UTC
Further complications:  it can never be as simple as just inserting an ID into a syspref.  First off, we'd have to have a syspref for each analytics tool we want to support, which would probably just be GA and Piwik to start.  Not only would we need to record the ID, but both of these tools also have provisioning for Domains within the code (so you could track opac.library.tld and staff.library.tld on the same code, but with divisions in reporting).  Addtionally, for GA, you need to manually specify your particular regional server, so that would either require complicated SWITCH statements, or another syspref.

Both tools also allow for Javascript event recording, so we could record how many items are added to the Cart (as well as which ones they are, etc).  The syntax to do this is different for each tool, and would again need to be coded up.  We've have to decide on schema for how the data is collected, and probably add a series of sysprefs to govern various choices.

I think the best way to handle this, really, is just continue to allow a block of arbitrary HTML to be placed in the OPAC or staff client, and let users copy/paste the code provided by their analytics tool of choice.  We wouldn't get JS event recording this way, but it'd be the least invasive and complicated.
Comment 13 Paul Poulain 2012-04-06 14:09:52 UTC
(In reply to comment #12)
> I think the best way to handle this, really, is just continue to allow a
> block of arbitrary HTML to be placed in the OPAC or staff client, and let
> users copy/paste the code provided by their analytics tool of choice.  We
> wouldn't get JS event recording this way, but it'd be the least invasive and
> complicated.

(+1, it was that kind of idea I wanted to express in my comment 1)

About piwik: piwik requires that the JS is placed at the end of the page, it can't be placed anywhere (I don't know why, it's just what is written in the documentation: 
Display JavaScript Code

Piwik will issue you with a JavaScript code. This code must appear on every page you want Piwik to analyze. We recommend that you put this code just before your </body> at the bottom of your pages (or in a general "footer" file that is included at the bottom of your pages).
(reference: http://piwik.org/docs/installation/)
Comment 14 Liz Rea 2012-04-06 16:10:43 UTC
I have included piwik code in intranetuserjs and opacuserjs with perfect results. I don't think it *has* to go at the end of the page.

Also, I don't see why we can't just do a *userjs style entry box for people to copy/paste whatever tracking code they want into. Seems easier and more extensible.