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 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.
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 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:
Some reports also aggregate on
The things the reports optionally aggregate on are (and this is the exciting one):
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.
Asking and answering these questions in order should give you a basic approach that you can adapt to your own needs.
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.
For more details, see also:
You can transform them to a value that suite you. See: Attribute transformation
A brief summary of the steps is:
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
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