DSpace

Hi Ying,

On 25/10/12 07:07, Ying Jin wrote:
> We are interested in Google Analytics within DSpace
> http://ukcorr.blogspot.com/2012/03/using-google-analytics-statistics.html
>
> However, the implementation is on JSPUI. Is there anyone developing it
> on XMLUI?

XMLUI comes with Google Analytics support out of the box. All you should
have to do is to set your Google Analytics key in dspace.cfg. You don't
say what version of DSpace you're using; the documentation for DSpace
1.8.2 is here
https://wiki.duraspace.org/display/DSDOC18/XMLUI+Configuration+and+Customization#XMLUIConfigurationandCustomization-ManakinConfigurationPropertyKeys
(look for the  xmlui.google.analytics.key property).

cheers,
Andrea

-- 
Dr Andrea Schweer
IRR Technical Specialist, ITS Information Systems
The University of Waikato, Hamilton, New Zealand

Hi Ying,

We also have interest in this. I recently checked out Claire's code on github with the intent of analyzing what it would take to port it over to the xmlui—something I've been meaning to get back to.

If you (and hopefully others on this list) would be interested in collaborating, we probably would too. I doubt, however, that we have the resources to go at it alone.

Cheers,
Bill


From: Ying Jin <Ying.Jin@...>>
Date: Wed, 24 Oct 2012 13:07:46 -0500
To: "dspace-tech@...> Tech" <dspace-tech@...>>
Subject: [Dspace-tech] Google Analytics Statistics within DSpace on XMLUI?

Hi All,

We are interested in Google Analytics within DSpace
http://ukcorr.blogspot.com/2012/03/using-google-analytics-statistics.html

However, the implementation is on JSPUI. Is there anyone developing it on XMLUI?

Thanks,
Ying @ Rice University
------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct_______________________________________________ DSpace-tech mailing list DSpace-tech@...> https://lists.sourceforge.net/lists/listinfo/dspace-tech

Hi all,

if you want to collaborate on this, it would be best to create an
issue (or multiple issues) in Jira describing what needs to be done
and who's doing it. It will prevent duplication of work and allow
everyone to check the status of such work. It's also desirable to link
to code on GitHub from the issue(s).

You may also want to coordinate with Peter Dietz (should be on this
list), who has developed another statistics implementation (Elastic
search) in addition to Solr statistics (Mark Diggory will want to have
a say in that, too). It may turn out that there's a need for a
framework supporting different statistics implementations/backends
(Solr, Elastic, Analytics, ...), while allowing to use the same
presentation elements (like graphs) with any of them.

Regards,
~~helix84

This is good. I have not had a chance to play around with Elastic Search,
so I will definitely look into that. We actually have Mark's Solr stats
running now. What it lacks‹really, what they all lack‹is a sure-fire way
making only counting real users.

If you are anything like us, then you know most of your traffic is robots.
You obviously don't want them counted in your stats. The blacklist
approach does not work; it doesn't come close, unless you have a full time
person working to keep the list up to date.

The Google Analytics approach is better, but it comes with its own set of
problems. Like, links from Google have to go to the item page, not
directly to the PDF, in order to be counted.

A third idea I've been kicking around is to augment the current system
with ping-back, so only the downloads and page visits that respond to the
ping back are counted. That would probably take the least work to
implement, but it could have issues as well.

This is going a bit long, but let me add that I am surprised that this is
not a bigger concern within the community. Accurate statistics are key to
measuring an article's impact, and the impact of the repository itself. It
definitely influences buy-in: both faculty participation and institutional
support. 

Anyway, thanks for the input. I wonder, does anyone else have any insight
into gathering accurate statistics?

Cheers, 
Bill




On 10/24/12 6:44 PM, "helix84" <helix84@...> wrote:

>Hi all,
>
>if you want to collaborate on this, it would be best to create an
>issue (or multiple issues) in Jira describing what needs to be done
>and who's doing it. It will prevent duplication of work and allow
>everyone to check the status of such work. It's also desirable to link
>to code on GitHub from the issue(s).
>
>You may also want to coordinate with Peter Dietz (should be on this
>list), who has developed another statistics implementation (Elastic
>search) in addition to Solr statistics (Mark Diggory will want to have
>a say in that, too). It may turn out that there's a need for a
>framework supporting different statistics implementations/backends
>(Solr, Elastic, Analytics, ...), while allowing to use the same
>presentation elements (like graphs) with any of them.
>
>Regards,
>~~helix84

On Thu, Oct 25, 2012 at 3:58 AM, Ingram, William A
<wingram2@...> wrote:
> Anyway, thanks for the input. I wonder, does anyone else have any insight
> into gathering accurate statistics?

I'm copying in João Melo. He might have somthing to say about the
future of statistics, too :)

Regards,
~~helix84

We "hacked" our XMLUI to use a local Piwik stats server.
See snippet below.
###
        <!-- Add a google analytics script if the key is present
        <xsl:if
test="/dri:document/dri:meta/dri:pageMeta/dri:metadata[@element='google'][@qualifier='analytics']">
            <script type="text/javascript"><xsl:text>
                   var _gaq = _gaq || [];
                   _gaq.push(['_setAccount', '</xsl:text><xsl:value-of
select="/dri:document/dri:meta/dri:pageMeta/dri:metadata[@element='google'][@qualifier='analytics']"/><xsl:text>']);
                   _gaq.push(['_trackPageview']);

                   (function() {
                       var ga = document.createElement('script'); ga.type =
'text/javascript'; ga.async = true;
                       ga.src = ('https:' == document.location.protocol ? '
https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
                       var s = document.getElementsByTagName('script')[0];
s.parentNode.insertBefore(ga, s);
                   })();
           </xsl:text></script>
        </xsl:if>
-->

<!-- Piwik W Klapwijk 2012-01 -->
        <xsl:if
test="/dri:document/dri:meta/dri:pageMeta/dri:metadata[@element='google'][@qualifier='analytics']">
     <script type="text/javascript">
         <xsl:text>var pkBaseURL = (("https:" ==
document.location.protocol) ? "https://piwik.sun.ac.za/" : "
http://piwik.sun.ac.za/");</xsl:text>
         <xsl:text>document.write(unescape("%3Cscript src='" + pkBaseURL +
"piwik.js' type='text/javascript'%3E%3C/script%3E"));</xsl:text>
     </script>

<script type="text/javascript">
    <xsl:text>
     try {
       </xsl:text>
       <xsl:text>var piwikTracker = Piwik.getTracker(pkBaseURL +
"piwik.php", 3); </xsl:text>
       <xsl:text>piwikTracker.trackPageView();</xsl:text>
       <xsl:text>piwikTracker.enableLinkTracking();</xsl:text>
       <xsl:text>
     }
      catch( err ) {
     }
       </xsl:text>
</script>
        </xsl:if>
###

On 25 October 2012 10:03, helix84 <helix84@...> wrote:

> On Thu, Oct 25, 2012 at 3:58 AM, Ingram, William A
> <wingram2@...> wrote:
> > Anyway, thanks for the input. I wonder, does anyone else have any insight
> > into gathering accurate statistics?
>
> I'm copying in João Melo. He might have somthing to say about the
> future of statistics, too :)
>
> Regards,
> ~~helix84
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
> _______________________________________________
> DSpace-tech mailing list
> DSpace-tech@...
> https://lists.sourceforge.net/lists/listinfo/dspace-tech
>



-- 
*Hilton Gibson*
Systems Administrator
JS Gericke Library
Room 1025D
Stellenbosch University
Private Bag X5036
Stellenbosch
7599
South Africa

Tel: +27 21 808 4100 | Cell: +27 84 646 4758
http://library.sun.ac.za
http://scholar.sun.ac.za

Hi Bill,

Sure that we are interested in porting it over to XMLUI if it is not  
there yet. And it would be nice if we can collaborate on it. Let's  
talk about off the list.

Best,
Ying



On Oct 24, 2012, at 4:54 PM, Ingram, William A wrote:

> Hi Ying,
>
> We also have interest in this. I recently checked out Claire's code  
> on github with the intent of analyzing what it would take to port it  
> over to the xmlui—something I've been meaning to get back to.
>
> If you (and hopefully others on this list) would be interested in  
> collaborating, we probably would too. I doubt, however, that we have  
> the resources to go at it alone.
>
> Cheers,
> Bill
>
>
> From: Ying Jin <Ying.Jin@...>
> Date: Wed, 24 Oct 2012 13:07:46 -0500
> To: "dspace-tech@... Tech" <dspace-tech@... 
> >
> Subject: [Dspace-tech] Google Analytics Statistics within DSpace on  
> XMLUI?
>
> Hi All,
>
> We are interested in Google Analytics within DSpace
> http://ukcorr.blogspot.com/2012/03/using-google-analytics-statistics.html
>
> However, the implementation is on JSPUI. Is there anyone developing  
> it on XMLUI?
>
> Thanks,
> Ying @ Rice University
> ------------------------------------------------------------------------------ Everyone 
>  hates slow websites. So do we. Make your web apps faster with  
> AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct_______________________________________________ 
>  DSpace-tech mailing list DSpace-tech@... https://lists.sourceforge.net/lists/listinfo/dspace-tech

I will take a look at the Elastic too. Thanks, Ying

On Oct 24, 2012, at 5:44 PM, helix84 wrote:

> Hi all,
>
> if you want to collaborate on this, it would be best to create an
> issue (or multiple issues) in Jira describing what needs to be done
> and who's doing it. It will prevent duplication of work and allow
> everyone to check the status of such work. It's also desirable to link
> to code on GitHub from the issue(s).
>
> You may also want to coordinate with Peter Dietz (should be on this
> list), who has developed another statistics implementation (Elastic
> search) in addition to Solr statistics (Mark Diggory will want to have
> a say in that, too). It may turn out that there's a need for a
> framework supporting different statistics implementations/backends
> (Solr, Elastic, Analytics, ...), while allowing to use the same
> presentation elements (like graphs) with any of them.
>
> Regards,
> ~~helix84
>

On Thu, Oct 25, 2012 at 7:21 PM, Ying Jin <Ying.Jin@...> wrote:
> Sure that we are interested in porting it over to XMLUI if it is not there
> yet. And it would be nice if we can collaborate on it. Let's talk about off
> the list.

Why not do this in public? You can continue the discussion here and
benefit from additional advice, this already attracted a lot of people
and may be interesting to many others. You could start by defining
your requirements, I think there might be some pieces of work already
done that you may use.

Regards,
~~helix84

Just would like to follow up this. We are currently under DSpace 1.7.2  
and looking forward to upgrade to 3.0 once it is released next month.  
The current Google analytics stat within DSpace is on 1.8.2. We would  
like to work on the interface with XMLUI for it based on 3.0. However,  
it may depend on when the package is upgraded. It would be great to  
know the plan from the folks who are working on this project.

Thanks,
Ying

On Oct 24, 2012, at 8:58 PM, Ingram, William A wrote:

> This is good. I have not had a chance to play around with Elastic  
> Search,
> so I will definitely look into that. We actually have Mark's Solr  
> stats
> running now. What it lacks‹really, what they all lack‹is a sure-fire  
> way
> making only counting real users.
>
> If you are anything like us, then you know most of your traffic is  
> robots.
> You obviously don't want them counted in your stats. The blacklist
> approach does not work; it doesn't come close, unless you have a  
> full time
> person working to keep the list up to date.
>
> The Google Analytics approach is better, but it comes with its own  
> set of
> problems. Like, links from Google have to go to the item page, not
> directly to the PDF, in order to be counted.
>
> A third idea I've been kicking around is to augment the current system
> with ping-back, so only the downloads and page visits that respond  
> to the
> ping back are counted. That would probably take the least work to
> implement, but it could have issues as well.
>
> This is going a bit long, but let me add that I am surprised that  
> this is
> not a bigger concern within the community. Accurate statistics are  
> key to
> measuring an article's impact, and the impact of the repository  
> itself. It
> definitely influences buy-in: both faculty participation and  
> institutional
> support.
>
> Anyway, thanks for the input. I wonder, does anyone else have any  
> insight
> into gathering accurate statistics?
>
> Cheers,
> Bill
>
>
>
>
> On 10/24/12 6:44 PM, "helix84" <helix84@...> wrote:
>
>> Hi all,
>>
>> if you want to collaborate on this, it would be best to create an
>> issue (or multiple issues) in Jira describing what needs to be done
>> and who's doing it. It will prevent duplication of work and allow
>> everyone to check the status of such work. It's also desirable to  
>> link
>> to code on GitHub from the issue(s).
>>
>> You may also want to coordinate with Peter Dietz (should be on this
>> list), who has developed another statistics implementation (Elastic
>> search) in addition to Solr statistics (Mark Diggory will want to  
>> have
>> a say in that, too). It may turn out that there's a need for a
>> framework supporting different statistics implementations/backends
>> (Solr, Elastic, Analytics, ...), while allowing to use the same
>> presentation elements (like graphs) with any of them.
>>
>> Regards,
>> ~~helix84
>
>

Hi Ying,

I'm sorry but I'm not sure I understood the last part. Were you asking
about the release schedule? Here it is, but keep in mind that it still
might slip, even 1-2 weeks:

https://wiki.duraspace.org/display/DSPACE/DSpace+Release+3.0+Notes#DSpaceRelease3.0Notes-TimelineandProcessing

So you would like to work on the interface for displaying Google
Analytics stats within DSpace once 3.0 is released? That's great! And
you don't have to wait for the release, either. Just grab the latest
code from Git:

https://github.com/DSpace/DSpace

There's even a button there that will give you the latest code as a ZIP.

If you prefer to work on a stable version, it's safe to implement your
XMLUI changes on top of 1.8.2. You'd be working mostly with XSLT and
there were no significant changes there between 1.8 and 3.0.

If you need any help, just ask here or in the Jira issue comments.

Regards,
~~helix84

It is not clear to me what "Google Analytics support for JSPUI"  
means in DSpace 3.0 new features. It would be nice if it is part of  
DSpace 3.0 already. And I should be able to work on it soon.

Bill, would you like to cooperate on it based 3.0? If so, we can  
discuss the details.

Thanks,
Ying

On Oct 30, 2012, at 3:03 PM, helix84 wrote:

> Hi Ying,
>
> I'm sorry but I'm not sure I understood the last part. Were you asking
> about the release schedule? Here it is, but keep in mind that it still
> might slip, even 1-2 weeks:
>
> https://wiki.duraspace.org/display/DSPACE/DSpace+Release 
> +3.0+Notes#DSpaceRelease3.0Notes-TimelineandProcessing
>
> So you would like to work on the interface for displaying Google
> Analytics stats within DSpace once 3.0 is released? That's great! And
> you don't have to wait for the release, either. Just grab the latest
> code from Git:
>
> https://github.com/DSpace/DSpace
>
> There's even a button there that will give you the latest code as a  
> ZIP.
>
> If you prefer to work on a stable version, it's safe to implement your
> XMLUI changes on top of 1.8.2. You'd be working mostly with XSLT and
> there were no significant changes there between 1.8 and 3.0.
>
> If you need any help, just ask here or in the Jira issue comments.
>
> Regards,
> ~~helix84
>

It means that JSPUI now contains the counting Javascript and you just need
to put your GA key into the configuration file to enable it.

This has been on XMLUI for some time, but was missing in JSPUI.

There's nothing in DSpace at the moment to *display* the GA results.

You didn't answer my questions so I'm not sure what you'd like to work on.
 Dňa 30.10.2012 22:13, "Ying Jin" <Ying.Jin@...> napísal(-a):

>  It is not clear to me what "Google Analytics support for JSPUI" means in
> DSpace 3.0 new features. It would be nice if it is part of DSpace 3.0
> already. And I should be able to work on it soon.
>
> Bill, would you like to cooperate on it based 3.0? If so, we can discuss
> the details.
>
> Thanks,
> Ying
>
> On Oct 30, 2012, at 3:03 PM, helix84 wrote:
>
> Hi Ying,
>
> I'm sorry but I'm not sure I understood the last part. Were you asking
> about the release schedule? Here it is, but keep in mind that it still
> might slip, even 1-2 weeks:
>
> https://wiki.duraspace.org/display/DSPACE/DSpace+Release+3.0+Notes
> #DSpaceRelease3.0Notes-TimelineandProcessing
>
> So you would like to work on the interface for displaying Google
> Analytics stats within DSpace once 3.0 is released? That's great! And
> you don't have to wait for the release, either. Just grab the latest
> code from Git:
>
> https://github.com/DSpace/DSpace
>
> There's even a button there that will give you the latest code as a ZIP.
>
> If you prefer to work on a stable version, it's safe to implement your
> XMLUI changes on top of 1.8.2. You'd be working mostly with XSLT and
> there were no significant changes there between 1.8 and 3.0.
>
> If you need any help, just ask here or in the Jira issue comments.
>
> Regards,
> ~~helix84
>
>
>

Hi All,

My apologies for not getting back you sooner—I've been out of town.

I don't know if working on a 3.0 version is the approach we will want to take. I doubt we will be in a position to move to 3.0 until next fiscal year (school year) at the earliest. Maybe not, but I'd rather be conservative. We're not ready now.

Nevertheless, I would be very surprised if most, if not all, of a solution for 1.x couldn't be easily ported to 3.x. I have not had a chance to thoroughly dig into the 3.0 codebase, but I would guess the changes are not that radical. But if it turns out 3.0 is so entirely different from 1.x, then we are even less likely to move to it in the short term.

Long story short: I am only interested in a solution that will work for 1.x.

As far as I am concerned, the current tools available for displaying stats work fine: Atmire stats, Elastic Search etc. The piece that needs improvement is accurate stats recording. It would seem that is where we should focus our efforts. The crucial ingredient to Edinburgh's GA stats system is forcing outside, direct links to open the item page, rather than hitting the PDF directly (otherwise the download isn't counted). I doubt that would be different in 3.0.

Bill




From: ivan.masar@... [mailto:ivan.masar@...] On Behalf Of helix84
Sent: Tuesday, October 30, 2012 5:12 PM
To: Ying Jin
Cc: dspace-tech; Ingram, William A
Subject: Re: [Dspace-tech] Google Analytics Statistics within DSpace on XMLUI?


It means that JSPUI now contains the counting Javascript and you just need to put your GA key into the configuration file to enable it.

This has been on XMLUI for some time, but was missing in JSPUI.

There's nothing in DSpace at the moment to *display* the GA results.

You didn't answer my questions so I'm not sure what you'd like to work on.
Dňa 30.10.2012 22:13, "Ying Jin" <Ying.Jin@...>> napísal(-a):
 It is not clear to me what "Google Analytics support for JSPUI" means in DSpace 3.0 new features. It would be nice if it is part of DSpace 3.0 already. And I should be able to work on it soon.

Bill, would you like to cooperate on it based 3.0? If so, we can discuss the details.

Thanks,
Ying

On Oct 30, 2012, at 3:03 PM, helix84 wrote:


Hi Ying,

I'm sorry but I'm not sure I understood the last part. Were you asking
about the release schedule? Here it is, but keep in mind that it still
might slip, even 1-2 weeks:

https://wiki.duraspace.org/display/DSPACE/DSpace+Release+3.0+Notes#DSpaceRelease3.0Notes-TimelineandProcessing

So you would like to work on the interface for displaying Google
Analytics stats within DSpace once 3.0 is released? That's great! And
you don't have to wait for the release, either. Just grab the latest
code from Git:

https://github.com/DSpace/DSpace

There's even a button there that will give you the latest code as a ZIP.

If you prefer to work on a stable version, it's safe to implement your
XMLUI changes on top of 1.8.2. You'd be working mostly with XSLT and
there were no significant changes there between 1.8 and 3.0.

If you need any help, just ask here or in the Jira issue comments.

Regards,
~~helix84

Dňa 31.10.2012 0:07, "Ingram, William A" <wingram2@...>
napísal(-a):
> Nevertheless, I would be very surprised if most, if not all, of a
solution for 1.x couldn't be easily ported to 3.x. I have not had a chance
to thoroughly dig into the 3.0 codebase, but I would guess the changes are
not that radical. But if it turns out 3.0 is so entirely different from
1.x, then we are even less likely to move to it in the short term.

You're right, there are no radical changes.

> As far as I am concerned, the current tools available for displaying
stats work fine: Atmire stats, Elastic Search etc. The piece that needs
improvement is accurate stats recording. It would seem that is where we
should focus our efforts. The crucial ingredient to Edinburgh's GA stats
system is forcing outside, direct links to open the item page, rather than
hitting the PDF directly (otherwise the download isn't counted). I doubt
that would be different in 3.0.

Although you confused me by mentioning Solr/ES stats (I thought this thread
is about GA), it should be doable with a little Cocoon site map magic. What
you want is the bitstream link to be a redirect to the actual bitstream,
and where the redirect would also trigger the counter. In case of GA the
counter is Javascript so it can't be HTTP 302, but rather a meta tags
redirect so that the JS gets a chance to run. Maybe there's a way to bypass
the JS and count the hit by doing what the JS does server-side, and but I
imagine this would be unsupported by GA.
A similar but alternative approach would be to keep the bitstream url
pointing directly at the bitstream and create another url in its stead with
the functionality is mentioned (redirect to bitstream) , I then replace all
occurrences of the bitstream link with the later. Both have its pros and
cons when used with non-interactive user agents (like wget/curl).

Regards,
~~helix84

Although you confused me by mentioning Solr/ES stats

I am a bit confused myself. It would help if I looked into how these things work before I say any more—minimize the damage.

Cheers,
Bill



On Oct 30, 2012, at 6:28 PM, helix84 <helix84@...>>
 wrote:


Dňa 31.10.2012 0:07, "Ingram, William A" <wingram2@...>> napísal(-a):
> Nevertheless, I would be very surprised if most, if not all, of a solution for 1.x couldn't be easily ported to 3.x. I have not had a chance to thoroughly dig into the 3.0 codebase, but I would guess the changes are not that radical. But if it turns out 3.0 is so entirely different from 1.x, then we are even less likely to move to it in the short term.

You're right, there are no radical changes.

> As far as I am concerned, the current tools available for displaying stats work fine: Atmire stats, Elastic Search etc. The piece that needs improvement is accurate stats recording. It would seem that is where we should focus our efforts. The crucial ingredient to Edinburgh's GA stats system is forcing outside, direct links to open the item page, rather than hitting the PDF directly (otherwise the download isn't counted). I doubt that would be different in 3.0.

Although you confused me by mentioning Solr/ES stats (I thought this thread is about GA), it should be doable with a little Cocoon site map magic. What you want is the bitstream link to be a redirect to the actual bitstream, and where the redirect would also trigger the counter. In case of GA the counter is Javascript so it can't be HTTP 302, but rather a meta tags redirect so that the JS gets a chance to run. Maybe there's a way to bypass the JS and count the hit by doing what the JS does server-side, and but I imagine this would be unsupported by GA.
A similar but alternative approach would be to keep the bitstream url pointing directly at the bitstream and create another url in its stead with the functionality is mentioned (redirect to bitstream) , I then replace all occurrences of the bitstream link with the later. Both have its pros and cons when used with non-interactive user agents (like wget/curl).

Regards,
~~helix84

On Wed, Oct 31, 2012 at 2:09 AM, Ingram, William A
<wingram2@...> wrote:
> > Although you confused me by mentioning Solr/ES stats
>
> I am a bit confused myself. It would help if I looked into how these things
> work before I say any more—minimize the damage.

Alright, these 3 statistics are completely independent systems within
DSpace: Solr stats / Elastic Search and Google Analytics.

Solr stats - has been in DSpace since about 1.5, listens to internal
"events" in DSpace, should log everything including bitstream
downloads, uses Solr to store them, there are optional interfaces to
display these stats in DSpace, like the commercial addon from @mire.

Elastic Search - a new work by Peter Dietz, debuting in 3.0, also
listens to the same events, should log everything that Solr does, uses
different storage system, has some interfaces with graphs for DSpace
available out-of-the-box

Google Analytics - In DSpace this is only the Javascript snippets that
*records* hits, stores it in Google, has *currently no way of
displaying* the stats in DSpace interface (I thought this is the
development you were interested in), this snippet has been in XMLUI
and will be in JSPUI from 3.0

So those are the out-of-the-box statistics that are in DSpace. Plus
you can extract statistics from logs.

Available as a separate addon, there are Minho stats (also with
displaying capabilities), which I'm sure you'll hear more about in the
following year.

I hope that clears it up.


Regards,
~~helix84

Compulsory reading: DSpace Mailing List Etiquette
https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette

> Solr stats - has been in DSpace since about 1.5, listens to internal
> "events" in DSpace, should log everything including bitstream
> downloads, uses Solr to store them, there are optional interfaces to
> display these stats in DSpace, like the commercial addon from @mire.
>
> Elastic Search - a new work by Peter Dietz, debuting in 3.0, also
> listens to the same events, should log everything that Solr does, uses
> different storage system, has some interfaces with graphs for DSpace
> available out-of-the-box
>
> Google Analytics - In DSpace this is only the Javascript snippets that
> *records* hits, stores it in Google, has *currently no way of
> displaying* the stats in DSpace interface (I thought this is the
> development you were interested in), this snippet has been in XMLUI
> and will be in JSPUI from 3.0

Thanks for the explanation! I think making Google Analytics statistics  
viewable within the DSpace has been implemented by University of  
Edinbergh on JSPUI. We are interested in having this displayed on XMLUI.
http://ukcorr.blogspot.com/2012/03/using-google-analytics-statistics.html

The code is available at git too
https://github.com/seesmith/Dspace-googleanalytics

Best,
Ying