Analytics for play, earnings and financial activity including track and artist plays and period earnings, credit balances and reconciliation with payment orders. Orders and payment financial reconciliation is a separate list.
Backlog
Review and re-factor the stats queries and create a reporting summary table, updated daily
Review and re-factor the stats and earnings spreadsheet prototype. Create a playstats API on the reporting summary table.
Create a simple administrator reporting UI to present reporting stats from the API .
Add more granular scopes and roles and authorisation to the reporting UI to enable wider use
Introduce payment status codes to better reflect ‘buy now’ and future innovations / offers (requirements needed)
Review and re-factor the stats queries and create a reporting summary table, updated daily
Looks like I started working on some reporting stuff already after a chat with @Nick_M a little while back: to convert portions of the CSV-file based reporting into something intermediate with a free BI tool fed from endpoints from the Tracks API for more real-time reporting capabilities. I didn’t know this placeholder epic was here until today.
Should I make GitHub issues for each of the reports (I got the info from Nick) and work from there?
Spec out the work first here in topics in the relevant #platform category. This serves three functions
Helps you think through the product case for each report
Allows others to contribute to the spec
Allow the spec to be added to an epic, or to be flagged for PR (if needed)
2. Implementation
Not all specs need to be implemented via changes to a resonate repo. Perhaps changes won’t be needed here. If they are though, there are two ways to make that happen:
get the spec added to an epic; or
get consent from the development lead (currently me) to work on it as an ad-hoc project
The consent here is basically a signal that the PR would be merged if completed to the required technical standard. We might even use a tag for that, such as pr-accepted.
