conversion: Konversionsleiter mit Herkunft auf dem Magic-Link-Token (Block 0)

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>

routes/console.php

@@ -3,6 +3,7 @@
 use App\Console\Commands\AggregatePressReleaseViews;
 use App\Console\Commands\GenerateManualInvoices;
 use App\Console\Commands\PublishScheduledPressReleases;
+use App\Console\Commands\PurgeConversionEvents;
 use App\Console\Commands\PurgeExpiredPressReleaseDrafts;
 use App\Console\Commands\PurgeMagicLinks;
 use App\Console\Commands\PurgePressReleaseEvents;
@@ -92,6 +93,14 @@ Schedule::command(PurgePressReleaseEvents::class)
     ->runInBackground()
     ->onFailure($alertOnFailure('press-releases:purge-events'));
 
+// Konversions-Ereignisse auf den Aufbewahrungszeitraum begrenzen (täglich 03:25).
+// Frist zusammen mit der Tabelle festgelegt (395 Tage), siehe config/conversion.php.
+Schedule::command(PurgeConversionEvents::class)
+    ->dailyAt('03:25')
+    ->withoutOverlapping()
+    ->runInBackground()
+    ->onFailure($alertOnFailure('conversion:purge-events'));
+
 // ========================================
 // Manueller Rechnungskreis (MAN-) — Legacy-Zahlungen
 // ========================================