New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature: Aggregate Listener Hours in Listener Stats #196

Open
bdaneu12 opened this Issue May 3, 2017 · 6 comments

Comments

Projects
None yet
3 participants
@bdaneu12

bdaneu12 commented May 3, 2017

I need aggregation for the period specified in the analytics area for my reporting.

@hairmare

This comment has been minimized.

Show comment
Hide comment
@hairmare

hairmare May 3, 2017

Member

Hello @bdaneu12

Welcome to the LibreTime community. We are glad to have you on board. Help us keep LibreTime open and inclusive by following our Code of Conduct (CoC). Feel free to let us know if CONTRIBUTING.md is lacking anything you need to get onboarded rapidly.

Thank you for your feature request. We are trying to ensure that the release history of LibreTime is a list of meaningful issues logged and solved. To achieve this we need you to help out
by only logging explicitly documented and provable issues (see C4:2.4 for details on this process).

You can filter the data from the UI at «Analytics» -> «Playout History» with the following control:
screen shot 2017-05-04 at 01 35 24

If you need to customize the output you can do so with «Analytics» -> « History Templates».

Can I ask you to describe your use case in more detail? How do you need to aggregate the data? Do you have any links to documentation on the relevant reporting standards?

Cheers
Lucas

Member

hairmare commented May 3, 2017

Hello @bdaneu12

Welcome to the LibreTime community. We are glad to have you on board. Help us keep LibreTime open and inclusive by following our Code of Conduct (CoC). Feel free to let us know if CONTRIBUTING.md is lacking anything you need to get onboarded rapidly.

Thank you for your feature request. We are trying to ensure that the release history of LibreTime is a list of meaningful issues logged and solved. To achieve this we need you to help out
by only logging explicitly documented and provable issues (see C4:2.4 for details on this process).

You can filter the data from the UI at «Analytics» -> «Playout History» with the following control:
screen shot 2017-05-04 at 01 35 24

If you need to customize the output you can do so with «Analytics» -> « History Templates».

Can I ask you to describe your use case in more detail? How do you need to aggregate the data? Do you have any links to documentation on the relevant reporting standards?

Cheers
Lucas

@bdaneu12

This comment has been minimized.

Show comment
Hide comment
@bdaneu12

bdaneu12 May 4, 2017

bdaneu12 commented May 4, 2017

@hairmare

This comment has been minimized.

Show comment
Hide comment
@hairmare

hairmare May 4, 2017

Member

The current «Analytics» -> «Listener Stats» only has information on the amount of connected users. It looks like the «Aggregate Listener Hours» feature was implemented after legacy upstream stopped publishing open source code. This means we need to re-implement it from scratch.

To be able to do this we need the feature to be explicitly documented. The following questions spring to mind and might help you get started should you be willing to document your needs.

  • Where should we get what data from?
  • How should it be displayed?
  • What granularity do we need these stats in?
  • What length of data retention is needed?
  • Can we retain aggregated data or do we need the raw data?

I'm sure there are more questions I missed. Please help us make this issue meaningful enough that we can consider implementing it.

BTW, the output we currently have does not expose actual listening hours, adding up the values from the Listeners graph will probably not result in the right value.

Member

hairmare commented May 4, 2017

The current «Analytics» -> «Listener Stats» only has information on the amount of connected users. It looks like the «Aggregate Listener Hours» feature was implemented after legacy upstream stopped publishing open source code. This means we need to re-implement it from scratch.

To be able to do this we need the feature to be explicitly documented. The following questions spring to mind and might help you get started should you be willing to document your needs.

  • Where should we get what data from?
  • How should it be displayed?
  • What granularity do we need these stats in?
  • What length of data retention is needed?
  • Can we retain aggregated data or do we need the raw data?

I'm sure there are more questions I missed. Please help us make this issue meaningful enough that we can consider implementing it.

BTW, the output we currently have does not expose actual listening hours, adding up the values from the Listeners graph will probably not result in the right value.

@bdaneu12

This comment has been minimized.

Show comment
Hide comment
@bdaneu12

bdaneu12 May 4, 2017

bdaneu12 commented May 4, 2017

@hairmare

This comment has been minimized.

Show comment
Hide comment
@hairmare

hairmare May 4, 2017

Member

Yes, that makes sense. Piwik will probably be able to answer your questions.

If you find any issues with the docs, feel free to report them or contribute to fixing them in the LibreTime version of Icecast statistics with Piwik.

Member

hairmare commented May 4, 2017

Yes, that makes sense. Piwik will probably be able to answer your questions.

If you find any issues with the docs, feel free to report them or contribute to fixing them in the LibreTime version of Icecast statistics with Piwik.

@hairmare hairmare changed the title from Need Total Aggregation to Feature: Aggregate Listener Hours in Listener Stats May 26, 2017

@jerry924

This comment has been minimized.

Show comment
Hide comment
@jerry924

jerry924 Nov 15, 2017

Contributor

I actually need this also for PRO reporting. I can get the data out of the database we have today and load into Excel to create my reports, but should be easy to build this into the current reporting only using data that already exists.

  • Listener Stats DB table has a start time and a count of listeners.
  • We take that start time until the next start time as the number of listeners during that range
  • We can store the listener count and time range in a Range Hash Map only storing transitions (say when it changes from 5 listeners to 6 or from 10 to 9, etc).
  • Then in the playout log, we know the start and end time of each track that was played
  • Going from the start of the track to the end of the track, find the maximum number of listeners during the time the track played.
    • sometimes a whole track will span multiple ranges in the Hash Map
    • sometimes a many tracks will be inside one range in the Hash Map
  • For each track you will now have counted how many listeners
  • Now you can sum up all plays of the same track and get accumulated listeners

Your report will look like this:

Track       Artist           Accumulated Listeners          Total Plays
--------   ------------  ------------------------------- ------------
Song1     Bob               124                                          12
Song2     Joe                1293                                        45

I already do this in Excel, but it more tedious than having it built into the track report.

Contributor

jerry924 commented Nov 15, 2017

I actually need this also for PRO reporting. I can get the data out of the database we have today and load into Excel to create my reports, but should be easy to build this into the current reporting only using data that already exists.

  • Listener Stats DB table has a start time and a count of listeners.
  • We take that start time until the next start time as the number of listeners during that range
  • We can store the listener count and time range in a Range Hash Map only storing transitions (say when it changes from 5 listeners to 6 or from 10 to 9, etc).
  • Then in the playout log, we know the start and end time of each track that was played
  • Going from the start of the track to the end of the track, find the maximum number of listeners during the time the track played.
    • sometimes a whole track will span multiple ranges in the Hash Map
    • sometimes a many tracks will be inside one range in the Hash Map
  • For each track you will now have counted how many listeners
  • Now you can sum up all plays of the same track and get accumulated listeners

Your report will look like this:

Track       Artist           Accumulated Listeners          Total Plays
--------   ------------  ------------------------------- ------------
Song1     Bob               124                                          12
Song2     Joe                1293                                        45

I already do this in Excel, but it more tedious than having it built into the track report.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment