Reporting for Consortia

COUNTER recognizes that consolidated reports can be helpful to library consortia, and that some content providers may want to meet the needs of their consortium customers by providing Consortium Reports. This document sets out a standard method to create these reports. It should be noted that Consortium Reports are not a requirement of the COUNTER Code of Practice Release 5 and therefore will not be subject to a routine COUNTER audit.

Creating Consortium Reports by Extending COUNTER Master Reports

Section 11 of the Code of Practice describes the method for extending Master Reports and defines the additional elements (column headings in tabular reports) necessary for creating Consortium Reports:

• Institution_Name
• Customer_ID

With these elements the usage in Master Reports can be broken down by consortium member institutions by including their names and customer IDs. Using these elements in a standard way avoids conflicting custom implementations between content providers and provides a method that is consistent with the COUNTER_SUSHI API.

The example below shows what a tabular Consortium Report looks like – since a Consortium Report is an extended Master Report the only differences compared with a Master Report are the additional columns Institution_Name and Customer_ID and their declaration in Attributes_To_Show in the Report_Attributes header.

Rules for Using the Extensions

The Institution_Name and Customer_ID extensions must be used in a standard way to ensure a consistent implementation across providers. The rules apply to both tabular and JSON reports:

• Institution_Name must match the Institution_Name in the report header in a report for the consortium member institution and the Name for the institution returned by the /members COUNTER_SUSHI API path. If Institution_Name is included in a tabular report, it must be the first column.
• Customer_ID must match the Customer_ID in the report header in a JSON report for the consortium member institution and the Customer_ID for the institution returned by the /members COUNTER_SUSHI API path. If Customer_ID is included in a tabular report, it must be the second column if Institution_Name is also included, or the first column if Institution_Name is not included.
• The extensions only must be included in a Master Report if requested, and if included they must be declared in Attributes_To_Show in the Report_Attributes header.

Sample Report

This example shows what a Platform Master Report for a consortium looks like:

Access to Consortium Reports

Consortium administrators should be able to access the Consortium Reports in the same way as the required COUNTER reports, that is on the administrative/reporting site (tabular reports) and via the COUNTER_SUSHI API (JSON reports). The rules for the delivery of COUNTER reports from section 5.0 of the Code of Practice also should be applied to the Consortium Reports, for example the Consortium Reports should be provided at least for the current year plus the prior two years (or from the date the provider first became compliant).

Note that the rules from sections 5.1 and 10.3 of the Code of Practice still apply when Consortium Reports are provided – the consortium administrator still must be able to access the usage statistics for individual consortium members with a single login, consortium summary reports (usage for all members of the consortium rolled up at the consortia level) must be provided, and the COUNTER_SUSHI API implementation must support the /members path.

Duplicated Usage Data

In some cases, usage data might be duplicated in Consortium Reports, for example when a university and a university hospital have overlapping IP ranges and the usage is attributed to both sites. If the usage data in the consortium summary reports is deduplicated, the totals might differ between a Consortium Report and the corresponding consortium summary Master Report.

In some cases, when an institution belongs to more than one consortium, the usage data for the institution might be duplicated in Consortium Reports created for multiple consortia.

Standard Views

The Code of Practice does not permit extensions in Standard Views, so the Institution_Name and Customer_ID elements cannot be included in Standard Views. But it is possible to configure a Master Report in the same way as a Standard View (by using the same filters and attributes as for the Standard View) to create a Consortium Report that includes the same usage data as the corresponding Standard View. So providers could offer a set of pre-filtered Consortium Reports corresponding to Standard Views that cover the most common library consortia needs.

For example, a Consortium Report that contains the same information as TR_B1, broken down by Institution_Name and Customer_ID, could be created with these filters and attributes:

Note that the result still is a Master Report, so the Report_ID in this example is TR and the Report_Name Title Master Report. Using customized COUNTER reports (as described in section 11.2 of the Code of Practice) instead, which would allow to change Report_ID and Report_Name, is not recommended.

Requesting Consortium Reports via SUSHI

Since Consortium Reports are extended Master Reports, they can be requested via SUSHI as usual, simply by including Institution_Name or Customer_ID or both in the attributes_to_show parameter.

If the SUSHI server supports the extensions, the result is a Master Report with the usage broken down by consortium members institutions and the extensions declared in Attributes_To_Show in the Report_Attributes header. If the SUSHI server does not support the extensions, the expected result is a consortium summary Master Report with an Exception 3062 (Invalid ReportAttribute Value).

Exceptions

Some consortium member institutions might be missing from a Consortium Report because they have no usage for the requested period, or because the usage for the requested period is not ready for them yet.

The corresponding Exceptions must be used for the Consortium Reports as usual:

• If no consortium member institution had usage in the requested period, Exception 3030 (No Usage Available for Requested Dates) must be included in the Consortium Report.

• If for some consortium member institutions, the usage is not ready yet, or the usage is no longer available, or data is missing (permanently, for example because the logging failed), for parts of the requested period, Exception 3031 (Usage Not Ready for Requested Dates),3032 (Usage No Longer Available for Requested Dates) or 3040 (Missing Data) must be included in the Consortium Report.

Note that the idea to list the affected consortium member institutions in the optional Data element of the Exceptions has been dropped because the usage reporting systems of some (major) content providers currently are not able to provide this information.

If a consortium member institution is missing from the Consortium Report, the consortium administrator in case of doubt could check whether the corresponding report for the individual consortium member institution is empty.