Project

General

Profile

Actions

Feature #20103

closed

Configure ISTI Open Portal to expose usage statistics for OpenAIRE

Added by Leonardo Candela over 3 years ago. Updated almost 3 years ago.

Status:
Completed
Priority:
Normal
Target version:
Start date:
Feb 09, 2021
Due date:
% Done:

100%

Estimated time:
(Total: 0.00 h)

Description

A follow up of the successful registration of ISTI Open Portal in OpenAIRE (#20053) requires to provide OpenAIRE with repository usage statistics.

Please find below the details, I guess we should go for the python script case.

OpenAIRE’s usage statistic service uses the Matomo Open Source Analytics platform (matomo.org) to track usage activity. When metrics are enabled for a repository, two unique identifiers are generated - a matomo-ID that associates the repository with its usage events in Matomo and an authentication-ID that allows to track usage activity on the Matomo platform. Metadata views and item downloads are tracked and automatically sent to Matomo. Statistics are generated using the COUNTER Code of practice directives.

OpenAIRE's usage statistics service tracking code exploits Matomo’s API. In order to make the tracking of usage events from repositories more robust, it was necessary to implement repository platform specific patches and plugins starting with DSpace and EPrints. The code is maintained on Github:

Going to add the specific configuration parameters into a private area.

Details for the configuration files are given in the README of the tracking code.


Files

openportal-test.log.gz (26.7 KB) openportal-test.log.gz Andrea Dell'Amico, Jan 12, 2021 01:58 PM Delete
matomo_config.yaml (1.51 KB) matomo_config.yaml Leonardo Candela, Apr 08, 2021 01:27 PM Delete
matomo_import_logs.py (56.1 KB) matomo_import_logs.py Leonardo Candela, Apr 08, 2021 01:27 PM Delete

Add

Subtasks 1 (0 open1 closed)

Feature #20675: Reconsider the URLs for accessing the payloads ClosedMichele ArtiniFeb 09, 2021

Delete link to subtaskActions

Add

Related issues

Related to ISTI Open Access - Feature #24391: ISPC Open Portal: configure usage counts ClosedLeonardo CandelaJan 11, 2023

Delete relationActions
Follows ISTI Open Access - Feature #20053: Register ISTI Open Portal in OpenAIRECompletedLeonardo CandelaNov 02, 2020

Delete relationActions
Actions #2

Updated by Leonardo Candela over 3 years ago

Actions #3

Updated by Andrea Dell'Amico about 3 years ago

  • Status changed from New to In Progress

Updated by Andrea Dell'Amico about 3 years ago

  • % Done changed from 0 to 70

I created the environment and installed the script inside a virtualenv, but it does not work.
It seems that our apache logs directory sports too many files for the script and it gives up after the check of some of the rotated (compressed) files because it does not discriminate between compressed and not compressed files. I opened an issue here https://github.com/openaire/Generic-Matomo-Tracker/issues/7 asking for a new command line option.

I also see that the script diverged a lot from the original matomo one (that one supports files as arguments).

Updated by Leonardo Candela about 3 years ago

It seems the revised matomo script has been fixed.

Updated by Andrea Dell'Amico about 3 years ago

  • Status changed from In Progress to Feedback
  • % Done changed from 70 to 100

I see. I just installed the script, its execution will be triggered by the logrotate weekly run.

I also just started a run against the one year old access logs.

Updated by Andrea Dell'Amico about 3 years ago

The import script run without errors, but exactly 0 valid records were found.
The configuration used is the one published in the github repository, https://github.com/openaire/Generic-Matomo-Tracker/blob/master/matomo_config.yaml, the only modifications are the ID and the auth token.
Can anybody check if the configuration is valid? @michele.artini@isti.cnr.it , @leonardo.candela@isti.cnr.it ?

I guess the relevant part is

  #OAI-PMH Configuration
  oaipmh_preamble: "oai:repository.site:"

  #Metadata Location (supports multiple locations and regular expressions)
  tracking_metadata:
  - "/([0-9]*)/(?!pdf)$"

  #Item Location (supports multiple locations and regular expressions)
  tracking_download:
  - "/([0-9]*)/[0-9]*\\w.*pdf"

Updated by Leonardo Candela about 3 years ago

I'm not an expert and, if possible, I'll contact again the OpenAIRE colleagues to get some insights.

I would say that the easiest part is certainly this:

and I'm confident you already set it accordingly.

Regarding the three parameters you identified, it seems they are used by the methods

  • check_static
  • check_download

to identify the hits in the log to "count". By having a look at the log hits (is it possible to have an excerpt?) we might try to derive them.

For the sake of completeness, oai-pmh records we provide OpenAIRE with are like this

https://openportal.isti.cnr.it/oai?verb=GetRecord&metadataPrefix=oai_dc&identifier=oai:dnet:people______::a3e8ec3bad01d7a432cab3cdee473e76

I guess:

  • oaipmh_preamble might be either

  • tracking_metadata

    • seems the pattern matching expression that, in tandem with the preamble above, identifies an access to the record (by using any url/hit other than ending with ".pdf"
  • tracking_download

    • seems the pattern matching expression that, in tandem with the preamble identifies an access to the payload (by using any url/hit ending with ".pdf"

The "problem" that I see is that access to payloads is done via urls like

http://openportal.isti.cnr.it/data/2020/437281/2020_437281.preprint.pdf

i.e. they have a path diverse from that of phm records (/oai) and landing pages (/doc)

An approach might be to consider:

  • oaipmh_preamble = https://openportal.isti.cnr.it
  • tracking_metadata = a regular expression identifying any hit matching the preamble + "/doc" + *
  • tracking_download = a regular expression identifying any hit matching the preamble + "/data/" + *

Updated by Andrea Dell'Amico about 3 years ago

Leonardo Candela wrote:

The "problem" that I see is that access to payloads is done via urls like

http://openportal.isti.cnr.it/data/2020/437281/2020_437281.preprint.pdf

i.e. they have a path diverse from that of phm records (/oai) and landing pages (/doc)

An approach might be to consider:

  • oaipmh_preamble = https://openportal.isti.cnr.it
  • tracking_metadata = a regular expression identifying any hit matching the preamble + "/doc" + *
  • tracking_download = a regular expression identifying any hit matching the preamble + "/data/" + *

The oaiphm_preamble shoud be a piece of a URI and not the hostname. Even an empty string I guess if it's not relevant.
About the tracking regular expressions? are we interested in pdf files only?

Updated by Andrea Dell'Amico about 3 years ago

I tried with:

#OAI-PMH Configuration
  oaipmh_preamble: "oai?verb"

  #Metadata Location (supports multiple locations and regular expressions)
  tracking_metadata:
  - "/doc?(.*)$"

  #Item Location (supports multiple locations and regular expressions)
  tracking_download:
  - "/data/([0-9]*)/[0-9]*/.*pdf"

against a sample of 1000 lines, and something happened:

Logs import summary
-------------------
    6 requests imported successfully
    1 requests were downloads
    5 requests were metadata
    701 requests ignored done by bots, search engines...

Updated by Andrea Dell'Amico about 3 years ago

The log file I used to test the script is attached.

Updated by Leonardo Candela about 3 years ago

It seems the preamble is not used/useful at all ... none of the log entries contain it :)

Moreover, by looking at the sample of the log I guess this is the entry contributing to the download

93.44.104.144 - - [05/Jan/2020:12:45:03 +0100] "GET /data/2018/395392/2018_395392.postprint.pdf HTTP/1.1" 200 385200 "https://scholar.google.com/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:71.0) Gecko/20100101 Firefox/71.0"

My feeling is that someone discovered the paper via Scholar and accessed it (in fact the paper is indexed by scholar and one of its versions come from openportal).

https://scholar.google.it/scholar?hl=en&as_sdt=0%2C5&q=Do+we+need+new+strategies+for+testing+Systems-of-Systems%3F&btnG=

I would go for the following:

  • use an empty string for the preamble;
  • the metadata expression is fine;
  • the download expression could use any file under the /data/ path ... although the majority of files (if not all) will be pdf;

Updated by Andrea Dell'Amico about 3 years ago

Leonardo Candela wrote:

It seems the preamble is not used/useful at all ... none of the log entries contain it :)

Not that batch, but there are lots of

/oai?verb=....

From what I understand they are used to retrieve some metadata

Moreover, by looking at the sample of the log I guess this is the entry contributing to the download

Yes, it's the only valid download

  • use an empty string for the preamble;

See above about it.

  • the metadata expression is fine;

OK

  • the download expression could use any file under the /data/ path ... although the majority of files (if not all) will be pdf;

OK

Updated by Andrea Dell'Amico about 3 years ago

I just started the import of the year old historic records.
The records of the current week will be imported at the end of the week.

Updated by Andrea Dell'Amico about 3 years ago

The import of the old data just completed:

Logs import summary
-------------------

    71480 requests imported successfully
    28856 requests were downloads
    42624 requests were metadata
    653389 requests ignored done by bots, search engines...

Performance summary
-------------------

    Total time: 3068 seconds
    Requests imported per second: 23.3 requests per second

I don't know how to check if they are what we expect they are.

Updated by Leonardo Candela about 3 years ago

I'm skeptical about the use of the preamble ... it is about the oai-pmh protocol OpenAIRE (and other clients) use to collect all the records metadata ... it is certainly not used to access the files.

The figures we get seems to suggest that, during last year, there were 28856 calls like /oai?verb=.... ... where . is a file name

This sounds strange.

Moreover, access to metadata is done by the oai verb "GetRecord" (thus we should filter the oai calls and not count invocations of verb like ListIdentifier, Identify). Also the ListRecod is problematic because it is an access to the metadata yet in bulk (not for a single record);

Is it possible

  • to have a sample of the log where the calls to /oai are recorded ?
  • to re-run the script by using an empty preamble ?

Updated by Leonardo Candela about 3 years ago

Leonardo Candela wrote:

I'm skeptical about the use of the preamble ... it is about the oai-pmh protocol OpenAIRE (and other clients) use to collect all the records metadata ... it is certainly not used to access the files.

The figures we get seems to suggest that, during last year, there were 28856 calls like /oai?verb=.... ... where *.* is a file name

This sounds strange.

Moreover, access to metadata is done by the oai verb "GetRecord" (thus we should filter the oai calls and not count invocations of verb like ListIdentifier, Identify). Also the ListRecod is problematic because it is an access to the metadata yet in bulk (not for a single record);

Is it possible

  • to have a sample of the log where the calls to /oai are recorded ?
  • to re-run the script by using an empty preamble ?

Updated by Andrea Dell'Amico about 3 years ago

Leonardo Candela wrote:

I'm skeptical about the use of the preamble ... it is about the oai-pmh protocol OpenAIRE (and other clients) use to collect all the records metadata ... it is certainly not used to access the files.

The figures we get seems to suggest that, during last year, there were 28856 calls like /oai?verb=.... ... where . is a file name

The preamble is not used to build the URL that points to the documents, from what I understand.

This sounds strange.

Moreover, access to metadata is done by the oai verb "GetRecord" (thus we should filter the oai calls and not count invocations of verb like ListIdentifier, Identify). Also the ListRecod is problematic because it is an access to the metadata yet in bulk (not for a single record);

Is it possible

  • to have a sample of the log where the calls to /oai are recorded ?

From some weeks ago:

194.94.18.130 - - [31/Dec/2020:17:07:53 +0100] "GET /oai HTTP/1.1" 200 6962 "-" "Mozilla/5.0 (Windows NT 6.2; Win64; x64; rv:84.0) Gecko/20100101 Firefox/84.0"
194.94.18.130 - - [31/Dec/2020:17:07:54 +0100] "GET /favicon.ico HTTP/1.1" 200 1585 "https://openportal.isti.cnr.it/oai" "Mozilla/5.0 (Windows NT 6.2; Win64; x64; rv:
84.0) Gecko/20100101 Firefox/84.0"
194.94.18.130 - - [31/Dec/2020:17:08:13 +0100] "GET /oai?verb=ListRecords&metadataPrefix=oai_dc HTTP/1.1" 200 60215 "-" "Mozilla/5.0 (Windows NT 6.2; Win64; x64; rv:8
4.0) Gecko/20100101 Firefox/84.0"
129.70.12.220 - - [31/Dec/2020:17:35:00 +0100] "GET /oai?verb=Identify HTTP/1.1" 200 6762 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:52.3) Gecko/20100101 Firefox/52.3"
129.70.12.220 - - [31/Dec/2020:17:35:01 +0100] "GET /oai?verb=ListRecords&metadataPrefix=oai_dc HTTP/1.1" 200 279929 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:52.3) Gec
ko/20100101 Firefox/52.3"
129.70.12.220 - - [31/Dec/2020:17:35:03 +0100] "GET /oai?verb=ListSets HTTP/1.1" 200 6940 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:52.3) Gecko/20100101 Firefox/52.3"
129.70.12.220 - - [31/Dec/2020:17:35:04 +0100] "GET /oai?verb=ListMetadataFormats HTTP/1.1" 200 6978 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:52.3) Gecko/20100101 Fire
fox/52.3"
129.70.12.220 - - [31/Dec/2020:18:32:37 +0100] "GET /oai?verb=Identify HTTP/1.1" 200 6762 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:52.3) Gecko/20100101 Firefox/52.3"
129.70.12.220 - - [31/Dec/2020:18:32:38 +0100] "GET /oai?verb=ListRecords&from=2020-12-31&metadataPrefix=oai_dc HTTP/1.1" 200 6580 "-" "Mozilla/5.0 (X11; Linux x86_64
; rv:52.3) Gecko/20100101 Firefox/52.3"
129.70.12.220 - - [31/Dec/2020:18:32:40 +0100] "GET /oai?verb=ListSets HTTP/1.1" 200 6940 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:52.3) Gecko/20100101 Firefox/52.3"
129.70.12.220 - - [31/Dec/2020:18:32:41 +0100] "GET /oai?verb=ListMetadataFormats HTTP/1.1" 200 6978 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:52.3) Gecko/20100101 Fire
fox/52.3"
129.70.12.220 - - [31/Dec/2020:18:42:20 +0100] "GET /oai?verb=Identify HTTP/1.1" 200 6762 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:52.3) Gecko/20100101 Firefox/52.3"
129.70.12.220 - - [31/Dec/2020:18:42:22 +0100] "GET /oai?verb=ListRecords&metadataPrefix=oai_dc HTTP/1.1" 200 279929 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:52.3) Gec
ko/20100101 Firefox/52.3"
129.70.12.220 - - [31/Dec/2020:18:42:23 +0100] "GET /oai?verb=ListSets HTTP/1.1" 200 6940 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:52.3) Gecko/20100101 Firefox/52.3"
129.70.12.220 - - [31/Dec/2020:18:42:25 +0100] "GET /oai?verb=ListMetadataFormats HTTP/1.1" 200 6978 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:52.3) Gecko/20100101 Fire
fox/52.3"
213.135.60.121 - - [01/Jan/2021:08:18:05 +0100] "GET /oai?verb=ListRecords&metadataPrefix=oai_dc&from=2020-12-23 HTTP/1.1" 200 279753 "-" "Mozilla/5.0 (compatible; OA
I; +http://www.openaire.eu)"
213.135.60.121 - - [01/Jan/2021:08:18:11 +0100] "GET /oai?verb=ListRecords&resumptionToken=-1%7Coai_dc%7C*+AND+datestamp+%3E%3D+2020-12-23%7C100%7C5f9a924d2970f022109
6d967%7Ctrue%7C HTTP/1.1" 200 281410 "-" "Mozilla/5.0 (compatible; OAI; +http://www.openaire.eu)"
213.135.60.121 - - [01/Jan/2021:08:18:12 +0100] "GET /oai?verb=ListRecords&resumptionToken=-1%7Coai_dc%7C*+AND+datestamp+%3E%3D+2020-12-23%7C200%7C5f9a924e2970f022109
6d9cb%7Ctrue%7C HTTP/1.1" 200 277039 "-" "Mozilla/5.0 (compatible; OAI; +http://www.openaire.eu)"
213.135.60.121 - - [01/Jan/2021:08:18:12 +0100] "GET /oai?verb=ListRecords&resumptionToken=-1%7Coai_dc%7C*+AND+datestamp+%3E%3D+2020-12-23%7C300%7C5f9a924e2970f022109
6da2f%7Ctrue%7C HTTP/1.1" 200 290857 "-" "Mozilla/5.0 (compatible; OAI; +http://www.openaire.eu)"
213.135.60.121 - - [01/Jan/2021:08:18:13 +0100] "GET /oai?verb=ListRecords&resumptionToken=-1%7Coai_dc%7C*+AND+datestamp+%3E%3D+2020-12-23%7C400%7C5f9a924e2970f022109
6da93%7Ctrue%7C HTTP/1.1" 200 271118 "-" "Mozilla/5.0 (compatible; OAI; +http://www.openaire.eu)"
213.135.60.121 - - [01/Jan/2021:08:18:13 +0100] "GET /oai?verb=ListRecords&resumptionToken=-1%7Coai_dc%7C*+AND+datestamp+%3E%3D+2020-12-23%7C500%7C5f9a924e2970f022109
6daf7%7Ctrue%7C HTTP/1.1" 200 297614 "-" "Mozilla/5.0 (compatible; OAI; +http://www.openaire.eu)"
213.135.60.121 - - [01/Jan/2021:08:18:14 +0100] "GET /oai?verb=ListRecords&resumptionToken=-1%7Coai_dc%7C*+AND+datestamp+%3E%3D+2020-12-23%7C600%7C5f9a924f2970f022109
6db5b%7Ctrue%7C HTTP/1.1" 200 303997 "-" "Mozilla/5.0 (compatible; OAI; +http://www.openaire.eu)"
213.135.60.121 - - [01/Jan/2021:08:18:14 +0100] "GET /oai?verb=ListRecords&resumptionToken=-1%7Coai_dc%7C*+AND+datestamp+%3E%3D+2020-12-23%7C700%7C5f9a924f2970f022109
6dbbf%7Ctrue%7C HTTP/1.1" 200 263452 "-" "Mozilla/5.0 (compatible; OAI; +http://www.openaire.eu)"
213.135.60.121 - - [01/Jan/2021:08:18:15 +0100] "GET /oai?verb=ListRecords&resumptionToken=-1%7Coai_dc%7C*+AND+datestamp+%3E%3D+2020-12-23%7C800%7C5f9a924f2970f022109
6dc23%7Ctrue%7C HTTP/1.1" 200 233275 "-" "Mozilla/5.0 (compatible; OAI; +http://www.openaire.eu)"
213.135.60.121 - - [01/Jan/2021:08:18:15 +0100] "GET /oai?verb=ListRecords&resumptionToken=-1%7Coai_dc%7C*+AND+datestamp+%3E%3D+2020-12-23%7C900%7C5f9a92502970f022109
6dc87%7Ctrue%7C HTTP/1.1" 200 265360 "-" "Mozilla/5.0 (compatible; OAI; +http://www.openaire.eu)"
  • to re-run the script by using an empty preamble ?

This can lead to duplicate records in matomo.

Updated by Leonardo Candela about 3 years ago

Andrea Dell'Amico wrote:

The import of the old data just completed:

Logs import summary
-------------------

    71480 requests imported successfully
    28856 requests were downloads
    42624 requests were metadata
    653389 requests ignored done by bots, search engines...

Performance summary
-------------------

    Total time: 3068 seconds
    Requests imported per second: 23.3 requests per second

I don't know how to check if they are what we expect they are.

According to Google Analytics, in the period 01 Jan 2020 - 31 Dec. 2020 the open portal website had

  • 27,774 pageviews
  • 21,742 unique pageviews

This page https://openportal.isti.cnr.it/doc?id=people______::b3e08179b448c1d31dfe491e006da982 get

  • 2,291 pageviews
  • 1,917 unique page views

Updated by Andrea Dell'Amico about 3 years ago

Leonardo Candela wrote:

Andrea Dell'Amico wrote:

The import of the old data just completed:

Logs import summary
-------------------

    71480 requests imported successfully
    28856 requests were downloads
    42624 requests were metadata
    653389 requests ignored done by bots, search engines...

Performance summary
-------------------

    Total time: 3068 seconds
    Requests imported per second: 23.3 requests per second

I don't know how to check if they are what we expect they are.

According to Google Analytics, in the period 01 Jan 2020 - 31 Dec. 2020 the open portal website had

I was referring to the openaire usage statistics site :-). I don't think I have access, and even than I don't know how to check if the collected information is correct.

Updated by Leonardo Candela about 3 years ago

According to my understanding the figures we are going to store in matomo are usage statistics that are independent from OpenAIRE, i.e. they are usage statistics measured and declared by the single repository.

OpenAIRE is going to complement them with its own figures.

I was reporting the Google Analytics figures to highlight that the repository usage statistics we are going to store in matomo seems not comparable with usage statistics GA collect about our repository.

Was the script analysing only 2020 logs? Could you please let me know the time frame of the log we are analysing by the matomo script?

Updated by Andrea Dell'Amico about 3 years ago

Leonardo Candela wrote:

According to my understanding the figures we are going to store in matomo are usage statistics that are independent from OpenAIRE, i.e. they are usage statistics measured and declared by the single repository.

OpenAIRE is going to complement them with its own figures.

I try to rephrase: Do we have access to the OpenAIRE matomo data, to see what was imported?

I was reporting the Google Analytics figures to highlight that the repository usage statistics we are going to store in matomo seems not comparable with usage statistics GA collect about our repository.

I don't think they are meant to be comparable?

Was the script analysing only 2020 logs? Could you please let me know the time frame of the log we are analysing by the matomo script?

Oldest entry:

66.249.76.123 - - [05/Jan/2020:06:25:27 +0100] "GET /results?format=xml&pageSize=16&cnrcreatorforbrowsing%5B%5D=Antonia%20Bertolino&rights%5B%5D=Open%20Access HTTP/1.1" 200 23067 "-" "Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.96 Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"

Newest one:

185.191.171.45 - - [11/Jan/2021:06:25:08 +0100] "GET /results?id=people______%3A%3A0f040e21ccdf16af3624f3719159da1f&option=com_dnetindexclient&view=doc HTTP/1.1" 200 10194 "-" "Mozilla/5.0 (compatible; SemrushBot/7~bl; +http://www.semrush.com/bot.html)"

Updated by Leonardo Candela about 3 years ago

Andrea Dell'Amico wrote:

Leonardo Candela wrote:

According to my understanding the figures we are going to store in matomo are usage statistics that are independent from OpenAIRE, i.e. they are usage statistics measured and declared by the single repository.

OpenAIRE is going to complement them with its own figures.

I try to rephrase: Do we have access to the OpenAIRE matomo data, to see what was imported?

I don't think so. Moreover, I decided to send an email to OpenAIRE colleagues (you are in cc).

I was reporting the Google Analytics figures to highlight that the repository usage statistics we are going to store in matomo seems not comparable with usage statistics GA collect about our repository.

I don't think they are meant to be comparable?

Why? I would expect that the figures we get from GA about page views are greater than the figures we publish for "metadata view" ... at the end of the story a "metadata view" is a view of a specific web page.

Updated by Leonardo Candela about 3 years ago

  • % Done changed from 100 to 90

According to the information we received from OpenAIRE colleagues we should reconsider our config as follows

oaipmh_preamble: "oai:dnet:people______::"

Updated by Andrea Dell'Amico about 3 years ago

I reconfigured the tool and manually run the processing of the last week logs. The result:

Logs import summary
-------------------

    899 requests imported successfully
    610 requests were downloads
    289 requests were metadata
    9323 requests ignored done by bots, search engines...

Performance summary
-------------------

    Total time: 13 seconds
    Requests imported per second: 68.82 requests per second


Updated by Leonardo Candela almost 3 years ago

It seems that the current config is not working, this is the message we get from OpenAIRE team:

I ‘ve looked at the usage activity from ISTI and I ‘ve noticed that we are receiving two different patterns for ISTI records:
1. For downloads: oai:dnet:people______::2018
2. For pageviews: oai:dnet:people______::?id=people______::33ea8dd21185e71591a6ca43951ea24c

We should alter the Matomo config I guess. The pageviews is correct ... the downloads part should count URLs like this

http://openportal.isti.cnr.it/data/2021/428210/2020_%20428210.preprint.pdf?id=people______%3A%3A7362a3828ba52cbea14949c31be9def0

Updated by Andrea Dell'Amico almost 3 years ago

Our matomo tracker configuration reads:

  #OAI-PMH Configuration
  oaipmh_preamble: "oai:dnet:people______::"

  #Metadata Location (supports multiple locations and regular expressions)
  tracking_metadata:
  - "/doc?(.*)$"

  #Item Location (supports multiple locations and regular expressions)
  tracking_download:
  - "/data/([0-9]*)/[0-9]*/.*"

Updated by Leonardo Candela almost 3 years ago

We have received a revised version of the scripts (in attachment) ... I kindly ask @andrea.dellamico@isti.cnr.it to install them.

Updated by Andrea Dell'Amico almost 3 years ago

Done.

Updated by Leonardo Candela almost 3 years ago

  • Status changed from Feedback to Completed

We recceived a positive feedback from OpenAIRE colleagues on the correctness of the information we provide them with.

Actions #31

Updated by Leonardo Candela about 1 year ago

  • Related to Feature #24391: ISPC Open Portal: configure usage counts added
Actions

Also available in: Atom PDF