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 personally identifiable like the username or email address though:
- This is your data, so marking user-specific data as reportable is your decision
- This is your data, so marking user-specific data as reportable is your responsibility - 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 if this is something that is likely to come up for you, your choices at the moment are basically:
- set a non-mandatory 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 where is it (presumably) already consistent. 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:
If you're sure you can and should record user IDs though, here's how
- In the schema editor (Preferences > Schema editor) expand the core attributes section at the top of the page
- Next to username and / or email address click the reportable button
- You will need to map the user identifier to a schema attribute
- In the schema editor, drag a text attribute into the custom attributes section.
- Give it a name and set it as reportable
- Click on done and then save
- Go to your connection and add a mapping from the relevant source attribute to this new schema attribute