>
> From:
> Adrian Ho <Adrian.Ho_at_mail.uh.edu>
>
>
> Greetings,
>
> A month ago, I asked some questions about whether there were products
> on the market that would help libraries manage usage statistics (of
> e-journals and databases) and calculate cost of use. Below are the
> responses I have received. Apologies for the late summary and
> thank-you to those who shared their ideas and experiences.
>
> Adrian Ho
> Collections Coordinator
> University of Houston Libraries
> (713) 743-9759 | akho_at_mail.uh.edu
>
> Transforming Scholarly Communication Blog:
> http://weblogs.lib.uh.edu/scomm/
>
> ========================
>
> Response 1:
>
> Hello!
>
> Scholarly Stats provides monthly collection of journal and database
> usage statistics. Below is the web link to their homepage.
>
> https://www.scholarlystats.com/sstats/default.htm
>
>
> Response 2:
>
> We use Scholarly Stats.n We would not recommend Scholarly Stats and are
> probably ending our usage of it soon.
>
> Why?
>
> 1. More and more databases are going to IP recognition for logins.
> So, third party vendors such as Scholarly Stats cannot access the usage
> stats. Scholarly Stats had the nerve to ask us to collect the stats and
> send to them, so they could turn around and send them back to us and
> charge us.
>
> 2. Scholarly Stats collects stats two months past. They do not
> collect current stats, so this is not useful if you need this or last
> months numbers.
>
> 3. Scholarly Stats does no trouble shooting if they cannot obtain
> the stats on the first try. They send emails to you, the client , asking
> you to fix whatever problem is occurring.
>
> So, don't waste your time or money on this product.
>
> Have a good day. We also are looking into Serial Solutions.
>
>
> Response 3:
>
> We have not looked at 360 Counter, but we did recently see a web demo of
> Scholarly Stats which tracks usage stats for e-journals and databases.
> I don't think it will calculate cost per use - maybe if costs were
> manually input.
>
> Most ERMs (Electronic Resource Management) on the market are supposed to
> handle cost per use. We are implementing Verde, but at this point we
> have not gotten any usage stats into it and also need to resolve some
> issues with getting costs to transfer from our Voyager ILS.
>
>
> Response 4:
>
> We have been looking at ScholarlyStats which has adopted SUSHI standards.
> See: https://www.scholarlystats.com/sstats/default.htm
>
> I would be very interested in any feedback from users.
>
>
> Response 5:
>
> As far as [library's name] is concerned, there still is not one good
> all-around cost-per-use tool. We use a combination of ScholarlyStats and
> Innovative Millenium ERM to get cost per use for electronic journals,
> but it doesn't apply to electronic databases. Also, the Innovative tool
> is still in Beta release and is not yet available for most institutions.
>
>
> Response 6:
>
> I haven't used it, but I did investigate 360Counter.
>
> Part of my job includes collecting the usage statistics and aggregating
> them into a spreadsheet for calculating the data we want. The egregious
> part of this is the part that involves getting the reports from each and
> every vendor for each and every database we subscribe to. Putting it all
> into the spreadsheet is by far the least annoying part of the process.
> From what I could tell, however, that's the part 360Counter takes care
> of. You still need to retrieve all of the monthly usage statistics in
> whatever format they come in and then you need to massage that data into
> a formal that Serials Solutions will accept. And then Serials Solution's
> will tell you about cost per click and things like that
>
> My opinion is that it will make more work, not less, for less value.
> (Now, if they could take my list of databases and go out and get all the
> proper usage statistics and format it and calculate what I want to know?
> That would be priceless!)
>
> But I am very curious if other folks have tried 360Counter, and what
> their experience has been.
>
>
> Response 7:
>
> Your requirements sound very much like ours were. We looked at all of
> the major players and a few of the not-so major players.
>
> We decided to de-couple the statistics requirement from the ERMS, as no
> one could meet our requirements for that area. We are planning of using
> scholarly stats for our reporting. Due to choices made by the staff
> concerning access points to our resources, no ERMS would give us
> accurate statistics.
>
> The knowledge base is the key component of your ERMS. That said, EVERY
> ERMS vendor relies of title lists provided by the database vendors.
> These lists usually have errors so ease of editing these file is
> necessary.
>
> We are not supporting a consortia arrangement, however the growth of our
> campus and programs will necessitate that ability to manage or offer the
> hook to manage resources for various campus libraries.
>
> Finally, cost was a major consideration. With those issues in mind, our
> top three ERMS systems were reSearcher (SFU), 360 (Serials Solutions)
> and ERM (III). We went with reSearcher, because it would do 90% of what
> we needed and later we could bring it in-house and run the open-source
> version of the product.
>
>
> Response 8:
>
> ... I'm sure SS staff would be glad to help you update your research
> from their side of the marketspace. They are still a dominant player
> (which as good and bad dimensions to it, as we know). Their new 360
> Counter (statistics) product is powerful, and is SUSHI and COUNTER
> enhanced. The export to EXCEL feature for this would be a boon for
> some data analysis efforts. We've only explored but not purchased this
> module yet. See more at
> http://www.serialssolutions.com/downloads/data-sheet-360-counter.pdf
>
> The competition I know of that's still viable are the previously
> mentioned TDNet <http://www.tdnet.com/> and EBSCO's A-Z
> <http://www2.ebsco.com/en-us/Documents/prodServices/20027_a-to-z_factsheet.pdf>
> [PDF]. There's no ideal ERMS yet, IMHO, but we are getting closer. The
> customization (bells-and-whistles) of any of the existing offerings is
> still lamentably shallow.
>
> In any of these choices, the key factor to consider is the underlying
> data knowledgebase they are providing, updating, and servicing. It is
> the heart of the service.
>
Received on Sat May 03 2008 - 01:43:54 EDT