Usually, with PII data on persons we set a minimum for calculating averages so the data cannot be disambiguated and persons identified.
Essentially, such data should not be disaggregated at small numbers. There may be a standard at 10, that is usually 20 though for power to detect differences. So, for example, if you have <10 persons in a [sub] category then you don't report out on that [sub] category.
Security and GDI teams may be able to provide additional insights and feedback.

Thresholds for aggregating and disaggregating may also be relevant for T329006

FYI, this related dashboard may be of interest
https://www.mediawiki.org/wiki/Growth/Mentor_dashboard

Usually, with PII data on persons we set a minimum for calculating averages so the data cannot be disambiguated and persons identified.
Essentially, such data should not be disaggregated at small numbers. There may be a standard at 10, that is usually 20 though for power to detect differences. So, for example, if you have <10 persons in a [sub] category then you don't report out on that [sub] category.
Security and GDI teams may be able to provide additional insights and feedback.

Hey @Iflorez, how will that work if event organizers are able to view data at an individual level anyway (F35861130)? Will the detailed view of the Participants tab be unavailable once data is aggregated, after the 90-day window?

@sguebo_WMF I have reservations about showing sensitive data at an individual level within the organizer dashboards. Generally, we don't report out on small numbers so the data cannot be disambiguated and persons identified or the data put at risk. My recommendation from a data privacy perspective is to show aggregated data only and keep the PII in the back end for 90 days, during which time participants can update their answers, after which time we anonymize the PII data and keep only the aggregated data.

As far as aggregated data, I recommend reporting out when we have more than x persons in a [sub]category; below that we could either not report out or report, for example a compilation "other <x"

My recommendation from a data privacy perspective is to show aggregated data only and keep the PII in the back end for 90 days, during which time participants can update their answers, after which time we anonymize the PII data and keep only the aggregated data.
As far as aggregated data, I recommend reporting out when we have more than x persons in a [sub]category; below that we could either not report out or report, for example a compilation "other <x"

Hey @Iflorez. On principle, I agree with the idea of hiding subcategories if their data is too small. In that sense, displaying data at an individual level would not be acceptable as it would defeat the very purpose of aggregation.

However, while I am in favor of a more conservative privacy stance here, I think it makes sense to evaluate its impact on the extension's usefulness.
Could someone clarify what scenarios or use cases would require event organizers to view detailed participant PII? @ifried @cmelo

Displaying aggregate PII data
Prototype

cc @cmelo

@gonyeahialam Closing this as we think it is complete (in backlog refinement), please let me know if this is a mistake!