Expense Type Selection Tracked for Analytics and Audit
The expense type analytics tracker records anonymised selection events including: which expense type was chosen, whether a mutual exclusion conflict was triggered and which pair was involved, whether the user resolved the conflict or abandoned the flow, and the time taken from opening the picker to confirming a selection. These events are batched and sent to the analytics backend without PII. The data is surfaced in the admin dashboard to help coordinators and administrators review whether the exclusion rules are calibrated correctly and whether certain expense type combinations are being attempted frequently — suggesting a need for rule revision or user guidance. No individual peer mentor is identifiable from the analytics data.
User Story
Acceptance Criteria
- Given a peer mentor selects an expense type, when the selection is confirmed, then an analytics event is recorded with the expense type ID, organisation ID, and a session token (no user ID)
- Given a mutual exclusion conflict is triggered, when the conflicting type is disabled, then an analytics event records the pair of conflicting type IDs and the triggering type
- Given a peer mentor abandons the expense flow after a mutual exclusion conflict, when the session ends, then an abandonment event is recorded linked to the conflict event
- Given the analytics tracker records events, when the data is stored, then no personally identifiable information (name, user ID, contact references) is included in any event payload
- Given the admin dashboard is accessed by a coordinator, when the expense analytics section is viewed, then a summary of top-selected types and top mutual exclusion conflict pairs is shown for the configured time period
Business Value
Analytics on expense type selection behaviour provides objective evidence for refining mutual exclusion rules and identifying UX friction points that lead to claim abandonment. If a particular combination is attempted frequently before the user realises it is blocked, this signals either a UX labelling problem or a misconfigured exclusion rule. For HLF, where the reimbursement rules are detailed and were specifically called out in the workshop, the ability to iterate on configuration based on real usage data is essential to keeping the system accurate and user-friendly without requiring full development cycles for each adjustment.
Components
- Expense Type Analytics Tracker infrastructure
- Expense Selection BLoC service
- Mutual Exclusion Rule Engine service
- Expense Type Configuration data