@CHudson-WMF - @Dwisehaupt mentions that these activities won't currently hit the web logs - suggest connecting with him to help identify what needs to be tracked so ops can figure out the how

Updating this phab with some slack discussion:

• In initial discussions with @Dwisehaupt and @Jgreen @, @CHudson-WMF surfaced that because we weren't recording a login event (due to our magic link), we may need to rely on another signal (e.g. "hits")

• @Ejegg proposed that we could in fact "send a web beacon request from the front-end JS on specific events, like when we successfully read a donor's information from CiviCRM or when the donor clicks 'cancel'. We can include the contact ID in that beacon request to count unique users. We would just need a bit of apache config to return 200 for say any request starting with /beacon/. For example, we could track a successful page load for contact_id 123 that included wmf_campaign=testCampaign on the initial link as follows: /beacon/donor_portal/login/123?wmf_campaign=testCampaign"

@Dwisehaupt Do you think this approach would work, and should I make phab to implement and test?

This can be implemented fairly easily on the nginx side. There are a some caveats that I'll discuss with ejegg, but it should be ok from our side if the limitations are known.

Could we get the info we need from the API side? Looking at this https://civicrm.org/extensions/api-rest-log -- As long as the login method is to request a link, I think the request would go app -> portal->civiproxy->api and the event could be loggable into DB from the API side.

For initial quick testing, this has been implemented and we are now logging requests to /beacon/. It is ready for use. No post processing or data collection for metrics have been started until it is defined what we should be matching and where it should be going.

Also open to entertain research into what jgreen has asked.

Jgreen we could indeed get some info from the API side, but there are actions we want to track that don't involve an API call to Civi, like the donor first clicking on the 'Cancel recurring donation' button. We want to know how many people click that but then choose one of the alternatives like switching to annual, pausing, or reducing the amount.

In T404243#11248259, @Ejegg wrote:

We want to know how many people click that but then choose one of the alternatives like switching to annual, pausing, or reducing the amount.

@Ejegg that makes sense, thanks for clarifying.

Metrics now being collected with status code label: https://frmon.wikimedia.org/goto/ff31v15euaupse?orgId=1

@Ejegg No rush on this, but let us know if this meets your needs. If so, go ahead and close out the task.

@CHudson-WMF @AKanji-WMF @Ejegg We (fr-tech-ops) had some discussions about this today. With the beacon in place, we need to know what the log format would be, what data we need to pull from the log lines, and where that data will need to end up. Once we have that info, we can start to look at how to capture the required data and how to get the data to it's final location.