We know about a couple ways of associating a location with a request.

• The IP address of the request. We can gather this information anywhere flask.request is available.
• Some information obtained from the ILS record of the authenticated patron. We need to gather this information right at the beginning of the request, at the point we talk to the ILS to authenticate, since we don't want to

A given library needs to be able to configure its analytics integration with any of the currently implemented methods, or none at all.

I've identified two ways of setting up the configuration here:

1. Associate everything with the analytics integration in a single drop-down.
2. Associate the different ways of getting "some information from the ILS record" with the patron integration. Then, in the analytics integration, allow a library to configure whether to get location information from the patron integrations, from the IP address, or not at all.

The first solution is obviously less complicated from a UI perspective, but I have a couple concerns.

First, the code will be more complicated. When authenticating a patron, the patron authentication integration to check all the analytics integrations associated with the library to see if it should associate a location with the request while it's at it.

Not all patron authentication mechanisms will support the same methods of getting "some information from the ILS record", so there will be an interaction between the patron authentication mechanisms associated with a library and the options presented in the analytics drop-down. It's possible that whatever thing was selected in the analytics drop-down just won't work for the current patron auth configuration. Either we need to detect this (which requires that we introduce the notion of dependencies between external integrations) or we need to accept that the library configuration can get in an inconsistent state.

Finally, if we ever use location information for anything other than analytics (e.g. authentication, which I know is on the table) we may have to move towards something more like the second solution.

The second solution decouples the "patron authentication" configuration from the "analytics" configuration, but it's more complicated.

There might be a third solution that I just don't see.