If you need to get statistics reports that include user identifiers - e.g. to plug data into another system for any reason - then you can. There are certain things that should be considered before you set the reportable flag on something like the username or email address though.
- This is your data, so marking userID data as reportable is your decision
- This is your data, so marking userID data as reportable is your responsibility - e.g. you need to comply with all relevant data protection legislation
- The reportable flag on an attribute is on or off for your entire domain, and every OpenAthens account has a username and email address
Because the flag is all or nothing, a user withholding consent could mean you have to turn it off for everyone. There are things in the pipeline that will be able to help with this, but your choices at the moment are basically:
- set a different attribute as reportable and only populate data for your patrons who have consented.
- get the data you need to break down things by into OpenAthens and have us do the aggregation.
Since choice 1 will lead to reports that do not include all users, it is possible that the reports you get may not be able to do what you need them to do so option 2 is recommended in most cases.
OpenAthens is very flexible about what you can aggregate your data on. For example if you had been exporting usernames so that you could match them to departments, then putting the department data into OpenAthens would let you get the breakdowns you need; you would also most likely change a monthly job of cross-matching data into a one-time job to populate the data.
It could be any attribute of course, but let's use department as our example:
By setting the department attribute as reportable
- In the schema editor, expand the core section and find the Department attribute.
- Hover over it to reveal the reportable button and click it
- If you already have data there, there's nothing else to do
- Typos can really muddle things up in the report interface - fixing them will not change data that has already been recorded
- Can be left blank (usually a disadvantage)
Sites using local authentication as they can map the data from their own systems. See:
By creating a custom choice attribute
- In the schema editor, drag a choice attribute into the custom attributes section.
- Set it as required and reportable
- Add your departments as the choices
- Click on done and then save
- Limits the values that can be selected
- Cannot be left blank
- You have to get the data in there for any existing accounts
Sites using OpenAthens accounts. See: