Skip to content
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

How do you estimate number of users uploading keys #23

Open
ndegendogo opened this issue Jan 18, 2021 · 5 comments
Open

How do you estimate number of users uploading keys #23

ndegendogo opened this issue Jan 18, 2021 · 5 comments

Comments

@ndegendogo
Copy link

Wie berechnest / schätzt du eigentlich inzwischen die Anzahl der User, die DEK keys hochladen? Oder ist das eine Kennzahl, die das RKI inzwischen veröffentlicht?
Seit cws v 1.9 (?) / den neuen TRL Zuweisungen, wo 'days since symptoms' mit eingerechnet werden stimmt ja der 'naive' Ansatz mit dem TRL=6 nicht mehr?

@ndegendogo ndegendogo changed the title How do you rstimate number of users uploading keys How do you estimate number of users uploading keys Jan 18, 2021
@micb25
Copy link
Owner

micb25 commented Jan 18, 2021

Mit der Umstellung auf CWS v1.9 haben die Schätzungen für mich unplausible Werte ergeben (zu hoch). Zusätzlich gibt es mit der neuen Version des ENF auch ein Feld reportType, was seltsamerweise für eine nicht unerhebliche Anzahl an Schlüsseln auf RECURSIVE gesetzt war, obwohl dies laut Dokumentation reserved for future sein soll.

Unter diesen Umständen habe ich mich dazu entschlossen, die Personenzahl eher konservativ (Minimum) zu schätzen, indem momentan die Anzahl der hochgeladenen TEKs durch 13 (maximale Anzahl hochladbarer TEKs) dividiert wird. Die reale Quote lag wohl eher bei ca. 11 TEKs / Person.

Was mich stört ist, dass es seit Monaten detaillierte tagesaktuelle Backend-Daten gibt, aber nicht offiziell herausgegeben werden. Stattdessen müssen die Schlüsseldaten täglich heruntergeladen und prozessiert werden mit zunehmend sinkender Genauigkeit. Ich hoffe, dass sich dies in naher Zukunft ändert, weil ich es als unproduktiv sehe, Daten abzuschätzen, die eigentlich an anderer Stelle präzise vorliegen und diese man nur veröffentlichen müsste.

Hier einmal ein Auszug aus diesen tagesaktuellen JSON-Daten:

{
   "date":"2020-10-29",
   "app_downloads_cum":21254005,
   "key_uploads":2558,
   "test_total":83583,
   "total_redeemed":1313,
   "total_not_redeemed":679,
   "labs_total":165,
   "labs_done":152,
   "infections":16774,
   "day_of_week":"Thu",
   "week_of_year":44
}

@ndegendogo
Copy link
Author

ndegendogo commented Jan 18, 2021

Die Felder für den Report-Type sowie für den "days since onset of symptoms" hat man bei cwa "gekapert" und mit anderer Bedeutung hinterlegt (nämlich für die 8-stufige Codierung des TRL, die das RKI wohl auch mit der neuen ENF/ENS Version beibehalten wollte).
Thomas Klingbeil hat hierzu einen Vortrag im CCC gehalten, wo er das erklärt.

@ndegendogo
Copy link
Author

Was mich stört ist, dass es seit Monaten detaillierte tagesaktuelle Backend-Daten gibt, aber nicht offiziell herausgegeben werden.

Ja, da gebe ich dir 100% recht. Es ist ärgerlich; es wäre absolut kein großer Mehraufwand, und würde Transparenz und Vertrauen schaffen.

@ndegendogo
Copy link
Author

Report type = recursive steht für TRL= 1 oder 2, je nachdem ob DSOS auf 1 oder 2 steht.
Ich habe das in den vergangenen 3 Wochen überprüft. Es ist tatsächlich konsistent und redundant codiert.

@ndegendogo
Copy link
Author

See the newest release cwa 1.11 with statistics

micb25 added a commit that referenced this issue Feb 2, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants