Jak działają dane społeczności to dedykowany widok GeoLira dla tej części obserwatorium. Łączy interfejs właściwy dla danej trasy z tymi samymi zasadami źródeł, świeżości, prywatności i dowodowości, które obowiązują w całej platformie.
Od formularza do agregatu prowadzi kilka bramek
Check-in trafia najpierw do walidacji schematu i zgody. Dozwolone są wyłącznie znane pola, wartości 1-5, dozwolone kategorie oraz opcjonalny kod kraju w formacie dwóch liter. System sprawdza także local_date i odrzuca rekordy, które nie spełniają kontraktu. Dopiero zaakceptowane rekordy mogą wejść do agregacji.
Filtr strukturalny usuwa duplikaty i rekordy spoza okna
CommunityPulseAbuseFilter wymaga właściwego schematu, evidence class, wersji zgody i poprawnego submission_id. Odrzuca duplikaty, rekordy z błędnym czasem, niewłaściwym locale, niepoprawnym kodem kraju lub wartościami spoza kontraktu. Ten filtr nie fingerprintuje użytkowników i nie jest obietnicą pełnej odporności na automatyczne zgłoszenia, dlatego warstwa przyjmowania wymaga także zewnętrznego rate limitu.
Agregacja zachowuje granice prywatności i znaczenia
Po filtracji system liczy statystyki już od 1 kwalifikującego się zgłoszenia i od pierwszego wskazania kategorii. Przy kolejnych check-inach wartości stają się średnią aktualnej próby. Identyfikator indywidualnego zgłoszenia nie staje się publiczny, ale przy próbie równej 1 agregat może odzwierciedlać odpowiedź jednej osoby. Agregat pozostaje COMMUNITY_SELF_REPORT, a Community Pulse pozostaje AUTHORED_INDEX.