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.
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:
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.
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:
This example shows what a Platform Master Report for a consortium looks like:
Report_Name | Platform Master Report | |||||||
Report_ID | PR | |||||||
Release | 5 | |||||||
Institution_Name | Consortium Epsilon | |||||||
Institution_ID | ISNI:000000012150090X | |||||||
Metric_Types | ||||||||
Report_Filters | Access_Method=Regular | |||||||
Report_Attributes | Attributes_To_Show=Institution_Name|Customer_ID|Data_Type | |||||||
Exceptions | ||||||||
Reporting_Period | Begin_Date=2020-01-01; End_Date=2020-03-31 | |||||||
Created | 2020-05-25T11:39:38Z | |||||||
Created_By | Publisher Zeta | |||||||
Institution_Name | Customer_ID | Platform | Data_Type | Metric_Type | Reporting_Period_Total | Jan-2020 | Feb-2020 | Mar-2020 |
University of Beta | A1001 | Platform Alpha | Platform | Searches_Platform | 25511 | 4641 | 9985 | 10885 |
University of Beta | A1001 | Platform Alpha | Journal | Total_Item_Investigations | 52835 | 18975 | 15626 | 18234 |
University of Beta | A1001 | Platform Alpha | Journal | Total_Item_Requests | 13036 | 2300 | 4984 | 5752 |
University of Beta | A1001 | Platform Alpha | Journal | Unique_Item_Investigations | 12967 | 2467 | 4600 | 5900 |
University of Beta | A1001 | Platform Alpha | Journal | Unique_Item_Requests | 12100 | 2000 | 4500 | 5600 |
University of Beta | A1001 | Platform Alpha | Book | Total_Item_Investigations | 18868 | 3220 | 7269 | 8379 |
University of Beta | A1001 | Platform Alpha | Book | Total_Item_Requests | 10285 | 1780 | 3935 | 4570 |
University of Beta | A1001 | Platform Alpha | Book | Unique_Item_Investigations | 18848 | 3214 | 7263 | 8371 |
University of Beta | A1001 | Platform Alpha | Book | Unique_Item_Requests | 10271 | 1770 | 3933 | 4568 |
University of Beta | A1001 | Platform Alpha | Book | Unique_Title_Investigations | 378 | 61 | 117 | 200 |
University of Beta | A1001 | Platform Alpha | Book | Unique_Title_Requests | 378 | 61 | 117 | 200 |
University of Gama | A1002 | Platform Alpha | Platform | Searches_Platform | 1500 | 400 | 500 | 600 |
University of Gama | A1002 | Platform Alpha | Journal | Total_Item_Investigations | 3000 | 900 | 1100 | 1000 |
University of Gama | A1002 | Platform Alpha | Journal | Total_Item_Requests | 2770 | 870 | 1000 | 900 |
University of Gama | A1002 | Platform Alpha | Journal | Unique_Item_Investigations | 2800 | 900 | 1000 | 900 |
University of Gama | A1002 | Platform Alpha | Journal | Unique_Item_Requests | 2500 | 800 | 900 | 800 |
Delta College Winchester | A1003 | Platform Alpha | Platform | Searches_Platform | 23600 | 4600 | 9000 | 10000 |
Delta College Winchester | A1003 | Platform Alpha | Journal | Total_Item_Investigations | 51000 | 18000 | 15000 | 18000 |
Delta College Winchester | A1003 | Platform Alpha | Journal | Total_Item_Requests | 4200 | 1500 | 1300 | 1400 |
Delta College Winchester | A1003 | Platform Alpha | Journal | Unique_Item_Investigations | 4600 | 1600 | 1400 | 1600 |
Delta College Winchester | A1003 | Platform Alpha | Journal | Unique_Item_Requests | 4050 | 1450 | 1250 | 1350 |
Delta College Winchester | A1003 | Platform Alpha | Book | Total_Item_Investigations | 950 | 300 | 350 | 300 |
Delta College Winchester | A1003 | Platform Alpha | Book | Total_Item_Requests | 810 | 240 | 310 | 260 |
Delta College Winchester | A1003 | Platform Alpha | Book | Unique_Item_Investigations | 840 | 250 | 320 | 270 |
Delta College Winchester | A1003 | Platform Alpha | Book | Unique_Item_Requests | 780 | 230 | 300 | 250 |
Delta College Winchester | A1003 | Platform Alpha | Book | Unique_Title_Investigations | 840 | 250 | 320 | 270 |
Delta College Winchester | A1003 | Platform Alpha | Book | Unique_Title_Requests | 780 | 230 | 300 | 250 |
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.
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.
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:
Metric_Types | Total_Item_Requests; Unique_Title_Requests |
Report_Filters | Data_Type=Book; Access_Type=Controlled; Access_Method=Regular |
Report_Attributes | Attributes_To_Show=Institution_Name|Customer_ID|YOP |
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.
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).
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:
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.