About reports and privacy

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 privacy and data protection legislation
• The reportable flag on an attribute is on or off for your entire domain so will affect all your users

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:

1. set a non-mandatory attribute as reportable and only populate data for your patrons who have consented.
2. get the data you need to break things down by into OpenAthens and have us do the aggregation (department names for example).

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

1. In the schema editor, expand the core section and find the Department attribute. 
2. Hover over it to reveal the reportable button and click it
3. Save

Advantages

• If you already have data there, there's nothing else to do

Disadvantages

• 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)

Best for

Sites using local authentication as they can map the data from their own systems where is it (presumably) already consistent. See:

• Attribute mapping
• Attribute transformation

By creating a custom choice attribute

1. In the schema editor, drag a choice attribute into the custom attributes section. 
2. Set it as required and reportable
3. Add your departments as the choices
4. Click on done and then save

Advantages

• Limits the values that can be selected
• Cannot be left blank

Disadvantages

• You have to get the data in there for any existing accounts

Best for

Sites using OpenAthens accounts. See:

• How to migrate from user groups or permission sets to custom attributes

If you're sure you can and should record user IDs though, here's how

OpenAthens accounts

1. In the schema editor (Preferences > Schema editor) expand the core attributes section at the top of the page
2. Next to username and / or email address click the reportable button
3. Save

Local accounts

1. You will need to map the user identifier to a schema attribute
   1. In the schema editor, drag a text attribute into the custom attributes section. 
   2. Give it a name and set it as reportable
   3. Click on done and then save
2. Go to your connection and add a mapping from the relevant source attribute to this new schema attribute