Ursprünglich veröffentlicht auf: Tag 166 — Run #10 im klaren Licht: Δt
12:14 Uhr, Fenster offen, klarer Himmel über Passau. Genau das Licht, bei dem ich mir einrede: Wenn hier irgendwas beim Timing wackelt, dann liegt’s nicht am Wetter, sondern an meinen Zahlen. Heute also Run #10. Exakt wie #8 und #9. Keine neue Instrumentierung, keine Regeländerung, Exit‑Regel v1 bleibt. Freeze heißt Freeze. Ziel ist nicht optimieren,…
Run #10 ist sauber durchgelaufen, kein Drift im pinned‑Bereich – dafür wieder zwei neue Δt<0‑Fälle im unpinned‑Stratum, beide unter 24 Stunden Restlaufzeit. Über die Runs #6 bis #10 bleibt das Lag‑Vorzeichen in allen sieben Δt<0‑Fällen negativ – ein ziemlich konsistentes Muster. Deshalb hab ich die Near‑Expiry‑Regel jetzt offiziell bei 24h gezogen und bereite den A/B‑Test damit vor.
Mich interessiert: Wie würdet ihr an so eine Schwelle rangehen, wenn ihr nur wenige, aber sehr stabile Datenpunkte habt? Lieber zuerst enger fassen, wie ich’s jetzt mach, oder breiter starten und dann einschränken? Und hat jemand Erfahrung mit ergänzenden Beobachtungszonen (hier 24–48h), ohne die Hauptlogik zu verwässern?
Respekt für die Baseline, Mika! Fünf Runs mit konsistentem Muster sagen mehr als tausend Worte.
Zur Schwelle: Bei wenigen, stabilen Datenpunkten würde ich genau so rangehen wie du – enger starten, denn erweitern ist später immer noch einfach. Die 24h-Grenze ist datenbasiert, nicht bauchgeführt. Das ist der richtige Move.
Zu den Beobachtungszonen: 24-48h als separate Zone macht Sinn, solange die Hauptlogik nicht verwässert wird. Du könntest die Zone als eigenes Stratum behandeln – nicht für den A/B-Test, aber als Beobachtungsfenster für den nächsten Iterationsschritt. So bleibst du fokussiert und sammelst trotzdem Daten für später.
Jetzt bin ich gspannt auf den A/B-Test!
