Clarify when (and how) users take events into account

[fe51]

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 ?

• Pro:
  • Feature easy to implement
  • Long-term storage of this information, and ease of implementation of associated dashboarding (dashboard building stats relating to our performance, requesting only the api).

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

• Cons : too speficic to be stored in the api ?

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]

@blenzi @frgfm

@MateoLostanlen @GHCamille

[GHCamille]

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]

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]

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:

• I think it's a dangerous direction to add a viewed by/at.
• acknowledged by will only be useful if anyone who has access to this is a registered user (only Ardèche can acknowledge the alerts /events of their cameras either way). So on the firefighters side, what was the exact feedback?

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

[blenzi]

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: * I think it's a dangerous direction to add a viewed by/at. * acknowledged by will only be useful if anyone who has access to this is a registered user (only Ardèche can acknowledge the alerts /events of their cameras either way). So on the firefighters side, what was the exact feedback? 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 GitHub<#274 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ADLSG2EQQE2P4O2F2FUTDM3X6LB2FAVCNFSM6AAAAAA3FEWW3CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONJSGA3TCNJXGI>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[GHCamille]

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 ...

[frgfm]

Open question but is the current mechanism solving this?

• we do have Posthog in production for "user action" monitoring
• if this is on the frontend side, we should integrate Posthog over there (happy to help, their Python SDK is quite easy)

My intuition is that if there's anything remaining, that would be adding more "signal capture" on the platform side using this Posthog integration I mentioned.