OpenAthens reporting allows you to generate (and schedule) reports across a variety of measurable items and how useful they are will depend a bit on you - for example the snapshot reports about how many accounts you had on each day of the last three months will be of more interest to those of you whose number of patrons goes up and down regularly than, say, a site which generally has one big intake per year.

The authentication reports and the resource access reports will be of interest to all though, and to work out how to get the most out of them we first need to understand the three 'A's - Authentication, Access and Aggregation:

Authentication reports

Authentication is just about signing in to OpenAthens and not about access to content. It will tell you about how many user sessions there have been (and by how many unique users) - e.g. if you have 4200 authentications on a day by 1400 unique users you can see that your users are averaging 3 sessions per day. 

Access reports

I'm cheating a bit with the second 'A' as it is Resource Access. Technically it is about access attempts as the resources do not tell us whether or not they let the user in but in general the things you have a subscription to should have let them in. 

Aggregation

Aggregation is the most important of the three 'A's because it is about which fields have already been added up, the most basic example of which is the date - e.g. the system has already added up how many of X or Y happened yesterday or last Thursday. This means that it already has that data available when you ask, and just has to display it - i.e. when the arithmetic is already done, reports can appear quickly.

The things the reports automatically aggregate on are:

• Days
• Months
• Permission sets
• User groups

Some reports also aggregate on

• Hours
• Country
• Network

The things the reports optionally aggregate on are (and this is the exciting one):

• Custom attributes that you add to the schema

Best practice with accounts is to use custom schema attributes for any data that needs to be consistent over multiple sub-organisations (e.g. job roles, specialities, temporary status) and reporting is the same.

Reporting goes further and enforces that practice as it will not generate a report for permission sets or user groups that covers more than the current organisation. This is going to be a significant factor in any approach you take.

The bottom line is that to make the most of the reporting options, you need to make sure that the accounts your users are issued include all the relevant information that you want to report on, stored in (or mapped to) attributes that the system will aggregate on. 

Q & A

Asking and answering these questions in order should give you a basic approach that you can adapt to your own needs.

Do you have multiple sub-organisations?

If you need to report on the same factor over all the sub-organisations then you will want to use a custom attribute for it and this is the same if you are using OpenAthens accounts or local accounts. Jump ahead to the question about how to set up custom attributes.

If you do not have any sub-organisations, or if those sub-organisations are left to their own devices and you do not need to report on them, then you do not need custom attributes. You may still find them useful, however user groups and permission sets may be sufficient for your needs - just allocate them as required. Groups are one per user, but multiple permission sets can be assigned to a user. 

See also:

• Permission sets
• Groups

How do I set up a custom attribute? 

Briefly:

1. Sign in as the domain administrator then go to Preferences > Schema editor.
2. Drag an attribute type from the left into the account schema on the right
   1. For OpenAthens accounts: choice attributes are usually recommended as the put a definable dropdown list into the interface.
   2. If you are using a local connector: the text attribute is recommended choice as it allows the value restriction to be defined in your local system instead
3. Fill in the details
4. Tick the box for reportable
5. Click done and save
6. Populate data into existing accounts / make sure your local system is mapping the data 

For more details, see also: 

• Schema editor
• Attribute mapping

I use local accounts but I cannot map the local attribute values I need to a custom attribute because they are too long / inconsistent / badly spelled to be used...

You can transform them to a value that suite you. See: Attribute transformation

How do I migrate my user groups or permission sets to custom attributes?

A brief summary of the steps is:

1. Add the custom attribute to your schema
2. Download exiting data
3. Update the custom attribute column in a spreadsheet application
4. Upload the modified data

Depending on the number of accounts, groups or permission sets you have, and the approach you take this could take anywhere from a few minutes to more than an hour. There are more detailed instructions at: How to migrate from user groups or permission sets to custom attributes 

How do I get user IDs in the reports

First you should determine whether or not you need that as there are some privacy implications, and putting things like job roles or department data into OpenAthens as above is usually a better approach - see About reports and privacy