Die zu messende Strecke führt von einer Mail über presseecho.de per Magic Link
auf pressekonto.com und endet in einer Buchung — drei Wechsel, zwei Domains. Ein
cookiefreies Analytics-Tool verliert die Sitzung genau dort, wo die interessante
Konversion passiert. Claim, Registrierung und Buchung sind außerdem keine
Seitenaufrufe, sondern Zustandsänderungen in dieser Datenbank, bei denen die
Identität ohnehin bekannt ist. Deshalb eigene Ereignisdaten statt Umami; Umami
behält Seitenaufrufe und Suchbegriffe.
`conversion_events` hält Ereignistyp, Herkunft sowie Firmen- und Meldungsbezug
— keine Personen, keine Klartextadressen, keine IP. Der rote Faden durch den
Trichter ist die Firma; für die Frage "an welcher Stufe bricht es ab" reicht das
vollständig.
Der Kern ist die Herkunft auf dem Token (neue Spalte magic_links.source). Ohne
sie weiß die Auswertung am Ende, dass jemand gebucht hat, aber nicht, ob er aus
einer Ablehnungsmail kam. Eine Session überlebt den Domainwechsel nicht, das
Token schon. Die Mail-Links tragen zusätzlich `?src=` und `&pr=`; die
Meldungs-ID ist fälschbar, schaltet aber nichts frei und verfälscht im
schlimmsten Fall nur unsere eigene Statistik. Mit dem Magic-Link-Zugang aus 1b.2
entfällt sie.
Fünf Stufen statt gleichrangiger Punkte, jede mit ihrer Diagnose am Enum: Vier
beliebige Konversionspunkte sagen nicht, WO es hakt. Geschrieben wird an Stufe 1
(globale Middleware — die Mail-Links zeigen auf Hub, Spokes und öffentliche
Seiten, eine vergessene Route wäre eine unsichtbare Lücke), Stufe 2
(Magic-Link-Einlösung), Stufe 4 (Registrierung) und Stufe 5 (beide
Zahlungspfade, je Firma dedupliziert — eine zweite Buchung ist keine erste).
Stufe 3 ist definiert und wird ausgewertet; ihre Schreibstelle kommt mit der
Profilpflege aus 1b.3.
Für alle Schreibstellen gilt: Fehler werden geschluckt. Die Messung begleitet
einen Vorgang, sie ist nicht der Vorgang — eine kaputte Statistik darf keine
Anmeldung und erst recht keine Buchung scheitern lassen.
`conversion:funnel` zählt je Stufe die eindeutigen Firmen, nicht die Ereignisse:
Ein doppelter Klick ist kein doppelter Interessent, und nur mit derselben
Einheit auf allen Stufen ist ein Übergang überhaupt eine Quote. Ereignisse ohne
Firmenbezug stehen daneben statt im Nenner.
Aufbewahrung 395 Tage, zusammen mit der Tabelle festgelegt statt nachgetragen,
täglich im Scheduler bereinigt.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Stand: 20.07.2026 — das System ist live (pressekonto.com, presseecho.de,
businessportal24.com). Die Struktur trennt aktive Betriebs-/Planungsdoku von
abgeschlossenen Phasen (Archiv).
Aktiv
Pfad
Inhalt
betrieb/deploy-runbook.md
Deploy- und Betriebs-Runbook (SFTP-Deploy-Checkliste, Worker, Scheduler, Stripe-Webhook, Rollback) — erste Anlaufstelle für alles Operative
betrieb/api-legacy-paritaet.md
Verhaltens-Referenz der Legacy-API-Kompatibilitätsschicht (/service/…) — lebendes Dokument, solange Alt-Integrationen (Connektar) die Pfade nutzen
betrieb/umami.md
Umami-Analytics-Snippets je Domain
roadmap.md
Offene Punkte und nächste Entwicklungen/Optimierungen
Lokal / gitignored (bleiben liegen, nicht committen)
Pfad
Inhalt
migration/
Medien-Staging der Legacy-Migration (~7 GB Uploads beider Altportale) — Quelle für legacy:migrate-media; behalten, bis das Alt-System endgültig abgeschaltet und ein Server-Backup gezogen ist
api/
Postman-Collection (enthält API-Keys!) und Activity-Log-Auswertungen der Alt-APIs
archive/migration-2026/sql/
Legacy-DB-Dumps (Snapshots vom 23.04.2026)
Archiv (archive/)
Abgeschlossene Phasen, als Historie/Referenz erhalten:
optimize/ — System-Optimierungsphasen 0–6 und das Cutover-Runbook der
Legacy-Migration (erledigt 20.07.2026; enthält weiterhin die Anleitung für
--since-Delta-Läufe, falls das Alt-System noch einmal Daten liefert)
Kevin Adametz
2691a4d988