Best Practice on Syndicated Usage

Content syndication is becoming increasingly common. Our syndicated usage best practice guidance applies to content available on multiple platforms. It describes how syndication platforms should share COUNTER-compliant usage reports with publishers.

Sharing reports this way will mean publishers have consistent, comparable usage metrics from all the syndicated usage platforms they work with. It will help them understand which ones are delivering return on the time and effort invested in syndication. The guidance also explains how institutional COUNTER reports can include syndicated usage. That will allow libraries to see comprehensive usage reporting for a publisher’s content, no matter where the usage happens.

This guidance was updated on 23 October 2026 and applies to Release 5.1.1 of the COUNTER Code of Practice (R5.1.1), where content is syndicated and available on multiple platforms.

Best Practice

Conventions

Per the Code of Practice, this best practice guidance uses 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.

Who Can Share Syndicated Usage

• Where COUNTER metrics are being shared, both the syndication platform (Third Party) and the original publisher (First Party) MUST be independently audited as COUNTER-compliant.
• We recommend that usage metrics be shared from the Third Party syndication platform back to the First Party.
• Where raw usage data is being shared, the Third Party does not need to be COUNTER-compliant. The First Party is responsible for processing the data in line with the Code of Practice. It must be clearly stated on the First Party’s website that they are processing the data.

Global Reporting

• The Third Party SHOULD share raw usage information with the First Party, which the First Party then processes in compliance with the COUNTER Code of Practice. Where raw usage data cannot be shared, and the Third Party intends to share COUNTER-processed usage data with the First Party, both MUST be independently COUNTER-compliant.
• Where the Third Party is COUNTER compliant, it may deliver global reports directly to report consumers when these are requested. It SHOULD share information with the ​First Party about when global COUNTER reports are being called for the syndicated content.
• The First Party may deliver aggregated global usage reports (i.e. their own global reports plus the global usage from Third Partys) but MUST clearly mark the platforms on which usage occurred in the Platform field using the namespace SYNDICATED:{platform name}, so that syndicated usage can be identified and excluded when creating a Standard View from a COUNTER Report.

Institutional Reporting

• Institutional reports MUST only be shared where the Third Party and the First Party can guarantee that the authentication identifiers match exactly. Acceptable matches include
  • OpenAthens or Shibboleth sign-ins that can be very specifically tied to one institution are acceptable
  • IP ranges where the syndication platform and original publisher share an IP database.
  • Syndication platforms delivering the IP addresses used to access syndicated content as part of the raw usage data sent to the original publisher, provided this can be done without breaching privacy regulations, such that the original publisher can use their own IP database to attribute the syndicated usage to institutions.
  • GetFTR, which shares the original publisher’s internal Customer/Institution ID with the syndication platform as part of the entitlement check process.
  • Explicit institutional matching, in which the publisher’s institutional identifiers are shared with the syndication platform. Syndication platforms may include users who are outside of the shared IP ranges where the users are verified using their institutional email address.
• Institutional reports MUST NOT be shared based on ‘best-guess’ institutional matching where the First Party and Third Party have different IP databases.

What Third Parties Can Do With Institutional Reports

• The Third Party may deliver institutional reports directly to report consumers when these are requested, provided there is a clear notification on their report interface that this usage information is also available from the First Party.
• If the Third Party offers institutional usage reports directly to report consumers, it SHOULD share information with the First Party about when COUNTER reports are being called for the syndicated content, and by which institutions.

What First Parties Can Do With Institutional Reports

• The First Party MUST clearly mark the platforms on which usage occurred in the Platform field using the namespace SYNDICATED:{platform name}, so that syndicated usage can be identified within COUNTER Reports and excluded when creating a Standard View from a COUNTER Report.
• The First Party MUST allow syndicated usage to be excluded from their global and institutional reports in tabular format. The next breaking release of the Code of Practice will include a change to the COUNTER API (formerly sushi) to create a new Report_Attribute which will permit similar exclusion there.

Appendix: Glossary of Terms

• First Party. Report providers and publisher platforms offering scholarly content to end users and reporting usage directly to libraries. In the context of this best practice, a publisher such as Springer Nature or an aggregator such as EBSCO with AI systems embedded in their platforms.
• Original publisher. See First Party.
• Syndication platform. See Third Party.
• Third Party. Services making use of First Party content to deliver services to end users. Third Parties should report usage to First Parties, and may also report usage to libraries. In a COUNTER context, a service such as ResearchGate.

How this best practice was developed

Like all our best practices, this guidance started with a community consultation on a draft policy developed by a small working group.

The draft was revised in line with the feedback, before being published in August 2024. We’ve issued minor updates and clarifications since then. The best practice was last updated on 30 June 2026 to link to Release 5.1.1 of the Code of Practice. That version is available in PDF.

There are also tech support posts on our news page that you might find helpful.