Datenmethodik
Wie Alveos Kennzahlen zur Software-Verbreitung sammelt, speichert, transformiert und kennzeichnet.
Grundsätze
Jede Kennzahl muss Quelle, Bedeutung, Aktualität, Abdeckung und Transformation nennen. Fehlende Daten bleiben fehlend: Alveos füllt Ausfälle nicht mit Schätzwerten. „Offiziell“, „verifiziert“ oder „unabhängig“ wird nur verwendet, wenn die Quelle diese Aussage tatsächlich trägt.
Quellenklassen
- Öffentliche Anbieterquelle: direkte öffentliche APIs oder Einträge wie VS Code Marketplace, Open VSX, GitHub Releases, PyPI und Packagist.
- Öffentlicher Datensatz / vertrauenswürdiger Dritter: benannte Datensätze wie PSF BigQuery oder PypiStats.
- Produkteigene Telemetrie: das verbundene Produkt sendet Lifecycle-Ereignisse an Alveos (Beacon; Streaming Zebra bald verfügbar). Die Zahlen kommen aus dem Produkt und der Zählweise des Publishers — ereignisgesteuert, nicht von einem Marktplatz abgeholt.
- Manueller Publisher-Import: etwa vom Publisher bereitgestellte VS-Code-Publisher-Hub-Daten. Sie bleiben von öffentlichen Gallery-Zählern getrennt.
Bedeutung der Kennzahlen
Was die Quelle liefert, speichert Alveos. Was sie nicht liefert, wird hier nicht erfasst.
| Quelle | Geliefert und erfasst | Fehlt |
|---|---|---|
| VS Code Marketplace (Gallery) | Öffentliche Zähler (downloadCount, install, updateCount) — Akquisition |
Aktuell aktive Installationen: die Gallery liefert das nicht, Alveos erfasst es hier nicht |
| Open VSX | downloadCount (VSIX-Downloads) |
Aktive Installationen, eindeutige Nutzer, Deinstallationen: weder geliefert noch erfasst |
| GitHub Releases | download_count der Release-Dateien |
Klone, private Repositories, Quellarchive |
| PyPI / PypiStats | Datei-Downloads (Tagesserie ohne Spiegel) | Eindeutige Nutzer und Installationen, weil die Quelle sie nicht zählt |
| Packagist | downloads.total / monthly |
Installationen und eindeutige Nutzer |
| Beacon / Lifecycle | Vom Produkt gemeldete Install-, Update-, Uninstall-, Usage- und Build-Ereignisse | Marktplatz-Zähler; Uninstall oft unvollständig |
| Publisher-Hub (Import) | Daily-Stats-Tage, die der Publisher liefert | Keine Gallery-SSOT; Website-VSIX nur, wenn die Datei die Spalte hat |
Zähler mit unterschiedlicher Bedeutung werden nicht stillschweigend als dieselbe Kennzahl dargestellt.
Erfassung, Aktualität und Lücken
Öffentliche Stores holt Alveos einmal täglich um 05:20 Europe/Berlin. Gespeichert wird der heutige UTC-Tag. Ein fehlgeschlagener Abruf überspringt den Tag, behält die Historie und schreibt keine Nullen. Gallery, Open VSX, GitHub, PyPI-JSON, PypiStats und Packagist werden nicht drei Tage rückwärts nachgezogen.
Was im Graphen passiert: Ab dem ersten gespeicherten Tag bleibt die durchgezogene Linie auf dem letzten bekannten Stand (Step-Hold). Fehlt dazwischen ein Abruf, zeichnet Alveos denselben Stand gestrichelt — letzter bekannter Wert, keine Hochrechnung und keine Trendkurve über den realen Punkten. Fehlende Tage im Fenster werden markiert. Tage vor der Verbindung sind keine Lücken.
Liegt der letzte erfolgreiche Tag zwei oder drei Tage zurück, gilt die Reihe als verzögert; ab dem vierten Tag als veraltet. Das ist eine Anzeige, kein Nachzug.
Zwei Ausnahmen schreiben jüngere Tage nach, wenn der nächste Abruf gelingt: Streaming Zebra speichert D−2 und D−1 aus der Summary; PyPI-Länder (BigQuery, zahlende Tarife) schreiben die letzten sieben UTC-Tage erneut. Publisher-Import und Beacon sind kein Tagesabruf und gelten nicht als verpasste Lücken.
Transformation und Vergleichbarkeit
Alveos behält rohe Anbieterwerte und kennzeichnet abgeleitete Werte wie Differenzen kumulativer Zähler, Summen, Verhältnisse, importierte Werte und gefilterte Partitionen. Direkte Auslieferungs- und GitHub-Kanäle, die dieselbe Auslieferung beschreiben können, bleiben getrennt. Streaming-Zebra- und Beacon-Updates werden nicht doppelt addiert.
Reproduzierbare Exporte
CSV- und JSON-Exporte enthalten Anbieter, externe ID, Quellenklasse, Kennzahlenbedeutung, Abdeckungsbeginn, Rhythmus, Transformationsversion, Quellenlink und einen SHA-256-Zeilenhash. Historische Snapshots besitzen derzeit UTC-Tagesgenauigkeit: fetched_on enthält den Tag, time_precision ist day, und fetched_at bleibt leer statt eine Uhrzeit zu erfinden.
Anbieterreferenzen
| Quelle | Abruf | Rhythmus |
|---|---|---|
| VS Code Gallery, Open VSX, GitHub Releases, PyPI-JSON, PypiStats, Packagist | Cron speichert den heutigen UTC-Tag | Täglich 05:20 Europe/Berlin |
| PyPI-Länder (BigQuery, zahlende Tarife) | Upsert der letzten sieben UTC-Tage | Derselbe Cron |
| Streaming Zebra (bald verfügbar) | Summary; heilt D−2 und D−1 | Derselbe Cron |
| Beacon | Produkt sendet | Ereignisgesteuert, kein Tagesabruf |
| Publisher-Hub | xlsx-Import | Beim Import |
- VS Code Marketplace
- Open VSX
- GitHub Release Assets API
- Öffentliche PyPI-Daten in BigQuery
- Packagist API
Auditierbare Korrekturen
Angemeldete Publisher melden unter Datenkorrekturen eine bereits gespeicherte Verbindung: UTC-Tag, Kennzahl (Downloads, Installationen oder Updates), vorgeschlagenen Wert und Begründung. Die Anfrage hält den beobachteten Rohwert fest. Eine Korrektur füllt keine fehlenden Abrufe und schreibt keine Schätzung in eine Lücke.
Prüfung, Annahme, Ablehnung, Anwendung und Ersetzung sind nur ergänzende Ereignisse in einer manipulationssichtbaren Hash-Kette. Eine angewendete Korrektur ist ein versioniertes Lese-Overlay; der Provider-Snapshot bleibt unverändert. Graphen, Summen und Exporte verwenden das aktive Overlay. CSV/JSON nennen mit correction_request_ids und correction_original_json Anfrage und ursprüngliche Provider-Werte. Eine neuere Freigabe widerruft das alte Overlay, bewahrt aber beide Audit-Historien.
Fragen oder vermutete Datenfehler: support@alveos.eu.