[Eril-l] EBSCO Usage Consolidation Pricing change
Jessica Harris
jaharris at scu.edu
Sun May 3 09:00:06 PDT 2015
We began subscribing to UC in January and have had a few issues with it as
well. One of the main reasons we chose this service over the others was
because, as a serials agent, EBSCO does a great job with their reporting
features and they also tend to hire very knowledgeable, service-oriented
staff. We were hoping for a more thorough integration with the data already
held in EBSCONET, however. These are the issues that we've been seeing with
UC:
1. Reporting: When looking at usage, we need to see it for each
individually purchased subscription; otherwise these stats are of little
use for renewal/cancellation decisions. Unfortunately, the only way to pull
a report for only those journals we intentionally subscribe to is to do so
within their "Subscription Usage Details" report, which does not allow
customization or the ability to choose more than one year at a time.
Because of this, any JR1 reports that we pull require a great deal of data
manipulation and staff time (particularly with the merging of multiple
spreadsheets & the amount of data cleanup needed). EBSCONET itself contains
a wealth of information and their usage reports would be much more valuable
to us if they allowed us to choose which data to pull into our reports.
2. Definitely the JSTOR & Project MUSE issues. Every journal that we got
through either of these platforms needed to have their usage retrieved
manually. Also, all Highwire statistics were doubled, which took us some
time to figure out.
3. Platforms that hadn't yet been connected to UC show up in our
statistics as 0, rather than N/A. We had no easy way to distinguish between
these journals and journals that actually had zero use. This seems like it
should be an easy fix for EBSCO.
4. The usage stats for the journal packages we get through EBSCO were
inconsistent. We were told by Support that this number should be the total
usage for all journals contained within the package, but found that this
wasn't always the case. All packages needed to be reviewed manually.
I do think that UC has the potential to be valuable for our assessments,
but improvements are definitely needed.
------
Jessica Harris, Head of Electronic Resources & Serials
Santa Clara University Library
jaharris at scu.edu or eresources at scu.edu
(408) 554-5356
On Fri, May 1, 2015 at 9:40 AM, Marcia Thomas <mthomas at iwu.edu> wrote:
> We have had UC and the loading service for almost two years. While I've
> very much appreciated the work of Oliver Pesch, who helped us through
> difficult configurations, I've been disappointed with the product. I'm a
> neophyte when it comes to the technology side of e-resources, so I've
> appreciated the learning opportunities of setting up our many manually
> configured platforms. I could have used a LOT more help from the "Help"
> documentation, which is too often incomplete, misleading, cryptic, or out
> of date. We're locked in for another year, but I've been seriously
> contemplating just doing the work internally, depending on local staffing.
> After reading Roen and Tricia's posts, I'm leaning harder in that direction.
>
> Marcia Thomas
> Illinois Wesleyan University
> Bloomington, Illinois
>
> On Thu, Apr 30, 2015 at 5:01 PM, Roen Janyk <RJanyk at okanagan.bc.ca> wrote:
>
>> I responded to Mary directly, but would like to say we cancelled UC and
>> ULS as of March 31st because of all the reasons listed below. It became
>> apparent for a library of our size, it was more cost effective to have an
>> internal staff member doing the work, rather than EBSCO. It took a
>> considerable amount of monitoring and tweaking, and I still wasn't
>> completely certain I could trust all of the information. We are happy to
>> use our ERM's SUSHI capabilities and a staff member who runs stats reports
>> on a regular basis.
>>
>> Roën
>>
>>
>> Roën Janyk, MLIS
>> Web Services Librarian
>> Library Department Chair
>> Okanagan College
>> Kelowna, BC
>> (250) 762-5445 x.4660 | L101A
>> rjanyk at okanagan.bc.ca
>>
>> -----Original Message-----
>> From: Eril-l [mailto:eril-l-bounces at lists.eril-l.org] On Behalf Of
>> Tricia Clayton
>> Sent: Thursday, April 30, 2015 2:56 PM
>> To: VanUllen, Mary K
>> Cc: eril-l at lists.eril-l.org
>> Subject: Re: [Eril-l] EBSCO Usage Consolidation Pricing change
>>
>> We have been using Usage Consolidation for a few years now. We were not
>> very pleased a few months ago when we learned about the new business model
>> of bundling UC renewal with a mandatory usage loading service for 5
>> platforms.
>>
>> We did renew - we have invested a lot into setting the system up and are
>> seeing the benefits of having our usage data consolidated. But I think
>> we'll be monitoring this development closely. Here are our biggest issues
>> with the loading service - some of which other posters have mentioned.
>>
>> 1) We have already configured, historically loaded, and performed initial
>> troubleshooting on all of our COUNTER compliant platforms. All that is
>> left for the loading service to do now is load reports for 5 platforms
>> twice a year. This really doesn't take very long. For the minimal amount
>> of time this takes, I suspect we are paying EBSCO at a higher rate than we
>> are paying our staff member who is responsible for the rest of our loading.
>>
>> 2) There is more to our workflow than just loading reports in Usage
>> Consolidation. For example, we store the original reports on our network,
>> and in some cases we collect more report types than UC can handle. So, we
>> can't sit back and ignore these platforms even though EBSCO is going to
>> take over part of the work. How much time is this really saving us?
>>
>> 3) As others have mentioned, loading of some platforms is rather
>> complex. And while the idea of SUSHI is attractive, for now we have
>> abandoned the practice because it required too much monitoring to see if it
>> was working correctly. I'm not sure to what extent I trust an outside
>> organization to do things accurately. And I'm not sure how much "tracking"
>> we'll really be required to do in order to ensure quality control. For
>> these reasons, we didn't take full advantage of the service. We gave them
>> EBSCO's own platform, and a couple additional tricky ones, but we did not
>> pass off the ones we have found most troublesome. We just finished the
>> license negotiation [yes, we needed another one, and at my institution this
>> is no fast task!], so we haven't had our first loads yet. We'll see how
>> this year goes - if things go well, we might think about passing off more
>> difficult platforms in the future.
>>
>> Tricia
>>
>> Tricia Clayton
>> Collection Services Librarian
>> Georgia State University Library
>> 404-413-2867
>>
>>
>> -----Original Message-----
>> From: Eril-l [mailto:eril-l-bounces at lists.eril-l.org] On Behalf Of
>> Loder, Julie L
>> Sent: Thursday, April 30, 2015 1:35 PM
>> To: 'Annie Erdmann'; VanUllen, Mary K
>> Cc: eril-l at lists.eril-l.org
>> Subject: Re: [Eril-l] EBSCO Usage Consolidation Pricing change
>>
>> We have been using both the loading service and in Usage Consolidation we
>> are setting up some publishers using the SUSHI harvesting tool. We are
>> pretty happy with it. And, I am quite happy to let them reload when a
>> publisher announces problems.
>>
>>
>>
>> My only concern has been addressed below and that is the difference
>> between JSTOR current subscriptions, which should be in the publisher cost
>> per use data and the archive, which should not. Same with Project single
>> title add-ons. I was told quite a while back that Ebsco was working with
>> JSTOR specifically on this issue, but I haven’t had any updates in a
>> while. It seems like more of an issue with the providers and how they
>> supply the data than any usage collection tool.
>>
>>
>>
>> Julie
>>
>>
>>
>> From: Eril-l [mailto:eril-l-bounces at lists.eril-l.org] On Behalf Of Annie
>> Erdmann
>> Sent: Thursday, April 30, 2015 12:13 PM
>> To: VanUllen, Mary K
>> Cc: eril-l at lists.eril-l.org
>> Subject: Re: [Eril-l] EBSCO Usage Consolidation Pricing change
>>
>>
>>
>> Hi Mary,
>>
>>
>>
>> We use the Usage Consolidation Service here at Simmons College. I love
>> the product and the data we can get out of it, but I also think that the 5
>> platform loading service is gratuitous. I am not sure why that is a
>> required part of the business model for this product. I felt odd about
>> having them load usage from their direct competitors. So, I selected Ebsco
>> as one of my platforms and then just picked 4 other publishers. Honestly,
>> it was more inconvenient than a service to me.
>>
>>
>>
>> The only other concern for me is that the product does not seem to do a
>> good job of picking up on publisher platform statistics when the primary
>> platform is JSTOR, Project Muse, etc. I had to adjust those stats in my
>> reports manually. I did open a ticket or two at first to report that the
>> primary publishers platform was wrong, but Ebsco wasn't treating it as a
>> global problem, so I gave up on making 15 or so support tickets.
>>
>>
>>
>> I have found that if you have a problem loading the stats yourself, then
>> Ebsco will have problems also. I picked easy reports for them to load that
>> I knew would work.
>>
>>
>>
>> annie
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------------------------
>>
>>
>>
>> Annie Erdmann
>>
>> Digital Assets/ eResources Librarian
>>
>> Simmons College Library
>>
>> Boston MA 02115
>>
>> 617-521-2723
>>
>> erdmann at simmons.edu
>>
>>
>>
>> On Thu, Apr 30, 2015 at 11:48 AM, VanUllen, Mary K <mvanullen at albany.edu>
>> wrote:
>>
>> We’ve been using EBSCO’s Usage Consolidation for a few years to
>> centralize our usage data. We’ve just been told that going forward, they
>> are only going to offer this in combination with their usage loading
>> service. Their standard cost will include configuring and loading five
>> platforms. That will bump up our costs for the service by a significant
>> percentage and I see no benefit to us.
>>
>>
>>
>> I’m baffled (and annoyed) by this as a business decision. We have about
>> 100 platforms, and the majority of them are configured already. There is
>> enough complexity to gathering, vetting and uploading the statistics that I
>> am concerned about having them handle the more problematic platforms. I
>> worry about them capturing all the data for titles that change platforms
>> during the year and about things like JSTOR, where the Current Scholarship
>> titles need to be handled differently than the archival data in order to be
>> meaningful. My experience with trying to gather stats with SUSHI has not
>> been positive and makes me wonder if we would be missing chunks of data if
>> we weren’t monitoring the stats closely ourselves and just trusted EBSCO to
>> handle it.
>>
>>
>>
>> For those of you who are Usage Consolidation users now, do you already
>> pay for the usage loading service and how well have you found it to work?
>> Does it really cut down your workload or do you still have to do a lot of
>> troubleshooting? Do you just pay for five platforms or do you have them
>> handle everything?
>>
>>
>>
>> Any thoughts or insights would be helpful.
>>
>>
>>
>> Thanks,
>>
>> --Mary
>>
>>
>>
>>
>>
>> Mary K. Van Ullen
>>
>> Associate Director for Collections
>>
>> University Library, LI-328
>>
>> University at Albany
>>
>> 1400 Washington Avenue
>>
>> Albany, NY 12110
>>
>> (518) 442-3559 <tel:%28518%29%20442-3559>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Eril-l mailing list
>> Eril-l at lists.eril-l.org
>> http://lists.eril-l.org/listinfo.cgi/eril-l-eril-l.org
>>
>>
>>
>> _______________________________________________
>> Eril-l mailing list
>> Eril-l at lists.eril-l.org
>> http://lists.eril-l.org/listinfo.cgi/eril-l-eril-l.org
>> _______________________________________________
>> Eril-l mailing list
>> Eril-l at lists.eril-l.org
>> http://lists.eril-l.org/listinfo.cgi/eril-l-eril-l.org
>>
>
>
> _______________________________________________
> Eril-l mailing list
> Eril-l at lists.eril-l.org
> http://lists.eril-l.org/listinfo.cgi/eril-l-eril-l.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.eril-l.org/pipermail/eril-l-eril-l.org/attachments/20150503/3f136072/attachment-0001.html>
More information about the Eril-l
mailing list