Archived CoP 5.0.1 Amendments

Dated 12 July 2019

We have received several questions from content providers and auditors about when and how to count searches, especially about when to count searches as regular or automated.

We have also noticed that the definitions of Searches_Regular and Searches_Automated have been interpreted in differently: Searches are counted as Searches_Regular either if (1) the user has the option to select the databases being searched or (2) the user actually has selected the databases being searched.

While (2) would provide additional insight into how the databases are used, there are two problems with this approach; the first is that searches can occur in many scenarios, and it would be very difficult or even impossible to find a definition of what “the user actually has selected the databases” means, which would be consistent and comparable across content providers. Secondly, tracking how the databases have been selected would be a challenge and require significant changes for many content providers which usually have counted the Regular Searches in Release 4 according to (1). Therefore, we intend to clarify the definitions in section 3.3.4 of the Code of Practice and the Glossary as follows:

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.

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 tracked at the database level and is not represented at the platform level.

Dated 11 December 2018

The Section_Type element and filter are removed from the Item Master Report (IR). IR reports on the item level, therefore Data_Type already describes the content unit.

An Include_Parent_Details report attribute is added for Master Report (IR). With this attribute the Parent elements can be handled in the same way as the Component elements.

New Exceptions: 1011 (Report Queued for Processing) and 3032 (Usage No Longer Available for Requested Dates).

Dated 23 October 2018

In answer to queries we have received regarding the amendment to the Code of Practice posted in September (https://www.projectcounter.org/amendments-clarifications-code-practice-release-5/ ), we clarify that denials should not be counted as Investigations. However, link-outs can be counted as Investigations providing the target of such link-outs offer access to the content item or detailed information about the content item. Example of qualifying targets include: content item at publisher/other content sites; OpenURL link resolver; ILL or Document Delivery request form; library catalog or A-to-Z link; metadata/analysis sites such as PubMed, PlumAnalytics, Altmetrics.

While the intent of the previous amendment to the CoP related to investigations and link-outs was to concerns of that some link-outs may lead to double-counting of investigations for a given title, (e.g. a user clicks a link in one site that leads to full text in another, both sites would be able to record the “investigation” against the title), it had the undesired effect of eliminating a valuable tool of measuring the value of non-full text database, like PsycInfo. If the online search site was not allowed to count a user’s “clicks” while using PsycInfo, this would greatly reduce the apparent “usage” of the database when compared to R4 Result_Clicks.  We have thus amended the amendment to allow link-outs the lead to the content item or detailed information about the content item to be counted as investigations.

Dated 10 September 2018

In response to the questions and comments COUNTER has received from Content Providers implementing Release 5 of the COUNTER Code of Practice, the following amendments and clarifications have been made. The Code of Practice will shortly be updated to reflect these changes.

Unique_Titles

The Unique_Titles metrics are only intended for Books and must not be calculated for other Data_Types as they are not meaningful for them. A Unique_Title is defined as the unique combination of:

• User_Session
• Book
• Access_Type

Note that Section_Type is not involved in calculating a Unique_Title.  COUNTER recognizes that in rare cases, a book may contain both OA_Gold and Controlled sections and acknowledge that this could inflate counts in cases where a user has requested a Master Report for all Access_Types where counts are summarized by Access_Type. The acknowledgement is made with the understanding that it is not viable for reporting systems to calculate Unique_Titles at run-time.

Do denials count as investigations or do only successful investigations count?

Only successful Investigations must be counted. Please note that one user action might result in both a Denial and an Investigation being counted when access to full text is denied (Denial) and the user then is redirected to an abstract (Investigation).

Note that for simplicity and accuracy, return codes 200 and 304 must be counted as Investigations or Requests, based on the content being accessed.

Requests for content that generate return codes 401, 402, and 403 or their semantic equivalent must be counted as Access Denied.

Link outs

Given the definition of ‘Investigation’ in the Glossary and the requirement for a return code of 200 or 304 for something to be counted, clicks such as those required for ILL or Link Resolvers should not be counted. Even if they could be counted as Investigations within current guidelines, doing so would result in double counting – one count at the referring database and a second at the hosting platform – which breaches one of COUNTER’s core principles.

COUNTER will look at the possibility of extending the Code of Practice to include link out (and maybe also link in) metrics once Release 5 has been rolled out.

Access_Type and YOP in Database and Platform Reports

Access_Type and YOP attributes and the corresponding filters will be removed from the Master Database and Master Platform Reports, because of the problems they cause with the Searches metrics.

There will be no changes for the Access_Type and YOP attributes and the corresponding filters in the Title and Item Reports.

Host_Type Full_Content_Database

We will add a Host_Type Full_Content_Database for non-aggregated full content databases, i.e. databases that are a collection of content items that are not otherwise part of a serial or monograph (so they cannot support Title Reports for Journals or Books). An example is Cochrane Library. This will make it easier to distinguish the different types of content providers in terms of reporting Data_Type:

For the Host_Type Full_Content_Database

Investigations and Requests must be reported with Data_Type Database.

For the Host_Types Aggregated_Full_Content and A&I_Database

Investigations and Requests must be reported with the title-level Data_Types (e.g. Journal for a journal article).

This applies to all reports that must be provided.

Double-clicks for Searches

Double-click filtering applies to all Metric _Types except for searches.