
Datenqualität: Ein Sensor, der schweigt, darf keinen ruhigen Tag machen
Die Datenqualität von Besucherzahlen entscheidet sich nicht an dem Tag, an dem ein Sensor ganz schweigt, sondern an dem, an dem er halb ausfällt: Seine Tageszahl ist kleiner, aber plausibel, und sie geht als ruhiger Tag in jede Statistik. Erkennen lässt sich dieser Tag am Standort selbst - an seinen Minuten mit Daten, gemessen am 90. Perzentil seiner eigenen Tage.
Der Ausfall, vor dem man sich fürchtet, ist der vollständige: Der Sensor schweigt, die Anzeige zeigt einen Strich, jemand ruft an. Dieser Ausfall ist harmlos, weil er auffällt.
Gefährlich ist der halbe. Ein Sensor fällt am Vormittag für vier Stunden aus und liefert danach wieder. Am Abend steht eine Tageszahl in der Auswertung - kleiner als sonst, aber vorhanden. Es fehlt keine Zeile. Sie ist nur falsch.
Dieser Beitrag handelt von diesem Tag, und von einem zweiten, ebenso unauffälligen Fehler: dem Tag, der an der falschen Stelle beginnt. Er baut auf Warteschlangen und Wartezeiten messen auf, wo die drei Zustände gemessen, geschätzt und nicht gemessen beschrieben sind, und auf Belegung messen, wo es um den Strich statt der Null ging. Beides handelt vom Wert, der fehlt. Hier geht es um den Wert, der da ist und nicht stimmt.
Warum ein kleiner Tag schlimmer ist als ein leerer
Ein Sensor schreibt im Minutenraster. Ein normaler Betriebstag hat an einem Standort vielleicht 900 Minuten mit Zählungen. Schweigt der Sensor den grössten Teil des Tages, stehen am Abend vielleicht noch 40.
Jede Statistik, die auf Tageswerten aufbaut, liest diesen Tag als echten Tag mit wenig Verkehr. Warum auch nicht - er hat ein Datum, er hat eine Zahl, und die Zahl liegt in einem plausiblen Bereich. Eine Prüfung auf fehlende Werte findet nichts, weil nichts fehlt.
Das Ergebnis ist keine Lücke, sondern ein Fehlschluss, und zwar einer, der sich weiterträgt: in einen Wochentagsvergleich, in eine Korrelation mit dem Wetter, in eine Personalempfehlung. Alles plausibel, alles falsch - und nirgends ein Hinweis, dass es falsch sein könnte.
Ein Rechenbeispiel: aus 3 Prozent Wochenendplus werden 20
Wie weit ein paar kleine Tage eine Auswertung verschieben, lässt sich nachrechnen. Ein Standort hat an Werktagen 1'000 Besucher und am Wochenende 1'030 - ein Wochenendplus von 3 Prozent.
In einem Monat mit 20 Werktagen schweigt der Sensor an vier davon den grössten Teil des Tages; diese Tage melden je rund 300 Besucher. Der Durchschnitt der Werktage sinkt auf (16 × 1'000 + 4 × 300) / 20 = 860. Gegen 1'030 am Wochenende ergibt das ein Wochenendplus von rund 20 Prozent statt 3 - aus vier Tagen, an denen nichts geschehen ist ausser einem Ausfall.
Mit der Korrelation mit dem Wetter geschieht dasselbe: Häufen sich die Ausfalltage zufällig an Regentagen, misst die Korrelation den Sensor und nicht das Wetter.
An jeder dieser Zahlen kann eine Personalempfehlung hängen. Und beim Durchsehen fällt kaum jemandem eine davon als falsch auf, denn beide Zahlen erzählen eine Geschichte, die man sich vorstellen kann.
Der Massstab ist der Standort selbst
Die naheliegende Lösung wäre eine Mindestzahl aus dem Handbuch: Ein Tag zählt nur, wenn er mindestens so und so viele Minuten mit Daten hat. Sie scheitert an der Vielfalt der Standorte. Ein Flughafenterminal hat an jedem Tag fast jede Minute Verkehr, eine Boutique acht Stunden lang und danach keine.
Deshalb wird jeder Standort an sich selbst gemessen. Aus seinen eigenen Tagen entsteht eine Erwartung, wie viele Minuten mit Daten ein vollständiger Tag hat. Ein Tag, der deutlich darunter liegt, qualifiziert sich nicht und geht in keine Statistik ein.
| Schritt | Wie | Warum so |
|---|---|---|
| Erwartung | 90. Perzentil der Minuten mit Daten über alle Tage mit Daten | Ein vollständiger Tag dieses Standorts, nicht eines Durchschnittsstandorts |
| Schwelle | 80 Prozent dieser Erwartung | Normale Schwankung bleibt drin, ein Ausfall von Stunden fällt heraus |
| Ergebnis | qualifizierende und ausgeschlossene Tage, getrennt | Beide sind sichtbar, keiner verschwindet still |
Warum das 90. Perzentil und nicht der Median
Die Wahl sieht nach einem Detail aus und entscheidet, ob die Prüfung im schlimmsten Fall überhaupt funktioniert.
Der Median ist der mittlere Tag. Fällt ein Sensor in einem Fenster an mehr als der Hälfte der Tage teilweise aus, ist der Median selbst ein Ausfalltag. Die Erwartung sinkt auf das Niveau der Störung, und die Prüfung erklärt die Störung zum Normalfall. Sie versagt genau dann, wenn man sie am dringendsten braucht.
Ein Rechenbeispiel mit zehn Tagen. Sechs davon hatten einen Teilausfall und je rund 300 Minuten mit Daten, vier waren vollständig mit je 900:
| Massstab | Erwartung | Schwelle (80 %) | Die sechs Ausfalltage |
|---|---|---|---|
| Median | 300 Minuten | 240 Minuten | bestehen - und gehen als ruhige Tage in die Statistik |
| 90. Perzentil | 900 Minuten | 720 Minuten | fallen heraus - und werden als ausgeschlossen ausgewiesen |
Das 90. Perzentil liegt bei den vollständigsten Tagen des Fensters. Es bleibt auch dann richtig, wenn die Mehrheit der Tage beschädigt ist - solange es noch einige gute gibt. Ein Massstab, den auch viele schlechte Tage nicht nach unten ziehen, ist die Grundlage, die eine Ausfallprüfung braucht.
Warum dieselbe Menge für jede Kennzahl
Ein zweites Detail betrifft Auswertungen, die zwei Grössen zueinander in Beziehung setzen - Besucher gegen Temperatur, Besucher gegen Öffnungsstunden.
Werden die Ausfalltage für jede Grösse einzeln bestimmt, entstehen zwei leicht verschiedene Mengen von Tagen. Die Paare verrutschen: Der Besucherwert vom Dienstag steht plötzlich neben dem Wetterwert vom Mittwoch. Deshalb wird jede Reihe aus derselben Menge qualifizierender Tage abgeleitet. Das ist unspektakulär, und ohne es kann jede Korrelation zum Zufallsprodukt werden.
Ausgeschlossen heisst nicht versteckt
Ein Tag, der aus einer Auswertung fällt, verändert sie. Deshalb gehört die Zahl der ausgeschlossenen Tage an das Ergebnis und nicht in ein Protokoll, das niemand öffnet.
„Korrelation mit dem Wetter, 58 von 62 Tagen“ ist eine andere Aussage als „Korrelation mit dem Wetter“. Die erste sagt, worauf sie beruht. Die zweite verlangt Vertrauen.
Darum gehört die Prüfung vor jede Auswertung, die auf Tageswerten aufbaut: vor Anomalieerkennung und Besucherprognose, vor Einflussfaktoren, Szenarien und Personalbedarf, vor Korrelationen, Öffnungszeiten- und Wetteranalysen, vor Kampagnen- und Ländervergleichen. Und jede dieser Auswertungen sollte die Zahl der ausgeschlossenen Tage direkt anzeigen.
Und noch eine Folge, die man übersieht: Fehlen Tage, verschieben sich Gruppierungen. Eine Wochensaison, die nach Position statt nach Kalender rechnet, ordnet nach einem entfernten Montag jeden folgenden Wert dem falschen Wochentag zu. Die Lücken werden deshalb auf echte Kalendertage zurückgerechnet, bevor ein Wochenmuster entsteht.
Entfernen, nicht auffüllen
Wer einen Ausfalltag erkannt hat, steht vor einer Versuchung: ihn zu ergänzen. Den Durchschnitt der übrigen Dienstage einsetzen, die Lücke glätten, die Kurve schliessen. Das Diagramm sieht danach vollständiger aus.
Es ist trotzdem der falsche Weg, und zwar aus demselben Grund, aus dem die Prüfung existiert. Ein aufgefüllter Wert sieht aus wie ein gemessener. Er geht in Prognosen, Vergleiche und Korrelationen ein, und dort ist er von einer echten Messung nicht mehr zu unterscheiden. Man hätte den kleinen, falschen Tag durch einen plausiblen, erfundenen ersetzt.
Deshalb wird ein Ausfalltag entfernt und als entfernt ausgewiesen. Die Datenbasis wird dadurch kleiner, und das ist ehrlich: Eine Auswertung über 58 echte Tage ist belastbarer als eine über 62, von denen vier ausgedacht sind.
Ein Tag beginnt dort, wo der Standort steht
Der zweite unauffällige Fehler ist kein Ausfall, sondern eine Uhr. Dass Tages- und Stundensummen in der Zeitzone des Standorts gebildet werden, steht in Belegung messen. Wie schwer das richtig zu machen ist, steht dort nicht, und es lohnt sich, weil es an mehr Stellen schiefgehen kann, als man denkt.
Der Anker auf dem falschen Tag
Ein Portfolio über Zürich, Dubai und Auckland hat keinen gemeinsamen Tag. Das ist bekannt. Weniger bekannt ist, wie leicht ein Tag trotzdem verrutscht, selbst wenn jemand an Zeitzonen gedacht hat.
Ein verbreiteter Weg ist, einen Tag über einen Zeitpunkt zu bestimmen - etwa Mittag in Weltzeit - und ihn dann in die Ortszeit umzurechnen. In Zürich funktioniert das. In Auckland, im neuseeländischen Sommer bei Weltzeit plus 13 Stunden, wird aus Mittag Weltzeit ein Uhr nachts am Folgetag. Der Standort bekommt die Zahlen des falschen Tages, ohne dass irgendwo ein Fehler erscheint.
Deshalb werden Tagesbereiche auf dem Datum selbst verankert und nicht auf einem Zeitpunkt. Ein Datum hat keine Zeitzone, die es verschieben könnte.
Zeitumstellung: die Stunde, die es zweimal gibt
Am letzten Sonntag im Oktober gibt es in der Schweiz die Stunde von zwei bis drei Uhr zweimal. Am letzten Sonntag im März fehlt sie. Eine Stundenkurve, die das nicht weiss, zeigt an diesen Tagen einen Sprung - und niemand kann sagen, ob es das Geschäft war oder die Uhr.
Stundenbereiche werden deshalb aus der Wanduhrzeit aufgebaut, nicht durch Addieren von Stunden auf einen Startzeitpunkt. So bleibt 14 Uhr auch am Tag der Zeitumstellung 14 Uhr, und eine Kurve über das Wochenende der Umstellung braucht keine Fussnote.
Achse und Divisor aus einer Quelle
Der unscheinbarste der drei Fehler: Ein Diagramm beschriftet 31 Tage auf seiner Achse, der Durchschnitt darüber teilt durch 30, weil die beiden Zahlen an verschiedenen Stellen berechnet wurden. Die Differenz ist klein und fällt deshalb nie auf.
Achse und Divisor entstehen aus demselben Datums-Array. Ein Durchschnitt teilt damit durch genau die Tage, die sichtbar auf der Achse stehen. Ungültige, umgekehrte und über 366 Tage lange Zeiträume werden abgewiesen, bevor sie eine Zahl erzeugen.
Drei Uhr oder Mitternacht
Eine Unterscheidung gehört ausdrücklich dazu, weil sie sonst Monate später als unerklärliche Differenz auftaucht. Die laufende Belegung - am Standort und in den Zonen - schneidet den Tag um drei Uhr nachts Ortszeit, aus den Gründen, die in Belegung messen stehen. Alle übrigen Tagessummen beginnen um Mitternacht Ortszeit.
Beides ist richtig, weil es verschiedene Fragen beantwortet: „Wer ist gerade da“ braucht einen Nullpunkt, an dem niemand da ist. „Wie viele kamen am Dienstag“ braucht den Kalendertag. Man muss nur wissen, dass die beiden Ansichten um drei Stunden verschobene Tage beschreiben.
Datenqualität prüfen: woran man eine belastbare Zahl erkennt
Fünf Fragen, die jede Auswertung beantworten können sollte, bevor jemand eine Entscheidung darauf baut:
- Was passiert mit einem Tag, an dem der Sensor sechs Stunden geschwiegen hat? Geht er als kleiner Tag in die Statistik ein, oder wird er erkannt?
- Woran wird ein Ausfalltag gemessen? An einer festen Zahl, am Median, oder an einem Mass, das auch bei vielen schlechten Tagen richtig bleibt?
- Steht die Zahl der ausgeschlossenen Tage am Ergebnis? Oder muss man glauben, dass keine fehlen?
- Wo beginnt ein Tag? In der Ortszeit des Standorts, auf dem Datum verankert - und was passiert am Tag der Zeitumstellung?
- Durch was teilt der Durchschnitt? Durch die Tage auf der Achse, oder durch eine Zahl, die an anderer Stelle entstanden ist?
Keine dieser Fragen ist exotisch. Aber jede davon unterscheidet eine Zahl, die man glaubt, von einer, der man glauben kann.
Wie wir das machen
Im ANALYSIT Counting System wird jeder Tag geprüft, bevor er in eine der 14 statistischen Auswertungen eingeht, die auf Tageswerten aufbauen. Die Erwartung entsteht je Standort aus seinen eigenen Tagen, als 90. Perzentil der Minuten mit Daten; ein Tag unter 80 Prozent davon gilt als Ausfalltag und wird ausgeschlossen. Alle Reihen einer Auswertung stammen aus derselben Menge qualifizierender Tage.
Zu diesen 14 Auswertungen gehören Anomalieerkennung, Besucherprognose, Einflussfaktoren, Szenarien, Personalbedarf, Korrelation, Öffnungszeiten-Analyse, Wetterkorrelation und der Kampagnenvergleich. Jede zeigt die Zahl der ausgeschlossenen Tage direkt am Ergebnis.
Tages- und Stundenaggregationen entstehen je Standort in dessen eigener IANA-Zeitzone, Tagesbereiche sind auf dem Datum verankert, Stundenbereiche auf der Wanduhrzeit, und Achse und Divisor stammen aus demselben Datums-Array.
Wenn du bestehende Auswertungen gegen diese fünf Fragen halten willst, sprich mit uns. Oft reicht ein einziger Tag mit Teilausfall, um zu sehen, wie ein System damit umgeht.
