Currently, we use this graph to indicate our donation processing rate however, the data behind is graph is actually measuring how quickly previously processed donation queue messages are imported into CiviCRM. This doesn't feel like a typical donation processing rate metric. Instead, we should rename this to something more accurate, like our 'Save To CRM rate.'

Now, to more accurately measure our donation processing rate, we need to decide what we mean by donation processing rate. More specifically, we need to decide which part of the donation pipeline we want to measure.

Here are some suggestions of points in the flow that we could measure to derive processing rates from:

1. Gateway Result To CRM Save Rate - The time between the gateway giving us a result back and the donation being imported into the CRM
   • We currently capture this under the metric average_transaction_age in Prometheus. I added a test graph for this here Experimental Processing Rate, but the output looks questionable and needs verifying.
2. Submission to Save Rate - The time between the donor clicking submit and the completed donation being imported into the CRM
   • This feels like the truest measure of our overall processing rate. However, this would also include the time the donation is sitting on the Redis queue in between the front-end gateway transaction and the backend CRM save.
3. Submission to Thank You Email Rate - The same as above but adding on the period afterwards, which captures the time it takes for the thank you email to be sent
   • This feels like overkill, but it could give us timings for the full donor's donation lifecycle.
4. Gateway Processing Rate - The time between the donor clicking submit and the response coming back from a gateway
   • This one isn't really measuring how fast we do things, but it could be useful to indicate one of our gateways is backing up.
5. Frontend Processing Rate - The time between the donor clicking submit and the donation ending up on the Redis queue
6. Backend Processing Rate - AKA our Save-To-CRM rate!

We could discuss other options or even consider slicing and dicing different timings to come up with a more desirable metric.