Activity Summary Metrics¶

Overview¶

Occurrence data for certain topics is collected to provide:

The first occurrence
The last occurrence
The count of occurrences
The sum of a value, when applicable

Example use cases¶

Several workflows require the customer/payment summary data.

Example 1: Deactivate token flows¶

Send deactivate warning after 16 months¶

Needs to pull customers:

1 active token
No payment, RFP, registration in 16 months
ENS alert InactiveCustomerAlertSent not sent in last 90 days

Deactivate token after 18 months¶

Needs to pull customers:

1 active token
No payment, RFP, registration in 18 months

A cross-service query is difficult due to the need for collating active customers with the payment data. CPR has no info on customer status. We would have to do some sort of bulk search where we pass in batches of active customers. Notifier would require something similar.

Example 2: Inbound limits flows¶

UC 12x need to know the oldest inbound payment date since the last customer activation.

From the story:

For the pilot, the following periods will be used by default
- 0 - 60 days from the day the customer first receives a payment
- When a customer deletes all active tokens and re-registers, the 0-60 days starts over.

CPR is not able to provide this info. Combining BoyarServices.Zelle and BoyarServices.PaymentRepo data isn't sufficient unless we start tracking deactivations.