Git Scraping

Ein schneller Blick auf die Webseite des Fitnesscenters zeigte, dass dort immer die aktuellen Belegungszahlen publiziert werden. Ich vermute, dass diese Zahl direkt vom Einlass-System stammen, da jeder Gym-Besucher und jede Gym-Besucherin sich beim Drehkreuz am Eingang mit einem Badge anmelden und zum Hinausgehen wieder abmelden muss.

Damit war die Basis für ein Scraping, also das automatisierte Auslesen, der Daten gelegt. Ich nutze Python und den Ansatz Git Scraping (vgl. den Blogpost von Simon Willison). Dabei handelt es sich um eine Methode, bei der Daten regelmässig aus einer Webseite ausgelesen und in einem Git-Repository (in der Git-History) gespeichert werden. So entsteht automatisch eine Zeitreihe, die sich anschliessend leicht analysieren lässt.

Ich selbst besuche den Fitnesspark Zürich Stadelhofen. Es gibt aktuell 16 Fitnessparks in der Schweiz. Wenn ich die Daten von einem Fitnesscenter sammeln kann, kann ich das natürlich auch gleich für alle machen…

Mit einem weiteren Python-Skript kann ich die ganze Zeitreihe auslesen und dann für eine kleine Datenanalyse verwenden.

Explorative Datenanalyse

Jetzt da wir eine Zeitreihe haben, ist es Zeit, diese etwas genauer unter die Lupe zu nehmen. Dazu müssen wir uns zuerst einen Überblick verschaffen und verstehen, welche Daten uns vorliegen.

df = pd.read_csv("occupancy_history.csv", parse_dates=[0])
df_stadi = df[df.gym == "Fitnesspark Zürich Stadelhofen"]

fig, ax = plt.subplots(figsize=(20,10))
df_stadi.plot(kind='line', y='occupancy', x="timestamp_utc")

Schon der erste Plot zeigt: Im August klafft eine Lücke, die Zahlen sinken zum Jahresende und steigen im Januar sprunghaft an. Ein klarer Hinweis auf Neujahrsvorsätze.

Datenbereinigung

Um die Daten weiter zu analysieren, lohnt es sich, ein paar Bereinigungen durchzuführen. Dies ermöglicht es dann in einem nächsten Schritt bessere Auswertungen zu machen. Dieser Schritt ist essenziell um die Datenqualität zu steigern. Ich setze folgende Verbesserungen um:

• Zeitangaben auf Lokalzeit in der Schweiz (CET/CEST) umstellen
• Wir haben aus dem Scraping in den Rohdaten bis zu drei Werte pro Stunde. Für eine gute Vergleichbarkeit ist es empfehlenswert, die Zeitreihe auf Stundenmittelwerte zu sampeln.
• Die Fitnesscenter haben unterschiedliche Öffnungszeiten. Es lohnt sich daher, die Daten ausserhalb der Öffnungszeiten zu entfernen.

# Zeitzone und Zeit-Features
df["timestamp_utc"] = df.timestamp_utc.dt.tz_localize("UTC")
df["timestamp_cet"] = df.timestamp_utc.dt.tz_convert("Europe/Zurich")
df['hour'] = df['timestamp_cet'].dt.hour
df['dow'] = df['timestamp_cet'].dt.dayofweek  # 0=Mo, 1=Di, ...
df['weekday'] = df['timestamp_cet'].dt.day_name("de_CH")  # Montag, Dienstag, ...

# Werte ausserhalb der Öffnungszeiten entfernen
df = df[(df.hour >= df.start_hour) & (df.hour <= df.end_hour)]

# Re-Sampling auf Stundenmittelwerte
hourly = (df.set_index('timestamp_cet')
            .groupby('gym')
            .resample('1H')
['occupancy'].mean()
            .dropna()
            .reset_index())

Heatmap – oder: Wann sind die meisten Personen im Fitnesscenter?

Nach dieser Vorbereitung sind wir nun bereit für eine erste vertiefte Analyse. Uns interessiert ja, wann besonders viele oder wenige Personen im Fitnesscenter sind. Dazu eignet sich unter anderem eine Heatmap, bei der auf der einen Achse die Wochentage und auf der anderen Achse die Uhrzeiten sind. Schauen wir uns das zuerst über alle Standorte hinweg an:

# Mittelwert pro Wochentag und Stunde
agg = df.groupby(['weekday', 'hour'])
['occupancy'].mean().reset_index()

# Wochentage in richtiger Reihenfolge
order = ['Montag','Dienstag','Mittwoch','Donnerstag','Freitag','Samstag','Sonntag']
pivot_agg = agg.pivot(index='weekday', columns='hour', values='occupancy').reindex(order)

# Heatmap Wochentag × Stunde
plt.figure(figsize=(12,6))
sns.heatmap(pivot_agg, cmap='viridis', annot=False)
plt.title('Aggregierte Belegung: Wochentag × Stunde')
plt.xlabel('Stunde')
plt.ylabel('Wochentag')
plt.show()

Die Heatmap bestätigt das Bauchgefühl: Montag bis Mittwoch von 18 bis 20 Uhr sind über alle Fitnesscenter hinweg die Hotspots. Überraschend: Kein Mittagspeak – und sonntags ist mehr los als samstags.

Spannend ist der Vergleich von verschiedenen Fitnesscentern, da sich die Nutzungsmuster zum Teil stark unterscheiden. Die Skalen der einzelnen Visualisierungen oben sind jedoch nicht identisch – was den Vergleich stark erschwert. Ein grosses Studio wirkt in den Visualisierungen voller, obwohl es mehr Platz bietet als ein kleineres. Deshalb berechne ich im nächsten Schritt aus den absoluten Zahlen die Belegung in Form von «Personen pro 100m²». Damit werden die Visualisierungen vergleichbar.

# Berechne die "Dichte" pro 100 m²
df['density_100m2'] = df['occupancy'] / (df['training_area_m2'] / 100)

heat_all = df.groupby(['weekday','hour'])
['density_100m2'].mean().reset_index()
pivot_all = heat_all.pivot(index='weekday', columns='hour', values='density_100m2').reindex(order)

plt.figure(figsize=(10,5))
sns.heatmap(pivot_all, cmap='viridis', annot=False)
plt.title(f'Belegungsdichte (Personen pro 100 m²)')
plt.xlabel('Stunde')
plt.ylabel('Wochentag')
plt.show()

Und wenn wir jetzt diese Skala bei allen Fitnesscentern anwenden, dann kann man die relativ «vollen» deutlich von den relativ «leeren» Fitnesscentern unterscheiden:

Trend, Saisonalität und Ausreisser

Nachdem wir uns nun intensiv mit der Belegung in der Woche befasst haben, wollen wir zum Abschluss noch etwas zum Trend und Saisonalität der Zeitreihe herausfinden. Ich habe Daten bisher während circa 10 Monaten, noch nicht ein ganzes Jahr gesammelt (März 2025 bis Januar 2026). Das heisst: Diese Auswertung ist noch etwas mit Vorsicht zu geniessen.

Für diese Analyse verwenden wir die «Sesonal-Trend decomposition using LOESS (STL)»-Methode aus dem statsmodels Python-Paket. Mit STL zerlege ich die Zeitreihe in Trend, Saisonalität und Rest.

• Trend: Der Trend zeigt die langfristige Entwicklung der Zeitreihe. Nimmt die Nutzung eher zu oder ab oder bleiben die Werte mehr oder weniger stabil?
• Saisonalität: Gibt es regelmässige, wiederkehrende Muster (zum Beispiel Sommer vs. Winter)
• Rest: Im Rest finden sich mögliche Ausreisser bzw. diejenigen Anteile der Variabilität in den Daten, die sich nicht mit Trend und Saisonalität erklären lassen. Hier können zum Beispiel Anomalien erkannt werden.

Schauen wir uns diese drei Komponenten für den Fitnesspark Zürich Stockerhof an:

from statsmodels.tsa.seasonal import STL

# Aggregation auf Tagesmittelwerte (für klare Saisonalität)
df_stockerhof = df[df.gym == "Fitnesspark Zürich Stockerhof"].dropna().reset_index()
daily = df_stockerhof.groupby('date')
['occupancy'].mean()
daily.index = pd.to_datetime(daily.index)

# STL-Dekomposition
# period=7 für Wochenmuster (7 Tage)
stl = STL(daily, period=7, robust=True)
result = stl.fit()

# Zugriff auf Komponenten
trend, seasonal, resid = result.trend, result.seasonal, result.resid

Wir können sehen, dass der Trend von Mai bis Juli klar abnimmt, dann gibt es einen starken Peak im Sommer (aber Achtung: die Y-Achse beginnt nicht bei 0), der dann erst wieder etwas abflacht, und im Herbst nochmals zunimmt. Im Dezember gehen die Zahlen zurück und im Januar lassen sich die umgesetzten Neujahrsvorsätze anhand dem steilen Anstieg gut ablesen. Bei der Saisonalität ist ein klarer Wochengang erkennbar mit Spitzen am Montag und Senken gegen Ende der Woche.

Die Rest-Komponente eröffnet uns die Möglichkeit, Anomalien oder Ausreisser zu erkennen. Wenn wir die Saisonalität und den Trend zusammennehmen, bildet dies die geschätzten Werte unserer Zeitreihe ohne Ausreisser ab. Wenn wir diese Kurve mit jener der tatsächlichen Zeitreihe vergleichen, können wir visuell die (grossen) Unterschiede sehr klar erkennen.

Um Ausreisser (in normalverteilten Daten) zu erkennen, wird in der Statistik häufig auch auf die Standardabweichung (standard deviation, abgekürzt stddev oder std) abgestützt. Diese beschreibt für eine Verteilung, wie stark die einzelnen Werte um den Durchschnittswert (mean) streuen. Als Ausreisser angeschaut werden dann häufig Werte, die mehr als 3 Standardabweichungen vom Durchschnittswert entfernt liegen. Ermitteln wir diese Werte mit visueller Unterstützung:

resid_mean = resid.mean()
resid_dev = resid.std()
lower = resid_mean - 3*resid_dev
upper = resid_mean + 3*resid_dev

plt.plot(resid, label='Rest', color='blue')
plt.fill_between([daily.index.min(), daily.index.max()], lower, upper, color="g", alpha=0.25, linestyle="dashed")

Überall dort, wo die blaue Linie den grünen Bereich verlässt, haben wir mit dieser Operationalisierung einen Ausreisser. Wir sehen deutliche Ausreisser Ende Juli, dann noch einen Anfang August und Ende Dezember. Was mögen die Gründe für diese Anomalien sein? Schauen wir uns die Ausreiser in der Zeitreihe genauer an:

anomalies = daily[(resid < lower) | (resid > upper)]
plt.plot(daily, label='Tagesmittelwerte', color='blue')
plt.scatter(anomalies.index, anomalies.values, color="r", marker="D", label="Ausreisser")

Die Ausreisser sind vom 28. bis 31. Juli und am 9. August. Der erste lässt sich sehr einfach erklären: Der Fitnesspark Stockerhof war vom 28. Juli bis 3. August 2025 wegen Revision geschlossen. Und der (kleinere) Ausreisser am 9. August steht vielleicht auch in diesem Zusammenhang: Wegen der Revision könnten aussergewöhnlich viele Personen ihr Training in der Woche vom 4. bis 8. August nachgeholt haben; im Vergleich fällt dann der Samstag 9. August etwas ab. Der letzte Ausreisser ist am Heiligabend (24. Dezember), wo offensichtlich weniger Personen im Fitnesscenter sind als sonst.

Sämtlicher Code und die Daten sind auf GitHub frei verfügbar. Sobald die Zeitreihen etwas länger werden, könnten wir mit Machine Learning auch gut ein Prognose-Modell bauen, um die Belegung vorherzusagen.

Open Source als Lösung?

Tatsächlich kann die Veröffentlichung als Open Source zur Vertrauensbildung beitragen. Eine Organisation gibt damit bekannt dass sie a) nichts zu verstecken hat und b) sich dem öffentlich Review stellen will

Und gerade in besonders sensiblen Bereichen kann diese Massnahme dazu beitragen, die Akzeptanz zu steigern. In Bereichen wie den Berechnungsgrundlagen für Prognosen oder statistischen Auswertungen sollte es zum guten Ton gehören, seinen Code zu veröffentlichen. Code, der in der Verwaltung entwickelt wird, sollte auch frei von Geschäftsgeheimnissen sein, sodass sich diese Bereiche besonders gut eignen. Das sieht übrigens auch der Gesetzgeber so und hat deshalb per 1. Januar 2024 das Bundesgesetz über den Einsatz elektronischer Mittel zur Erfüllung von Behördenaufgaben (EMBAG) in Kraft gesetzt. In Art. 9 Abs. 1 heisst es denn auch:

Die diesem Gesetz unterstehenden Bundesbehörden legen den Quellcode von Software offen, die sie zur Erfüllung ihrer Aufgaben entwickeln oder entwickeln lassen, es sei denn die Rechte Dritter oder sicherheitsrelevante Gründe würden dies ausschliessen oder einschränken.

Das Gesetz umfasst neben der Open Source Thematik auch noch das Thema Open Data und Schnittstellen. Ich habe mich in den letzten Wochen intensiv mit dem EMBAG auseinander gesetzt. Das Resultat davon ist der EMBAG-Check, der Organisationen dabei helfen soll, zu prüfen, ob und wie sie die Anforderungen, die das neue Bundesgesetz stellt, erfüllen können. Es handelt sich um eine Checkliste, die vollgepackt ist mit wichtigen Hinweisen und nützlichen Tipps zu Themen wie organisatorischen Aspekten, Open Government Data, Open Source Software oder technischen Schnittstellen.

Open Source ist keine Wunderwaffe

Wichtig ist aber auch zu betonen, dass kein System durch die reine Veröffentlichung von Code besser wird. Wer soll denn die 70’000 Zeilen Code vom BSV reviewen? Es ist ein Trugschluss, dass dies eine Schar von Freiwilligen dann schon erledigt. Open Source besagt nur, dass ich die Möglichkeit habe, den Code anzuschauen, wenn ich denn möchte. Es sagt nichts darüber aus, ob das auch tatsächlich passiert oder ob die gefundenen Fehler behoben werden. Gerade im letzten März konnten wir die Nachrichten zum gefundenen Backdoor in den XZ Utils lesen, das von einem Angreifer im Open Source Quellcode versteckt wurde. Das Ereignis führte zu Diskussionen, ob kritische Teile der Infrastruktur von der Arbeit von Freiwilligen abhängen sollten.

Die BSV hat angekündigt, dass es zwei Forschungsinstitute damit beauftragt hat, unabhängige Modelle zu entwickeln, um die korrigierten Werte zu validieren. Das scheint mir ein guter erster Schritt zu sein. Die Veröffentlichung des Codes sollte aber zwingend auch noch erfolgen, sodass sich alle Interessierten selbst ein Bild machen können. Auch wenn nicht jede Bürgerin und jeder Bürger die Expertise für solche Berechnungen besitzt, so gibt es diese Leute zweifelsohne. Und gerade im Bereich der AHV, wo die Meinungen stark auseinander gehen und jede Seite glaubt „recht“ zu haben, sind verlässliche Zahlen, die sich sogar noch überprüfen lassen, unersetzbar.

Es führt somit kein Weg vorbei, am Aufbau einer Community oder beim Aufsetzen eines Bug-Bounty Programms. Einen anderen Ansatz hat die Schweizerische Post gewählt: sie hat mit ihrem E-Voting-Community-Programm Sicherheitsforschern aus aller Welt ermöglicht den Quellcode ihrer E-Voting Lösung zu analysieren. Der Code ist zwar offen zugänglich, derzeit aber (noch?) nicht unter einer Open Source Lizenz veröffentlicht.

Welche weiteren Vorgaben oder Best Practices gibt es sonst noch?

Ist ihre Organisation EMBAG-ready?

Unter https://embag-check.ch haben wir eine Checkliste mit obligatorischen Vorgaben und fakultativen Best Practices zusammengestellt. Die Checkliste hilft dabei, Handlungsbedarf zu erkennen und wichtige Fragen zu klären wie:

❔ Ist meine Organisation vom EMBAG betroffen?
❔ Welche Software muss als Open Source veröffentlicht werden?
❔ Welche Lizenzen eignen sich für Open Source?
❔ Welche digitalen Standards müssen genutzt werden?

❔ Was bedeutet Open-by-Default?

Egress vs. Ingress?

Wenn man Dateien in der Cloud speichert, berechnen sich die Kosten üblicherweise gemäss der Nutzung. Doch was heisst «Nutzung» im Cloud-Kontext überhaupt? Weshalb gibt es die Unterscheidung zwischen Ingress, Hosting und Egress? Und was bedeuten diese Begriffe überhaupt?

«Nutzung» kann für die Cloud tatsächlich unterschiedlich verstanden werden. Gebräuchlich sind die folgenden drei Begriffe, wovon der erste noch der am breitesten verstandene ist (vgl. auch die Abbildung):

• Hosting: Prozess der Aufbewahrung von Daten im System: z.B. Aufbewahren einer Datei in der Cloud (kostenpflichtig)
• Ingress: Prozess, in dem Daten ins System kommen (meist kostenlos): z.B. ein Upload einer Datei in die Cloud
• Egress: Prozess, in dem aus dem System fliessen (meist kostenpflichtig): z.B. ein Download einer Datei aus der Cloud

Cloud-Anbieter verrechnen Egress-Kosten unter anderem häufig, weil ihnen selbst durch Egress effektiv Kosten entstehen: Sie müssen die nötige Bandbreite für Downloads zur Verfügung stellen und entsprechende Verbindungen mit Internet-Service-Providern (ISPs) bereithalten. Die Verrechnung von Egress-Kosten dient auch dazu, die Nutzung der Dienste der Cloud-Anbieter zu steuern und zum Beispiel nicht regelmässig grosse Datenmengen über das öffentliche Internet zu verschieben.

Kostenvergleich

Zufälligerweise bin ich vor einigen Tagen über einen Artikel gestossen, der die Egress-Kosten von verschiedenen Cloud-Anbietern vergleicht. Die Unterschiede zwischen den Anbietern sind enorm. Wenn man die grossen Player im Markt vergleicht, gibt es eine Gemeinsamkeit: die Egress-Kosten sind in der Regel so ausgelegt, dass Kundinnen und Kunden einen grossen Anreiz haben, möglichst viele Teile ihrer Infrastruktur beim gleichen Anbieter zu haben. Ein Beispiel: wenn ich das Backup meiner Dateien in einer anderen Cloud habe als das Hosting, habe ich für jeden Backup-Vorgang Egress-Kosten. Typischerweise sind die Gebühren für Datentransfers innerhalb der gleichen Cloud sehr tief.

Es gibt aber auch Ausreisser: Wer nicht auf zum Beispiel spezifische Funktionen oder andere Aspekte des Angebots einer der grossen Dienstleister angewiesen ist, kann sich aktuell Egress-Kosten komplett sparen, wenn er oder sie beispielweise Cloudflare R2 (ein S3-kompatibler Object Storage) einsetzt. Ein Vergleich der Cloudanbieter lohnt sich in jedem Fall, mit möglichst konkreten Zahlen und Anforderungen für den eigenen Anwendungsfall. Je nach Dienst und Region können die Preise stark variieren. Dabei sind auch die häufig vorhandenen Freigrenzen («free allowance») und natürlich mögliche weitere Unterschiede der Angebote zu beachten.

Aber auch unabhängig davon, bei welchem Anbietern man ist, gibt es Möglichkeiten, wie die Egress-Kosten reduziert werden können.

Nutzende mit guter User Experience führen

Angesichts von Egress-Kosten spart jeder nicht gemachte Download Geld. Hinter dieser Binsenwahrheit steckt mehr als auf den ersten Blick ersichtlich ist: Wer viele und umfangreiche Downloads anbietet, die aus der Cloud kommen, tut gut daran, seine Nutzenden so zu führen, dass sie nur wirklich relevante Downloads auslösen. Gerade Anbieter von offenen Daten (Open Data bzw. OGD) stehen hier vor einem Dilemma: einerseits sollen die offenen Daten einer möglichst breiten Öffentlichkeit zugänglich sein, andererseits soll das Download-Budget (Egress) nicht schon bereits nach wenigen Monaten aufgebraucht sein bzw. die Kosten beliebig steigen.

Nutzende müssen also im Idealfall vor einem Download wissen, welche Daten sie vor sich haben. Es braucht klare Inhaltsangaben (Metadaten), Hinweise über die zeitliche, räumliche und/oder allenfalls thematische Abdeckung, idealerweise verbunden mit einer Vorschau der Daten und möglichen Anwendungsfällen – am besten kombiniert mit Hinweisen zur Grösse der Datei, der voraussichtlichen Download-Dauer und allenfalls Angaben zur digitalen Suffizienz (z.B. CO₂-Ausstoss pro Download) und mit der Möglichkeit des Downloads von Testdaten (in Form einer kleinen Stichprobe).

Um das alles zu erreichen, braucht es ein User Interface, das die Nutzenden zielgenau zu den für sie richtigen Daten führt. Umgekehrt müssen die Daten auch so strukturiert vorliegen, wie die Nutzenden diese (am häufigsten) brauchen: Wenn ich Messdaten typischerweise monatlich analysiere, diese aber nur als Gigabyte-grosse Datei über ein ganzes Jahr vorliegen, lade ich immer (für meinen Anwendungsfall) «zu viel» herunter. Dazu ist es unerlässlich mit den eigenen Nutzerinnen und Nutzern zu sprechen, ihre Bedürfnisse zu antizipieren und ihr tatsächliches Verhalten zu analysieren.

Technische Massnahmen

Neben einem gut gestalteten User Interface und der angenehmen User Experience gibt es auch noch verschiedene technische Massnahmen, die dabei helfen, die Egress-Kosten zu senken:

• Einsatz eines Content Delivery Networks (CDN): Ein CDN ist ein Cache, der räumlich bzw. «internet-topologisch» möglichst nah bei den Nutzenden Daten zur Verfügung stellt. Dadurch können die Kosten für Datentransfers aus der Cloud selbst reduziert werden.
• Verwendung geeigneter Dateiformate und/oder von Kompression: Ein passendes Datenformat kann die Dateigrösse stark beeinflussen (zum Beispiel Parquet anstatt CSV). Alternativ kann die ganz klassische Kompression, beispielsweise mit Zip/BZip/GZip/Brotli, helfen.
• Monitoring: Um die eigenen Kosten im Griff zu haben, ist es wichtig, ein geeignetes Monitoring aufzusetzen. So kann man frühzeitig Nutzungsmuster erkennen und bei Bedarf (zum Beispiel bei Serien-Downloads) geeignete Massnahmen ergreifen.
• Einschränkung des Zugriffs: Wenn Nutzende die Infrastruktur übermässig beanspruchen, dann ist die Ultima Ratio, den Zugriff zu sperren oder Downloads zumindest zu drosseln (d.h. die Geschwindigkeit von Downloads künstlich zu verringern). Der «Nutzende» kann in diesem Fall beispielsweise ein Skript sein, das zu oft Daten herunterlädt. Zu diesem Zweck ist es hilfreich, entsprechende Bestimmungen in den eigenen Nutzungsbestimmungen zu haben, zum Beispiel eine sogenannte Fair-Use-Klausel, wie sie beispielsweise das Bundesamt für Landestopografie swisstopo kennt.

Hinweis: dieser Blogpost wurde zuerst auf dem EBP-Blog digital.ebp.ch publiziert.

Headerbild: CC-BY J. Triepke (via Flickr)