a values conundrum

Scales
photo by Charles Thompson (CC BY 2.0)

‘Tis the season when I spend a lot of time gathering and consolidating usage reports for the previous calendar year (though next year not as many if my SUSHI experiment goes well). Today, as I was checking and organizing some of the reports I had retrieved last week, I noticed a journal that had very little use in the 2017 YOP (or 2016, for that matter), so I decided to look into it a bit more.

The title has a one year embargo and then the articles are open access. Our usage is very low (average 3.6 downloads per year) and most of it, according to the JR5 and JR1 GOA for confirmation, is coming from the open access portion, not the closed access we pay for.

The values conundrum I have is multifaceted. This is a small society publisher, and we have only the one title from them. They are making the content open access after one year, and I don’t think they are making authors pay for this, though I could be wrong. These are market choices I want to support. And yet….

How do I demonstrate fiscal responsibility when we are paying ~$300/download? Has the research and teaching shifted such that this title is no longer needed and that’s why usage is so low? Is this such a seminal title we would keep it regardless of whether it’s being used?

Collection development decisions are not easy when there are conflicting values.

ER&L 2010: Comparison Complexities – the challenges of automating cost-per-use data management

Speakers: Jesse Koennecke & Bill Kara

We have the use reports, but it’s harder to pull in the acquisitions information because of the systems it lives in and the different subscription/purchase models. Cornell had a cut in staffing and an immediate need to assess their resources, so they began to triage statistics cost/use requests. They are not doing systematic or comprehensive reviews of all usage and cost per use.

In the past, they have tried doing manual preparation of reports (merging files, adding data), but that’s time-consuming. They’ve had to set up processes to consistently record data from year to year. Some vendor solutions have been partially successful, and they are looking to emerging options as well. Non-publisher data such as link resolver use data and proxy logs might be sufficient for some resources, or for adding a layer to the COUNTER information to possibly explain some use. All of this has required certain skill sets (databases, spreadsheets, etc.)

Currently, they are working on managing expectations. They need to define the product that their users (selectors, administrators) can expect on a regular basis, what they can handle on request, and what might need a cost/benefit decision. In order to get accurate time estimates for the work, they looked at 17 of their larger publisher-based accounts (not aggregated collections) to get an idea of patterns and unique issues. As an unfortunate side effect, every time they look at something, they get an idea of even more projects they will need to do.

The matrix they use includes: paid titles v. total titles, differences among publishers/accounts, license period, cancellations/swaps allowed, frontfile/backfile, payment data location (package, title, membership), and use data location and standard. Some of the challenges with usage data include non-COUNTER compliance or no data at all, multiple platforms for the same title, combined subscriptions and/or title changes, titles transferred between publishers, and subscribed content v. purchased content. Cost data depends on the nature of the account and the nature of the package.

For packages, you can divide the single line item by the total use, but that doesn’t help the selectors assess the individual subset of titles relevant to their areas/budgets. This gets more complicated when you have packages and individual titles from a single publisher.

Future possibilities: better automated matching of cost and use data, with some useful data elements such as multiple cost or price points, and formulas for various subscription models. They would also like to consolidate accounts within a single publisher to reduce confusion. Also, they need more documentation so that it’s not just in the minds of long-term staff. 

css.php