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

Show statistics #355

Open
tiltec opened this Issue Feb 27, 2017 · 11 comments

Comments

Projects
None yet
4 participants
@tiltec
Copy link
Member

tiltec commented Feb 27, 2017

The new /history endpoint can be used to display some statistics per group and per user.

On user page:

  • pickups done for each group (that the users have in common)

On group page:

  • pickups done per store
  • total pickups per group

Later on, the backend would provide some more statistics and aggregate them for reduced server load.
yunity/karrot-backend#253 will provide the weight of the food, so this could also be used for stats.

@tiltec tiltec added this to the Release 4 milestone Feb 27, 2017

@tiltec tiltec modified the milestones: Discussion (lesser priority), Current discussion (higher priority) Jul 2, 2017

@D0nPiano

This comment has been minimized.

Copy link
Member

D0nPiano commented Jul 24, 2017

So far, I can think of:
Overall:

  • no. of groups
  • no. of stores
  • no. of members
  • no. of pickups
  • amount of saved food

In Groups:

  • no. of members (already displayed)
  • no. of stores (could easily be displayed)
  • no. of pickups
  • amount of saved food

Store:

  • no. of pickups
  • amount of saved food

User page:

  • pickups done for each group (that the users have in common)

...which of course there is no need to implement all of them 😉


@tiltec
amount of saved food waits for https://github.com/yunity/foodsaving-backend#253, but what about the overall stats? If we wanted to display them on the landing page, or on an extra stats page, would you just load the whole lists on users, groups, stores etc.? Or should there be another backend endpoint?

And also, would you create a seperated endpoint for Store: no of pickups and Group: no of pickups ? Or load it from the current history api somehow?

@tiltec

This comment has been minimized.

Copy link
Member

tiltec commented Jul 30, 2017

Having a cumulated foodsaving.world stats endpoint makes sense, since anonymous visitors don't have access to the users and stores endpoint.

I would like to take some care that the stats make as much sense as possible, i.e. only showing the active users (at least one sign of activity per 2 months), only showing the pickups where people signed up to get the food.

I would deliver the group stats through either/or

  1. an additional stats field in GET /api/groups/:id/
  2. an additional endpoint GET /api/groups/:id/stats/

Similar for stores. (1) seems easier for the front-end, but (2) would make it clearer that these are not the group data, but something else. Would prefer (2) therefore.

@D0nPiano

This comment has been minimized.

Copy link
Member

D0nPiano commented Jul 31, 2017

Would something like

group = {
id: 5,
name: StoreName,
stats: {
  pickups: 513,
  stores: 15,
  members: 20
}

..work for (1)? I think it would be clear that it's stats, without having an extra endpoint.

@tiltec

This comment has been minimized.

Copy link
Member

tiltec commented Jul 31, 2017

Yes, that would be the structure of (1).

How would you handle updates? Currently we always send the whole modified group object back to the server via PATCH. Would make sense to only send changed fields back if we go for (1), which would make the frontend a bit more complex.

On the other hand, (2) would mean adding another service method and another resolve entry. Seems quite straightforward.

@D0nPiano

This comment has been minimized.

Copy link
Member

D0nPiano commented Jul 31, 2017

Wouldn't it be fine if we keep the update function like it is, and the backend is just not updating the stats when getting PATCH requests?
I'm fine with either one of the versions though, and 2 definitely makes sense, too. And frontend wise it wouldn't be hard to implement either way...

@tiltec

This comment has been minimized.

Copy link
Member

tiltec commented Jul 31, 2017

Yes, the backend doesn't have any problem if it gets more fields than expected.

@djahnie

This comment has been minimized.

Copy link
Member

djahnie commented Mar 28, 2018

We collect statistics into influxdb, now it needs figuring out what statistics we want to show on karrot itself. We are yet unsure if we should let Django read from InfluxDB or write statistics into PostgreSQL.

@tiltec

This comment has been minimized.

Copy link
Member

tiltec commented Jun 29, 2018

Silvia from Efa asked

Wenn ich auf den Betrieb gehe und mir dort das Feedback ansehe, dann finde ich oft nur das letzte Feedback, oder maximal das Feedback aus dem Monat.
D.h. auch bei der Menge, die insgesamt in den Betrieb gerettet wurde steht dann z.B. für Bäckerei Darmstädter nur 52 kg, vom 23.+27. Juni.
Dabei bin ich dort 2x pro Woche. Und es waren in diesem Monat bestimmt schon über 200 kg.
Könntet Ihr das so machen, dass die Mengen über den Monat und über das Jahr angegeben werden?
Das wäre uns eine sehr wichtige Funktion, damit wir Rechenschaft ablegen können.

I'll raise the priority of this issue, but details need yet to be figured out.

@tiltec

This comment has been minimized.

Copy link
Member

tiltec commented Jul 10, 2018

Next steps:

  • analyze response time for store statistics endpoint (via grafana.yunity.org)
  • add some kind of caching, either via django caching infrastructure or by precalculating values in the database
  • make store statistics more prominent in the frontend (currently they are quite hidden on the feedback page)
  • add group statistics endpoint
  • add user statistics endpoint
  • add fancy statistics UI to frontend
@nicksellen

This comment has been minimized.

Copy link
Member

nicksellen commented Jul 27, 2018

@tiltec

This comment has been minimized.

Copy link
Member

tiltec commented Oct 31, 2018

Group statistics ("kg") were requested by Foodsharing Warszawa again. Nick commented that our stats are probably unreliable because people might not give feedback or enter the wrong numbers. Janina says that the exact numbers don't really matter and we should publish them. I think we could publish a roughly rounded number ("more than 100kg" or "about 150kg") and show the number of feedback.

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