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.
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
> so I will definitely look into that. We actually have Mark's Solr
> running now. What it lacks‹really, what they all lack‹is a sure-fire
> making only counting real users.
> If you are anything like us, then you know most of your traffic is
> 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
> Anyway, thanks for the input. I wonder, does anyone else have any
> into gathering accurate statistics?
> 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
>> 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
>> 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.