Improving open access (OA) reporting was one of our major objectives for R5.1. That meant we needed to ensure usage is always reported at the level of the item. That was already happening for most types of content. Usage for journals, databases, multimedia and so on is still reported in the same way as it has been historically. However, reporting at the level of the Item does affect some book metrics, including books that are classed as reference works (e.g. encyclopedias).

Book Metrics

Book usage is reported using both Item and Title metrics. The Title metrics are not affected by the move to item-level reporting, but the Item metrics are.

Let’s take a scenario where a publisher platform offers books on a chapter-by-chapter basis, as well as journal articles. A user has elected to download a full ten-chapter book plus ten journal articles. In Release 5 the publisher couldn’t report the usage of those chapters independently. With item-level reporting in place for R5.1, the publisher can accurately report usage of chapters. The way that book-level Title usage metrics are reported hasn’t changed, so there’s no usage ‘inflation’. Take a look at the table below to see how it works.

Section Types

A knock-on effect of the move to item-level reporting is that the old Section Type Attribute is no longer useful. In R5, Data Type often referred to the title or database container for a piece of content. For example, journal articles often had Data Type Journal. In R5.1, we have clarified that Data Type refers to the Item, and Parent Data Type to the container for that Item. For example, book usage in R5 would be reported against Data Type Book, Section Type Chapter in the Item Report. The Item Reports also offered the concept of Parent Data Types and Components (e.g. a video embedded within a book chapter), allowing up to four tiers of granularity. That meant R5 reports often used Section Type to refer to the Item.

In R5.1, we’ve got rid of the overlap between Data and Section Types. Using our book example: Parent Data Type Book, Data Type Book Segment, Component Audiovisual. The Parent Data Type always applies to the container, and it’s what you should expect to see in the Platform, Database, and Title Reports.

As well as clarifying how Data Type should be used, for R5.1 we also expanded the list of Data Types and edited some confusing Data Type definitions. Data Type is now mandatory in all four main COUNTER Reports. This will make it easier for publishers to report granular usage information and for libraries to compare usage across publishers and over time.

By expanding the list of Data Types we have changed what is reported in some of the Standard Views of COUNTER Reports. For example, publishers who adopt the new Conference Data Type won’t report usage of conference proceedings in the TR_J1 Standard View. This is resolved by using the Title Report instead of the Standard View, as the Title Report can be easily filtered to show the Data Types. If you aren’t sure which report is right for you, check out the Why Not To Use Standard Views guide.

Where Access Types Apply

In earlier releases of the Code of Practice we weren’t clear enough about where COUNTER Access Types apply. In R5.1 we introduced some principles for Access Types:

• The Access Type you’ll see in a COUNTER Report only relates to the platform producing the report. That means an OA book in a database that is only available to subscribers will be reported as Controlled.
• An Item can only have one Access Type. That means if a journal article has freely available metadata but restricts the full text for subscribers, all usage of that article needs to be reported as Controlled.

What The Access Types Are

We also thought the R5 Access Type definitions were a bit confused, and only two (Controlled and OA Gold) were in common use. For R5.1 we wanted to avoid describing OA by referencing a business model or a specific type of OA license. We also needed to help publishers report on usage of free to read content that isn’t OA. After many months of discussion, and feedback from the community through the R5.1 consultation, we agreed on three Access Types:

• Controlled. Material that is only available to authorized users (e.g. subscribers or registered users).
• Open. Any content item that the publisher asserts is OA, no matter what the license is or whether the item was originally Controlled (e.g. until after an embargo).
• Free To Read. Materials that are temporarily freely available to everyone (e.g. special collections of coronavirus papers during the early days of the Covid pandemic).

What The Changes Mean

The main impact here is on the TR_B1, TR_J1 and TR_J4 Standard Views of the Title Report. Historically these Standard Views only excluded OA chapters or articles. In R5.1, they also exclude Free To Read book and journal content. You can still see all of that Free To Read and Open usage by using the Title Report, which can be easily filtered by Access Type.

It’s useful to know that the principles behind Access Types, combined with our definition of Open, means publishers who make materials freely available (sometimes called ‘bronze’ OA) will be able to report their usage as Open instead of Controlled, as was previously the case.

Librarians often tell us that they are not sure if their reports are being provided by COUNTER-compliant publishers, or just look like they are. We made it easier to check by asking publishers to include a link to their record in the COUNTER Registry. The Registry gives details of every platform that offers audited, COUNTER-compliant usage reports. If you’re looking at a report for a platform that isn’t in the Registry, you aren’t looking at a COUNTER report.

COUNTER API (Formerly Sushi)

There are two obvious changes here. The first is that we’re calling it the COUNTER API, and not using the old ‘sushi’. The second is that from R5.1, the Code of Practice release number will be included in the API’s URL (e.g. https://usage.reporting/counter/r51).

There are some security changes, too: we dropped IP-based authentication for COUNTER API services to make the API more robust. Publishers can choose to implement API Key authentication if they want a replacement.

Lastly, there are some changes to the API endpoints:

• /status is public, so you can easily check whether a specific service is live.
• /reports was expanded to show information about the first and last months for which data are available.
• New parameters were introduced to cover the common extensions to COUNTER reports.

JSON

The JSON schema for R5.1 uses OpenAPI3.1 and is more compact than the old schema, so the files are easier to produce, validate, and use. That meant we were able avoid duplicate item and parent metadata, simplify the Performance structure, and simplify value lists. We’ve also made sure that the JSON and tabular reports match by removing some extra fields that only appeared in JSON reports, making it easier to compare across report formats.

There are some changes you need to know about, but which aren’t likely to impact your day-to-day experience of COUNTER Reports.

• We’re encouraging every publisher to offer Global Item Reports – there’s more about that in the Friendly Guide to COUNTER and Open Access. There’s some text in Section 10 of the Code about requiring COUNTER for OA, in case you want to include it in your license agreements.
• Components are now optional in the Item Report, not mandatory. We hope that will encourage more publishers to offer the Item Report and its Global counterpart.