There are two "movements" in librarianship that I'm quite interested in, one is of course "library 2.0" , the other which doesn't show as much because it's hard to blog about is "evidence based librarianship". I always liked figures and statistics (I enjoyed analyzing the heck out of LibQual+ data last year) and being able to "prove" that some initiative is worthwhile always makes me happy.
Some have suggested that Library 2.0 and evidence based librarianship is on
"opposite ends of the innovation scale. EBLIP is concerned with using the best available evidence, researching where possible, and making informed decisions to achieve best practice. Library 2.0 on the other hand challenges us to look beyond standard practice, ‘play’, and give new things a go."
One thing in particular I loved was embedding search boxes, in theory, search boxes would encourage users to try the search as opposed to a page with a simple link since they don't get instant gratification. But this is theory, I have no evidence to back this hypothesis.
As such I was happy to see this tweet, by Gale about libraries using the Gale Widget
and they promised to blog more about this in the future.
I suppose other databases that provide search widgets like EBSCOhost, CSA probably provide usage statistics as well. And in theory, they could provide similar statistics, or you could run experiments yourself.
But still it did not solve my problem because
(1) I want to create search widgets for any and all of the databases we have access to , regardless of whether the database vendor provides one
(2) I want usage statistics for each search widget i.e number of times the search button was clicked.
Problem (2), was harder - how could I track how often people were using the search box?
I could think of only 2 ways. Either you detect this at the destination (database end) or you detect this at the source (search box end).
Taking statistics at the destination was possible. My institution like most libraries are using EZproxy for authentication, and logs are stored. So in theory, you could look at the referrer to figure out where it came from. This is an elegant method that allows you to track what is driving traffic to all your databases but can be a massive undertaking to analyse for a large institution like ours.
The other method would be to keep track at the source.
Using Google Analytics to track usage of search boxes.
One day I noticed that Google analytics allows you to track outbound links from your site.The idea is that whenever someone clicks on a outbound link that has being specially modified on your webpage (obviously Google analytics code needs to be embedded) , the click will be recorded in Google Analytics.
The idea here is to modify not just for a normal link but also for it to work for the search box, such that each click on the search button will be recorded in Google analytics.
window.open(url + encodeURIComponent(searchInput
<div id="enterText" style="position: absolute; left: -1000em; width: 20em;">Enter your search terms:</div>
<input type="text" id="
<input type="button" value="Search" onclick="
The only change you need compared to the past is to insert the line in red. The characters in bold is what will appear in Google Analytics, under Content--Top content.
If you are doing this in Libguides, you need to split the tracking code given by GoogleAnalytics. Under system wide setting..., you need to add one part to the custom header
If you want to use Google Analytics for normal page tracking as well, add the page tracker code.
An interesting question would be whether this could work in Netvibes, I'm not quite sure whether you can insert custom headers into NetVibes page. If not the Google analytics code will not work?
Direct links vs search boxes - which is used?
With this trick you can get custom search boxes with usage tracking. So you can now measure how useful your search boxes are by the number of times they are clicked. In fact for each database, you could track 2 usage statistics...... See example below
The link text above, EconLit is hyperlinked to EconLit database. Users could click on that (call it A), or they could enter a search in the search box and click the search box (call it B).
Using Google analytic codes, one could track usage of the two.
Here's a interesting question, what do you think the ratio of B (pushing search box button) to A (clicking on hyperlink) is? about 1? Greater than 1? Less than 1?
What do you think?
To further complete matters, how about a third link that adds the opensearch plugin to the users' browser?
Improvements?A slight improvement would be to use I think two different Google Analytics codes/acounts, one for tracking normal pageviews and one of outbound links only. For the later, one could possibly filter other results to show only those triggered by clicking on outbound link for more elegant results?
ConclusionSo what do you think about this idea? Have you tracked the amount of traffic driven by search widgets? How effective are they compared to a direct link to the resource?
On second thought, the comparison above isn't fair, you probably need two seperate pages with identical content, except in one you have a straight link, in the other a search box. What type of experiments could you do at the library level to determine how much if at all embedding search widgets help compared to a straight link?