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
Audience Summaries
This story delivers the observability layer that makes the expense reimbursement system self-improving over time. Without anonymised analytics on expense type selection behaviour and mutual exclusion conflict rates, administrators have no objective basis for evaluating whether configuration rules are accurate or whether UX friction is causing claim abandonment. For HLF, whose reimbursement rules are detailed and were highlighted as a primary concern in stakeholder workshops, the ability to refine exclusion logic based on real usage patterns — rather than assumptions — reduces support overhead, increases claim completion rates, and avoids costly full development cycles for each rule adjustment. The privacy-preserving design (session tokens only, no PII) ensures compliance with data protection requirements while still generating actionable insights.
Coordinators gain a direct feedback loop in the admin dashboard, improving their ability to manage program accuracy and user satisfaction without engineering involvement.
This is a medium-priority story with dependencies on two upstream mutual exclusion stories that must be completed first. Delivery involves three workstreams: event instrumentation in the mobile client, a privacy-compliant analytics ingestion pipeline on the backend, and an admin dashboard view for coordinators. The analytics schema must be agreed upon early to avoid rework — key fields are expense type ID, organisation ID, session token, conflict pair IDs, and abandonment signals. PII exclusion must be validated by a privacy review before any data is sent to the backend.
QA should cover event firing correctness, payload schema validation, PII absence verification, and dashboard aggregation accuracy. Rollout risk is low since analytics are additive and do not affect the core expense flow. Timeline should include time for coordinator UAT on the dashboard view, as the summary statistics need to match their mental model of 'top selected types' and 'top conflict pairs'. Coordination with the data/analytics team is needed if the backend pipeline is owned separately.
Implementation spans three layers. On the mobile client: instrument selection confirmation, conflict trigger, and abandonment events using the existing analytics service or a new lightweight event emitter. Each event payload must include expense type ID, organisation ID, and a session-scoped token — explicitly excluding user ID, name, and any contact references. Conflict events must capture both the triggering type ID and the blocked type ID.
Abandonment events must be linked to the preceding conflict event via session token for correlation. Events should be batched and flushed to the analytics backend on session end or a configurable interval to avoid per-interaction network calls. On the backend: define an analytics event ingestion endpoint that validates payload schema, rejects PII fields, and writes to an append-only events store. On the admin dashboard: add an expense analytics section that queries aggregated data — top N selected expense types and top N mutual exclusion conflict pairs — filtered by organisation and configurable time period.
Use server-side aggregation to avoid sending raw event logs to the frontend. Ensure the analytics pipeline is isolated from the core expense submission flow so failures do not affect claim processing.
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