3.0 Technical Specifications for COUNTER Reports

3.1 COUNTER Reports for Libraries

Reports for R5 consist of four Master Reports that allow the librarian to filter and configure to create customized views of their usage data. R5 also specifies Standard Views (pre-set filters/configuration).

To achieve compliance, a content provider MUST offer the Master Reports and Standard Views 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.

Content providers may offer additional Master Reports and Standard Views 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 isn’t required.

3.1.1 Master Reports

Master Reports include all relevant metrics and attributes; they are intended to be customizable through the application of filters and other configuration options, allowing librarians to create a report specific to their needs. The four Master 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): Master Reports

*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.

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

3.1.2 Standard Views

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

3.1.2.1 Platform Usage Standard Views

The Platform Usage Standard Views are derived from the Platform Master Report and 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.

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

*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.

See Section 4.1 below for details on Platform Usage Reports.

3.1.2.2 Database Usage Standard Views

The Database Usage Standard Views 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): Database Usage Standard Views

See Section 4.2 below for details on Database Usage Reports.

3.1.2.3 Title Usage Standard Views

Title Usage Standard Views 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): Title Usage Standard Views

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

3.1.2.4 Item Usage Standard Views

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

Table 3.e (below): Item Usage Standard Views

See Section 4.4 below for details on Item Usage Reports.

3.2 Formats for COUNTER Reports

R5 reports can be delivered in tabular form or as machine-readable data (JSON) via the COUNTER_SUSHI API. The tabular form MUST be either Excel or a tab-separated-value (TSV) file. The reports in JSON and TSV format MUST be encoded using UTF-8. The JSON format MUST comply with the COUNTER_SUSHI API Specification (see Section 8 below).

All COUNTER reports have the same layout and structure. Figure 3.b (below) provides an example of the “Journal Requests (Excluding OA_Gold)” Standard View. 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 “Journal Requests (Excluding OA_Gold)” Standard View

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.

3.2.1 Report Header

The first 12 rows of a tabular COUNTER report contain the header, and the 13th 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 12 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

3.2.2 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 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

Platform

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

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

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

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

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 Master Reports. Note that 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.

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

Item and Report Attributes

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

Metric Type

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

Usage Data

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

3.3 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 expands the scope of COUNTER into the area of research data and social media. In order to help organize this increased scope in a single, consistent, and coherent Code of Practice, several new elements and attributes have been added.

3.3.1 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, the R5 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 content 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

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.

3.3.2 Data Types

R5 reports on scholarly information in many ways. These major groupings, referred to as Data_Types, are listed in the table below along with the Host_Types and reports that they apply to. All Data_Types apply to the Platform Reports since they summarize the usage on the platform. Note that the table lists only Host_Types required to provide one or more reports for compliance, but that content providers may offer additional reports. For example, Host_Type eJournal might also offer IR and IR_A1 and would then use Data_Type Article in these reports.

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

*Full_Content_Databases may also use Data_Type Database in the Master Title Report if this report is offered. All other Host_Types MUST report Investigations and Requests either with the title-level Data_Types (e.g. Journal for a journal article or Book for a book, from Host_Type A&I_Database, Aggregated_Full_Content, Discovery_Service, eBook, eBook_Collection and eJournal), or with the item-level Data_Types (e.g. Article for an article or Multimedia for a video from Host_Type Data_Repository, Multimedia, Multimedia_Collection, Repository and Scholarly_Collaboration_Network). These Data_Types MUST be used across all reports required for compliance to ensure a consistent reporting.

3.3.3 Section Types

Some scholarly content is accessed in sections. For example, a user may access a chapter or section at a time. Section_Type was introduced to provide a categorization of the transaction based on the type of section accessed. For example, a librarian could use a Title Master Report to see a breakdown of usage by Title and Section_Type. The following table lists the Section_Types defined by COUNTER and the Host_Types and reports to which they apply.

Table 3.q (below): List of Section_Type Values

3.3.4 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

*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 3e: The relationship between Investigations and Requests

Totals, Unique Items and Unique Titles

R5 also introduces the concept of unique items and unique titles. The Metric_Types that begin with Total are very similar to the metrics of R4, i.e. if a given article or book or book chapter was accessed multiple times in a user session, the metric would increase by the number of times the content item was accessed (minus any adjustments for double-clicks).

Unique_Item metrics have been introduced in R5 to help eliminate the effect different styles of user interfaces may have on usage counts. With R5, 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.

Unique_Title metrics have been introduced in R5 to help normalize eBook metrics. Since eBooks can be downloaded as an entire book in a single PDF or as separate chapters, the counts for R4’s BR1 (book downloads) and BR2 (section downloads) are not comparable. With R5, the book’s Unique_Title metrics are only increased by 1 no matter how many (or how many times) chapters or sections were accessed in a given user session. Unique_Title metrics provide comparable eBook metrics regardless of the nature of the platform and how eBook content was delivered.

The Unique_Title metrics MUST NOT be used for Data_Types other than Book as they are not meaningful for them. If a book contains both OA_Gold 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

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

Access Denied

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

3.3.5 Access Types

In order to track the value of usage for licensed content, librarians want to know how much Open Access or other freely available content was used and how much content was behind a paywall. To accommodate this R5 has introduced an Access_Type attribute with values of Controlled, OA_Gold, OA_Delayed, and Other_Free_To_Read. The table below lists the Access_Types and the Host_Types and reports they apply to. Note that Access_Type relates to access on the platform where the usage occurs: if access to a Gold Open Access article 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.

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

3.3.6 Access Methods

In order to track content usage that was accessed for the purpose of text and data mining (TDM) and to keep that usage separate from normal usage, R5 introduces 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

3.3.7 YOP

Analyzing collection usage by the age of the content is also desired. The YOP usage 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

3.3.8 Report Filters and Report Attributes

Customized views of the usage data are created by applying report filters and report attributes to the Master Reports. The Standard Views specified by R5 are examples of such views. Report attributes define the columns (elements) and report filters the rows (values) included in the reports. For Master Reports the user can choose from specific sets of filters and attributes depending on the report, while for Standard Views 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 name/value pairs in the Report_Filters and Report_Attributes elements 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 method 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

Table 3.y (below): Report Filters

3.3.9 Zero Usage

Not all content providers or other COUNTER report providers link their COUNTER reporting tool to their subscription database, so R5 reports cannot include zero-usage reporting based on subscription records. Inclusion of zero-usage reporting for everything, including unsubscribed content, could make reports unmanageably large. The need for libraries to identify subscribed titles with zero usage will be addressed by the KBART Automation Working Group initiative.

• 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 any Instance element with a Count of zero.
  • Omit Performance elements that don’t have at least one Instance element.
  • Omit Report_Items elements that don’t have at least one Performance element.

3.3.10 Missing and Unknown Field Values

• For tabular reports
  • If a field value is missing or unknown (e.g. the ISBN for a title doesn’t exist or isn’t known), the field MUST be left blank. For clarity, the field MUST NOT contain values such as “unknown” or “n/a”.
• For JSON reports
  • If the value of a field is missing or unknown and the COUNTER_SUSHI API Specification (see Section 8 below) indicates the field is REQUIRED, the value of the field MUST be expressed as empty as appropriate for the data type.
  • If the value of a field is missing or unknown and the field is not REQUIRED according to the COUNTER_SUSHI API Specification, the field MUST be omitted from the response.