COUNTER SUSHI Oliver Pesch, ALA Annual June 2016

Editor's Notes

• #2: Good afternoon.... I am Oliver Pesch and I am here to talk about COUNTER and SUSHI... I work as product strategist for EBSCO and I also do a lot of work with COUNTER and NISO. For COUNTER I serve on the board of directors, the Executive Committee and am chair of the COUNTER Release 5 Technical Working Group. For NISO I serve on the board of directors and am co-chair of the NISO SUSHI Standing Committee.
• #3: Likely most of you are quite familiar with both COUNTER and SUSHI so I will keep the introduction brief so we can discuss recent developments and take a look a head to what is in store for us.
• #4: Lets start with a quick background on COUNTER and SUSHI
• #5: COUNTER is a Code of Practice for usage reporting – consistent, credible and compatible usage reporting. The code specifies the reports to provide, how they should be formatted, what metrics to include, how transactions should be processed and how the reports are to be delivered. Credibility is enhanced by the requirement for vendors to under go an audit.
• #6: Here is the list of “standard” reports – those that must be supplied (when applicable) by the vendor.
• #7: These are the ones you are probably most familiar with are... Journal Report 1, Database Report 1 and Book Reports 1 & 2 which provide the basic stats for cost-per-use analysis. And Platform Report 1 is likely the one you use when assembling overall numbers for various surveys and annual reports. We will talk about Book Report 1 & 2 a little later...
• #8: SUSHI describes a client/server approach to harvesting COUNTER stats such that an ERM or usage consolidation application, once configured properly, can automatically request and retrieve usage stats on a regular basis (more on that later too).
• #9: Here is a timeline that puts this in historical context... In the late 1990s, the Publishers and Libraries Services group (PALS) began looking into the challenges of usage reporting of online resources. They held an international forum on usage in London in June of 2001 which directly lead to the creation of COUNTER And the publication of the 1st code of practice in 2003. And as you can see, several releases have followed over the years For SUSHI, the 2004 DLF ERMI report was the likely its incubator... ERMs were coming on the market and the report acknowledged the promise of COUNTER as a standard for reporting usage... SUSHI came about shortly after as the automated harvesting solution to address the practicality of downloading 100s of usage reports from dozens of content providers. SUSHI became official ANSI/NISO standard in 2007.
• #10: So with that background, lets talk about some developments of note
• #11: From the timeline perspective - the events are COUNTER Release 4, the COUNTER SUSHI Implementation Profile, Usus web site and the SUSHI-Lite technical report...
• #12: COUNTER Release 4 had a few impactful changes... Sessions were removed since federated searching made them an unreliable metric. Federated searches became “federated and automated” searches. Previously a discovery service or pre-selected multiple-database searches were counted as “regular” searches but counts no longer reflected user action or intent – and database search stats sky-rocketed as a result. With Release 4, “regular” searches are counted hen the user selected the database otherwise they are automated. And because “searches” were a less reliable metric, result clicks and record views were added to for database assessment reflect user actions related to a given database – a better measure of value. Plus SUSHI became a requirement for compliance... Though enforcement seemed to be a bit spotty...
• #13: SUSHI was a frequent topic of discussion and often not in a good context... Incompatible implementations lead to a lot of frustration and while the standard itself is OK, it is abstract enough to cause confusion to implementers. The COUNTER SUSHI Implementation profile was developed by the SUSHI standing committee to provide specific guidance to developers (and auditors) to remove ambiguity.
• #14: While there has been a sense the SUSHI isn’t working, with the efforts of various groups, things are improving...
• #15: Lets look at some numbers... Last February, EBSCO’s SUSHI harvesting was averaging 60% FAILURE rate. Since that time we introduced an updated version of our SUSHI Client... This coupled with significant improvements on the part of publishers, we have gone from seeing a 60% FAILURE rate in February of 2015 to a 95% SUCCESS rate in February of 2016.
• #16: In 2015 the Usus web site was launched. Supported by COUNTER but run by the community, this site provides a forum for discussion and feedback. If you have a question or problem with a SUSHI report or vendor, submit it through the feedback link and the Usus supervisory team will look into it. The track record is pretty good... But normally if a compliance issue is uncovered, the Usus team works with the vendor and the issue is usually fixed quickly.
• #17: Also in 2015, the SUSHI Standing Committee published a technical report which described using a current-day micro-service approach to SUSHI. The goal was to lower the barrier to client development as well as offer the option to exchange snippets of usage data so one could, for example, request usage just for one journal and embed that usage in another application. SUSHI-Lite is currently in trial use.
• #18: Here is an example of a request – it looks like a URL and it is...
• #19: The response is in JSON format and most developers familiar with today’s web development languages can easi;y process this.
• #20: And speaking about embedding usage... Imagine a typical renewals screen for a subscription management system... A place where renewal decisions are made...
• #21: If we can add use and projected cost-per-use to this screen we have enhanced the user’s workflow by adding key data needed to inform the decision.
• #22: Any of you find Book Report 1 and Book Report 2 challenging when trying to compare usage across platforms? Comparing a count of whole book downloads to chapter downloads is virtually meaningless. COUNTER has addressed this with Book Report 7 – currently an optional report that reflects unique book views within a user session. We expect this to become standard in the next release of the code of practice.
• #23: OK... Now a quick look ahead
• #24: COUNTER will have a new website in a couple weeks. In addition to be more “current”, it will offer interactive browsing of the code of practice and a searchable list of compliant vendors... Plus the SUSHI server registry will be integrated... And searchable by publisher.
• #25: Also in the works... COUNTER is developing a COUNTER Report Validator. This will be an online tool that will allow vendors, auditors and librarians to perform quick validation of SUSHI implementations and regular excel COUNTER reports. The goal is to provide a consistent test environment that all implementers can use and thus reduce development time and increase compliance and interoperability.
• #26: And then there is release 5 of the COUNTER Code of Practice. You will likely be hearing and reading more about this in the coming weeks and months. The major themes are consistency, clarity, simplification, flexibility all while introducing an continuous maintenance approach.
• #27: Consistence... Here is Journal Report 1 and Database Report 1. Database Reports have one row per metric type, whereas, Journal Report 1 is only recording details for Full Text Requests. The Excel version of Journal Report 1 only has reporting period totals for HTML and PDF yet the XML version has these broken out by month.
• #28: In release 5 the goal is for consistency between reports and formats. For example, all reports would include usage broken out by metric types and, where practical, the same vocabulary would be used in Excel and XML versions.
• #29: Adding clarity through better definitions... Including intended purpose of reports and metric types... And possibly providing scenarios that visually represent a user’s trip though a site and the metrics that result for various user actions.
• #30: While it may sound like a contradiction, we are looking to reduce the number of reports and increase flexibility. We would start by getting rid of several of the single-purpose optional reports and replace them with general reports for titles, databases, etc. General reports that can be filtered or configured to meet specific reporting goals. For example. a librarian would be able to select criteria to generate a title report with usage broken out by device type, limited to open access articles...
• #31: Finally, the plan is for COUNTER Release 5 to include processes that allow for continuous maintenance so that, much like with SUSHI, changes can be introduced without waiting for a 5 year review of the standard.