COUNTER Code of Practice Release 5.1

COUNTER’s report consumer and report provider members have contributed to the development of Release 5.1 (R5.1) of the COUNTER Code of Practice.

The Code of Practice enables report providers to produce consistent, comparable and credible usage data for their online content. This allows report consumers to compare the usage data they receive, and to understand and demonstrate the value of electronic resources.

Release 5.1 (published 5 May 2023) will become the current Code of Practice and the requirement for COUNTER compliance effective from January 2025.

The Code of Practice is maintained by COUNTER. This online version is the version of record for Release 5.1 of the Code of Practice. There is more information about COUNTER on COUNTER website.

Foreword

Librarians and consortia managers spend considerable amounts of money funding open access materials and licensing different types of online content, and want to measure return on the investment to ensure that budgets are spent as productively as possible. One of the ways to measure this return on investment is to assess usage statistics.

This release of the COUNTER Code of Practice is designed to balance changing reporting needs with the need to make things simpler so that all report providers can achieve compliance and report consumers can have usage statistics that are credible, consistent and comparable.

Consistency in report formats

Release 5.1 consists of four COUNTER Reports. Each of the COUNTER Reports is associated with several pre-set filtered Standard Views of the COUNTER Report, but we encourage report consumers to use COUNTER Reports to customize their analysis and meet their specific reporting needs.

Consistency and clarity in metrics

Release 5.1 maintains the Release 5 Metric Types, which ensure comprehensive, consistent and detailed usage reporting.

Flexibility

Flexibility is built into Release 5.1 through Attributes, pieces of information which can be associated with multiple metrics. Providing information about matters such as Year of Publication, Access_Type, and Data_Types means that users can roll up or drill down through reports with ease, eliminating the need for special purpose reports.

How do I use this Code of Practice?

This online version is the version of record for Release 5.1 of the Code of Practice, which can also be downloaded as a PDF. More information is available from the COUNTER website.

The Code of Practice will be of interest to both report providers and report consumers, however some sections are more relevant to particular user cases.

Sections 1 and 2 provide an introduction and outline of the scope of the COUNTER Code of Practice.

Sections 3 and 4 provide an explanation of the COUNTER Reports and Standard Views of the COUNTER Reports which are a requirement for COUNTER-compliance and that allow the report consumer to filter and configure to create customized “views” of their usage data. Section 3 also explains Metric Types and Attributes.

Report Providers implementing Release 5.1

Sections 5 to 7 provide essential information. These sections give detail on the delivery of COUNTER-compliant reports and views, logging usage and processing rules.

COUNTER compliance requires content hosts to implement COUNTER_SUSHI (the standardised model for harvesting online usage data). Section 8 provides the specifications for the RESTful COUNTER_SUSHI API and the methods that must be supported. Appendix D explains handling errors and exceptions.

Report Providers preparing for COUNTER audit

An important feature of the COUNTER Code of Practice is that compliant report providers must be independently audited on a regular basis in order to maintain their COUNTER compliant status. If you are preparing for a COUNTER audit, Section 9 explains the audit process and procedures, while Appendix E explains audit requirements and tests.

Conventions

This Code of Practice is implemented using the following convention:

The keywords MUST (or REQUIRED), MUST NOT, SHOULD (or RECOMMENDED), SHOULD NOT (or NOT RECOMMENDED), and OPTIONAL in this document are to be interpreted as described in RFC 2119.

Note that the force of these words is modified by the requirement level of the document in which they are used.

1. MUST (or REQUIRED) means that the definition is an absolute requirement of the specification.

2. MUST NOT means that the definition is an absolute prohibition of the specification.

3. SHOULD (or RECOMMENDED) means that there may be valid reasons in certain circumstances to ignore a particular item, but the full implications should be understood and carefully weighed before choosing a different course.

4. SHOULD NOT (or NOT RECOMMENDED) means that there may be valid reasons in certain circumstances when the particular behaviour is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behaviour described with this label.

Report providers implementing the Code of Practice who feel they have a valid disagreement with a requirement of the code are requested to present their case in writing to the COUNTER Project Director (tasha.mellins-cohen@counterusage.org) and ask for clarification on interpretation of the code.

Text appearing in italic will be replaced with appropriate values at implementation time, terms enclosed in curly brackets are variables. For example, Exception in the format “{Exception Code}: {Exception Message}” might resolve to “3030: No Usage Available for Requested Dates”.

Introduction

Since its inception in 2002, COUNTER has been focused on providing a Code of Practice that helps ensure report consumers (e.g. librarians and consortia managers) have access to consistent, comparable, and credible usage reporting for their online scholarly information. The COUNTER Code of Practice provides guidance on data elements to be measured and definitions of these data elements, as well as guidelines for output report content and formatting and requirements for data processing and auditing. To have their usage statistics and reports designated COUNTER compliant, report providers MUST provide usage statistics that conform to the current Code of Practice.

Purpose

The purpose of the COUNTER Code of Practice is to facilitate the recording, exchange, and interpretation of online usage data by establishing open international standards and protocols for the provision of report-provider-generated usage statistics that are consistent, comparable, and credible.

Scope

This COUNTER Code of Practice provides a framework for the recording and exchange of online usage statistics for the major categories of digital resources (journals, databases, books, reference works, and multimedia databases) at an international level. In doing so, it covers the following areas: data elements to be measured, definitions of these data elements, content and format of usage reports, requirements for data processing, requirements for auditing, and guidelines to avoid duplicate counting.

Application

COUNTER is designed for report providers and report consumers who require reliable online usage statistics. The guidelines provided by this Code of Practice enable report consumers to compare statistics from different platforms, to make better-informed purchasing decisions, and to plan more effectively. COUNTER also provides report providers with the detailed specifications they need to follow to generate data in a format useful to their customers, to compare the relative usage of different delivery channels, and to learn more about online usage patterns. COUNTER also provides guidance to others interested in information about online usage statistics.

Strategy

COUNTER provides an open Code of Practice that evolves in response to the demands of the international scholarly communication community. The Code of Practice is continually under review; feedback on its scope and application are actively sought from all interested parties. See Section 12 Continuous Maintenance below.

Governance

The COUNTER Code of Practice is owned and developed by Counter Online Metrics (COUNTER), a non-profit distributing company registered in England. A Board of Directors governs Counter Online Metrics. An Executive Committee reports to the Board, and day-to-day management is the responsibility of the Project Director.

Definitions

This Code of Practice provides definitions of data elements and other terms that are relevant, not only to the usage reports specified in Release 5.1 (R5.1), but also to other reports that report providers may wish to generate. Every effort has been made to use existing ISO, NISO, etc. definitions where appropriate, and these sources are cited (see Appendix A).

Versions

The COUNTER Code of Practice will be extended and upgraded as necessary based on input from the community it serves. Each new version will be made available as a numbered release on the COUNTER website; users will be alerted to its availability. R5.1 of the Code of Practice replaces Release 5 (R5) of the Code of Practice. The deadline date for implementation of this Release is 01-Jan-2025. After this date, only those content providers compliant with R5.1 will be deemed compliant with the Code of Practice.

COUNTER R5 introduced a continuous maintenance process (see Section 12 below) that allows the Code of Practice to evolve over time minimizing the need for major version changes. In R5.1 the COP will transition to use of Explicit Versioning, a four-digit numbering system in the structure Release.Breaking.Feature.Fix, where “Breaking” indicates changes that are not backwards compatible, “Feature” indicates new features or extensions that are backwards compatible, and “Fix” is used for typographic corrections and similar small amendments.

Auditing and COUNTER Compliance

An independent annual audit is REQUIRED of each report provider’s reports and processes to certify that they are COUNTER compliant. The auditing process is designed to be simple, straightforward and not unduly burdensome or costly to the content provider while providing reassurance to customers of the reliability of the COUNTER usage data. See Section 9 below and Appendix E for more details.

Relationship to other Standards, Protocols and Codes

The COUNTER Code of Practice builds on several existing industry initiatives and standards that address report provider-based online performance measures. Where appropriate, definitions of data elements and other terms from these sources have been used in this Code of Practice, and these are identified in Appendix A.

Making Comments on the Code of Practice

The COUNTER Executive Committee welcomes comments on the Code of Practice (see Section 12 below).

Overview

This section provides an overview of the scope of the COUNTER Code of Practice.

Section 3 Technical Specifications for COUNTER Reports introduces the REQUIRED COUNTER Reports, describes the common format shared by all COUNTER Reports, and defines the COUNTER Report attributes and their values.

Section 4 COUNTER reports provides detailed specifications for each COUNTER Report and Standard Views of the COUNTER Reports. Use this section to understand what elements are included in each COUNTER Report.

Section 5 Delivery of COUNTER Reports outlines the options a report provider MUST provide to enable customers to access their reports.

Section 6 Logging Usage describes various options used for logging usage transactions.

Section 7 Processing Rules for Underlying COUNTER Reporting Data discusses topics such as which HTTP status codes to count, double-click filtering, calculating unique items and unique titles accessed in a session, classifying searches (regular, federated, automated, or platform), robots and internet crawlers, tools that cause bulk downloads, and text and data mining.

Section 8 SUSHI for Automated Report Harvesting offers a more in-depth description of the REQUIRED COUNTER_SUSHI API support.

Section 9 Audit provides the requirements for the COUNTER audit.

Section 10 Other Compliance Topics talks about license language to require COUNTER usage statistics, confidentiality of data, and supporting consortia in their need to obtain usage data for their members.

Section 11 Extending the Code of Practice offers suggestions for report providers who may want to create custom reports or include additional elements and attribute values in COUNTER Reports.

Section 12 Continuous Maintenance outlines the procedures that have been put in place to allow the Code of Practice to be amended and expanded on an incremental basis in a controlled and managed way.

Section 13 Transitioning from Previous Releases or to New Reporting Services describes the procedures and requirements for transitioning to a new reporting service or underlying logging system and for transitioning to a new COUNTER release.

Section 14 Change History provides a list of the Code of Practice releases.

Technical Specifications for COUNTER Reports

COUNTER Reports for Report Consumers

R5.1 consists of four COUNTER Reports that allow the report consumer to filter and configure to create customized views of their usage data. R5.1 also specifies Standard Views of the COUNTER Reports (pre-set filters/configuration).

To achieve compliance, a report provider MUST offer the COUNTER Reports and Standard Views of the COUNTER Reports that are applicable to their Host_Types, with the exception of Standard Views that always would be empty (e.g. an Access Denied Standard View if denials cannot occur). An independent audit is required for these reports.

Report providers may offer additional COUNTER Reports and Standard Views of the COUNTER Reports not required for compliance or custom reports (see Section 11.2), according to the rules set for the reports by the Code of Practice. For these reports an audit is not required.

COUNTER Reports

COUNTER Reports include all relevant Metrics and Attributes; they are intended to be customizable through the application of filters and other configuration options, allowing report consumers to create a report specific to their needs. The four COUNTER Reports are shown in Table 3.a along with their Report_ID, Report_Name and Host_Types who are REQUIRED to provide these reports. See Section 3.3.1 below for details on Host_Types.

Table 3.a (below): COUNTER Reports

Report_ID	Report_Name	Details	Host_Types
PR	Platform Report	A customizable report summarizing activity across a report provider’s platforms that allows the user to apply filters and select other configuration options.	All Host_Types
DR	Database Report	A customizable report detailing activity by database that allows the user to apply filters and select other configuration options.	A&I_Database Aggregated_Full_Content Discovery_Service eBook_Collection Full_Content_Database Multimedia_Collection
TR	Title Report	A customizable report detailing activity at the title level (journal, book, etc.) that allows the user to apply filters and select other configuration options.	Aggregated_Full_Content eBook eBook_Collection eJournal
IR	Item Report	A granular, customizable report showing activity at the level of the item (article, chapter, media object, etc.) that allows the user to apply filters and select other configuration options.	Data_Repository* Multimedia Repository Scholarly_Collaboration_Network

* Data repositories may choose to conform to the Code of Practice R5.1, alternatively, may wish to work with the Code of Practice for Research Data.

Figure 3.a (below) provides an example of how the user interface could look. The user will be presented with an interface that allows them to select usage dates, one or more Metric_Types, Data_Types, Access_Types, etc. and indicate if the filter columns are to be included. Including the column will cause usage to be broken out by individual values for the selected filter, whereas not including the column will result in usage being summarized for the selected filter.

Figure 3.a: Example of a user interface

Reporting for Open Access

All Host_Types are encourged but not required to provide a Global Item Report, which provides a granular per-item view of all usage, whether attributed to institutions or not.

The Global Item Report is an Item Report to “The World” including all global usage, whether attributed to an institution or not, which could be broked down by geolocation with the Country and Subdivision extensions.

Standard Views of the COUNTER Reports

The goal of Standard Views of the COUNTER Reports is to provide a set of pre-filtered views of the COUNTER Reports covering the most common set of report consumer needs. Report_IDs for Standard Views are derived from the Report_ID of the COUNTER Report that they are based on. The format is {COUNTER Report_ID}_{View ID}.

Standard Views of the Platform Report

The Platform Usage Standard View is derived from the Platform Report and provides a summary of activity on a given platform to support the evaluation of platforms and to provide high-level statistical data to support surveys and reporting to funders.

Table 3.b (below): Platform Usage Standard View

Report_ID	Report_Name	Details	Host_Types
PR_P1	Platform Usage	Platform-level usage summarized by Metric_Type.	All Host_Types

*Data repositories may choose to conform to the Code of Practice R5.1 or, alternatively, may wish to work with the Code of Practice for Research Data.

See Section 4.1 below for details on Platform Usage Reports.

Standard Views of the Database Report

The Standard Views of the Database Report support the evaluation of the value of a given database of resources (e.g. a full-text database, an A&I database, or a multimedia collection).

Table 3.c (below): Standard Views of the Database Report

Report_ID	Report_Name	Details	Host_Types
DR_D1	Database Search and Item Usage	Reports on key Searches, Investigations and Requests metrics needed to evaluate a database.	A&I_Database Aggregated_Full_Content Discovery_Service eBook_Collection Full_Content_Database Multimedia_Collection
DR_D2	Database Access Denied	Reports on Access Denied activity for databases where users were denied access because simultaneous-use licenses were exceeded or their institution did not have a license for the database.	A&I_Database Aggregated_Full_Content Discovery_Service eBook_Collection Full_Content_Database Multimedia_Collection

See Section 4.2 below for details on Database Usage Reports.

Standard Views of the Title Report

Standard Views of the Title Report are used to support the evaluation of the value of a given serial (e.g. journal, magazine, or newspaper) or monograph (e.g. book, eBook, textbook, or reference work) title.

Table 3.d (below): Standard Views of the Title Report

Report_ID	Report_Name	Details	Host_Types
TR_B1	Book Requests (Controlled)	Reports on full-text activity for books, excluding Open and Free_To_Read content, as Total_Item_Requests and Unique_Title_Requests. The Unique_Title_Requests provides comparable usage across book and reference work platforms. The Total_Item_Requests shows overall activity; however, numbers between sites will vary significantly based on how the content is delivered (e.g. delivered as a complete book or by chapter).	Aggregated_Full_Content eBook eBook_Collection
TR_B2	Book Access Denied	Reports on Access Denied activity for books where users were denied access because simultaneous-use licenses were exceeded or their institution did not have a license for the book.	Aggregated_Full_Content eBook eBook_Collection
TR_B3	Book Usage by Access Type	Reports on book usage showing all applicable Metric_Types broken down by Access_Type.	Aggregated_Full_Content eBook eBook_Collection
TR_J1	Journal Requests (Controlled)	Reports on usage of journal content, excluding Open and Free_To_Read content, as Total_Item_Requests and Unique_Item_Requests. The Unique_Item_Requests provides comparable usage across journal platforms by reducing the inflationary effect that occurs when an HTML full text automatically displays and the user then accesses the PDF version. The Total_Item_Requests shows overall activity.	Aggregated_Full_Content eJournal
TR_J2	Journal Access Denied	Reports on Access Denied activity for journal content where users were denied access because simultaneous-use licenses were exceeded or their institution did not have a license for the title.	Aggregated_Full_Content eJournal
TR_J3	Journal Usage by Access Type	Reports on usage of journal content for all Metric_Types broken down by Access_Type.	Aggregated_Full_Content eJournal
TR_J4	Journal Requests by YOP (Controlled)	Breaks down the usage of journal content, excluding Open and Free_To_Read content, by year of publication (YOP), providing counts for the Metric_Types Total_Item_Requests and Unique_Item_Requests. Provides the details necessary to analyze usage of content in backfiles or covered by perpetual access agreements. Note that COUNTER reports do not provide access model or perpetual access rights details.	Aggregated_Full_Content eJournal

See Section 4.3 below for details on Title Usage Standard Views.

Standard Views of the Item Report

The Standard Views for item-level reporting are designed to support the most common reporting needs. Journal Article Requests provides insight into the usage of individual journal articles (e.g. in institutional repositories) while Multimedia Item Requests allows evaluation of multimedia materials.

Table 3.e (below): Standard Views of the Item Report

Report_ID	Report_Name	Details	Host_Types
IR_A1	Journal Article Requests	Reports on journal article requests at the article level. This report is limited to content with a Data_Type of Article and Metric_Types of Total_Item_Requests and Unique_Item_Requests.	Repository Scholarly_Collaboration_Network
IR_M1	Multimedia Item Requests	Reports on multimedia requests at the item level.	Multimedia

See Section 4.4 below for details on Item Usage Reports.

Formats for COUNTER Reports

COUNTER Reports and Standard Views of the COUNTER Reports MUST be delivered in machine-readable data (JSON) via the COUNTER_SUSHI API and in tabular form as .tsv files. The tabular form MUST be provided as either an Excel or a tab-separated-value (TSV) file, or both. Additional file formats that can be easily imported into spreadsheet programs without loss or corruption may be offered at the vendor’s discretion. The reports in JSON, TSV and other text formats MUST be encoded using UTF-8. The JSON format MUST comply with the COUNTER_SUSHI API Specification (see Section 8 below).

Except where otherwise specified, the remainder of this section uses COUNTER Reports to refer to both the four COUNTER Reports and the Standard Views of the COUNTER Reports.

All COUNTER Reports have the same layout and structure. Figure 3.b (below) provides an example of the Title Report. Figure 3.c (below) shows the layout for tabular reports, which will be the focus of the discussions throughout this document. Note that the COUNTER_SUSHI API Specification includes the same elements with the same or similar names; therefore, understanding the tabular reports translates to an understanding of what is REQUIRED in reports retrieved via the COUNTER_SUSHI API.

Figure 3.b: Sample Title Report

Figure 3.c: Layout for Tabular COUNTER Reports

All COUNTER Reports have a header. In tabular reports, the header is separated from the body with a blank row (to facilitate sorting and filtering in Excel). Beneath that is the body of the report with column headings. The contents of the body will vary by report. Figure 3.c (above) identifies the different kinds of information you may find in the report and the relative positioning of this information. All of this is discussed in more detail below.

Report Header

The first 13 rows of a tabular COUNTER Report contain the header, and the 14th row is always blank. The header information is presented as a series of name-value pairs, with the names appearing in Column A and the corresponding values appearing in Column B. All tabular COUNTER reports have the same names in Column A. Column B entries will vary by report.

Figure 3.d: Common Report Header Information

Figure 3.d (above) shows the layout of the common header. The 13 elements in Column A and the values in Column B are discussed in more detail in the table below. Note that the element names (Column A) MUST appear in the COUNTER report exactly as they are shown here. Capitalization, spelling, and punctuation MUST match exactly.

Table 3.f (below): COUNTER Report Header Elements

Element Name	Description of value to provide	Example
Report_Name	The name of the report as it appears in Section 3.1.	Journal Requests (Controlled)
Report_ID	The unique identifier for the report as it appears in Section 3.1.	TR_J1
Release	The COUNTER release this report complies with.	5
Institution_Name	The name of the organization to which the usage is attributed. This can be a higher education institution, or for example a country for a country-wide contract, or a publisher if an aggregator or discovery service wants to report usage of a publisher’s content to the publisher. Where reports show content usage that cannot be attributed to an institution, the Institution_Name should be “The World”. Note that such a report would include all global usage, whether attributed to institutions or not, but it could be filtered and broken down as usual, including by using Attributed and other extensions (see Section 11.5).	Mt. Laurel University
Institution_ID	A series of identifiers that represent the institution, in tabular reports in the format of {namespace}:{value}. Include multiple identifiers separated with a semicolon-space (“; ”), but only one value per namespace. In JSON reports multiple values per namespace can be included. Permitted identifier namespaces are ISIL, ISNI, OCLC, ROR and, for local identifiers assigned by the report provider, the platform ID of the report provider. The customer ID used for requesting the report MUST be included, usually with the platform ID as namespace. For reports to “The World”, Institution_ID should be 0000000000000000, with the platform ID as namespace.	ISNI:0000000419369078; ROR:00hx57361; pubsiteA:PrncU
Metric_Types	A semicolon-space delimited list of Metric_Types requested for this report. Note that even though a Metric_Type was requested, it might not be included in the body of the report if no report items had usage of that type.	Unique_Item_Investigations; Unique_Item_Requests
Report_Filters	A series of zero or more report filters applied on the reported usage, excluding Metric_Type, Begin_Date and End_Date (which appear in separate rows in the tabular reports for easier reading). Typically, a report filter affects the amount of usage reported. Entries appear in the form of {filter name}={filter value} with multiple filter name-value pairs separated with a semicolon-space (“; ”) and multiple filter values for a single filter name separated by the vertical pipe (“|”) character.	Access_Type=Controlled; Access_Method=Regular
Report_Attributes	A series of zero or more report attributes applied to the report. Typically, a report attribute affects how the usage is presented but does not change the totals. Entries appear in the form of {attribute name}={attribute value} with multiple attribute name-value pairs separated with a semicolon-space (“; ”) and multiple attribute values for a single attribute name separated by the vertical pipe (“|”) character.	Attributes_To_Show=Access_Type
Exceptions	An indication of some difference between the usage that was requested and the usage that is being presented in the report. The format for the exception values is “{Exception Code}: {Exception Message} ({Data})” with multiple exception values separated by semicolon-space (“; ”). The Exception Code and Exception Message MUST match values provided in Table D.1 of Appendix D. For some exceptions further information MUST be provided in the Data element as indicated in Table D.1, otherwise the Data is optional. Note that for tabular reports usually only the limited set of exceptions which indicate that usage is not, not yet or no longer available will occur.	3031: Usage Not Ready for Requested Dates (request was for 2024-01-01 to 2024-12-31; however, usage is only available to 2024-08-31)
Reporting_Period	The date range for the usage represented in the report, in the form of: “Begin_Date=yyyy-mm-dd; End_Date=yyyy-mm-dd”.	Begin_Date=2024-01-01; End_Date=2024-08-31
Created	The date and time the usage was prepared, in RFC3339 date-time format (yyyy-mm-ddThh:mm:ssZ).	2024-10-11T14:37:15Z
Created_By	The name of the organization or system that created the COUNTER report.	EBSCO Information Services 360 COUNTER
Registry_Record	The link to the platform’s COUNTER Registry record. Report providers who do not have a Registry record MUST leave the value blank.	https://registry.projectcounter.org/platform/b2b2736c-2cb9-48ec-91f4-870336acfb1c
(blank row)	Row 14 MUST be blank.

Report Body

Figures 3.b and 3.c (above) show the body of the COUNTER reports containing an extensive array of data elements. Not all COUNTER Reports and Standard Views of COUNTER Reports will include all elements. When formatting a report, maintain the order of elements described below, but only include those elements relevant to that report. Where practical, the discussion below will provide guidance as to which reports an element may be included in. See Section 4 below for an extensive mapping of elements to reports.

Report Item Description

Every COUNTER report will have columns that describe its report items.

Table 3.g (below): Elements that Describe the Report Item

Element Name	Description	Reports	Examples
Database	Name of database for which usage is being reported. Applies only to Database Reports.	DR DR_D1, DR_D2	MEDLINE
Title	Name of the book or journal for which usage is being reported. Applies only to Title Reports.	TR TR_B1, TR_B2, TR_B3, TR_J1, TR_J2, TR_J3, TR_J4	Journal of Economics Gone with the Wind
Item	Name of the article, book chapter, multimedia work, or repository item for which usage is being reported. Applies only to Item Reports.	IR IR_A1, IR_M1	CRISPR gene-editing tested in a person for the first time
Publisher	Name of the publisher of the content item. Note that when the content item is a database, the publisher would be the organization that creates that database.	DR, TR, IR DR_D1, DR_D2, TR_B1, TR_B2, TR_B3, TR_J1, TR_J2, TR_J3, TR_J4, IR_A1, IR_M1	Taylor & Francis APA
Publisher_ID	A unique identifier for the publisher, in tabular reports in the form of {namespace}:{value}. When multiple identifiers are available for a given publisher, include all identifiers separated with semicolon-space (“; ”), but only one value per namespace. In JSON reports multiple values per namespace can be included. Permitted identifier namespaces are ISNI, ROR and, for local identifiers assigned by the report provider, the platform ID of the report provider.	DR, TR, IR DR_D1, DR_D2, TR_B1, TR_B2, TR_B3, TR_J1, TR_J2, TR_J3, TR_J4, IR_A1, IR_M1	ISNI:1234123412341234; ROR:012a3bc45; ebscohost:PubX

For Database the value MUST NOT be empty. For Title, Item and Publisher the value SHOULD NOT be empty, and if the value for Title or Item is empty at least one DOI, ISBN, Online_ISSN, Print_ISSN, Proprietary_ID or URI MUST be provided so that the report item can be identified. Note that report providers are expected to make all reasonable efforts to provide this information and that using an empty value may affect the result of an audit (see Section 3.3.9).

Platform

The next column in the report identifies the platform where the activity happened.

Table 3.h (below): Elements that Identify the Platform

Element Name	Description	Reports	Examples
Platform	Identifies the platform/content host where the activity took place. Note that in cases where individual titles or groups of content have their own branded user experience but reside on a common host, the identity of the underlying common host MUST be used as the Platform.	All COUNTER Reports and Standard Views of COUNTER Reports	EBSCOhost ProQuest ScienceDirect

Report Item Identifiers

The item being reported on is further identified by the columns to the right of the platform.

Table 3.i (below): Elements for Report Item Identifiers

Element Name	Description	Reports	Examples
Authors	Authors of the work for which usage is being reported, in tabular reports in the format {author name} ({author identifier}) with one OPTIONAL author identifier in the format {namespace}:{value}. Permitted identifier namespaces are ISNI and ORCID. A maximum of three authors should be included, in tabular reports with multiple authors separated by semicolon-space (“; ”).	IR IR_A1	John Smith (ORCID:0000-0001-2345-6789)
Publication_Date	Date of publication for the work in the format yyyy-mm-dd.	IR IR_A1	2024-09-05
Article_Version	ALPSP/NISO code indicating the version of the work as defined by NISO RP-8-2008, Journal Article Versions.	IR IR_A1	VoR
DOI	Digital Object Identifier for the item being reported on in the format {DOI prefix}/{DOI suffix}.	TR, IR TR_B1, TR_B2, TR_B3, TR_J1, TR_J2, TR_J3, TR_J4, IR_A1, IR_M1	10.1629/uksg.434
Proprietary_ID	A proprietary ID assigned by the report provider for the item being reported on. Format as {namespace}:{value} where the namespace is the platform ID of the host which assigned the proprietary identifier.	DR, TR, IR DR_D1, DR_D2, TR_B1, TR_B2, TR_B3, TR_J1, TR_J2, TR_J3, TR_J4, IR_A1, IR_M1	publisherA:jnrlCode123
ISBN	International Standard Book Number in the format ISBN-13 with hyphens.	TR, IR TR_B1, TR_B2, TR_B3	978-3-16-148410-0
Print_ISSN	International Standard Serial Number assigned to the print instance of a serial publication in the format nnnn-nnn[nX].	TR, IR TR_B1, TR_B2, TR_B3, TR_J1, TR_J2, TR_J3, TR_J4, IR_A1	0953-1513
Online_ISSN	International Standard Serial Number assigned to the online instance of a serial publication in the format nnnn-nnn[nX].	TR, IR TR_B1, TR_B2, TR_B3, TR_J1, TR_J2, TR_J3, TR_J4, IR_A1	2048-7754
URI	Universal Resource Identifier, a valid URL or URN according to RFC 3986.	TR, IR TR_B1, TR_B2, TR_B3, TR_J1, TR_J2, TR_J3, TR_J4, IR_A1, IR_M1

At least one DOI, ISBN, Online_ISSN, Print_ISSN, Proprietary_ID or URI SHOULD be provided for each report item. Note that only one value per identifier is permitted, unless specified otherwise.

Parent Item Description and Identifiers

When reporting usage on content items like articles and book chapters, it is often desirable to identify the item’s parent item, such as the journal or book it is part of. This next grouping of columns identifies the parents and is used by a small subset of reports.

Table 3.j (below): Elements that Describe a Parent Item

Element Name	Description	Reports	Examples
Parent_Title	Title of the parent item.	IR IR_A1	The Serials Librarian
Parent_Authors	Authors of the parent work. See the Authors element in Table 3.i for the format.	IR IR_A1
Parent_Publication_Date	Date of publication for the parent work in the format yyyy-mm-dd.	IR
Parent_Article_Version	ALPSP/NISO code indicating the version of the parent work as defined by NISO RP-8-2008, Journal Article Versions.	IR IR_A1	VoR
Parent_Data_Type	Identifies the nature of the parent.	IR	Journal
Parent_DOI	DOI assigned to the parent item in the format {DOI prefix}/{DOI suffix}.	IR IR_A1
Parent_Proprietary_ID	A proprietary ID that identifies the parent item. Format as {namespace}:{value} where the namespace is the platform ID of the host which assigned the proprietary identifier.	IR IR_A1	TandF:wser20
Parent_ISBN	ISBN of the parent item in the format ISBN-13 with hyphens.	IR
Parent_Print_ISSN	Print ISSN assigned to the parent item in the format nnnn-nnn[nX].	IR IR_A1	0361-526X
Parent_Online_ISSN	Online ISSN assigned to the parent item in the format nnnn-nnn[nX].	IR IR_A1	1541-1095
Parent_URI	URI (valid URL or URN according to RFC 3986) for the parent item.	IR IR_A1	https://www.tandfonline.com/action/journalInformation?journalCode=wser20

At least one DOI, ISBN, Online_ISSN, Print_ISSN, Proprietary_ID or URL MUST be included if parent information is provided for a report item. Note that only one value per identifier is permitted, unless specified otherwise.

Component Item Description and Identifiers

Repositories often store multiple components for a given repository item. These components could take the form of multiple files or datasets, which can be identified and usage reported on separately in Item Reports. Note that reporting on component usage is optional. For report providers who elect to do so, the component usage may only be reported for Total_Item_Investigations and Total_Item_Request. For other Metric_Types the usage cannot be broken down by component and the corresponding cells MUST be empty.

Note that delivering Components within an Item Report is optional.

Table 3.k (below): Elements that Describe a Component Item

Element Name	Description	Reports	Examples
Component_Title	Name or title of the component item.	IR	Research Data Plan
Component_Authors	Authors of the component item. See the Authors element in Table 3.i for the format.	IR	John Smith (ORCID:0000-0001-2345-6789)
Component_Publication_Date	Date of publication for the component item in the format yyyy-mm-dd.	IR	2022-09-05
Component_Data_Type	Data type of the component item.	IR	Other
Component_DOI	DOI assigned to the component item in the format {DOI prefix}/{DOI suffix}.	IR
Component_Proprietary_ID	A proprietary ID assigned by the repository to uniquely identify the component. Format as {namespace}:{value} where the namespace is the platform ID of the repository which assigned the proprietary identifier.	IR	repositorya:plan126
Component_ISBN	ISBN that is assigned to the component item in the format ISBN-13 with hyphens.	IR
Component_Print_ISSN	Print ISSN that is assigned to the component item in the format nnnn-nnn[nX].	IR
Component_Online_ISSN	Online ISSN that is assigned to the component item in the format nnnn-nnn[nX].	IR
Component_URI	URI (valid URL or URN according to RFC 3986) assigned to the component item.	IR

At least one DOI, ISBN, Online_ISSN, Print_ISSN, Proprietary_ID or URI per component MUST be included if component information is provided for a report item. Note that only one value per identifier is permitted, unless specified otherwise.

Item and Report Attributes

Table 3.l (below): Elements for Item and Report Attributes

Element Name	Description	Reports	Examples
Data_Type	Nature of the content that was used. See Section 3.3.2 for more detail.	PR, DR, TR, IR	Book Journal
YOP	Year of publication for the item being reported on. See Section 3.3.6 for more detail.	TR, IR TR_B1, TR_B2, TR_B3, TR_J4	1997
Access_Type	See Section 3.3.4 for more detail.	TR, IR TR_B3, TR_J3, IR_A1	Controlled Open Free_To_Read
Access_Method	See Section 3.3.5 for more detail.	PR, DR, TR, IR	Regular TDM

If one of the elements is included in a report, either because it is mandatory for a COUNTER Report (as specified in Section 4) or it is called for by the report consumer, a permissible value MUST be specified for each report item.

Metric Type

Table 3.m (below): Report Element for Metric_Type

Element Name	Description	Reports	Examples
Metric_Type	The type of activity that is being counted. See Section 3.3.3 for more detail.	All COUNTER Reports and Standard Views of COUNTER Reports	Total_Item_Investigations

Usage Data

Table 3.n (below): Elements for Usage Data

Element Name	Description	Reports	Examples
Reporting_Period_Total	Total of usage in this row for all months covered. Note that this element does NOT appear in the JSON reports, instead the JSON format offers a Granularity report attribute (see Section 3.3.7 for details).	All COUNTER Reports and Standard Views of COUNTER Reports	123456
Mmm-yyyy	A series of columns with usage for each month covered by the report. The format is Mmm-yyyy. Note: In the JSON format this is represented by the Counts element with the months in yyyy-mm format.	All COUNTER Reports and Standard Views of COUNTER Reports	May-2024

COUNTER Report Common Attributes and Elements

Early releases of the COUNTER Code of Practice focused on usage statistics related to journals. That was expanded to books, and later articles and multimedia collections were added. R5 further expanded the scope of COUNTER Reports. In order to help organize this increased scope in a consistent and coherent Code of Practice, several new elements and attributes have been added.

Host Types

Usage reports are provided by many different types of content hosts ranging from eBook to A&I_Database, eJournal, Discovery_Service, Multimedia etc. The usage reporting needs vary by Host_Type. To accommodate this variance, R5.1 defines a set of Host_Type categories. Although the Host_Type does not appear on the COUNTER report, the Code of Practice uses Host_Types throughout this document to help report providers identify which reports, elements, metric types, and attributes are relevant to them. The Host_Types are:

Table 3.o (below): List of Host_Type Values

Host_Type	Description	Examples
A&I_Database	Provides access to databases containing abstract and index information on scholarly articles intended to support discovery.	APA EBSCOhost ProQuest
Aggregated_Full_Content	Provides access to databases of full text serial and/or book content (monographs, reference works, etc.), and/or content otherwise aggregated into titles, where content is accessed in the context of the licensed database.	EBSCOhost ProQuest
Data_Repository	Includes subject repositories, institution, etc.	UK Data Service - ReShare Figshare DSpace Eprints
Discovery_Service	Assists users with discovery of scholarly content by providing access to a central index of articles, books, and other metadata.	EBSCOhost (EDS) ProQuest (Primo/Summon)
eBook	Provides access to eBook content made available as individual eBooks or eBook packages.	EBL EBSCOhost ScienceDirect
eBook_Collection	Provides access to eBook content that is sold as fixed collections and behaves like databases.	EBSCOhost
eJournal	Provides access to online serial (journals, conferences, newspapers, etc.) content made available as individual titles or packages.	ScienceDirect
Full_Content_Database	A COUNTER Host_Type for report providers that offer databases that are a collection of content items that are not aggregated into titles (i.e. not part of a serial or book or other title). Full_Content_Database may include but not be exclusively composed of multimedia content items.	Cochrane
Multimedia	Provides access to audio, video, or other multimedia content.	Alexander Street Press
Multimedia_Collection	Provides access to multimedia materials sold as and accessed like databases.
Repository	Provides access to an institution’s research output. Includes subject repositories, institution, department, etc.	Cranfield CERES
Scholarly_Collaboration_Network	A service used by researchers to share information about their work.	Mendeley Reddit/science

Note that a given content host may be classified as having multiple Host_Types and would be expected to provide reports, metric types, elements, and attributes applicable to all. For example, EBSCOhost would be classified as A&I_Database, Aggregated_Full_Content, Discovery_Service, eBook, and eBook_Collection.

Data Types

To facilitate flexible reporting, R5 introduced Data_Types representing major groupings of content. The extended list of Data_Types for R5.1 is detailed in Table 3.p below.

The table lists the Data_Types and related Host_Types which use them in one or more reports for compliance, but Host_Types may choose to offer additional reports. For example, we encourage all Host_Types to offer the Global Item Report using all relevant Data_Types.

Report providers MUST report metrics in line with the following:

• Host_Types required to provide the TR MUST deliver title level information in the PR (e.g. Journal for a journal article or Book for a book). If the DR is also required, usage MUST be reported at the title level within the DR.

• Host_Types required to provide the TR and which choose to also offer the IR MUST report usage at the item level in IR (e.g. Article for a journal article, Book_Segment for a book).

• Host_Types that are required to provide the IR MUST also report at item level in the PR and, if required, the DR. Only certain Data_Type and Parent_Data_Type combinations are permitted, as detailed in Table 3.q.

Table 3.p (below): List of Data_Type Values

Data_Type	Description	Host_Types	Reports
Article	An article from a journal, or an article available as a standalone piece of content (e.g. in an institutional repository) either as a preprint, an author accepted manuscript, a version of record, or another article version as defined by NISO RP-8-2008, Journal Article Versions. Article SHOULD NOT be used for content other than journal articles.	Repository Scholarly_Collaboration_Network	PR, IR PR_P1
Audiovisual	A form of multimedia, typically describing video content.	Full_Content_Database Multimedia Multimedia_Collection	PR, DR, IR PR_P1, IR_M1
Book	A monograph text, edited volume, textbook, or other form of book that is not a reference work.	A&I_Database Aggregated_Full_Content Discovery_Service eBook eBook_Collection	PR, DR, TR PR_P1, TR_B1, TR_B2, TR_B3
Book_Segment	A segment of a book (e.g. chapter, section, etc.), or a segment available as a standalone piece of content available as a distinct item not aggregated into a title, for example in an institutional repository. Where a whole book is being downloaded and it is not possible to identify Book_Segments (i.e. where the report provider lacks metadata at the level of the Book_Segment), the whole book MUST be counted as a single Book_Segment.	Repository Scholarly_Collaboration_Network	PR, IR PR_P1
Conference	A collection of papers, posters, or recordings of material associated with a conference. Typically part of a serial publication.	A&I_Database Aggregated_Full_Content Discovery_Service eBook eBook_Collection eJournal	PR, DR, TR PR_P1
Conference_Item	A single paper, poster, or recording of material associated with a conference.	Repository Scholarly_Collaboration_Network	PR, IR PR_P1
Database_Aggregated	Only applies to Denial and Search metrics. Activity within an aggregated database of full text serial and/or monograph content, or content otherwise aggregated into titles. A given item on the host may be in multiple databases but a transaction must be attributed to a specific database. Activity that would result in Investigation and Request metrics must be reported against the appropriate title level Data_Type (e.g. Journal for a journal article).	Aggregated_Full_Content eBook_Collection	DR
Database_AI	Only applies to Denial and Search metrics. Activity within a fixed database where bibliographic metadata is searched and accessed in the context of the database. A given item on the host may be in multiple databases but a transaction must be attributed to a specific database. Activity that would result in Investigation and Request metrics must be reported against the appropriate Data_Type (e.g. Journal for a journal article).	A&I_Database Discovery_Service	DR
Database_Full	Only applies to Denial and Search metrics. Activity within databases that are a collection of content items that are not aggregated into titles. A given item on the host may be in multiple databases but a transaction must be attributed to a specific database. Activity that would result in Investigation and Request metrics must be reported against the appropriate item-level Data_Type (e.g. Multimedia).	Full_Content_Database Multimedia_Collection	DR
Database_Full_Item	Usage of an item from a Full_Content_Database. Database_Full_Item applies where Investigations and Requests are being reported and a more specific Data_Type cannot be applied.	Full_Content_Database	PR, DR, IR PR_P1
Dataset	Data encoded in a defined structure, for example data associated with a research project.	Data_Repository Repository	PR, IR PR_P1
Image	A form of multimedia describing a static visual image.	Full_Content_Database Multimedia Multimedia_Collection	PR, DR, IR PR_P1, IR_M1
Interactive_Resource	A form of multimedia, typically describing materials that require user interaction to be understood, executed, or experienced (e.g. quizzes).	Full_Content_Database Multimedia Multimedia_Collection	PR, DR, IR PR_P1, IR_M1
Journal	A serial that is a branded and continually growing collection of original articles within a particular discipline.	A&I_Database Aggregated_Full_Content Discovery_Service eJournal Repository	PR, DR, TR PR_P1
Multimedia	Multimedia content such as audio, image, streaming audio, streaming video, and video, that cannot be easily classified as a specific multimedia Data_Type.	Full_Content_Database Multimedia Multimedia_Collection	PR, DR, IR PR_P1, IR_M1
News_Item	An article from a newspaper or magazine, or a news item available as a standalone piece of content available as a distinct item not aggregated into a title, for example in an institutional repository.	Repository Scholarly_Collaboration_Network	PR, IR PR_P1
Newspaper_or_Newsletter	Textual content published serially in a newspaper or newsletter.	A&I_Database Aggregated_Full_Content Discovery_Service eJournal	PR, DR, TR PR_P1
Other	Content that has been labelled with a data type that does not exist within and cannot be mapped to COUNTER’s Code of Practice. Other MUST NOT be used if there is not sufficient information available to classify the content.	A&I_Database Aggregated_Full_Content Discovery_Service Repository	PR, DR, TR, IR PR_P1
Patent	A patent document representing an exclusive right granted for an invention, which is a product or a process that provides, in general, a new way of doing something, or offers a new technical solution to a problem. Typically associated with a patent number.	A&I_Database Discovery_Service Full_Content_Database Repository Scholarly_Collaboration_Network	PR, DR, TR, IR PR_P1
Platform	Only applies to Searches_Platform metrics.	All Host_Types	PR PR_P1
Reference_Item	An item or record within a reference work (e.g. an encylopedia reference), or a reference item available as a standalone piece of content available as a distinct item not aggregated into a title, for example in an institutional repository. Where a whole reference work is being downloaded and it is not possible to identify Reference_Items (i.e. the report provider lacks metadata about individual Reference_Items), the whole reference work MUST be counted as a single Reference_Item.	Repository Scholarly_Collaboration_Network	PR, IR PR_P1
Reference_Work	An authoritative source of information about a subject used to find quick answers to questions, such as an encyclopedia or dictionary. The content may be stable or updated over time.	A&I_Database Aggregated_Full_Content Discovery_Service eBook eBook_Collection	PR, DR, TR PR_P1, TR_B1, TR_B2, TR_B3
Report	A document presenting information in an organized format for a specific audience and purpose, such as a policy report.	A&I_Database Aggregated_Full_Content Discovery_Service Repository Scholarly_Collaboration_Network	PR, DR, TR, IR PR_P1
Software	Source code or compiled software, or a virtual notebook environment used for programming.	Data_Repository Repository	PR, IR PR_P1
Sound	A form of multimedia, typically describing materials that are audio-only, such as radio programmes.	Full_Content_Database Multimedia Multimedia_Collection	PR, DR, IR PR_P1, IR_M1
Standard	A document outlining processes agreed and established by authority or by general consent (e.g. materials from NISO).	A&I_Database Aggregated_Full_Content Discovery_Service Repository Scholarly_Collaboration_Network	PR, DR, TR, IR PR_P1
Thesis_or_Dissertation	A thesis or dissertation, such as one written by a PhD candidate.	A&I_Database Aggregated_Full_Content Discovery_Service Repository Scholarly_Collaboration_Network	PR, DR, TR, IR PR_P1
Unspecified	Content that cannot be classified by any of the other Data_Types due to lack of sufficient information. Note that report providers are expected to make all reasonable efforts to classify the content. Using Unspecified will give rise to a Warning in the Validation Tool.	A&I_Database Aggregated_Full_Content Data_Repository Discovery_Service Repository Scholarly_Collaboration_Network	PR, DR, TR, IR PR_P1

Some Data_Types are associated with Parent_Data_Types. For example, Data_Type Article has Parent_Data_Type Journal, while Data_Type Book_Segment has Parent_Data_Type Book.

• Host_Types that MUST offer an IR MUST provide Parent_Data_Type and other relevant parent information if it is available.

• Host_Types that choose to offer an IR (e.g. eJournal or eBook) SHOULD provide Parent_Data_Type and other relevant parent information as specified in the table.

• Data_Types MUST NOT be used with other Parent_Data_Types than those listed in the table.

Table 3.q (below): List of Parent_Data_Type Values and Associated Data_Types

Data_Type in IR	Parent_Data_Type in IR
Article	Journal
Book_Segment	Book
Conference_Item	Conference
Database_Full_Item	Database_Full
News_Item	Newspaper_or_Newsletter
Reference_Item	Reference_Work

Metric Types

Metric_Types, which represent the nature of activity being counted, can be grouped into the categories of Searches, Investigations, Requests, and Access Denied. The Tables 3.r, 3.s and 3.t (below) list the Metric_Types and the Host_Types and reports they apply to.

Searches

Table 3.r (below): List of Metric_Types for Searches

Metric_Type	Description	Host_Types	Reports
Searches_Regular	Number of searches conducted against a database where results are returned to the user on the host UI and either a single database is searched, or multiple databases are searched and the user has the option of selecting the databases to be searched. This metric only applies to usage tracked at the database level and is not represented at the platform level.	A&I_Database Aggregated_Full_Content Discovery_Service eBook_Collection Full_Content_Database Multimedia_Collection	DR DR_D1
Searches_Automated	Number of searches conducted against a database on the host site or discovery service where results are returned in the host UI, multiple databases are searched and the user does NOT have the option of selecting the databases to be searched. This metric only applies to usage that is tracked at the database level and is not represented at the platform level.	A&I_Database Aggregated_Full_Content Discovery_Service eBook_Collection Full_Content_Database Multimedia_Collection	DR DR_D1
Searches_Federated	Searches conducted by a federated search engine where the search activity is conducted remotely via client-server technology. This metric only applies to usage that is tracked at the database level and is not represented at the platform level.	A&I_Database Aggregated_Full_Content Discovery_Service eBook_Collection Full_Content_Database Multimedia_Collection	DR DR_D1
Searches_Platform	Searches conducted by users and captured at the platform level. Each user-initiated search can only be counted once regardless of the number of databases involved in the search. This metric only applies to Platform Reports.	All Host_Types	PR PR_P1

*Repositories should provide these Metric_Types if they are able to.

Investigations and Requests of Items and Titles

This group of Metric_Types represents activities where content items were retrieved (Requests) or information about a content item (e.g. an abstract) was examined (Investigations). Any user activity that can be attributed to a content item will be considered an Investigation including downloading or viewing the item. Requests are limited to user activity related to retrieving or viewing the content item itself. The figure below provides a graphical representation of the relationship between Investigations and Requests.

Figure 3.e: The Relationship between Investigations and Requests

Totals, Unique Items and Unique Titles

R5 also introduced the concept of unique items and unique titles.

Unique_Item metrics were introduced in R5 to help eliminate the effect different styles of user interfaces may have on usage counts. With R5.1, if a single article is accessed multiple times in a given user session, the corresponding Unique_Item metric can only increase by 1 to simply indicate that the content item was accessed in the session. Unique_Item metrics provide comparable usage across journal platforms by reducing the inflationary effect that occurs when an HTML full text automatically displays and the user then accesses the PDF version.

The method for counting book usage in R5.1 at the item level is different than it was in R5. In R5.1, a Unique_Item_Investigation or Unique_Item_Request MUST be counted for each item (Book_Segment) that is used, independent of the method of content delivery.

• Where Book_Segments can be identified within a Book, a Unique_Item_Investigation MUST be counted for each Book_Segment with which a user interacts and a Unique_Item_Request counted for each Book_Segment accessed in full. This includes where users download or view the whole book as a single file.

• Where it is not possible to identify Book_Segments, the whole book MUST be counted as a single Book_Segment.

• The same rules apply to identifying and counting usage of other items within aggregated works, such as Reference_Items within Reference_Works or News_Items within Newspaper_or_Newsletters.

This change facilitates consistent reporting on items within the Item Report, and permits more accurate comparisons of usage across Data_Types, while retaining the ability to compare book usage across platforms through Unique_Title_Investigations and Unique_Title_Requests.

Unique_Title metrics were introduced in R5 to help normalize eBook metrics, and are retained in R5.1. Unique_Title metrics are only increased by 1 no matter how many (or how many times) chapters or sections are accessed in a given user session. Unique_Title metrics provide comparable eBook metrics regardless of the nature of the platform and how eBook content is delivered. They are comparable across report providers and across releases.

The Unique_Title metrics MUST NOT be used for Data_Types other than Book and Reference_Work as they are not meaningful for them. If a title contains both Open and Controlled sections or sections with different YOPs, the usage must be broken down by Access_Type and YOP so that the total counts are consistent between reports including and not including these columns/elements.

Table 3.s (below): List of Metric_Types for Requests and Investigations

Metric_Type	Description	Host_Types	Reports
Total_Item_Investigations	Total number of times a content item or information related to a content item was accessed. Double-click filters are applied to these transactions. Examples of content items are articles, book chapters, or multimedia files.	All Host_Types	PR, DR, TR, IR DR_D1, TR_B3, TR_J3
Unique_Item_Investigations	Number of unique content items investigated in a user-session. Examples of content items are articles, book chapters, or multimedia files.	All Host_Types	PR, DR, TR, IR TR_B3, TR_J3
Unique_Title_Investigations	Number of unique titles investigated in a user-session. This Metric_Type is only applicable for Data_Types Book and Reference_Work.	A&I_Database Aggregated_Full_Content Discovery_Service eBook eBook_Collection	PR, DR, TR TR_B3
Total_Item_Requests	Total number of times a content item was requested (i.e. the full text or content was downloaded or viewed). Double-click filters are applied to these transactions. Examples of content items are articles, book chapters, or multimedia files.	Aggregated_Full_Content Data_Repository eBook eBook_Collection eJournal Full_Content_Database Multimedia Multimedia_Collection Repository Scholarly_Collaboration_Network	PR, DR, TR, IR PR_P1, DR_D1, TR_B1, TR_B3, TR_J1, TR_J3, TR_J4, IR_A1, IR_M1
Unique_Item_Requests	Number of unique content items requested in a user-session. Examples of content items are articles, book chapters, or multimedia files.	Aggregated_Full_Content Data_Repository eBook eBook_Collection eJournal Full_Content_Database Multimedia Multimedia_Collection Repository Scholarly_Collaboration_Network	PR, DR, TR, IR PR_P1, TR_B3, TR_J1, TR_J3, TR_J4, IR_A1
Unique_Title_Requests	Number of unique titles requested in a user-session. This Metric_Type is only applicable for Data_Types Book and Reference_Work.	Aggregated_Full_Content eBook eBook_Collection	PR, DR, TR PR_P1, TR_B1, TR_B3

*Repositories should provide these Metric_Types if they are able to.

Access Denied

Table 3.t (below): List of Metric_Types for Access Denied

Metric_Type	Description	Host_Types	Reports
No_License	Number of times access was denied because the user’s institution did not have a license to the content. Double-click filtering applies to this Metric_Type. Note that if the user is automatically redirected to an abstract, that action will be counted as a No_License and also as an Item_Investigation.	A&I_Database Aggregated_Full_Content Discovery_Service eBook eBook_Collection eJournal Full_Content_Database Multimedia Multimedia_Collection Scholarly_Collaboration_Network	DR, TR, IR DR_D2, TR_B2, TR_J2
Limit_Exceeded	Number of times access was denied because the licensed simultaneous-user limit for the user’s institution was exceeded. Double-click filtering applies to this Metric_Type.	A&I_Database Aggregated_Full_Content Discovery_Service eBook eBook_Collection eJournal Full_Content_Database Multimedia Multimedia_Collection Scholarly_Collaboration_Network	DR, TR, IR DR_D2, TR_B2, TR_J2

Access Types

In order to separately track the usage of subscribed content, open access content, and freely available materials, R5.1 uses the Access_Type attribute with values of Controlled, Open, and Free_To_Read. The table below lists the Access_Types and the Host_Types and reports they apply to.

Note that the values for Access_Type changed in R5.1 to reflect community needs around reporting and to address common misunderstandings.

The Access_Type applied to an item MUST adhere to the following principles:

• Access_Type relates to access on the platform where the usage occurs: if access to a content item is restricted on a platform (for example because the article is included in an aggregated full-text database available to subscribers only) the Access_Type is Controlled, even if the content item is Open on a different platform.

• Access_Type applies to all parts of a content item. That is, the metadata, the full-text (if any) and supplementary materials (if any) all share a single Access_Type. For a journal article, for example, an Investigation of the article metadata must be reported under the same Access_Type as a Request for the full article.

• Access_Type applies in all circumstances. That is, an item MUST NOT be reported as Open for one user and as Controlled for a different user.

Table 3.u (below): List of Access_Type Values

Access_Type	Description	Host_Types	Reports
Controlled	At the time of the Request or Investigation the content item was restricted to authorized users (e.g. behind a paywall) on this platform. This includes free content that is only available to authorized (registered) users.	Aggregated_Full_Content Data_Repository eBook eBook_Collection eJournal Multimedia Repository Scholarly_Collaboration_Network	TR, IR TR_B1, TR_B2, TR_B3, TR_J1, TR_J2, TR_J3, TR_J4, IR_A1, IR_M1
Open	At the time of the Request or Investigation the content item was available to all users on this platform, regardless of authorization status, under an open access model. Open applies where the report provider asserts that the content is open access, irrespective of the license associated with the content item (that is, while the content item may be under a Creative Commons license this is not essential). Open content items may be in hybrid or fully open access publications. Open content items may have been Open from the day of publication, or after expiry of an embargo, but are not intended to return to Controlled status.	Aggregated_Full_Content Data_Repository eBook eBook_Collection eJournal Multimedia Repository Scholarly_Collaboration_Network	TR, IR TR_B3, TR_J3, IR_A1, IR_M1
Free_To_Read	At the time of the Request or Investigation the content item was available to all users on this platform, regardless of authorization status, but was not Open. The content item may or may not have been Controlled at some point in the past, and may or may not return to Controlled status in the future (e.g. promotional materials where these can be tracked by the platform, or archival content a publisher has made free to read).	Aggregated_Full_Content Data_Repository eBook eBook_Collection eJournal Multimedia Repository Scholarly_Collaboration_Network	TR, IR TR_B3, TR_J3, IR_A1, IR_M1

Access Methods

In order to track content usage accessed for the purpose of text and data mining (TDM) and to keep that usage separate from normal usage, R5 introduced the Access_Method attribute, with values of Regular and TDM. The table below lists the Access_Methods and the Host_Types and reports they apply to.

Table 3.v (below): List of Access_Method Values

Access_Method	Description	Host_Types	Reports
Regular	Refers to activities on a platform or content host that represent typical user behaviour.	All Host_Types	All COUNTER Reports and Standard Views of COUNTER Reports
TDM	Content and metadata accessed for the purpose of text and data mining, e.g. through a specific API used for TDM. Note that usage representing TDM activity is to be included in COUNTER Reports only.	All Host_Types	PR, DR, TR, IR

YOP

Analyzing collection usage by the age of the content is also desired. The YOP report attribute represents the year of publication, and it must be tracked for all Investigations, Requests and Access Denied metrics in the Title and Item Reports. The table below lists the Host_Types and reports the YOP attribute applies to.

Table 3.w (below): YOP Values

YOP	Description	Host_Types	Reports
yyyy	The year of publication for the item as a four-digit year. If a content item has a different year of publication for an online version than for the print version, use the year of publication for the Version of Record. If the year of publication is not known, use a value of 0001. For articles in press (not yet assigned to an issue), use the value 9999.	Aggregated_Full_Content Data_Repository eBook eBook_Collection eJournal Multimedia Repository Scholarly_Collaboration_Network	TR, IR TR_B1, TR_B2, TR_B3, TR_J1, TR_J2, TR_J3, TR_J4, IR_A1, IR_M1

Report Filters and Report Attributes

Customized views of the usage data are created by applying report filters and report attributes to the COUNTER Reports. The Standard Views of the COUNTER Reports specified by R5.1 are examples of such views. Report attributes define the columns (elements) and report filters the rows (values) included in the reports. For COUNTER Reports the user can choose from specific sets of filters and attributes depending on the report, while for Standard Views of the COUNTER Reports the filters and attributes are pre-set except for an optional Platform filter.

The filters and attributes used to create a report are included in the report header (unless the default value is used, in this case the filter/attribute MUST be omitted), for JSON reports as Report_Filters and Report_Attributes objects and for tabular reports encoded in the Metric_Types, Reporting_Period, Report_Filters and Report_Attributes elements (see Section 3.2.1 for the encoding). For the COUNTER_SUSHI API each filter/attribute corresponds to a API path parameter with the same name in lower case (see the COUNTER_SUSHI API Specification for details).

The tables below show the attributes and filters and the reports where they (might) appear in the header (excluding Standard Views using the default values).

Table 3.x (below): Report Attributes

Report Attribute	Description	Reports
Attributes_To_Show	List of additional columns/elements to include in the report (default: none). See Section 4.1.2, Section 4.2.2, Section 4.3.2 and Section 4.4.2 for permissible values. Note that the component and parent columns/elements cannot be selected individually and MUST NOT be included in the list (see the Include_Component_Details and Include_Parent_Details attributes below).	PR, DR, TR, IR
Exclude_Monthly_Details	Specifies whether to exclude the columns with the monthly usage from the report. Permissible values are False (default) and True. This attribute is only applicable for tabular reports. The corresponding attribute for JSON reports is Granularity.	PR, DR, TR, IR (tabular)
Granularity	Specifies the granularity of the usage data to include in the report. Permissible values are Month (default) and Totals. This attribute is only applicable to JSON reports, the corresponding attribute for tabular reports is Exclude_Monthly_Details. For Totals each Item_Performance element represents the aggregated usage for the reporting period. Support for Month is REQUIRED for COUNTER compliance, support for Totals is optional.	PR, DR, TR, IR (JSON)
Include_Component_Details	Specifies whether to include the component columns/elements (see Table 3.k) in the report, where report providers offer component usage reporting. Permissible values are False (default) and True.	IR
Include_Parent_Details	Specifies whether to include the parent columns/elements (see Table 3.j) in the report. Permissible values are False (default) and True.	IR

Table 3.y (below): Report Filters

Report Filter	Description	Reports
Access_Method	List of Access_Methods for which to include usage (default: all). See Section 4.1.3, Section 4.2.3, Section 4.3.3 and Section 4.4.3 for permissible/pre-set values.	All COUNTER Reports and Standard Views of COUNTER Reports
Access_Type	List of Access_Types for which to include usage (default: all). See Section 4.3.3 and Section 4.4.3 for permissible/pre-set values.	TR, IR TR_B1, TR_B2, TR_J1, TR_J2, TR_J4, IR_A1
Begin_Date End_Date	Beginning and end of the reporting period. Note that the COUNTER_SUSHI API allows the format yyyy-mm for the API path parameters, which must be expanded with the first/last day of the month for the report header. For the tabular reports these filters are included in the Reporting_Period header instead of the Reporting_Filters header for easier reading.	All COUNTER Reports and Standard Views of COUNTER Reports
Database	Name of a specific database for which usage is being requested (default: all). Support for this filter is optional but recommended for the reporting website.	DR
Data_Type	List of Data_Types for which to include usage (default: all). See Section 4.1.3, Section 4.2.3, Section 4.3.3 and Section 4.4.3 for permissible/pre-set values.	PR, DR, TR, IR TR_B1, TR_B2, TR_B3, TR_J1, TR_J2, TR_J3, TR_J4, IR_A1, IR_M1
Item_Contributor	Identifier of a specific contributor (author) for which usage is being requested (default: all). Support for this filter is optional but recommended for the reporting website.	IR
Item_ID	Identifier of a specific item for which usage is being requested. Support for this filter is optional but recommended for the reporting website.	TR, IR
Metric_Type	List of Metric_Types for which to include usage (default: all). See Section 4.1.3, Section 4.2.3, Section 4.3.3 and Section 4.4.3 for permissible/pre-set values. For the tabular reports this filter is included in the Metric_Types header instead of the Reporting_Filters header for easier reading.	All COUNTER Reports and Standard Views of COUNTER Reports
Platform	The Platform filter is only intended in cases where there is a single endpoint for multiple platforms; that is, the same base URL for the COUNTER_SUSHI API is used for multiple platforms and the platform parameter is required for all API calls. In the web interface this would correspond to first selecting one platform and then creating reports only for that platform.	All COUNTER Reports and Standard Views of COUNTER Reports
YOP	Range of years of publication for which to include usage (default: all). For the COUNTER_SUSHI API more complex filter values (list of years and ranges) MUST be supported.	TR, IR

Zero Usage

Not all report providers are able to link COUNTER reporting tools to the relevant subscription database(s), so R5.1 reports cannot include zero-usage reporting based on subscription records. Equally, inclusion of zero-usage reporting for everything, including unsubscribed content, could make reports unmanageably large. The need for report consumers to identify subscribed titles with zero usage is addressed by NISO RP-26-2019, KBART Automation: Automated Retrieval of Customer Electronic Holdings.

• For tabular reports

  • Omit any row where the Reporting_Period_Total would be zero.

  • If the Reporting_Period_Total is not zero, but usage for an included month is zero, set the cell value for that month to 0.

• For JSON reports

  • Omit months with zero usage from the Counts element.

  • Omit Metric_Types with an empty Counts element.

  • Omit Performance with no Metric_Types.

  • Omit Attribute_Performance with no Performance.

  • Omit Report_Items with no Attribute_Performance.

Missing and Unknown Values

The value for an element might be missing or unknown, for example a title might not have an ISBN or the ISBN might be unknown. In COUNTER reports this is expressed as follows:

• For tabular reports the cell MUST be left blank.

• For JSON reports

  • If the COUNTER_SUSHI API Specification (see Section 8) indicates the element is REQUIRED, the value of the element MUST be expressed as empty as appropriate for the data type.

  • If the element is not REQUIRED according to the COUNTER_SUSHI API Specification, the element MUST be omitted.

For clarity, values such as “unknown”, “n/a” or “-” MUST NOT be used.

If a non-empty value is required for an element and the value is empty or the element is omitted, the COUNTER Validation Tool reports a (Critical) Error which would cause the report to fail an audit. If Title, Item or Publisher is empty or Data_Type Unspecified is used, the COUNTER Validation Tool reports a Warning which might affect the result of an audit. See Section 9.4 for details on the error levels used by the Validation Tool.

COUNTER reports

Platform Reports

Platform Reports provide a summary of activity on a given platform to support the evaluation of platforms and to provide high-level statistical data to support surveys and reporting to funders.

To better facilitate open access reporting, report providers are encouraged to provide a Global Platform Report including all global usage, whether attributed to institutions or not. The Global Platform Report could be filtered and broken down as usual, including by using Attributed and other extensions (see Section 11.5).

Table 4 (below): Platform Report and Standard Views of the Platform Report

Report_ID	Report_Name	Details	Host_Types
PR	Platform Report	A customizable report summarizing activity across a report provider’s platforms that allows the user to apply filters and select other configuration options.	All Host_Types
PR_P1	Platform Usage	Platform-level usage summarized by Metric_Type.	All Host_Types

*Data repositories may choose to conform to the Code of Practice Release 5.1 or, alternatively, may wish to work with the Code of Practice for Research Data.

Report Header

The table below shows the header details for the Platform Report and its Standard Views. For the tabular reports, elements MUST appear in the exact order shown, and spelling, casing, and punctuation of labels (Column A) and fixed data elements such as report names (Column B) MUST match exactly. The JSON version of the report MUST comply with the Report_Header definition in the COUNTER_SUSHI API Specification (see Section 8 below). Entries in the table appearing in italics describe the values to include.

Note that for the Global Platform Report, if provided, the Institution_Name should be “The World”.

Table 4.a (below): Header for Platform Report and Standard Views of the Platform Report

Row in Tabular Report	Label for Tabular Report (Column A)	Value for Tabular Report (Column B)
		PR	PR_P1
1	Report_Name	Platform Report	Platform Usage
2	Report_ID	PR	PR_P1
3	Release	5.1	5.1
4	Institution_Name	Name of the institution the usage is attributed to.
5	Institution_ID	Identifier(s) for the institution in the format of {namespace}:{value}. Leave blank if identifier is not known. Multiple identifiers may be included by separating with semicolon-space (“; ”).
6	Metric_Types	Semicolon-space delimited list of Metric_Types included in the report.	Searches_Platform; Total_Item_Requests; Unique_Item_Requests; Unique_Title_Requests
7	Report_Filters	Semicolon-space delimited list of filters applied to the data to generate the report.	Access_Method=Regular*
8	Report_Attributes	Semicolon-space delimited list of report attributes applied to the data to generate the report.	(blank)
9	Exceptions	Any exceptions that occurred in generating the report, in the format “{Exception Code}: {Exception Message} ({Data})” with multiple exceptions separated by semicolon-space (“; ”).
10	Reporting_Period	Date range requested for the report in the form of “Begin_Date=yyyy-mm-dd; End_Date=yyyy-mm-dd”. The “dd” of the Begin_Date is 01. The “dd” of the End_Date is the last day of the month.
11	Created	Date and time the report was run in RFC3339 date-time format (yyyy-mm-ddThh:mm:ssZ).
12	Created_By	Name of organization or system that generated the report.
13	Registry_Record	Link to the platform’s COUNTER Registry record.
14	(blank)	(blank)	(blank)

*If a Platform filter is used (see Section 3.3.7 for details), it MUST be included in Report_Filters.

Column Headings/Elements

The following elements MUST appear in the tabular report in the order they appear in the table below. For guidance on how these elements appear in the JSON format, refer to the COUNTER_SUSHI API Specification (see Section 8 below). Mandatory (M) elements MUST be included in the report. The other elements MUST only be included in the COUNTER Report if called for (C), and if included they MUST be listed in Attributes_To_Show in the Report_Attributes header.

Table 4.b (Below): Column Headings/Elements for Platform Report and Standard Views of the Platform Report

Element Name (Tabular)	PR	PR_P1
Platform	M	M
Data_Type	M	M
Access_Method	C
Metric_Type	M	M
Reporting_Period_Total	M	M
Mmm-yyyy	M*	M

*unless Exclude_Monthly_Details=True is used

Filters and Attributes

The following table presents the values that can be chosen for the Platform Report and that are pre-set for the Standard Views of the Platform Report. If a filter is not included in the request, the default applies. For the Standard Views an empty cell indicates that the filter is not applied.

Table 4.c (below) Filters/Attributes for Platform Report and Standard Views of the Platform Report

Filter/Attribute	Filters available (options for Platform Report and required for Standard Views of the Platform Report)
	PR	PR_P1
Data_Type	One or more or all (default) of the Data_Types applicable to the platform.
Access_Method	One or all (default) of: - Regular - TDM	Regular
Metric_Type	One or more or all (default) of: - Searches_Platform - Total_Item_Investigations - Total_Item_Requests - Unique_Item_Investigations - Unique_Item_Requests - Unique_Title_Investigations - Unique_Title_Requests	Searches_Platform Total_Item_Requests Unique_Item_Requests Unique_Title_Requests
Exclude_Monthly_Details	False (default) or True

If a filter is applied to a column that does not show on the report, usage for all selected attribute values is summed and the totals are presented in the report.

Database Reports

Database Reports provide a summary of activity related to a given database or fixed collection of content that is packaged like a database. These reports provide a means of evaluating the impact a database has for an institution’s users.

To better facilitate open access reporting, report providers are encouraged to provide a Global Database Report including all global usage, whether attributed to institutions or not. The Global Database Report could be filtered and broken down as usual, including by using Attributed and other extensions (see Section 11.5).

Table 4.d (below): Database Report and Standard Views of the Database Report

Report_ID	Report_Name	Details	Host_Types
DR	Database Report	A customizable report detailing activity by database that allows the user to apply filters and select other configuration options.	A&I_Database Aggregated_Full_Content Discovery_Service eBook_Collection Full_Content_Database Multimedia_Collection
DR_D1	Database Search and Item Usage	Reports on key Searches, Investigations and Requests metrics needed to evaluate a database.	A&I_Database Aggregated_Full_Content Discovery_Service eBook_Collection Full_Content_Database Multimedia_Collection
DR_D2	Database Access Denied	Reports on Access Denied activity for databases where users were denied access because simultaneous-use licenses were exceeded or their institution did not have a license for the database.	A&I_Database Aggregated_Full_Content Discovery_Service eBook_Collection Full_Content_Database Multimedia_Collection

Report Header

The table below shows the header details for the Database Report and its Standard Views. For the tabular reports, elements MUST appear in the exact order shown, and spelling, casing, and punctuation of labels (Column A) and fixed data elements such as report names (Column B) MUST match exactly. The JSON version of the report MUST comply with the Report_Header definition in the COUNTER_SUSHI API Specification (see Section 8 below). Entries in the table appearing in italics describe the values to include.

Note that for the Global Database Report, if provided, the Institution_Name should be “The World”.

Table 4.e (below): Header for Database Report and Standard Views of the Database Report

Row in Tabular Report	Label for Tabular Report (Column A)	Value for Tabular Report (Column B)
		DR	DR_D1	DR_D2
1	Report_Name	Database Report	Database Search and Item Usage	Database Access Denied
2	Report_ID	DR	DR_D1	DR_D2
3	Release	5.1	5.1	5.1
4	Institution_Name	Name of the institution the usage is attributed to.
5	Institution_ID	Identifier(s) for the institution in the format of {namespace}:{value}. Leave blank if identifier is not known. Multiple identifiers may be included by separating with semicolon-space (“; ”).
6	Metric_Types	Semicolon-space delimited list of Metric_Types included in the report.	Searches_Automated; Searches_Federated; Searches_Regular; Total_Item_Investigations; Total_Item_Requests; Unique_Item_Investigations; Unique_Item_Requests	Limit_Exceeded; No_License
7	Report_Filters	Semicolon-space delimited list of filters applied to the data to generate the report.	Access_Method=Regular*	Access_Method=Regular*
8	Report_Attributes	Semicolon-space delimited list of report attributes applied to the data to generate the report.	(blank)	(blank)
9	Exceptions	Any exceptions that occurred in generating the report, in the format “{Exception Code}: {Exception Message} ({Data})” with multiple exceptions separated by semicolon-space (“; ”).
10	Reporting_Period	Date range requested for the report in the form of “Begin_Date=yyyy-mm-dd; End_Date=yyyy-mm-dd”. The “dd” of the Begin_Date is 01. The “dd” of the End_Date is the last day of the month.
11	Created	Date and time the report was run in RFC3339 date-time format (yyyy-mm-ddThh:mm:ssZ).
12	Created_By	Name of organization or system that generated the report.
13	Registry_Record	Link to the platform’s COUNTER Registry record.
14	(blank)	(blank)	(blank)	(blank)

*If a Platform filter is used (see Section 3.3.7 for details), it MUST be included in Report_Filters.

Column Headings/Elements

The following elements MUST appear in the tabular report in the order they appear in the table below. For guidance on how these elements appear in the JSON format, refer to the COUNTER_SUSHI API Specification (see Section 8 below). Mandatory (M) elements MUST be included in the report. The other elements MUST only be included in the COUNTER Report if called for (C), and if included they MUST be listed in Attributes_To_Show in the Report_Attributes header.

Table 4.f (below): Column Headings/Elements for Database Report and Standard Views of the Database Report

Element Name (Tabular)	DR	DR_D1	DR_D2
Database	M	M	M
Publisher	M	M	M
Publisher_ID	M	M	M
Platform	M	M	M
Proprietary_ID	M	M	M
Data_Type	M
Access_Method	C
Metric_Type	M	M	M
Reporting_Period_Total	M	M	M
Mmm-yyyy	M*	M	M

*unless Exclude_Monthly_Details=True is used

Filters and Attributes

The following table presents the values that can be chosen for the Database Report and that are pre-set for the Standard Views of the Database Report. If a filter is not included in the request, the default applies. For the Standard Views an empty cell indicates that the filter is not applied.

Table 4.g (below): Filters/Attributes for Database Report and Standard Views of the Database Report

Filter/Attribute	Filters available (options for Database Report and required for Standard Views of the Database Report)
	DR	DR_D1	DR_D2
Data_Type	One or more or all (default) of the Data_Types applicable to the platform.
Access_Method	One or all (default) of: - Regular - TDM	Regular	Regular
Metric_Type	One or more or all (default) of: - Searches_Automated - Searches_Federated - Searches_Regular - Total_Item_Investigations - Total_Item_Requests - Unique_Item_Investigations - Unique_Item_Requests - Unique_Title_Investigations - Unique_Title_Requests - Limit_Exceeded - No_License	Searches_Automated Searches_Federated Searches_Regular Total_Item_Investigations Total_Item_Requests Unique_Item_Investigations Unique_Item_Requests	Limit_Exceeded No_License
Exclude_Monthly_Details	False (default) or True

If a filter is applied to a column that doesn’t show on the report, usage for all selected attribute values is summed and the totals are presented in the report.

Title Reports

Title Reports provide a summary of activity related to content at the title level and provide a means of evaluating the impact a title has for an institution’s patrons.

To better facilitate open access reporting, report providers are encouraged to provide a Global Title Report including all global usage, whether attributed to institutions or not. The Global Title Report could be filtered and broken down as usual, including by using Attributed and other extensions (see Section 11.5).

Table 4.h (below): Title Report and Standard Views of the Title Report

Report_ID	Report_Name	Details	Host_Types
TR	Title Report	A customizable report detailing activity at the title level (journal, book, etc.) that allows the user to apply filters and select other configuration options.	Aggregated_Full_Content eBook eBook_Collection eJournal
TR_B1	Book Requests (Controlled)	Reports on full-text activity for books (Data_Types Book and Reference_Work), excluding Open and Free_To_Read content, as Total_Item_Requests and Unique_Title_Requests. The Unique_Title_Requests provides comparable usage across book platforms. The Total_Item_Requests shows overall activity; however, numbers between sites will vary significantly based on how the content is delivered (e.g. delivered as a complete book or by chapter).	Aggregated_Full_Content eBook eBook_Collection
TR_B2	Book Access Denied	Reports on Access Denied activity for books (Data_Types Book and Reference_Work) where users were denied access because simultaneous-use licenses were exceeded or their institution did not have a license for the book.	Aggregated_Full_Content eBook eBook_Collection
TR_B3	Book Usage by Access Type	Reports on book usage (Data_Types Book and Reference_Work) showing all applicable Metric_Types broken down by Access_Type.	Aggregated_Full_Content eBook eBook_Collection
TR_J1	Journal Requests (Controlled)	Reports on usage of journal content, excluding Open and Free_To_Read content, as Total_Item_Requests and Unique_Item_Requests. The Unique_Item_Requests provides comparable usage across journal platforms by reducing the inflationary effect that occurs when an HTML full text automatically displays and the user then accesses the PDF version. The Total_Item_Requests shows overall activity.	Aggregated_Full_Content eJournal
TR_J2	Journal Access Denied	Reports on Access Denied activity for journal content where users were denied access because simultaneous-use licenses were exceeded or their institution did not have a license for the title.	Aggregated_Full_Content eJournal
TR_J3	Journal Usage by Access Type	Reports on usage of journal content for all Metric_Types broken down by Access_Type.	Aggregated_Full_Content eJournal
TR_J4	Journal Requests by YOP (Controlled)	Breaks down the usage of journal content, excluding Open and Free_To_Read content, by year of publication (YOP), providing counts for the Metric_Types Total_Item_Requests and Unique_Item_Requests. Provides the details necessary to analyze usage of content in backfiles or covered by perpetual access agreement. Note that COUNTER reports do not provide access model or perpetual access rights details.	Aggregated_Full_Content eJournal

Report Header

The table below shows the header details for the Title Report and its Standard Views. For the tabular reports, elements MUST appear in the exact order shown, and spelling, casing, and punctuation of labels (Column A) and fixed data elements such as report names (Column B) MUST match exactly. The JSON version of the report MUST comply with the Report_Header definition in the COUNTER_SUSHI API Specification (see Section 8 below). Entries in the table appearing in italics describe the values to include.

Note that for the Global Title Report, if provided, the Institution_Name should be “The World”.

Table 4.i (below) Header for Title Report and Standard Views of the Title Report - Part 1 (for Books)

Row in Tabular Report	Label for Tabular Report (Column A)	Value for Tabular Report (Column B)
		TR	TR_B1	TR_B2	TR_B3
1	Report_Name	Title Report	Book Requests (Controlled)	Book Access Denied	Book Usage by Access Type
2	Report_ID	TR	TR_B1	TR_B2	TR_B3
3	Release	5.1	5.1	5.1	5.1
4	Institution_Name	Name of the institution the usage is attributed to.
5	Institution_ID	Identifier(s) for the institution in the format of {namespace}:{value}. Leave blank if identifier is not known. Multiple identifiers may be included by separating with semicolon-space (“; ”).
6	Metric_Types	Semicolon-space delimited list of Metric_Types included in the report.	Total_Item_Requests; Unique_Title_Requests	Limit_Exceeded; No_License	Total_Item_Investigations; Total_Item_Requests; Unique_Item_Investigations; Unique_Item_Requests; Unique_Title_Investigations; Unique_Title_Requests
7	Report_Filters	Semicolon-space delimited list of filters applied to the data to generate the report.	Data_Type=Book| Reference_Work; Access_Type=Controlled; Access_Method=Regular*	Data_Type=Book| Reference_Work; Access_Method=Regular*	Data_Type=Book| Reference_Work; Access_Method=Regular*
8	Report_Attributes	Semicolon-space delimited list of report attributes applied to the data to generate the report.	(blank)	(blank)	(blank)
9	Exceptions	Any exceptions that occurred in generating the report, in the format “{Exception Code}: {Exception Message} ({Data})” with multiple exceptions separated by semicolon-space (“; ”).
10	Reporting_Period	Date range requested for the report in the form of “Begin_Date=yyyy-mm-dd; End_Date=yyyy-mm-dd”. The “dd” of the Begin_Date is 01. The “dd” of the End_Date is the last day of the month.
11	Created	Date and time the report was run in RFC3339 date-time format (yyyy-mm-ddThh:mm:ssZ).
12	Created_By	Name of organization or system that generated the report.
13	Registry_Record	Link to the platform’s COUNTER Registry record.
14	(blank)	(blank)	(blank)	(blank)	(blank)

*If a Platform filter is used (see Section 3.3.7 for details), it MUST be included in Report_Filters.

Table 4.j (below): Header for Standard Views of the Title Report - Part 2 (for Journals)

Row in Tabular Report	Label for Tabular Report (Column A)	Value for Tabular Report (Column B)
		TR_J1	TR_J2	TR_J3	TR_J4
1	Report_Name	Journal Requests (Controlled)	Journal Access Denied	Journal Usage by Access Type	Journal Requests by YOP (Controlled)
2	Report_ID	TR_J1	TR_J2	TR_J3	TR_J4
3	Release	5.1	5.1	5.1	5.1
4	Institution_Name	Name of the institution the usage is attributed to.
5	Institution_ID	Identifier(s) for the institution in the format of {namespace}:{value}. Leave blank if identifier is not known. Multiple identifiers may be included by separating with semicolon-space (“; ”).
6	Metric_Types	Total_Item_Requests; Unique_Item_Requests	Limit_Exceeded; No_License	Total_Item_Investigations; Total_Item_Requests; Unique_Item_Investigations; Unique_Item_Requests	Total_Item_Requests; Unique_Item_Requests
7	Report_Filters	Data_Type=Journal; Access_Type=Controlled; Access_Method=Regular*	Data_Type=Journal; Access_Method=Regular*	Data_Type=Journal; Access_Method=Regular*	Data_Type=Journal; Access_Type=Controlled; Access_Method=Regular*
8	Report_Attributes	(blank)	(blank)	(blank)	(blank)
9	Exceptions	Any exceptions that occurred in generating the report, in the format “{Exception Code}: {Exception Message} ({Data})” with multiple exceptions separated by semicolon-space (“; ”).
10	Reporting_Period	Date range requested for the report in the form of “Begin_Date=yyyy-mm-dd; End_Date=yyyy-mm-dd”. The “dd” of the Begin_Date is 01. The “dd” of the End_Date is the last day of the month.
11	Created	Date and time the report was run in RFC3339 date-time format (yyyy-mm-ddThh:mm:ssZ).
12	Created_By	Name of organization or system that generated the report.
13	Registry_Record	Link to the platform’s COUNTER Registry record.
14	(blank)	(blank)	(blank)	(blank)	(blank)

*If a Platform filter is used (see Section 3.3.7 for details), it MUST be included in Report_Filters.

Column Headings/Elements

The following elements MUST appear in the tabular report in the order they appear in the table below. For guidance on how these elements appear in the JSON format, refer to the COUNTER_SUSHI API Specification (see Section 8 below). Mandatory (M) elements MUST be included in the report. The other elements MUST only be included in the COUNTER Report if called for (C), and if included they MUST be listed in Attributes_To_Show in the Report_Attributes header.

Table 4.k (below): Column Headings/Elements for Title Report and Standard Views of the Title Report

Element Name (Tabular)	TR	TR_B1	TR_B2	TR_B3	TR_J1	TR_J2	TR_J3	TR_J4
Title	M	M	M	M	M	M	M	M
Publisher	M	M	M	M	M	M	M	M
Publisher_ID	M	M	M	M	M	M	M	M
Platform	M	M	M	M	M	M	M	M
DOI	M	M	M	M	M	M	M	M
Proprietary_ID	M	M	M	M	M	M	M	M
ISBN	M	M	M	M
Print_ISSN	M	M	M	M	M	M	M	M
Online_ISSN	M	M	M	M	M	M	M	M
URI	M	M	M	M	M	M	M	M
Data_Type	M	M	M	M
YOP	C	M	M	M				M
Access_Type	C			M			M
Access_Method	C
Metric_Type	M	M	M	M	M	M	M	M
Reporting_Period_Total	M	M	M	M	M	M	M	M
Mmm-yyyy	M*	M	M	M	M	M	M	M

*unless Exclude_Monthly_Details=True is used

Filters and Attributes

The following table presents the values that can be chosen for the Title Report and that are pre-set for the Standard Views of the Title Report. If a filter is not included in the request, the default applies. For the Standard Views an empty cell indicates that the filter is not applied.

Table 4.l (below): Filters/Attributes for Title Report and Standard Views of the Title Report - Part 1 (for Books)

Filter/Attribute	Filters available (options for Title Report and required for Standard Views of the Title Report)
	TR	TR_B1	TR_B2	TR_B3
Data_Type	One or more or all (default) of the Data_Types applicable to the platform.	Book Reference_Work	Book Reference_Work	Book Reference_Work
YOP	All years (default), a specific year in the format yyyy, or a range of years in the format yyyy-yyyy. Use 0001 for unknown or 9999 for articles in press. Note that the COUNTER_SUSHI API allows the specification of multiple years and ranges separated by the vertical pipe (“|”) character.
Access_Type	One or more or all (default) of: - Controlled - Open - Free_To_Read	Controlled
Access_Method	One or all (default) of: - Regular - TDM	Regular	Regular	Regular
Metric_Type	One or more or all (default) of: - Total_Item_Investigations - Total_Item_Requests - Unique_Item_Investigations - Unique_Item_Requests - Unique_Title_Investigations - Unique_Title_Requests - Limit_Exceeded - No_License	Total_Item_Requests Unique_Title_Requests	Limit_Exceeded No_License	Total_Item_Investigations Total_Item_Requests Unique_Item_Investigations Unique_Item_Requests Unique_Title_Investigations Unique_Title_Requests
Exclude_Monthly_Details	False (default) or True

Table 4.m (below): Filters/Attributes for Standard Views of the Title Report - Part 2 (for Journals)

Filter/Attribute	Filters available (options for Title Report and required for Standard Views of the Title Report)
	TR_J1	TR_J2	TR_J3	TR_J4
Data_Type	Journal	Journal	Journal	Journal
YOP
Access_Type	Controlled			Controlled
Access_Method	Regular	Regular	Regular	Regular
Metric_Type	Total_Item_Requests Unique_Item_Requests	Limit_Exceeded No_License	Total_Item_Investigations Total_Item_Requests Unique_Item_Investigations Unique_Item_Requests	Total_Item_Requests Unique_Item_Requests
Exclude_Monthly_Details

If a filter is applied to a column that doesn’t show on the report, usage for all selected attribute values is summed and the totals are presented in the report.

Item Reports

Item Reports provide a summary of activity related to content at the item level and provide a means of evaluating the impact an item has for an institution’s patrons.

To better facilitate open access reporting, Release 5.1 encourages all Host_Types to provide a Global Item Report, which provides a granular per-item view of all usage, whether attributed to institutions or not. This is particularly relevant for report providers with open access content. The Global Item Report is an Item Report to “The World” including all global usage, whether attributed to an institution or not, which could be broken down by geolocation with the Country and Subdivision extensions, as well as by using Attributed and other extensions (see Section 11.5).

Table 4.n (below): Item Report and Standard Views of the Item Report

Report_ID	Report_Name	Details	Host_Types
IR	Item Report	A granular, customizable report showing activity at the level of the item (article, chapter, media object, etc.) that allows the user to apply filters and select other configuration options.	Data_Repository* Multimedia Repository Scholarly_Collaboration_Network
IR_A1	Journal Article Requests	Reports on journal article requests at the article level. This report is limited to content with a Data_Type of Article and Metric_Types of Total_Item_Requests and Unique_Item_Requests.	Repository Scholarly_Collaboration_Network
IR_M1	Multimedia Item Requests	Reports on multimedia requests at the item level.	Multimedia

*Data repositories may choose to conform to the Code of Practice Release 5 or, alternatively, may wish to work with the Code of Practice for Research Data.

Report Header

The table below shows the header details for the Item Report and its Standard Views. For the tabular reports, elements MUST appear in the exact order shown, and spelling, casing and punctuation of labels (Column A) and fixed data elements such as report names (Column B) MUST match exactly. The JSON version of the report MUST comply with the Report_Header definition in the COUNTER_SUSHI API Specification (see Section 8 below). Entries in the table appearing in italics describe the values to include.

Note that for the Global Item Report, if provided, the Institution_Name should be “The World”.

Table 4.o (below): Header for Item Report and Standard Views of the Item Report

Row in Tabular Report	Label for Tabular Report (Column A)	Value for Tabular Report (Column B)
		IR	IR_A1	IR_M1
1	Report_Name	Item Report	Journal Article Requests	Multimedia Item Requests
2	Report_ID	IR	IR_A1	IR_M1
3	Release	5.1	5.1	5.1
4	Institution_Name	Name of the institution the usage is attributed to.
5	Institution_ID	Identifier(s) for the institution in the format of {namespace}:{value}. Leave blank if identifier is not known. Multiple identifiers may be included by separating with semicolon-space (“; ”).
6	Metric_Types	Semicolon-space delimited list of Metric_Types included in the report.	Total_Item_Requests; Unique_Items_Requests	Total_Item_Requests; Unique_Items_Requests
7	Report_Filters	Semicolon-space delimited list of filters applied to the data to generate the report.	Data_Type=Article; Access_Method=Regular*	Data_Type=Audiovisual| Image|Interactive_Resource| Multimedia|Sound; Access_Method=Regular*
8	Report_Attributes	Semicolon-space delimited list of report attributes applied to the data to generate the report.	(blank)	(blank)
9	Exceptions	Any exceptions that occurred in generating the report, in the format “{Exception Code}: {Exception Message} ({Data})” with multiple exceptions separated by semicolon-space (“; ”).
10	Reporting_Period	Date range requested for the report in the form of “Begin_Date=yyyy-mm-dd; End_Date=yyyy-mm-dd”. The “dd” of the Begin_Date is 01. The “dd” of the End_Date is the last day of the month.
11	Created	Date and time the report was run in RFC3339 date-time format (yyyy-mm-ddThh:mm:ssZ).
12	Created_By	Name of organization or system that generated the report.
13	Registry_Record	Link to the platform’s COUNTER Registry record.
14	(blank)	(blank)	(blank)	(blank)

*If a Platform filter is used (see Section 3.3.7 for details), it MUST be included in Report_Filters.

Column Headings/Elements

The following elements MUST appear in the tabular report in the order they appear in the table below. For guidance on how these elements appear in the JSON format, refer to the COUNTER_SUSHI API Specification (see Section 8 below). Mandatory (M) elements MUST be included in the report. The Parent elements MUST only be included in the COUNTER Report if called for (C) via Include_Parent_Details. For report providers who elect to offer component usage information, the Component elements MUST only be included in the COUNTER Report if called for (C) via Include_Component_Details. If they are included, then the corresponding Include_Parent_Details=True or Include_Component_Details=True MUST be included in the Report_Attributes header. The other elements also MUST only be included if called for (C), and if included they MUST be listed in Attributes_To_Show in the Report_Attributes header.

Table 4.p (below): Column Headings/Elements for Item Report and Standard Views of the Item Report

Element Name (Tabular)	IR	IR_A1	IR_M1
Item	M	M	M
Publisher	M	M	M
Publisher_ID	M	M	M
Platform	M	M	M
Authors	C	M
Publication_Date	C	M
Article_Version	C	M
DOI	M	M	M
Proprietary_ID	M	M	M
ISBN	M
Print_ISSN	M	M
Online_ISSN	M	M
URI	M	M	M
Parent_Title	C	M
Parent_Authors	C	M
Parent_Publication_Date	C
Parent_Article_Version	C	M
Parent_Data_Type	C
Parent_DOI	C	M
Parent_Proprietary_ID	C	M
Parent_ISBN	C
Parent_Print_ISSN	C	M
Parent_Online_ISSN	C	M
Parent_URI	C	M
Component_Title	C
Component_Authors	C
Component_Publication_Date	C
Component_Data_Type	C
Component_DOI	C
Component_Proprietary_ID	C
Component_ISBN	C
Component_Print_ISSN	C
Component_Online_ISSN	C
Component_URI	C
Data_Type	M		M
YOP	C
Access_Type	C	M
Access_Method	C
Metric_Type	M	M	M
Reporting_Period_Total	M	M	M
Mmm-yyyy	M*	M	M

*unless Exclude_Monthly_Details=True is used

Filters and Attributes

The following table presents the values that can be chosen for the Item Report and that are pre-set for the Standard Views of the Item Report. If a filter is not included in the request, the default applies. For the Standard Views of the Item Report an empty cell indicates that the filter is not applied.

Table 4.q (below): Filters/Attributes for Item Report and Standard Views of the Item Report

Filter/Attribute	Filters available (options for Item Report and required for Standard Views of the Item Report)
	IR	IR_A1	IR_M1
Data_Type	One or more or all (default) of the Data_Types applicable to the platform.	Article	Audiovisual Image Interactive_Resource Multimedia Sound
YOP	All years (default), a specific year in the format yyyy, or a range of years in the format yyyy-yyyy. Use 0001 for unknown or 9999 for articles in press. Note that the COUNTER_SUSHI API allows the specification of multiple years and ranges separated by the vertical pipe (“|”) character.
Access_Type	One or more or all (default) of: - Controlled - Open - Free_To_Read
Access_Method	One or all (default) of: - Regular - TDM	Regular	Regular
Metric_Type	One or more or all (default) of: - Total_Item_Investigations - Total_Item_Requests - Unique_Item_Investigations - Unique_Item_Requests - Limit_Exceeded - No_License	Total_Item_Requests Unique_Item_Requests	Total_Item_Requests Unique_Item_Requests
Include_Parent_Details	False (default) or True
Include_Component_Details	False (default) or True
Exclude_Monthly_Details	False (default) or True

If a filter is applied to a column that doesn’t show on the report, usage for all selected attribute values is summed and the totals are presented in the report.

Delivery of COUNTER Reports

Report providers MUST make COUNTER Reports and Standard Views of the COUNTER Reports available in JSON format via the COUNTER_SUSHI API. Report providers MUST also make tabular versions of their reports available from an administrative/reporting site accessible by members of the institution requesting the report.

• Reports MUST be provided monthly.

• Data MUST be updated within 4 weeks of the end of the reporting period.

• Usage MUST be processed for the entire month before any usage for that month can be included in reports. If usage for a given month is not available yet, the report provider MUST NOT return usage for that month and MUST include exception 3031 in the report/response to indicate that usage is not ready for requested dates.

• A minimum of the current year plus the prior 24 months of usage data MUST be available, unless the report provider is newly COUNTER compliant.

• When report providers become compliant with a new release of the Code of Practice, they begin compiling usage compliant with the new release from the time they become compliant; and they MUST continue to provide the older usage that complies with the previous release(s) of the Code of Practice to fulfil the requirement.

• The reports MUST allow the report consumer the flexibility to specify a date range, in terms of months, within the most recent 24-month period.

• Report providers should provide reports on a per-customer basis where it is possible to do so accurately. That is, if a business school has a separate customer ID from its parent university and it is possible to separately identify usage from each customer ID (e.g. there are different IP ranges for the university and the business school), the school and the university should be sent separate COUNTER reports.

Delivering JSON Reports

• JSON reports MUST be formatted in accordance with the COUNTER_SUSHI API Specification (see Section 8).

• The reports MUST be encoded using UTF-8. JSON reports and other SUSHI server responses MUST NOT include a byte order mark (according to RFC 8259, Section 8.1).

• JSON Reports MUST be “minimal”, i.e. information that can be included in a single objects MUST NOT be split into multiple objects:

  • all Items with the same Parent MUST be included in a single Parent_Item object (Item Reports only, avoids duplicate Parent metadata)

  • all Attribute_Performance objects for the same Item/Title/Database/Platform MUST be included in a single Report_Item object (avoids duplicate item metadata)

  • all Performance for the same Attribute combination MUST be included in a single Attribute_Performance object (avoids duplicate Attribute combinations)

• The reports SHOULD not include unnecessary whitespace.

• SUSHI servers SHOULD use HTTP Compression if the client supports it.

• JSON Reports MUST be available for harvesting via the COUNTER_SUSHI API within 4 weeks of the end of the reporting period.

Delivering Tabular Reports

• Tabular reports MUST be encoded using UTF-8. Tabular reports in text formats SHOULD include a byte order mark, so that spreadsheet programs can automatically detect the encoding.

• Tabular reports MUST be provided either as an Excel or a tab-separated-value (TSV) file, or both. Additional file formats that can be easily imported into spreadsheet programs without loss or corruption may be offered at the vendor’s discretion.

• Each report MUST be delivered as a separate file to facilitate automated processing of usage reports into ERM and usage consolidation systems. For clarity, multiple reports MUST NOT be included in the same Excel file as separate worksheets.

• Tabular reports MUST be made available through a website.

  • The website may be password-controlled.

  • Email alerts may be sent when data is updated.

  • The report interface MUST provide filter and configuration options for the COUNTER Reports that apply to the report provider.

  • The report interface MUST offer all Standard Views of the COUNTER Reports the report provider is required to provide, and Standard Views options MUST automatically apply the REQUIRED filter and configuration options and not allow the report consumer to alter the filters or configuration options except for the usage begin and end dates.

  • The date range fields on the user interface MUST default to the latest month with complete usage. For example, if the current date is 15 May 2024 and April usage has been processed, the begin date would default to 01 April 2024 and the end date would default to 30 April 2024. If the April usage has not yet been processed, the start and end dates would default to 01 March 2024 and 31 March 2024.

  • COUNTER Reports MUST include the option to Exclude_Monthly_Details.

  • Item Reports MUST include the option to Include_Parent_Details. If reporting on Components is supported, Item Reports MUST include the option to Include_Component_Details (see Section 3.3.7 for details).

Access to Usage for Consortia

Separate consortium reports are not provided under R5.1. Consortium managers must be able to access any R5.1 report for their members. To facilitate this:

• The consortium administrator MUST be able to access the usage statistics for individual consortium member institutions, from a single login, using the same user id and password (i.e. without having to logout and back in for each individual institution).

• COUNTER_SUSHI API implementations MUST support the /r51/members path (see Section 10.3 below) to facilitate consortium managers retrieving usage for all members.

Logging Usage

Usage data can be generated in a number of ways, and COUNTER does not prescribe which approach should be taken. The two most common approaches are:

• Log file analysis, which reads the log files containing the web server records of all its transactions

• Page tagging, which uses JavaScript on each page to notify a third-party server when a page is rendered by a web browser.

Each of these approaches has advantages and disadvantages, summarised below.

Log File Analysis

Log files are text files representing individual HTTP requests, including the user host name or IP address, the date and time of the request, the requested file name, the HTTP response status and size, the referring URL and the browser information. HTTP requests are what happen when a user tries to access a web page, while an HTTP response is the delivery of that page to the user’s browser.

Most web servers produce log files by default in a pre-defined format which may differ by server type. The log file data needed for a COUNTER implementation should be available without changes to the platform.

As log file data is held on servers in a standard format, report providers can use a variety of analytics programmes and receive consistent results over time. Log files are also independent of users’ web browsers, meaning report providers can reliably track all activity for the purposes of COUNTER reporting.

Report providers wishing to learn more about log files should read the Amazon Web Service documentation.

Other things to note in respect of log file analysis are:

• Log files contain information on visits from spiders and robots. Although these MUST NOT be reported as part of user activity, it is useful information for search engine optimization.

• Log files require no additional DNS lookups. Thus, there are no external server calls which can slow page load speeds or result in uncounted page views.

• Cached pages are not requested from the server and therefore do not appear in log file analysis, although cached pages can account for a sizeable proportion of usage.

Page Tagging

With the increasing use of cloud services, page tagging is becoming a preferred way to obtain analytics information. Page tagging and tag data analysis can be done in-house, but are also widely available as third-party services

Page tags are small pieces of code embedded in each page of a platform website. Data is gathered via these tags and passed to a database. This data can then be manipulated and stored, allowing complete control over how the data is represented.

A key difference between log file analysis and page tagging is that with page tags a usage count is activated by opening the page in the browser, not by requesting it from the server. This means page tagging is likely to offer a more accurate reflection of usage, because cached pages are counted in the same way as server calls. However, many browsers block some page tagging services so as with log file analysis some usage will not be recorded.

Other things to note in respect of page tagging are:

• The data storage and manipulation script may have access to additional information about the web client or the user; for example, by reading information from the report providers’ access management system.

• Page-tagging services typically manage the process of assigning cookies to visitors.

Distributed Usage Logging

Distributed Usage Logging (DUL) was an initiative sponsored by Crossref that provides a framework for publishers to capture usage of DOI-identified content items that occurs on other websites, such as aggregators, repositories, and scholarly information-sharing sites. The premise behind DUL was that publishers could register a DUL usage logging end-point with Crossref, which was then mapped to all of the publisher’s DOIs. A content site, such as a repository, could use a content item’s DOI to look up where the publisher wants a transaction to be logged, then use the standard DUL message structure to log the activity. Using DUL could allow a publisher to capture a more complete picture of content usage.

The Crossref project has terminated but this process could be used by content providers to capture usage activity related to their content that happens on sites other than their own. The following points cover how DUL could be used to facilitate that process:

• DUL is not a replacement for log file analysis or page-tagging approaches. DUL can supplement a publisher’s normal usage logging mechanisms, but not replace them.

• DUL-captured usage MUST NOT appear on Standard Views.

• DUL-captured usage may appear on COUNTER Reports.

• DUL-captured usage that appears on COUNTER Reports MUST be reported under the platform name where the transaction occurred.

• The platform name MUST include the namespace DUL (i.e. MUST be in the format of DUL:{platform name}), so that DUL-captured usage can be identified and excluded when creating a Standard View from a COUNTER Report.

• An organization that supplies usage transactions using DUL MUST include their platform ID with each transaction, and their platform MUST be registered with COUNTER.

• Reporting usage through DUL is OPTIONAL.

• The publisher receiving transactions through DUL is responsible for performing COUNTER processing to eliminate double-clicks, eliminate robot/crawler or other rogue usage, and perform the actions to identify unique items and unique titles.

• Publishers that plan to include usage reported through DUL in their COUNTER Reports are responsible for ensuring that DUL-reported usage is included in the audit.

Processing Rules for Underlying COUNTER Reporting Data

Usage data collected by report providers for the usage reports to be sent to customers should meet the basic requirement that only intended usage is recorded and that all requests that are not intended by the user are removed.

Because the way usage records are generated can differ across platforms, it is impractical to describe all the possible filters and techniques used to clean up the data. This Code of Practice, therefore, specifies only the requirements to be met by the data to be used for building the usage reports.

HTTP Status Codes

Only successful and valid requests MUST be counted. For web server log files successful requests are those with specific HTTP status codes (200 and 304). The standards for HTTP status codes are defined and maintained by the IETF HTTP working group in a series of RFCs (most notably RFC 9110). If key events are used, their definition MUST match the HTTP standards.

Double-Click Filtering

The intent of double-click filtering is to remove the potential of over-counting which could occur when a user clicks the same link multiple times, typically due to a slow internet connection. Double-click filtering applies to Total_Item_Investigations, Total_Item_Requests, No_License and Limit_Exceeded.

The double-click filtering rule is as follows:

• Double-clicks, i.e. two clicks in succession, on a link by the same user within a 30-second period MUST be counted as one action. For the purposes of COUNTER, the time window for a double-click on any page is set at a maximum of 30 seconds between the first and second mouse clicks. For example, a click at 10:01:00 and a second click at 10:01:29 would be considered a double-click (one action); a click at 10:01:00 and a second click at 10:01:35 would count as two separate single clicks (two actions).

• A double-click may be triggered by a mouse-click or by pressing a refresh or back button. When two actions are made for the same URL within 30 seconds the first request MUST be removed and the second retained.

• Any additional requests for the same URL within 30 seconds (between clicks) MUST be treated identically: always remove the first and retain the second.

There are different ways to track whether two requests for the same URL are from the same user and session. These options are listed in order of increasing reliability, with Option 4 being the most reliable.

1. If the user is authenticated only through an IP address, that IP address combined with the browser’s user-agent (logged in the HTTP header) MUST be used to trace double-clicks. Where you have multiple users on a single IP address with the same browser user-agent, this can occasionally lead to separate clicks from different users being logged as a double-click from one user. This will only happen if the multiple users are clicking on exactly the same content within a few seconds of each other.

2. When a session cookie is implemented and logged, the session cookie MUST be used to trace double-clicks.

3. When a user cookie is available and logged, the user cookie MUST be used to trace double-clicks.

4. When an individual has logged in with their own profile, their username MUST be used to trace double-clicks.

Counting Unique Items

Some COUNTER Metric_Types count the number of unique items that had a certain activity, such as a Unique_Item_Requests or Unique_Item_Investigations.

For the purpose of COUNTER metrics, an item is the typical unit of content being accessed by users, such as articles, book chapters, book segments, whole books (if delivered as a single file), and multimedia content. The item MUST be identified using the unique ID which identifies the work (e.g. chapter or article) regardless of format (e.g. PDF, HTML, or EPUB). If no item-level identifier is available, then use the item name in combination with the identifier of the parent item (i.e. the article title + ISSN of the journal, or chapter name + ISBN of the book).

The method for counting book usage in R5.1 at the item level is different than it was in R5. In R5.1, a Unique_Item_Investigation or Unique_Item_Request MUST be counted for each item (Book_Segment) that is used, independent of the method of content delivery.

• Where Book_Segments can be identified within a Book, a Unique_Item_Investigation MUST be counted for each Book_Segment with which a user interacts and a Unique_Item_Request counted for each Book_Segment accessed in full. This includes where users download or view the whole book as a single file.

• Where it is not possible to identify Book_Segments (e.g. the report provider does not have metadata identifying individual Book_Segments), the whole book MUST be counted as a single Book_Segment.

• The same rules apply to identifying and counting usage of other items within aggregated works, such as Reference_Items within Reference_Works or News_Items within Newspaper_or_Newsletters.

To illustrate: PDFs for twelve chapters are downloaded within a single book in a single session. In R5.1 this must be reported as 12 Unique_Item_Requests and 1 Unique_Title_Request, where in R5 the same usage would be reported as 1 Unique_Item_Request and 1 Unique_Title_Request. This change has been introduced to allow more consistent reporting on the Book_Segment level in the Item Report and to facilitate accurate comparisons of usage across Data_Types, while retaining the ability to accurately compare book usage across platforms through the unique title metrics.

The rules for calculating the unique item counts are as follows:

If multiple transactions qualifying for the Metric_Type in question represent the same item and occur in the same user-sessions, only one unique activity MUST be counted for that item.

A user session is defined any of the following ways: by a logged session ID + transaction date, by a logged user ID (if users log in with personal accounts) + transaction date + hour of day (day is divided into 24 one-hour slices), by a logged user cookie + transaction date + hour of day, or by a combination of IP address + user agent + transaction date + hour of day.

To allow for simplicity in calculating session IDs, when a session ID is not explicitly tracked, the day will be divided into 24 one-hour slices and a surrogate session ID will be generated by combining the transaction date + hour time slice + one of the following: user ID, cookie ID, or IP address + user agent. For example, consider the following transaction:

• Transaction date/time: 2024-06-15 13:35

• IP address: 192.1.1.168

• User agent: Mozilla/5.0

• Generated session ID: 192.1.1.168|Mozilla/5.0|2024-06-15|13

The above replacement for a session ID does not provide an exact analogy to a session. However, statistical studies show that the result of using such a surrogate for a session ID results in unique counts are within 1-2 % of unique counts generated with actual sessions.

Counting Unique Titles

Two COUNTER Metric_Types count the number of unique titles that had a certain activity: Unique_Title_Requests and Unique_Title_Investigations. These metrics apply only to books, including Data_Types Book and Reference_Work.

For the purpose of COUNTER metrics, a title represents the parent work (book) that a specific content item is part of. The title MUST be identified using a unique identifier (e.g. an ISBN for a book) regardless of format (e.g. PDF, HTML or EPUB).

While the method for counting book usage in R5.1 at the item level is different than it was in R5, the method for counting title-level usage is unchanged. That means Unique_Title_Requests and Unique_Title_Investigations are comparable across report providers and across releases.

The rules for calculating the unique title counts are as follows:

If multiple transactions qualifying for the Metric_Type in question represent the same title and occur in the same user-session only one unique activity MUST be counted for that title.

A user session is defined any of the following ways: by a logged session ID + transaction date, by a logged user ID (if users log in with personal accounts) + transaction date + hour of day (day is divided into 24 one-hour slices), by a logged user cookie + transaction date + hour of day, or by a combination of IP address + user agent + transaction date + hour of day.

To allow for simplicity in calculating session IDs, when a session ID is not explicitly tracked, the day will be divided into 24 one-hour slices and a surrogate session ID will be generated by combining the transaction date + hour time slice + one of the following: user ID, cookie ID, or IP address + user agent. For example, consider the following transaction:

• Transaction date/time: 2024-06-15 13:35

• IP address: 192.1.1.168

• User agent: Mozilla/5.0

• Generated session ID: 192.1.1.168|Mozilla/5.0|2024-06-15|13

The above replacement for a session ID does not provide an exact analogy to a session. However, statistical studies show that the result of using such a surrogate for a session ID results in unique counts are within 1-2 % of unique counts generated with actual sessions.

Attributing Usage when Item Appears in More Than One Database

Content providers that offer databases where a given content item (e.g. an article) is included in multiple databases MUST attribute the Investigations and Requests metrics to just one database. The following recommendations may be helpful when choosing when ambiguity arises:

• Give priority to databases that the institution has rights to access.

• If there is a priority order for databases for search or display within the platform, credit usage to the highest priority database.

• Beyond that, use a consistent method of prioritizing database, such as by database ID or name.

• If none of the above, pick randomly.

Searches

A search is counted any time the platform executes a search to retrieve a new set of results. This means that platforms performing multiple searches (e.g. search for exact match, search for words in subject, general search) to return a single set of results ordered by relevancy must only count a single search, not multiple searches.

Design options and activities that do count as separate searches include:

• Platforms where multiple searches are conducted to retrieve and present multiple result sets, for example to deliver multi-tab search result interfaces.

• Platforms where applying a facet or filter requires the search to be re-run.

• Where browsing triggers a search, for example where clicking on a topic from browse lists conducts a search to present a set of topic-specific search results.

Note that link resolution MUST NOT count as a search.

Discovery Services and Other Multiple-Database Searches

Search activity generated by discovery services and other systems where multiple databases are searched simultaneously and the user does not have the option of selecting the databases being searched MUST be counted as Searches_Automated on Database Reports. Such searches MUST be included on the Platform Reports as Searches_Platform, but only as a single search regardless of the number of databases searched.

Example: A user searches a content site where 20 databases have been pre-selected for business and economics searches and the user does not have the option to change the selection. For each search conducted by the user:

• In the Database Report, each of the 20 databases gets credit for 1 Searches_Automated.

• In the Platform Report, Searches_Platform gets credited by 1.

Federated Searches

The growing use of federated searches and the spread of web crawler robots has the potential to inflate usage statistics, so COUNTER requires report providers to identify this type of usage in COUNTER Reports.

Search activity generated by federated search engines MUST be categorized separately from searches conducted by users on the host platform.

Any searches generated from a federated search system MUST be included in the separate Searches_Federated counts within Database Reports and MUST NOT be included in the Searches_Regular or Searches_Automated counts.

The most common ways to recognize federated and automated search activity are as follows:

• A federated search engine may be using its own dedicated IP address, which can be identified and used to separate out the activity.

• If the standard HTML interface is being used (e.g. for screen scraping), the browser ID within the web log files can be used to identify the activity as coming from a federated search.

• All searches via APIs and Z39.50 activity must be counted as Searches_Federated, as the results are not presented in the platform user interface.

• If an API gateway is available, set up an instance of the gateway that is for the exclusive use of federated search tools. It is recommended you also require the federated search engine to include an identifying parameter when making requests to the gateway.

• For Z39.50 activity, authentication is usually through a username/password combination. Create a unique username/password that just the federated search engine will use.

Where federated or automated usage is genuine user-driven usage, in the context of Text & Data Mining, Access_Method=TDM should be used. This allows users of the resultant reports to distinguish automated usage from more traditional (Access_Method=Regular) usage.

COUNTER has lists of federated search tools in Appendix F, separate from a list of robots which is reviewed and updated on a regular basis and which can be found at COUNTER Robots.

Internet Robots and Crawlers

Activity generated by internet robots and crawlers MUST be excluded from all COUNTER usage reports. COUNTER provides a list of user agent values that represent the crawlers and robots that MUST be excluded. Any transaction with a user agent matching one on the list MUST NOT be included in COUNTER reports.

COUNTER maintains the current list of internet robots and crawlers at COUNTER Robots.

Tools and Features that Enable Bulk Downloading

Only genuine, user-driven usage MUST be reported. COUNTER reports MUST NOT include usage that represents requests of full-text content when it is initiated by automatic or semi-automatic bulk download tools where the downloads occur without direct user action.

• Products like RightFind or PubHive MUST only be recorded only when the user has clicked on the downloaded full-text article in order to open it.

• Full text retrieved by automated processes such as reference manager software or robots (see Section 7.8 above) MUST be excluded.

• Usage that occurs through emailing of a list of articles or citations that was not as a result of a user explicitly selecting the items for sharing MUST NOT be counted. Note that the act of a user explicitly sharing a single item would be considered an Investigation.

Text and Data Mining

Text and data mining (TDM) is a computational process whereby text or datasets are crawled by software that recognizes entities, relationships, and actions. (STM Statement on Text and Data Mining)

TDM does NOT include straightforward information retrieval, straightforward information extraction, abstracting and summarizing activity, automated translation, or summarizing query-response systems.

A key feature of TDM is the discovery of unknown associations based on categories that will be revealed as a result of computational and linguistic analytical tools.

Principles for reporting usage:

• COUNTER metrics do not record TDM itself, as most of this activity takes place after an article has been downloaded. Instead, metrics represent the count of articles downloaded for the purposes of mining.

• Usage associated with TDM activity (e.g. articles downloaded for the purpose of TDM) MUST be tracked by assigning an Access_Method of TDM.

• Usage associated with TDM activity MUST be reported using the Title, Database, and Platform Reports by identifying such usage as Access_Method=TDM.

• Usage associated with TDM activity MUST NOT be reported in Standard Views of the COUNTER Reports (TR_J1, TR_B1, etc.).

Detecting activity related to TDM:

TDM activity typically requires a prior agreement between the report provider and the individual or organization downloading the content for the purpose of text mining. The report provider can isolate TDM-related traffic using techniques like:

• Providing a dedicated end-point that is specifically for TDM data harvesting.

• Requiring the use of a special account or profile for TDM data harvesting.

• Assigning an API key that would be used for the harvesting.

• Registering the IP address of the machine harvesting content.

Harvesting of content for TDM without permission or without using the endpoint or protocol supplied by the report provider MUST be treated as robot or crawler traffic and MUST be excluded from all COUNTER reports.

Restating Data

Retrospective Reporting of Errors

If errors are identified in COUNTER reports, the report provider MUST correct the errors within three months of their discovery. The report provider MUST alert the Project Director (tasha.mellins-cohen@counterusage.org) so that a notification may be included in the COUNTER Registry. Report providers SHOULD also directly inform their customers of the corrections.

Reporting Usage When Journal Titles Change

When the title of a journal is changed but the identification code (ISSN or DOI) stays the same, report providers should consider the journal to be a single title for the purposes of COUNTER reporting. COUNTER Reports and Standard Views of the COUNTER Reports SHOULD be provided against the new title, with the original title being dropped from the reports.

If a new DOI or ISSN is allocated to the journal when the title changes, Report providers should consider the journal to be two titles and provide usage information separately. Report providers MUST NOT report usage for the same period under both the old and new DOI or ISSN. Any report generated for the old DOI or ISSN SHOULD show zero usage from the month in which the new DOI or ISSN takes effect.

Abnormal Spikes in Usage

What is regarded as an abnormal spike in usage can vary from one report provider and report consumer to another and there are many occasions on which exceptionally high usage in a month is genuine, so COUNTER does not have a strict protocol for dealing with usage spikes. The following approaches will provide an indication of possible abnormal usage or another unusual event. These should only be as a prompt for human intervention to take a closer look at the numbers, rather than any automated cut-off of access.

Positive Spikes in Usage

Reported usage may be considered as a positive spike if, in a specific month, the reported usage by a report consumer is at least one hundred units of measurement greater than thrice the previous twelve-month average.

Negative Spikes in Usage

Reported usage may be considered as a negative spike if, in a specific month, the reported usage by a report consumer is less than 1% of the previous twelve-month average, where the average usage of that product in the previous 12 months is at least twenty units of measurement.

SUSHI for Automated Report Harvesting

The COUNTER_SUSHI API is designed to simplify the gathering of usage statistics by report consumers, and report providers MUST support automatic harvesting of COUNTER reports via the COUNTER_SUSHI API. Starting with R5.1, the specification for the RESTful COUNTER_SUSHI API uses JSON schema for the JSON format, and OpenAPI 3.1 for the API. The COUNTER_SUSHI API Specification is now maintained by COUNTER on Stoplight.io:

https://countermetrics.stoplight.io/docs/counter-sushi-api

The COUNTER_SUSHI API Specification is contained in a single OpenAPI 3.1/JSON schema file (COUNTER_SUSHI_API.json) which is used by Stoplight.io for presenting the information about the API paths and the JSON responses. It is expected that report providers will use only the parts relevant to them, or export the file and make local tailored copies relevant to their particular circumstances, for example by removing API paths and models detailing reports they do not support. Note that it is also possible to export the JSON schemas for the JSON reports and other API responses and use them with a JSON schema validator.

The COUNTER_SUSHI API Specification for R5.1 is more detailed and precise than the specification for R5, but it is not self-contained, since it is not possible to express all rules in the COUNTER Code of Practice in JSON schema. So the rules in the Code of Practice still apply, and in the case of any conflicts with the COUNTER_SUSHI API Specification the Code of Practice takes precedence.

COUNTER_SUSHI API Paths to Support

Starting with Release 5.1, the COUNTER_SUSHI API paths include the Release in the format /r{Release without .}, so that the COUNTER_SUSHI API is properly versioned.

Report providers SHOULD use the same COUNTER_SUSHI API base URL for all releases. For example, if the URL for requesting the list of reports is https://example.org/sushi/reports in R5, it should be https://example.org/sushi/r51/reports in R5.1, so that the base URL for both releases is https://example.org/sushi.

The following paths (methods) MUST be supported:

HTTP Method	Path	Description
GET	/r51/status	Returns the current status of the COUNTER_SUSHI API service. This path returns a message that includes the operating status of the API, the URL to the service’s entry in the COUNTER Registry, and an array of service alerts (if any). This path MUST be public, i.e. not protected by the methods described in Section 8.2, to allow report consumers to easily check whether a SUSHI server is live.
GET	/r51/reports	Returns a list of reports supported by the COUNTER_SUSHI API service. The response includes an array of reports, including the report identifier, the release number, the report name, a description, the path to use when requesting the report (optional but recommended for custom reports), and the first and last months for which usage data has been processed and is available. This information SHOULD be specific for each customer ID.
GET	/r51/reports/{Report_ID in lower case}	Each supported report has its own path, e.g. GET /r51/reports/tr_b1 for “Book Requests (Controlled)”, GET /r51/reports/tr_j1 for “Journal Requests (Controlled)”. The paths for the COUNTER Reports offer parameters that allow report consumers to customize the reports by applying report filters and report attributes (see Section 3.3.7), including filters for some common extensions (see Section 11.5). Support for common extensions is optional. Report providers that support one of the extensions also SHOULD support the corresponding parameter. If filtering by an extension is not supported, report providers MUST handle this as described for Exception 3060 in Appendix D.
GET	/r51/members	Returns the institutions associated with the customer ID in the request and their customer IDs and requestor IDs. The associated institutions can be consortium members, or sites for multi-site customers. If the customer in the request is neither a consortium nor multi-site, the response only includes the details for the customer itself. The response is an array of customer account information, including for each the customer ID (for requesting COUNTER reports and making other API calls), the requestor ID (if required for API calls and differing from the requestor ID in the request), the institution name, and additional identifiers for the institution (if any).

Authentication and Security for the COUNTER_SUSHI API

The COUNTER_SUSHI API MUST be implemented using TLS (HTTPS).

The COUNTER_SUSHI API - excluding the public path /r51/status (see Section 8.1) - MUST be secured using one or more of the following methods:

• Combination of customer ID and requestor ID

• API key assigned to the organization harvesting the usage

All API paths (excluding the public /r51/status path) MUST be secured with the same method(s). Non-standard techniques (not specified in the Code of Practice and the COUNTER_SUSHI API specification) MUST NOT be used. This includes authorization based on IP addresses.

Report providers who would like to improve the security of their SUSHI server should consider using API keys with secure values (e.g. randomly generated UUIDs). Report providers who already use requestor IDs and/or customer IDs with secure values should consider that adding an API key would require all report consumers to update their SUSHI credentials.

If global reports are available, the customer ID 0000000000000000 should be used for “The World”. The report should be available to any valid requestor ID and/or API key.

Report Filters and Report Attributes

The COUNTER_SUSHI API specification allows report responses to be customized to the caller’s needs using report filters and report attributes. For Standard Views of the COUNTER Reports, these filters and attributes are implicit. For the COUNTER Reports, the filters and attributes will be explicitly included as parameters on the COUNTER_SUSHI request.

Refer to Section 3.3.7 and the COUNTER_SUSHI API Specification for the list of filters and attributes supported by the various COUNTER reports.

Errors and Exceptions

Implementations of the COUNTER_SUSHI API MUST comply with the warnings, exceptions and errors described in Appendix D.

Audit

R5.1 of the COUNTER Code of Practice, published in April 2023, will become the only valid version of the Code of Practice from 1 January 2025.

An important feature of the COUNTER Code of Practice is that compliant report providers (including third-party services providing stats on behalf of publishers) MUST be independently audited on an annual basis to maintain their COUNTER-compliant status. To facilitate this, a set of auditing standards and procedures has been published in Appendix E of this Code of Practice. COUNTER has tried to meet the need of report consumers for credible usage statistics without placing an undue administrative or financial burden on report providers. For this reason, audits will be conducted online in accordance with the program included in the auditing standards and procedures (Appendix E).

COUNTER will recognize an audit carried out by any Certified Public Accountant (CPA) in the USA, by any Chartered Accountant (CA) in the UK, or by their equivalent in other countries. Alternatively, the audit may be done by a COUNTER-approved auditor which is not a CA or a CPA. Contact COUNTER for a list of approved auditors.

The Audit Process

Audit Scope

Audits are primarily focused on the four COUNTER Reports. The Standard Views of the COUNTER Reports will pass the audit provided the metrics match those in the COUNTER Reports, with the appropriate aggregation.

Each report provider MUST be audited on all the COUNTER Reports and Standard Views of the COUNTER Reports they are required to provide. Report providers who elect to offer additional COUNTER Reports (e.g. eJournal Host_Types that offer Item Reports) SHOULD have the additional COUNTER Reports and Standard Views of the COUNTER Reports audited. If the elective reports are not audited, this must be documented in the audit report.

Any exclusions to the audit scope MUST be agreed with the Project Director in writing prior to an audit commencing (tasha.mellins-cohen@counterusage.org).

Audit Scope For Third-Party Report Providers

Some publishers work with third parties to provide COUNTER reports. In these cases it is the third party report provider that is audited. Where such third parties are supporting multiple platforms, they must provide the auditor with a list of all platforms and the related COUNTER Reports and Standard Views. The auditor will then select a minimum of two and a maximum of five platforms from the list and audit accordingly, with the list to be approved by the COUNTER Project Director before the audit begins.

Where different technologies are used to generate reports for different platforms (e.g. data is harvested differently from one platform to the next), each technology MUST be audited separately.

Stages of the Audit Process

Audits follow a five-stage process.

• Stage one - pre-flight preparation. Report providers SHOULD run all of their COUNTER reports (JSON and tabular) through the COUNTER Validation Tool. Report providers SHOULD also seek feedback from large report consumers (e.g. JUSP) in respect of issues they have identified with the reports. Report providers SHOULD fix any problems that are discovered and re-run the Validation Tool before proceeding to Stage two.

• Stage two - audit initiation. Auditor and report provider agree on the scope of the audit, which MUST include all COUNTER Reports and Standard Views of COUNTER Reports required by the Code of Practice but SHOULD include all COUNTER Reports and Standard Views of COUNTER Reports offered by the report provider. COUNTER’s Project Director will adjudicate if the auditor and report provider cannot agree on the audit scope. Report providers MUST provide pre-flight documentation to the auditor, using the template provided in Appendix E. If Stage one has been followed, report providers MUST provide the Validation Tool results to the auditor.

• Stage three - seeding, audit begins. In this stage the auditors perform actions on the audited platforms in line with Appendix E. Seeding takes a full calendar month.

• Stage four - report reconciliation. The auditors reconcile the COUNTER reports generated by the report provider with the seeding actions they undertook in Stage three. The outputs from this stage may be an Interim Report or a Pass Report, which MUST be shared with the COUNTER Project Director. If an Interim Report is issued,

  • The report provider MUST fix the issues identified by the auditor within three months of the date of the interim report

  • The auditor will re-reconcile the COUNTER reports

• Stage five - audit complete. Once a Pass Report is issued, COUNTER will update the Registry of COUNTER compliant platforms to reflect the updated audit status of all platforms covered by the audit (COUNTER Registry).

Note that if it is not possible to re-reconcile the COUNTER reports after a report provider has completed their fix process, the auditor will need to re-seed the audit. The Project Director SHOULD be notified when this occurs.

Categories of Audit Result

There are four categories of audit result, as follows:

• Pass - No further action is required by the report provider as a result of the audit. In some cases, the auditor may add observations to the audit report, which are intended to help the report provider improve its COUNTER usage reports but are not required for compliance.

• Qualified Pass - The report provider has passed the audit, but the auditor raises a minor issue requiring further action to maintain COUNTER-compliant status. A minor issue does not affect the reported figures but MUST be resolved within three months of the audit to maintain COUNTER-compliant status. Where a Qualified Pass is reported, the reason for the qualification will be included in the COUNTER Registry.

• Interim Report - The auditor has identified an issue that MUST be resolved within three months for the report provider to maintain COUNTER-compliant status.

• Fail - The report provider has not resolved the issues identified in the Interim Report. The report provider MUST start a fresh audit (i.e. a new seeding process) within three months of the Fail report being issued.

Audit Timelines

An audit is valid for twelve months from the date of seeding: that is, an audit seeded in April 2025 will be valid until the end of March 2026.

The audit process can be lengthy and report providers should take this into consideration when planning for audits. A typical timeline is shown in Table 9.a below.

Table 9.a (below): Audit Timelines

Process	Usual Duration	Example
Seeding	1 calendar month	February
Usage processed, reports available	Up to 28 days from end of seeding month	March
Report reconciliation	4 to 6 weeks	April
Fixes after interim report	Up to 3 months	May to July
Report reconciliation after fixes	1 month	August

Extensions

Report providers may request extensions to the usual timelines under the following circumstances.

• Delayed seeding - where a report provider is able to demonstrate that they have run the COUNTER Validation Tool and are in the process of fixing problems identified by the tool before commencing an audit, they may apply for up to three months delay in the seeding process.

• Extension to the fix period - where an Interim Report has identified significant problems with COUNTER reports, the report provider may apply for an extension of the fix period from three to up to six months.

Applications for extensions MUST be sent to both the Project Director (tasha.mellins-cohen@counterusage.org) and the auditor, and will be considered on a case-by-case basis. Only one extension of each type will be granted for any audit, and all extensions will be tracked in the Registry.

Alternate year audits

Some report providers are eligible to be audited once every 24 months. Specifically, report providers delivering COUNTER reports for a single platform, where that platform includes up to 150 books OR 15 journals OR one database, may apply to the Project Director for alternate year audit status.

Report providers with historic permission to be audited in alternate years for Release 5 of the Code of Pratice will also be considered for alternate year audit for R5.1, but they MUST reapply to the Project Director for confirmation.

COUNTER Validation Tool

The COUNTER Validation Tool allows report providers and auditors to quickly perform compliance checks related to format and consistency of both JSON and tabular reports. Report providers SHOULD use this free tool to check their reports and COUNTER_SUSHI API implementation and fix issues detected by the tool before they begin the audit. It is recommended to use the tool not just when preparing for the audit, but to integrate the testing in the regular QA processes or at least test regularly to make sure the reports stay compliant. We recommend testing reports using the Validation Tool once every four months at a minimum, and monthly where possible.

The COUNTER Validation Tool uses the following error levels to report issues with different severity:

• Fatal error - Validation was aborted because an unrecoverable error was encountered, for example a missing or invalid Reporting_Period. The fatal error MUST be fixed before the report can be fully validated.

• Critical error - Validation has detected a serious error that MUST be fixed, for example inconsistent data like a title with more Unique_Item_Requests than Total_Item_Requests or missing data. A critical error indicates that there could be a serious issue that would cause the audit to fail.

• Error - Validation has detected an error that MUST be fixed to pass the audit.

• Warning - Validation has detected an issue that needs to be checked by the auditor and might affect the result of the audit.

• Notice - Additional information, for example about deprecations or amendments that must be addressed at some point in the future but currently will not affect the result of an audit.

Application for inclusion in the COUNTER Registry

The Registry of report providers and their platforms for which COUNTER-compliant usage reports are available is maintained by COUNTER and publicly available at Registry.

Report providers may apply to the Project Director (tasha.mellins-cohen@counterusage.org) for their products to be included on the Registry. Report providers will have to provide proof of initial compliance by including the results of COUNTER Validation Tool tests showing compliance for each reports, including testing both the upload of the tabular reports and SUSHI harvesting of the same reports. Upon receipt of the application and proof of compliance, report providers MUST allow at least one large report consumer (e.g. JUSP) to evaluate their usage reports.

When the reports are deemed to comply with the COUNTER Code of Practice, the report provider will be asked to sign a Declaration of COUNTER Compliance (Appendix C), to be sent to the Project Director, after which the report provider and its platforms will be added to the Registry. These report providers may then use the designation “COUNTER Compliance Pending”.

An audit report confirming that the usage reports and data are indeed COUNTER-compliant is REQUIRED within six months of inclusion in the Registry.

Report providers who have not applied for compliance or whose compliance has lapsed MUST NOT claim or imply COUNTER compliance on their site, in licenses, or in their marketing and do not have the rights to use the COUNTER name or logo.

Other Compliance Topics

Report providers seeking COUNTER compliant status are expected to comply with the following.

Including COUNTER in License Agreements

To encourage widespread implementation of the COUNTER Code of Practice, report consumers are urged to include the following clause(s) in their license agreements with report providers:

For Licensed Content

‘The licensor confirms to the licensee that usage statistics covering the online usage of the products covered by this license will be provided. The licensor further confirms that such usage statistics will adhere to the specifications of the COUNTER Code of Practice, including data elements collected and their definitions; data processing guidelines; usage report content, format, frequency and delivery method’.

For Open Access Content

‘The licensor confirms to the licensee that usage statistics covering the total online usage of open access materials provided by the licensor will be provided. The licensor further confirms that such usage statistics will adhere to the Global Item Report specifications of the COUNTER Code of Practice, including data elements collected and their definitions; data processing guidelines; usage report content, format, frequency and delivery method’.

Confidentiality of Usage Data

Privacy and User Confidentiality

Statistical reports or data that reveal information about individual users will not be released or sold by report providers without the permission of that individual user, the consortium, and its member institutions (ICOLC Guidelines for Statistical Measures of Usage of Web-Based Information Resources).

It is the responsibility of the report providers to be aware of and ensure that they meet security and privacy requirements, including GDPR and other standards and requirements that may be applicable.

Institutional or Consortia Confidentiality

Report providers do not have the right to release or sell statistical usage information about specific institutions or the consortium without permission, except to the consortium administrators and other member libraries, and to the original publisher and copyright holder of the content. Use of institutional or consortium data as part of an aggregate grouping of similar institutions for purposes of comparison does not require prior permission as long as specific institutions or consortia are not identifiable. When required by contractual agreements, report providers, such as aggregators, may furnish institutional use data to the original publisher. (Based on ICOLC Guidelines, as above).

COUNTER Reporting for Consortia

Consortia license content for their members, and consortia managers and administrators need access to COUNTER statistics that show how each member within a given consortium has used the licensed resources.

Types of Consortia-Level Report

There are three types of consortia-level reporting:

• Report providers MUST offer summary reports that show total usage for all members of the consortium rolled up to the consortia level, and which cannot be broken down by institution. Summary reports MUST be offered for all relevant COUNTER Reports and Standard Views of the COUNTER Reports. The totals on the summary report may differ from the sum of the totals on individual member reports for the same items if an authentication method used identifies to multiple member sites and usage it attributed to each such site (e.g. overlapping IP ranges).

• Report providers may elect to offer detailed reports that show total usage for all members of the consortium, and which can be broken down by institution. As with the summary report, the totals on the detailed report may differ from the sum of the totals on individual member reports for the same items.

• Institutional reports are the individual institutional-level reports. Consortia managers and administrators MUST be able to retrieve institutional reports.

Creating Detailed Consortia-Level Reports

COUNTER recognizes that consolidated reports can be helpful to consortia, and that some report providers may want to meet the needs of their consortium customers by providing detailed reports. This can be done using existing extensions to the Code of Practice (see Section 11.5):

• The Customer_ID used in a detailed report MUST match that used in a report to the individual institution, and the ID for the institution returned by the /r51/members COUNTER_SUSHI API path.

• If provided, the Institution_Name used in a detailed report MUST match that used in a report to the individual institution, and the name for the institution returned by the /r51/members COUNTER_SUSHI API path.

• If provided, Institution_Name MUST be the first column in the tabular report, with Customer_ID the second column. Otherwise Customer_ID should be the first column.

As they are optional, detailed reports are not subject to COUNTER audits.

Accessing Consortia-Level Reports

Consortia managers and administrators MUST be able to access usage reports through the same user interface or SUSHI server as any other report consumer.

To facilitate gathering institutional reports, report providers MUST support the /r51/members COUNTER_SUSHI API path to provide the consortium with the list of their members on the platform and the SUSHI credentials for each member. This will enable tools to be created to efficiently retrieve member usage and create separate or consolidated reporting, such as those described on the COUNTER website. Note that where an API Key is required, it must be possible to make requests to all API paths with that API key and the customer ID (and requestor ID) returned for the members.

The report provider MUST NOT place limits on the SUSHI server (such as requests per day or amount of data transferred) that would prevent a consortium from retrieving reports for all its members.

Privacy and Confidentiality

COUNTER acknowledges that some organizations treat their usage data as sensitive and private information. Report providers may include the option for consortium members to opt-out of consortium reporting. COUNTER recommends the default setting for an organization is to opt-in to consortium reporting.

Content to Report Usage On

When a COUNTER report is harvested by a consortium administrator, a report provider may choose to limit member usage to include only content acquired through the consortium. Note that when such a limitation is in place the resulting report may differ from the member-sites own version of the report. Since not all report providers can provide such limits, the consortium will be responsible for ensuring usage is filtered to the content they license for members.

When the report provider chooses to limit member usage to only content acquired through the consortium, they MUST include a message to this effect in the Notes element in their implementation of the /r51/members path in the COUNTER_SUSHI API (see Section 8 above).

Extending the Code of Practice

COUNTER recognises that some report providers may want to provide customized versions of COUNTER reports to address reporting needs specific to their platform and content. This section describes a method of extending the Code of Practice that avoids creating conflicting custom implementations between content providers.

Platform as a Namespace

Report providers wishing to create custom reports or introduce custom elements or values can do so by using their platform identifier (platform ID) as a namespace. For example, if EBSCO wanted to create a customized version of the “Journal Requests (Controlled)” Standard View for their link resolver product that includes a new Metric_Type for counting link-outs, they could do this by naming the report EBSCOhost:LR1 and creating a new Metric_Type of EBSCOhost:Total_Linkouts. Note that the platform ID is also used as a namespace for local Institution_IDs and Publisher_IDs assigned by the report provider and for Proprietary_IDs (see Section 3.2).

The platform ID MUST only contain ASCII letters (a–z, A–Z), digits (0–9), underscores (_), dots (.) and forward slashes (/), and the length MUST NOT exceed 17 characters. Note that the platform ID is used in various columns and therefore should be as short as possible, but still recognizable. The platform ID usually should be based on the name, a well-known unique abbreviation or the domain of the publisher or platform. A short standard identifier like GRID or ROR (without the https://) also could be used.

COUNTER will assign the platform ID when adding the platform to their Registry (report providers can suggest a value to be used for their platform ID). Other organizations providing COUNTER reports, such as consortia or ERM providers, may contact COUNTER to register a namespace if they wish to create extensions and customizations. COUNTER will maintain a list of approved namespaces.

Creating Custom COUNTER Reports

Custom COUNTER reports can be created as long as the general layout for COUNTER reports is followed. Custom reports MUST be given an identifier and a name in the format of {namespace}:{report ID} and {namespace}:{report name}. An example of a custom report could be:

Report_ID	Report_Name
EBSCOhost:LR1	EBSCOhost:Link-out Report 1

It is recommended to make custom reports available both from the administrative/reporting site and via the COUNTER_SUSHI API and to include them in the response for the /r51/reports path in the COUNTER_SUSHI API (see Section 8).

Creating Custom Elements/Columns Headings

Custom elements/column headings can be added to the COUNTER Reports (PR, DR, TR, IR) and custom reports. The element name MUST take the form of {namespace}:{element name}. An example of a custom elements/column heading could be:

Element Name
EBSCOhost:Total_Linkouts

Custom elements/column headings MUST only be included in COUNTER Reports if called for, and if included they MUST be listed in Attributes_To_Show in the Report_Attributes header.

Creating Custom Values for Enumerated Elements

Several elements in COUNTER reports include a controlled list of possible values. On occasion, report providers may want to introduce additional custom values that better reflect their content and platform. For COUNTER reports (PR, DR, TR, IR) and custom reports the element value lists can be extended by including additional custom values in the form of {namespace}:{element value}. An example would be a custom Metric_Type value EBSCOhost:Total_Linkouts. The following is the list of elements that can be extended in this manner:

• Data_Type

• Access_Type

• Access_Method

• Metric_Type

Custom values MUST only be included in COUNTER Reports if called for, and if included they MUST be listed in the corresponding report filters in the Report_Filters or Metric_Types header.

Reserved Elements and Values Available for Extending Reports

COUNTER recognizes that there are some common extensions that report providers might want to include in COUNTER Reports or when creating custom reports; therefore the following element names and values have been reserved for this common use:

Element Name	Description	Reports	Examples
Customer_ID	When a COUNTER Report contains usage for multiple organizations, this element can be used to break the usage down by institution. The Customer_ID MUST be included in the Institution_ID report header in a report for that institution (usually as a proprietary identifier with the platform ID as namespace), and it MUST match the Customer_ID for the institution returned by the /r51/members COUNTER_SUSHI API path. Customer_ID 0000000000000000 is reserved for delivery of global reports to “The World”. 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.	PR, DR, TR, IR	C12345
Institution_Name	When a COUNTER Report contains usage for multiple organizations, this element can be used to break the usage down by institution. The Institution_Name MUST match the Institution_Name in the report header in a report for that institution and the Name for the institution returned by the /r51/members COUNTER_SUSHI API path. If Institution_Name is included in a tabular report, it MUST be the first column.	PR, DR, TR, IR	Mt. Laurel University
Book_Segment_Count	The number of Book_Segments within a Book. Note that this extension MUST only be used where the number of Book_Segments is known, and MUST NOT be used where the number of Book_Segments is only being estimated.	TR	52
Country_Name	Name of the country according to ISO 3166-1. Note that the standard allows country names in different languages. The name is included for easier reading, for processing the reports the Country_Code should be used.	PR, DR, TR, IR	Canada
Country_Code	ISO 3166-1 alpha-2 code of the country.	PR, DR, TR, IR	CA
Subdivision_Name	Name of the country subdivision according to ISO 3166-2. Note that the standard allows country subdivision names in different languages. The name is included for easier reading, for processing the reports the Subdivision_Code should be used.	PR, DR, TR, IR	Quebec Québec
Subdivision_Code	ISO 3166-2 code of the country subdivision.	PR, DR, TR, IR	CA-QC
Attributed	Whether the report provider was able to attribute the usage to an institution or not. Valid values are Yes and No. With this extension usage of open content that could not be attributed to an institution can be reported. The extension usually would be used in a Global Platform Report, Global Database Report, Global Title Report or Global Item Report for “The World” (see Section 3.2.1) which could be broken down by geolocation with the Country and Subdivision extensions.	PR, DR, TR, IR	No

Note that by supporting the Institution_Name and Customer_ID extensions report providers can offer COUNTER Reports to consortia with usage broken down by their members. If a consortium requests a report with Institution_Name and/or Customer_ID, the usage would be broken down by institution if the extension is supported by the report provider, otherwise the usage would be summarised over all consortium members as usual.

Restrictions in Using Custom Elements and Values

Extensions MUST only be used with COUNTER Reports and custom reports, they MUST NOT be used with Standard Views of the COUNTER Reports. Note, however, that a report with extensions that is similar to a Standard View of the COUNTER Reports can be created by applying the Standard View’s filters and attributes to the corresponding COUNTER Report and adding the extensions.

Custom elements and values MUST only be included in COUNTER Reports if called for. So for reports requested via the COUNTER_SUSHI API, custom elements MUST only be included if requested via attributes_to_show, and custom values MUST only be included if requested via the corresponding report filters (e.g. metric_type or data_type). On the administrative/reporting site the custom elements and values can be preselected for COUNTER Reports, but the user MUST have the option to exclude the custom elements and values from the COUNTER Reports.

Continuous Maintenance

With R5, the COUNTER Code of Practice operates under a continuous maintenance procedure to allow incremental changes to be made to the Code of Practice without creating a completely new release. This section describes those procedures.

Instructions for Submittal of Proposed Change

Changes and updates to the COUNTER Code of Practice can be submitted by anyone. Submissions MUST be made via email and directed to the Project Director (tasha.mellins-cohen@counterusage.org). Each idea for submission MUST include:

• Submitter contact information:

  • Name

  • Email

  • Affiliation

• Description of the enhancement/adjustment (include the section and paragraph number of the current Code of Practice if applicable)

• Reason for the change (use case and/or goals to be accomplished)

• Any relevant attachments

Review of Change Requests

All submissions received will be acknowledged and forwarded to the COUNTER Technical Advisory Group in the first instance. TAG will review submissions for technical feasibility and scope of change.

Where TAG recommends that the submission be incorporated into the Code of Practice, it will be passed to the Executive Committee for consideration at their next quarterly meeting.

Resolution of Proposed Changes

Responding to Submissions

The COUNTER Executive Committee (EC) will review submissions as recommended by the Technical Advisory Group (TAG) and provide a response via the Project Director after their next regularly scheduled EC meeting. The EC will respond to every submission with one of the following, providing clarity when needed:

• Proposed change accepted without modification

• Proposed change accepted with modification

• Proposed change accepted for further study

• Proposed change rejected

If further study is needed, the EC may convene a separate working group to study the proposal and make recommendations related to the suggested comments.

Approval of Changes

Changes that are approved will enter the usual Explicit Versioning process. Fix and Feature changes do not require community consultation and will be added to the TAG worklist for upcoming releases.

Changes that are substantive in nature (e.g. those that would require changes in how reports are generated or consumed) will be incorporated into the worklist for future Breaking releases and form part of the community consultation process.

After the community consultation period, changes to the COUNTER Code of Practice MUST be voted upon by the COUNTER Executive Committee and approved by committee majority. EC Members can respond to a ballot by voting Yes, No or Abstain. For clarity, the number of affirmative votes MUST be greater than 50% of the total number of EC members minus abstentions (a non-vote is considered a “No” vote.)

Communication of Changes

COUNTER will inform the COUNTER membership about upcoming changes to the COUNTER Code of Practice through email and on the COUNTER website and through posting on listservs that discuss usage topics.

Version and Change Control

Each update to the COUNTER Code of practice will generate a new version number (i.e. the initial release of “R5” was designated as version 5.0.

Under Explicit Versioning, a four-digit numbering system in the structure Release.Breaking.Feature.Fix, “Breaking” releases including changes that are not backwards compatible take the first point place (e.g. R5.1.0.0), “Feature” releases with new features or extensions that are backwards compatible take the second point place (e.g. R5.1.1.0), and “Fix” releases with bug fixes, typographic corrections and similar small amendments take the third point place (R5.1.0.1). Note that in practice, trailing zeroes will be omitted from release numbering.

Explicit Versioning thus allows for us to change the Release number where changes are so comprehensive that Release 5 would no longer apply.

All changes included in each release will be included in the Change History section of the Code of Practice. The prior release will be archived as a PDF document and access to that release provided via the COUNTER website.

Implementation Schedule

Under Explicit Versioning, changes to the COUNTER Code of Practice fall under three headings.

Fix releases become effective immediately upon publication of the new version of the Code of Practice. Fix releases include bug fixes, typographic amendments and clarifications.

Feature releases include backward-compatible and optional changes that become effective six months from the date of publication of the new version of the Code of Practice.

COUNTER will put out Fix and/or Feature releases no more than one every six months. That is, if a Fix release went out in October 2023 no further Fix or Feature release would be issued before April 2024.

Breaking releases require report providers to make changes to their implementations of the CoP and report consumers to make changes to their analysis tools. COUNTER therefore does not intend for Breaking releases to happen frequently. From the date of compliance being required, potential Breaking releases will follow this schedule:

• Compliance required month 1 (e.g. January 2025).

• Consultation opens for next Breaking release in month 24 (e.g. February 2027).

• Breaking release goes live month 30 (e.g. September 2027).

• Compliance required with Breaking release month 48 or subsequent January (e.g. January 2030).

Report providers may elect to become compliant with Feature and Breaking releases earlier than the stated compliance date per Section 13.

All changes will be clearly marked in the change log in our GitHub repository to ensure they can be easily identified.

All other requirements of the Code of Practice will remain in effect during the implementation period for changes brought about by a new release.

Transitioning from Previous Releases or to New Reporting Services

A requirement of the COUNTER Code of Practice is that report providers offer report consumers access to the current year plus the prior 24 months of usage or from the date they first became compliant, whichever is later. This requirement must continue to be met even when a provider may be transitioning to a new release of the COUNTER Code of Practice or if they are moving to a new reporting service.

Transitioning to a New Reporting Service

When a report provider implements a new reporting service, underlying logging system, or approach, they MUST continue to meet the requirement to offer valid COUNTER reports for the current year plus the prior 24 months (or from the date they first became compliant, whichever is later). At a minimum, these reports MUST be available in tabular format with all Attributes via the new reporting service’s web interface. The reports SHOULD also be available in JSON via a SUSHI server.

Availability of Previous Reports

Report providers SHOULD offer a single report with date ranges that span the transition period. That is, if the new reporting service was deployed in August of 2024 a customer could request a report for January-December 2024 and receive a single report.

When it is not practical to support a single report with date ranges that span the transition period, the report provider SHOULD perform the transition on the first day of a month. If the new reporting service was deployed in August 2024, a customer wanting January-December 2024 usage would request January-July 2024 from the previous reporting service and August-December 2024 from the new reporting service.

Project COUNTER is aware that it is not always possible to transition on the first day of a month (e.g. where a platform is moving from one service provider to another). Where a report provider has no option but to perform the transition mid-month, such that the customer is required to run reports on both the old and new reporting services for the same month, the report provider MUST provide clear guidance about merging and summing the results to obtain actual monthly usage.

Report providers MUST alert the COUNTER Project Director (tasha.mellins-cohen@counterusage.org) in advance of platforms transitioning to a new reporting service to ensure that the COUNTER Registry remains up to date. Transition details, including the date of transition, will be noted in the specific platform record and as a notification to report consumers.

Dual Running of Reporting Systems

Report providers have two options in respect of delivering previous reports, where they are unable to offer a single report with date ranges that span the transition period.

• Support two reporting systems, such that reports on usage dating prior to transition are held in the old reporting service. In this case report consumers will access post-transition reports on the new reporting service and pre-transition reports on the old reporting service.

• Support the pre-transition reports on the new reporting service.

Transitioning to a New Code of Practice

New releases of the COUNTER Code of Practice will typically be assigned an effective date after which a report provider must be compliant. In such cases, a report provider may choose to implement the new release before the effective date.

Compliant Report Providers

New releases of the COUNTER Code of Practice may come with specific transition instructions, but, in general, report providers who are already COUNTER-compliant:

• May implement the new release prior to the effective date of the new release while continuing to offer reporting compliant with the existing release.

• Are not required to provide reports compliant with the new release for usage transacted prior to the implementation date; however, they may choose to do so at their discretion.

• MUST continue to meet the requirement to offer valid COUNTER reports for the current year plus the prior 24 months (or from the date they first became compliant, whichever is later) via a web interface and via a SUSHI server.

• MUST provide a means for customers to receive prior-release reports for usage transacted from the report provider’s transition date through to 3 full months after the effective date of the new release. For clarity, once Release 5.1 becomes effective 1 January 2025, report consumers must be able to obtain Release 5.0.3 reports for January, February and March 2025. A report provider can meet this requirement in one of the following ways:

  • Maintain two reporting systems such that usage is logged to the old and new reporting services and customers can access current-release reports on the new reporting service and prior-release reports on the old reporting service.

  • Support the prior-release reports on the new reporting service. This may involve using the metrics from the new release to produce reports formatted to the prior release; or it may involve logging additional data to the new reporting service such that the prior release reports can continue to be supported.

  • If the new release offers metrics compatible with the prior release, offer only new release reports provided customers have access to freely available tools that will automatically generate the required prior release report from an equivalent new release report and meet the requirement that these reports are available in tabular form and via the COUNTER_SUSHI API.

• May choose to support COUNTER reports that include a range of months that span the transition period. For example, if the new reporting service compliant with a new COUNTER release was deployed in October of 2024, a customer could request a report for January-December 2024 and receive a single report in either the new release or the previous release (see previous point on the transition period).

• When it is not practical to support a single report with date ranges that span the transition period, the report provider MUST perform the transition on the first day of a month. E.g. if the new reporting service was deployed in October 2024, a customer wanting January-December 2024 usage would request January-September 2024 from the previous reporting service and October-December 2024 from the new reporting service. For clarity, a provider MUST NOT perform the transition mid-month such that the customer is required to run reports on both the old and new reporting services for the same month and merge and sum the results to obtain actual monthly usage.

Report providers MUST alert the COUNTER Project Director (tasha.mellins-cohen@counterusage.org) in advance of transitioning to a new release to ensure that the COUNTER Registry remains up to date. Transition details, including the date of transition, will be noted in the specific platform record and as a notification to report consumers.

New Report Providers

Report providers implementing COUNTER for the first time are encouraged to implement the new release prior to the effective date of the new release. These report providers

• Are not required to provide reports compliant with the new release for usage transacted prior to the implementation date, but may choose to do so at their discretion.

• Are not required to meet the requirement to offer valid COUNTER reports for the current year plus the prior 24 months, but may choose to do so at their discretion.

• Are not required to offer reports compliant with the prior release, but may choose to do so at their discretion.

Report providers implementing COUNTER for the first time are encouraged to contact the COUNTER Project Director (tasha.mellins-cohen@counterusage.org) for advice and support and to request inclusion in the COUNTER Registry per Section 9.

Transitioning from COUNTER R5 to R5.1

The transition from R5 to R5.1 meets the general requirements outlined in Section 13.2.

• Report providers MUST be compliant by Feburary 2025 for delivery of reports starting with January 2025 usage.

• Report providers may choose to become compliant with R5.1 before February 2025.

• Report providers MUST offer R5-compliant reports until April 2025 for delivery of reports up to and including March 2025 usage.

• Report providers may choose to offer access to R5 reports beyond April 2025 at their discretion.

Comparing R5 and R5.1 COUNTER Reports

R5 and R5.1 reports are broadly comparable, provided some care is applied.

• In R5.1, the rule that items are the unit of reporting is applied consistently for all Data_Types. This means item-level requests and investigations for books may be larger in R5.1 reports. To compare R5 to R5.1, report consumers should use the Unique_Title_Investigations and Unique_Title_Requests.

• For the same reason, R5.1 does not use the Section_Type attribute.

• The list of Data_Types has been expanded. This means that conference proceedings, for example, can be more accurately classified. Report consumers are advised to use the Title Report to gain a full understanding of usage, rather than using Standard Views of the Title Report which are restricted to reporting on books and journals.

• The definition and application of Access_Types has been clarified. The primary impact here is on the TR_B1, TR_J1 and TR_J4 Standard Views of the Title Report, which will show only Controlled content without Open and Free_To_Read materials. Report consumers are advised to use the Title Report to gain a full understanding of usage.

• Components, an aspect of the Item Report, are optional in R5.1. Report consumers should use Unique_Item_Investigations and Unique_Item_Requests, which are always reported at the level of the item rather than the component, to effectively compare usage across report providers.

A note on JSON

The R5.1 JSON schema is more compact, resulting in smaller files that are easier to produce, validate, and consume. It can be converted back to the R5 structure, but other changes in R5.1, specifically those detailed above, mean care should be taken when comparing usage reported in R5 and R5.1 formats.

Change History

Release	Description of Change	Substantive?	Date approved	Date for compliance
5.0	New Code of Practice to replace Release 4.	Yes	2017-07-01	2019-02-28 (with support for January 2019 usage)
5.0.1	Amendments, corrections and clarifications based on feedback and questions from the community.	Yes	2018-12-10	2019-02-28 (with support for January 2019 usage)
5.0.2	Amendments, corrections and clarifications based on feedback and questions from the community.	No	2021-09-28	2022-02-28 (with support for January 2022 usage)
5.0.3	Corrections and clarifications based on feedback and questions from the community.	No	2023-03-30	2023-04-28 (with support for March 2023 usage)
5.1	Substantive changes to the Code of Practice, in line with feedback and questions from the community.	Yes	2023-03-30	2025-01-01 (with support for January 2025 usage)

Starting with Release 5.0.2 the COUNTER Code of Practice Release 5 is maintained in the GitHub repository Project-Counter/cop5, and all changes are tracked with GitHub issues and linked pull requests. The change log lists all changes by type and impact of the change.

Appendices

Appendix A: Glossary of Terms

Note: The main Code of Practice document takes precedence in the case of any conflicts between it and this appendix.

Term	Definition	Examples
Abstract	A short summary of an article or content item. A detailed view of article metadata that includes the summary but not the full text. Accessing the abstract/detailed view falls into the usage category of Investigations.
Accepted manuscript	The version of a journal article that has been accepted for publication in a journal. This version includes any pre-publication revisions, but it does not include any formatting or copyediting changes or corrections.
Access Denied	The user is denied access to a content item because their institution lacks a proper license or because simultaneous user limits specified in the license have been exceeded.	Limit_Exceeded, No_License
Access_Method	A COUNTER report attribute indicating whether the usage related to investigations and requests was generated by a human user browsing and searching a website (Regular) or by Text and Data Mining processes (TDM).	Regular, TDM
Access_Type	A COUNTER report attribute used to report on the nature of access control restrictions, if any, placed on the content item on the platform at the time when the content item was accessed.	Controlled, Open, Free_to_Read
Aggregated_Full_Content	A COUNTER Host_Type for report providers that provide access to databases of full text serial and/or book content (monographs, reference works, etc.), and/or content otherwise aggregated into titles, where content is accessed in the context of the licensed database.
Aggregated full-text database	A full-text database that includes content from multiple titles, usually from multiple publishers.	Academic Search Complete
Aggregator	A type of report provider that hosts content from multiple publishers, delivers content directly to customers, and is paid for this service by customers.	EBSCOhost, Gale, Lexis Nexis, ProQuest
A&I database A&I_Database	A database that primarily contains bibliographic metadata and descriptive abstracts to support search, discovery, and selection of the described items. The majority of A&I databases center on articles, books, and book chapters. A&I_Databases do not host full text of the described items. For databases that contain A&I and full text, see Full-text database, Aggregated full-text database, Aggregated_Full_Content and Full_Content_Database. A COUNTER Host_Type.	PubMed, PsycInfo
AJAX	Asynchronous JavaScript And XML. AJAX allows web pages to be updated asynchronously by exchanging data with a web server behind the scenes.
ALPSP	The Association of Learned and Professional Society Publishers is an international trade association of non-profit publishers.
APC	See Article processing charge.
API	Application Programming Interface.
Archive	Non-current collections of journals, books, articles, or other publications that are preserved because of their continuing value and which are frequently made available by publishers as separate acquisitions.	Oxford Journals Archive
Article	An article from a journal, or an article available as a standalone piece of content (e.g. in an institutional repository) either as a preprint, an author accepted manuscript, a version of record, or another article version as defined by NISO RP-8-2008, Journal Article Versions. An article is complete, but usually cites other relevant published works in its list of references, if it has one. A COUNTER Data_Type.
Article processing charges	An article processing charge (APC), also known as a publication fee, is a fee which is sometimes charged to authors to make a work available open access in either an open access journal or hybrid journal. …They are the most common funding method for professionally published open access articles. [Wikipedia]
Article_Version	Defined by ALPSP and NISO as a classification of the version of an Article as it goes through its publication life-cycle, in NISO RP-8-2008, Journal Article Versions. An element in COUNTER Item Reports that identifies the version of the Article being accessed.	AM, VoR, CVoR, EVoR
Articles in press	Full-text articles that have been accepted for publication in a journal and have been made available online to customers and that will be assigned a publication date of the current year or a future year.
Attribute	See Report Attributes.
Audiovisual	A form of multimedia, typically describing video content. A COUNTER Data_Type.
Author(s)	The person/people who wrote/created the items whose usage is being reported.
Automated search	A search from a host site or discovery service where multiple databases are searched simultaneously with a single query from the user interface and the end user does not have the option of selecting the databases being searched. Usage of this nature is reported as Searches_Automated. A search run repeatedly (e.g. daily or weekly) by a script or automated process. Usage of this nature must not be included in COUNTER reports.
Automated search agent	A script or automated process that runs a search repeatedly, usually at pre-set intervals such as daily or weekly.
Backfile	See Archive.	Oxford Journals Archive
Begin_Date	The first date in the range for the usage represented in a COUNTER report.
Book	A monograph text, edited volume, textbook, or other form of non-serial (book) publication. A COUNTER Data_Type.
Book chapter	A subdivision of a book or of some categories of reference work; usually numbered and titled.
Book Requests	Book content items retrieved.
Book_Segment	A generic term applying to a sub-division of a book regardless of the label applied by the publisher (e.g. chapter, section, etc.). May be available as part of the book as a standalone piece of content available as a distinct item not aggregated into a title, for example in an institutional repository. A COUNTER Data_Type.
Bulk download	A single event where multiple content items are downloaded to the user’s computer.
Cache	An automated system that collects items from remote servers to serve closer and more efficiently to a given population of users. Often populated by robots or modern browsers. Note: Publishers take steps to prevent local caching of their content, i.e. including appropriate response headers on their site to restrict caching.
Central Index	Also known as a Discovery Index. A collection of locally-hosted, consistently indexed metadata and content harvested from multiple external metadata and content sources, frequently including a library’s catalog and repository metadata, and usually representing a significant portion of the library’s collection.
Certified Public Accountant (CPA)	An accounting designation granted to accounting professionals in the United States.
Chapter	A subdivision of a book or of some categories of reference work, usually numbered and titled.
Chartered Accountant (CA)	An international accounting designation granted to accounting professionals in many countries around the world, aside from the United States.
Citation	A reference to a published or unpublished source.
Collection	A subset of the content of a service. A collection is a branded group of online information products from one or more vendors that can be subscribed to/licensed and searched as a complete group. For the COUNTER reporting this term is restricted to pre-set collections that are defined like databases. See Database. Note: A package or bundle provided by a publisher is not considered a database or a collection.
Component	A uniquely identifiable constituent part of a content item composed of more than one file (digital object). Report providers may choose to offer component usage reporting, but are not obliged to do so.
Conference	A collection of papers, posters, or recordings of material associated with a conference. Typically part of a serial publication. A COUNTER Data_Type.
Conference_Item	A single paper, poster, or recording of material associated with a conference. A COUNTER Data_Type.
Consortium	A group of institutions joining together to license content.	Ohiolink
Consortium member	An institution that has obtained access to online information resources as part of a consortium. A consortium member is defined by a subset of the consortium’s range of IP addresses or by other specific authentication details.	Ohio State University
Content host	A website that provides access to content typically accessed by patrons of libraries and other research institutions.
Content item	A generic term describing a unit of content accessed by a user of a content host. Typical content items include articles, books, chapters, multimedia, etc.
Content provider	See Report provider.
Controlled	A COUNTER Access_Type. At the time of the Request or Investigation the content item was restricted to authorized users (e.g. behind a paywall) on this platform. This includes free content that is only available to authorized (registered) users. For example, trial subscription usage would be considered Controlled.
Copyright holder	A person or a company who owns any one of the Exclusive Rights of copyright in a work.
Corrected Version of Record	A version of the Version of Record of a journal article in which errors in the VoR have been corrected. The errors could be author errors, publisher errors, or other processing errors.
COUNTER compliance pending	Status of a vendor who is currently not compliant but whose audit is in progress or scheduled.
COUNTER Report Validation Tool	An online tool to validate COUNTER reports in JSON and tabular format.
COUNTER Reports	The four primary reports (Platform, Database, Title and Item Reports) defined by COUNTER, highly flexible with multiple filter options, and with associated Standard Views of the COUNTER Reports.
COUNTER_SUSHI API	A RESTful implementation of SUSHI automation intended to return COUNTER Release 5 reports and snippets of COUNTER usage in JSON format.
Crawler	See Internet robot, crawler, spider.
Created	COUNTER element name. The date and time the usage was prepared, in RFC3339 date-time format (yyyy-mm-ddThh:mm:ssZ).
Created_By	COUNTER element name. The name of the organization or system that created the COUNTER report.
Crossref	A not-for-profit membership organization for publishers.
Customer	An individual or organization that can access a specified range of the report provider’s services and/or content that is subject to the agreed terms and conditions.
Customer_ID	The element in the COUNTER reports that indicates whose usage is being reported. May be a proprietary or standard value such as ISNI.	ISNI:000000012150090X
Data harvesting	Automated processes used for extracting data from websites.
Data_Repository	An online database service; an archive that manages the long-term storage and preservation of digital resources and provides a catalogue for discovery and access. A COUNTER Host_Type.	Figshare
Data_Type	The element identifying the type of content.	Article, Audiovisual, Book, Book_Segment, Conference, Conference_Item, Database_Aggregated, Database_AI, Database_Full, Database_Full_Item, Dataset, Image, Interactive_Resource, Journal, Multimedia, News_Item, Newspaper_Or_Newsletter, Other, Patent, Platform, Report, Reference_Item, Reference_Work, Report, Software, Sound, Standard, Thesis_Or_Dissertation, Unspecified
Database_Aggregated	An aggregated database of full text serial and/or monograph content, or content otherwise aggregated into titles. A COUNTER Data_Type applying only to Denial and Search metrics.
Database_AI	An fixed database of bibliographic metadata used for abstracting and indexing purposes. A COUNTER Data_Type applying only to Denial and Search metrics.
Database_Full	A non-aggregated database of full text serial and/or monograph content, or content otherwise not aggregated into titles. A COUNTER Data_Type applying only to Denial and Search metrics.
Database_Full_Item	An individual item of content held on a Full_Content_Database. A COUNTER Data_Type.
Database Report	A COUNTER report that contains additional filters and breakdowns beyond those included in the Standard Views of the Database Report and is aggregated to the database level.
Database Reports	A series of COUNTER reports that provide usage aggregated to the database level.
Dataset	Data encoded in a defined structure, for example data associated with a research project. A COUNTER Data_Type.
Delayed Open Access	See Open.
Digital Object Identifier	See DOI.
Discovery Layer	A web-accessible interface for searching, browsing, filtering, and otherwise interacting with indexed metadata and content. The searches produce a single, relevancy-ranked results set, usually displayed as a list with links to full content, when available. Typically, discovery layers are customizable by subscribing libraries and may be personalized by individual users.
Discovery service Discovery_Service	A pre-harvested central index coupled with a fully featured discovery layer. A COUNTER Host_Type.	EDS, Primo, Summon
Distributed Usage Logging (DUL)	A peer-to-peer channel for the secure exchange and processing of COUNTER-compliant private usage records from hosting platforms to publishers.
DNS lookups	Domain Name System lookups.
DOI (digital object identifier)	A standard identifier (ANSI/NISO Z39.84). The digital object identifier is a means of identifying a piece of intellectual property (a creation) on a digital network, irrespective of its current location. DOIs may be assigned at the title, article/chapter, or component level.
Double-click	Two clicks in succession on the same link by the same user within a period of 30 seconds. COUNTER requires that double-clicks must be counted as a single click.
Double-click filtering	A process to remove the potential of over-counting which could occur when a user clicks the same link multiple times. Double-click filtering applies to Total_Item and Access Denied Metric_Types.
DR	Database Report.
DR_D1	Database Search and Item Usage. A pre-set Standard View of DR showing Total_Item_Investigations and Requests, as well as Searches_Regular, Automated and Federated.
DR_D2	Database Access Denied. A pre-set Standard View of DR showing where users were denied access because simultaneous-use (concurrency) licenses were exceeded, or their institution did not have a license for the database.
DUL	See Distributed Usage Logging (DUL).
eBook	Monographic content that is published online. A COUNTER Host_Type.
eBook_Collection	A branded group of eBooks that can be subscribed to/licensed and searched as a complete group. A COUNTER Host_Type.
eBook host	A content host that provides access to eBook and reference work content.	EBL, EBSCOhost, ScienceDirect
EC	See Executive Committee.
eJournal	Serial content that is published online. A COUNTER Host_Type.
eJournal host	A content host that provides access to online serial publications (journals, conferences, newspapers, etc.).	ScienceDirect
Element	A piece of information to be reported on, displayed as a column heading (and/or in the report header) in a COUNTER report.
Embargo period	The period of time before an article is moved out from behind the paywall, i.e. from Controlled to Open.
End_Date	The last date in the range for the usage represented in a COUNTER report.
Enhanced Version of Record	A version of the Version of Record of a journal article that has been updated or enhanced by the provision of supplementary material. For example, multimedia objects such as audio clips and applets; additional XML-tagged sections, tables, or figures or raw data.
e-Resources	Electronic resources.
Exception	An optional element that may be included within a COUNTER report indicating some difference between the usage that was requested and the usage that is being presented in the report. An Exception includes the Exception Code and Exception Message and may include additional Data that further describes the error.	3031: Usage Not Ready for Requested Dates (request was for 2024-01-01 to 2024-12-31, but usage is only available to 2024-08-31).
Exception Code	A unique numeric code included as part of an Exception that identifies the type of error.
Exception Message	A short description of the Exception encountered. The Message is normally a standard message for the Exception Code concerned. See Appendix D.
Exclude_Monthly_Details	A COUNTER report attribute for tabular reports that specifies whether the columns with the month-by-month breakdown of the usage are excluded from the report.
Executive Committee	The committee which deals with the day-to-day activities of COUNTER’s business.
Federated search	A search conducted by a federated search application that allows users to simultaneously search multiple content sources, typically hosted by different vendors, with a single query from a single user interface. The federated search application typically presents the user with a single set of results collected from the content sources searched. The end user is not responsible for selecting the content sources being searched. The content sources being searched will report such activity as Searches_Federated. See Appendix F.	MetaLib, EBSCOhost Connection
Filter	See Report filters.
Free_to_Read	A COUNTER Access_Type. At the time of the Request or Investigation the content item was available to all users on this platform, regardless of authorization status, but was not Open. The content item may or may not have been Controlled at some point in the past, and may or may not return to Controlled status in the future (e.g. promotional materials where these can be tracked by the platform, or archival content a publisher has made free to read).
Full_Content_Database	A COUNTER Host_Type for report providers that offer databases that are a collection of content items that are not aggregated into titles (i.e. not part of a serial or book or other title). Full_Content_Database may include but not be exclusively composed of multimedia content items.
Full-text article	The complete text - including all references, figures, and tables - of an article, plus links to any supplementary material published with it.
Full-text database	A database that contains the complete text of books,dissertations, journals, magazines, newspapers or other kinds of textual documents. [Wikipedia]
GDPR	General Data Protection Regulation.
Global Report	A report to “The World” including all global usage, whether attributed to an institution or not.
Global Database Report	A Database Report that is reporting all global usage to “The World”, whether attributed to an institution or not.
Global Item Report	An Item Report that is reporting all global usage to “The World”, whether attributed to an institution or not. Particularly valuable for reporting on usage of open access content.
Global Platform Report	A Platform Report that is reporting all global usage to “The World”, whether attributed to an institution or not.
Global Title Report	A Title Report that is reporting all global usage to “The World”, whether attributed to an institution or not.
Host	See Content host.	Ingenta, Semantico, SpringerLink
Host Site	See Content host.
Host_Type	A categorization of content hosts used by COUNTER to facilitate implementation of the Code of Practice. The Code of Practice identifies the Host_Types that apply to the various artefacts in the Code of Practice, allowing a content host to quickly identify the areas of the Code of Practice to implement by identifying the Host_Types that apply to them.	A&I_Database, Aggregated_Full_Content, Data_Repository, Discovery_Service, eBook, eBook_Collection, eJournal, Full_Content_Database, Multimedia, Multimedia_Collection, Repository, Scholarly_Collaboration_Network
Host UI	User interface that an end user would use to access content on the content host.
HTTP	Hypertext Transfer Protocol.
Hybrid publication	A publication that is available via a subscription license but also contains articles available as open access.
Image	A form of multimedia describing a static visual image. A COUNTER Data_Type.
Institution	The organization for which usage is being reported.
Institution_ID	A unique identifier for an institution. In COUNTER reports the Institution_ID is presented as a combination of the identifier namespace and its value. Proprietary identifiers that identify the content platform can be used.	ISNI:000000012150090X, EBSCOhost:s12345
Institution_Name	The element in the COUNTER reports that indicates the name of the institution.
Institutional identifier	See Institution_ID.
Interactive_Resource	A form of multimedia, typically describing materials that require user interaction to be understood, executed or experienced. A COUNTER Data_Type.
Internet robot, crawler, spider	Any automated program or script that visits websites and systematically retrieves information from them, often to provide indexes for search engines. See Appendix H.
Investigation	A category of COUNTER Metric_Types that represent a user accessing information related to a content item (e.g. an abstract or detailed descriptive metadata of an article) or a content item itself (e.g. full text of an article).
IP	Internet Protocol.
IP address	Internet protocol (IP) address of the computer on which the session is conducted. May be used by report providers as a means of authentication and authorization and for identifying the institution a user is affiliated with. The identifying network address (typically four 8-bit numbers separated by “.” for IPv4 or eight groups of up to four hexadezimal numbers separated by “:” for IPv6) of the user’s computer or proxy.
IR	Item Report.
IR_A1	Journal Article Requests. A pre-set Standard View of IR showing Total and Unique_Item_Requests for journal articles.
IR_M1	Multimedia Item Requests. A pre-set Standard View of IR showing Total_Item_Requests for multimedia items.
ISBN (International Standard Book Number)	A unique standard identifier (ISO 2108) used to identify monographic publications (books).
ISIL	International Standard Identifier for Libraries and Related Organizations (ISO 15511). In COUNTER reports ISILs can be used as identifiers for institutions.
ISNI	International Standard Name Identifier (ISO 27729). A unique number used to identify authors, contributors, and distributors of creative works, including researchers, inventors, writers, artists, visual creators, performers, producers, publishers, aggregators, etc. In COUNTER reports ISNIs can be used as identifiers for institutions, publishers and item contributors (authors).
ISO	International Organization for Standardization.
ISSN (International Standard Serial Number)	A unique standard identifier (ISO 3297) used to identify a print or electronic periodical publication. A periodical published in both print and electronic form may have two ISSNs, a print ISSN and an electronic ISSN.
Issue	A collection of journal articles that share a specific issue number and are presented as an identifiable unit online and/or as a physically bound and covered set of numbered pages in print.
Item	Collective term for content that is reported at a high level of granularity, e.g. a full-text article (original or a review of other published work), an abstract or digest of a full-text article, a sectional HTML page, supplementary material associated with a full-text article (e.g. a supplementary data set), or non-textual resources such as an image, a video, audio, a dataset, a piece of code, or a chemical structure or reaction.	Full-text article, Abstract, Database record, Dataset, Thesis
Item Report	A COUNTER report that provides usage data at the item or (at the discretion of the report provider) item-component level.
Item Reports	A series of COUNTER reports that provide usage data at the item or (at the discretion of the report provider) item-component level.
JavaScript Object Notation	See JSON.
Journal	A serial that is a branded and continually growing collection of original articles within a particular discipline. A COUNTER Data_Type.	Tetrahedron Letters
Journal Requests	Journal content items retrieved.
JQuery	A JavaScript library.
JSON	JavaScript Object Notation (JSON) is an open standard file format that uses human-readable text to transmit data objects consisting of attribute–value pairs and array data types. [Wikipedia]
License	A contract or agreement that provides an organization or individual (licensee) with the right to access certain content.
Limit_Exceeded	A COUNTER Metric_Type. A user is denied access to a content item because the simultaneous-user limit for their institution’s license would be exceeded.
Log file analysis	A method of collecting usage data in which the web server records all of its transactions.
Master Reports	An older term for COUNTER reports.
Metadata	A series of textual elements that describes a content item but does not include the item itself. For example, metadata for a journal article would typically include publisher, journal title, volume, issue, page numbers, copyright information, a list of names and affiliations of the authors, author organization addresses, the article title and an abstract of the article, and keywords or other subject classifications.
Metadata provider	An organization, such as a publisher, that provides descriptive article/item-level metadata to an online search service.
Metric_Type	A COUNTER report attribute that identifies the nature of the usage activity.	Total_Item_Requests, Searches_Regular, Limit_Exceeded, Unique_Title_Requests
Monograph Text	See Book.
Multimedia	Non-textual media such as audio, images, video and interactive tools. Typically used as a Data_Type only where report providers cannot easily classify materials more specifically. A COUNTER Host_Type. A COUNTER Data_Type.
Multimedia collection Multmedia_Collection	A grouping of multimedia items that are hosted and searched as a single unit and behave like a database. A COUNTER Host_Type. See also Database.
Multimedia item	An item of non-textual media content such as an image or streaming or downloadable audio or video files. (Does not include thumbnails or descriptive text/metadata.)
Namespace	A term primarily used in programming languages where the same name may be used for different objects. It is created to group together those names that might be repeated elsewhere within the same or interlinked programs, objects and elements. For example, an XML namespace consists of element types and attribute names. Each of the names within that namespace is only related/linked to that namespace. The name is uniquely identified by the namespace identifier ahead of the name. For example, Namespace1:John and Namespace2:John are the same names but within different namespaces.
News_Item	An article from a newspaper or magazine, or a news piece available as a standalone piece of content available as a distinct item not aggregated into a title. A COUNTER Data_Type.
Newspaper_or_Newsletter	Textual content published serially in a newspaper or newsletter. A COUNTER Data_Type.	The Guardian
NISO	The National Information Standards Organization is a United States non-profit standards organization that develops, maintains and publishes technical standards related to publishing, bibliographic and library applications. [Wikipedia]
No_License	A COUNTER Metric_Type. A user is denied access to a content item because the user or the user’s institution does not have access rights under an agreement with the vendor.
OA	See Open Access.
OA_Gold	An Access_Type applied in Release 5. Now replaced with the broader Open.
Open	A COUNTER Access_Type. At the time of the Request or Investigation the content item was available to all users on this platform, regardless of authorization status, under an open access model. Open applies where the content provider asserts that the content is open access, irrespective of the license associated with the content item (that is, while the content item may be under a Creative Commons license this is not essential). Open content items may be in hybrid or fully open access publications. Open content items may have been Open from the day of publication, or after expiry of an embargo, but it is not intended to return to Controlled status.
Open Access	See Open.
OCLC	OCLC (Online Computer Library Center). An American non-profit cooperative organization “dedicated to the public purposes of furthering access to the world’s information and reducing information costs”. It was founded in 1967 as the Ohio College Library Center. [Wikipedia]
Online_ISSN	A COUNTER report item identifier for the ISSN assigned to the online manifestation of a serial work. See also ISSN.	1533-4406
Open Access	Open Access (OA) refers to online research outputs that are free of all restrictions on access (e.g. access tolls) and free of many restrictions on use (e.g. certain copyright and license restrictions). Open access can be applied to all forms of published research output, including peer-reviewed and non-peer-reviewed academic journal articles, conference papers, theses, book chapters, and monographs. [Wikipedia]
ORCID	An international standard identifier for individuals (i.e. authors) to use with their name as they engage in research, scholarship, and innovation activities. See https://orcid.org/. A COUNTER identifier type for item contributors.
Other	A content item that has been labelled as a type of data that does not exist within and cannot be mapped to a COUNTER Data_Type. A COUNTER Data_Type.
Other_Free_to_Read	An Access_Type applied in a very limited way in Release 5. Now replaced with Free_To_Read.
Page tag	Page-tagging is a method of collecting usage data that uses, for example, JavaScript on each page to notify a third-party server when a page is rendered by a web-browser.
Parent	In COUNTER Item Reports the parent is the publication an item is part of. For a journal article, the parent is the journal, and for a book chapter it is the book.
Patent	A patent document representing an exclusive right granted for an invention, which is a product or process that provides (in general) a new way of doing something, or offers a new technical solution to a problem. Typically associated with a patent number. A COUNTER Data_Type.
Paywall	A term used to describe the fact that a user attempting to access a content item must be authorized by license or must pay a fee before the content can be accessed.
PDF	Portable Document Format, a standard file format for representing electronic documents (ISO 32000). Items such as full-text articles or journals published in PDF format tend to replicate the printed page in appearance.
PHP	PHP is a general-purpose programming language originally designed for web development. The PHP reference implementation is now produced by The PHP Group. [Wikipedia]
Platform	The content host of an aggregator, publisher, or other online service that delivers the content to the user and that counts and provides the COUNTER usage reports. Individual titles or groups of content might have their own branded user experience but reside on a common host. A COUNTER Data_Type.	Wiley Online Library, HighWire
Platform Report	A COUNTER report that contains additional filters and breakdowns beyond those included in the Standard Views of the Platform Report, and which is aggregated to the platform level.
Platform Reports	A series of COUNTER reports that provide usage aggregated to the platform level.
Platform search	A search conducted at the platform level.
Platform usage	Activity across all metrics for entire platforms.
PR	Platform Report.
PR_P1	Platform Usage. A pre-set Standard View of PR showing Total and Unique_Item_Requests and Unique_Title_Requests, as well as Searches_Platform.
Print_ISSN	A COUNTER report item identifier for the ISSN assigned to the print manifestation of a work. See also ISSN.	0028-4793
Proprietary_ID	A COUNTER report item identifier for a unique identifier given by publishers and other report providers to a product or collection of products.
Proprietary Identifier	See Proprietary_ID.
Publication date Publication_Date	The date of release by the publisher to customers of a content item. An element in COUNTER Item Reports.
Publisher	An organization whose function is to commission, create, collect, validate, host, distribute and trade information online and/or in printed form.	Sage, Cambridge University Press
Publisher_ID	An element in COUNTER reports for a publisher’s unique identifier. In COUNTER reports the Publisher_ID is presented as a combination of identifier namespace and value.
R4	Release 4.
R5	Release 5.
Reference_Item	An item or record within a Reference_Work, such as an encyclopedia reference, or a similar item not aggregated into a title. A COUNTER Data_Type.
Reference_Work	An authoritative source of information about a subject used to find quick answers to questions. The content may be stable or updated over time. A COUNTER Data_Type	Dictionary, encyclopedia, directory, manual, guide, atlas, index
References	A list of works referred to in an article or chapter with sufficient detail to enable the identification and location of each work.
Registry of compliance	The COUNTER Registry of report providers compliant with the COUNTER Code of Practice [Registry].
Regular	A COUNTER Access_Method. Indicates that usage was generated by a human user browsing/searching a website, rather than by text and data mining processes.
Regular search	A search conducted by a user on a host where the user has the option of selecting the databases being searched.
Release	Version of the COUNTER Code of Practice.
Report	A document that presents information in an organized format for a specific audience and purpose, such as a policy report. A COUNTER Data_Type.
Report attributes Report_Attributes	Report attributes are elements in COUNTER reports that describe the nature of usage for an item or affect how the usage is broken down. In COUNTER Reports the Report_Attributes report header includes a series of report attributes applied to the report. This affects how the usage is presented (i.e. which columns/elements are included in the report), but it does not change the totals.	Attributes_To_Show=Access_Type|YOP
Report consumer	An umbrella term referring to all those who make use of COUNTER reports, including librarians, consortia managers, publisher and aggregator staff, etc.
Report filters Report_Filters	Report filters can be used to limit the usage returned in a COUNTER report. For Standard Views of the COUNTER Reports the report filters are pre-set, for COUNTER Reports they can be used to customize the report. The Report_Filters report header includes a series of report filters applied to the report.	Data_Type=Journal
Report_ID	The alphanumeric identifier of a specific COUNTER Report or Standard View of a COUNTER Report.	PR, DR_D1, TR_J3
Report name Report_Name	The name of a COUNTER Report or Standard View of a COUNTER Report.	Journal Requests (Controlled)
Report provider	An umbrella term. Includes publishers, aggregators and others who directly provide access to content, as well as organizations that provide specialist reporting services on behalf of one or more organizations.	Science Direct, Clarivate, JSTOR, ScholarlyIQ
Report validation tool	See COUNTER Report Validation Tool.
Reporting period Reporting_Period	The total time period covered in a usage report.	Begin_Date=2024-01-01; End_Date=2024-06-30
Repository	A host who provides access to an institution’s research output. Includes subject repositories, institution, department, etc. A COUNTER Host_Type.	Cranfield CERES
Repository item Repository_Item	A content item hosted in a repository, including one that consists of one or more digital objects such as text files, audio, video or data, described by associated metadata. A COUNTER Data_Type.
Request	A category of COUNTER Metric_Types that represents a user accessing content (e.g. full text of an article).
Requestor ID	A system-generated hash identifier that uniquely identifies a requestor session.
Required reports	The COUNTER reports that Host_Types are required to provide.
Research data	Data that supports research findings and may include databases, spreadsheets, tables, raw transaction logs, etc.
RESTful COUNTER_SUSHI API	A RESTful implementation of SUSHI automation intended to return COUNTER Release 5 reports and snippets of COUNTER usage in JSON format. RESTful is based on representational state transfer (REST) technology, an architectural style and approach to communications often used in web services development.
Robot	See Internet robot, crawler, spider.
ROR (Research Organization Registry)	ROR is a community-led registry of open, sustainable, usable, and unique identifiers for every research organization in the world. [ROR]. In COUNTER reports ROR IDs can be used as identifiers for institutions and publishers.
Scholarly Collaboration Network Scholarly_Collaboration_Network	A service used by researchers to share information about their work. A COUNTER Host_Type.	Mendeley, Reddit/Science
Screen scraping	The action of using a computer program to copy data from a website.
Search	A user-driven intellectual query, typically equated to submitting the search form of the online service to the server. For COUNTER reports a search is counted any time a system executes a search to retrieve a new set of results. This means that systems that perform multiple searches (e.g. search for exact match, search for words in subject, general search) to return a single set of results must only count a single search, not multiple searches. Things that do count as separate searches: Bento-box or multi-tab user interfaces, where multiple searches are conducted to retrieve and present multiple result sets Refinement of a set of search results by faceting, where applying a facet or filter requires the search to be re-run Browsing through a topics list or subject authority file, where clicking on the topic or subject conducts a search to present a set of search results Note that link resolution never counts as a search.
Search engine	A service that allows users to search for content via the World Wide Web.
Searches_Automated	A COUNTER Metric_Type used to report on searches conducted on a host site or discovery service where multiple databases are searched simultaneously with a single query and the end user does not have the option of selecting the databases being searched. See also Automated search.
Searches_Federated	A COUNTER Metric_Type used to report on searches conducted by a federated search application. See Appendix F. See also Federated search.
Searches_Platform	A COUNTER Metric_Type used to report on searches conducted at the platform level. Note: Searches conducted against multiple databases on the platform will only be counted once.
Searches_Regular	A COUNTER Metric_Type used to report on searches conducted by a user on a host site where the user has the option of selecting the databases being searched. Note: If a search is conducted across multiple databases, each database searched will count that search. See also Regular search.
Section	A group of chapters or articles.
Section_Type	Defunct in R5.1. A COUNTER R5 report attribute that identified the type of section that was accessed by the user.	Article, Book, Chapter, Other
Serial	A publication in any medium issued in successive parts bearing numerical or chronological designations and intended to be continued indefinitely. This definition includes periodicals, journals, magazines, electronic journals, ongoing directories, annual reports, newspapers, monographic series, and also those journals, magazines, and newsletters of limited duration that otherwise bear all the characteristics of serials (e.g. newsletter of an event). [NISO]
Server-side scripting language	Server-side scripting is a technique used in web development which involves employing scripts on a web server which produce a response customized for each user’s request to the website. The alternative is for the web server itself to deliver a static web page. [Wikipedia]
Service	See Content host.	ScienceDirect, Academic Universe
Session	A successful use of an online service. A single user connects to the service or database and ends by terminating activity that is either explicit (by leaving the service through exit or logout) or implicit (timeout due to user inactivity). [NISO]
Session cookie	A data file that a web server can place on a browser to track activity by a user and attribute that usage to a session.
Session ID	A unique identifier for a single user session. If the report provider’s web-site does not assign and capture a unique identifier to each user session, then a surrogate session ID can be generated using the browser user-agent, the user’s IP address and a one hour time slice (see Section 7 for details). The Session ID is used for double-click filtering and computing Unique_Item and Unique_Title metrics.
Sites	See Hosts.
Software	Source code or compiled software, or a virtual notebook environment used for programming. A COUNTER Data_Type.
Sound	A form of multimedia, typically describing content that is audio-only (e.g. a radio programme). A COUNTER Data_Type.
Spider	See Internet robot, crawler, spider.
Standard	A document outlining processes agreed and established by authority or by general consent (e.g. materials from NISO). A COUNTER Data_Type.	The COUNTER Code of Practice
Standard View of a COUNTER Report	A predefined version of a COUNTER report, designed to meet the most common needs.	Book Requests (Controlled), Journal Article Requests
Standardized Usage Statistics Harvesting Initiative	See SUSHI.
Status code	HTTP response status code. Status codes are issued by a server in response to a client’s request made to the server. [Wikipedia]
SUSHI	Short form for the COUNTER_SUSHI API used in COUNTER R5 for harvesting COUNTER reports. COUNTER compliance requires content hosts to implement the COUNTER_SUSHI API.
Tab Separated Value	See TSV.
TDM	Text and data mining (TDM) is a computational process whereby text or datasets are crawled by software that recognizes entities, relationships, and actions. [STM Publishers] A COUNTER Access_Method used to separate regular usage from usage that represents access to content for the purposes of text and data mining.
Text and data mining	See TDM.
The World	Used as the Institution_Name for global reports including all global usage, whether attributed to institutions or not.
Thesis_Or_Dissertation	Long-form writing on a specific subject, often involving personal research, and typically produced to meet requirements for postgraduate or undergraduate qualifications. A COUNTER Data_Type.
Title	The name of a book, journal, or reference work.
Title Report	A COUNTER report that contains additional filters and breakdowns beyond those included in the Standard Views of the Title Report and is aggregated to publication title level rather than towards individual articles/chapters.
Title Reports	A series of COUNTER reports where usage is aggregated to the publication title level.
TLS (HTTPS)	Transport Layer Security (TLS) protocol, Hypertext Transfer Protocol Secure (HTTPS) protocol.
Total_Item_Investigations	A COUNTER Metric_Type that represents the number of times users accessed the content (e.g. a full text) of an item, or information describing that item (e.g. an abstract).
Total_Item_Requests	A COUNTER Metric_Type that represents the number of times users requested the full content (e.g. a full text) of an item. Requests may take the form of viewing, downloading, emailing, or printing content, provided such actions can be tracked by the report provider.
TR	Title Report.
TR_B1	Book Requests (Controlled). A pre-set Standard View of TR showing full text activity for all book and reference work content which is not Open or Free_To_Read.
TR_B2	Book Access Denied. A pre-set Standard View of TR showing where users were denied access because simultaneous-use (concurrency) licenses were exceeded, or their institution did not have a license for the book or reference work.
TR_B3	Book Usage by Access Type. A pre-set Standard View of TR showing all applicable Metric_Types broken down by Access_Type for books and reference works.
TR_J1	Journal Requests (Controlled). A pre-set Standard View of TR showing full text activity for all journal content which is not Open or Free_To_Read.
TR_J2	Journal Accessed Denied. A pre-set Standard View of TR showing where users were denied access because simultaneous-use licenses were exceeded, or their institution did not have a license for the journal.
TR_J3	Journal Usage by Access Type. A pre-set Standard View of TR showing all applicable Metric_Types broken down by Access_Type.
TR_J4	Journal Requests by YOP (Controlled). A pre-set Standard View of TR breaking down the full text usage of Controlled content by year of publication (YOP).
Transaction	A usage event.
TSV	A tab-separated values (TSV) file is a simple text format for storing data in a tabular structure, e.g. database table or spreadsheet data. Each record in the table is one line of the text file. Each field value of a record is separated from the next by a tab character. [Wikipedia]
Turnaway	See Access denied.
Unique item	A content item assessed during a session. Each unique content item accessed in a session is counted once per user session, even if there are multiple requests for the same content item during a session.
Unique_Item_Investigations	A COUNTER Metric_Type that represents the number of unique content items investigated in a user session. Examples of content items are articles, books, book chapters, and multimedia files.
Unique_Item_Requests	A COUNTER Metric_Type that represents the number of unique content items requested in a user session. Examples of content items are articles, books, book chapters, and multimedia files.
Unique title	A book assessed during a session. Each unique book title accessed in a session is counted once per user session, even if there are multiple requests for the same title during a session.
Unique_Title_Investigations	A COUNTER Metric_Type that represents the number of unique titles investigated in a user session. This Metric_Type is only applicable for Data_Types Book and Reference_Work.
Unique_Title_Requests	A COUNTER Metric_Type that represents the number of unique titles requested in a user session. This Metric_Type is only applicable for Data_Types Book and Reference_Work.
Unspecified	Content that cannot be classified by any of the other Data_Types due to lack of sufficient information. Note that content providers are expected to make all reasonable efforts to classify the content. A COUNTER Data_Type.
URI	In information technology, a Uniform Resource Identifier (URI) is a string of characters that unambiguously identifies a particular resource. To guarantee uniformity, all URIs follow a predefined set of syntax rules, but also maintain extensibility through a separately defined hierarchical naming scheme (e.g.http://). [Wikipedia] An element in COUNTER reports used to identify the item for which usage is being reported.
URL	Uniform Resource Locator. The address of a World Wide Web page.
URN	Uniform Resource Name, which identifies a resource by name in a particular namespace.
User	A person who accesses the online resource.
User agent	An identifier that is part of the HTTP protocol that identifies the software (e.g. browser) being used to access the site. May be used by robots to identify themselves.
User cookie	A small piece of data sent from a website and stored on the user’s computer by the user’s web browser while the user is browsing.
User session	See Session.
UTF-8	UTF-8 is a variable width character encoding capable of encoding all 1,112,064 valid code points in Unicode using one to four 8-bit bytes. The encoding is defined by the Unicode Standard, and was originally designed by Ken Thompson and Rob Pike. The name is derived from Unicode Transformation Format - 8-bit. [Wikipedia]
Vendor	A publisher or other online information provider who delivers licensed content to the customer and with whom the customer has a contractual relationship.	Taylor & Francis, EBSCO
Version of Record	A fixed version of a journal article that has been made available by any organization that acts as a publisher that formally and exclusively declares the article “published”.
W3C	The World Wide Web Consortium is the main international standards organization for the World Wide Web. [Wikipedia]
XML	A mark-up language that defines a set of rules for encoding documents in a format that is both human-readable and machine-readable. [Wikipedia]
Year of Publication	See YOP.
YOP	Year of publication. Calendar year in which an article, item, issue, or volume is published. For the COUNTER report attribute YOP, use the year of publication for the Version of Record if the year of publication differs for print and online version.
Z39.50	An international standard protocol created by NISO for search. A Z39.50 client can search any Z39.50-compatible online service. Often used by federated search applications to facilitate searching content at other sites.

Appendix B: Changes from Release 5

Note: The main Code of Practice document takes precedence in the case of any conflicts between it and this appendix.

Starting with Release 5.0.2 the COUNTER Code of Practice Release 5 is maintained in the GitHub repository Project-Counter/cop5, and all changes are tracked with GitHub issues and linked pull requests. The change log lists all changes by type and impact of the change.

Primary changes between R5 and R5.1

• Item becoming the unit of reporting - Improved OA reporting is one of the major objectives of R5.1, which requires reporting at the level of the item. This impacts on reporting of book usage: under R5.1, usage of each Book_Segment (e.g. chapter) MUST be reported as a separate item investigation or request, with multiple item investigations or requests rolled up to 1 title investigation or request per book.

• Data_Type - Many publishers reported difficulties with the restricted list of Data_Types provided in R5, so the list has been expanded and the definitions and use of each Data_Type clarified.

• Section_Type - The impact of the above changes means Section_Type is removed in R5.1.

• Access_Type - R5.1 clarifies where and how COUNTER Access_Types apply. R5.1 also introduced revised definitions for Access_Types to better facilitate reporting of open and free materials.

• Components - Required for the Item Report in R5, Components are optional in R5.1 to simplify delivery of Item Reports.

• Report headers - R5.1 added a link to the COUNTER Registry to the standard report header in both JSON and tabular reports.

SUSHI changes between R5 and R5.1

• COUNTER_SUSHI API - The COUNTER_SUSHI API can now be found at Stoplight.io.

• SUSHI URLs - Starting with Release 5.1, the release version number will need to be included in the SUSHI URL path.

• SUSHI authentication - R5.1 removes support for IP-based authentication in the COUNTER_SUSHI API. API key may be used if a replacement is desired.

• SUSHI paths - The /r51/status path is public to allow report consumers to easily check whether a service is live. The /r51/reports endpoint is extended to return information about the first and last months for which data are available. We are also introducing separate parameters for common extensions.

JSON changes between R5 and R5.1

• Compact - to avoid problems with large reports, and easier to process:

  • Parent_Items include Report_Items to avoid duplicate parent metadata.

  • Report_Items include an Attribute_Performance object to avoid duplicate item metadata.

  • Performance is more compact and easier to read.

• Reflect all other changes

  • Changes in the Code of Practice.

  • Changes related to the COUNTER_SUSHI API.

• JSON - format updated to be more in line with standard JSON and thus easier to work with.

• Alignment - removed deviations between the JSON and tabular reports.

Smaller and optional changes

• Global Reports - R5 introduced the concept of “The World” reporting - that is, a report showing total global usage of content, wherever it comes from (institutional or otherwise). R5.1 recommends that all report providers should provide reports at the global level.

• Item Reports - Other changes introduced in R5.1 (e.g. optional Components) simplify delivery of Item Reports. All Host_Types are therefore encouraged to offer the IR.

• Global Item Reports - All Host_Types are encouraged to provide a Global Item Report.

• Report naming - R5.1 uses the terms COUNTER Reports and Standard Views of COUNTER Reports in place of Master Reports and Standard Views.

• Audits - The audit process is clarified and the audit scripts rationalised in R5.1 compared with R5.

• Versioning - We have clarified the versioning process for future Code of Practice releases.

Appendix C: Vendor/Aggregator/Gateway Declaration of COUNTER Compliance

We <name of Report Provider> (‘The Company’) hereby confirm the following:

1. That the following online usage reports that are supplied by The Company to its customers, and which The Company claims to be ‘COUNTER-compliant’, conforming to Release 5.1 of the COUNTER Code of Practice:

   <insert list COUNTER-compliant reports>

2. The Company agrees that it will implement the protocols specified in Section 7 of Release 5 of the Code of Practice to correct for the effects of federated searches and internet robots on usage statistics.

3. Where The Company supplies to customers online usage statistics not included in the usage reports covered in 1 above, but which use terms defined in the COUNTER Code of Practice, that the definitions used by The Company are consistent with those provided in the COUNTER Code of Practice.

4. The Company will pay to COUNTER the Vendor Registration Fee (£500), unless The Company is a Member of COUNTER in good standing, for whom this fee is waived.

5. That to maintain COUNTER-compliant status, the usage reports provided by The Company to its customers will be independently audited according to a schedule and standards specified by COUNTER.

Signature: _________________________________       Date: _________________________________

Name: ____________________________________       Title: __________________________________

For and on behalf of (report provider’s name):

______________________________________________________________________________________

Address: _____________________________________________________________________________

Email address: ________________________________________________________________________

Upon receipt of this signed declaration by the COUNTER office, and upon payment (where the Company is not a member of COUNTER) by The Company of the Report Provider Registration Fee, The Company will be listed on the COUNTER Registry as providing COUNTER-compliant usage reports pending completion of a formal audit within 6 months of signing this declaration.

This Declaration may be scanned and emailed to: tasha.mellins-cohen@counterusage.org

Appendix D: Handling Errors and Exceptions

Note: The main Code of Practice document takes precedence in the case of any conflicts between it and this appendix.

Exceptions are used both for reporting errors that occur while responding to a COUNTER_SUSHI API call and, when generating a report, for indicating that the report differs from what might be expected. While the COUNTER_SUSHI API Specification (see Section 8) defines the API methods and the JSON response formats, including the format for Exceptions, this appendix defines the permissible Exceptions, that is the Exception Codes, the corresponding Exception Messages and HTTP status codes, and how these Exceptions are expected to be used. Some of the Exceptions also can occur when generating tabular reports at an administrative/reporting site.

There are four types of errors that can occur while responding to COUNTER_SUSHI API calls:

• The base URL, for example the release, or the method is wrong, resulting in an invalid path. In this case the SUSHI server MUST respond with HTTP status code 404.

• While processing a COUNTER_SUSHI API call an error occurs that usually prohibits generating the requested report, report list, member list or server status. The SUSHI server MUST respond with the appropriate non-200 HTTP status code and a single Exception in JSON format (see below).

• The SUSHI server detects errors in a report request that can be ignored and processing can continue. The SUSHI server SHOULD continue processing the request and return HTTP status code 200 and the report in JSON format with the appropriate Exceptions in the report header.

• The report differs from what might be expected, for example the report is empty because there was no usage. In this case the report in JSON format MUST be returned with the appropriate Exceptions in the report header.

When requesting a tabular report at an administrative/reporting site, only the last type of error should occur and be included in a report. The website is expected to gracefully handle other errors that might occur while generating the report.

While only a single Exception can be returned for a non-200 HTTP status code, the Exceptions element in the report header allows to return multiple Exceptions with HTTP status code 200, both in JSON and tabular reports. If the SUSHI server detects multiple errors, including some with a non-200 HTTP status code, it MUST only return a single Exception with a non-200 HTTP status code, preferably the one with the lowest Exception Code.

The COUNTER_SUSHI API Specification defines the general JSON format for Exceptions as follows:

{
  "title": "Exception",
  "type": "object",
  "properties": {
    "Code": {
      "type": "integer",
      "description": "Exception Code. See Table D.1 in the Code of Practice, Appendix D."
    },
    "Message": {
      "type": "string",
      "minlength": 2,
      "description": "Exception Message. See Table D.1 in the Code of Practice, Appendix D."
    },
    "Help_URL": {
      "type": "string",
      "description": "URL to a help page that explains the Exception in more detail.",
      "format": "uri"
    },
    "Data": {
      "type": "string",
      "description": "Additional data provided by the server to clarify the Exception."
    }
  },
  "required": [
    "Code",
    "Message"
  ],
  "additionalProperties": false
}

For tabular reports the format for the Exceptions header is defined in Section 3.2.1 of the Code of Practice, Table 3.f, as “{Exception Code}: {Exception Message} ({Data})” with multiple Exceptions separated by semicolon-space (”; “).

As indicated in the code above, Exceptions in JSON format have the following elements:

• Code: The Code is a number that identifies the Exception. See Table D.1 below for permissible values.

• Message: The Message element contains a textual description of the Exception. For standard Exceptions with Codes > 999 the Message MUST exactly match the Message in Table D.1 below.

• Data: The Data element contains additional information that further describes the Exception. For some Exceptions this additional information MUST be provided (as indicated in Table D.1 below), for other Exceptions it is optional.

• Help_URL: An optional element that contains an URL to a help page that explains the Exception in more detail.

Table D.1 lists all permissible Exceptions. The COUNTER_SUSHI API Specification also includes this information, in the form of one Exception schema per row in Table D.1. Note that the standard Exceptions with Code > 999 MUST be used for the indicated invocation conditions, it is neither permitted to use custom Exceptions with Code <= 999 instead nor to define custom Exceptions with Code > 999.

Table D.1 (below): Exceptions

Exception Message	Exception Code	HTTP Status Code	Invocation Conditions
{Info or Debug Message}	0	200	Any. These Messages will never be standardized and service providers can design them as they see fit.
{Warning Message}	1-999	200	Any. This range is reserved for the use of service providers to supply their own custom warnings.
Service Not Available	1000	503	The service is executing a request, but due to internal errors cannot complete the request. If possible, the server should provide an explanation in the additional Data element.
Service Busy	1010	503	The service is too busy to execute the incoming request. The client should retry the request after some reasonable time.
Report Queued for Processing	1011	202	Services queueing incoming report requests must return a response with this Exception and no payload to inform the client about the processing status. The client should retry the request after some reasonable time.
Client has made too many requests	1020	429	If the service sets a limit on the number of requests a client can make within a given timeframe, the server will return this Exception when the client exceeds that limit. The server would provide an explanation of the limit in the additional Data element (e.g. “Client has made too many requests. This server allows only 500 requests per day per requestor_id and customer_id.”).
Insufficient Information to Process Request	1030	400	There is insufficient data in the request to begin processing (e.g. missing requestor_id, no customer_id, etc.).
Requestor Not Authorized to Access Service	2000	401	If requestor_id is not recognized or not authorized by the service.
Requestor is Not Authorized to Access Usage for Institution	2010	403	If requestor_id has not been authorized to harvest usage for the institution identified by the customer_id, or if the customer_id is not recognized.
Global Reports Not Supported	2011	403	Reporting to “The World”, customer_id 0000000000000000, is not supported.
APIKey Invalid	2020	401	The service requires a valid APIKey to access usage data and the key provided was not valid or not authorized for the data being requested.
Invalid Date Arguments	3020	400	Any format or logic errors involving date computations (e.g., end_date cannot be less than begin_date).
No Usage Available for Requested Dates	3030	200	The service did not find any data for the specified date range and other filters (if any). Note: If the usage for a requested month either hasn’t been processed yet or is no longer available, only Exception 3031 or 3032 must be returned for that month.
Usage Not Ready for Requested Dates	3031	200	The service has not yet processed the usage for one or more of the requested months, if some months are available that data should be returned. The Exception should include the months not processed in the additional Data element. Note: If the requested begin_date is the current or a future month, the server should return Exception 3020. If the requested end_date is the current or a future month, the server may continue processing the request and include Exception 3031, the End_Date Report_Filter then should be set to the previous month (the last month that could have been processed).
Usage No Longer Available for Requested Dates	3032	200	The service does not have the usage for one or more of the requested months because the requested begin_date is earlier than the first month for which data has been processed and is available. If some months are available that data should be returned. The Exception should include the information about the months processed and available in the additional Data element.
Partial Data Returned	3040	200	The request could not be fulfilled in its entirety, since some of the requested data is missing. The server should return the available data and provide an explanation in the additional Data element. Note: This Exception is not intended for the conditions already covered by Exceptions 3030, 3031 and 3032. A use case for this Exception for example would be that usage data is missing because the logging has failed. Usually this Exception indicates a permanent error.
Parameter Not Recognized in this Context	3050	200	The request contained one or more parameters that are not recognized by the server in the context of the report being serviced. The server should list the names of unsupported parameters in the additional Data element. Note: The server is expected to ignore unsupported parameters and continue to process the request, returning data that is available without the parameter being applied. Note: This Exception is only applicable for report requests. For report list, member list and server status requests parameters not recognized by the server should be ignored.
Invalid ReportFilter Value	3060	200	The request contained one or more filter values that are not supported by the server. The server should list the names of unsupported filter values in the additional Data element. Note: The server is expected to ignore unsupported filters and continue to process the request, returning data that is available without the filter being applied. Note: If the begin_date or end_date value is invalid, the server must return Exception 3020. If the service requires a platform parameter, and the platform value is invalid, the server should return Exception 1030.
Incongruous ReportFilter Value	3061	200	A filter element includes multiple values in a pipe-delimited list; however, the supplied values are not all of the same scope (e.g., item_id filter includes article level DOIs and journal level DOIs or ISSNs). Note: The server is expected to ignore the invalid filters and continue to process the request, returning data that is available without the filter being applied.
Invalid ReportAttribute Value	3062	200	The request contained one or more report attribute values that are not supported by the server. The server should list the names of unsupported report attribute values in the additional Data element. Note: The server is expected to ignore unsupported report attributes and continue to process the request, returning data that is available without the report attribute being applied.
Components Not Supported	3063	200	The request contained include_component_details=True, but reporting on component usage is not supported. Note: The server is expected to ignore unsupported report attributes and continue to process the request, returning data that is available without the report attribute being applied.
Required ReportFilter Missing	3070	200	A required filter was not included in the request. Which filters are required will depend on the report and the service being called. The server should list the names of the missing filters in the additional Data element. Note: If begin_date or end_date is missing, the server must return Exception 1030. If the service requires a platform parameter, and platform is missing, the server also should return Exception 1030. Note: Currently there are no other required report filters, so this Exception should not occur.

Appendix E: Audit Requirements and Tests

Note: The main Code of Practice document takes precedence in the case of any conflicts between it and this appendix.

E.1 Audit Requirements

Audits seek to mirror institutional (customer) usage on a report provider’s platform. COUNTER defines specific audit tests for each of the required reports. As report providers may work with different auditors, the audit test scripts in this appendix help ensure each auditor follows a common auditing procedure, as well as ensuring the reports comply with the Code of Practice.

There are three aspects of audit compliance

• Report delivery: Auditors test whether the COUNTER_SUSHI API has been correctly implemented for delivery of JSON reports, and whether the web interface permits retrieval of tabular reports, using the instructions supplied by the report provider.

• Format: JSON and tabular reports are reviewed by the auditor to confirm they adhere to the format and presentation specified in the Code of Practice.

• Data integrity: Metrics included in the reports are verified by the auditor to ensure they accurately record activities carried out during audit seeding. This includes

  • Checking that reports are consistent regardless of the browser used for seeding and/or accessing reports. Auditors MUST use a minimum of two different browsers for testing, one of which MUST be Chrome, Edge, Firefox, or Safari. Any browser used for testing must account for a minimum of one quarter (25%) of the overall testing.

  • Verifying whether the report provider operates a cache server, as this may result in under-reporting of seeding activity. Auditors MUST always switch off the browser cache settings of test machines.

Note that auditors are not obliged to express an opinion regarding usage reported in any other accounts/institutions, or regarding aspects of the Code of Practice not specifically tested.

Audit test requirements vary depending on the set up of the platform and any related database(s), as indicated by the Options within the tests below. For each applicable audit test to achieve an audit pass, all metrics reported MUST be within a -8% and +3% reliability window of the same audit metrics on the auditor’s report.

E.1.1 Auditor Setup

The reporting period for COUNTER is the calendar month: a report run for any given month MUST reflect all activity of a customer for the entire selected month. For the purposes of audits, auditors MUST conduct and conclude all audit tests within the seeding month.

Prior to an audit, the report provider SHOULD supply to the auditor, using either the setup form provided (PDF) or the auditor’s preferred alternative:

• Account details for at least four separate accounts with access to all areas of the site (or specific restrictions for testing Denials).

• SUSHI credentials for the test accounts to enable verification of SUSHI harvesting of JSON format reports.

• Access to download usage reports in tabular format.

• A declaration confirming federated and automated searches have been disaggregated from any searches reported.

• If server-side caching is implemented, information on cache settings used SHOULD be provided.

To prevent any collision of reported data, auditors MUST be allowed to set up and maintain separate accounts for each of the audit tests. During the seeding month, there MUST NOT be any activity on the audit accounts other than activity generated by the auditor. Any non-auditor activity on the test accounts will make the test reports unreliable and result in failure of the audit.

Unless otherwise specified the auditor MUST

• Have access to all available content on the platform.

• Allow at least 31 seconds between each metric-triggering action on the platform.

• Record the database searched (if applicable).

• Record the numbers of content items investigated or requested.

• Perform each separate test within its own separate session. Tests that are not completed within a separate session will give incorrect results, particularly where testing unique metrics such as Unique_Item_Investigations and Unique_Title_Requests.

E.1.2 Audits Where ‘Accounts’ Do Not Apply

Institutional repositories typically cannot set up or supply account details for auditors. The same may be true for purely open access publishers. Where this is the case, all audit tests MUST be run on defined and agreed IP addresses.

E.2 General Audit Tests

This section of the appendix outlines tests that MUST be run during all audits, and which are not specific to a particular COUNTER Report.

E.2.1 Validation Tool

Once reports are available for testing (i.e. up to 28 days after the end of the seeding month), auditors MUST run the COUNTER Reports and Standard Views of COUNTER Reports that are within the scope of the audit through the Validation Tool. This test must include all attributes report providers are required to support, including attributes that are included only if called for.

Where report providers have elected to follow the pre-flight preparation step outlined in Section 9 of the Code of Practice, this audit test should not result in any errors.

E.2.2 SUSHI Endpoints

The auditor MUST test the SUSHI server endpoints as follows

• The /status endpoint MUST be public (i.e. unprotected) to allow report consumers to easily check whether the service is live.

• The /reports endpoint MUST return the date range for which COUNTER Reports and the Standard Views of COUNTER Reports are available. If this is less than the required year-to-date plus two years of back data, the auditor MUST note the missing months in the audit report.

• The /members endpoint MUST return the auditor’s customer details.

Any error messages returned by the SUSHI server in the process of audit MUST be noted in the audit report, including an indication of where these error messages deviate from those specified in Appendix D.

E.2.3 Audit Tests for Double-Click Filtering

This audit test applies to investigations and requests metrics across all COUNTER Reports and should represent the scope of the platform. That is, where a platform is made up of a mixture of content with Data_Types Article, Multimedia and Patent, the auditor should represent each of those Data_Types proportionately in the audit test.

The test consists of making requests to an item twice in succession (double-clicks). If the two clicks occur within a 30-second time-span, only the second request MUST be recorded, resulting in 1 Total_Item_Investigations and 1 Total_Item_Requests. If the two clicks occur with more than 30 seconds between them, then 2 Total_Item_Investigations and 2 Total_Item_Requests must be counted. In both cases only 1 Unique_Item_Investigations and 1 Unique_Item_Requests will be reported.

The auditor MUST carry out a total of 30 tests:

• 15 Inside tests, whereby 2 identical requests are made and the second request is within 30 seconds of the first.

• 15 Outside tests, whereby 2 identical requests are made and the second request is more than 30 seconds after the first.

The Inside tests MUST result in 15 each of Total_Item_Investigations, Total_Item_Requests, Unique_Item_Investigations and Unique_Item_Requests, and the Outside tests MUST result in 30 Total_Item_Investigations, 30 Total_Item_Requests, 15 Unique_Item_Investigations and 15 Unique_Item_Requests, for a total of 45 Total_Item_Investigations, 45 Total_Item_Requests, 30 Unique_Item_Investigations and 30 Unique_Item_Requests.

Note that in the specific case of platforms offering Books and/or Reference_Works as whole-title downloads where Book_Segments and/or Reference_Items can be identified, the metric counts will deviate from those specified. The auditor MUST note the number of Book_Segments and/or Reference_Items in the titles subject to double-click tests, and the number of Total_Item_Investigations, Total_Item_Requests, Unique_Item_Investigations and Unique_Item_Requests must reflect the number of Book_Segments and/or Reference_Items in addition to any other items tested.

E.3 Audit Tests for Denials

Report providers operating platforms where turnaways or denials are in operation MUST be subject to the following audit tests for denials. For report providers operating multiple platforms, the audit scope as defined in Section 9 MUST include platforms where turnaways or denials are in operation. Where either Limit_Exceeded or No_License denials do not apply to a report provider, auditors MUST note this in the audit report. This does not require an exemption from the COUNTER Project Director.

These audit tests should represent the scope of the platform under audit. That is, where a platform is made up of a mixture of content with Data_Types Article, Multimedia and Patent, the auditor SHOULD represent each of those Data_Types proportionately in the audit test.

These audit tests apply to the Database Report, Title Report and Item Report. The DR_D2, TR_B2, and TR_J2 Standard Views of COUNTER Reports will be deemed COUNTER-compliant if the metrics match those in the relevant COUNTER Report, with the appropriate aggregation.

E.3.1 Limit_Exceeded

Note that the account used for this testing MUST have concurrent/simultaneous-user limit (concurrency limits) set at a single user. A second user attempting to access the database would be denied.

Option 1: The report provider denies the user access when the concurrency limit is exceeded upon login.

The auditor MUST force 50 Limit_Exceeded access denials by logging into the site causing the user limit to reach the maximum allowance. The auditor will then attempt to log into the site using a different computer, or a different browser, which should be refused access. Each time access is refused, the auditor will record this as 1 Limit_Exceeded.

The test MUST result in 50 Limit_Exceeded.

Option 2: The report provider denies the user access when the concurrency limit is exceeded upon searching or accessing a database.

The auditor MUST force 50 Limit_Exceeded turnaways by logging into the site, then either selecting and searching a database or browsing to a database causing the user limit to reach the maximum allowance. The auditor will then log into the same site using a different computer, or a different browser, and repeat the action, which should be refused access. Each time access is refused, the auditor will record this as 1 Limit_Exceeded.

The test MUST result in 50 Limit_Exceeded.

Option 3: The report provider denies the user access when the concurrency limit is exceeded upon accessing a content item.

The auditor MUST force 50 Limit_Exceeded turnaways by logging into the site and requesting an item, causing the user limit to reach the maximum allowance. The auditor will then log into the site again using a different computer, or a different browser, and repeat the action, which should be refused access. Each time access is refused, the auditor will record this as 1 Limit_Exceeded.

The test MUST result in 50 Limit_Exceeded.

E.3.2 No_Licence

The content for which the auditor has no license MUST be declared by the report provider prior to audit testing.

The auditor MUST force 50 No_License turnaways by logging into the site and requesting an item. Each time access is refused, the auditor will record this as 1 No_License.

The test MUST result in 50 No_License.

E.4 Audit Tests for Search Metrics

All report providers MUST be subject to the audit tests for Searches_Platform. For report providers operating multiple platforms including one or more of Host_Type A&I_Database, Aggregated_Full_Content, Discovery_Service, eBook_Collection, Full_Content_Database or Multimedia_Collection, the audit scope as defined in Section 9 MUST include one of these platforms and be subject to the audit tests for Searches_Automated and Searches_Regular.

Audit test requirements vary depending on the set up of the platform, as indicated by the Options within the tests below.

E.4.1 Searches_Platform

These tests are specific to the Platform Report. The PR_P1 Standard View of the Platform Report will be deemed COUNTER-compliant if the metrics match those in the Platform Report, with the appropriate aggregation.

Option 1: Platform has multiple databases and the user can search the whole platform, multiple selected databases, or a single database.

The auditor MUST run 100 searches on the platform

• 50 searches against only 1 selected database.

• 25 searches against 2 selected databases.

• 25 searches against all databases on the platform.

The auditor activity MUST result in 100 Searches_Platform (1 per search).

Option 2: Platform has multiple databases and the user can search the whole platform or a single database.

The auditor MUST run 100 searches on the platform

• 50 searches against only 1 selected database.

• 50 searches against all databases on the platform.

The auditor activity MUST result in 100 Searches_Platform (1 per search).

Option 3: Platform has multiple databases but the user can only search the whole platform OR the platform has just one database.

The auditor MUST run 100 searches on the platform.

The auditor activity MUST result in 100 Searches_Platform (1 per search).

Option 4: Platform has multiple databases but the user can only search a single database at a time.

The auditor MUST run 100 searches across at least 10% of the available databases, restricted to one database at a time.

The auditor activity MUST result in 100 Searches_Platform (1 per search).

Option 5: Platform does not include any databases.

The auditor MUST run 100 searches on the platform.

The auditor activity MUST result in 100 Searches_Platform (1 per search).

E.4.2 Searches_Regular and Searches_Automated

These tests are specific to the Database Report. The DR_D1 Standard View of the Database Report will be deemed COUNTER-compliant if the metrics match those in the Database Report, with the appropriate aggregation.

Option 1: Platform has multiple databases and the user can search the whole platform, multiple selected databases, or a single database.

The auditor MUST run 100 searches on the platform

• 50 searches against only 1 selected database, resulting in 50 Searches_Regular against that database.

• 25 searches against 2 selected databases, resulting in 25 Searches_Regular against both databases.

• 25 searches against all databases on the platform, resulting in 25 Searches_Regular against every database.

Option 2: Platform has multiple databases and the user can search the whole platform or a single database.

The auditor MUST run 100 searches on the platform

• 50 searches against only 1 selected database, resulting in 50 Searches_Regular against that database.

• 50 searches against all databases on the platform, resulting in 50 Searches_Regular against every database.

Option 3: Platform has multiple databases but the user can only search the whole platform.

The auditor MUST run 100 searches, resulting in 100 Searches_Automated (1 per search).

Option 4: Platform has multiple databases but the user can only search a single database at a time.

The auditor MUST run 100 searches across at least 10% of the available databases, restricted to one database at a time, resulting in 100 Searches_Regular (1 per search).

Option 5: Platform has only one database.

The auditor MUST run 50 searches, resulting in 50 Searches_Regular (1 per search).

E.5 Audit Tests for Investigations and Requests for Books and Reference_Works

This section of the appendix outlines tests that MUST be run during audits for any platform delivering Book and/or Reference_Work content. For report providers operating multiple platforms including one or more with Book and/or Reference_Work content, the audit scope as defined in Section 9 MUST include one of these platforms and be subject to the audit tests outlined here. Note that these tests refer to Data_Types Book and Book_Segment for ease of reading. In all cases, Book includes Data_Types Book and Reference_Work, while Book_Segment includes Data_Types Book_Segment and Reference_Item.

These tests apply to the Platform Report, Database Report, Title Report and Item Report. The counts specified in the tests are those required for the Title Report and Item Report, which must be aggregated appropriately for the Platform Report and Database Report where multiple Access_Types are present on the platform under test. The PR_P1, DR_D1, TR_B1 and TR_B3 Standard Views of the COUNTER Reports will be deemed COUNTER-compliant if the metrics and Data_Types match those in the relevant COUNTER Report, with the appropriate aggregation.

Unique_Title_Investigations and Unique_Title_Requests are referenced in these audit tests. These MUST NOT appear in the Item Report.

These audit tests specify minimum numbers of Books and Book_Segments to be tested. Where a platform has fewer than the required number of Books, the auditor MUST make at least one request for each Book on the platform, and where necessary undertake duplicate actions to reach the required threshold.

Audit test requirements vary depending on the set up of the platform, as indicated by the Options within the tests below.

E.5.1 Books Available as Book_Segments

These tests apply where users can access books segment-by-segment.

Where possible, 50% of items requested SHOULD be via browsing the platform and 50% via searching the platform. If either browsing or searching is not possible, all items can be requested via the only available option.

Option 1: Report provider offers Book_Segments under only one Access_Type.

The auditor MUST request 70 Book_Segments across 7 different Books.

This MUST result in 70 each of Total_Item_Investigations, Total_Item_Requests, Unique_Item_Investigations and Unique_Item_Requests, and 7 each of Unique_Title_Investigations and Unique_Title_Requests with the appropriate Access_Type.

Option 2: Report provider offers Book_Segments under two different Access_Types.

The auditor MUST request 50 Book_Segments across 5 different Books, from each Access_Type represented on the platform.

This MUST result in 50 each of Total_Item_Investigations, Total_Item_Requests, Unique_Item_Investigations and Unique_Item_Requests, and 5 each of Unique_Title_Investigations and Unique_Title_Requests with each Access_Type.

The Access_Type combinations might be: Controlled plus Open, Controlled plus Free_To_Read, or Open plus Free_To_Read.

Option 3: Report provider offers Book_Segments under all three Access_Types (Controlled, Open and Free_To_Read).

The auditor MUST request

• 40 Book_Segments across 4 different Books with Access_Type Controlled.

• 40 Book_Segments across 4 different Books with Access_Type Open.

• 20 Book_Segments across 2 different Books with Access_Type Free_To_Read.

This MUST result in 40 each of Total_Item_Investigations, Total_Item_Requests, Unique_Item_Investigations and Unique_Item_Requests, and 4 each of Unique_Title_Investigations and Unique_Title_Requests with Access_Type Controlled; the same again for Access_Type Open; and 20 each of Total_Item_Investigations, Total_Item_Requests, Unique_Item_Investigations and Unique_Item_Requests, and 2 each of Unique_Title_Investigations and Unique_Title_Requests with Access_Type Free_To_Read.

E.5.2 Books Available as Whole Books Where Book_Segments Can Be Identified

These tests apply where books are available as whole-books downloads, and Book_Segments can be identified for reporting purposes.

Where possible, 50% of items requested SHOULD be via browsing the platform and 50% via searching the platform. If either browsing or searching is not possible, all items can be requested via the only available option.

Option 1: Report provider offers whole Books with identifiable Book_Segments under only one Access_Type.

The auditor MUST request 50 whole Books, noting the count of Book_Segments from each Title.

This MUST result in the sum of Book_Segments of each of Total_Item_Investigations, Total_Item_Requests, Unique_Item_Investigations and Unique_Item_Requests, and 50 each of Unique_Title_Investigations and Unique_Title_Requests with the appropriate Access_Type.

Option 2: Report provider offers whole Books with identifiable Book_Segments under two different Access_Types.

The auditor MUST request 30 whole Books, noting the count of Book_Segments, for each Access_Type.

This MUST result in the sum of Book_Segments of each of Total_Item_Investigations, Total_Item_Requests, Unique_Item_Investigations and Unique_Item_Requests, and 30 each of Unique_Title_Investigations and Unique_Title_Requests, for each of the two Access_Types.

The Access_Type combinations might be: Controlled plus Open, Controlled plus Free_To_Read, or Open plus Free_To_Read.

Option 3: Report provider offers whole Books with identifiable Book_Segments under all three Access_Types (Controlled, Open and Free_To_Read).

The auditor MUST request 20 whole Books, noting the count of Book_Segments from each Title, for each Access_Type

This MUST result in the sum of Book_Segments of each of Total_Item_Investigations, Total_Item_Requests, Unique_Item_Investigations and Unique_Item_Requests, and 20 each of Unique_Title_Investigations and Unique_Title_Requests, for each of the Access_Types.

E.5.3 Books Available as Whole Books Where Book_Segments Cannot Be Identified

These tests apply where Books are only available as single downloads and it is not possible to identify Book_Segments.

Where possible, 50% of items requested SHOULD be via browsing the platform and 50% via searching the platform. If either browsing or searching is not possible, all items can be requested via the only available option.

Option 1: Report provider offers whole Books without identifable Book_Segments under only one Access_Type.

The auditor MUST request 25 Books.

This MUST result in 25 each of Total_Item_Investigations, Total_Item_Requests, Unique_Item_Investigations, Unique_Item_Requests, Unique_Title_Investigations and Unique_Title_Requests with the appropriate Access_Type.

Option 2: Report provider offers whole Books without identifable Book_Segments under two different Access_Types.

The auditor MUST request 25 Books with each Access_Type.

This MUST result in 25 each of Total_Item_Investigations, Total_Item_Requests, Unique_Item_Investigations, Unique_Item_Requests, Unique_Title_Investigations and Unique_Title_Requests with each Access_Type.

The Access_Type combinations might be: Controlled plus Open, Controlled plus Free_To_Read, or Open plus Free_To_Read.

Option 3: Report provider offers whole Books without identifable Book_Segments under all three Access_Types (Controlled, Open and Free_To_Read).

The auditor MUST request 20 Books of each Access_Type.

This MUST result in 20 each of Total_Item_Investigations, Total_Item_Requests, Unique_Item_Investigations, Unique_Item_Requests, Unique_Title_Investigations and Unique_Title_Requests for each Access_Type.

E.5.4 Investigations Independent of Requests

These audit tests applies where Investigations can be reported independently of Requests. If all Investigations have a matching Request, auditors MUST note this in the audit report. This does not require an exemption from the COUNTER Project Director.

The tests mimic those defined above, but the auditor MUST undertake a separate Investigation activity for each audit test, resulting in a doubling of the Total_Item_Investigation counts.

E.6 Audit Tests for Investigations and Requests for Other Data_Types

This section of the appendix outlines tests that MUST be run during audits for any platform delivering any Data_Type that is not Book or Reference_Work content. For report providers operating multiple platforms including one or more with non-Book or Reference_Work content, the audit scope as defined in Section 9 MUST include one of these platforms and be subject to the audit tests outlined here. Note that these tests refer to ‘item’ for ease of reading, without specifying Data_Type.

These tests apply to the Platform Report, Database Report, Title Report and Item Report. The counts specified in the tests are those required for the Title Report and Item Report, which must be aggregated appropriately for the Platform Report and Database Report where multiple Access_Types are present on the platform under test. The PR_P1, DR_D1, TR_J1, TR_J3, TR_J4 and IR_A1 Standard Views of the COUNTER Reports will be deemed COUNTER-compliant if the metrics and Data_Types match those in the relevant COUNTER Report, with the appropriate aggregation.

These audit tests specify minimum numbers of items to be tested. Where a platform has fewer than the required number of items, the auditor MUST make at least one request for each item on the platform, and where necessary undertake duplicate actions to reach the required threshold.

Audit test requirements vary depending on the set up of the platform, as indicated by the Options within the tests below.

E.6.1 Access Types

Where possible, 50% of items requested SHOULD be via browsing the platform and 50% via searching the platform. If either browsing or searching is not possible, all items can be requested via the only available option.

Option 1: Report provider offers items under just one Access_Type.

The auditor MUST request 100 items.

This MUST result in 100 each of Total_Item_Investigations, Total_Item_Requests, Unique_Item_Investigations and Unique_Item_Requests with the appropriate Access_Type.

Option 2: Report provider offers items under two Access_Types.

The auditor MUST request 50 items with each Access_Type.

This MUST result in 50 each of Total_Item_Investigations, Total_Item_Requests, Unique_Item_Investigations and Unique_Item_Requests with each Access_Type.

The Access_Type combinations might be: Controlled plus Open, Controlled plus Free_To_Read, or Open plus Free_To_Read.

Option 3: Report provider offers items under all three Access_Types (Controlled, Open and Free_To_Read).

The auditor MUST request

• 40 items with Access_Type Controlled.

• 40 items with Access_Type Open.

• 20 items with Access_Type Free_To_Read.

This MUST result in 40 each of Total_Item_Investigations, Total_Item_Requests, Unique_Item_Investigations and Unique_Item_Requests with Access_Type Controlled; the same again for Access_Type Open; and 20 each of Total_Item_Investigations, Total_Item_Requests, Unique_Item_Investigations and Unique_Item_Requests with Access_Type Free_To_Read.

E.6.2 Investigations Independent of Requests

These audit tests applies where Investigations can be reported independently of Requests. If all Investigations have a matching Request, auditors MUST note this in the audit report. This does not require an exemption from the COUNTER Project Director.

The tests mimic those defined above, but the auditor MUST undertake a separate Investigation activity for each audit test, resulting in a doubling of the Total_Item_Investigation counts.

E.6.3 Year of Publication

Year of publication (YOP) is useful in evaluating usage of archive content for Data_Types that can be published serially, namely:

• Conference/Conference_Item

• Journal/Article

• Newspaper_or_Newsletter/News_Item

The auditor MUST confirm the YOP of items covered in other audit tests described above, with appropriate and proportionate spot checks covering a minimum of 20% of all items tested from the relevant Data_Types. If an Item Report is provided the YOP checks should occur in that COUNTER Report, otherwise the aggregated counts in the Title Report should be used (i.e. to ensure that YOPs of tested items appear in the Title Report, without any other YOPs).

If the YOP appearing in the COUNTER Reports is different from that of the item for more than 10% of the checked items, the auditor must expand their spot checks to cover at least 40% of tested items. If 10% or more of the items have a different YOP from that in the COUNTER Reports, the report provider has failed the YOP audit test. To use the example of audit tests under Option 1 above:

• 100 items are subject to audit tests.

• 20 of these are checked to ensure the YOP matches between the item and the COUNTER Report, of which 3 are found to conflict.

• An additional 20 items are checked to ensure the YOP matches between the item and the COUNTER Report.

• If a total of 4 YOPs do not match between the item and the COUNTER Report, the audit test is failed.

Appendix F: List of Federated Search Products

Note: The main Code of Practice document takes precedence in the case of any conflicts between it and this appendix.

The following are lists of known (to COUNTER) federated search products and user-agent values that may be used to identify federated search activity for reporting as Searches_Federated in Database Reports.

NOTE: These lists are for reference purposes only and may not represent all current Federated Search Products (please contact COUNTER with updates).

Table F.1: Federated Search Products

Federated Search Product	Vendor
360 Search	ProQuest
EBSCOhost Integrated Search	EBSCO Information Services
Enterprise (Federated Search)	SirsiDynx
EOS.Web	EOS (SirsiDynx)
MetaLib	ProQuest (Ex LIbris)
SEARCHit	Auto-Graphics

Table F.2: Federated Search Agent “User Agent” values

Federated Search User Agent
AGENTPORT-SCOCIT
AGENTPORT-SDICIT
AHMKEYS-SCOCIT
AHMKEYS-SCOFUL
ARCHIMINC-SCOCIT
ARCHIMINC-SDICIT
CITAVI-SCOCIT
CITAVI-SDICIT
COSMADRALI-SCOCIT
COSMADRALI-SDICIT
DEEPEX-SCOCIT
DEEPEX-SDIABS
DEEPEX-SDICIT
EDINGET-SCOCIT
EDINGET-SDICIT
ENCOMP-SCOCIT
ENCOMP-SDIABS
ENCOMP-SDICIT
GROGRO-SDICIT
HENKINTRA-SCOCIT
INERAEX-SCOCIT
INTELLIFED-SCOCIT
INTELLIFED-SDICIT
MEKPAPERS-SCOCIT
MEKPAPERS-SDICIT
METALIB-SCOCIT
METALIB-SDICIT
MUSESEARCH-SCOCIT
MUSESEARCH-SDICIT
NJIT-SCOCIT
NRLNAVY-SCOCIT
OCLCPICAZ2-SCOCIT
OCLCPICAZ2-SDICIT
OOIPSDWID-SDICIT
POTIRORDY-SCOCIT
POTIRORDY-SDICIT
QES-SCOCIT
QES-SDICIT
QINETIQ-SCOCIT
RIGHTS-SDIABS
RITENSE-SCOCIT
SERSOL-SCOCIT
SERSOL-SDICIT
SYSONEMCKIN-SCOFUL
SYSONEMCKIN-SDIABS
TDNETDF-SCOCIT
TDNETDF-SDICIT
TDNSRCHR-SCOCIT
TDNSRCHR-SDICIT
UAG-SCOCIT
UMIARERES-SCOCIT
UWASOCR-SCOCIT
UWASOCR-SCOFUL
VSPACES-SCOCIT
VSPACES-SDICIT
WEBFEAT-SCOCIT
WEBFEAT-SDICIT

Appendix G: Sample COUNTER Reports and Standard Views of the COUNTER Reports

Note: The main Code of Practice document takes precedence in the case of any conflicts between it and this appendix.

The COUNTER Reports and Standard Views of the COUNTER Reports in the following table are organized by reporting level with Platform first followed by Database, Title and ending with Item. Within the reporting level, the COUNTER Report appears first followed by the Standard Views of the COUNTER Report. Click the TSV and JSON links to download the corresponding sample reports.

Note that the sample reports provided here include all Data_Types. This has created some unusual situations; for example, Book_Segment and Book both appear in the Platform Report. In practice Book_Segment would appear in the Platform Report for Host_Types Repository and Scholarly_Collaboration_Network, while Book would appear in the Platform Report for Host_Types A&I_Database, Aggregated_Full_Content, Discovery_Service, eBook, and eBook_Collection.

Table G.1: Sample COUNTER Reports and Standard Views of the COUNTER Reports

Report_ID	Report_Name	Sample Report
PR	Platform Report	JSON TSV Excel
PR_P1	Platform Usage	JSON TSV Excel
DR	Database Report	JSON TSV Excel
DR_D1	Database Search and Item Usage	JSON TSV Excel
DR_D2	Database Access Denied	JSON TSV Excel
TR	Title Report	JSON TSV Excel
TR_B1	Book Requests (Controlled)	JSON TSV Excel
TR_B2	Book Access Denied	JSON TSV Excel
TR_B3	Book Usage by Access Type	JSON TSV Excel
TR_J1	Journal Requests (Controlled)	JSON TSV Excel
TR_J2	Journal Access Denied	JSON TSV Excel
TR_J3	Journal Usage by Access Type	JSON TSV Excel
TR_J4	Journal Request by YOP (Controlled)	JSON TSV Excel
IR	Item Report	JSON TSV Excel
IR_A1	Journal Article Requests	JSON TSV Excel
IR_M1	Multimedia Item Requests	JSON TSV Excel

Appendix H: List of internet robots, crawlers and spiders

Note: The main Code of Practice document takes precedence in the case of any conflicts between it and this appendix.

The growing use of internet robots, crawlers and spiders has the potential to artificially inflate usage statistics. Only genuine, user-driven usage should be reported in COUNTER usage reports. Usage of full text articles that is initiated by automatic or semi-automatic bulk download tools, such as RightFind or PubHive should only be recorded when the user has clicked on the downloaded full-text article in order to open it.

Activity generated by internet robots, crawlers and spiders must be excluded from all COUNTER usage reports.

This list of internet robots, crawlers and spiders was published in April 2016 and last updated March 2023. Please note it is rationalised, removing some previously redundant entries (e.g. the text ‘bot’ - msnbot, awbot, bbot, turnitinbot, etc. - which is now collapsed down to a single entry ‘bot’).

The list is displayed below and also available on the COUNTER Robots repository.

This page will always show the readme and give potential users and contributors of the list more information on how to integrate the list.

For further information on regular expression matching, see Regular expressions.

Please let us know of any user agents that should be included in this list or to suggest other amendments.