http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6610 --- Comment #2 from Owen Leonard <oleonard@myacpl.org> 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. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6610 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |katrin.fischer@bsz-bw.de --- Comment #3 from Katrin Fischer <katrin.fischer@bsz-bw.de> 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. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6610 --- Comment #5 from Juan Romay Sieira <juan.sieira@xercode.es> 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. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6610 --- Comment #7 from Juan Romay Sieira <juan.sieira@xercode.es> 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. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6610 Magnus Enger <magnus@enger.priv.no> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |magnus@enger.priv.no --- Comment #8 from Magnus Enger <magnus@enger.priv.no> 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. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug. You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6610

--- Comment #10 from Paul Poulain <paul.poulain@biblibre.com> 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)

-- 
Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA Contact for the bug.
You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6610 Ian Walls <koha.sekjal@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |In Discussion CC| |koha.sekjal@gmail.com --- Comment #12 from Ian Walls <koha.sekjal@gmail.com> --- 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. -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6610 Liz Rea <wizzyrea@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |wizzyrea@gmail.com --- Comment #14 from Liz Rea <wizzyrea@gmail.com> --- 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. -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.