Question/comment: Many vendors have developed a “search all” portal on their platform interface so that users can search across all the databases all together. Therefore, search numbers are almost identical for all the databases and are not relevant to how the individual databases are being used
Response: The intent of the COUNTER Code of Practice (but not necessarily explained clearly) is that if a user is responsible for selecting the databases, then searches against each database are counted as “Searches – Regular”. However, if the system automatically chooses the databases (as is the case with a federated search or multi-database discovery) then each database would count the search as “Searches – automated and federated”. The “search all databases” option is a user action; therefore, arguably all databases record as “Searches – Regular”.
Question/comment: If a user is searching from local discovery services, searches are not recorded at vendors’ sites. So some of the uses are missing.
Response: If the local discovery service is hosting the database on behalf of the database provider, then it is the responsibility of the local discovery vendor to provide the COUNTER DB1 report reflecting the use of those databases. If the user does not control which databases are searched, they would be reported as “Searches – automated and federated”. If the local discovery service blends all records into one central index such that the original database is no longer identifiable, then database-level statistics are not possible, but the library could use the PR1 report from the discovery platform and assume the total searches at the platform level apply to each of the databases covered by the discovery platform. Again, this highlights how searches are not a reliable measure of “value”.
Question/comment: Search is simply not relevant to how the database content is useful. It is more like a metric evaluating the database searching efficiency.
Response: Agreed, in a multiple database search environment, searches are not an indication of value.
Comment: Result click and record view seem to be good alternatives and I think they have addressed some of the issues. However, we found that vendors have developed different flavors of result clicks and record views. Some vendors have the identical result click numbers and record view numbers for their databases. Some vendors’ result clicks numbers are closer to record views. Some vendors have huge differences between result clicks and record views. I hope that COUNTER can help us to clarify some of the questions listed below:
Question: In the “COUNTER Quick Guide to Result Clicks and Record Views” document posted on COUNTER site, it indicates that a link to full text from result page is only counted as result click but not record view, but some vendors define their record views as user retrievals. Any time a user views a record -full text of not, article or video, image, etc., record view is recorded. Which is correct?
Response: Result Clicks are user-initiated actions from the Result List (not the detailed display). Record views are counting the views of the detailed record (abstract view) and may or may not include full text.
Question: If users are searching on their local discovery services, and clicking on the links to records from there, is the record view the only metric that will be counted at vendors site? Are the result clicks being triggered at vendors’ sites?
Response: If the local discovery system is hosting the metadata that make up a database and is able to track the source database for the result the user clicks, then it is the responsibility of the discovery vendor to provide the DB1 report reflecting the Result Clicks. If the local discovery system provides the detailed record (abstract view or even full text view) by linking the user to the database provider’s platform, then the database provider would count the Record Views and Full Text Requests (which would be applied to the title concerned.) To clarify, Result Clicks are measuring actions that take place on the result list for a given platform so would be counted by the provider of the user interface (e.g. local discovery or Federated Search) and would not be counted by the vendor that “owns” the record. If the detailed record is pulled from the vendor site in real-time, then the vendor site would count the Record View. Note that COUNTER recently released the Provider-Discovery reports that provide a standard way of discover providers to report usage of databases and journals back to the database/journal provider. Customers are identified in such reports allowing the database provider (or journal provider) to offer more holistic reporting of the use of their content. COUNTER has already added an option JR1b report to allow a publisher to report on usage of their content across multiple Platforms. A similar database report will be considered for the next release of the COUNTER Code of Practice.
Question: One of the main reasons we move to result click/record view is that we thought the usage can be linked to a particular database even though the searches are being done from the search all portal on vendors’ interface. However, some vendors told us that if users are searching via their “search all” interface, result click and record views still cannot be grouped by the databases. Are there any requirement from COUNTER standard about that?
Response: The discovery vendor should maintain the identity of the original database the result came from, even if they only provide a single central index, and use that identify to capture the Result Clicks and Record Views. In the case of A&I databases like PsycInfo or full text databases which require a subscription, an institution would need to have a subscription to that database before detailed records from that database are displayed or even searched. Therefore, to meet the expectations of their database providers, the local discover would need to know which database a given result was from and thus should be able to provide the needed reporting.
Question: If users are exporting/downloading multiple records at a time to citation management tools or other places, how are the record views and result click recorded? Exporting and downloading multiple records are very different kind of uses than looking at individual records.
Response: Result Clicks reflect user actions of many kinds and are intended to reflect an expression of interest in a result. Adding a result to a folder or exporting to a citation manager would be an expression of interest – IF that action happens on the Result List. Record Views reflect the retrieval of detailed records; therefore, if the export involves the system retrieving the detailed record for the export, then technically the Record View would be counted as well.
Issue Report: In a recent ProQuest DR1 report for our subscription to British Humanities Index, I noticed that the number of record views were much, much higher than the number of result clicks. For the 2014 calendar year, the number of result clicks was 116 but the number of record views as 1760. Any idea how the number of record views could get so high as compared to result clicks?
Usus Response: In DB1 (R4) reports, result clicks are generated when users are searching a database on the platform host and then clicking on a search result. Record views are generated when users are opening a detailed record the platform hosts regardless of the source of the search, e.g. the search could have been initiated on a discovery service or federated search system. Because of this, the activity you are seeing with British Humanities Index is accurate in that if your library is using a system such as a discovery service your users may be accessing records from BHI more times through the discovery service than going directly to BHI and generating result clicks.
Issue Report: I’m wondering if you might be able to shed light on some puzzling changes I’m recently seeing in COUNTER data from EBSCO. Although EBSCO has adopted COUNTER 4, the admin platform still also provides COUNTER data in accordance with the Release 3 categories. For some time now, my library has been regularly reviewing searches in EBSCO databases as measured by the DR3 category. There recently seems to be a precipitous drop in these searches. For August 2014, EBSCO’s DR3 report indicated a number of 54,306 for “EBSCOhost research databases.” By way of comparison, in August 2013 the number here was twice as much, 109,727. I do not believe that my institution has made any recent changes in EBSCOhost access or accessibility that would account for this drop. Such a drop is not evident EBSCO DR3 data for July 2014: for “EBSCOhost research databases” we had 105,197 searches in July 2013 and 111,389 in July 2014. However, the drop does seem to have extended to September 2014: for “EBSCOhost research databases” we had 329,792 searches in September 2013 and 174,331 searches in September 2014. Any assistance that Usus could provide with understanding this drop would be greatly appreciated.
Associated with that query, I have another one. My understanding is that, with COUNTER 4, PR1 replaces DR3. On that basis, it seems like my institution should transition from regularly reviewing EBSCO DR3 reports to regularly reviewing PR1 reports. However, the numbers in EBSCO DR3 and PR1 numbers are very different. For example, EBSCO’s August 2014 PR1 report for my institution shows a total of 6,642 “regular searches” and 33 “Searches-federated and automated”. This is far below the 54,306 searches in EBSCO’s August 2014 DR3 report for “EBSCO research databases.” How could I make apple-to-apple comparisons of EBSCO searches across DR3 and PR1 reports?
Response from Usus: Regarding the first question of the drop in DB3 searches from Fall 2013 to Fall 2014, unfortunately this kind of variation is not completely unusual, and it is one of the main reasons that the new COUNTER 4 reports, especially the metrics of result clicks and record views, are much better determinants of use and value for databases.
Some of the reasons this change could have happened at your institution are the implementation of a discovery layer other than the EBSCO Discovery Service (EDS), a lesson plan change for a first year curriculum or library instruction course that steered students toward general databases from other providers, or changes to the way students and faculty accessed your resources, such as adjustments to your LibGuides, A to Z list, etc. EBSCO indicated that total searches in their COUNTER R3 DB3 report were being incorrectly reported as the total searches across all databases. This has since been corrected, but it could likely have affected your institution, especially if your library used EDS. Additionally, EBSCO states that the COUNTER R1/R3 reports will be removed from EBSCOadmin before the end of the month.
Regarding your second question about the difference between DB3 and PR1, you are correct that although PR1 replaces DB3, it is quite different in what it is calculating. A search click on the platform is only counted once although dozens of databases may have been searched, which means that it does a much better job of deduplicating multi-database searching. If you still want total searches across all databases, you can use the DB1 report.
Issue Report: I am not sure that this is really a COUNTER but rather the method that ProQuest reports searches for sub-collections of databases. The issue is most frustrating with indexing and abstracting databases. With full text resources, one can gain an idea of use from full-text items delivered (JR or BR reports – or now multimedia reports). But with indexing and abstracting sources, searches and sessions are all one has to go on. ProQuest DB1 reports often include subsets of a database wherein all the searches in each subset are then added to the total. For example, ASFA (Aquatic Science and Fisheries Abstracts) is purchased by us as one database. But ProQuest reports the use of 6 component subsets of ASFA, not the true use of the entire database. Thus, if each subset reports 4000 searches in a year, that is then added together for a total of 24,000 searches. That is a false inflation since a review of each subset shows exactly the same number of searches. This occurs with other databases, such as ProQuest Congressional. It means hand-editing every single report to get more meaningful numbers. Since we use Serials Solutions, a ProQuest product, to help us aggregate our use statistics, this makes more work for us and for them. I would like to see ProQuest offer an option to exclude these subsets so that we get a better picture of our true use.
Response from Usus: It is important to note that the use of searches to evaluate the value of databases is not going to be accurate. There are many opportunities for search inflation, including federated and cross-platform searches and discovery systems. The new database metrics available in COUNTER 4, however, result clicks and record views, are much more useful for the evaluation of databases since they are only counted if a user actually clicks on a result.
ProQuest has been asked about this issue, and they have reported that it is primarily an issue with what they call “modular” databases, or databases that are searchable as one unit but that a library would buy as separate units. They are looking at possible enhancements to their usage reports in 2015 to reduce the duplication caused by some of the more complex product bundles and modular products and have said that they will have more information to share over the coming months.
In the meantime, because change across time is important and COUNTER 4 has only been in effect a short while, a rough method you can use to find an approximation of true search/session numbers is to identify a database in the report that your library does not link to or highlight and use the numbers from that database to estimate how many of the searches/sessions were multi-database searches/sessions. This number can then be subtracted from the individual database results to estimate a truer level of usage.