Skip to content

[Feature Request] historical adoption metrics #1028

Open

Description

@smartin015

What do you want to see implemented in the plugin repository?

I'd like to see some longer historical data around plugin adoption, to complement the 7-day and 30-day active user metrics already published.

It would be fantastic if there were multiple historical dumps of weekly/monthly plugin stats, in addition to the current json dumps in https://data.octoprint.org/export/. Even something as simple as "copy the current json files into a /yyyy/mm/dd/*.json folder" run once a week would be enough to do some manual analysis.

Even cooler would be a graph on each plugin page that shows how adoption has trended over time.

Why, what problems would be solved by this?

The "new installs" and "active instances" stats sections to the right of each plugin are great! But as a plugin maintainer, I'd like to know more about how my plugin has performed over time - whether adoption is growing or shrinking, and by how much.

With this information, I can see if my development effort has been worthwhile, or if people are losing interest / leaving for something else.

Any additional information you want to provide?

Happy to help contribute to make this happen, although I haven't been able to see how the data export stuff works from a brief search through octoprint's repositories.

Activity

  1. jneilliii commented on Mar 16, 2022

    @jneilliii
    Contributor

    A couple of us have done our own where we are scraping the exports and storing in our json file. You can see mine here and Charlie and Taylor have done similar ones.

    https://jneilliii.github.io/OctoPluginStats/

    https://octopluginstats.vercel.app/

    https://the-eg.github.io/plugins-dashboard/

  2. cp2004 commented on Mar 16, 2022

    @cp2004
    Member

    I was just typing out the same set of links...

  3. smartin015 commented on Mar 16, 2022

    @smartin015
    ContributorAuthor

    Wow, thanks for those links! I'll look into setting up an instance of my own.

    Bit of a shame it has to be a separate instance though, since it appears I'm not the only one that's thought about this. Y'all can do what you like with the FR - I'll leave it open in case you think there's merit in a more central solution with less scraping.

  4. cp2004 commented on Mar 16, 2022

    @cp2004
    Member

    Bit of a shame it has to be a separate instance though, since it appears I'm not the only one that's thought about this.

    The positive spin on it - you get to customise it to what you want and I learnt a bit of React/MUI stuff at the time doing it as an experiment 🙂 . Ideally, the less things that we can maintain the better - it may benefit a few plugin authors, but it is adding more stuff to maintain across the octoprint.org sites for a very small number of people, often just one.

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

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions