Home | Workrooms | Standardized Usage Statistics Harvesting Initiative (SUSHI) | SUSHI for Librarians
In basic terms, The SUSHI protocol provides instructions to automate the collection of usage statistics reports from compliant vendors, which you’d otherwise manually download from a vendor website or receive via email. If you have an electronic resource management (ERM) system at your library, setting up SUSHI might be as simple as filling out a configuration screen. If you don’t have an ERM that works with SUSHI, you may be interested in developing your own system to collect reports. For help with this, see the SUSHI tools area.
Be sure to read the FAQ below for help getting your system configured or for more information about the protocol itself. If you still need help after reading through the FAQ and other resources on the site, don’t hesitate to email the SUSHI developers email list or contact a member of the Standing Committee with your questions.
Usage-related topics are also discussed on Usus, a community web site on usage.
These frequently asked questions are for librarians or other end users who wish to gather usage reports via the SUSHI protocol.
- What are the benefits of using the SUSHI protocol?
- Do you have a sense of how much time the implementation of SUSHI will save you in managing data collection?
- How do I implement SUSHI?
- What COUNTER reports can be delivered with SUSHI?
- Is it intended that SUSHI implementations support older Releases of the COUNTER reports?
- Can a single SUSHI request aggregate multiple vendor reports?
- How does SUSHI handle the requesting of consortium reports?
- Can I use SUSHI to receive or deliver non-COUNTER reports?
- Are there any limits to how many or how often I can request reports with SUSHI?
- Is there any limit to the time frame of the reports content which I can request?
- Can issuance of the SUSHI request be automated?
- What vendors have implemented the SUSHI protocol in their ERM products?
The primary benefit of SUSHI is that it automates a tedious and repetitive process. Current practice for statistics retrieval calls for library staff to go to each individual publisher’s website and manually retrieve statistical data. In some cases, this data is in COUNTER format, but sometimes it is the publisher’s own internal format. Occasionally it is available only through a web screen and cannot be downloaded; only printed. The SUSHI protocol automates the process; but also, by default, encourages the publishers to put usage data into a standard format (COUNTER XML). Therefore the retrieval is not only automatic but far easier to use.
2. Do you have a sense of how much time the implementation of SUSHI will save you in managing data collection?
The University of Washington has found it takes roughly 30 hours to collect usage statistics for all of their resources when it involves navigating to Web sites, logging in, finding the reports, downloading the reports, and storing the reports where collection development librarians can find them. As more resources move to collection via SUSHI feeds, the fewer places have to be visited manually. This is a huge time saver since once the feeds are set up they require no attention and will be collected automatically on a monthly basis. When collecting statistics by hand, UW would not collect on a monthly basis but rather on a quarterly basis because it was so time consuming.
From the perspective of a library customer, it should only be necessary to purchase or develop a system that supports SUSHI, and then manually input the connection information for all the various vendors that support SUSHI.
SUSHI 1.6 supports retrieval of any COUNTER report. The standardized names of the COUNTER reports to be used with the SUSHI protocol are listed on the SUSHI Report Name Registry.
With release 3 of the COUNTER Code of Practice, content providers are required to support the SUSHI standard and provide reports in XML format (adhering to COUNTER3_0.xsd). Given this, the expectation is that reports conforming to COUNTER 3.0 will form the baseline for SUSHI support. New implementations of both clients and servers should focus on support for this version of COUNTER reports.
Going forward, when changes to the schema do occur (this is not expected to happen often), COUNTER recommends that the current release and one previous release of its Code of Practice be supported.
The above does not prevent a SUSHI client service provider or content provider from supporting earlier versions of COUNTER reports if they feel there is customer demand; however, it should be clear that it is neither an expectation nor a requirement.
The protocol is designed as a one-report-at-a-time service. If a client needs multiple reports of different types or from different vendors, then it would simply make a separate SUSHI call for each one.
Results will need to be aggregated by the requesting library, either manually or using software such as an ERM system. In many cases, the request and aggregation process will be automated within the software that makes the request. For example, the system could be programmed to request all of last month’s reports on the 15th of this month, assuming that all of the content providers had their report data complete by that date. However, such automation is outside the scope of the SUSHI protocol.
Release 3 of the COUNTER Code of Practice for Journals and Databases introduced two reports specifically to address the needs of consortia. Using SUSHI (or by requesting the XML version of these reports from the content providers website), the consortium can request a report by identifying the consortium. The report that is returned will include the usage details for each member of the consortium.
Yes. COUNTER reports are the primary focus of the SUSHI standard, but other reports, agreed upon by the trading partners, can be retrieved as well. These custom reports would have to meet the standard's requirements for report naming and would have to be deliverable in an XML format.
There is a Registry of standardized report names. All COUNTER reports are included in the registry, however, registration of other customized reports is voluntary, so not all reports in use may appear here.
No, there are no SUSHI-based limits. The individual content provider servers may have access rules relating to frequency of requests and numbers of downloads. If the server is unable or unwilling to deliver a requested report through SUSHI, an Exception message is returned in the SUSHI response that describes the problem.
SUSHI places no time limits on the time frame of reports. Availability of reports for a particular range of months or years is determined by the content provider and the service provider of the SUSHI server that makes available the publisher’s data. If the publisher has not made statistics for certain years available, then SUSHI cannot retrieve it. If a request is made for an unavailable report, the SUSHI protocol will return an exception indicating why no data was returned. (Note: some ERM systems can only retrieve data within a single year. Data spanning multiple years will need to be retrieved one year at a time.)
Absolutely. Most current client-side SUSHI implementers are building automated triggering into their system to initiate SUSHI retrieval based on a known calendar of expected availability of usage reports. The initiating software package needs to know the publisher’s URL, a customer number, and a calendar of when the vendor makes their updates statistics available, and the process can be automated. ERM vendors who are incorporating the SUSHI client protocol into their software may provide additional automation capabilities.
Innovative Interfaces has released a version of their ERM product that supports the SUSHI protocol. Ex Libris is has built SUSHI into Verde, their ERM product. EBSCO provides SUSHI statistics collection in their Usage Consolidation product, Serials Solutions offers SUSHI statistics collection as part of 360 Counter product, Swets provides SUSHI statistics collections in their ScholarlyStats product, and PubGet offers SUSHI harvesting as part of their PaperStats product.
1. Where do I report problems with COUNTER reports from a content provider?
In the event that you encounter a COUNTER report that does not appear to be compliant with the current COUNTER Code of Practice, COUNTER wants to know about it if direct discussions with the content provider do not resolve the situation. Report such issues to Peter Shepherd at: pshepherd@projectCounter.org and include the following information:
- A copy of the report/file in question
- The name of the content provider
- The name of the customer (including customer code if available) whose usage the report represents
- A description of the problem or concern
COUNTER will take the matter up with the content provider concerned and will also use this input to enhance future versions of the Code of Practice and to improve the audit process.
2. Does the COUNTER XML include “Total for all Journals”?
No. COUNTER XML reports are designed for machine-to-machine transfer of usage data and they are not intended for direct human viewing. The library (or other recipient) will use a software program of some kind (e.g. a usage consolidation module of an ERM) to display or otherwise process the data; therefore, the expectation is that software will total the data as necessary.
3. Should the COUNTER XML include report totals for each journal, database or platform when multiple months of data are requested?
No. COUNTER XML reports are designed for machine-to-machine transfer of usage data and are not intended for human viewing. For example, when multiple months of data are requested for Journal Report 1, the COUNTER XML should include usage for each month for each journal; however, it should not include totals for all months for each journal. Inclusion of totals and subtotals for the range of months is both unnecessary and undesirable. Unnecessary because the software into which the use is loaded will handle any needed summarization. Undesirable because it makes the client and server software more complex.
The COUNTER Codes of Practice do not require the XML to contain all the elements of the Excel versions of the reports. The XML is intended to transfer the raw usage information. The Excel versions are intended for human viewing and thus include totals and sub-totals not necessary in the XML.
4. For Journal Reports; if usage is reported for ft_html and ft_pdf is it also necessary to include ft_total?
Yes. PDF and HTML are merely two possible formats that full text may be available in at a content provider site (others include XML, Postscript, etc.) The ft_html and ft_pdf counts were added to the Journal Reports in an effort to provide some insight into the “interface effect” of a particular user interface (if the html count is high, this could be indicative of a user having to view the html before requesting the pdf.) Because these metrics were designed to be merely indicative of the influence of the user interface, they were not intended to be inclusive.
Even though in many cases the ft_total is equal to ft_html + ft_pdf this cannot be guaranteed and the software loading the COUNTER report will have no way of knowing; therefore, ft_total metric must be included in the Journal Reports to ensure reports are comparable.
5. If a SUSHI request contains a data range that spans more than one month, should the resulting COUNTER report include just the summary totals by journal?
No. The COUNTER XML should use the date range in the request to determine the months to be reported on and then provide separate metrics for each month covered in the request. For example, if a request for Journal Report 1 is for 2012-01 through 2012-06, the resulting COUTNER XML would contain six itemPerformance elements (one for each month).
6. What does a content provider have to do to become COUNTER compliant?
Refer to the Friendly (technical) Guide to COUNTER (https://www.projectcounter.org/wp-content/uploads/2016/03/Technical-pdf.pdf) which is designed to take vendors, step-by-step, through the COUNTER compliance process.