search

pyronear / pyro-api

Alert Management API for wildfire prevention, detection & monitoring. Built with FastAPI & PostgreSQL
Apache License 2.0
21 stars 9 forks source link

Clarify when (and how) users take events into account #274

Open fe51 opened 1 year ago

fe51 commented 1 year ago

Hi there ✋

Feature

Know when (by whom, and how) an alert/event was seen

Motivation

As of today, knowledge of how events are taken into account by users is limited to is_acknowledged ,(a boolean) information.

The problem is that it doesn't contain any information about when (I think, tell if I am wrong) the information was seen and moreover it means: "I have seen this alert/event" AND "I no longer wish to see it on the platform".

However, having information about when the information was considered is important if we want to be able to estimate the time saved for firefighter (compared, for example, with an alert received via an emergency call).

Solutions ?

Update in pyro-api

A solution could be to add new fields to event table;

Field Type
viewed_at datetime
viewed_by user_id
viewed_with UI_type (plateform, telegram, mail, etc)

However : The suggestion here maybe poses a problem if several users see the information (only insert if field are empty to store the earlier info) (Maybe, as admin users, no info should be sent when seeing an alert ? so update those field only if the user_id is associated to the group_id of the owner_id of the device that have sent the alert ?

It will be useful for the feedback we'll be doing on the summer experiments !

Web Analytics App

Those information could be obtained setting up a web analytics app (like matomo, similar to google analytics but respecting privacy)

This will require a benchmark of the web analytics solution we want to use. Implementing it, and I tend to think that although it's necessary to implement one in general, for this specific use case, having the information in the API makes it easier to get the stats / performance of our solution. Moreover (I do not know it we would be able to monitor with ease those info if it cames from telegram or mail)

What do you think ? Happy to discuss it ! 😄
This is a fairly important feature if we want to be able to get feedback from our experiments this summer !

Of course, there will be further developments to come on the platform side. We'll open dedicated issues once the back-end is clear :)

fe51 commented 1 year ago

@blenzi @frgfm

@MateoLostanlen @GHCamille

GHCamille commented 1 year ago

Hello,

I agree that it would be an information of great value. But I have a question : by "viewed", do you mean "acknowledged" ? Because both can be handy (know when someone view an alert, and the delta before they acknowledge it, or in the future, is it the same person whom views the alert than the person who acknowledge it ...)

blenzi commented 1 year ago

Hello!

I also agree it is very useful to have it and to distinguish "acknowledged" by/at and "viewed" by/at. The former is related to who is responsible for "I no longer wish to see it on the platform". I would add those fields to the event table.

The latter is more a measurement of audience, if I understand well. Therefore there can be multiple users per alert and it needs another table.

frgfm commented 1 year ago

Hey there :wave:

Similarly to the others, I think there is a distinction between a passive "viewed by XYZ" and "acknowledged by XYZ". The second involves the person / make that person responsible to act on the information/communicate it.

Also, while "is_acknowledged" is a flag. The viewed by / acknowledged by or their timestamps are event payloads. For the sake of the maintenablity of the core API, I think we always need to assess whether we are talking about state information or events.

In truth, we've added the "alerts" as intermediate signals to update the state of "events". Either way, about what should be on the backend vs frontend:

Regarding analytics, I would suggest PostHog, I've used it and it's very useful / easy to add!

blenzi commented 1 year ago

Hi FG,

Quite often we (admins) end up acknowledging some events. Generally, if multiple users have the right to acknowledge a given event, it can be useful to know who did it and if the event is assessed as a wildfire or something else.

From: F-G Fernandez @.> Sent: Sunday, October 8, 2023 5:34:58 PM To: pyronear/pyro-api @.> Cc: Bruno Lenzi @.>; Mention @.> Subject: Re: [pyronear/pyro-api] Clarify when (and how) users take events into account (Issue #274)

Hey there 👋

Similarly to the others, I think there is a distinction between a passive "viewed by XYZ" and "acknowledged by XYZ". The second involves the person / make that person responsible to act on the information/communicate it.

Also, while "is_acknowledged" is a flag. The viewed by / acknowledged by or their timestamps are event payloads. For the sake of the maintenablity of the core API, I think we always need to assess whether we are talking about state information or events.

In truth, we've added the "alerts" as intermediate signals to update the state of "events". Either way, about what should be on the backend vs frontend:

Regarding analytics, I would suggest PostHog, I've used it and it's very useful / easy to add!

— Reply to this email directly, view it on GitHubhttps://github.com/pyronear/pyro-api/issues/274#issuecomment-1752071572, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ADLSG2EQQE2P4O2F2FUTDM3X6LB2FAVCNFSM6AAAAAA3FEWW3CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONJSGA3TCNJXGI. You are receiving this because you were mentioned.Message ID: @.***>

GHCamille commented 1 year ago

Backing up what Bruno is saying.

I would add that it could be useful to have the stats of how long it takes between viewing the alert and acknowledging it. For instance we could see if there is a huge impact when changing things on the platform, such as adding the bounding box, making a gif ...